[[406848]]

微服務(wù)架構(gòu)相比單體架構(gòu)而言的優(yōu)點(diǎn)，可以列舉出很多：服務(wù)個(gè)體更小，更內(nèi)聚，業(yè)務(wù)職責(zé)更清晰，可復(fù)用性更強(qiáng)，可以獨(dú)立部署發(fā)布等等；從軟件開發(fā)的角度，靈活性和效率都會(huì)有很大的提升……

然而，微服務(wù)架構(gòu)本質(zhì)上是分布式系統(tǒng)架構(gòu)，各個(gè)服務(wù)需要配合協(xié)同來(lái)完成產(chǎn)品的需求，業(yè)務(wù)數(shù)據(jù)的分散使得服務(wù)之間需要通過集成來(lái)完成協(xié)同工作，那么問題來(lái)了，集成要采用什么方式？要以什么樣的原則進(jìn)行？如何設(shè)計(jì)才能盡量保證不同服務(wù)之間數(shù)據(jù)的一致性？

混亂的實(shí)現(xiàn)

微服務(wù)架構(gòu)下推薦使用REST作為服務(wù)間同步通信的方式，對(duì)于非實(shí)時(shí)需求，可以基于事件來(lái)實(shí)現(xiàn)異步協(xié)作。這個(gè)原則非常簡(jiǎn)單，也非常容易實(shí)現(xiàn)，然而僅遵循這個(gè)原則卻很難讓我們沿著微服務(wù)的道路走下去。一些號(hào)稱微服務(wù)架構(gòu)的系統(tǒng)，最初服務(wù)拆分并無(wú)太大問題，但隨著邏輯的不斷擴(kuò)展，跨服務(wù)數(shù)據(jù)交換場(chǎng)景的增加，這個(gè)簡(jiǎn)單的原則就很難指引日常的決策，甚至引發(fā)了一些新的問題，舉幾個(gè)例子：

• 服務(wù)循環(huán)依賴

  在一些場(chǎng)景下服務(wù)A依賴服務(wù)B，會(huì)調(diào)用服務(wù)B的API，而在另外一些場(chǎng)景下，服務(wù)B也需要服務(wù)A的數(shù)據(jù)，也會(huì)通過調(diào)用服務(wù)A的API來(lái)實(shí)現(xiàn)。單從實(shí)現(xiàn)層面來(lái)看，按需獲取數(shù)據(jù)，實(shí)現(xiàn)很方便，可以完成業(yè)務(wù)要達(dá)成的效果；但從長(zhǎng)遠(yuǎn)來(lái)看，兩個(gè)服務(wù)的耦合越來(lái)越緊，未來(lái)新增需求的實(shí)現(xiàn)成本會(huì)越來(lái)越高，成為技術(shù)債

• 第三方系統(tǒng)集成實(shí)現(xiàn)到業(yè)務(wù)服務(wù)中

  在一些業(yè)務(wù)場(chǎng)景下，當(dāng)前產(chǎn)品需要的業(yè)務(wù)數(shù)據(jù)需要從幾個(gè)第三方系統(tǒng)獲取并進(jìn)行整合甚至經(jīng)過一些計(jì)算后才能使用，之前的一些項(xiàng)目在初期實(shí)現(xiàn)時(shí)，數(shù)據(jù)從第三方系統(tǒng)獲取后，經(jīng)過處理直接寫入業(yè)務(wù)數(shù)據(jù)庫(kù)，就把集成的代碼直接寫到業(yè)務(wù)服務(wù)中，看起來(lái)并沒有太大的問題，只要代碼上做好隔離就好了。但實(shí)際上，后期發(fā)生了一些棘手的問題讓我們不得不作出改變：

1. 一些定時(shí)觸發(fā)的集成任務(wù)，每次只會(huì)在一個(gè)服務(wù)實(shí)例上運(yùn)行，在運(yùn)行期間可能會(huì)有大量的數(shù)據(jù)讀取、計(jì)算、更新、插入等操作，會(huì)短時(shí)大量占用當(dāng)前服務(wù)實(shí)例的資源，嚴(yán)重的情況下當(dāng)前服務(wù)實(shí)例甚至無(wú)法正常對(duì)外提供服務(wù)
2. 相似的集成以同樣的方式集成到業(yè)務(wù)服務(wù)中，比如不同品牌的產(chǎn)品庫(kù)存會(huì)從多個(gè)第三方系統(tǒng)獲取，業(yè)務(wù)服務(wù)變的臃腫
3. 集成方的一些變化直接影響到業(yè)務(wù)服務(wù)，比如API的升級(jí)，這種改變必須要重新升級(jí)部署業(yè)務(wù)服務(wù)才能完成

• 集成接口不冪等

  無(wú)論在第三方系統(tǒng)集成和內(nèi)部服務(wù)的調(diào)用過程中，接口不冪等都會(huì)造成數(shù)據(jù)不一致的問題。最典型的場(chǎng)景是服務(wù)A調(diào)用服務(wù)B的接口更新或?qū)懭霐?shù)據(jù)，服務(wù)B處理成功，但由于網(wǎng)絡(luò)原因，服務(wù)A沒有收到服務(wù)B的響應(yīng)，服務(wù)A重試調(diào)用接口，此時(shí)，服務(wù)B由于接口不冪等返回異常的響應(yīng)，導(dǎo)致業(yè)務(wù)流程無(wú)法繼續(xù)下去

理想是豐滿的，現(xiàn)實(shí)是骨感的，大多數(shù)的項(xiàng)目開始于滿懷激情的整潔架構(gòu)的夢(mèng)想，而開發(fā)工作并不像想象的那么順利，伴隨著項(xiàng)目人員更替、交付壓力大、人員能力不足等等，架構(gòu)開始逐漸走向大家不期望的方向，技術(shù)債臺(tái)高筑，攻城獅們疲于奔命的追趕進(jìn)度的同時(shí)，只能望債臺(tái)興嘆。

集成的原則

當(dāng)問題發(fā)生時(shí)，架構(gòu)師們都能第一時(shí)間站出來(lái)說(shuō)這個(gè)設(shè)計(jì)太爛了，怎么能做成這樣；事后諸葛是我們積累經(jīng)驗(yàn)的重要手段，從高筑的技術(shù)債臺(tái)，從疲于救火的線上問題，從接了新需求卻找不到合理方案……我們一直在總結(jié)經(jīng)驗(yàn)，為了避免再次摔倒在同一個(gè)地方，有哪些架構(gòu)設(shè)計(jì)原則可以先行呢？

單向依賴

微服務(wù)拆分之初都定義了各個(gè)服務(wù)的上下游關(guān)系，我們可以定義上下游服務(wù)的依賴關(guān)系如下：

• 下游服務(wù)可以直接依賴上游服務(wù)，下游服務(wù)可以通過上游服務(wù)提供的API同步對(duì)上游服務(wù)的數(shù)據(jù)進(jìn)行讀寫
• 上游服務(wù)不依賴下游服務(wù)，上游服務(wù)數(shù)據(jù)狀態(tài)變化如果會(huì)對(duì)下游服務(wù)產(chǎn)生影響，可以通過發(fā)布領(lǐng)域事件，由下游系統(tǒng)監(jiān)聽事件作出對(duì)應(yīng)的操作
  

  服務(wù)間僅冗余引用信息

  微服務(wù)的各個(gè)領(lǐng)域?qū)嶓w之間存在著各式各樣的關(guān)系，當(dāng)領(lǐng)域?qū)嶓wA依賴領(lǐng)域?qū)嶓wB的信息時(shí)，通常需要在領(lǐng)域?qū)嶓wA中保留一部分領(lǐng)域?qū)嶓wB的副本信息，那這份副本信息中該包含哪些信息呢？

舉個(gè)例子，領(lǐng)域?qū)嶓wA是訂單，領(lǐng)域?qū)嶓wB是客戶，客戶端每次查詢訂單信息時(shí)，都要求同時(shí)查出客戶的姓名、性別和手機(jī)號(hào)碼，將這3個(gè)關(guān)鍵信息冗余在訂單的服務(wù)中就可以輕松滿足需求了，一切聽起來(lái)是那么的美好。

然而，這3個(gè)關(guān)鍵信息如果是可以變化的，那么問題就來(lái)了，如果領(lǐng)域?qū)嶓wB中的信息更新了，領(lǐng)域?qū)嶓wA中的信息要不要更新，如果不更新會(huì)造成數(shù)據(jù)不一致，如果更新無(wú)端增加了復(fù)雜度，而很有可能因此而產(chǎn)生循環(huán)依賴。

因此，在無(wú)法確定數(shù)據(jù)變化的準(zhǔn)確情況時(shí)，在副本中只保留引用信息最保險(xiǎn)，需要完整信息時(shí)可以通過引用查詢相關(guān)信息。

為第三方系統(tǒng)構(gòu)建外觀服務(wù)

面對(duì)第三方系統(tǒng)集成，在系統(tǒng)集成過程中要考慮的更周全，一般情況下，我們無(wú)法控制第三方系統(tǒng)，一旦集成出現(xiàn)問題，需要溝通解決方案，排期開發(fā)，聯(lián)調(diào)測(cè)試等等，修復(fù)周期很長(zhǎng)。

另一個(gè)問題是第三方系統(tǒng)通常采用的技術(shù)棧或集成方式可能和我們的系統(tǒng)完全不同。比如它可能是個(gè)非常老舊的系統(tǒng)，提供的接口是基于XML的SOAP；再比如它可能無(wú)法提供API，只能通過導(dǎo)出文件到某個(gè)SFTP或發(fā)送郵件的方式進(jìn)行集成……

為了讓第三方系統(tǒng)集成產(chǎn)生盡量小的影響，我們傾向于構(gòu)建外觀服務(wù)來(lái)隱藏第三方系統(tǒng)實(shí)現(xiàn)的細(xì)節(jié)，通過外觀服務(wù)對(duì)第三方系統(tǒng)的功能進(jìn)行包裝，提供和當(dāng)前系統(tǒng)更加一致的集成方式。我們可以把外觀服務(wù)和第三方系統(tǒng)看做是一個(gè)整體，那么第三方系統(tǒng)的集成對(duì)于當(dāng)前系統(tǒng)內(nèi)的服務(wù)來(lái)說(shuō)，服務(wù)間的集成就可以和內(nèi)部服務(wù)一樣處理。而對(duì)于第三方系統(tǒng)集成相關(guān)的細(xì)節(jié)內(nèi)容被隔離在外觀服務(wù)中，第三方系統(tǒng)集成的變化，只需要修改外觀服務(wù)就可以了。

集成接口實(shí)現(xiàn)要考慮冪等性

這個(gè)原則非常簡(jiǎn)單，但實(shí)現(xiàn)過程中非常容易被忽略，如果不在設(shè)計(jì)好的測(cè)試用例中，測(cè)試過程中也很難發(fā)現(xiàn)問題；多數(shù)情況下是到了線上，用戶使用的真實(shí)場(chǎng)景才會(huì)發(fā)現(xiàn)問題，這時(shí)已經(jīng)產(chǎn)生了業(yè)務(wù)影響。

因此在涉及集成的接口中，要特別關(guān)注，業(yè)務(wù)上是否要求接口的冪等性，接口不冪等的情況下業(yè)務(wù)是否能夠正常的流轉(zhuǎn)。

契約測(cè)試

服務(wù)提供的接口通常不只有一個(gè)消費(fèi)者，不同消費(fèi)者關(guān)心的信息往往可能也不一樣，隨著服務(wù)數(shù)量的增加，在沒有契約測(cè)試的情況下，很有可能發(fā)生因?yàn)橐粋€(gè)需求修改了當(dāng)前服務(wù)接口的實(shí)現(xiàn)，而影響其他已有功能。而往往這個(gè)問題直到全面回歸的時(shí)候才能完全發(fā)現(xiàn)，甚至可能發(fā)生因改動(dòng)范圍很小，回歸不夠，在上線前也難以發(fā)現(xiàn)。

契約測(cè)試可以很好的解決這個(gè)問題，一方面測(cè)試前置，盡早提供反饋，另一方面也起到了架構(gòu)守護(hù)的作用。

小結(jié)

系統(tǒng)集成是分布式系統(tǒng)中一定會(huì)談及的問題，而且是個(gè)大問題，因?yàn)樗苯佑绊懙疆?dāng)前系統(tǒng)的架構(gòu)，一個(gè)微不足道的改動(dòng)很可能就破壞了整個(gè)系統(tǒng)架構(gòu)的原則，久而久之原則便形同虛設(shè)。

微服務(wù)架構(gòu)也不例外，在缺少架構(gòu)約束的情況下，只圖一時(shí)之快的實(shí)現(xiàn)往往會(huì)葬送了微服務(wù)的優(yōu)勢(shì)，一個(gè)個(gè)微小的不合理改動(dòng)會(huì)逐漸將整個(gè)架構(gòu)大廈摧毀，所謂千里之堤，潰于蟻穴就是這個(gè)道理。

因此，在微服務(wù)架構(gòu)設(shè)計(jì)之初，我們就要在團(tuán)隊(duì)內(nèi)建立一些原則，明確系統(tǒng)間集成需要遵守的一些規(guī)范，并且在實(shí)踐過程中定期review，必要時(shí)可以采用一些架構(gòu)守護(hù)的輔助工具，來(lái)保護(hù)架構(gòu)的健康度。