微服務(wù)

軟件架構(gòu)是一個包含各種組織的系統(tǒng)組織，這些組件包括 Web服務(wù)器, 應(yīng)用服務(wù)器, 數(shù)據(jù)庫,存儲, 通訊層), 它們彼此或和環(huán)境存在關(guān)系。系統(tǒng)架構(gòu)的目標(biāo)是解決利益相關(guān)者的關(guān)注點(diǎn)。

Conway’s law: Organizations which design systems[...] are constrained to produce designs which are copies of the communication structures of these organizations.

（設(shè)計系統(tǒng)的組織，其產(chǎn)生的設(shè)計和架構(gòu)等價于組織間的溝通結(jié)構(gòu)。)

Monolithic架構(gòu)

Monolithic比較適合小項目，優(yōu)點(diǎn)是：

開發(fā)簡單直接，集中式管理, 基本不會重復(fù)開發(fā)

功能都在本地，沒有分布式的管理開銷和調(diào)用開銷。它的缺點(diǎn)也非常明顯，特別對于互聯(lián)網(wǎng)公司來說（不一一列舉了）：

開發(fā)效率低：所有的開發(fā)在一個項目改代碼，遞交代碼相互等待，代碼沖突不斷

代碼維護(hù)難：代碼功能耦合在一起，新人不知道何從下手

部署不靈活：構(gòu)建時間長，任何小修改必須重新構(gòu)建整個項目，這個過程往往很長

穩(wěn)定性不高：一個微不足道的小問題，可以導(dǎo)致整個應(yīng)用掛掉

擴(kuò)展性不夠：無法滿足高并發(fā)情況下的業(yè)務(wù)需求

微服務(wù)架構(gòu)

微服務(wù)是指開發(fā)一個單個小型的但有業(yè)務(wù)功能的服務(wù)，每個服務(wù)都有自己的處理和輕量通訊機(jī)制，可以部署在單個或多個服務(wù)器上。微服務(wù)也指一種種松耦合的、有一定的有界上下文的面向服務(wù)架構(gòu)。也就是說，如果每個服務(wù)都要同時修改，那么它們就不是微服務(wù)，因為它們緊耦合在一起；如果你需要掌握一個服務(wù)太多的上下文場景使用條件，那么它就是一個有上下文邊界的服務(wù)，這個定義來自DDD領(lǐng)域驅(qū)動設(shè)計。

相對于單體架構(gòu)和SOA，它的主要特點(diǎn)是組件化、松耦合、自治、去中心化，體現(xiàn)在以下幾個方面：

一組小的服務(wù)
服務(wù)粒度要小，而每個服務(wù)是針對一個單一職責(zé)的業(yè)務(wù)能力的封裝，專注做好一件事情。
獨(dú)立部署運(yùn)行和擴(kuò)展
每個服務(wù)能夠獨(dú)立被部署并運(yùn)行在一個進(jìn)程內(nèi)。這種運(yùn)行和部署方式能夠賦予系統(tǒng)靈活的代碼組織方式和發(fā)布節(jié)奏，使得快速交付和應(yīng)對變化成為可能。
獨(dú)立開發(fā)和演化
技術(shù)選型靈活，不受遺留系統(tǒng)技術(shù)約束。合適的業(yè)務(wù)問題選擇合適的技術(shù)可以獨(dú)立演化。服務(wù)與服務(wù)之間采取與語言無關(guān)的API進(jìn)行集成。相對單體架構(gòu)，微服務(wù)架構(gòu)是更面向業(yè)務(wù)創(chuàng)新的一種架構(gòu)模式。
獨(dú)立團(tuán)隊和自治
團(tuán)隊對服務(wù)的整個生命周期負(fù)責(zé)，工作在獨(dú)立的上下文中，自己決策自己治理，而不需要統(tǒng)一的指揮中心。團(tuán)隊和團(tuán)隊之間通過松散的社區(qū)部落進(jìn)行銜接。

我們可以看到整個微服務(wù)的思想就如我們現(xiàn)在面對信息爆炸、知識爆炸是一樣的：通過解耦我們所做的事情，分而治之以減少不必要的損耗，使得整個復(fù)雜的系統(tǒng)和組織能夠快速的應(yīng)對變化。

我們?yōu)槭裁床捎梦⒎?wù)呢？

"讓我們的系統(tǒng)盡可能快地響應(yīng)變化" - Rebecca Parson

讓我們的系統(tǒng)盡可能快地去響應(yīng)變化。其實幾十年來我們一直在嘗試解決這個問題。如果一定要在前面加個限制的話，那就是低成本的快速響應(yīng)變化。上世紀(jì)90年代Kent Beck提出要擁抱變化，在同期出現(xiàn)了諸多輕量級開發(fā)方法（諸如 XP、Scrum）；2001年敏捷宣言誕生，之后又出現(xiàn)了精益、看板等新的管理方式。如果說，這些是為了盡快的響應(yīng)變化，在軟件開發(fā)流程和實踐方面提出的解決方案，那么微服務(wù)架構(gòu)就是在軟件技術(shù)和架構(gòu)層面提出的應(yīng)對之道。

Autonomous
A Microservice is a unit of functionality; it provides an API for a set of capabilities oriented around a business domain or common utility

Isolated
A Microservice is a unit of deployment; it can be modified, tested and deployed as a unit without impacting other areas of a solution

Elastic
A Microservice is stateless; it can be horizontally scaled up and down as needed

Resilient
A Microservice is designed for failure; it is fault tolerant and highly available

Responsive
A Microservice responds to requests in a reasonable amount of time

Intelligent
The intelligence in a system is found in the Microservice endpoints not ‘on the wire’

Message Oriented
Microservices rely on HTTP or a lightweight message bus to establish a boundary between components; this ensures loose coupling, isolation, location transparency, and provides the means to delegate errors as messages

Programmable
Microservices provide API’s for access by developers and administrators

Composable
Applications are composed from multiple Microservices

Automated
The lifecycle of a Microservice is managed through automation that includes development, build, test, staging, production and distribution

服務(wù)之間如何通信

一般同步調(diào)用比較簡單，一致性強(qiáng)，但是容易出調(diào)用問題，性能體驗上也會差些，特別是調(diào)用層次多的時候。RESTful和RPC的比較也是一個很有意思的話題。一般REST基于HTTP，更容易實現(xiàn)，更容易被接受，服務(wù)端實現(xiàn)技術(shù)也更靈活些，各個語言都能支持，同時能跨客戶端，對客戶端沒有特殊的要求，只要封裝了HTTP的SDK就能調(diào)用，所以相對使用的廣一些。RPC也有自己的優(yōu)點(diǎn)，傳輸協(xié)議更高效，安全更可控，特別在一個公司內(nèi)部，如果有統(tǒng)一個的開發(fā)規(guī)范和統(tǒng)一的服務(wù)框架時，他的開發(fā)效率優(yōu)勢更明顯些。

就看各自的技術(shù)積累實際條件，自己的選擇了。而異步消息的方式在分布式系統(tǒng)中有特別廣泛的應(yīng)用，他既能減低調(diào)用服務(wù)之間的耦合，又能成為調(diào)用之間的緩沖，確保消息積壓不會沖垮被調(diào)用方，同時能保證調(diào)用方的服務(wù)體驗，繼續(xù)干自己該干的活，不至于被后臺性能拖慢。

不過需要付出的代價是一致性的減弱，需要接受數(shù)據(jù)最終一致性；還有就是后臺服務(wù)一般要實現(xiàn)冪等性，因為消息發(fā)送出于性能的考慮一般會有重復(fù)（保證消息的被收到且僅收到一次對性能是很大的考驗）；最后就是必須引入一個獨(dú)立的broker，如果公司內(nèi)部沒有技術(shù)積累，對broker分布式管理也是一個很大的挑戰(zhàn)。

微服務(wù)優(yōu)點(diǎn)

每個微服務(wù)都很小，這樣能聚焦一個指定的業(yè)務(wù)功能或業(yè)務(wù)需求。
微服務(wù)能夠被小團(tuán)隊單獨(dú)開發(fā)，這個小團(tuán)隊是2到5人的開發(fā)人員組成。
微服務(wù)是松耦合的，是有功能意義的服務(wù)，無論是在開發(fā)階段或部署階段都是獨(dú)立的。
微服務(wù)能使用不同的語言開發(fā)。
微服務(wù)允許容易且靈活的方式集成自動部署，通過持續(xù)集成工具，如Jenkins, bamboo 。
一個團(tuán)隊的新成員能夠更快投入生產(chǎn)。
微服務(wù)易于被一個開發(fā)人員理解，修改和維護(hù)，這樣小團(tuán)隊能夠更關(guān)注自己的工作成果。無需通過合作才能體現(xiàn)價值。
微服務(wù)允許你利用融合最新技術(shù)。
微服務(wù)只是業(yè)務(wù)邏輯的代碼，不會和html,css 或其他界面組件混合。
微服務(wù)能夠即時被要求擴(kuò)展。
微服務(wù)能部署中低端配置的服務(wù)器上。
易于和第三方集成。
每個微服務(wù)都有自己的存儲能力，可以有自己的數(shù)據(jù)庫。也可以有統(tǒng)一數(shù)據(jù)庫。

微服務(wù)架構(gòu)的缺點(diǎn)

微服務(wù)架構(gòu)可能帶來過多的操作。
需要DevOps技巧 (http://en.wikipedia.org/wiki/DevOps).
可能雙倍的努力。
分布式系統(tǒng)可能復(fù)雜難以管理。
因為分布部署跟蹤問題難。
當(dāng)服務(wù)數(shù)量增加，管理復(fù)雜性增加。

需要考慮的問題

單個微服務(wù)代碼量小，易修改和維護(hù)。但是，系統(tǒng)復(fù)雜度的總量是不變的，每個服務(wù)代碼少了，但服務(wù)的個數(shù)肯定就多了。就跟拼圖游戲一樣，切的越碎，越難拼出整幅圖。一個系統(tǒng)被拆分成零碎的微服務(wù)，最后要集成為一個完整的系統(tǒng)，其復(fù)雜度肯定比大塊的功能集成要高很多。
單個微服務(wù)數(shù)據(jù)獨(dú)立，可獨(dú)立部署和運(yùn)行。雖然微服務(wù)本身是可以獨(dú)立部署和運(yùn)行的，但仍然避免不了業(yè)務(wù)上的你來我往，這就涉及到要對外通信，當(dāng)微服務(wù)的數(shù)量達(dá)到一定量級的時候，如何提供一個高效的集群通信機(jī)制成為一個問題。
單個微服務(wù)擁有自己的進(jìn)程，進(jìn)程本身就可以動態(tài)的啟停，為無縫升級的打好了基礎(chǔ)，但誰來啟動和停止進(jìn)程，什么時機(jī)，選擇在哪臺設(shè)備上做這件事情才是無縫升級的關(guān)鍵。這個能力并不是微服務(wù)本身提供的，而是需要背后強(qiáng)大的版本管理和部署能力。
多個相同的微服務(wù)可以做負(fù)載均衡，提高性能和可靠性。正是因為相同微服務(wù)可以有多個不同實例，讓服務(wù)按需動態(tài)伸縮成為可能，在高峰期可以啟動更多的相同的微服務(wù)實例為更多用戶服務(wù)，以此提高響應(yīng)速度。同時這種機(jī)制也提供了高可靠性，在某個微服務(wù)故障后，其他相同的微服務(wù)可以接替其工作，對外表現(xiàn)為某個設(shè)備故障后業(yè)務(wù)不中斷。同樣的道理，微服務(wù)本身是不會去關(guān)心系統(tǒng)負(fù)載的，那么什么時候應(yīng)該啟動更多的微服務(wù)，多個微服務(wù)的流量應(yīng)該如何調(diào)度和分發(fā)，這背后也有一套復(fù)雜的負(fù)載監(jiān)控和均衡的系統(tǒng)在起作用。
微服務(wù)可以獨(dú)立部署和對外提供服務(wù)，微服務(wù)的業(yè)務(wù)上線和下線是動態(tài)的，當(dāng)一個新的微服務(wù)上線時，用戶是如何訪問到這種新的服務(wù)？這就需要有一個統(tǒng)一的入口，新的服務(wù)可以動態(tài)的注冊到這個入口上，用戶每次訪問時可以從這個入口拿到系統(tǒng)所有服務(wù)的訪問地址。這個統(tǒng)一的系統(tǒng)入口并不是微服務(wù)本身的一部分，所以這種能力需要系統(tǒng)單獨(dú)提供。
還有一些企業(yè)級關(guān)注的系統(tǒng)問題，比如，安全策略如何集中管理？系統(tǒng)故障如何快速審計和跟蹤到具體服務(wù)？整個系統(tǒng)狀態(tài)如何監(jiān)控？服務(wù)之間的依賴關(guān)系如何管理？等等這些問題都不是單個微服務(wù)考慮的范疇，而需要有一個系統(tǒng)性的考慮和設(shè)計，讓每個微服務(wù)都能夠按照系統(tǒng)性的要求和約束提供對應(yīng)的安全性，可靠性，可維護(hù)性的能力。

API為什么很重要

•服務(wù)價值的精華體現(xiàn)
•可靠、可用、可讀
•只有一次機(jī)會

實現(xiàn)一個API網(wǎng)關(guān)作為所有客戶端的唯一入口。API網(wǎng)關(guān)有兩種方式來處理請求。有些請求被簡單地代理/路由到合適的服務(wù)上，其他的請求被轉(zhuǎn)給到一組服務(wù)。

相比于提供普適的API，API網(wǎng)關(guān)根據(jù)不同的客戶端開放不同的API。比如，Netflix API網(wǎng)關(guān)運(yùn)行著客戶端特定的適配器代碼，會向客戶端提供最適合其需求的API。

API網(wǎng)關(guān)也可以實現(xiàn)安全性，比如驗證客戶端是否被授權(quán)進(jìn)行某請求。

設(shè)計要素

•Version
•RequstID
•Auth&Signature
•RateLimit
•Docs
•ErrorCode&Message

微服務(wù)治理

•按需伸縮
–部署與監(jiān)控運(yùn)維成本
•獨(dú)立部署
–機(jī)器數(shù)量與部署成本
•業(yè)務(wù)獨(dú)立
–服務(wù)依賴、治理，版本管理、事務(wù)處理
•技術(shù)多樣性
–環(huán)境部署成本、約定成本

•運(yùn)行狀態(tài)治理
–監(jiān)控、限流、SLA、LB、日志分析
•服務(wù)注冊與發(fā)現(xiàn)
•部署
–快速、復(fù)制、擴(kuò)容
–單機(jī)開發(fā)
•調(diào)用
–安全、容錯、服務(wù)降級、調(diào)用延時

服務(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)站癱瘓。

服務(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ù)。在運(yùn)行環(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)運(yùn)行時配置，能夠在運(yùn)行時針對不同環(huán)境動態(tài)調(diào)整服務(wù)的參數(shù)和配置。
限流和容錯，框架集成限流容錯組件，能夠在運(yùn)行時自動限流和容錯，保護(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模塊就是一個強(qiáng)大的管理接口。
統(tǒng)一錯誤處理，對于框架層和服務(wù)的內(nèi)部異常，如果框架層能夠統(tǒng)一處理并記錄日志，對服務(wù)監(jiān)控和快速問題定位有很大幫助。
安全，安全和訪問控制邏輯可以在框架層統(tǒng)一進(jìn)行封裝，可做成插件形式，具體業(yè)務(wù)服務(wù)根據(jù)需要加載相關(guān)安全插件。
文檔自動生成，文檔的書寫和同步一直是一個痛點(diǎn)，框架層如果能支持文檔的自動生成和同步，會給使用API的開發(fā)和測試人員帶來極大便利。Swagger是一種流行Restful API的文檔方案。

微服務(wù)系統(tǒng)底座

一個完整的微服務(wù)系統(tǒng)，它的底座最少要包含以下功能：

日志和審計，主要是日志的匯總，分類和查詢
監(jiān)控和告警，主要是監(jiān)控每個服務(wù)的狀態(tài)，必要時產(chǎn)生告警
消息總線，輕量級的MQ或HTTP
注冊發(fā)現(xiàn)
負(fù)載均衡
部署和升級
事件調(diào)度機(jī)制
資源管理，如：底層的虛擬機(jī)，物理機(jī)和網(wǎng)絡(luò)管理

以下功能不是最小集的一部分，但也屬于底座功能：

認(rèn)證和鑒權(quán)
微服務(wù)統(tǒng)一代碼框架，支持多種編程語言
統(tǒng)一服務(wù)構(gòu)建和打包
統(tǒng)一服務(wù)測試
微服務(wù)CI/CD流水線
服務(wù)依賴關(guān)系管理
統(tǒng)一問題跟蹤調(diào)試框架，俗稱調(diào)用鏈
灰度發(fā)布
藍(lán)綠部署

容器（Docker）與微服務(wù)

•容器夠小
–解決微服務(wù)對機(jī)器數(shù)量的訴求
•容器獨(dú)立
–解決多語言問題
•開發(fā)環(huán)境與生產(chǎn)環(huán)境相同
–單機(jī)開發(fā)、提升效率
•容器效率高
–省錢
•代碼/image一體化
–可復(fù)用管理系統(tǒng)
•容器的橫向與縱向擴(kuò)容
–可復(fù)制
–可動態(tài)調(diào)節(jié)CPU與內(nèi)存

容器(Docker)與微服務(wù)

•Image管理
•系統(tǒng)安全管理
•授權(quán)管理
•系統(tǒng)成熟度
•社區(qū)成熟度

開發(fā)方式影響

隨著持續(xù)交付概念推廣以及Docker容器普及，微服務(wù)將這兩種理念和技術(shù)結(jié)合起來，形成新的微服務(wù)+API + 平臺的開發(fā)模式，提出了容器化微服務(wù)的持續(xù)交付概念。
下圖傳統(tǒng)Monolithic的DevOps開發(fā)隊伍方式：

這種整體型架構(gòu)要求產(chǎn)品隊伍橫跨產(chǎn)品管理 Dev開發(fā) QA DBA 以及系統(tǒng)運(yùn)營管理，而微服務(wù)架構(gòu)引入以后，如下圖：

微服務(wù)促進(jìn)了DevOps方式的重組，將一個大臃腫的整體產(chǎn)品開發(fā)隊伍切分為根據(jù)不同微服務(wù)的劃分的產(chǎn)品隊伍，以及一個大的整體的平臺隊伍負(fù)責(zé)運(yùn)營管理，兩者之間通過API交互，做到了松耦合隔絕。

首先需要考慮構(gòu)建DevOps能力，這是保證微服務(wù)架構(gòu)在持續(xù)交付和應(yīng)對復(fù)雜運(yùn)維問題的動力之源；
其次保持服務(wù)持續(xù)演進(jìn)，使之能夠快速、低成本地被拆分和合并，以快速響應(yīng)業(yè)務(wù)的變化；
同時要保持團(tuán)隊和架構(gòu)對齊。微服務(wù)貌似是技術(shù)層面的變革，但它對團(tuán)隊結(jié)構(gòu)和組織文化有很強(qiáng)的要求和影響。識別和構(gòu)建匹配架構(gòu)的團(tuán)隊是解決問題的另一大支柱。
最后，打造持續(xù)改進(jìn)的自組織文化是實施微服務(wù)的關(guān)鍵基石。只有持續(xù)改進(jìn)，持續(xù)學(xué)習(xí)和反饋，持續(xù)打造這樣一個文化氛圍和團(tuán)隊，微服務(wù)架構(gòu)才能持續(xù)發(fā)展下去，保持新鮮的生命力，從而實現(xiàn)我們的初衷。

微服務(wù)的實施是有一定的先決條件：基礎(chǔ)的運(yùn)維能力（如監(jiān)控、快速配置、快速部署）需提前構(gòu)建，否則就會陷入如我們般被動的局面。推薦采用基礎(chǔ)設(shè)施及代碼的實踐，通過代碼來描述計算和網(wǎng)絡(luò)基礎(chǔ)設(shè)施的方法，使得圖案度i可以快速安全的搭建和處理由新的配置代替的服務(wù)器，服務(wù)器之間可以擁有更高的一致性，降低了在“我的環(huán)境工作，而你的環(huán)境不工作”的可能，也是為后續(xù)的發(fā)布策略和運(yùn)維提供更好的支撐。