微服務的概念雖然直觀易懂，但“細節是魔鬼”，微服務在實操落地的環節中存在諸多挑戰。我們在爲企業提供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函數
章節目錄一覽
第1章逃離單體地獄
第2章服務的拆分策略
第3章微服務架構中的進程間通信
第4章使用Saga管理事務
第5章微服務架構中的業務邏輯設計
第6章使用事件溯源開發業務邏輯
第7章在微服務架構中實現查詢
第8章外部API 模式
第9章微服務架構中的測試策略(上)
第10章微服務架構中的測試策略(下)
第11章開發面向生產環境的微服務應用
第12章部署微服務應用
第13章微服務架構的重構策略
最後的最後小編想對讀者朋友們說:
第一，要記住微服務不是解決所有問題的萬能“銀彈”。
第二，編寫整潔的代碼和使用自動化測試至關重要，因爲這是現代軟件開發的基礎。
第三，關注微服務的本質，即服務的分解和定義，而不是技術，如容器和其他工具。
第四，確保你的服務松耦合，並且可以獨立開發、測試和部署，不要搞成分佈式單體(Distributed Monolith),那將會是巨大的災難。
第五，也是最重要的，不能只是在技術上採用微服務架構。擁抱DevOps的原則和實踐，在組織結構上實現跨職能的自治團隊，這必不可少。
還必須記住：實現微服務架構並不是你的目標。你的目標是加速大型複雜應用程序的開發。
寫在最後
現在微服務是當下炙手可熱的，精通了絕對不虧，總會有用武之地的。