一. micro-service架構(gòu)

微服務(wù)是指開發(fā)一個單個小型的但有業(yè)務(wù)功能的服務(wù)，每個服務(wù)都有自己的處理和通訊機(jī)制腕唧，可以部署在單個或多個服務(wù)器上蹋订。比如：訂單系統(tǒng)，用戶系統(tǒng)清寇，路線系統(tǒng)，支付系統(tǒng)等等
現(xiàn)階段Twitter, Netflix, Amazon 和 eBay都已經(jīng)遷移到了微服務(wù)架構(gòu)护蝶。
微服務(wù)一般通過http RESTful接口進(jìn)行通訊华烟。
微服務(wù)的優(yōu)點

• 每個微服務(wù)都很小，這樣能聚焦一個指定的業(yè)務(wù)功能或業(yè)務(wù)需求,可測試性好
• 微服務(wù)是松耦合的持灰，易于并行開發(fā)以及上線后的局部靈活部署調(diào)整
• 由于是松耦合的盔夜，每個微服務(wù)技術(shù)選型比較靈活，可以使用不同的語言和框架

微服務(wù)的缺點

• 由于有更多的網(wǎng)絡(luò)開銷堤魁，整體延遲有一定的增加
• 更多的模塊喂链，系統(tǒng)整體復(fù)雜度變高

二. micro-service的組成

1. 服務(wù)注冊、發(fā)現(xiàn)妥泉、負(fù)載均衡和健康檢查

第一種是集中式LB方案
如下圖椭微，在服務(wù)消費者和服務(wù)提供者之間有一個獨立的LB，LB通常是專門的硬件設(shè)備如F5盲链，或者基于軟件如LVS蝇率，HAproxy或者Nginx等實現(xiàn)。LB上有所有服務(wù)的地址映射表刽沾，通常由運維配置注冊本慕，當(dāng)服務(wù)消費方調(diào)用某個目標(biāo)服務(wù)時，它向LB發(fā)起請求侧漓，由LB以某種策略（比如Round-Robin）做負(fù)載均衡后將請求轉(zhuǎn)發(fā)到目標(biāo)服務(wù)锅尘。LB一般具備健康檢查能力，能自動摘除不健康的服務(wù)實例布蔗。服務(wù)消費方如何發(fā)現(xiàn)LB呢鉴象？通常的做法是通過DNS忙菠，運維人員為服務(wù)配置一個DNS域名，這個域名指向LB纺弊。

集中式LB方案

我的上一家公司后端使用的就是這種架構(gòu)的微服務(wù)陕凹。搭建一組nginx用作負(fù)載均衡悍抑，單機(jī)承受1Wqps沒有什么問題。利用nginx的內(nèi)置功能摘除失敗的service provider

第二種是進(jìn)程內(nèi)LB方案
針對集中式LB的不足杜耙，進(jìn)程內(nèi)LB方案將LB的功能以庫的形式集成到服務(wù)消費方進(jìn)程里頭搜骡，該方案也被稱為軟負(fù)載(Soft Load Balancing)或者客戶端負(fù)載方案，下圖展示了這種方案的工作原理佑女。這一方案需要一個服務(wù)注冊表(Service Registry)配合支持服務(wù)自注冊和自發(fā)現(xiàn)记靡，服務(wù)提供方啟動時，首先將服務(wù)地址注冊到服務(wù)注冊表（同時定期報心跳到服務(wù)注冊表以表明服務(wù)的存活狀態(tài)团驱，相當(dāng)于健康檢查）摸吠，服務(wù)消費方要訪問某個服務(wù)時，它通過內(nèi)置的LB組件向服務(wù)注冊表查詢（同時緩存并定期刷新）目標(biāo)服務(wù)地址列表嚎花，然后以某種負(fù)載均衡策略選擇一個目標(biāo)服務(wù)地址寸痢，最后向目標(biāo)服務(wù)發(fā)起請求。這一方案對服務(wù)注冊表的可用性(Availability)要求很高贩幻，一般采用能滿足高可用分布式一致的組件（例如Zookeeper和基于docker的Consul, Etcd等）來實現(xiàn)。

進(jìn)程內(nèi)LB方案

baidu的ubclient＋namingservice 使用的也是這個模式

第三種是主機(jī)獨立LB進(jìn)程方案
該方案是針對第二種方案的不足而提出的一種折中方案，原理和第二種方案基本類似爷辙，不同之處是彬坏，他將LB和服務(wù)發(fā)現(xiàn)功能從進(jìn)程內(nèi)移出來，變成主機(jī)上的一個獨立進(jìn)程犬钢，主機(jī)上的一個或者多個服務(wù)要訪問目標(biāo)服務(wù)時苍鲜，他們都通過同一主機(jī)上的獨立LB進(jìn)程做服務(wù)發(fā)現(xiàn)和負(fù)載均衡，見下圖玷犹。

主機(jī)獨立LB進(jìn)程方案

多個上下游微服務(wù)的組合兜粘，就會形成一個類似樹形的服務(wù)集群

2. 服務(wù)前端路由

微服務(wù)除了內(nèi)部相互之間調(diào)用和通信之外申窘，最終要以某種方式暴露出去，才能讓外界系統(tǒng)（例如客戶的瀏覽器孔轴、移動設(shè)備等等）訪問到剃法，這就涉及服務(wù)的前端路由，對應(yīng)的組件是服務(wù)網(wǎng)關(guān)(Service Gateway)距糖，如下圖玄窝，網(wǎng)關(guān)是連接企業(yè)內(nèi)部和外部系統(tǒng)的一道門，有如下關(guān)鍵作用：

1. 服務(wù)反向路由悍引，網(wǎng)關(guān)要負(fù)責(zé)將外部請求反向路由到內(nèi)部具體的微服務(wù)的最上一層恩脂，這樣雖然企業(yè)內(nèi)部是復(fù)雜的分布式微服務(wù)結(jié)構(gòu)，但是外部系統(tǒng)從網(wǎng)關(guān)上看到的就像是一個統(tǒng)一的完整服務(wù)趣斤，網(wǎng)關(guān)屏蔽了后臺服務(wù)的復(fù)雜性俩块，同時也屏蔽了后臺服務(wù)的升級和變化。
2. 安全認(rèn)證和防爬蟲浓领，所有外部請求必須經(jīng)過網(wǎng)關(guān)玉凯，網(wǎng)關(guān)可以集中對訪問進(jìn)行安全控制，比如用戶認(rèn)證和授權(quán)联贩，同時還可以分析訪問模式實現(xiàn)防爬蟲功能漫仆，網(wǎng)關(guān)是連接企業(yè)內(nèi)外系統(tǒng)的安全之門。
3. 限流和容錯泪幌，在流量高峰期盲厌，網(wǎng)關(guān)可以限制流量，保護(hù)后臺系統(tǒng)不被大流量沖垮（防雪崩）祸泪，在內(nèi)部系統(tǒng)出現(xiàn)故障時吗浩，網(wǎng)關(guān)可以集中做容錯，保持外部良好的用戶體驗没隘。
4. 監(jiān)控懂扼，網(wǎng)關(guān)可以集中監(jiān)控訪問量，調(diào)用延遲右蒲，錯誤計數(shù)和訪問模式阀湿，為后端的性能優(yōu)化或者擴(kuò)容提供數(shù)據(jù)支持」逋可以清洗流量陷嘴，防ddos。

5. 日志翰撑，網(wǎng)關(guān)可以收集所有的訪問日志罩旋，進(jìn)入后臺系統(tǒng)做進(jìn)一步分析。

   
   
   網(wǎng)關(guān)

除以上基本能力外眶诈，網(wǎng)關(guān)還可以實現(xiàn)線上引流涨醋，線上壓測，線上調(diào)試(Surgical debugging)逝撬，A/B測試(灰度測試)浴骂，數(shù)據(jù)中心雙活(Active-Active HA)等高級功能。
網(wǎng)關(guān)通常工作在7層宪潮，有一定的計算邏輯溯警，一般以集群方式部署，前置LB進(jìn)行負(fù)載均衡狡相。
開源的網(wǎng)關(guān)組件有Netflix的Zuul梯轻，特點是動態(tài)可熱部署的過濾器(filter)機(jī)制，其它如HAproxy尽棕，Nginx等都可以擴(kuò)展作為網(wǎng)關(guān)使用喳挑。

3. 服務(wù)容錯

當(dāng)企業(yè)微服務(wù)化以后，服務(wù)之間會有錯綜復(fù)雜的依賴關(guān)系滔悉，例如伊诵，一個前端請求一般會依賴于多個后端服務(wù)，技術(shù)上稱為1 -> N扇出回官。在實際生產(chǎn)環(huán)境中曹宴，服務(wù)往往不是百分百可靠，服務(wù)可能會出錯或者產(chǎn)生延遲歉提，如果一個應(yīng)用不能對其依賴的故障進(jìn)行容錯和隔離笛坦，那么該應(yīng)用本身就處在被拖垮的風(fēng)險中。在一個高流量的網(wǎng)站中唯袄，某個單一后端一旦發(fā)生延遲弯屈，可能在數(shù)秒內(nèi)導(dǎo)致所有應(yīng)用資源(線程，隊列等)被耗盡恋拷，造成所謂的雪崩效應(yīng)(Cascading Failure)资厉，嚴(yán)重時可致整個網(wǎng)站癱瘓。

所以蔬顾，調(diào)用方要設(shè)定合理的超時timeout值宴偿，如搜索業(yè)務(wù)，在某些情況下可以拋棄某些庫的結(jié)果返回诀豁。這種是沒有pvlost窄刘，但是效果會變差的方案

經(jīng)過多年的探索和實踐，業(yè)界在分布式服務(wù)容錯一塊探索出了一套有效的容錯模式和最佳實踐舷胜，主要包括：
電路熔斷器模式(Circuit Breaker Patten)
該模式的原理類似于家里的電路熔斷器娩践，如果家里的電路發(fā)生短路，熔斷器能夠主動熔斷電路，以避免災(zāi)難性損失翻伺。在分布式系統(tǒng)中應(yīng)用電路熔斷器模式后材泄，當(dāng)目標(biāo)服務(wù)慢或者大量超時，調(diào)用方能夠主動熔斷吨岭，以防止服務(wù)被進(jìn)一步拖垮拉宗；如果情況又好轉(zhuǎn)了，電路又能自動恢復(fù)辣辫，這就是所謂的彈性容錯旦事，系統(tǒng)有自恢復(fù)能力。下圖是一個典型的具備彈性恢復(fù)能力的電路保護(hù)器狀態(tài)圖急灭，正常狀態(tài)下姐浮，電路處于關(guān)閉狀態(tài)(Closed)，如果調(diào)用持續(xù)出錯或者超時葬馋，電路被打開進(jìn)入熔斷狀態(tài)(Open)单料，后續(xù)一段時間內(nèi)的所有調(diào)用都會被拒絕(Fail Fast)，一段時間以后点楼，保護(hù)器會嘗試進(jìn)入半熔斷狀態(tài)(Half-Open)扫尖，允許少量請求進(jìn)來嘗試，如果調(diào)用仍然失敗掠廓，則回到熔斷狀態(tài)换怖，如果調(diào)用成功，則回到電路閉合狀態(tài)蟀瞧。

彈性電路保護(hù)狀態(tài)圖

以上3種饥脑，都會有pvlost拒絕部分服務(wù)恳邀。

回退(fallback)，在熔斷或者限流發(fā)生的時候灶轰，應(yīng)用程序的后續(xù)處理邏輯是什么谣沸？回退是系統(tǒng)的彈性恢復(fù)能力，常見的處理策略有笋颤，直接拋出異常乳附，也稱快速失敗(Fail Fast)，也可以返回空值或缺省值伴澄，還可以返回備份數(shù)據(jù)赋除，如果主服務(wù)熔斷了，可以從備份服務(wù)獲取數(shù)據(jù)非凌。

Netflix將上述容錯模式和最佳實踐集成到一個稱為Hystrix的開源組件中举农，凡是需要容錯的依賴點(服務(wù)，緩存敞嗡，數(shù)據(jù)庫訪問等)颁糟，開發(fā)人員只需要將調(diào)用封裝在Hystrix Command里頭，則相關(guān)調(diào)用就自動置于Hystrix的彈性容錯保護(hù)之下喉悴。Hystrix組件已經(jīng)在Netflix經(jīng)過多年運維驗證棱貌，是Netflix微服務(wù)平臺穩(wěn)定性和彈性的基石，正逐漸被社區(qū)接受為標(biāo)準(zhǔn)容錯組件箕肃。

4. 服務(wù)框架

微服務(wù)的一個優(yōu)點就是可以為每個微服務(wù)采用不同的框架或者語言婚脱。但是框架的共性還是存在的。

微服務(wù)框架

微服務(wù)框架一般包括：

• 服務(wù)注冊勺像、發(fā)現(xiàn)起惕、負(fù)載均衡和健康檢查，假定采用進(jìn)程內(nèi)LB方案咏删，那么服務(wù)自注冊一般統(tǒng)一做在服務(wù)器端框架中惹想，健康檢查邏輯由具體業(yè)務(wù)服務(wù)定制，框架層提供調(diào)用健康檢查邏輯的機(jī)制督函，服務(wù)發(fā)現(xiàn)和負(fù)載均衡則集成在服務(wù)客戶端框架中嘀粱。
• 監(jiān)控日志激挪，框架一方面要記錄重要的框架層日志、metrics和調(diào)用鏈數(shù)據(jù)锋叨，還要將日志垄分、metrics等接口暴露出來，讓業(yè)務(wù)層能根據(jù)需要記錄業(yè)務(wù)日志數(shù)據(jù)娃磺。在運行環(huán)境中薄湿，所有日志數(shù)據(jù)一般集中落地到企業(yè)后臺日志系統(tǒng)，做進(jìn)一步分析和處理偷卧。
• REST/RPC和序列化豺瘤，框架層要支持將業(yè)務(wù)邏輯以HTTP/REST或者RPC方式暴露出來，HTTP/REST是當(dāng)前主流API暴露方式听诸，在性能要求高的場合則可采用Binary/RPC方式坐求。針對當(dāng)前多樣化的設(shè)備類型(瀏覽器、普通PC晌梨、無線設(shè)備等)桥嗤，框架層要支持可定制的序列化機(jī)制，例如仔蝌，對瀏覽器泛领，框架支持輸出Ajax友好的JSON消息格式，而對無線設(shè)備上的Native App敛惊，框架支持輸出性能高的Binary消息格式师逸。
• 配置，除了支持普通配置文件方式的配置豆混，框架層還可集成動態(tài)運行時配置篓像，能夠在運行時針對不同環(huán)境動態(tài)調(diào)整服務(wù)的參數(shù)和配置。
• 限流和容錯皿伺，框架集成限流容錯組件员辩，能夠在運行時自動限流和容錯，保護(hù)服務(wù)鸵鸥，如果進(jìn)一步和動態(tài)配置相結(jié)合奠滑，還可以實現(xiàn)動態(tài)限流和熔斷。
• 管理接口妒穴，框架集成管理接口宋税，一方面可以在線查看框架和服務(wù)內(nèi)部狀態(tài)，同時還可以動態(tài)調(diào)整內(nèi)部狀態(tài)讼油，對調(diào)試杰赛、監(jiān)控和管理能提供快速反饋。Spring Boot微框架的Actuator模塊就是一個強大的管理接口矮台。
• 統(tǒng)一錯誤處理乏屯，對于框架層和服務(wù)的內(nèi)部異常根时，如果框架層能夠統(tǒng)一處理并記錄日志，對服務(wù)監(jiān)控和快速問題定位有很大幫助辰晕。
• 安全蛤迎，安全和訪問控制邏輯可以在框架層統(tǒng)一進(jìn)行封裝，可做成插件形式含友，具體業(yè)務(wù)服務(wù)根據(jù)需要加載相關(guān)安全插件替裆。
• 文檔自動生成，文檔的書寫和同步一直是一個痛點窘问，框架層如果能支持文檔的自動生成和同步辆童，會給使用API的開發(fā)和測試人員帶來極大便利。Swagger是一種流行Restful API的文檔方案南缓。
• DB/KV/filesystem訪問引擎
• 代碼的內(nèi)部routing功能
• 加密，單元測試功能

當(dāng)前業(yè)界比較成熟的微服務(wù)框架有Netflix的Karyon/Ribbon荧呐，Spring的Spring Boot/Cloud汉形，阿里的Dubbo等”恫基于php的lumen概疆。

5. 運行期配置管理

服務(wù)一般有很多依賴配置，例如訪問數(shù)據(jù)庫有連接字符串配置峰搪，連接池大小和連接超時配置岔冀，這些配置在不同環(huán)境(開發(fā)/測試/生產(chǎn))一般不同，比如生產(chǎn)環(huán)境需要配連接池概耻，而開發(fā)測試環(huán)境可能不配使套，另外有些參數(shù)配置在運行期可能還要動態(tài)調(diào)整，例如鞠柄，運行時根據(jù)流量狀況動態(tài)調(diào)整限流和熔斷閥值侦高。目前比較常見的做法是搭建一個運行時配置中心支持微服務(wù)的動態(tài)配置，簡化架構(gòu)如下圖：

服務(wù)配置中心

動態(tài)配置存放在集中的配置服務(wù)器上厌杜，用戶通過管理界面配置和調(diào)整服務(wù)配置奉呛，具體服務(wù)通過定期拉(Scheduled Pull)的方式或者服務(wù)器推(Server-side Push)的方式更新動態(tài)配置，拉方式比較可靠夯尽，但會有延遲同時有無效網(wǎng)絡(luò)開銷(假設(shè)配置不常更新)瞧壮，服務(wù)器推方式能及時更新配置，但是實現(xiàn)較復(fù)雜匙握，一般在服務(wù)和配置服務(wù)器之間要建立長連接咆槽。配置中心還要解決配置的版本控制和審計問題，對于大規(guī)模服務(wù)化環(huán)境圈纺，配置中心還要考慮分布式和高可用問題罗晕。
配置中心比較成熟的開源方案有百度的Disconf济欢，360的QConf，Spring的Cloud Config和阿里的Diamond等小渊。

配置中心和負(fù)載均衡的服務(wù)類似法褥，需要分布式穩(wěn)定的kv存儲作為基礎(chǔ)。

6. 使用微服務(wù)架構(gòu)的大互聯(lián)網(wǎng)公司

netflix

其中
Eureka:　服務(wù)注冊發(fā)現(xiàn)框架
Zuul:　服務(wù)網(wǎng)關(guān)
Karyon:　服務(wù)端框架
Ribbon:　客戶端框架
Hystrix: 服務(wù)容錯組件
Archaius: 服務(wù)配置組件
Servo: Metrics組件
Blitz4j: 日志組件

twitter

[參考資料]
(1) [實施微服務(wù)需要哪些基礎(chǔ)框架]