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

背景

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

設計

微服務開發(fā)架構

只需要有一套BASE微服務，BASE微服務生成業(yè)務系統(tǒng)微服務實例，供各個業(yè)務系統(tǒng)調(diào)用；業(yè)務系統(tǒng)不直接調(diào)用BASE，只能調(diào)用微服務INSTANCE。

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

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

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

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

調(diào)用邏輯

調(diào)用邏輯

• 客戶端調(diào)用業(yè)務系統(tǒng)，不直接調(diào)用微服務；
• 微服務內(nèi)部也存在調(diào)用關系。

設計理念

1. 模塊化是基礎

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

邊模塊化邊微服務

• 松耦合、強內(nèi)聚

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

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

開發(fā)

• 強大而友好的spring體系

java開發(fā)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統(tǒng)一配置中心，用于多環(huán)境的配置文件配置，大家再也不用為多個微服務的開發(fā)、測試與生產(chǎn)環(huán)境的配置文件管理而發(fā)愁了；spring cloud eureka用于服務注冊與發(fā)現(xiàn)，下面有單獨介紹；其它的組件大家可以去官網(wǎng)看看，這里不一一介紹，總之如果JAVA平臺，盡量使用spring體系的內(nèi)容。

• 數(shù)據(jù)庫

我們采用mysql，因為我們是應用多，但數(shù)據(jù)量單表并不算大，多則不超過百萬，mongodb也實驗過，開發(fā)非?？欤卜浅ｌ`活，但因為不是關系型數(shù)據(jù)庫，維護成本較高。

• 權限認證

針對外部校驗，內(nèi)部完全信任機制。

權限認證

• 接口規(guī)范

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

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

• 服務注冊與發(fā)現(xiàn)：eureka

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

服務注冊發(fā)現(xiàn)

• 消息隊列

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

• 異步編程方式

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

• 實時日志分析平臺 ELK

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

• 統(tǒng)一配置中心 ETCD

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

測試

微服務接口測試工具postman

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

部署

微服務的好基友：docker

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

負載均衡利器：docker swarm

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

升級

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

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

• 持續(xù)集成

傳統(tǒng)的版本升級，

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

2.項目經(jīng)理根據(jù)svn審核文件，并打包成war包；

3.投到測試環(huán)境讓測試公司測試；

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

….

我都寫不下去了，項目經(jīng)理像個超人似的。

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

結尾

• 最后說明

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