• 寫在前面的話：

本文是假定自建微服務(wù)基礎(chǔ)架構(gòu)，有些產(chǎn)品其實(shí)有對(duì)應(yīng)的云服務(wù)可以直接使用，比如直接用開源的Spring Cloud等。自建和采用云服務(wù)各有利弊，架構(gòu)師需要根據(jù)場(chǎng)景上下文綜合權(quán)衡。
搬磚不易，希望能得到友情三連。如果有大佬想轉(zhuǎn)載，轉(zhuǎn)載記得附出處哈！

一、選型準(zhǔn)則

1、成熟穩(wěn)定抗流量

我們選擇的技術(shù)棧一定是能上生產(chǎn)，能解決實(shí)際業(yè)務(wù)上產(chǎn)生的問題，而不是簡(jiǎn)單的做一個(gè)DEMO，這樣容易由于實(shí)際業(yè)務(wù)中一些不可控因素導(dǎo)致生產(chǎn)級(jí)的事故。所以，生產(chǎn)級(jí)、可運(yùn)維級(jí)、可治理級(jí)等成熟穩(wěn)定的技術(shù)才是我們的首選。

2、選擇一線互聯(lián)網(wǎng)落地的產(chǎn)品

盡量采用在一線互聯(lián)網(wǎng)公司落地并且開源的，且在社區(qū)內(nèi)形成良好口碑的產(chǎn)品。它們已經(jīng)在這些公司經(jīng)過流量沖擊，坑已經(jīng)基本被填平，且被社區(qū)接受形成一個(gè)良好的社區(qū)生態(tài)。先謀發(fā)展，再求突破?。ū疚母戒洸糠謺?huì)給出所有推薦使用或參考的開源項(xiàng)目的github鏈接）

3、社區(qū)開源且活躍度高

Github上的stars的數(shù)量是一個(gè)重要指標(biāo)，同時(shí)會(huì)參考其代碼和文檔更新頻率（尤其是近年），這些指標(biāo)直接反應(yīng)開源產(chǎn)品的社區(qū)活躍度或者說生命力。如果引入的技術(shù)沒有跟隨時(shí)代的步伐迭代，那么我們可以尋找新技術(shù)，拋棄這個(gè)舊技術(shù)。因?yàn)槟銜?huì)發(fā)現(xiàn)，當(dāng)你引入的是一個(gè)社區(qū)活躍度不高的技術(shù)，你在出現(xiàn)bug、出現(xiàn)生產(chǎn)事故的時(shí)候，你是沒辦法從社區(qū)里面快速的得到解決方法，只能自己搞定這個(gè)坑。這點(diǎn)特別重要，但是很多人會(huì)忽視。

另外，對(duì)于不同業(yè)務(wù)體量和團(tuán)隊(duì)規(guī)模的公司，技術(shù)選型標(biāo)準(zhǔn)往往是不同的，創(chuàng)業(yè)公司的技術(shù)選型和BAT級(jí)別公司的技術(shù)選型標(biāo)準(zhǔn)可能完全不同。
本文主要針對(duì)日流量千萬(wàn)以上的。如果研發(fā)團(tuán)隊(duì)規(guī)模不少于50人的公司，如果小于這個(gè)規(guī)模我建議認(rèn)真評(píng)估是否真的需要采用微服務(wù)架構(gòu)，而不是盲目的跟風(fēng)做去分布式。講道理，有這個(gè)時(shí)間和經(jīng)費(fèi)還不如想著怎么樣把產(chǎn)品運(yùn)營(yíng)好，畢竟賺錢才是王道！

二、微服務(wù)基礎(chǔ)架構(gòu)的核心

微服務(wù)基礎(chǔ)架構(gòu).png

以上是我認(rèn)為微服務(wù)基礎(chǔ)架構(gòu)的幾個(gè)核心模塊，本文也會(huì)針對(duì)這幾個(gè)核心的模塊去展開分析。在針對(duì)具體產(chǎn)品做技術(shù)選型時(shí)，我希望大家可以盡可能覆蓋到這些關(guān)注點(diǎn)。

下圖是我在參考過華為技術(shù)專家王磊的《微服務(wù)的設(shè)計(jì)與生態(tài)系統(tǒng)》的基礎(chǔ)上，結(jié)合自身的實(shí)踐和理解調(diào)整而來(lái)，希望大家在做技術(shù)選型時(shí)，可以同時(shí)一起對(duì)照一下這個(gè)體系。

微服務(wù)技術(shù)體系.png

三、三種主流服務(wù)框架選型

SpringCloud

由于Spring社區(qū)的影響力和Netflix的背書，目前可以認(rèn)為是構(gòu)建Java微服務(wù)的一個(gè)社區(qū)標(biāo)準(zhǔn)?；赟pring的框架本質(zhì)上可以認(rèn)為是一種RESTful框架（不是RPC框架），序列化協(xié)議主要采用基于文本的JSON，通訊協(xié)議一般基于HTTP。RESTful框架天然支持跨語(yǔ)言，任何語(yǔ)言只要有HTTP客戶端都可以接入調(diào)用，但是客戶端一般需要自己解析payload。目前Spring框架也支持Swagger契約編程模型，能夠基于契約生成各種語(yǔ)言的強(qiáng)類型客戶端，極大方便不同語(yǔ)言棧的應(yīng)用接入，但是因?yàn)镽ESTful框架和Swagger規(guī)范的弱契約特性，生成的各種語(yǔ)言客戶端的互操作性還是有不少坑的。

優(yōu)點(diǎn)

• Netflix背書
• 社區(qū)非常活躍
• 基于SpringBoot，配置簡(jiǎn)單，快速開發(fā)，部署輕松，方便測(cè)試等
• 集成了各種微服務(wù)組件，滿足了構(gòu)建微服務(wù)架構(gòu)需要的所有解決方案，開發(fā)風(fēng)險(xiǎn)小
• 適用于輕量級(jí)的微服務(wù)架構(gòu)

缺點(diǎn)

• JVM only
• 運(yùn)行消耗資源性能，網(wǎng)絡(luò)

Dubbo

Dubbo是阿里多年構(gòu)建生產(chǎn)級(jí)分布式微服務(wù)的技術(shù)結(jié)晶，服務(wù)治理能力非常豐富，在國(guó)內(nèi)技術(shù)社區(qū)具有很大影響力。Dubbo本質(zhì)上是一套基于Java的RPC框架，當(dāng)當(dāng)Dubbox擴(kuò)展了Dubbo支持RESTful接口暴露能力。Dubbo主要面向Java 技術(shù)棧，跨語(yǔ)言支持不足是它的一個(gè)弱項(xiàng)，另外因?yàn)橹卫砟芰μS富，以至于這個(gè)框架比較重，完全用好這個(gè)框架的門檻比較高，但是如果你的企業(yè)基本上投資在Java技術(shù)棧上，選Dubbo可以讓你在服務(wù)框架一塊站在較高的起點(diǎn)上，不管是性能還是企業(yè)級(jí)的服務(wù)治理能力，Dubbo都做的很出色。新浪微博開源的Motan（github 4k stars）也不錯(cuò)，功能和Dubbo類似，可以認(rèn)為是一個(gè)輕量裁剪版的Dubbo。但是實(shí)際上，Dubbo的關(guān)注點(diǎn)在于服務(wù)治理，并不能算是一個(gè)真正的微服務(wù)框架！

優(yōu)點(diǎn)

• 阿里背書
• 成熟穩(wěn)定
• RPC高性能調(diào)用
• 具有調(diào)度、發(fā)現(xiàn)、監(jiān)控、治理等功能，相當(dāng)豐富的服務(wù)治理能力

缺點(diǎn)

• 復(fù)雜度高，重量級(jí)
• JVM only
• 耦合性高
• 國(guó)外社區(qū)小

K8s

Kubernetes（簡(jiǎn)稱k8s）是Google在2014年6月開源的一個(gè)容器集群管理系統(tǒng)，使用Go語(yǔ)言開發(fā)，用于管理云平臺(tái)中多個(gè)主機(jī)上的容器化的應(yīng)用，Kubernetes的目標(biāo)是讓部署容器化的應(yīng)用簡(jiǎn)單并且高效，Kubernetes提供了資源調(diào)度、部署管理、服務(wù)發(fā)現(xiàn)、擴(kuò)容縮容、監(jiān)控，維護(hù)等一整套功能。努力成為跨主機(jī)集群的自動(dòng)部署、擴(kuò)展以及運(yùn)行應(yīng)用程序容器的平臺(tái)。 它支持一系列容器工具, 包括Docker等。故障遷移、資源調(diào)度、資源隔離、采用docker容器，進(jìn)程之間互不影響、安全、快速精準(zhǔn)地部署應(yīng)用程序、負(fù)載均衡等特點(diǎn)。

優(yōu)點(diǎn)

• 谷歌背書
• 社區(qū)活躍
• 平臺(tái)抽象
• 全面覆蓋的服務(wù)關(guān)注點(diǎn)（發(fā)布）
• 語(yǔ)言棧無(wú)關(guān)

缺點(diǎn)

• 偏DevOps和運(yùn)維
• 重量復(fù)雜
• 技術(shù)門檻高

四、后臺(tái)服務(wù)選型

后臺(tái)服務(wù)主要包括消息系統(tǒng)，分布式緩存，分布式數(shù)據(jù)訪問層和任務(wù)調(diào)度系統(tǒng)。后臺(tái)服務(wù)是一個(gè)相對(duì)比較成熟的領(lǐng)域。很多開源產(chǎn)品基本可以開箱即使用。

消息系統(tǒng)

對(duì)于日志等可靠性要求不高的場(chǎng)景，則Apache頂級(jí)項(xiàng)目Kafka是社區(qū)標(biāo)配?？赡苡行?duì)可靠性要求比較高的業(yè)務(wù)場(chǎng)景，可能就有些會(huì)用阿里開源的RocketMQ。如果硬是要用kafka去處理一些需要高可用的場(chǎng)景，那建議就是在對(duì)kafka的監(jiān)控和治理能力上進(jìn)行適當(dāng)?shù)耐晟??？梢詤⒖糰llegro公司開源的hermes項(xiàng)目。除此之外，老牌的RabbitMQ也是可以考慮一下的，文檔也特別完善，適用中小規(guī)模場(chǎng)景可選。

緩存治理

如果傾向于采用客戶端直連模式（個(gè)人認(rèn)為緩存直連更簡(jiǎn)單輕量），則SohuTV開源的cachecloud是一款不錯(cuò)的Redis服務(wù)治理平臺(tái)，提供諸如監(jiān)控統(tǒng)計(jì)，一鍵開啟，自動(dòng)故障轉(zhuǎn)移，在線伸縮，自動(dòng)化運(yùn)維等生產(chǎn)級(jí)治理能力，另外其文檔也比較豐富。如果傾向采用中間層Proxy模式，則Twitter開源的twemproxy和CodisLab開源的codis是社區(qū)比較熱的選項(xiàng)。

分布式數(shù)據(jù)訪問層

如果采用Java技術(shù)棧，當(dāng)當(dāng)開源的shardingjdbc是一個(gè)不錯(cuò)的選項(xiàng)，分庫(kù)分表邏輯在客戶端jdbc driver中，客戶端直連數(shù)據(jù)庫(kù)比較簡(jiǎn)單輕量，建議中小規(guī)模場(chǎng)景采用這種方式。如果傾向采用數(shù)據(jù)庫(kù)訪問層proxy模塊，那么阿里的分庫(kù)分表中間件MyCAT是一個(gè)不錯(cuò)選擇。proxy模塊運(yùn)維成本較高，建議中大規(guī)模場(chǎng)景，有一定框架自研和運(yùn)維能力的團(tuán)隊(duì)選型采用。

任務(wù)調(diào)度系統(tǒng)

個(gè)人推薦徐雪里開源的xxl-job，部署簡(jiǎn)單輕量，大部分場(chǎng)景夠用。當(dāng)當(dāng)開源的elastic-job也是一個(gè)不錯(cuò)選擇，相比xxl-job功能更強(qiáng)一些也更復(fù)雜。

五、運(yùn)行時(shí)支撐服務(wù)選型

運(yùn)行時(shí)支撐服務(wù)主要包括服務(wù)路由網(wǎng)關(guān)、服務(wù)注冊(cè)中心，和集中式配置中心三個(gè)模塊。

服務(wù)網(wǎng)關(guān)

是一個(gè)比較成熟的領(lǐng)域。如果采用springcloud那一套，那么選擇Zuul是最佳搭配。Zuul在Netflix經(jīng)過大規(guī)模生產(chǎn)驗(yàn)證，支持靈活的動(dòng)態(tài)過濾器腳本機(jī)制，但是異步的性能不足，也是spring cloud的短板之一，希望后續(xù)基于Netty的異步Zuul可以推出正式版，那就真的無(wú)敵了。還有一款最近特別火的基于Ngnix/OpenResty的API網(wǎng)關(guān)Kong，因?yàn)椴捎肗gnix內(nèi)核，Kong的一部性能較強(qiáng)，另外lua的插件機(jī)制也比較靈活，社區(qū)插件也豐富，從安全到限流熔斷都有，也有不少開源的管理界面，能集中管理Kong集群。

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

如果采用Spring Cloud體系，則選擇Eureka是最佳搭配，Eureka在Netflix經(jīng)過大規(guī)模生產(chǎn)驗(yàn)證，支持跨數(shù)據(jù)中心，客戶端配合Ribbon可以實(shí)現(xiàn)靈活的客戶端軟負(fù)載。Consul也是不錯(cuò)選擇，天然支持跨數(shù)據(jù)中心，還支持KV模型存儲(chǔ)和靈活健康檢查能力。

配置中心

如果采用Spring Cloud體系，則可以選擇Spring Cloud Config，不過個(gè)人并不推薦。因?yàn)樗悬c(diǎn)算不上生產(chǎn)級(jí)，很多治理能力缺失，小規(guī)模的場(chǎng)景可以試用。個(gè)人強(qiáng)力推薦Apollo配置中心，是攜程推出的，也是經(jīng)過了攜程大規(guī)模的生產(chǎn)驗(yàn)證，具備高可用，配置實(shí)時(shí)生效（推拉結(jié)合），配置審計(jì)，分環(huán)境部署和版本化。

六、服務(wù)安全選型

對(duì)于服務(wù)安全這塊，目前業(yè)界雖然有OAuth和OpenID connect等標(biāo)準(zhǔn)協(xié)議，但是由于企業(yè)一般都會(huì)有很多特殊的定制需求，整個(gè)社區(qū)沒有形成通用的生產(chǎn)級(jí)開箱即用的產(chǎn)品。有一些開源授權(quán)服務(wù)器產(chǎn)品，比如：CAS、keycloak，spring security等，但是兼容性太差，缺乏靈活性。個(gè)人建議基于OAuth和OpenID connect標(biāo)準(zhǔn)，在參考一些開源產(chǎn)品的基礎(chǔ)上（例如Mitre開源的 OpenID-Connect-Java-Spring-Server），定制自研輕量級(jí)授權(quán)服務(wù)器。
整塊服務(wù)安全可以這樣選型：

• 使用支持OAuth 2.0和OpenID connect標(biāo)準(zhǔn)協(xié)議的授權(quán)服務(wù)器（個(gè)人建議定制自研）；
• 客戶端在訪問微服務(wù)之前，先通過授權(quán)服務(wù)器登錄獲取access token，然后帶著access token和請(qǐng)求一起發(fā)送到API網(wǎng)關(guān)
• API網(wǎng)關(guān)一般是作為單一請(qǐng)求訪問服務(wù)器入口，實(shí)現(xiàn)統(tǒng)一安全治理；
• API網(wǎng)關(guān)拿access token，通過授權(quán)服務(wù)器校驗(yàn)token，同時(shí)做token轉(zhuǎn)換獲取JWT token。
• API網(wǎng)關(guān)將JWT Token和請(qǐng)求一起轉(zhuǎn)發(fā)到后臺(tái)微服務(wù)；
• JWT中會(huì)存儲(chǔ)一些用戶的會(huì)話信息，該信息可以傳遞給后臺(tái)的微服務(wù)，也可以在微服務(wù)之間傳遞，作為認(rèn)證授權(quán)等用途；
• 每個(gè)微服務(wù)包含JWT客戶端，能夠解密JWT并獲取其中的用戶會(huì)話信息。
  整個(gè)方案中，access token是一種by reference token，不包含用戶信息可以暴露在公網(wǎng)上；JWT token是一種by value token，包含用戶信息但不可以暴露在公網(wǎng)上。

七、服務(wù)容災(zāi)選型

針對(duì)Java技術(shù)棧，Netflix的Hystrix把熔斷、隔離、限流和降級(jí)等能力封裝成組件，任何依賴調(diào)用（數(shù)據(jù)庫(kù)，服務(wù)，緩存）都可以封裝在Hystrix Command之內(nèi)，封裝后自動(dòng)具備容錯(cuò)能力。Hystrix起源于Netflix，經(jīng)過Netflix大規(guī)模生產(chǎn)驗(yàn)證，目前是容錯(cuò)組件的社區(qū)標(biāo)準(zhǔn)。
Hystrix一般需要在應(yīng)用端或者框架內(nèi)埋點(diǎn)，有一定的使用門檻。對(duì)于采用集中式反向代理（邊界和內(nèi)部）做服務(wù)路由的公司，則可以集中在反向代理上做熔斷限流，例如采用 nginx [附錄12.25]（github 5.1k stars）或者 Kong [附錄12.7]（github 11.4k stars）這類反向代理，它們都有插件支持靈活的限流容錯(cuò)配置。Zuul網(wǎng)關(guān)也可以集成Hystrix實(shí)現(xiàn)網(wǎng)關(guān)層集中式限流容錯(cuò)。集中式反向代理需要有一定的研發(fā)和運(yùn)維能力，但是可以對(duì)限流容錯(cuò)進(jìn)行集中治理，可以簡(jiǎn)化客戶端。
Hystrix一般需要在應(yīng)用端或者框架內(nèi)埋點(diǎn)，有一定的使用門檻。對(duì)于采用集中式反向代理（邊界和內(nèi)部）做服務(wù)路由的公司，則可以集中在反向代理上做熔斷限流，例如采用 nginx 或者 Kong 這類反向代理，它們都有插件支持靈活的限流容錯(cuò)配置。Zuul網(wǎng)關(guān)也可以集成Hystrix實(shí)現(xiàn)網(wǎng)關(guān)層集中式限流容錯(cuò)。集中式反向代理需要有一定的研發(fā)和運(yùn)維能力，但是可以對(duì)限流容錯(cuò)進(jìn)行集中治理，可以簡(jiǎn)化客戶端。

八、服務(wù)監(jiān)控選型

這塊主要包括日志監(jiān)控、調(diào)用鏈監(jiān)控。健康檢查和告警通知等產(chǎn)品。

日志監(jiān)控

ELK目前可以認(rèn)為是日志監(jiān)控的標(biāo)配。功能開箱即用，且在Elastalert里面還加入了告警通知模塊。

調(diào)用鏈監(jiān)控

目前社區(qū)主流的應(yīng)該是美團(tuán)點(diǎn)評(píng)的CAT，Twitter之前開源的Zipkin可以考慮一下。本人推薦美團(tuán)點(diǎn)評(píng)開源的CAT，在多家公司都有經(jīng)歷生產(chǎn)級(jí)的磨練，另外CAT自帶告警模塊?？梢钥匆幌乱幌聦?duì)比的表格：

健康檢查和告警

社區(qū)比較火的是Sensu，能夠應(yīng)對(duì)各種服務(wù)（例如spring boot暴露的健康檢查端點(diǎn)，時(shí)間序列數(shù)據(jù)庫(kù)中的metrics，ELK中的錯(cuò)誤日志等）定制靈活的健康檢查機(jī)制（check），然后用戶可以針對(duì)check結(jié)果設(shè)置靈活的告警通知策略。同樣的產(chǎn)品還有Esty和ZMon，但是定制check和告警配置的使用門檻比較高，社區(qū)不熱，建議有定制自研能力的團(tuán)隊(duì)試用。

九、服務(wù)部署選型

容器已經(jīng)被社區(qū)接受為交付微服務(wù)的一種理想手段，可以實(shí)現(xiàn)不可變（immutable）發(fā)布模式。一個(gè)輕量級(jí)的基于容器的服務(wù)部署平臺(tái)主要包括系統(tǒng)發(fā)布平臺(tái)，容器調(diào)度平臺(tái)，鏡像治理，用戶資源治理和IAM等模塊。

系統(tǒng)發(fā)布平臺(tái)

面向用戶發(fā)布管理控制臺(tái)，支持發(fā)布流程編排，串并行發(fā)布皆可設(shè)置，它和其他子系統(tǒng)對(duì)接交互，實(shí)現(xiàn)基本的應(yīng)用發(fā)布能力，也能實(shí)現(xiàn)藍(lán)綠部署、金絲雀（灰度）部署、滾動(dòng)部署等高級(jí)發(fā)布機(jī)制。這里簡(jiǎn)要介紹一下這三種部署機(jī)制：

• 藍(lán)綠部署

藍(lán)綠部署是不停老版本，部署新版本然后進(jìn)行測(cè)試，確認(rèn)OK，將流量切到新版本，然后老版本同時(shí)也升級(jí)到新版本。
無(wú)需停機(jī)，風(fēng)險(xiǎn)較小，新版本在上線的過程沒有修改老版本的內(nèi)容，所以在部署期間，老版本的狀態(tài)不受影響。

• 滾動(dòng)部署

滾動(dòng)部署一般是取出一個(gè)或者多個(gè)服務(wù)器停止服務(wù)，執(zhí)行更新，并重新將其投入使用。周而復(fù)始，直到集群中所有實(shí)例都更新到新版本。
相對(duì)藍(lán)綠版本的好處是更加節(jié)省資源，不需要去維護(hù)兩套集群、兩倍的實(shí)例數(shù)，可以部分部署，例如每次只取出集群中的百分之20進(jìn)行升級(jí)。缺點(diǎn)也很多：
(1) 沒有一個(gè)確定OK的環(huán)境。使用藍(lán)綠部署，我們能夠清晰地知道老版本是OK的，而使用滾動(dòng)發(fā)布，我們無(wú)法確定。
(2) 修改了現(xiàn)有的環(huán)境。
(3) 如果需要回滾，很困難。舉個(gè)例子，在某一次發(fā)布中，我們需要更新100個(gè)實(shí)例，每次更新10個(gè)實(shí)例，每次部署需要5分鐘。當(dāng)滾動(dòng)發(fā)布到第80個(gè)實(shí)例時(shí)，發(fā)現(xiàn)了問題，需要回滾，這個(gè)回滾卻是一個(gè)痛苦，并且漫長(zhǎng)的過程。
(4) 因?yàn)槭侵鸩礁?，那么我們?cè)谏暇€代碼的時(shí)候，就會(huì)短暫出現(xiàn)新老版本同時(shí)并存的情況，如果對(duì)上線要求較高的場(chǎng)景，那么就需要考慮如何做好兼容的問題。

• 灰度發(fā)布/金絲雀部署

灰度發(fā)布是指在黑與白之間，能夠平滑過渡的一種發(fā)布方式。
AB test就是一種灰度發(fā)布方式，用nginx或者網(wǎng)關(guān)，切一部分用戶繼續(xù)用A，一部分用戶開始用B。如果用戶對(duì)B沒有什么反對(duì)意見，那么逐步擴(kuò)大范圍，把所有用戶都遷移到B上面來(lái)。
灰度發(fā)布可以保證整體系統(tǒng)的穩(wěn)定，在初始灰度的時(shí)候就可以發(fā)現(xiàn)、調(diào)整問題，以保證其影響度，而我們平常所說的金絲雀部署也就是灰度發(fā)布的一種方式。
除此之外灰度發(fā)布還可以設(shè)置路由權(quán)重，動(dòng)態(tài)調(diào)整不同的權(quán)重來(lái)進(jìn)行新老版本的驗(yàn)證。

容器調(diào)度平臺(tái)

屏蔽底層的容器系統(tǒng)，將容器集群抽象成容器資源池，支持按需申請(qǐng)和釋放容器資源，多種腳本語(yǔ)言同時(shí)運(yùn)行不會(huì)出現(xiàn)數(shù)據(jù)安全問題，物理機(jī)發(fā)生故障時(shí)能實(shí)現(xiàn)自動(dòng)遷移。目前谷歌開源的Kubernetes，即K8s，在谷歌背書和社區(qū)的強(qiáng)力推動(dòng)下，基本上已經(jīng)形成龍頭型產(chǎn)品了 。其他還有mesos和swarm，不過不具競(jìng)爭(zhēng)力了。

鏡像治理

基于docker registry，封裝一些輕量級(jí)的治理功能。vnware開源的harbor是目前社區(qū)比較成熟的企業(yè)級(jí)產(chǎn)品，在docker registy基礎(chǔ)上拓展了權(quán)限控制，審計(jì)，鏡像同步，管理界面等治理能力，可以考慮采用。

用戶資源治理

類似CMDB的思路，在容器集群中也應(yīng)該要有一個(gè)configuration manage去管理應(yīng)用app，組織org，容器配置和數(shù)量等相關(guān)信息的輕量級(jí)治理產(chǎn)品。目前這塊還沒有開源的生產(chǎn)級(jí)產(chǎn)品，需要企業(yè)自研。

考慮到服務(wù)部署平臺(tái)還沒有端到端的生產(chǎn)級(jí)解決方案，企業(yè)一般需要自己定制方案集成，下面給出一個(gè)可供參考的輕量級(jí)部署平臺(tái)的發(fā)布體系：（建議反復(fù)閱讀）

1、應(yīng)用通過CI集成后生成鏡像，用戶將鏡像推到 鏡像治理中心①。
2、用戶在 用戶資源治理中心② 申請(qǐng)發(fā)布，填報(bào)應(yīng)用，發(fā)布，發(fā)布配置等信息，并等待審批通過。
3、審批等過，開發(fā)人員通過 發(fā)布控制臺(tái)③ 發(fā)布應(yīng)用。
4、服務(wù)部署平臺(tái)通過 用戶資源治理中心② 可以查詢到發(fā)布規(guī)格信息。
5、發(fā)布控制臺(tái)向 容器云④ 發(fā)送啟動(dòng)容器實(shí)例指令。
6、容器云④ 從 鏡像治理中心① 拉取鏡像并啟動(dòng)容器。
7、容器云中的服務(wù)啟動(dòng)后自動(dòng)注冊(cè)到 服務(wù)注冊(cè)中心⑤ ，并定期保持心跳長(zhǎng)連接。
8、用戶通過 發(fā)布控制臺(tái)③ 調(diào)用 服務(wù)注冊(cè)中心⑤ 調(diào)撥流量，實(shí)現(xiàn)藍(lán)綠部署、金絲雀（灰度）部署、滾動(dòng)部署等發(fā)布機(jī)制。
9、網(wǎng)關(guān)⑥ 和 內(nèi)部的微服務(wù)⑦ 定期的去 服務(wù)注冊(cè)中心⑤ 上拉取最新的服務(wù)路由表，將流量按負(fù)載均衡策略分發(fā)到 容器云④ 上的新微服務(wù)實(shí)例上。

十、寫在后面的話

注意，本文限于篇幅，對(duì)測(cè)試和CI等環(huán)節(jié)沒有涉及，但它們同樣是構(gòu)建微服務(wù)架構(gòu)的重要環(huán)節(jié)，也有眾多成熟的開源成熟產(chǎn)品可選。

技術(shù)選型雖然重要，但還只是微服務(wù)建設(shè)的一小部分工作，選型后的產(chǎn)品要在企業(yè)內(nèi)部真正落地，形成完整的微服務(wù)技術(shù)棧體系，則后續(xù)還有大量集成、定制、治理、運(yùn)維和推廣等工作。

本文僅限個(gè)人經(jīng)驗(yàn)視角，選型思路僅供參考借鑒。每個(gè)企業(yè)的具體上下文（業(yè)務(wù)場(chǎng)景，團(tuán)隊(duì)組織，技術(shù)架構(gòu)等）各不相同，每個(gè)架構(gòu)師的背景經(jīng)驗(yàn)也各不相同，大家要結(jié)合實(shí)際自己做出選型，沒有最好的技術(shù)棧，只有相對(duì)較合適的技術(shù)棧。另外，好的技術(shù)選型是相互借鑒甚至PK出來(lái)的，歡迎大家討論，給出自己的微服務(wù)2.0技術(shù)棧選型意見。

下面附各類開源微服務(wù)產(chǎn)品的社區(qū)地址：

Spring Boot
https://github.com/spring-projects/spring-boot
Alibaba Dubbo
https://github.com/alibaba/dubbo
Google gRPC
https://github.com/grpc/grpc
NetflixOSS Eureka
https://github.com/Netflix/eureka
Hashicorp Consul
https://github.com/hashicorp/consul
NetflixOSS Zuul
https://github.com/Netflix/zuul
Kong
https://github.com/Kong/kong
Spring Cloud Config
https://github.com/spring-cloud/spring-cloud-config
CTrip Apollo
https://github.com/ctripcorp/apollo
ElasticSearch
https://github.com/elastic/elasticsearch
Yelp Elastalert
https://github.com/Yelp/elastalert
Dianping CAT
https://github.com/dianping/cat
Zipkin
https://github.com/openzipkin/zipkin
Naver Pinpoint
https://github.com/naver/pinpoint
OpenTSDB
https://github.com/OpenTSDB/opentsdb
KairosDB
https://github.com/kairosdb/kairosdb
Argus
https://github.com/salesforce/Argus
InfluxDB
https://github.com/influxdata/influxdb
Prometheus
https://github.com/prometheus/prometheus
Grafana
https://github.com/grafana/grafana
Sensu
https://github.com/sensu/sensu
Esty 411
https://github.com/etsy/411
Zalando ZMon
https://github.com/zalando/zmon
NetflixOSS Hystrix
https://github.com/Netflix/Hystrix
Nginx
https://github.com/nginx/nginx
Apache Kafka
https://github.com/apache/kafka
Allegro Hermes
https://github.com/allegro/hermes
Apache Rocketmq
https://github.com/apache/rocketmq
Rabbitmq
https://github.com/rabbitmq/rabbitmq-server
Sohutv CacheCloud
https://github.com/sohutv/cachecloud
Twitter twemproxy
https://github.com/twitter/twemproxy
CodisLab codis
https://github.com/CodisLabs/codis
Dangdang Sharding-jdbc
https://github.com/shardingjdbc/sharding-jdbc
MyCAT
https://github.com/MyCATApache/Mycat-Server
Xxl-job
https://github.com/xuxueli/xxl-job
Dangdang elastic-job
https://github.com/elasticjob/elastic-job-lite
Apereo CAS
https://github.com/apereo/cas
JBoss keycloak
https://github.com/keycloak/keycloak
Spring cloud security
https://github.com/spring-cloud/spring-cloud-security
OpenID-Connect-Java-Spring-Server
https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server
Google Kubernetes
https://github.com/kubernetes/kubernetes
Apache Mesos
https://github.com/apache/mesos
Vmware Harbor
https://github.com/vmware/harbor
Netflix Spinnaker
https://github.com/spinnaker/spinnaker
Microservices in Practice – Key Architecture Concepts of an MSA
https://wso2.com/whitepapers/microservices-in-practice-key-architectural-concepts-of-an-msa/
微服務(wù)的設(shè)計(jì)與生態(tài)系統(tǒng)
http://servicecomb.incubator.apache.org/assets/slides/20170619/MSAPrinciple&EcoSystem.pdf