【揭祕】一個小團隊真正能落地的微服務架構實踐

編者的話

微服務是否真的適合小團隊這裏很少作爭辯。可是透過現象看本質，隨着產品版本的不斷迭代、業務複雜度的提升最終都會致使單體應用愈來愈龐大，總會超過單體架構的負荷。那麼使用微服務分而治之就成爲一個不得不面對的問題。因此這麼龐大的單體應用拆分出多個小應用也更符合這種分治的思想。雖然這些不是小團隊可以考慮到的事情，可是若是能在產品的初期階段可以規劃好產品的架構體系那麼在慢慢演變的過程當中會愈來愈順手，團隊的戰鬥力也打造的愈來愈強。

1、背景

公司的背景是提供SaaS服務，初期是對於客戶的定製開發以及私有化部署。通過兩年多的發展，公司產品受到客戶的歡迎而且慢慢蛻變到平臺化的產品，技術架構也從單體架構到微服務架構遷移。

一、單體應用

起步的時候開發人員只有二、3人，並無考慮微服務之類的（多餘）。可是總體架構採用了SPA式的先後端分離法，單純的從物理層作區分（認爲只要是客戶端的就是前端，服務器端的就是後端），這種分法不能知足先後端分離的需求，認爲從技術職責上劃分才能知足目前咱們的使用場景。

因爲團隊資源有限後端人員每每擔任前端的一些開發任務，因此採用了以下職責劃分：
前端：負責View和Controller層。
後端：只負責Model層，業務處理/數據等。
複製代碼

優勢：能夠作url design，咱們能夠根據場景決定在服務端同步渲染，仍是根據view層數據輸出json數據，咱們還能夠根據表現層需求很容易的作Bigpipe,Comet,Socket等等，徹底是需求決定使用方式。
缺點：須要前端來寫Controller，以Java語言開發爲例，須要前端學會Java開發，這樣在處理複雜的業務邏輯的產品裏雙方都有Java 代碼方面的重疊。

服務器部署上，採用Nginx代理前端HTML資源，在接收請求時根據路徑反向代理到服務端口達到實現業務目的，以下圖所示：

單體架構部署

採用RESTful Api和Json搭建先後臺交互

備註：後臺提供一組設計原則和約束條件，接口經過swagger生成文檔進行接口測試和聯調。

二、開發過程遇到的問題

2.1 半持續集成
因爲團隊成員之間沒有共事過的經歷，對於開發模式、質量管控和開發流程都須要從新開始制定。針對這種狀況開發初期沒有進行引入很是完整的集成測試體系，主要是針對接口進行單元測試（Unit Test）、編寫測試用例和人工Review。

2.2 引進Jenkins持續集成工具
Jenkins功能包括：
一、持續的軟件版本發佈/測試項目。
二、監控外部調用執行的工做。

兩種啓動方式

第一種：
切換到jenkins.war存放的目錄，輸入以下命令：
$ java -jar jenkins.war
若是須要修改端口可使用以下命令：
$ java -jar jenkins.jar--httpPort=8081
而後在瀏覽器中輸入localhost:8081，localhost能夠是本機的ip，也能夠是計算機名。就能夠打開jenkins。
第二種：
解壓tomcat到某個目錄,如/usr/local，進入tomcat下的/bin目錄，啓動tomcat
將jenkins.war文件放入tomcat下的webapps目錄下，啓動tomcat時，會自動在webapps目錄下創建jenkins目錄，在地址欄上須要輸入localhost:8080/jenkins。
複製代碼

Jenkins持續集成

持續集成

執行步驟：

• 開發人員提交代碼進入gerrit中；
• Jenkins被觸發開始編譯代碼並執行集成測試；
• 完成後生成測試報告；
• 測試經過再由reviewer進行代碼Review；

在單體應用時代這樣的CI架構已經足夠好用，因爲有集成測試的覆蓋，在保持API兼容性的前提下進行代碼重構都將變得更有信心。

3、微服務時代

1 服務拆分原則
「獨立，獨立，再獨立？」先忘記這句話吧！想象是美好的，顯示卻很骨感。如下拆分方案能夠給你們一點參考，有好的經驗也能夠留言分享。

1.1 公共庫的初始化拆分
咱們把公共的庫都放在common裏面，這裏麪包括了log，config，errors等基礎庫，還有redis，mysql，mongodb等db的鏈接池初始化，還有rpc的鏈接池初始化，這裏或者用grpc或者用戶本身基於go自帶的rpc的二次封裝等。還有trace等用於追蹤請求方便日誌查詢的基本庫。

這些基礎庫是咱們作微服務的必備，在搭建一個新項目的時候，前期需求討論評審完成後，編碼前期，咱們會先把這些公共庫的初始化工做都作了，好比db的一些鏈接池初始化不一樣項目稍微有一些不一樣。rpc等鏈接池代碼基本都是能複用的。其餘的公共庫，直接拖到新項目裏就能開搞，大大的規範了代碼質量和減小開發週期。

1.2 根據業務職責拆分
其實微服務的拆分最根本是一些代碼職責的拆分和抽象，這一步和咱們模塊化的時候思路是同樣的。咱們將按照要開發的業務功能拆分爲不一樣的項目，而負責不一樣功能的研發人員就能夠在本身的代碼項目上進行開發，從而解決了你們沒法在開發階段並行開發的苦惱。

業務職責拆分

如上圖所示，能夠拆分爲用戶中心、產品中心和訂單中心等，支撐總體業務的基礎服務業能夠相應的進行拆分。

1.3 各組件之間接口的定義（重點講）
公共庫和各個業務職責搞清楚後，接下來還不要着急寫代碼，咱們先把各個組件之間接口定義清楚。否則各自寫各自的，最後仍是一團亂麻。
先作到如下幾點：
1.3.1 接口協議選型。

- 如今微服務流行採用的http協議restful接口(語言無關)。
- RMI遠程接口調用(Java語言支持)。
- 大數據傳遞採用文件離線下載的方式(FTP)。
- 狀態數據(若是進度條)放在Redis中共享緩存。
- 數據庫共享。通常來講微服務的數據庫是隔離的，不一樣微服務不容許直接訪問彼此的數據庫。如涉及大數據有性能問題時可特殊考慮。
複製代碼

備註：若是爲防止數據被人抓包分析，須要有相對應的加解密處理方案。

1.3.2 定義接口內容。
接口內容包含接口名稱(url)、輸入參數、返回值、錯誤碼。一個典型的restful接口內容定義以下：

restful示例

備註：code：100表明成功，message：描述說明，result：返回詳細信息能夠通常是json格式

1.3.3 明確接口性能。
接口性能包括：接口單次響應時間、單次查詢返回記錄條數和每秒支持調用次數等。數據量比較大的查詢接口一把都會設計成分頁查詢，須要定義好單次查詢返回的最大記錄條數。

微服務接口的支撐能力是有限的，必須定義好單位時間內容許的最大請求次數(超過請求次數就不響應或者返回錯誤碼)，不然海量的請求一下涌過來，服務就掛了。對於特殊的服務，還會根據實際狀況設定一天的請求次數上限等。

1.3.4 作好接口管理。
上面說了要作那麼多事情那麼能不能用好而且是持續的用好，接口管理是很是重要的。
接口管理包括：接口版本管理、接口權限管理、接口管控等；

爲何要作接口版本管理？
你們都知道同一個接口隨着產品的不斷迭代、需求的不斷變動均可能面臨接口升級（無論是新增仍是兼容）。可是無論怎麼升級都須要兼容舊的業務使用，爲了管理好就須要經過版本號來解決。例如：在URL中帶上不一樣的版本號，須要使用新特性的能夠調用新版本的接口；不使用新特性的能夠仍然沿用舊版本接口。

爲何要作接口權限管理？
對外發布的接口都須要作權限控制，未受權的服務是不容許訪問的。能夠採用在接口的header參數中加上加密的token做爲權限認證。

後續當整個系統愈來愈龐大複雜後，各微服務發佈的接口須要作可視化管理，包含服務的註冊、發佈、調用、下線都須要在統一的運維平臺上操做。
爲何要作接口管控？
前面提到的接口版本管理對接口不一樣版本的兼容處理是不可能不限支持下去的。發佈舊版本接口的下線公告到期後，若是在監控平臺上發現舊版本接口已無人調用就能夠下線了，若是還有人調用則能夠通知他進行限期整改。

1.4 開始分工寫本身的組件
這樣就能夠分配任務編寫代碼啦。每一個開發人員都是相對獨立的開發，而且接口也定義好了，公共庫也都已經初始化完畢，而後開發就是徹底並行了。編寫完以後，本身的組件能夠依靠單元測試，作一些基本的測試。而後聯調便可。

2 技術框架選擇
來看一下經典的微服務架構圖：

經典的微服務架構圖

主要包含11大核心組件，分別是：

核心支撐組件

• 服務網關Zuul
• 服務註冊發現Eureka+Ribbon
• 服務配置中心Apollo
• 認證受權中心Spring Security OAuth
• 服務框架Spring MVC/Boot

監控反饋組件

• 數據總線Kafka
• 日誌監控ELK
• 調用鏈監控CAT
• Metrics監控KairosDB
• 健康檢查和告警ZMon
• 限流熔斷和流聚合Hystrix/Turbine

看到這裏是否是想說：「尼瑪，這是幾我的小團隊能玩起來的？肯定不是讓咱們996 變 007 嗎？」，我也想說咱們也不是用的這個，通常是給別人吹牛用的，哈哈哈哈！
咱們來看下面這張技術架構圖，你們會好理解許多。

微服務

這張圖大部分業務都通用，根據團隊自身狀況去選擇技術來知足業務需求。

4、總結

仍是那句話，技術棧沒有好壞之分，只有適合一說。本文推薦的技術棧主要基於我我的的實踐和總結，可是未必適合全部場景，畢竟每一個企業的上下文各不相同。做爲架構師你能夠參考我推薦的技術棧，但不可拘泥照搬，你必須在深刻理解分佈系統原理的基礎上，再結合企業實際場景靈活應用。
在整個互聯網基礎技術平臺體系中，還有消息，任務，數據訪問層，發佈系統，容器雲平臺，分佈式事務，分佈式一致性，測試，CI/CD等其它重要主題

最後送上整理的業務架構圖，但願對你們有所幫助！

以爲不錯請點贊支持，歡迎留言或進個人我的羣855801563領取【架構資料專題目合集90期】、【BATJTMD大廠JAVA面試真題1000+】，本羣專用於學習交流技術、分享面試機會，拒絕廣告，我也會在羣內不按期答題、探討。