什么是微服務(wù)？
微服務(wù)(Microservices Architecture)是一種架構(gòu)風格，一個大型復雜軟件應(yīng)用由一個或多個微服務(wù)組成。系統(tǒng)中的各個微服務(wù)可被獨立部署，各個微服務(wù)之間是松耦合的。每個微服務(wù)僅關(guān)注于完成一件任務(wù)并很好地完成該任務(wù)。在所有情況下，每個任務(wù)代表著一個小的業(yè)務(wù)能力。
單體架構(gòu)(Monolithic Architecture )
企業(yè)級的應(yīng)用一般都會面臨各種各樣的業(yè)務(wù)需求，而常見的方式是把大量功能堆積到同一個單體架構(gòu)中去。比如：常見的ERP、CRM等系統(tǒng)都以單體架構(gòu)的方式運行，同時由于提供了大量的業(yè)務(wù)功能，隨著功能的升級，整個研發(fā)、發(fā)布、定位問題，擴展，升級這樣一個“怪物”系統(tǒng)會變得越來越困難。
這種架構(gòu)模式就是把應(yīng)用整體打包部署，具體的樣式依賴本身應(yīng)用采用的語言，如果采用java語言，自然你會打包成war包，部署在Tomcat或者Jetty這樣的應(yīng)用服務(wù)器上，如果你使用spring boot還可以打包成jar包部署。其他還有Rails和Node.js應(yīng)用以目錄層次的形式打包
上圖：單體架構(gòu)
大部分企業(yè)通過SOA來解決上述問題，SOA的思路是把應(yīng)用中相近的功能聚合到一起，以服務(wù)的形式提供出去。因此基于SOA架構(gòu)的應(yīng)用可以理解為一批服務(wù)的組合。SOA帶來的問題是，引入了大量的服務(wù)、消息格式定義和規(guī)范。
多數(shù)情況下，SOA的服務(wù)直接相互獨立，但是部署在同一個運行環(huán)境中（類似于一個Tomcat實例下，運行了很多web應(yīng)用）。和單體架構(gòu)類似，隨著業(yè)務(wù)功能的增多SOA的服務(wù)會變得越來越復雜，本質(zhì)上看沒有因為使用SOA而變的更好。圖1，是一個包含多種服務(wù)的在線零售網(wǎng)站，所有的服務(wù)部署在一個運行環(huán)境中，是一個典型的單體架構(gòu)。
單體架構(gòu)的應(yīng)用一般有以下特點：
設(shè)計、開發(fā)、部署為一個單獨的單元。
會變得越來越復雜，后導致維護、升級、新增功能變得異常困難
很難以敏捷研發(fā)模式進行開發(fā)和發(fā)布
部分更新，都需要重新部署整個應(yīng)用
水平擴展：必須以應(yīng)用為單位進行擴展，在資源需求有沖突時擴展變得比較困難（部分服務(wù)需要更多的計算資源，部分需要更多內(nèi)存資源）
可用性：一個服務(wù)的不穩(wěn)定會導致整個應(yīng)用出問題
創(chuàng)新困難：很難引入新的技術(shù)和框架，所有的功能都構(gòu)建在同質(zhì)的框架之上
運維困難：變更或升級的影響分析困難，任何一個小修改都可能導致單體應(yīng)用整體運行出現(xiàn)故障。
微服務(wù)架構(gòu)（Microservices Architecture）
微服務(wù)架構(gòu)的核心思想是，一個應(yīng)用是由多個小的、相互獨立的、微服務(wù)組成，這些服務(wù)運行在自己的進程中，開發(fā)和發(fā)布都沒有依賴。不同服務(wù)通過一些輕量級交互機制來通信，例如 RPC、HTTP 等，服務(wù)可獨立擴展伸縮，每個服務(wù)定義了明確的邊界，不同的服務(wù)甚至可以采用不同的編程語言來實現(xiàn)，由獨立的團隊來維護。簡單的來說，一個系統(tǒng)的不同模塊轉(zhuǎn)變成不同的服務(wù)！而且服務(wù)可以使用不同的技術(shù)加以實現(xiàn)！
上圖：微服務(wù)架構(gòu)
微服務(wù)設(shè)計
那我們在微服務(wù)中應(yīng)該怎樣設(shè)計呢。以下是微服務(wù)的設(shè)計指南：
職責單一原則（Single Responsibility Principle）：把某一個微服務(wù)的功能聚焦在特定業(yè)務(wù)或者有限的范圍內(nèi)會有助于敏捷開發(fā)和服務(wù)的發(fā)布。
設(shè)計階段就需要把業(yè)務(wù)范圍進行界定。
需要關(guān)心微服務(wù)的業(yè)務(wù)范圍，而不是服務(wù)的數(shù)量和規(guī)模盡量小。數(shù)量和規(guī)模需要依照業(yè)務(wù)功能而定。
于SOA不同，某個微服務(wù)的功能、操作和消息協(xié)議盡量簡單。
項目初期把服務(wù)的范圍制定相對寬泛，隨著深入，進一步重構(gòu)服務(wù)，細分微服務(wù)是個很好的做法。
微服務(wù)消息
在單體架構(gòu)中，不同功能之間通信通過方法調(diào)用，或者跨語言通信。SOA降低了這種語言直接的耦合度，采用基于SOAP協(xié)議的web服務(wù)。這種web服務(wù)的功能和消息體定義都十分復雜，微服務(wù)需要更輕量的機制。
同步消息 REST
同步消息就是客戶端需要保持等待，直到服務(wù)器返回應(yīng)答。REST是微服務(wù)中默認的同步消息方式，它提供了基于HTTP協(xié)議和資源API風格的簡單消息格式，多數(shù)微服務(wù)都采用這種方式（每個功能代表了一個資源和對應(yīng)的操作）
異步消息 – AMQP, STOMP, MQTT
異步消息就是客戶端不需要一直等待服務(wù)應(yīng)答，有應(yīng)到后會得到通知。某些微服務(wù)需要用到異步消息，一般采用AMQP, STOMP, MQTT 這三種通訊協(xié)議
消息格式 – JSON, XML, Thrift, ProtoBuf, Avro
消息格式是微服務(wù)中另外一個很重要的因素。SOA的web服務(wù)一般采用文本消息，基于復雜的消息格式（SOAP）和消息定義（xsd）。微服務(wù)采用簡單的文本協(xié)議JSON和XML，基于HTTP的資源API風格。如果需要二進制，通過用到Thrift, ProtoBuf, Avro。
服務(wù)約定 – 定義接口 – Swagger, RAML, Thrift IDL
如果把功能實現(xiàn)為服務(wù)，并發(fā)布，需要定義一套約定。單體架構(gòu)中，SOA采用WSDL，WSDL過于復雜并且和SOAP緊耦合，不適合微服務(wù)。
REST設(shè)計的微服務(wù)，通常采用Swagger和RAML定義約定。
對于不是基于REST設(shè)計的微服務(wù)，比如Thrift，通常采用IDL（Interface Definition Languages），比如Thrift IDL。
微服務(wù)集成 (服務(wù)間通信)
大部分微服務(wù)基于RPC、HTTP、JSON這樣的標準協(xié)議，集成不同標準和格式變的不再重要。另外一個選擇是采用輕量級的消息總線或者網(wǎng)關(guān)，有路由功能，沒有復雜的業(yè)務(wù)邏輯。下面就介紹幾種常見的架構(gòu)方式。
點對點方式
點對點方式中，服務(wù)之間直接用。每個微服務(wù)都開放REST API，并且調(diào)用其它微服務(wù)的接口。
上圖：通過點對點方式通信
很明顯，在比較簡單的微服務(wù)應(yīng)用場景下，這種方式還可行，隨著應(yīng)用復雜度的提升，會變得越來越不可維護。這點有些類似SOA的ESB，盡量不采用點對點的集成方式。
API-網(wǎng)關(guān)方式
API網(wǎng)關(guān)方式的核心要點是，所有的客戶端和消費端都通過統(tǒng)一的網(wǎng)關(guān)接入微服務(wù)，在網(wǎng)關(guān)層處理所有的非業(yè)務(wù)功能個。通常，網(wǎng)關(guān)也是提供REST/HTTP的訪問API。服務(wù)端通過API-GW注冊和管理服務(wù)。
上圖：通過API-網(wǎng)關(guān)暴露微服務(wù)
所有的業(yè)務(wù)接口通過API網(wǎng)關(guān)暴露，是所有客戶端接口的入口。微服務(wù)之間的通信也通過API網(wǎng)關(guān)。\
采用網(wǎng)關(guān)方式有如下優(yōu)勢：
有能力為微服務(wù)接口提供網(wǎng)關(guān)層次的抽象。比如：微服務(wù)的接口可以各種各樣，在網(wǎng)關(guān)層，可以對外暴露統(tǒng)一的規(guī)范接口。
輕量的消息路由、格式轉(zhuǎn)換。
統(tǒng)一控制安全、監(jiān)控、限流等非業(yè)務(wù)功能。
每個微服務(wù)會變得更加輕量，非業(yè)務(wù)功能個都在網(wǎng)關(guān)層統(tǒng)一處理，微服務(wù)只需要關(guān)注業(yè)務(wù)邏輯
目前，API網(wǎng)關(guān)方式應(yīng)該是微服務(wù)架構(gòu)中應(yīng)用廣泛的設(shè)計模式。
消息代理方式
微服務(wù)也可以集成在異步的場景下，通過隊列和訂閱主題，實現(xiàn)消息的發(fā)布和訂閱。一個微服務(wù)可以是消息的發(fā)布者，把消息通過異步的方式發(fā)送到隊列或者訂閱主題下。作為消費者的微服務(wù)可以從隊列或者主題共獲取消息。通過消息中間件把服務(wù)之間的直接調(diào)用解耦。
上圖：異步通信方式
通常異步的生產(chǎn)者/消費者模式，通過AMQP, STOMP, MQTT 等異步消息通訊協(xié)議規(guī)范。
數(shù)據(jù)的去中心化
單體架構(gòu)中，不同功能的服務(wù)模塊都把數(shù)據(jù)存儲在某個中心數(shù)據(jù)庫中。
每個微服務(wù)有自己私有的數(shù)據(jù)庫，其它微服務(wù)不能直接訪問。單體架構(gòu)，用一個數(shù)據(jù)庫存儲所有數(shù)據(jù)
微服務(wù)方式，多個服務(wù)之間的設(shè)計相互獨立，數(shù)據(jù)也應(yīng)該相互獨立（比如，某個微服務(wù)的數(shù)據(jù)庫結(jié)構(gòu)定義方式改變，可能會中斷其它服務(wù)）。因此，每個微服務(wù)都應(yīng)該有自己的數(shù)據(jù)庫。
每個微服務(wù)有自己私有的數(shù)據(jù)庫，其它微服務(wù)不能直接訪問。每個微服務(wù)有自己私有的數(shù)據(jù)庫，其它微服務(wù)不能直接訪問。
數(shù)據(jù)去中心話的核心要點：
每個微服務(wù)有自己私有的數(shù)據(jù)庫持久化業(yè)務(wù)數(shù)據(jù)
每個微服務(wù)只能訪問自己的數(shù)據(jù)庫，而不能訪問其它服務(wù)的數(shù)據(jù)庫
某些業(yè)務(wù)場景下，需要在一個事務(wù)中更新多個數(shù)據(jù)庫。這種情況也不能直接訪問其它微服務(wù)的數(shù)據(jù)庫，而是通過對于微服務(wù)進行操作。
數(shù)據(jù)的去中心化，進一步降低了微服務(wù)之間的耦合度，不同服務(wù)可以采用不同的數(shù)據(jù)庫技術(shù)（SQL、NoSQL等）。在復雜的業(yè)務(wù)場景下，如果包含多個微服務(wù)，通常在客戶端或者中間層（網(wǎng)關(guān)）處理。
微服務(wù)架構(gòu)的優(yōu)點：
每個服務(wù)都比較簡單，只關(guān)注于一個業(yè)務(wù)功能。
微服務(wù)架構(gòu)方式是松耦合的，可以提供更高的靈活性。
微服務(wù)可通過佳及合適的不同的編程語言與工具進行開發(fā)，能夠做到有的放矢地解決針對性問題。
每個微服務(wù)可由不同團隊獨立開發(fā)，互不影響，加快推出市場的速度。
微服務(wù)架構(gòu)是持續(xù)交付(CD)的巨大推動力，允許在頻繁發(fā)布不同服務(wù)的同時保持系統(tǒng)其他部分的可用性和穩(wěn)定性。
微服務(wù)架構(gòu)的缺點：
微服務(wù)的一些想法在實踐上是好的，但當整體實現(xiàn)時也會呈現(xiàn)出其復雜性。
運維開銷及成本增加：整體應(yīng)用可能只需部署至一小片應(yīng)用服務(wù)區(qū)集群，而微服務(wù)架構(gòu)可能變成需要構(gòu)建/測試/部署/運行數(shù)十個獨立的服務(wù)，并可能需要支持多種語言和環(huán)境。這導致一個整體式系統(tǒng)如果由20個微服務(wù)組成，可能需要40~60個進程。
必須有堅實的DevOps開發(fā)運維一體化技能：開發(fā)人員需要熟知運維與投產(chǎn)環(huán)境，開發(fā)人員也需要掌握必要的數(shù)據(jù)存儲技術(shù)如NoSQL，具有較強DevOps技能的人員比較稀缺，會帶來招聘人才方面的挑戰(zhàn)。
隱式接口及接口匹配問題：把系統(tǒng)分為多個協(xié)作組件后會產(chǎn)生新的接口，這意味著簡單的交叉變化可能需要改變許多組件，并需協(xié)調(diào)一起發(fā)布。在實際環(huán)境中，一個新品發(fā)布可能被迫同時發(fā)布大量服務(wù)，由于集成點的大量增加，微服務(wù)架構(gòu)會有更高的發(fā)布風險。
代碼重復：某些底層功能需要被多個服務(wù)所用，為了避免將“同步耦合引入到系統(tǒng)中”，有時需要向不同服務(wù)添加一些代碼，這就會導致代碼重復。
分布式系統(tǒng)的復雜性：作為一種分布式系統(tǒng)，微服務(wù)引入了復雜性和其他若干問題，例如網(wǎng)絡(luò)延遲、容錯性、消息序列化、不可靠的網(wǎng)絡(luò)、異步機制、版本化、差異化的工作負載等，開發(fā)人員需要考慮以上的分布式系統(tǒng)問題。
異步機制：微服務(wù)往往使用異步編程、消息與并行機制，如果應(yīng)用存在跨微服務(wù)的事務(wù)性處理，事務(wù)的實現(xiàn)更具挑戰(zhàn)性，其實現(xiàn)機制會變得復雜化。
可測性的挑戰(zhàn)：在動態(tài)環(huán)境下服務(wù)間的交互會產(chǎn)生非常微妙的行為，難以可視化及全面測試。經(jīng)典微服務(wù)往往不太重視測試，更多的是通過監(jiān)控發(fā)現(xiàn)生產(chǎn)環(huán)境的異常，進而快速回滾或采取其他必要的行動。但對于特別在意風險規(guī)避監(jiān)管或投產(chǎn)環(huán)境錯誤會產(chǎn)生顯著影響的場景下需要特別注意。
關(guān)于微服務(wù)架構(gòu)的取舍
在合適的項目，合適的團隊，采用微服務(wù)架構(gòu)收益會大于成本。
微服務(wù)架構(gòu)有很多吸引人的地方，但在擁抱微服務(wù)之前，也需要認清它所帶來的挑戰(zhàn)。
需要避免為了“微服務(wù)”而“微服務(wù)”。
微服務(wù)架構(gòu)引入策略 – 對傳統(tǒng)企業(yè)而言，開始時可以考慮引入部分合適的微服務(wù)架構(gòu)原則對已有系統(tǒng)進行改造或新建微服務(wù)應(yīng)用，逐步探索及積累微服務(wù)架構(gòu)經(jīng)驗，而非全盤實施微服務(wù)架構(gòu)。
本站文章版權(quán)歸原作者及原出處所有 。內(nèi)容為作者個人觀點， 并不代表本站贊同其觀點和對其真實性負責，本站只提供參考并不構(gòu)成任何投資及應(yīng)用建議。本站是一個個人學習交流的平臺，網(wǎng)站上部分文章為轉(zhuǎn)載，并不用于任何商業(yè)目的，我們已經(jīng)盡可能的對作者和來源進行了通告，但是能力有限或疏忽，造成漏登，請及時聯(lián)系我們，我們將根據(jù)著作權(quán)人的要求，立即更正或者刪除有關(guān)內(nèi)容。本站擁有對此聲明的最終解釋權(quán)。
