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