微服務(wù)架構(gòu)

作者：DevOps亮哥

來自：DevOps探路者

一、關(guān)鍵點(diǎn)：

對于面向?qū)ο蟮脑O(shè)計(jì)，我們遵循SOLID原則。對于微服務(wù)設(shè)計(jì)，我們建議開發(fā)人員遵循IDEALS原則：接口分離（Interface segregation），可部署性（deployability），事件驅(qū)動(dòng)（event-driven），可用性勝于一致性（Availability over Consistency），松耦合（Loose coupling）和單一責(zé)任（single responsibility）。

• 接口分離：指的是不同類型的客戶端（移動(dòng)應(yīng)用程序，web應(yīng)用程序，CLI程序）應(yīng)該能夠通過適合其需求的協(xié)議與服務(wù)端交互。
• 可部署性：指的是在微服務(wù)時(shí)代，也就是DevOps時(shí)代，開發(fā)人員需要在打包、部署和運(yùn)行微服務(wù)方面做出關(guān)鍵的設(shè)計(jì)決策和技術(shù)選擇。
• 事件驅(qū)動(dòng)：指的是在任何時(shí)候，都應(yīng)該對服務(wù)進(jìn)行建模，通過異步消息或事件而不是同步調(diào)用。
• 可用性勝于一致性：指的是最終用戶更看重系統(tǒng)的可用性而不是強(qiáng)一致性，它們對最終一致性也很滿意。
• 松耦合：仍然是一個(gè)重要的設(shè)計(jì)問題，涉及傳入和傳出的耦合。
• 單一責(zé)任：是一種思想，它支持對不太大或太細(xì)的微服務(wù)進(jìn)行建模，因?yàn)樗麄儼诉m當(dāng)數(shù)量的內(nèi)聚功能。

在2000年，Robert C. Martin編寫了面向?qū)ο笤O(shè)計(jì)的五個(gè)原則。Michael Feathers后來將這五個(gè)原則的首字母組成了縮略詞，也就是SOLID。從那時(shí)起，用于OO設(shè)計(jì)的SOLID原則就在業(yè)界被廣為人知。這五個(gè)原則是：

• 單一責(zé)任原則（Single responsibility principle）
• 開閉原則（Open/closed principle）
• 里氏代換原則（Liskov substitution principle）
• 界面分離原則（Interface segregation principle）
• 依賴倒置原則（Dependency inversion principle）

幾年前，我在給其他人講授微服務(wù)設(shè)計(jì)時(shí)，一個(gè)學(xué)生問：“SOLID原則適用于微服務(wù)嗎”，經(jīng)過一番思考，我的回答是“部分”。后面的幾個(gè)月，我發(fā)現(xiàn)我一直在尋找微服務(wù)的基本設(shè)計(jì)原則（包含一些縮略詞）。為什么這樣的問題會(huì)如此重要呢？

作為一個(gè)行業(yè)，我們已經(jīng)設(shè)計(jì)和實(shí)施基于微服務(wù)的解決方案已經(jīng)超過六年了。在此期間，越來越多的工具、框架、平臺(tái)和支撐產(chǎn)品圍繞微服務(wù)建立了一個(gè)極其豐富的技術(shù)環(huán)境。在這種情況下，一個(gè)新手微服務(wù)開發(fā)人員在面對一個(gè)微服務(wù)項(xiàng)目中許多設(shè)計(jì)決策和技術(shù)選擇時(shí)會(huì)感到迷惑。在這個(gè)領(lǐng)域，一組核心原則可以幫助開發(fā)人員更好的理解基于微服務(wù)的解決方案。

雖然有些SOLID原則適用于微服務(wù)，但面向?qū)ο笫且环N設(shè)計(jì)范式，它處理的元素有類、接口和繼承等，與一般分布式系統(tǒng)中的元素（特別是微服務(wù)）有著根本的區(qū)別。

因此，我們提出以下一套微服務(wù)設(shè)計(jì)的核心原則：

• 接口分離（Interface segregation）
• 可部署性（Deployability (is on you)）
• 事件驅(qū)動(dòng)（Event-driven）
• 可用性勝于一致性（Availability over consistency）
• 松耦合（Loose coupling）
• 單一職責(zé)（Single responsibility）

這些原則并沒有覆蓋基于微服務(wù)的解決方案的所有設(shè)計(jì)決策，但他們涉及到創(chuàng)建現(xiàn)代基于服務(wù)的系統(tǒng)的關(guān)鍵關(guān)注點(diǎn)和成功因素。下面對微服務(wù)的“IDEALS”的原則進(jìn)行詳細(xì)的解釋。

二、接口分離

最初的接口分離原則是指防止面向?qū)ο笾蓄愂褂谩芭帧苯涌?。換句話說，就是每種類型的客戶端應(yīng)該有單獨(dú)的接口，而不是提供一個(gè)滿足所有客戶端需要的所有可能方法的接口。

微服務(wù)體系結(jié)構(gòu)風(fēng)格是面向服務(wù)體系結(jié)構(gòu)的一種特殊化，其中接口（即服務(wù)契約）的設(shè)計(jì)一直是最重要的。從21世紀(jì)初開始，SOA文檔就規(guī)定了所有客戶端都應(yīng)該遵守的規(guī)范模型和規(guī)范模式。然而，自從SOA的舊時(shí)代以來，我們處理服務(wù)契約設(shè)計(jì)的方式發(fā)生了改變。在微服務(wù)時(shí)代，同一個(gè)服務(wù)邏輯通常有許多客戶端程序。這就是將接口分離應(yīng)用于微服務(wù)的主要目的。

實(shí)現(xiàn)微服務(wù)的接口分離

微服務(wù)接口分離的目標(biāo)是每種類型的前端都能看到最適合其需求的服務(wù)契約。例如，一個(gè)移動(dòng)應(yīng)用程序系統(tǒng)調(diào)用端點(diǎn)，這些端點(diǎn)返回簡短的JSON格式數(shù)據(jù)作為響應(yīng)。當(dāng)另一個(gè)web應(yīng)用程序需要返回完整的JSON格式數(shù)據(jù)作為響應(yīng)。與此同時(shí)，還有一個(gè)桌面應(yīng)用程序調(diào)用同一個(gè)服務(wù)，但需要返回完整的XML格式數(shù)據(jù)。不同的客戶端也可能使用不同的協(xié)議。例如，外部的客戶端希望使用HTTP來調(diào)用gRPC服務(wù)。

我們沒有試圖在所有類型的服務(wù)客戶機(jī)上強(qiáng)加相同的服務(wù)契約（使用規(guī)范模型），而是通過“分離接口”，以便每種類型的客戶機(jī)都能看到它需要的服務(wù)接口。我們怎么做？一個(gè)突出的選擇是使用API網(wǎng)關(guān)，它可以進(jìn)行消息格式轉(zhuǎn)換（message format transformation），消息結(jié)構(gòu)轉(zhuǎn)換（message structure transformation），協(xié)議橋接（protocol bridging），消息路由（message routing）等。一個(gè)流行的替代方案是BFF（Backend for Frontends）模式。在這種情況下，我們?yōu)槊糠N不同類型的客戶機(jī)提供了一個(gè)API網(wǎng)關(guān)，也就是通常說的，為每種客戶機(jī)提供不同的BFF,如下圖所示：

三、可部署性

幾乎在整個(gè)軟件歷史上，設(shè)計(jì)工作都集中在與實(shí)現(xiàn)單元（模塊）如何組織以及運(yùn)行時(shí)元素如何交互相關(guān)的設(shè)計(jì)決策上。架構(gòu)策略、設(shè)計(jì)模式和其他設(shè)計(jì)策略為在層中組織軟件元素、避免過度依賴、為特定類型的組件分配特定的角色或關(guān)注點(diǎn)以及軟件空間中的其他設(shè)計(jì)決策提供了指導(dǎo)。對于微服務(wù)開發(fā)人員來說，有一些關(guān)鍵的設(shè)計(jì)決策超出了軟件元素。

作為開發(fā)人員，我們早就意識(shí)到將軟件正確打包并部署到適當(dāng)?shù)倪\(yùn)行時(shí)環(huán)境中的重要性。然而，我們從沒有像今天的微服務(wù)那樣關(guān)注部署和運(yùn)行時(shí)監(jiān)控。在這里稱為“可部署性”的技術(shù)和設(shè)計(jì)決策領(lǐng)域已經(jīng)成為微服務(wù)成功的關(guān)鍵。主要原因是一個(gè)簡單的事實(shí)，即微服務(wù)顯著增加了部署單元的數(shù)量。

因此，IDEALS中的D代表微服務(wù)開發(fā)者有責(zé)任確保軟件及其新版本隨時(shí)可以部署到環(huán)境中供用戶使用?？傊刹渴鹦园ǎ?/p>

• 配置運(yùn)行時(shí)基礎(chǔ)設(shè)施，包括容器、pods、集群、持久性、安全性和網(wǎng)絡(luò)。
• 微服務(wù)的擴(kuò)縮容，或者將他們從一個(gè)運(yùn)行時(shí)環(huán)境遷移到另一個(gè)運(yùn)行時(shí)環(huán)境。
• 加速提交+構(gòu)建+測試+部署過程
• 減少版本升級(jí)時(shí)的停機(jī)時(shí)間
• 同步相關(guān)軟件的版本更改
• 監(jiān)控微服務(wù)運(yùn)行狀況，以快速識(shí)別和修復(fù)故障。

實(shí)現(xiàn)良好的可部署性

自動(dòng)化是實(shí)現(xiàn)高效部署的關(guān)鍵。自動(dòng)化包括明智的使用工具和技術(shù)，這是自微服務(wù)出現(xiàn)以來不斷看到最大變化的領(lǐng)域。因此，微服務(wù)開發(fā)人員應(yīng)該在工具和平臺(tái)方面尋找新的方向。但總是質(zhì)疑每一個(gè)新選擇的好處和挑戰(zhàn)。（這里可參考Thoughtworks技術(shù)雷達(dá)和軟件架構(gòu)與設(shè)計(jì)趨勢報(bào)告）

以下是開發(fā)人員在任何基于微服務(wù)的解決方案中為提高可部署性而應(yīng)該考慮的策略和技術(shù)列表：

• 容器化和容器編排：容器化的微服務(wù)更容易實(shí)現(xiàn)跨平臺(tái)和云提供商進(jìn)行復(fù)制和部署，而編排平臺(tái)為路由、擴(kuò)展、復(fù)制、負(fù)載均衡等提供了共享資源和機(jī)制。Docker和Kubernetes是當(dāng)今容器和容器編排的事實(shí)標(biāo)準(zhǔn)。
• 服務(wù)網(wǎng)格：這種工具可以用于流量監(jiān)控，策略執(zhí)行，身份驗(yàn)證，RBAC，路由，斷路器、消息轉(zhuǎn)換等，以幫助容器編排平臺(tái)中的服務(wù)進(jìn)行通信。流行的服務(wù)網(wǎng)格包括Istio、Linkerd和Consul Connect。
• API網(wǎng)關(guān)：通過攔截對微服務(wù)的調(diào)用，API網(wǎng)關(guān)產(chǎn)品提供了豐富的功能集，包括消息轉(zhuǎn)換和協(xié)議橋接、流量監(jiān)控、安全控制、路由、緩存、請求限制和API配額以及熔斷。這一領(lǐng)域的主要參與者是Ambassador、Kong、Apiman、WSO2 API Manager、Apigee和Amazon API Gateway。
• 無服務(wù)器架構(gòu)：通過將服務(wù)部署到遵循FaaS范式的無服務(wù)器平臺(tái)，可以避免容器編排的復(fù)雜性和操作成本。AWS Lambda、Azure函數(shù)和Google云函數(shù)都是無服務(wù)器平臺(tái)的示例.
• 日志整合工具：微服務(wù)可以輕松的將部署單元的數(shù)量增加一個(gè)數(shù)量級(jí)。我們需要工具來整合這些組件的日志輸出，以及搜索、分析和生成告警的能力。這個(gè)領(lǐng)域流行的工具有Fluentd、Graylog、Splunk和ELK（Elasticsearch、Logstash、Kibana）。
• 鏈路跟蹤工具：這些工具可用于檢測您的微服務(wù)，然后生成、收集和可視化運(yùn)行時(shí)跟蹤數(shù)據(jù)，以顯示跨服務(wù)的調(diào)用。它可以幫助您發(fā)現(xiàn)性能問題。跟蹤工具的例子有Zipkin, Jaeger, and AWS X-Ray，OpenTraceing。
• DevOps：當(dāng)開發(fā)人員和運(yùn)維人員可以進(jìn)行更緊密的溝通和協(xié)作時(shí)，微服務(wù)的工作會(huì)更加容易，從基礎(chǔ)設(shè)施配置到事件處理。
• 藍(lán)綠部署和金絲雀發(fā)布：這些部署策略允許在發(fā)布新版本的微服務(wù)時(shí)實(shí)現(xiàn)零或接近零的停機(jī)時(shí)間，并在出現(xiàn)問題時(shí)進(jìn)行快速切換。
• 基礎(chǔ)設(shè)施即代碼：這種做法使得構(gòu)建-部署周期中的交互更少，從而變得更快，更不容易出錯(cuò)，更易于審計(jì)。
• 持續(xù)交付：這是縮短從提交到部署間隔并保持代碼質(zhì)量的必要實(shí)踐。傳統(tǒng)的CICD工具有Jenkins、Gitlab CI/CD、Bamboo、GoCD、CircleCI和Spinnaker。最近，Weaveworks和Flux等GitOps工具被添加到這個(gè)領(lǐng)域，將CD和IaC結(jié)合起來。
• 配置管理：將配置屬性存儲(chǔ)在微服務(wù)部署單元之外，并且易于管理。

四、事件驅(qū)動(dòng)

微服務(wù)架構(gòu)風(fēng)格用于創(chuàng)建后端服務(wù)，這些服務(wù)通常使用以下三種類型的方式進(jìn)行調(diào)用：

• HTTP調(diào)用（REST服務(wù)）
• 使用特定于平臺(tái)的組件技術(shù)進(jìn)行類RPC調(diào)用，如gRPC或GraphQL
• 通過消息中間件處理異步消息

前兩個(gè)通常是同步的，HTTP調(diào)用也是最常見的方式。通常，服務(wù)需要調(diào)用其他服務(wù)進(jìn)行組合，太多時(shí)候，組合中的服務(wù)調(diào)用是同步的。如果異步，需要連接和接收Queue/Topic里的消息，那么我們將創(chuàng)建一個(gè)事件驅(qū)動(dòng)的體系結(jié)構(gòu)。（我們可以討論消息驅(qū)動(dòng)和事件驅(qū)動(dòng)的區(qū)別，但都可以表示網(wǎng)絡(luò)上的異步通信，使用消息中間件產(chǎn)品（Apache Kafka、RabbitMQ和Amazon SNS）提供的Queue和Topic）

事件驅(qū)動(dòng)體系結(jié)構(gòu)的一個(gè)重要好處是提高了可伸縮性和吞吐量。這是因?yàn)椋合l(fā)送者在等待響應(yīng)時(shí)不會(huì)被阻塞，并且同一個(gè)消息/事件可以由多個(gè)接收者以發(fā)布-訂閱的方式并行使用。

事件驅(qū)動(dòng)的微服務(wù)

IDEALS中的E就表示使用事件驅(qū)動(dòng)對微服務(wù)進(jìn)行建模。因?yàn)樗麄兏軡M足當(dāng)今軟件解決方案的可伸縮性和性能要求，這種設(shè)計(jì)還促進(jìn)了松耦合，因?yàn)橄l(fā)送方和接收方——微服務(wù)——是對立的，彼此不了解。可靠性也得到了提升，因?yàn)檫@個(gè)設(shè)計(jì)可以處理微服務(wù)的臨時(shí)中斷，當(dāng)微服務(wù)恢復(fù)后可以處理排隊(duì)中的消息。

但事件驅(qū)動(dòng)的微服務(wù)，也稱為反應(yīng)式微服務(wù)，也會(huì)帶來挑戰(zhàn)，比如異步處理和并行執(zhí)行，可能需要同步點(diǎn)和相關(guān)標(biāo)識(shí)符。設(shè)計(jì)需要考慮錯(cuò)誤和丟失的消息——校正事件和撤銷數(shù)據(jù)更改的機(jī)制（如Saga模式）通常是必須的。對于事件驅(qū)動(dòng)體系結(jié)構(gòu)帶來的面向用戶的事務(wù)，應(yīng)仔細(xì)考慮用戶體驗(yàn)，以使最終用戶了解進(jìn)度和事故。

五、可用性勝于一致性

CAP理論本質(zhì)上給了我們兩個(gè)選擇：可用性或者一致性。我們看到業(yè)界為了讓我們選擇可用性而付出了巨大努力，從而最終實(shí)現(xiàn)一致性。原因很簡單：今天的最終用戶不會(huì)容忍服務(wù)不可用。假如一個(gè)網(wǎng)絡(luò)商店，如果我們在瀏覽產(chǎn)品時(shí)顯示的庫存量和購買時(shí)更新的實(shí)際庫存量之間強(qiáng)制執(zhí)行強(qiáng)一致，那么數(shù)據(jù)變更將會(huì)帶來巨大的開銷，如何任何更新庫存的服務(wù)暫時(shí)無法訪問，那么頁面無法顯示庫存信息，結(jié)賬將停止服務(wù)。相反，如果選擇可用性，用戶瀏覽產(chǎn)品時(shí)顯示的庫存量和購買時(shí)更新的實(shí)際庫存量之間會(huì)有偶爾的不一致。當(dāng)用戶在下單買時(shí)，然后再去查詢真實(shí)的庫存量，如果沒有庫存，再提示用戶沒有庫存。從用戶的角度來看，這個(gè)場景比由于系統(tǒng)要實(shí)現(xiàn)強(qiáng)一致而讓整個(gè)系統(tǒng)不可用或超級(jí)慢對所有用戶來說要好很多。

有些業(yè)務(wù)操作確實(shí)需要很強(qiáng)的一致性。然而，正如Pat Helland指出，當(dāng)你面對你是想要正確?還是想要現(xiàn)在?的問題時(shí)，人們通常想要的是現(xiàn)在而不是正確的答案時(shí)，就需要考慮強(qiáng)一致。

最終一致性的可用性

對于微服務(wù)來說，保證可用性選擇的主要策略是數(shù)據(jù)復(fù)制?？梢圆捎貌煌脑O(shè)計(jì)模式，有時(shí)可以組合使用。

• 服務(wù)數(shù)據(jù)復(fù)制模式：當(dāng)微服務(wù)需要訪問屬于其他應(yīng)用程序的數(shù)據(jù)（而API調(diào)用不適合獲取數(shù)據(jù)）時(shí)，使用此基本模式。我們創(chuàng)建該數(shù)據(jù)的副本，并使其隨時(shí)可供微服務(wù)使用。該解決方案還需要一種數(shù)據(jù)同步機(jī)制（如ETL工具/程序、發(fā)布-訂閱消息傳遞、物化視圖），該機(jī)制將定期或基于觸發(fā)器使副本與主數(shù)據(jù)庫保持一致。
• 命令查詢責(zé)任分離（CQRS）模式：這里我們將更改數(shù)據(jù)（Command）的操作設(shè)計(jì)與實(shí)現(xiàn)和只讀數(shù)據(jù)（Query）的操作分開。CQRS通常建立在服務(wù)數(shù)據(jù)復(fù)制的基礎(chǔ)上，用于提高查詢的效率。
• 事件源（Event Source）模式：我們不在數(shù)據(jù)庫中存儲(chǔ)對象的當(dāng)前狀態(tài)，而是存儲(chǔ)影響該對象的僅附加的、不可變的事件序列。當(dāng)前狀態(tài)是通過回放事件獲得，這樣做是為了提供數(shù)據(jù)的“查詢視圖”。因此，事件源通常建立在CQRS設(shè)計(jì)的基礎(chǔ)上。

我們經(jīng)常使用的CQRS模式通常如下圖所示：一個(gè)可以更改數(shù)據(jù)的HTTP請求由后臺(tái)一個(gè)REST服務(wù)處理，該服務(wù)可以操作一個(gè)集中式的Oracle數(shù)據(jù)庫。其他只讀的HTTP請求轉(zhuǎn)到另一個(gè)后臺(tái)服務(wù)，該服務(wù)可以從基于文本的Elasticsearch數(shù)據(jù)存儲(chǔ)中獲取數(shù)據(jù)。一個(gè)Spring Batch Kubernetes cron任務(wù)定期將在Oracle數(shù)據(jù)庫中的變更同步到ES中，這個(gè)設(shè)計(jì)使用兩個(gè)數(shù)據(jù)存儲(chǔ)之間的最終一致性。即使Oracle DB和cron任務(wù)不起作用，查詢服務(wù)也是可用的。

六、松耦合

在軟件工程中，耦合是指兩個(gè)軟件元素之間相互依賴的程度。對于基于服務(wù)的系統(tǒng)來說，傳入耦合是指服務(wù)用戶如何與服務(wù)交互。我們知道這種交互應(yīng)該通過服務(wù)契約來實(shí)現(xiàn)，并且該服務(wù)契約不應(yīng)該與實(shí)現(xiàn)細(xì)節(jié)和特定技術(shù)緊密結(jié)合。服務(wù)是可以由不同程序調(diào)用的分布式組件。有時(shí)候，服務(wù)提供方不知道所有服務(wù)用戶在哪里（公共API服務(wù)通常就是這樣）。因此，服務(wù)契約應(yīng)該避免變更。如何服務(wù)契約與服務(wù)邏輯或技術(shù)緊密耦合，那么當(dāng)邏輯或技術(shù)需要演化時(shí)，它也需要同時(shí)發(fā)生變化。

服務(wù)通常需要與其他服務(wù)或其他類型的組件交互，從而產(chǎn)生傳出耦合。這種交互建立了直接影響服務(wù)自治的運(yùn)行時(shí)依賴關(guān)系。如果一個(gè)服務(wù)的自治性較低，它的行為就不那么可預(yù)測：最好的情況就是，該服務(wù)將與他需要調(diào)用的最慢的，最不可靠的和最不可用的組件一樣快速、可靠和可用。

微服務(wù)的松耦合策略

IDEALS中的L表示要關(guān)注服務(wù)及微服務(wù)的耦合?？梢允褂貌⒔M合多種策略來改進(jìn)傳入和傳出的松散耦合。這些策略包括：

• 點(diǎn)對點(diǎn)和發(fā)布-訂閱（Point-to-point and Publish-subscribe）：這種通過消息傳遞的模式改進(jìn)了耦合性，因?yàn)榘l(fā)送方和接收方彼此不知道對方。響應(yīng)式微服務(wù)（如Kafka消費(fèi)方）的契約將成為消息隊(duì)列的名稱和消息的結(jié)構(gòu)體。
• API網(wǎng)關(guān)和BFF：這些解決方案規(guī)定了一個(gè)中間組件，該組件處理服務(wù)契約與客戶端需要的消息格式和協(xié)議之間的差異，從而有助于分離他們。
• 契約優(yōu)先設(shè)計(jì)（Contract-first design）：通過設(shè)計(jì)與任何現(xiàn)有代碼相關(guān)的契約，從而避免創(chuàng)建與技術(shù)和實(shí)現(xiàn)緊密耦合的api。
• 超媒體（Hypermedia）：對于REST服務(wù)，超媒體幫助前端更加獨(dú)立于服務(wù)端點(diǎn)。
• Facade和Adapter/Wrapper模式：這些GoF模式的變體在微服務(wù)架構(gòu)中可以規(guī)定內(nèi)部的組件和服務(wù)，可以防止在微服務(wù)實(shí)現(xiàn)中傳播不良的耦合性。
• 每個(gè)微服務(wù)一個(gè)數(shù)據(jù)庫模式：該模式使得微服務(wù)不僅獲得了自治性，而且避免了與數(shù)據(jù)庫共享帶來的直接耦合。

七、單一職責(zé)

最初的單一職責(zé)原則（ Single Responsibility Principle，SRP）是關(guān)于在OO類中具有內(nèi)聚功能。在一個(gè)類中擁有多個(gè)職責(zé)自然會(huì)導(dǎo)致緊耦合，并導(dǎo)致脆弱的設(shè)計(jì)，在變更時(shí)會(huì)發(fā)生意想不到的結(jié)果。SRP這個(gè)想法很簡單，也很容易理解，但要用好并不容易。

單一職責(zé)的概念可以擴(kuò)展到微服務(wù)中服務(wù)的內(nèi)聚性。微服務(wù)體系結(jié)構(gòu)風(fēng)格部署單元應(yīng)該包含一個(gè)服務(wù)或幾個(gè)內(nèi)聚服務(wù)。如果一個(gè)微服務(wù)包含太多的職責(zé)，也就是說，有太多不太具有內(nèi)聚力的服務(wù)，那么它就可能會(huì)承受一個(gè)巨大的痛苦。膨脹的微服務(wù)在功能和技術(shù)棧方面變得更難發(fā)展。而且，持續(xù)交付將會(huì)變得繁重，因?yàn)樗麄儗?huì)使許多開發(fā)人員在同一個(gè)部署單元開發(fā)不同的內(nèi)容。

另一方面，如果微服務(wù)過于細(xì)粒度，則其中的幾個(gè)服務(wù)可能需要交互來滿足用戶請求。在最壞的情況下，數(shù)據(jù)變更可能會(huì)跨多個(gè)微服務(wù)，可能會(huì)產(chǎn)生分布式事務(wù)的場景。

粒度適中的微服務(wù)

微服務(wù)設(shè)計(jì)成熟度的一個(gè)重要方面是創(chuàng)建粒度適中的微服務(wù)的能力。這里的解決方案不是任何工具或技術(shù)中，而是在適當(dāng)?shù)念I(lǐng)域建模上。為后端服務(wù)建模并為其定義微服務(wù)邊界可以通過多種方式完成。業(yè)界流行的一種驅(qū)動(dòng)微服務(wù)范圍的方法是遵循領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（Domain-Driven Design，DDD）原則。簡而言之：

一個(gè)服務(wù)（例如：REST服務(wù)）可以具體DDD聚合的作用域。一個(gè)微服務(wù)的作用域可以是DDD限定的上下文。該微服務(wù)中的服務(wù)將對應(yīng)于該限定上下文的聚合。

對于微服務(wù)間的通信，我們可以使用：當(dāng)異步消息滿足需求時(shí)使用領(lǐng)域事件（Domain Event）；當(dāng)請求-響應(yīng)更適合時(shí)，使用某種形式的中間層進(jìn)行API調(diào)用；當(dāng)一個(gè)微服務(wù)需要另一個(gè)可用區(qū)的大量數(shù)據(jù)時(shí)，可以使用數(shù)據(jù)復(fù)制保證最終一致性。

八、結(jié)論

IDEALS是在大多數(shù)典型的微服務(wù)設(shè)計(jì)中要遵循的核心設(shè)計(jì)原則。然而，遵循IDEALS并不是使我們的微服務(wù)設(shè)計(jì)成功的良藥。通常，我們還需要對質(zhì)量需求有一個(gè)很好的理解，并使設(shè)計(jì)決策意識(shí)到他們的權(quán)衡。此外，我們還應(yīng)該學(xué)習(xí)可以用來幫助實(shí)現(xiàn)設(shè)計(jì)原則的設(shè)計(jì)模式和架構(gòu)策略。還應(yīng)該掌握可用的技術(shù)選型。

多年來，我一直使用IDEALS設(shè)計(jì)、實(shí)現(xiàn)和部署微服務(wù)，在設(shè)計(jì)研討會(huì)和講座中，我與來自不同組織的數(shù)百名軟件開發(fā)人員討論這些核心原則以及每一個(gè)原則背后的許多策略。有時(shí)候，會(huì)讓人覺得微服務(wù)的工具、框架、平臺(tái)和模式層出不窮，我相信，對微服務(wù)IDEALS更好的理解，能夠幫助我們更清晰的了解技術(shù)領(lǐng)域。

翻譯自：

https://www./articles/microservices-design-ideals/?itm_source=infoq&itm_campaign=user_page&itm_medium=link