微服務並不是單獨存在的，為了更好地實現微服務架構，需要整合許多組件混搭使用，方能打通任督二脈，天下無敵。網上很多大拿講了微服務治理的內容，也有人單方面講微服務的，比如spring boot與docker，本文著重於組件選型的較量，也積累了我們團隊多次PK的精華；這些組件包括spring boot、spring cloud、docker、服務註冊發現、RESTFUL、postman、jenkins、ELK、ETCD等。
背景
隨著公司一年多的成長，我們已經開發了數十個項目了，後臺有JAVA的有PHP的，為了更好地提升開發與管理效率，各技術大牛小牛們時常進行激烈的PK，碰撞出了許許多多愛的火花，比如其中之一：微服務實踐
設計
微服務開發架構.png
只需要有一套BASE微服務，BASE微服務生成業務系統微服務實例，供各個業務系統調用；業務系統不直接調用BASE，只能調用微服務INSTANCE。
問題一：有些人會問，假如有20個業務系統，那就有上百個微服務，這怎麼管理得了？
這是運維的問題，讓運維去解決，運維使用工具，實際也不算困難，反正執行的都是腳本，不需要手工操作。
問題二：為什麼不做成一個saas的微服務，這樣就只有不到10個的微服務，就非常容易管理了不是嗎？
單點故障影響全局，我們選擇了穩定更重要；另外saas的話，為了應對不同行業，會存在過度設計的嫌疑；私有化更容易。
調用邏輯
調用邏輯.png
- 客戶端調用業務系統，不直接調用微服務；
- 微服務內部也存在調用關係。
設計理念
1. 模塊化是基礎
非模塊化，談不上微服務，比如我們上面的用戶微服務、產品微服務、地址微服務等，都需要先模塊化，為了更好地落實開發，你可能不得不，邊模塊化邊微服務，模塊化的時候要注意，不能有關聯查詢，包要完全獨立，到時候微服務才能拆開。
邊模塊化邊微服務.png
- 鬆耦合、強內聚
鬆耦合表示我們模塊之間不直接依賴，無狀態，可以單獨地為外界提供服務；
強內聚是指，我們雖然要拆分成一個個小的微服務，但是也要考慮某些功能的強關聯性，比如一個凳子是由四個腳與一個板組成，我們不能把四個腳與板分開售賣，就沒有意義了。
開發
- 強大而友好的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也實驗過，開發非常快，也非常靈活，但因為不是關係型數據庫，維護成本較高。
- 權限認證
針對外部校驗，內部完全信任機制。
權限認證.png
- 接口規範
RESTFUL：URL的資源與操作解耦，讓URL更加符合語義，上百個接口也非常好管理，網上有很多文章講得非常透徹，這玩意不是特別好理解，要多領悟，在項目中實踐，就有矛塞盾開的感覺，這裡不做詳細介紹。
接口文檔swagger：比起傳統全手工寫接口文檔，swagger有統一的輸出格式，不管是幾個人寫的；swagger採用寫代碼的方式來寫接口文檔，以前修改了代碼，還必須打開wiki手工修改接口文檔，現在只需要修改一下代碼即可，程序員更願意修改了，成本更低了，前端與其它調用者不會天天吼著，你這接口咋又變了，新加的字段是啥意思呀。
- 服務註冊與發現：eureka
服務接口改變後，再也不需要口頭通知服務調用者了，因為調用者太多，你根本不知道他是誰，難免遺漏；可支持PHP。
服務註冊發現.png
- 消息隊列
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，推完代碼，點幾下按鈕就完成了上線，不管是測試環境，還是生產環境都非常簡單，不然項目經理核對文件眼睛都綠了。
結尾
- 最後說明
本文主要是介紹微服務開發上的選型，對於細則不做深究，大家感興趣可以瞭解下各個組件。當然，我們的選型未免正確，不同場景應用可能完全不同，本文僅供參考。