Google App Engine 的微服務架構

「微服務」是一種應用程式開發架構風格，可讓大型應用程式分解成獨立的組成部分，每個部分都有各自負責的範圍。為了向單一使用者提供服務或處理 API 要求，微服務型應用程式可呼叫許多內部微服務來建構回應。

經過妥善實作的微服務型應用程式可達到下列目標：

• 在多個微服務之間定義完善協定。
• 允許獨立的部署週期，包括復原。
• 協助在子系統中進行 A/B 版本並行測試。
• 降低測試自動化和品管方面的負擔。
• 讓記錄和監控作業更清楚好懂。
• 提供精密的成本會計作業。
• 提高應用程式整體的擴充性和穩定性。

Google App Engine 提供許多適用於微服務型應用程式的功能。本頁面將概略說明在 Google App Engine 中將應用程式部署為微服務型應用程式的最佳做法。

以微服務的形式使用 App Engine 服務

在 App Engine 專案中，您可以將多個微服務部署為個別的服務 (先前在 App Engine 中稱為模組)。這些服務的程式碼完全獨立，您只能透過 HTTP 叫用來執行這些服務的程式碼，例如透過使用者要求或符合 REST 樣式的 API 呼叫。一項服務中的程式碼無法直接呼叫另一服務中的程式碼。程式碼可獨立部署至服務中，且不同服務可使用不同語言編寫，例如 Python、Java、Go 和 PHP。系統會分別管理各服務的自動調度資源流程、負載平衡和機器執行個體類型。

服務中的版本

此外，每項服務都可同時部署多個「版本」。每項服務都會提供一個預設版本，但由於各服務的每個版本都有對應位址，因此您也可以直接存取已部署的其他所有版本。這個結構可帶來諸多可能，包括對新版本進行冒煙測試、在不同版本之間進行 A/B 測試，以及簡化向前復原和復原作業。App Engine 架構針對大部分的這些項目提供輔助機制。我們會在後續各節中深入說明這些機制。

服務區隔

雖然大部分服務都各自獨立，但還是會共用部分 App Engine 資源。舉例來說，App Engine 專案中的服務會共用 Cloud Datastore、Memcache 和工作佇列資源。雖然這樣可帶來一些好處，但微服務型應用程式還是得讓不同微服務的程式碼和資料保持獨立。有些架構模式可協助減少不必要的共用情況，詳情請見後文。

專案區隔

如果您不想依賴這些模式來達到區隔效果，並想以更正式的方式強制實行區隔，那麼您可以使用多項 App Engine 專案。使用專案而非服務有好有壞，您必須視自己的情況進行取捨。除非您特別需要使用多項專案帶來的某項好處，否則建議您先在單一專案使用多項服務，因為這種做法效能較佳，管理方面的負擔也可降至最低。當然，您也可以選擇混用這兩種做法。

服務區隔和專案區隔的比較

下表提供在微服務架構中使用多項服務和多項專案的比較：

	多項服務	多項專案
程式碼區隔	不同服務和版本的已部署程式碼各自獨立。	不同專案的已部署程式碼各自獨立，各專案中不同服務和版本的已部署程式碼亦同。
資料區隔	不同服務和版本會共用 Cloud Datastore 和 Memcache，但可使用「命名空間」做為開發人員模式以區隔資料。針對工作佇列區隔，您可以採用開發人員的佇列命名慣例，例如 user-service-queue-1。	不同專案的 Cloud Datastore、Memcache 和工作佇列彼此完全獨立。
記錄區隔	每項服務 (和版本) 都有獨立記錄，不過這些記錄可以合併查看。	每項專案 (以及各專案的服務和版本) 都有獨立記錄，不過特定專案的所有記錄可以合併查看。不同專案的記錄無法合併查看。
效能負擔	相同專案的服務會部署在相同資料中心，因此使用 HTTP 從某項服務呼叫其他服務的延遲非常低。	專案可能會部署在不同的資料中心，因此 HTTP 延遲可能較高，不過 Google 提供世界一流的網路，因此延遲仍然頗低。
成本會計	各項服務的執行個體時數 (用於執行程式碼的 CPU 和記憶體) 成本不會分開；整個專案的所有執行個體時數會合併在一起。	不同專案的成本會分開，方便您瞭解不同微服務的成本。
操作者權限	操作者可部署程式碼、向前復原和復原版本，以及查看專案中所有服務的記錄。您無法限制對特定服務的存取權。	不同專案的操作者權限可分開管理。
要求追蹤	透過 Google Cloud Trace，您可以針對相同專案中的服務查看要求和所產生微服務要求的追蹤記錄，而且所有追蹤記錄會整合成一筆記錄。有了這項功能，您就能以更輕鬆的方式提高效能。	如果 Cloud Trace 呼叫隸屬於同一個 機構，系統就能以視覺化的方式呈現不同 GCP 專案中的 Cloud Trace 呼叫。

後續步驟

• 瞭解如何透過 App Engine 的微服務建立及命名開發、測試和品質確保作業，以及測試環境和實際工作環境。
• 瞭解將 API 設計為能在不同微服務之間進行通訊的最佳做法。
• 瞭解發揮微服務效能的最佳做法。
• 瞭解如何將現有的龐大應用程式遷移至微服務。
• 瞭解您是否適合使用微服務。Google 解決方案架構師 Preston Holmes 在他的個人網誌中發布了一篇文章，說明他在微服務中發現的一些缺點。