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

背景

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

設(shè)計(jì)

微服務(wù)開發(fā)架構(gòu)

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

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

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

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

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

調(diào)用邏輯

調(diào)用邏輯

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

設(shè)計(jì)理念

1. 模塊化是基礎(chǔ)

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

邊模塊化邊微服務(wù)

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

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

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

開發(fā)

• 強(qiáng)大而友好的spring體系

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

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

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

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

我們采用mysql，因?yàn)槲覀兪菓?yīng)用多，但數(shù)據(jù)量單表并不算大，多則不超過百萬，mongodb也實(shí)驗(yàn)過，開發(fā)非?？?，也非常靈活，但因?yàn)椴皇顷P(guān)系型數(shù)據(jù)庫，維護(hù)成本較高。

• 權(quán)限認(rèn)證

針對(duì)外部校驗(yàn)，內(nèi)部完全信任機(jī)制。

權(quán)限認(rèn)證

• 接口規(guī)范

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

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

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

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

服務(wù)注冊(cè)發(fā)現(xiàn)

• 消息隊(duì)列

RocketMQ：一直糾結(jié)kafka與rocketMQ，最終選擇了RocketMQ

• 異步編程方式

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

• 實(shí)時(shí)日志分析平臺(tái) ELK

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

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

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

測(cè)試

微服務(wù)接口測(cè)試工具postman

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

部署

微服務(wù)的好基友：docker

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

負(fù)載均衡利器：docker swarm

用幾句簡(jiǎn)單的命令就搞定了負(fù)載均衡，而且還可以平滑升級(jí)，版本升級(jí)的時(shí)候，大家就不用告訴客戶：系統(tǒng)通知，某日某晚00:00-08:00我行處于系統(tǒng)升級(jí)維護(hù)中，大家不要去取錢哦，因?yàn)槟憧赡苋〔怀鰜恚呛恰?/p>

升級(jí)

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

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

• 持續(xù)集成

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

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

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

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

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

….

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

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

結(jié)尾

• 最后說明

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