背景

你正在開發(fā)一個(gè)服務(wù)端的企業(yè)應(yīng)用程序。它必須支持不同的客戶端，包括桌面瀏覽器，移動(dòng)端瀏覽器和原生手機(jī)應(yīng)用。它需要暴露一個(gè)API接口給第三方消費(fèi)。它需要通過web service或者消息機(jī)制與其他應(yīng)用程序集成。它接受請求（HTTP請求和消息）；執(zhí)行業(yè)務(wù)邏輯；訪問數(shù)據(jù)庫；與其他系統(tǒng)交換數(shù)據(jù)；返回HTML/JSON/XML響應(yīng)。這個(gè)應(yīng)用中，不同的功能區(qū)域都對應(yīng)著不同的邏輯組件。

問題

該應(yīng)用的部署架構(gòu)？

限制

一個(gè)團(tuán)隊(duì)的開發(fā)人員正在開發(fā)這個(gè)應(yīng)用
新的團(tuán)隊(duì)成員應(yīng)該迅速上手
該應(yīng)用應(yīng)該容易理解和修改
你想嘗試持續(xù)部署
你必須在不同機(jī)器上運(yùn)行該應(yīng)用的拷貝，以滿足可擴(kuò)展性和可用性的需求
你想嘗試新的技術(shù)（框架，編程語言等）

解決方案

定義一種架構(gòu)，將應(yīng)用程序組織為松散寫作的服務(wù)。這個(gè)方法對應(yīng)于Scale Cube的Y軸。每個(gè)服務(wù)都定義了一組狹隘的相關(guān)功能。例如，應(yīng)用程序可以包含訂單管理服務(wù)，客戶管理服務(wù)等等。
服務(wù)之間使用同步協(xié)議，例如HTTP/REST或者異步協(xié)議，例如AMQP交互。服務(wù)之間可以獨(dú)立的開發(fā)和部署。每個(gè)服務(wù)擁有它自己的數(shù)據(jù)庫，與其他服務(wù)解耦。服務(wù)之間的數(shù)據(jù)一致是通過Saga pattern管理。

示例

虛擬的電商應(yīng)用

設(shè)想一下，你正在構(gòu)建一個(gè)商城應(yīng)用程序，為客戶生成訂單，驗(yàn)證庫存和可用積分，快遞商品。這個(gè)應(yīng)用程序由以下幾個(gè)組件構(gòu)成：商城前端UI，它包括了用戶界面；后端服務(wù)，包括檢查積分，管理庫存和運(yùn)送商品。該應(yīng)用程序包含一組服務(wù)。

微服務(wù)架構(gòu)應(yīng)用程序

展示代碼

請?jiān)L問 example applications developed by Chris Richardson。這些示例在github.com上，展示了微服務(wù)架構(gòu)的各個(gè)方面。

結(jié)果

優(yōu)勢

該解決方案有以下優(yōu)勢：

• 允許持續(xù)交付和部署大型，復(fù)雜的應(yīng)用程序
  • 更好的可測試性 - 服務(wù)測試更小，更快
  • 更好的部署能力 - 服務(wù)可以獨(dú)立的部署
  • 允許你圍繞多個(gè)自動(dòng)化團(tuán)隊(duì)組織開發(fā)工作。允許你圍繞多個(gè)部門組織開發(fā)工作。每個(gè)部門負(fù)責(zé)一個(gè)或多個(gè)單獨(dú)的服務(wù)。每個(gè)部門都可以獨(dú)立開發(fā)，部署和擴(kuò)展他們的服務(wù)。
• 每個(gè)微服務(wù)相對較小
  • 很容易讓每個(gè)開發(fā)人員理解
  • IDE啟動(dòng)更快，讓開發(fā)人員更有效率
  • 應(yīng)用啟動(dòng)更快，這讓開發(fā)人員更有效率，而且加快開發(fā)速度
• 提高了錯(cuò)誤隔離。例如，如果一個(gè)服務(wù)出現(xiàn)內(nèi)存泄漏，僅有這個(gè)服務(wù)會(huì)受到影響。其他服務(wù)將繼續(xù)處理請求。作為比較，單體架構(gòu)中一個(gè)組件出現(xiàn)異常，將拖垮整個(gè)系統(tǒng)。
• 消除對一個(gè)技術(shù)棧的長期依賴。當(dāng)開發(fā)一個(gè)新服務(wù)時(shí)，你可以選擇新技術(shù)棧。同樣，當(dāng)對現(xiàn)有服務(wù)做出重大修改時(shí)，也可以用一個(gè)新技術(shù)棧來重寫它。

弊端

該解決方案有以下弊端：

• 開發(fā)人員必須處理額外帶來的分布式系統(tǒng)的復(fù)雜性。
  • 開發(fā)工具/IDE面向的是構(gòu)建單體應(yīng)用，不為開發(fā)分布式應(yīng)用程序提供明確支持
  • 測試變得更復(fù)雜
  • 開發(fā)人員必須實(shí)現(xiàn)服務(wù)內(nèi)部的通信機(jī)制
  • 實(shí)現(xiàn)跨多個(gè)服務(wù)的用例而不使用分布式事務(wù)非常困難
  • 實(shí)現(xiàn)跨多個(gè)服務(wù)的用例需要部門之間的緊密合作
• 部署復(fù)雜性。在生產(chǎn)環(huán)境中，存在部署和管理包含多個(gè)不同服務(wù)類型的系統(tǒng)的操作復(fù)雜性。
• 內(nèi)存消耗增加。微服務(wù)架構(gòu)將N個(gè)單體應(yīng)用替換成了N×M個(gè)服務(wù)實(shí)例。如果每個(gè)服務(wù)都運(yùn)行在它獨(dú)有的JVM（或者類似的運(yùn)行時(shí)），這對隔離實(shí)例很游泳，這樣就存在M倍的開銷。還有，如果每個(gè)服務(wù)運(yùn)行在它
  獨(dú)有的虛擬機(jī)（或者EC2實(shí)例），比如Netflix那樣，開銷會(huì)更高。

問題

你必須解決很多問題。

什么時(shí)候該采用微服務(wù)架構(gòu)？

采用這個(gè)方法的一個(gè)挑戰(zhàn)是決定什么時(shí)候使用它。當(dāng)開發(fā)一個(gè)應(yīng)用的第一個(gè)版本，你通常不會(huì)遇到必須采用這個(gè)架構(gòu)才能解決的難題。此外，采用精心設(shè)計(jì)的分布式架構(gòu)會(huì)減慢開發(fā)速度。這對初創(chuàng)公司是個(gè)主要問題，因?yàn)樗麄冏畲蟮奶魬?zhàn)通常是迅速解決業(yè)務(wù)模型和對應(yīng)的應(yīng)用程序。使用Y軸拆分，會(huì)使迅速迭代變得更困難。然而，一段時(shí)間后，當(dāng)挑戰(zhàn)變成如何擴(kuò)展，并且你需要使用功能分解時(shí)，這些糾纏的依賴可能使你難以將單體應(yīng)用分解成一組服務(wù)。

如何將應(yīng)用分解成服務(wù)？

另外一個(gè)挑戰(zhàn)是決定該如何將系統(tǒng)拆分到微服務(wù)。這更是一門藝術(shù)，但是有一些策略可以幫上忙：

• 按業(yè)務(wù)能力拆分，定義與業(yè)務(wù)能力相對應(yīng)的服務(wù)。
• 按領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的子域拆分.
• 按謂詞和用例拆分，定義與特定行為對應(yīng)的服務(wù)。例如，一個(gè)“Shipping Service”對應(yīng)運(yùn)送訂單。
• 按名詞和資源拆分，定義與一個(gè)指定類型的entities/resources的所有操作相對應(yīng)的服務(wù)。例如，一個(gè)“Account Service”對應(yīng)管理用戶賬號。

理想角度，每個(gè)服務(wù)應(yīng)該只擁有一小部分能力。Bob Martin討論了采用單一職責(zé)原理（SRP）來設(shè)計(jì)類。SRP將一個(gè)類的職責(zé)定義為改變的理由，并且一個(gè)類只能有一個(gè)理由發(fā)生改變。將SRP應(yīng)用到服務(wù)設(shè)計(jì)很有意義。
另一個(gè)幫助服務(wù)設(shè)計(jì)的類比是Unix工具設(shè)計(jì)理念。Unix提供了眾多的工具，比如grep，cat和find。每個(gè)工具只明確做一件事，通常非常好，而且可以通過一個(gè)shell腳本和其他工具合并，提供復(fù)雜的任務(wù)。

如何保持?jǐn)?shù)據(jù)一致性？

為了確保松耦合，每個(gè)服務(wù)都有它肚子的數(shù)據(jù)庫。由于2階段提交/分布式事務(wù)在多數(shù)應(yīng)用中并不是一個(gè)選擇 ，在不同服務(wù)之間保持?jǐn)?shù)據(jù)一致是個(gè)很大的挑戰(zhàn)。應(yīng)用程序必須改為采用Saga模式。服務(wù)在數(shù)據(jù)發(fā)生更改時(shí)發(fā)布事件。其他服務(wù)訂閱事件并更新它們的數(shù)據(jù)。有很多種方式可以可靠的更新數(shù)據(jù)和發(fā)布事件，包括Event Sourcing和Transaction Log Tailing。

如何實(shí)現(xiàn)查詢

另外一個(gè)挑戰(zhàn)是查詢多個(gè)服務(wù)擁有的數(shù)據(jù)

• API Composition 和 Command Query Responsibility Segregation (CQRS) 模式。

相關(guān)的模式

有很多和微服務(wù)相關(guān)的模式。單體架構(gòu)是微服務(wù)之外的另一選擇。其他模式解決了你將在微服務(wù)架構(gòu)中遇到的問題。

微服務(wù)相關(guān)的模式

• 分解模式：
  • 根據(jù)業(yè)務(wù)能力分解
  • 根據(jù)子域分解
• 每服務(wù)每數(shù)據(jù)庫模式介紹了一個(gè)服務(wù)怎樣擁有其獨(dú)有的數(shù)據(jù)庫以實(shí)現(xiàn)松散耦合
• 網(wǎng)關(guān)模式定義了客戶端怎樣訪問微服務(wù)架構(gòu)中的服務(wù)
• 消息模式和遠(yuǎn)程調(diào)用模式是服務(wù)間通信的兩種不同方法
• 每主機(jī)單服務(wù)和每主機(jī)多服務(wù)模式是兩種不同的部署策略
• 橫切關(guān)注模式和外部化的配置
• 測試模式：服務(wù)組件測試和服務(wù)集成測試
• 斷路器
• Access Token
• 可觀測的模式：
  • 日志聚合
  • 審計(jì)日志
  • 分布式追蹤
  • 異常追蹤
  • 健康檢查API
  • 記錄部署和變更
• UI模式
  • 服務(wù)端頁面片段合成
  • 客戶端UI合成

已知案例

大多數(shù)大型網(wǎng)站，包括 Netflix，Amazon和eBay都從單體架構(gòu)進(jìn)化到了微服務(wù)架構(gòu)。

Netflix，知名的視頻流服務(wù)，承擔(dān)了30%的互聯(lián)網(wǎng)訪問流量，采用了大規(guī)模的，面向服務(wù)的架構(gòu)。他們每天處理來自800個(gè)不同設(shè)備類型，針對視頻流API的上十億次調(diào)用。每個(gè)API調(diào)用平均分散出對后臺(tái)服務(wù)的六次調(diào)用。

Amazon.com最開始采用兩層架構(gòu)。為了擴(kuò)展，他們遷移為存在幾百個(gè)后端服務(wù)的面向服務(wù)架構(gòu)。一部分應(yīng)用程序調(diào)用這些服務(wù)，包括Amazon.com網(wǎng)站和web服務(wù)API。Amazon.com網(wǎng)站訪問100-150個(gè)服務(wù)，獲取數(shù)據(jù)構(gòu)建網(wǎng)頁。

拍賣網(wǎng)站ebay.com也從單體架構(gòu)進(jìn)化到了面向服務(wù)架構(gòu)。應(yīng)用層有很多獨(dú)立的應(yīng)用程序。每個(gè)應(yīng)用程序?qū)崿F(xiàn)了特定功能領(lǐng)域的業(yè)務(wù)邏輯，比如購買和銷售。每個(gè)應(yīng)用程序采用X-軸切割；一部分應(yīng)用，比如搜索，采用Y-軸切割。Ebay.com針對數(shù)據(jù)庫層提供了X-，Y-，Z-風(fēng)格的合并。

還有許多其他公司使用微服務(wù)架構(gòu)的案例