微服務的概念雖然直觀易懂，但“細節是魔鬼”，微服務在實操落地的環節中存在諸多挑戰。我們在為企業提供PaaS、人工智慧、雲原生平臺等數字化轉型解決方案時也發現，企業實現雲原生，並充分利用PaaS能力的第一步，往往是對已有應用架構進行現代化微服務改造，而如何進行微服務拆分、設計微服務邏輯、實現微服務治理等實操問題成為很大的挑戰。

本文既包含了微服務的原理、原則，又包含了實際落地中的架構設計模式；既包含可舉一反三的理念和概念，也包含類似領域驅動設計、Saga實現事務操作、CQRS構建事件驅動系統等具體可套用的示例。本書可以幫助讀者把傳統的單體巨石型應用循序漸進地改造為微服務架構，從微服務的拆分，微服務架構下業務邏輯的設計以及事務、API、 通訊等的實現，一直到微服務系統的測試與生產上線，幫助讀者建立從無到有的完整微服務系統搭建的生命週期。

書籍優質內容節選

第8章外部APl模式

8.1外部API的設計難題

為了探索與API相關的各種問題，讓我們考慮一下FTGO應用程式。如圖8-1所示,該應用程式的服務由各種客戶端使用。使用服務API的客戶端一共有四種:

■Web應用程式，如Consumer web 應用程式一為 消費者實現基於瀏覽器的使用者介面，Restaurant web 應用程式一實 現基於瀏覽器的餐館使用者介面，以及AdminWeb應用程式一實 現供內部管理員使用的使用者介面。

■在瀏覽器中執行的JavaScript應用程式。

■移動應用程式，一個供消費者使用，另一個供送餐員使用。

■由第三方開發人員編寫的應用程式。

Web應用程式在防火牆內部執行，因此它們通過高頻寬、低延遲的區域網訪問服務。其他客戶端在防火牆之外執行，因此它們通過較低頻寬、較高延遲的網際網路或行動網路訪問服務。

API的一種設計思路是讓客戶端直接呼叫服務。從表面上看，這聽起來非常簡單，畢竟，這就是客戶端呼叫單體應用程式的API的方式。但由於存在以下弊端，這種方法很少用於微服務架構：

■細粒度服務API要求客戶端發出多個請求以檢索所需的資料，這樣做效率低，並且可能導致糟糕的使用者體驗。

■由於客戶端了解每項服務以及服務的API從而導致封裝不足(緊耦合),因此今後很難更改服務的架構和API。

”服務可能使用對客戶端而言不便或不能使用的程式間通訊機制，尤其是防火牆外的客戶端。

要了解有關這些弊端的更多資訊，讓我們來看看FTGO移動應用程式如何從服務中檢索資料。

8.1.1 FTGO 移動客戶端API的設計難題

消費者使用FTGO移動客戶端來下訂單和管理他們的訂單。想象一下，你正在開發移動客戶端的View Order檢視，該檢視顯示訂單。如第7章所述，此檢視顯示的資訊包括基本訂單資訊，如訂單狀態、付款狀態、餐館視角下的訂單狀態，以及送餐狀態(包括其位置和運輸過程中的預計送餐時間)。

FTGO應用程式的單體版本具有返回訂單詳細資訊的API介面。移動客戶端通過發出單一請求來檢索所需的資訊。相比之下，在FTGO應用程式的微服務版本中，如前所述，訂單詳細資訊分散在多個服務中，包括以下內容:

■Order Service: 基本訂單資訊，包括詳細資訊和狀態。

■Kitchen Service: 餐館視角下的訂單狀態以及送餐員可以取餐的預計時間。

■Delivery Service: 訂單的送餐狀態，預計送餐時間和當前位置。

如果移動客戶端直接呼叫服務，則必須如圖8-2所示，進行多次呼叫以檢索此資料。

在此設計中，移動應用程式扮演著API組合器的角色。它呼叫多個服務並組合結果。儘管這種方法看似合理，但它有幾個嚴重的問題。

...........................

8.1.2其他型別客戶端API的設計難題

8.2 API Gateway模式

8.2.1什麼是 API Gateway模式

8.2.2 API Gateway模式的好處和弊端

8.2.3以Netlix為例的API Gateway

8.2.4 API Gateway的設計難題

8.3實現一個 API Gateway

8.3.1使用現成的 API Gateway產品或服務

8.3.2開發自己的API Gateway

8.3.3使用GraphQL實現API Gateway

第12章部署微服務應用

12.1部署模式: 程式語言特定的釋出包格式

12.1.1使用程式語言特定的釋出包格式進行部署的好處

12.1.2使用程式設計語 言特定的釋出包格式進行部署的弊端

12.2部署模式: 將服務部署為虛擬機器器

12.2.1將服務部署為虛擬機器器的好處

12.2.2將服務部署為虛擬機器器的弊端

12.3部署模式: 將服務部署為容器

12.3.1使用 Docker部署服務

12.3.2將服務部署為容器的好處

12.3.3將服務部署為容器的弊端

12.4使用Kubernetes部署FTGO應用程式

12.4.1什麼是Kubernetes

12.4.2在 Kubernetes.上部署Restaurant Service

12.4.3部署 API Gateway

12.4.4零停機部署

12.4.5使用服務網格分隔部署與釋出流程

12.5部署模式: Serverless部署

12.5.1使用 AWS Lambda進行Serverless部署

12.5.2開發Lambda函式

12.5.3呼叫Lambda函式

12.5.4使用Lambda函式的好處

12.5.5使用Lambda函式的弊端

12.6使用AWS Lambda和AWS Gateway部署RESTful服務

12.6.1 AWS Lambda版本的Restaurant Service

12.6.2把服務打包為ZIP檔案

12.6.3使用Serverless 框架部署Lambda函式

這份微服務架構設計模式PDF，小編已經為大家整理完畢，PDF內容完整，需要免費領取麻煩幫忙轉發一下這篇文章+關注我，然後掃碼免費獲取。

章節目錄一覽

第1章逃離單體地獄

第2章服務的拆分策略

第3章微服務架構中的程式間通訊

第4章使用Saga管理事務

第5章微服務架構中的業務邏輯設計

第6章使用事件溯源開發業務邏輯

第7章在微服務架構中實現查詢

第8章外部API 模式

第9章微服務架構中的測試策略(上)

第10章微服務架構中的測試策略(下)

第11章開發面向生產環境的微服務應用

第12章部署微服務應用

第13章微服務架構的重構策略

最後的最後小編想對讀者朋友們說:

第一，要記住微服務不是解決所有問題的萬能“銀彈”。

第二，編寫整潔的程式碼和使用自動化測試至關重要，因為這是現代軟體開發的基礎。

第三，關注微服務的本質，即服務的分解和定義，而不是技術，如容器和其他工具。

第四，確保你的服務鬆耦合，並且可以獨立開發、測試和部署，不要搞成分散式單體(Distributed Monolith),那將會是巨大的災難。

第五，也是最重要的，不能只是在技術上採用微服務架構。擁抱DevOps的原則和實踐，在組織結構上實現跨職能的自治團隊，這必不可少。

還必須記住：實現微服務架構並不是你的目標。你的目標是加速大型複雜應用程式的開發。

寫在最後

這份PDF領取方式也簡單，作為電子版全網首發，需要領取的朋友麻煩幫忙轉發轉發這篇文章+關注小編，然後新增小編vx：kaixindian331免費獲取。