微服務的概念雖然直觀易懂，但“細節是魔鬼”，微服務在實操落地的環節中存在諸多挑戰，我們在為企業提供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領取方式也簡單，作為電子版全網首發，需要領取的朋友麻煩幫忙轉發點贊這篇文章+關注小編，掃碼獲取！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/76126.html
標籤：其他