混亂的實現(xiàn)

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

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

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

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

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

一些定時觸發(fā)的集成任務(wù)，每次只會在一個服務(wù)實例上運(yùn)行，在運(yùn)行期間可能會有大量的數(shù)據(jù)讀取、計算、更新、插入等操作，會短時大量占用當(dāng)前服務(wù)實例的資源，嚴(yán)重的情況下當(dāng)前服務(wù)實例甚至無法正常對外提供服務(wù)

相似的集成以同樣的方式集成到業(yè)務(wù)服務(wù)中，比如不同品牌的產(chǎn)品庫存會從多個第三方系統(tǒng)獲取，業(yè)務(wù)服務(wù)變的臃腫

集成方的一些變化直接影響到業(yè)務(wù)服務(wù)，比如API的升級，這種改變必須要重新升級部署業(yè)務(wù)服務(wù)才能完成

?