微服務學習與思考(03):微服務總體架構圖解

九卷發表於2020-07-13

前面微服務2篇文章:

如何進行服務分層

分層:是一種很常見的架構方法。比如我們常見的網路協議TCP/IP的分層。分層之後,各層各司其職,相互隔離開來。

最簡單的服務分層

服務分層

第一層:接入層
外部裝置訪問的統一接入層。

第二層:聚合服務層
對下層的基礎服務做一些聚合,剪裁的工作,適配上層不同裝置的資料輸出。

第三層:基礎服務層
比較細粒度的微服務層,提供基礎的核心服務,公共服務。

有了下面的基礎服務層,還有上面的聚合層幹什麼呢?

比如:有時候PC端和APP端的資料顯示不一樣,手機螢幕比較小,可能顯示的資料少些,而PC端顯示的資料多些,這樣就需要對不同的接入層裝置的資料做一些裁剪的工作。

比如:下面的基礎服務層,分的服務粒度可能比較細,接入層APP需要一個功能時,有時需要訪問幾個基礎服務,之後APP在聚合這些服務資料,這樣效率就很差,不如我們在服務端直接聚合服務,然後把聚合好的資料直接發給APP,這樣訪問效率就可以提升,從而提升使用者體驗。

上面只是一個最基本的服務分層,可以在這個基本分層結構之上進行擴充套件。

微服務總體架構圖

學習楊波老師的《微服務架構》裡面的一張圖,稍微做了一些修改:

微服務總體架構圖

上面的總體技術架構圖一共分了6層

  • 接入層
    也可以叫負載均衡層,把外部的流量引入到系統中來。一般負載均衡軟體有nginx,lvs,還有各大雲服務廠商自己的負載均衡服務。

  • 閘道器層
    內部介面的一些認證、安全、鑑權、過濾、限流等服務,一般處於這一層。這一層把內部的服務介面做一層安全隔離,保護內部服務,同時也可以實現一些其他需求,比如前面講的鑑權、黑名單過濾等等需求。所以這一層在微服務架構中是很重要的一層。

  • 業務服務層
    基礎服務和聚合服務

    • 基礎服務:根據業務特點又可以分為核心基礎服務、公共服務、中間層服務等。
    • 聚合服務:把下面細粒度的基礎服務再進一步封裝、關聯,組合成新的服務,供上層呼叫。這一層可以實現多變的需求。
      上面的這種劃分是根據邏輯來劃分,各個公司可以根據自己實際的業務需求來進行劃分。
  • 支撐服務層
    微服務能夠成功實施落地,這一層與下一層CI/CD的配套設施是非常重要。微服務不是把上面的業務服務寫完就完事了,在服務治理的過程中需要很多配套設定支援。
    這一層包括註冊服務中心,配置中心,監控報警服務,日誌聚合服務,呼叫鏈監控幾大服務,後臺服務涉及的服務有訊息佇列,定時任務,資料訪問等內容。

  • 平臺服務層
    這一層是實施業務彈性治理的關鍵。叢集的資源排程:擴充套件和減少。業務量上來時,可以彈性增加資源。
    在微服務建設過程中,可能會遇到一些突發事件。比如微博明星熱點事件,會導致訪問量暴增,這就需要能實時增加服務資源應對這種突發情況,熱點過後,又要減少資源。
    映象管理和釋出系統配合使用可以應對出現的這種情況。所以很多團隊後面會引入docker+k8s,容器,映象管理,容器服務編排。此外,基於CI/CD的DevOps也是構建在這一層能力。

  • 基礎設施層
    這個是最底層的基礎設施,網路,儲存,硬碟,IDC的部分。
    laas 這個概念就是針對這一層。

上面的這個架構圖,還可以有其他的表現形式,比如把支撐系統服務畫在2側面,只要能正確表達出架構思想。

每家公司業務模型,開發人員,都不盡相同,所以架構設計也可能不同,上面的當作一種參考設計。請務必根據自家情況來設計架構,適合自己的才是最好的。

參考

相關文章