前面微服務2篇文章： - [微服務學習與思考(01)：什麼是微服務？微服務的優勢和劣勢](https://www.cnblogs.com/jiujuan/p/13280473.html) - [微服務學習與思考(02)：微服務實施前有哪些問題需要思考？](https://www.cnblogs.com/jiujuan/p/13284412.html) ## 如何進行服務分層 分層：是一種很常見的架構方法。比如我們常見的網路協議TCP/IP的分層。分層之後，各層各司其職，相互隔離開來。 **最簡單的服務分層**：  **第一層：接入層** 外部裝置訪問的統一接入層。 **第二層：聚合服務層** 對下層的基礎服務做一些聚合，剪裁的工作，適配上層不同裝置的資料輸出。 **第三層：基礎服務層** 比較細粒度的微服務層，提供基礎的核心服務，公共服務。 有了下面的基礎服務層，還有上面的聚合層幹什麼呢？ 比如：有時候PC端和APP端的資料顯示不一樣，手機螢幕比較小，可能顯示的資料少些，而PC端顯示的資料多些，這樣就需要對不同的接入層裝置的資料做一些裁剪的工作。 比如：下面的基礎服務層，分的服務粒度可能比較細，接入層APP需要一個功能時，有時需要訪問幾個基礎服務，之後APP在聚合這些服務資料，這樣效率就很差，不如我們在服務端直接聚合服務，然後把聚合好的資料直接發給APP，這樣訪問效率就可以提升，從而提升使用者體驗。 >上面只是一個最基本的服務分層，可以在這個基本分層結構之上進行擴充套件。 ## 微服務總體架構圖 學習楊波老師的《微服務架構》裡面的一張圖，稍微做了一些修改：  上面的總體技術架構圖一共分了6層 - **接入層** 也可以叫負載均衡層，把外部的流量引入到系統中來。一般負載均衡軟體有nginx，lvs，還有各大雲服務廠商自己的負載均衡服務。 - **閘道器層** 內部介面的一些認證、安全、鑑權、過濾、限流等服務，一般處於這一層。這一層把內部的服務介面做一層安全隔離，保護內部服務，同時也可以實現一些其他需求，比如前面講的鑑權、黑名單過濾等等需求。所以這一層在微服務架構中是很重要的一層。 - **業務服務層** 基礎服務和聚合服務 - 基礎服務：根據業務特點又可以分為核心基礎服務、公共服務、中間層服務等。 - 聚合服務：把下面細粒度的基礎服務再進一步封裝、關聯，組合成新的服務，供上層呼叫。這一層可以實現多變的需求。 上面的這種劃分是根據邏輯來劃分，各個公司可以根據自己實際的業務需求來進行劃分。 - **支撐服務層** 微服務能夠成功實施落地，這一層與下一層CI/CD的配套設施是非常重要。微服務不是把上面的業務服務寫完就完事了，在服務治理的過程中需要很多配套設定支援。 這一層包括註冊服務中心，配置中心，監控報警服務，日誌聚合服務，呼叫鏈監控幾大服務，後臺服務涉及的服務有訊息佇列，定時任務，資料訪問等內容。 - **平臺服務層** 這一層是實施業務彈性治理的關鍵。叢集的資源排程：擴充套件和減少。業務量上來時，可以彈性增加資源。 在微服務建設過程中，可能會遇到一些突發事件。比如微博明星熱點事件，會導致訪問量暴增，這就需要能實時增加服務資源應對這種突發情況，熱點過後，又要減少資源。 映象管理和釋出系統配合使用可以應對出現的這種情況。所以很多團隊後面會引入docker+k8s，容器，映象管理，容器服務編排。此外，基於CI/CD的DevOps也是構建在這一層能力。 - **基礎設施層** 這個是最底層的基礎設施，網路，儲存，硬碟，IDC的部分。 laas 這個概念就是針對這一層。 上面的這個架構圖，還可以有其他的表現形式，比如把支撐系統服務畫在2側面，只要能正確表達出架構思想。 >每家公司業務模型，開發人員，都不盡相同，所以架構設計也可能不同，上面的當作一種參考設計。請務必根據自家情況來設計架構，適合自己的才是最好的。 ## 參考 - [楊波老師的微服務架構](https://time.geekbang.org/course/intro/100003901) - [唯品會微服務架構演進](https://www.infoq.cn/article/mFQxr9JM01ua7_