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

前面微服務2篇文章：

• 微服務學習與思考(01)：什麼是微服務？微服務的優點和劣勢
• 微服務學習與思考(02)：微服務實施前有哪些問題須要思考？

如何進行服務分層

分層：是一種很常見的架構方法。好比咱們常見的網絡協議TCP/IP的分層。分層以後，各層各司其職，相互隔離開來。

最簡單的服務分層：

第一層：接入層
外部設備訪問的統一接入層。

第二層：聚合服務層
對下層的基礎服務作一些聚合，剪裁的工做，適配上層不一樣設備的數據輸出。

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

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

好比：有時候PC端和APP端的數據顯示不同，手機屏幕比較小，可能顯示的數據少些，而PC端顯示的數據多些，這樣就須要對不一樣的接入層設備的數據作一些裁剪的工做。

好比：下面的基礎服務層，分的服務粒度可能比較細，接入層APP須要一個功能時，有時須要訪問幾個基礎服務，以後APP在聚合這些服務數據，這樣效率就不好，不如咱們在服務端直接聚合服務，而後把聚合好的數據直接發給APP，這樣訪問效率就能夠提高，從而提高用戶體驗。

上面只是一個最基本的服務分層，能夠在這個基本分層結構之上進行擴展。

微服務整體架構圖

學習楊波老師的《微服務架構》裏面的一張圖，稍微作了一些修改：

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

• 接入層
  也能夠叫負載均衡層，把外部的流量引入到系統中來。通常負載均衡軟件有nginx，lvs，還有各大雲服務廠商本身的負載均衡服務。

• 網關層
  內部接口的一些認證、安全、鑑權、過濾、限流等服務，通常處於這一層。這一層把內部的服務接口作一層安全隔離，保護內部服務，同時也能夠實現一些其餘需求，好比前面講的鑑權、黑名單過濾等等需求。因此這一層在微服務架構中是很重要的一層。

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

  • 基礎服務：根據業務特色又能夠分爲核心基礎服務、公共服務、中間層服務等。
  • 聚合服務：把下面細粒度的基礎服務再進一步封裝、關聯，組合成新的服務，供上層調用。這一層能夠實現多變的需求。
    上面的這種劃分是根據邏輯來劃分，各個公司能夠根據本身實際的業務需求來進行劃分。

• 支撐服務層
  微服務可以成功實施落地，這一層與下一層CI/CD的配套設施是很是重要。微服務不是把上面的業務服務寫完就完事了，在服務治理的過程當中須要不少配套設置支持。
  這一層包括註冊服務中心，配置中心，監控報警服務，日誌聚合服務，調用鏈監控幾大服務，後臺服務涉及的服務有消息隊列，定時任務，數據訪問等內容。

• 平臺服務層
  這一層是實施業務彈性治理的關鍵。集羣的資源調度：擴展和減小。業務量上來時，能夠彈性增長資源。
  在微服務建設過程當中，可能會遇到一些突發事件。好比微博明星熱點事件，會致使訪問量暴增，這就須要能實時增長服務資源應對這種突發狀況，熱點事後，又要減小資源。
  鏡像管理和發佈系統配合使用能夠應對出現的這種狀況。因此不少團隊後面會引入docker+k8s，容器，鏡像管理，容器服務編排。此外，基於CI/CD的DevOps也是構建在這一層能力。

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

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

每家公司業務模型，開發人員，都不盡相同，因此架構設計也可能不一樣，上面的看成一種參考設計。請務必根據自家狀況來設計架構，適合本身的纔是最好的。

參考

• 楊波老師的微服務架構
• 惟品會微服務架構演進