前言

首先，微服務(wù)不是一個(gè)名字，而是一個(gè)架構(gòu)的概念，就像Restful不僅僅是描述api的格式，而更多的是描述基于Restful API的架構(gòu)是一樣的。微服務(wù)架構(gòu)（MSA）是對(duì)原來的大型系統(tǒng)而言的，通過橫向或者縱向、業(yè)務(wù)或者架構(gòu)切分，將一個(gè)大型的系統(tǒng)分散成很多微型小系統(tǒng)。當(dāng)系統(tǒng)復(fù)雜到一定程度時(shí)，幾十號(hào)人共同維護(hù)一個(gè)系統(tǒng)的效率很低，而且出問題的風(fēng)險(xiǎn)也很高。

這時(shí)候就需要對(duì)系統(tǒng)進(jìn)行切分，很早之前提出的SOA系統(tǒng)，和微服務(wù)的架構(gòu)理念不謀而合。大家現(xiàn)在使用的基于RPC框架（dubbo、thrift等）的架構(gòu)也可以視為一種微服務(wù)。微服務(wù)到現(xiàn)在為止還沒有確切的邊界和定義，貌似計(jì)算機(jī)上很多概念都定義不出來邊界。但是，我理解微服務(wù)之間的通信是http通信，傳統(tǒng)rpc調(diào)用方式并不是嚴(yán)格的微服務(wù)，因?yàn)樗荒茏岳?，需要依賴，比如可能必須某個(gè)rpc服務(wù)Producer存在的情況下，rpc服務(wù)的Consumer才能啟動(dòng)起來。所以，下文中的討論，我都以微服務(wù)之間以http通信為前提。

微服務(wù)有什么好處

解耦：對(duì)于我們底層程序員而言，看得見的好處就是解耦。我要實(shí)現(xiàn)一個(gè)功能，可能并不需要很深入的了解別人的代碼，因?yàn)槌绦騿T嘛，可能都覺得別人的代碼是個(gè)渣渣（［哭笑不得］）。我可以新作一個(gè)微服務(wù)，這個(gè)服務(wù)為其他功能提供服務(wù)，又不依賴于原來已有的功能，至于業(yè)務(wù)邏輯，可以一邊上手一邊熟悉 內(nèi)聚，可以獨(dú)立部署：意思就是我維護(hù)的這個(gè)微服務(wù)，可以獨(dú)立部署，對(duì)其他服務(wù)不會(huì)是強(qiáng)依賴，不會(huì)存在因?yàn)槠渌?wù)不存在而造成我自己的服務(wù)不能啟動(dòng)或者不可用的問題。

分布式：微服務(wù)架構(gòu)下不存在一個(gè)特別大的系統(tǒng)包含很多中心功能，這樣也能提高容錯(cuò)性，一個(gè)服務(wù)的癱瘓并不會(huì)讓整個(gè)系統(tǒng)癱瘓 權(quán)限驗(yàn)證：微服務(wù)是高度內(nèi)聚的服務(wù)，我自己的這個(gè)服務(wù)，我可以定制任意合理規(guī)則，而這個(gè)規(guī)則又只適用于我自己的服務(wù)。相比于dubbo RPC調(diào)用，http微服務(wù)調(diào)用的權(quán)限驗(yàn)證可以更直接更嚴(yán)格更定制化，而rpc調(diào)用時(shí)的權(quán)限驗(yàn)證，我個(gè)人始終覺得不能做的很優(yōu)雅 數(shù)據(jù)分開治理，自帶分庫屬性：原來的大系統(tǒng)使用一個(gè)數(shù)據(jù)庫，當(dāng)數(shù)據(jù)很多流量很大時(shí)，就會(huì)涉及到分庫分表。

而微服務(wù)下，每個(gè)服務(wù)是否使用數(shù)據(jù)庫，數(shù)據(jù)庫是和其他服務(wù)公用還是自建，都有很大靈活性，即我覺得微服務(wù)自帶分庫分表屬性 系統(tǒng)不會(huì)被長(zhǎng)期限制在某個(gè)技術(shù)棧上，在微服務(wù)的架構(gòu)下，整個(gè)系統(tǒng)不會(huì)受限于java或者nodejs 或者go，而是大家協(xié)同不沖突，全部http協(xié)議，json格式 各個(gè)模塊的單元測(cè)試容易自動(dòng)化 等

微服務(wù)面臨的挑戰(zhàn)

通信，http請(qǐng)求速度慢，通常一個(gè)操作可能會(huì)涉及到多個(gè)微服務(wù)的相互調(diào)用，如果為了完成一個(gè)操作而多次從服務(wù)端調(diào)用不同的微服務(wù)，http請(qǐng)求的耗時(shí)可能會(huì)成為瓶頸，如圖1所示。

客戶端與服務(wù)端的通信需要一個(gè) API GateWay：通常情況下，客戶端和微服務(wù)們不在一起，而各個(gè)微服務(wù)會(huì)集中部署在一個(gè)機(jī)房，那微服務(wù)之間的互相調(diào)用是很快速的，但是客戶端和微服務(wù)之間的調(diào)用會(huì)是耗時(shí)的。而且，用戶的一個(gè)動(dòng)作不能在客戶端進(jìn)行多次連續(xù)調(diào)用，這樣一來速度慢，二來會(huì)有泄漏系統(tǒng)架構(gòu)的風(fēng)險(xiǎn)。正常情況下，在客戶端和微服務(wù)架構(gòu)之間會(huì)有一個(gè)API GateWay。

如圖1變成圖2所示，GateWay最重要的作用是為客戶端提供后臺(tái)服務(wù)的聚合，提供一個(gè)統(tǒng)一的服務(wù)出口，解除他們之間的耦合，為了解決API Gateway單點(diǎn)故障點(diǎn)或者性能瓶頸，通常Gateway也是一個(gè)集群，而且客戶端的訪問控制、賬號(hào)管理、登錄管理等切面通常會(huì)在這里處理

微服務(wù)很多時(shí)，整個(gè)鏈路可能很長(zhǎng)，調(diào)用失敗的風(fēng)險(xiǎn)高，而且e2e自動(dòng)化測(cè)試會(huì)成為一個(gè)問題 服務(wù)注冊(cè)和服務(wù)發(fā)現(xiàn)，我司有自己的服務(wù)管理系統(tǒng)。我推薦etcd。Google開源的Kubernetes（k8s）貌似也是使用的這個(gè)。 分布式事務(wù)，這個(gè)是微服務(wù)系統(tǒng)的大難點(diǎn)，可能需要根據(jù)自己系統(tǒng)的情況和業(yè)務(wù)需求進(jìn)行定制了，我推薦補(bǔ)償性分布式事務(wù)和基于消息的分布式事務(wù)。（下次有時(shí)間介紹一下常用的集中分布式事務(wù)要怎么做）

基于微服務(wù)架構(gòu)和架構(gòu)實(shí)施過程中存在的優(yōu)點(diǎn)和缺點(diǎn)：

采用微服務(wù)架構(gòu)的優(yōu)點(diǎn)

采用微服務(wù)架構(gòu)可以更好的實(shí)現(xiàn)DevOps開發(fā)運(yùn)維一體化，同時(shí)因?yàn)槲⒎?wù)架構(gòu)下各個(gè)微服務(wù)模塊相對(duì)獨(dú)立和松耦合，因此在后續(xù)業(yè)務(wù)變更的分析和處理中往往能夠更加敏捷快速的響應(yīng)，同時(shí)相對(duì)影響也最小。

整個(gè)業(yè)務(wù)系統(tǒng)水平擴(kuò)展更加容易，單體應(yīng)用要擴(kuò)展往往數(shù)據(jù)庫是大問題，而在微服務(wù)架構(gòu)下實(shí)現(xiàn)了單體應(yīng)用的垂直拆分，可以更加容易的通過廉價(jià)的X86服務(wù)器資源來實(shí)現(xiàn)水平擴(kuò)展。

通過微服務(wù)架構(gòu)可以更好的提升各個(gè)模塊的可復(fù)用性和可組裝性。通過微服務(wù)架構(gòu)更好的實(shí)現(xiàn)了原單體應(yīng)用內(nèi)部各個(gè)組件或模塊的徹底解耦，通過解耦本身也降低了原單體應(yīng)用內(nèi)部的復(fù)雜度。

可以使研發(fā)過程根據(jù)敏捷和小團(tuán)隊(duì)化，包括和敏捷軟件開發(fā)最佳實(shí)踐更好的匹配，每個(gè)微服務(wù)模塊都可以形成獨(dú)立的敏捷小團(tuán)隊(duì)進(jìn)行開發(fā)和部署上線。

進(jìn)一步在傳統(tǒng)單體應(yīng)用內(nèi)部實(shí)施SOA參考架構(gòu)思想，體現(xiàn)業(yè)務(wù)能力組件化，組件能力服務(wù)化，同時(shí)也可以更好貫徹各個(gè)能力中心和前端應(yīng)用組件的分離，實(shí)現(xiàn)共性能力下沉和復(fù)用。

采用微服務(wù)架構(gòu)的缺點(diǎn)或困難

微服務(wù)架構(gòu)需要開發(fā)團(tuán)隊(duì)本身具備較強(qiáng)的團(tuán)隊(duì)管理能力，軟件研發(fā)技能，因?yàn)楣芸氐牧６葐挝灰呀?jīng)從原有業(yè)務(wù)系統(tǒng)變化為了微服務(wù)模塊。

微服務(wù)架構(gòu)本身會(huì)提升開發(fā)難度和工作量，特別是上層的跨多個(gè)微服務(wù)模塊或組件的功能應(yīng)用的實(shí)現(xiàn)，往往需要在前端進(jìn)行服務(wù)組合而不是傳統(tǒng)方式在數(shù)據(jù)庫層做SQL關(guān)聯(lián)。

由于各個(gè)微服務(wù)模塊完全相對(duì)獨(dú)立和松耦合，因此對(duì)于跨多模塊業(yè)務(wù)帶來的分布式事務(wù)問題是必須解決或找尋替代方案。特別是在微服務(wù)架構(gòu)下數(shù)據(jù)庫已經(jīng)進(jìn)行了垂直拆分，對(duì)于跨庫訪問本身的分布式事務(wù)一致性問題是最需要和重視的問題。

服務(wù)的治理將成為實(shí)施微服務(wù)架構(gòu)中重點(diǎn)問題，包括了服務(wù)全生命周期管理，服務(wù)后期的運(yùn)維和監(jiān)控，性能分析，服務(wù)鏈監(jiān)控等。如果企業(yè)本身的IT治理和SOA管控治理能力弱，那么及時(shí)開始正常實(shí)施了微服務(wù)架構(gòu)，到了后期的運(yùn)維管控也很難做的很好。其核心原因還是管控的粒度更加細(xì)，需要管控的微服務(wù)模塊，服務(wù)接口都會(huì)呈現(xiàn)指數(shù)級(jí)增加。

集成復(fù)雜度增加，任何徹底的分解都將帶來集成的復(fù)雜度，即模塊在集成時(shí)候需要外部微服務(wù)模塊更多的配合。

部署復(fù)雜度增加，由于微服務(wù)模塊需要獨(dú)立部署，往往涉及到多達(dá)上100個(gè)容器的安裝和部署和集成等相關(guān)工作，這也是需要和Docker集成并實(shí)現(xiàn)自動(dòng)部署的一個(gè)原因。

微服務(wù)很多時(shí)，整個(gè)鏈路可能很長(zhǎng)，調(diào)用失敗的風(fēng)險(xiǎn)高，而且e2e自動(dòng)化測(cè)試會(huì)成為一個(gè)問題 服務(wù)注冊(cè)和服務(wù)發(fā)現(xiàn)，我司有自己的服務(wù)管理系統(tǒng)。我推薦etcd。Google開源的Kubernetes（k8s）貌似也是使用的這個(gè)。 分布式事務(wù)，這個(gè)是微服務(wù)系統(tǒng)的大難點(diǎn)，可能需要根據(jù)自己系統(tǒng)的情況和業(yè)務(wù)需求進(jìn)行定制了，我推薦補(bǔ)償性分布式事務(wù)和基于消息的分布式事務(wù)。（下次有時(shí)間介紹一下常用的集中分布式事務(wù)要怎么做）