六種經常使用的微服務架構設計模式 第二種模式

基於細粒度SOA的分層API

簡單地說，API主導的鏈接方法能夠被看做是API設計的一種分層方法（至少在本文中是這樣）。其中，系統API公開系統的資產數據信息；中間的是流程API，與系統API一塊兒進行編排和組合；頂端的體驗API公開來自後端數據源的數據，提供最終用戶體驗。這種API分層方法與細粒度SOA模式很好地結合在一塊兒，一般，這二者要麼能夠共存，要麼細粒度SOA模式演化成基於細粒度SOA的分層API模式。

API主導的鏈接方法爲細粒度SOA模式提供了一些層次結構，這些層次結構容許對API或微服務進行一致的管理和治理。然而，基於細粒度SOA的分層API模式也存在一些與細粒度SOA 模式相似的深層問題（這很直觀）：

在細粒度SOA模式執行單個API調用的地方，基於細粒度SOA的分層API模式如今必須經過層執行多個調用。從「網絡跳數」的角度來看，這種模式多是低效的。可是，基於細粒度SOA的分層API模式中，層次結構的存在並不強制跨越網絡來調用每一個API。直接的跨層調用，而不是經過網絡調用是徹底有效的；分層的目的是爲了增長靈活性，同時以一種很好地分離關注點的方式構建體系架構。

在細粒度SOA模式管理大量服務的地方，使用分層API將會管理來自多個層次的大量細粒度服務。您的管理工具可能再也不像之前那樣有效，由於它們可能沒法可視化複雜的微服務視圖。

最終應用程序的數據存儲一致性在分層API模式下實際上獲得了改善，由於訪問數據的服務都是有組織，且集中地查詢或修改應用程序的狀態。（例如：系統API）

實際上，對於大多數企業來講，基於細粒度SOA的分層API模式是一個很好的模式，可是，就像細粒度SOA模式同樣，在實踐過程當中會出現困難。然而，這種困難一般在大範圍使用時纔會顯現出來。所以，只有在預期或正在經歷大規模的使用時，咱們才應該準備其餘的模式。

問題：

沒有必定層次結構的微服務架構是很難進行合理解釋的，由於沒有明顯的方法來對每一個微服務的用途進行分類和可視化。

解決方案：

經過建立按用途分組的分層API（系統層、流程及領域模型層，以及體驗層），您能夠更容易地管理微服務架構的複雜性。

應用：

將微服務架構分爲多個層。一般狀況下，可使用標準化，並具備相似用途的一組微服務以相似的方式工做，從而進一步使微服務架構的複雜性合理化。

影響：

1.經過標準化和進一步分解微服務架構，能夠提升快速變動的能力。

2.因爲更專門化的層次結構，進程間服務調用的數量可能增長。

3.須要對服務監控和可視化工具進行檢查，以肯定它們是否可以正確地與分層架構一塊兒工做。

目標：

1.快速的敏捷變動。

2.可伸縮性：理論上經過基於細粒度SOA的分層API模式能夠提升可伸縮性，但實際上，除非有支持自動化的基礎設施，不然可伸縮性每每會下降。

主要特色：

1.爲了實現快速變動，可能存在低效的IPC（Inter-Process Communication，進程間通訊）。

2.數據一致性和狀態管理能力較差，但容許高度重用。重用自己會抵消變動的速度。

3.因爲與現存模式的類似性，已有的問題每每一樣會出現。

4.基於細粒度SOA的分層API模式在小範圍內使用效果很好，在大規模狀況下會出現困難。

5.因爲採用告終構化的體系架構方法，因此具備很高的內聚性。

6.重點放在服務顆粒度要細，但一般沒有考慮其能力。

7.基於細粒度SOA的分層API模式以集成爲導向，每一個微服務依賴於外部系統。這將會下降變動的速度。

基於細粒度SOA的分層API模式如何與SOA或API等現有系統共存？

基於細粒度SOA的分層API模式每每是與現有IT資產共存的最佳方式。因爲分層減小了每一個微服務的範圍，並約束了其用途，所以該模式可以在不明顯下降變動速度的狀況下，最好地鏈接和利用現有IT系統。然而，經過細粒度和分層的設計來協調變動多是一個挑戰。您可能須要使用必定的技術手段來管理全部不一樣微服務之間的契約，或者使用徹底自動化的測試技術來確保變動不會形成破壞。