spring cloud微服務架構設計

spring cloud微服務架構設計

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單點問題，方便日后分模塊進行升級，但對人員的要求相對要高很多，開發工作量要比單體應用高出很多，如果沒有專業的團隊，很可能實際的性能、可靠性反而降低了。另外開發微服務在開發過程中也需解決很多低效的開發問題，如應采用代碼生成器和形成很多團隊開的規范的約定。