1.概述

分別從整體層級、開發檢視、部署檢視三個角度，對整個系統的微服務架構進行“解剖”。整體層級關注呼叫的層級（從終端人機介面到物聯網）；開發檢視則主要面向開發人員，描述了系統工程結構、模組及關聯關係；部署檢視則是系統最終部署時的拓撲圖；通過這些視角可以較為清晰的明白整個微服務架構設計思路。

2.整體層級檢視

自頂向下的一張呼叫層次關係圖：

詳細的說明，見下方的開發檢視和部署檢視。

 

3.開發檢視

下圖僅對微服務部分進行描述，前端架構不是本文重點部分，在下一節的部署圖中會作說明：

微服務開發檢視展示了java開發環境中有哪些具體的工程、工程之間的依賴關係，關鍵點說明如下：

1. 上圖中的每一個元件框代表了一個工程，所有工程都採用spring boot構建，都通過繼承基礎POM，通過maven來進行多工程之間的依賴管理；
2. 右側的基礎工程以jar包方式被所有微服務工程引用，通用服務則是單獨執行起來，供其所有工程以restful介面方式呼叫。
3. 微服務目前劃分為5個，分別是公式超市、行業記錄、相簿、使用者子系統、共用服務，具體詳細設計時會進行細化完善，設計為可以單獨執行（啟動多個獨立程式），也可以合併（該工程通過引用jar包方式合併）在一個工程執行（啟動一個程式），主要是視使用者規模來定（程式碼工程為一套，只是打包時不一樣或作少量程式碼配置修改即可完成不同的部署方式）；
4. 微服務分為客戶端和服務端，服務端支援HA部署，上圖設計和下方部署設計中客戶端不是直接呼叫服務端，也可以依據專案進度緊迫性要求，先可以讓客戶端（前端）直接訪問微服務，而是通過eurake註冊中心，還有熔斷、閘道器等服務通過spring cloud元件完成，只需少量配置即可。

4.整體部署圖

部署圖更為直觀地展示了服務之間的呼叫關係、各服務部署情況。如下圖：

上圖中呼叫關係看起來較複雜，按以下思路看圖：

1. 實際上都是以服務註冊中心和相關元件為中心，見上圖中的橙色部分，這部分的服務都可以直接採用spring cloud提供的現成元件，除閘道器可能有較多業務程式碼外，其它只需要做少量配置即可，入門門檻很低；
2. 業務類微服務，見下方中間部分是具體restful介面api，同常規的spring boot工程沒有太大區別，關鍵在於充分的理解業務，進行較為合理的劃分；
3. 通用類服務，這部分主要一些通用服務，其中訊息對列（kafka/emq/rabbitmq等）可以直接採用開源元件即可，認證授權是對整個受限訪問資源訪問控制，可以採用JWT方式進行認證，可以在業務類客戶端呼叫，也可以在閘道器呼叫（或者直接寫到閘道器程式碼中）； 訊息推送服務，主要是對一些需要即時推送的訊息進行立即推送服務，pc瀏覽器可以採用webstocket方式推送，手機端可以採用極光等第三方推送服務；
4. 持久化部分，見左側部分，分別對不同的儲存場景，使用不同的存取方式，對大多數系統來說可能只需要一個關係型資料庫，但有些情況還是需要用到nosql、分佈多檔案系統，但一般nosql用於解決關係簡單大表的儲存和查詢，常規的業務還是建議放到關係統資料庫中；
5. 右側部分為客戶端部分，這裡有兩種方式：

        A.加入一層微服務客戶端，主要為了更好的處理訪問時的負載均衡、容斷、restful服務；

       B.直接呼叫閘道器，閘道器再呼叫具體的微服務，見上圖中虛線部分；

不管採用哪種方式，本案例中採用的是前後分離的開發模式，在ngnix中放置前端開發的程式碼（如vue.js+elementUI或bootstrap、layui等）直接配置到ngnix中或者用node.js啟動後，在ngnix的配置檔案中進行代理。

最後看一下手機端，不管採用原生的開發還是html5+css3方式開發，其呼叫介面將保持不變，建議一般要求不高的場景下采用html5開發，這樣基本上前端人員即可完成移動端開發工作，原生開發則需要分別招聘andriod/ios開發人員。

5.總結

個人認為，其實大部分情況下中小型系統不適合採用微服務架構，一個系統跑下來，即使是一個小網站，也要啟動很多服務程式，雖然解決了效能、HA單點問題，方便日後分模組進行升級，但對人員的要求相對要高很多，開發工作量要比單體應用高出很多，如果沒有專業的團隊，很可能實際的效能、可靠性反而降低了。另外開發微服務在開發過程中也需解決很多低效的開發問題，如應採用程式碼生成器和形成很多團隊開的規範的約定。