微服務并不是單獨存在的，為了更好地實現微服務架構，需要整合許多組件混搭使用，方能打通任督二脈，天下無敵。網上很多大拿講了微服務治理的內容，也有人單方面講微服務的，比如spring boot與docker，本文著重于組件選型的較量，也積累了我們團隊多次PK的精華；這些組件包括spring boot、spring cloud、docker、服務注冊發現、RESTFUL、postman、jenkins、ELK、ETCD等。

背景

隨著公司一年多的成長，我們已經開發了數十個項目了，后臺有JAVA的有PHP的，為了更好地提升開發與管理效率，各技術大牛小牛們時常進行激烈的PK，碰撞出了許許多多愛的火花，比如其中之一：微服務實踐。

設計

微服務開發架構

只需要有一套BASE微服務，BASE微服務生成業務系統微服務實例，供各個業務系統調用；業務系統不直接調用BASE，只能調用微服務INSTANCE。

問題一：有些人會問，假如有20個業務系統，那就有上百個微服務，這怎么管理得了？

這是運維的問題，讓運維去解決，運維使用工具，實際也不算困難，反正執行的都是腳本，不需要手工操作。

問題二：為什么不做成一個saas的微服務，這樣就只有不到10個的微服務，就非常容易管理了不是嗎？

單點故障影響全局，我們選擇了穩定更重要；另外saas的話，為了應對不同行業，會存在過度設計的嫌疑；私有化更容易。

調用邏輯

調用邏輯

• 客戶端調用業務系統，不直接調用微服務；
• 微服務內部也存在調用關系。

設計理念

1. 模塊化是基礎

非模塊化，談不上微服務，比如我們上面的用戶微服務、產品微服務、地址微服務等，都需要先模塊化，為了更好地落實開發，你可能不得不，邊模塊化邊微服務，模塊化的時候要注意，不能有關聯查詢，包要完全獨立，到時候微服務才能拆開。

邊模塊化邊微服務

• 松耦合、強內聚

松耦合表示我們模塊之間不直接依賴，無狀態，可以單獨地為外界提供服務；

強內聚是指，我們雖然要拆分成一個個小的微服務，但是也要考慮某些功能的強關聯性，比如一個凳子是由四個腳與一個板組成，我們不能把四個腳與板分開售賣，就沒有意義了。

開發

• 強大而友好的spring體系

java開發5年以上的都非常清楚，很多JAVA框架都淡出了視野，比如hibernate、struts1、struts2，唯有spring越來越受歡迎。

spring-boot:較springmvc更加簡約了，springmvc有一大零的配置文件，比如spring-servlet、spring-mybatis、spring.xml與web.xml，這些在spring-boot都不需要了，只需要強大的注解功能即可，boot更合適微服務。

spring-cloud:里面有比較多組件，用于支持微服務，比如spring cloud config統一配置中心，用于多環境的配置文件配置，大家再也不用為多個微服務的開發、測試與生產環境的配置文件管理而發愁了；spring cloud eureka用于服務注冊與發現，下面有單獨介紹；其它的組件大家可以去官網看看，這里不一一介紹，總之如果JAVA平臺，盡量使用spring體系的內容。

• 數據庫

我們采用mysql，因為我們是應用多，但數據量單表并不算大，多則不超過百萬，mongodb也實驗過，開發非常快，也非常靈活，但因為不是關系型數據庫，維護成本較高。

• 權限認證

針對外部校驗，內部完全信任機制。

權限認證

• 接口規范

RESTFUL：URL的資源與操作解耦，讓URL更加符合語義，上百個接口也非常好管理，網上有很多文章講得非常透徹，這玩意不是特別好理解，要多領悟，在項目中實踐，就有矛塞盾開的感覺，這里不做詳細介紹。

接口文檔swagger：比起傳統全手工寫接口文檔，swagger有統一的輸出格式，不管是幾個人寫的；swagger采用寫代碼的方式來寫接口文檔，以前修改了代碼，還必須打開wiki手工修改接口文檔，現在只需要修改一下代碼即可，程序員更愿意修改了，成本更低了，前端與其它調用者不會天天吼著，你這接口咋又變了，新加的字段是啥意思呀。

• 服務注冊與發現：eureka

服務接口改變后，再也不需要口頭通知服務調用者了，因為調用者太多，你根本不知道他是誰，難免遺漏；可支持PHP。

服務注冊發現

• 消息隊列

RocketMQ：一直糾結kafka與rocketMQ，最終選擇了RocketMQ

• 異步編程方式

為了性能上面的考慮，盡量使用異步編程，比如注冊送優惠券，那么注冊成功就可以給用戶返回注冊成功了，但是送優惠券可以是異步調用的，不阻塞注冊的線程。

• 實時日志分析平臺 ELK

微服務框架下，日志不可能還分散在各個服務節點上，必須有統一的日志中心。ELK是一個實時日志分析平臺，就是將各個服務的日志匯總于日志中心，然后可以按照系統、節點等進行搜索，除上述搜索條件外，我們還在各個微服務實現了按照業務id（一次請求生成一個業務id）與用戶id搜索日志，方便跟蹤與定位問題。

• 統一配置中心 ETCD

當然可能有更加輕量級與好用的disconf或spring cloud config，但是我們有php開發的應用，以上二者都不支持。如果全是JAVA應用，采用disconf還是非常不錯的。

測試

微服務接口測試工具postman

每個程序員都有這樣的經歷，剛上線，客戶又反饋了bug，原來是我們修改某個功能代碼的時候，導致了其它功能的bug，每次上線心里都沒底；這就體現了接口測試的必須性，尤其是每次版本升級的時候，都需要執行一遍，以防修改某個接口導致其它接口報錯，比手動測試靠譜許多。

部署

微服務的好基友：docker

docker已經家喻戶曉了，這是繼虛擬機以后，又一重大變革，將所有的單個微服務都放在docker中，這樣你何時何地想部署，直接丟過去就OK了，快到爆。

負載均衡利器：docker swarm

用幾句簡單的命令就搞定了負載均衡，而且還可以平滑升級，版本升級的時候，大家就不用告訴客戶：系統通知，某日某晚00:00-08:00我行處于系統升級維護中，大家不要去取錢哦，因為你可能取不出來，呵呵。

升級

• 數據庫升級
• 升級前對數據庫做物理或邏輯備份
• 數據庫腳本不能含有刪除或修改表與數據的語句，防止升級過程中舊業務報錯
• 所有腳本上線前運維人員必須check，一些敏感詞drop或delete

我們采用工具flyway，可以對數據庫腳本進行版本控制。

• 持續集成

傳統的版本升級，

1.開發推代碼并同時記錄自己提交了哪些文件；

2.項目經理根據svn審核文件，并打包成war包；

3.投到測試環境讓測試公司測試；

4.中途修改了文件，可能需要重新打包；

….

我都寫不下去了，項目經理像個超人似的。

現在用持續集成（CI）非常簡單，我們用的工具是Jenkins，推完代碼，點幾下按鈕就完成了上線，不管是測試環境，還是生產環境都非常簡單，不然項目經理核對文件眼睛都綠了。

結尾

• 最后說明

本文主要是介紹微服務開發上的選型，對于細則不做深究，大家感興趣可以了解下各個組件。當然，我們的選型未免正確，不同場景應用可能完全不同，本文僅供參考。