架構模式
微服務像亞馬遜這樣的大多數企業最初都是以整體式應用程式作為業務基礎，因為這是一類開發速度最快、難度最低的系統。但是，這種將各個程序緊密組合並作為單一整體服務的作法，往往會帶來一系列嚴重問題。
如果應用程式中的某個程序遭遇需求高峰，我們只能擴充套件整體架構才能實現單個程序的擴容。另外，隨著程式碼庫規模的增長，功能的新增與改進也開始變得非常複雜，這讓企業很難試驗以及實現新的想法。
整體式架構還增加了應用程式的可用性風險，因為大量相互依賴且緊密耦合的程序會增加單一程序因故障受到的影響。這就是微服務架構隨企業發展而出現的原因所在。利用微服務架構，應用程式將由眾多獨立元件構成，這些元件將各個應用程式的程序以單一服務形式執行。服務將專為業務功能而構建，例如線上購物車，而且每項服務只負責自己的一項功能。這些程序獨立執行並由對應的一支開發團隊負責管理，因此我們可以對各服務進行獨立更新、部署與擴充套件，最終滿足對應用程式特定功能的需求。
舉例來說，當出現使用者購買峰值時，我們可以單純擴容購物車服務以強化承載能力。隨著組織由整體式架構逐步轉向微服務架構，很多開發人員也希望透過流水線管理各項服務中的依賴關係，這就要求我們創造出新的方法以實現應用程式打包與程式碼執行。好訊息是，憑藉著強大的創新成果儲備，如今例項已經不再是我們的唯一計算選項。
大家也可以使用容器或者 AWS Lambda 函式。容器是目前最受歡迎的程式碼打包選項，同時也是實現遺留應用程式現代化的最佳工具之一。容器技術，為我們帶來出色的應用程式可移植性與設定靈活性。而利用 Lambda，大家則能夠更輕鬆地獲取所需功能，利用程式碼編寫出業務邏輯即可。微服務架構的另一大需求，在於我們必須為之建立一種服務間的相互通訊方式。
目前大部分應用程式都繼續沿用 API 連線，但也有一些選擇在不同服務之間傳送資料。具體包括用於實時資料處理的流、用於根據資料變化觸發響應的事件，以及用於應用級通訊及可見性的服務網格等等。大家可以根據自身需求選擇最適合自己應用程式的整合方法。
架構模式
微服務像亞馬遜這樣的大多數企業最初都是以整體式應用程式作為業務基礎，因為這是一類開發速度最快、難度最低的系統。但是，這種將各個程序緊密組合並作為單一整體服務的作法，往往會帶來一系列嚴重問題。
如果應用程式中的某個程序遭遇需求高峰，我們只能擴充套件整體架構才能實現單個程序的擴容。另外，隨著程式碼庫規模的增長，功能的新增與改進也開始變得非常複雜，這讓企業很難試驗以及實現新的想法。
整體式架構還增加了應用程式的可用性風險，因為大量相互依賴且緊密耦合的程序會增加單一程序因故障受到的影響。這就是微服務架構隨企業發展而出現的原因所在。利用微服務架構，應用程式將由眾多獨立元件構成，這些元件將各個應用程式的程序以單一服務形式執行。服務將專為業務功能而構建，例如線上購物車，而且每項服務只負責自己的一項功能。這些程序獨立執行並由對應的一支開發團隊負責管理，因此我們可以對各服務進行獨立更新、部署與擴充套件，最終滿足對應用程式特定功能的需求。
舉例來說，當出現使用者購買峰值時，我們可以單純擴容購物車服務以強化承載能力。隨著組織由整體式架構逐步轉向微服務架構，很多開發人員也希望透過流水線管理各項服務中的依賴關係，這就要求我們創造出新的方法以實現應用程式打包與程式碼執行。好訊息是，憑藉著強大的創新成果儲備，如今例項已經不再是我們的唯一計算選項。
大家也可以使用容器或者 AWS Lambda 函式。容器是目前最受歡迎的程式碼打包選項，同時也是實現遺留應用程式現代化的最佳工具之一。容器技術，為我們帶來出色的應用程式可移植性與設定靈活性。而利用 Lambda，大家則能夠更輕鬆地獲取所需功能，利用程式碼編寫出業務邏輯即可。微服務架構的另一大需求，在於我們必須為之建立一種服務間的相互通訊方式。
目前大部分應用程式都繼續沿用 API 連線，但也有一些選擇在不同服務之間傳送資料。具體包括用於實時資料處理的流、用於根據資料變化觸發響應的事件，以及用於應用級通訊及可見性的服務網格等等。大家可以根據自身需求選擇最適合自己應用程式的整合方法。