基於服務架構的世界

微服務和SOA都被認為是基於服務的架構，這意味著這兩種架構模式都非常強調將“服務”作為其架構中的首要元件，用於實現各種功能（包括業務層面和非業務層面）。微服務和SOA是兩種差異很大的架構模式，但是他們仍有一些相同的特徵。

所有基於服務的架構的一個共性是他們一般都是分散式架構，也就是服務元件都是通過遠端訪問協議來實現的，例如REST、SOAP、AMQP、JMS、MSMQ、RMI或者.NET Remoting。相對於單體式架構和分層式架構，分散式架構有很多優勢，包括可伸縮性、解耦能力以及對開發、測試和部署的可控性等。分散式架構中的元件更趨向於自包含，因此其變更管理和維護也更容易，從而使得相應的應用也更穩定，響應也更快。分散式架構也非常適用於各模組之間耦合度較低、更加模組化的應用。

在基於服務的架構語境中，“模組化”指的是將應用的各個部分分別封裝為自包含的服務的做法。拆分後的每個服務都可以單獨設計、開發、測試和部署，與其他元件或服務之間的依賴性很低甚至沒有。模組化的架構還支援用重寫的方式來維護元件的做法。隨著業務增長，架構可以逐漸地、以很小的部件為單位進行重構或者替換，而不是大張旗鼓地對整個應用進行重構或者替換。

不幸的是，凡事都有代價，享受分散式系統的優點也一樣。與優點相伴的缺點則是複雜性的增加和投入的增長。維護服務合約、選擇正確的遠端訪問協議、處理不響應的或不可用的服務、加密遠端服務和管理分散式事務，這些還只是構造基於服務的架構時許多複雜問題中的一部分。本章中，我會描述這些與基於服務的架構有關的複雜問題。

服務合約

服務合約是服務提供者（通常是遠端的）和使用者（客戶）之間使用合約語言（XML、JSON、Java Object等）約定資料輸入和資料輸出的一份協議。建立和維護服務合約是一項困難的工作，不應該被輕視或者當作補充條款。因此，服務合約的議題在基於服務的架構設計中值得特殊關注。

在基於服務的架構中，存在兩種服務合約模型可供使用：基於服務的合約和客戶驅動的合約。兩者之間的真正差別在於合作程度。在基於服務的合約中，服務是合約的唯一擁有者，一般可以在不考慮服務客戶需求情況下演化或修改合約。這種模式強迫服務的所有客戶都要接受新的服務合約變更，而不管客戶是否需要這些新功能。

與之相反，客戶驅動的合約所基於的是服務和與服務客戶之間更為密切地合作的一種關係。在這種模型下，服務擁有者和客戶有很強的合作（關係），因此任何服務合約變更會充分考慮客戶的需求。採用這種模型時，服務（擁有者）一般需要了解客戶是誰以及每個客戶都是如何使用這些服務的。客戶可以對服務合約隨意提出變更建議，服務方則可以根據是否影響其他客戶而自行決定是否採納。理想情況下，服務的客戶向服務擁有者發起修改建議和測試用例，測試被執行時可以監測該修改是否影響其他客戶。開源工具如Pact和Pacto可以幫助維護和測試這類客戶驅動的合約。

服務合約的上下文中另一個重要議題是合約的版本。我們必須接受這一現實——在服務和服務客戶間實現繫結的合約終究是要變化的。改變程度和範圍取決於這些變更如何影響每個客戶，以及合約改變後服務的向後相容性。

合約的版本化使得啟用新的、包含合約變更的服務功能時能夠為仍舊使用老版本合約的客戶提供向後相容性。從開始開發之前就要為合約的版本化做出規劃，即使開始你覺得不需要，到了最後一定需要，這也許是本章最重要的一條建議。有很多開源和商業版本的框架可以用來幫助管理和實施合約版本化策略，不過你也可以選擇使用兩項基本技術來實現自己的合約版本化策略：同質版本化和異質版本化。

同質版本化是指在同一個服務合約中使用合約版本號。圖1-1中，被客戶A和B同時使用的合約都用圓形（代表同一服務合約）來表現，但是其中各自包含著不同版本號。舉一個簡單例子，假定合約是基於XML的，用來表示某些商品的訂單，採用合約版本號1.0。現在新版本1.1釋出了，其中包含了額外欄位用於提供當訂單派送而接收人不在家的時候的交貨規則。這種情況下，可以通過讓新的delivery-instructions欄位成為可選欄位來保持向後相容版本1.0的合約。

圖1-1

異質版本化則涉及對不同型別合約的支援。這個技術跟本節之前描述的客戶驅動的合約很相似。服務引入新的功能特性時，就引入新合約用來支援這一（些）功能特性。注意，圖1-1與1-2之間不同在於表示服務合約的形狀。1-2中，客戶A使用圓圈所代表的合約，而客戶B則使用三角形所代表的合約。在這種情況下，向後相容性是由不同合約而不是同一合約的不同版本所支援的。許多基於JMS的訊息系統都是採用這種方式，尤其是使用ObjectMessage訊息型別的系統。例如，基於Java的接收端可以使用instanceof關鍵字來檢查通過訊息傳送的物件型別，然後根據物件型別來採取響應的步驟。或者，XML負載可以通過JMS的 TextMessage來發送（每個不同合約包含完全不同的XML schema），由一個訊息屬性來指明XML schema和XML型別負載之間的對應關係。

圖1-2

合約版本化的主要目的就是提供向後相容性。謹記，服務必須支援多個版本的合約（或者多個合約），這樣才能使得開發團隊能夠更快地部署新的功能特性或者其它變更，而不必擔心破壞與其它服務客戶之間的現有合約。需要注意的是，這兩種技術也可以組合起來，支援不同合約型別的多個版本。

最後一個關於服務合約中變更合約需要注意的是：一定要從開始就制定一個明確的服務客戶溝通策略，以便客戶能夠及時獲知合約變更的資訊，或者特定合約型別不再被支援的資訊。很多情況下，因為內部/外部客戶很多，這類溝通並不可行。這時候，一個整合中心（integration hub），或者說訊息中介軟體，可以在服務的客戶與服務之間建立抽象層，實行服務合約的轉譯。我將在後續“合約解耦”一節種談到這種可能性。

服務可用性

服務可用性（Availability）和服務響應能力（Responsiveness）是基於服務的架構通常需要考慮的另外兩個問題。這兩者都涉及服務客戶與遠端服務之間通訊的能力，但他們還是有著輕微不同的內涵，因此客戶也會採用不同方式來解決這兩個問題。

服務可用性是指遠端服務及時地接受請求的能力，例如，與此遠端服務建立連線。服務響應能力是指客戶及時地從服務接收響應的能力。圖1-3展示了這種不同。

圖1-3

儘管這兩種錯誤條件造成的結果是一樣的（服務請求無法被處理），但是處理方式是不同的。因為服務可用性跟服務的可連線性有關，因此客戶能夠做的並不多，只能要麼多試幾次，要麼在可能的情況下把請求放入佇列，以後再處理。

處理服務響應能力問題就更困難一些。請求成功地傳送給服務之後，客戶需要等待多久？是否服務僅僅是很慢，又或者服務端發生了什麼事情導致無法傳送響應？解決超時條件問題對於遠端服務的可連線性來說是相當具有挑戰性的。一種常見的做法是在有負載的情況下獲得最長響應時間作為基準，然後在此基礎上新增額外的時延以處理負載的波動。例如，假設執行某個基準測試時，某個特定服務請求的最大響應時間為2000毫秒。那麼你可能需要將這個值乘以二，用以處理負載較高的狀況，因此預期的超時時長應該是4000毫秒。

儘管看起來這是一個合理的估算服務響應超時時長的解決方案，但有時也會有各種問題。首先，如果服務真的停止了或者未啟動，每個請求都要等待四秒才能判定服務無響應。這實在是效率太低，而且會引起最終客戶的不滿意。另外一個問題在於，你所使用的基準測試可能並不精確，在高負載情況下，服務響應時間可能會是五秒而不是我們所算出來的四秒。這種情況下，服務端實際上能夠做出響應，但是客戶端會因為超時時長設得太低而拒絕了所有響應。

比較常見的一種解決方案是使用斷路器模式（circuit breaker pattern）。如果服務不能及時做出響應或者乾脆不響應，軟體斷路器將會起作用，提醒客戶不必浪費時間等待超時事件發生。與物理斷路器相比，軟體斷路器很不錯的一點是在實現這種設計模式時，可以在服務端開始傳送響應或者變得可用時對自己進行重置。軟體斷路器有不少開源實現，包括Netfix的Ribbon等。你可以在Michael Nygard的書Release It!中讀到更多的關於斷路器模式的內容。

在處理超時時長值的問題時，應該儘量避免使用全域性的超時值來處理每個請求。恰恰相反，建議你基於上下文來定義超時時長，同時確保這些數值可以從外部通過配置來設定，這樣你就可以在負載條件變化的情況下快速做出響應，而不用重建或者重新部署應用。另一種方案是在程式碼中使用“智慧超時值（smart timeout values）”，以便在負載變化情況下自行調整超時值。例如，應用可以在高負載或者網路有問題的情況下自動增加超時時長值。當負載降低，響應時間變短後，應用可以重新計算平均響應時間，並對應地降低超時時長值。

安全性

在基於服務架構下，服務都是遠端訪問的，很重要的一點是需要確認給定的客戶是否被授權訪問某個特定服務。根據實際情況，服務的客戶可能既需要被認證（authentication）也需要被授權（authorization）。認證是指服務客戶是否可以連線到某個服務，一般是通過使用者名稱和密碼來建立登入憑證來進行認證。某些情況下，僅僅執行認證還不夠：客戶可以連線到某個服務並不意味著他可以訪問服務所提供的所有功能。授權指的是某個服務客戶是否被允許訪問服務內部特定的業務功能項。

安全在早期SOA實現中是個大問題。原本被嚴格隔離的某個應用的功能突然被公開，從企業的全球各處都能訪問到。這一變化所引發的問題促使我們換個角度思考，重新認識服務以及如何保護服務不會被不該訪問的客戶訪問到。

對微服務而言，安全問題成為挑戰主要是因為沒有一個專門處理安全問題的中介軟體元件。相反地，每個服務必須各自處理安全性問題，或者在某些情況下需要增強API層以使之更加智慧地處理應用的安全性問題。我看到的微服務中所實現的一個比較好的設計是將認證工作委託給一個獨立的服務，而保留授權工作在微服務內部。儘管這一設計可以修改為將認證和授權都交由單獨的服務來完成，我還是傾向於將授權包含在微服務自身當中。這樣做可以避免與遠端安全性服務之間的太多的不必要互動，還可以使得服務的上下文邊界更加穩定，減少對外界的依賴。

事務

事務管理在基於服務的架構中也是很大的挑戰。大多數時候我們所討論的事務是指在大量業務應用中都存在的ACID（atomicity、consistency、isolation和durability）事務。ACID事務用於維持資料庫一致性，對同一個請求中的多個數據庫更新操作進行協調，使得當事務處理過程中發生問題時，該請求所作出的所有資料庫更新都可以回滾。

考慮到基於服務的架構一般都是分散式架構，在多個遠端服務之間傳播和維護事務的上下文很困難。如圖1-4所示，一個服務請求（紅色X旁邊的方框）可能需要呼叫多個遠端服務來完成請求。紅色X表明這種情況下無法實現ACID事務。

圖1-4

事務問題在SOA架構中更為普遍，因為與微服務架構不同，SOA架構中通常使用多個服務來完成一個業務請求。我將在對比架構特點一章的“服務編排”一節中詳細討論這個問題。

基於服務的架構一般更依賴於 BASE事務，而不是ACID事務。BASE事務一般包括基本的可用性、軟性的狀態和最終一致性（basic availability、soft state和eventual consistency）。分散式應用依賴BASE事務來追求資料庫中的最終一致性而不是每個中間事務的一致性。一個典型的BASE事務的例子是往ATM機裡存錢。當通過ATM機向你的賬戶中存入現金，大概幾分鐘甚至幾個小時後才會在賬號中顯現出來。換句話說，錢從離開自己的手到真正存入賬戶之間有一個軟性的轉換狀態：錢已經離手，但是還沒到達你的銀行賬戶中。我們可以容忍這一延遲，並且寄希望於軟狀態和最終一致性，因為我們知道並信任這筆錢最終一定會到達我們的賬號。從全系統檢視的角度看，批處理作業也是依賴最終一致性的。

遷移到到基於服務的架構需要我們改變對事務和一致性的認識。對於不能依賴最終一致性和軟狀態的而必需事務一致性的情況，可以將服務的粒度設計得較粗，從而把業務邏輯包裝在一個服務內，最後通過ACID事務來實現事務級別的一致性。另一種方法是使用事件驅動技術，當請求狀態變得一致時向相關客戶推送通知。這種技術給應用帶來了很高的複雜度，不過確實能夠在使用BASE事務時實現事務狀態管理。

太複雜了？

基於服務的架構相對於單體式應用來說是一種巨大的進步，但是正如你所看到的，他們同時也帶來很多問題，例如服務合約、可用性、安全性以及事務管理等等。不幸的是，轉向基於服務的架構，如微服務或者SOA，意味著必須在某些方面做出權衡。有鑑於此，除非做好準備並且原意去解決分散式系統所面對的種種問題，否則不要匆忙轉向基於服務的架構。

本節討論的問題很複雜，但它們肯定不是不可克服的障礙。大多數使用基於服務的架構的團隊最終都能順利通過開源、商用和定製化的方案解決和克服這些問題。

基於服務的架構是不是太複雜了？肯定是的。但是，事物總是兩面的。伴隨著複雜性，基於服務的架構也有一些額外的特性和能力，能夠提高開發團隊的效率，開發出更為可靠的、更為穩定的應用，同時降低總體開銷並縮短產品進入市場的週期。接下來的三節中，我會對比微服務和SOA，幫助你瞭解哪種架構模式更適合自己。

對比服務特性

OASIS面向服務架構參考模型（OASIS Reference Model for Service Oriented Architecture）中將“服務”定義為“一種支援對一或多種能力進行訪問的機制，這裡的訪問是通過使用預定義的介面來提供的，並且穩定地按照服務描述所規定的約束和策略來執行”。換句話說，一個服務要提供某些業務能力，並提供定義良好的介面以及定義良好的合約以便（客戶）進行訪問。這個定義沒有規定的是如何基於類別、組織所有關係以及粒度『如服務的規模』（classification、organizational ownership and granularity）來進一步地定義服務。理解這些服務特性有助於在特定架構模式下為服務的上下文給出定義。

儘管微服務和SOA都有賴於服務作為其主要的架構元件，他們在服務特性上是有很大的差別的。本章將圍繞不同模式下服務如何分類（也就是服務的分類學）、如何基於服務的所有者進行服務之間的協調以及微服務與SOA之間服務粒度上的不同展開討論。

服務分類學

服務分類學指的是在某種架構下服務是如何歸類的。有兩種服務分類的基本型別：服務型別和業務領域。服務型別分類法會根據整個架構中服務所扮演的角色進行分類。例如，某些服務是實現業務功能的，而另一些服務可能是實現非業務功能的，例如日誌、審計和安全。業務領域分類法會根據服務在特定業務功能領域中所扮演的角色來進行分類，例如報表、交易處理和訂單送貨等等。

服務型別分類一般在架構模式層進行定義，而業務領域分類則在架構實現層進行定義。儘管架構模式提供了很好的基礎來定義服務型別，作為一個架構師，你可以按照自己的想法對其進行修改，定義自己的分類方法。本節中，我們會關注架構模式以及在微服務和SOA中比較常見的服務型別。

微服務架構就服務型別而言其分類法並不複雜，一般來說主要有兩類服務型別，如圖2-1所示。功能服務（functional services）是指用來支援特定業務操作或功能的服務，而基礎服務（infrastructure services）則負責支援非業務工作，例如認證、授權、審計、日誌和監控。在微服務架構中，這是非常重要的區別，因為基礎服務並不對外開放而僅作為供內部使用的私有共享服務，對其它服務可用。功能服務則提供外部訪問能力，而且不對其它服務共享。

圖2-1

SOA內的服務分類法跟微服務有很大不同。在SOA中，從全域性架構來看有非常明確的、非常正式的服務型別，各自在整體架構中扮演不同角色。儘管在SOA中可以有任意數量的服務型別，架構模式定義了四種基本型別，如圖2-2所示：

圖2-2

業務服務（business services）是一種抽象的、高層級的、粗粒度的服務，定義在企業層面的執行的核心業務操作。因為抽象，所以不依賴於任何實現或者協議，一般只包括服務名字，期望的輸入以及期望的輸出。可選地，這些服務型別還可以包括處理步驟或者跟服務相關的特殊編排規則。業務服務一般都用XML、Web Services Definition Language（WSDL）或者Business Process Execution Language（BPEL）等語言來表述。一般確認某個服務是否屬於業務服務會在服務名上下文前後加上“我們是否在做某某的業務”來加以判斷。例如，有兩個服務，分別名為ProcessTrade（處理交易）和InsertCustomer（插入客戶）。那麼“我們是否在做處理交易的業務”可以很清楚看出ProcessTrade是一個業務服務；而“我們是否在處理插入客戶的業務”聽上去就不對，所以不是一個好的業務服務抽象，更像是一個在處理業務服務時所呼叫的某個具體服務。

企業服務（enterprise services）是具體的、企業層級的、粗粒度的服務，用以實現業務服務所定義的功能。如圖2-2中所示，一般是介於抽象業務服務和對應具體企業服務實現之間的中介軟體，在其間起到橋樑作用。企業服務可以與業務服務之間存在一對一或一對多的對應關係。
它們可以用任何語言和平臺進行定製，或者採用第三方採購的產品（COTS）來實現。企業服務很獨特的一點是它們通常會在組織內共享。例如，一個RetrieveCustomer（檢索客戶）的企業服務可能被組織內很多模組使用，用來接收客戶資訊。其它例如CheckTradeCompliance（檢查交易合規） , CreateCustomer（建立客戶）, ValidateOrder（驗證訂單） 和 GetInventory（獲取庫存目錄）等都是企業服務很好的例子。企業服務通常依賴應用服務（application services）和基礎服務（infrastructure services）來完成特定業務請求。但是在某些情況下，某個企業服務也可能把完成特定請求所需要的所有業務功能都歸入自身，形成自包含的服務。

應用服務（application services）是細粒度的、特定於具體應用的服務，與某個特定應用的語境相關。應用服務提供在企業服務中沒有的特定的業務功能。例如，一個大型保險公司汽車報價應用可能提供服務來計算汽車保險費率。這是一個只針對該應用而並不適用於整個企業的服務。應用服務可以從某個專用的使用者介面直接呼叫，或者通過某個企業服務呼叫。應用服務的例子包括：AddDriver（新增司機）、AddVehicle（新增車輛）以及CalculateAutoQuote（計算機車報價）等等。

SOA中最後一個基本服務型別是基礎服務（infrastructure services）。與微服務架構相同，這些服務用於實現非功能性任務，例如審計、安全和日誌。在SOA中，基礎服務可以從應用服務或者企業服務呼叫。

需要記住的是，作為一個架構師，你既可以使用架構模式所提供的標準服務型別，也可以完全拋棄他們建立自己的分類方式。不管採用哪種方式，重要的事情是要確保針對架構存在定義良好且文件齊備的服務分類法。

服務責任制與協調

服務責任人（service owner）是組織內負責建立和維護某個服務的組別的型別。因為微服務架構僅支援有限的服務型別（功能服務和基礎服務），應用開發團隊一般都會同時負責這兩種服務。儘管大量應用開發團隊可能負責編寫服務，需要了解的是他們都屬於同一組別型別（即應用開發團隊）。圖2-3展示了微服務的服務責任制模型。

圖2-3

對於SOA而言，一般對不同服務型別有不同服務責任人。業務服務的責任人通常是業務使用者，而企業服務的責任人大多是是共享的服務團隊或者架構師。應用服務的責任人一般是應用開發團隊，基礎服務的責任人一般是應用開發團隊或者基礎服務團隊。中介軟體在SOA架構中經常使用，儘管不是一種服務，其責任人一般是整合架構師或者中介軟體團隊。圖2-4展示了SOA架構下服務責任制模型。

圖2-4

服務責任人的重要性體現在全域性的服務協調。在SOA中，必須在建立或維護某個應用需求的時候在多個組之間進行協調。關於抽象的業務服務必須諮詢業務使用者，關於完成業務服務功能所需的企業服務必須諮詢共享服務團隊，應用開發團隊之間必須相互協調才能保證企業服務可以呼叫底層功能。同樣，必須協調基礎團隊來確保非功能性需求能夠通過基礎服務得到保障。最後，所有這些都需要與中介軟體團隊或者管理訊息中介軟體的整合架構師進行協調。

在微服務場景中，完成某一業務請求通常只需要很少甚至完全不需要對多個服務進行協調。如果需要在多個服務責任人之間進行協調，也可以通過規模較小的應用開發團隊快速而高效地完成。

微服務和SOA在服務責任制和總體協調上的不同直接決定了兩種架構模式下開發、測試、部署和維護服務上所需要的精力和時間。在這個問題上，微服務模式表現突出。因為服務比較輕量，各個組之間協調最少，服務可以很快被開發、測試、部署。而這些優勢最終又轉化為較短的投放市場週期、較低的開發和維護成本以及和更穩定的應用。

服務粒度

從服務角度來看微服務和SOA的最大區別在於服務粒度。如名字所示，微服務是規模較小的、細粒度的服務。更確切地說，微服務架構中的服務元件一般都是單一目的/用途的服務，只做一件事且做到極致。而對於SOA而言，服務元件規模相差可以很大，可能是很小的應用服務，也可以是很大的企業服務。實際上，很常見的一種情況是SOA架構中的某個服務元件是由一個很大規模的產品或者一個子系統來提供。

有趣的是，SOA一開始碰到的最大挑戰來自於服務粒度。如果不理解服務粒度影響，架構師很可能會設計粒度過細的服務，導致太多資訊互動而影響整體效能。架構師和元件設計師很快學習到大規模的、粗粒度的、提供多種資料檢視的服務是更好的服務模式。例如，相比較於太細粒度的資料讀寫服務，像GetCustomerAddress（獲得客戶地址）、GetCustomerName（獲得客戶名稱）、UpdateCustomerName（更新客戶名稱）等等，架構師和共享服務團隊更願意採用部署企業級Customer（客戶）服務的做法，用於處理更多粗粒度更新和接收資料檢視，而把底層資料讀寫功能委託給並未開放給外部企業的應用級別服務。通過這種方式，像GetCustomerDemographics（獲得客戶統計資料）或者GetCustomerInformation（獲取客戶資訊）之類的操作會返回一批客戶資料，而不是單一的資料欄位。

粒度不同自然是跟服務元件的作用範圍和功能差異相關。對於微服務而言，服務元件的功能（服務作用範圍）傾向於做得較小，有時通過一兩個模組就可以完成。對於SOA，服務傾向於包含儘量多的業務功能，有時會作為子系統（例如，索賠處理引擎或者庫存系統）來實現。不過，SOA通常依賴於多個服務完成單個服務請求，而微服務卻並不這樣。我會在下一章的“服務編排”一節中詳細討論這個問題。

無論使用微服務架構還是SOA，選擇合適的粒度來設計服務並不是件容易的事情。服務粒度既影響效能也影響事務管理。服務的粒度太細時需要服務間通訊來完成單一業務請求，從而導致大量的遠端服務請求，佔用掉寶貴的時間。假設訪問某服務時花在遠端訪問協議上的時間是100毫秒，如圖2-5所示，僅僅花在資料傳輸上的時間就達到600毫秒。如果將這些服務整合到一個服務中，將會將傳輸時間減少為200毫秒，這樣總處理時間將會減少一半。

圖2-5

服務粒度也會影響事務管理。這裡我指的是傳統的ACID事務，而不是前一章提到的BASE事務。如果遠端服務的粒度太細，如圖2-6上圖所示，就不能使用一個事務工作單位來協調這些服務。然而，如果把這些服務組合進一個較大規模的遠端服務中，如圖2-6下圖所示，這時你就可以用一個事務來協調這些服務，從而確保資料庫更新可以在一個事務工作單位內完成。

圖2-6

在處理服務粒度時，我發現從粗粒度服務開始會更容易一些。隨著對服務的用法的瞭解逐漸增加，不妨再考慮如何對其進行拆分。如Sam Newman在Building Microservices書中所說，“從少數幾個大服務開始”。只需要觀察事務問題和服務之間通訊量，尤其是在微服務架構下，如果發生相關問題很可能說明服務可能粒度太細了。

相關推薦