淺識微服務架構_ZenDei技術網路在線

ref:https://blog.csdn.net/wuxiaobingandbob/article/details/78642020?fps=1&locationNum=1 http://www.cnblogs.com/imyalost/p/6792724.html http://www.cnbl ...

什麼是微服務架構

在介紹微服務時，首先得先理解什麼是微服務，顧名思義，微服務得從兩個方面去理解，什麼是"微"、什麼是"服務"，微狹義來講就是體積小、著名的"2 pizza 團隊"很好的詮釋了這一解釋（2

pizza 團隊最早是亞馬遜 CEO Bezos提出來的，意思是說單個服務的設計，所有參與人從設計、開發、測試、運維所有人加起來只需要2個披薩就夠了）。而所謂服務，一定要區別於系統，服務

一個或者一組相對較小且獨立的功能單元，是用戶可以感知最小功能集。微服務是指開發一個單個小型的但有業務功能的服務，每個服務都有自己的處理和輕量通訊機制，可以部署在單個或多個

伺服器上。微服務也指一種種松耦合的、有一定的有界上下文的面向服務架構。也就是說，如果每個服務都要同時修改，那麼它們就不是微服務，因為它們緊耦合在一起；如果你需要掌握一個服

務太多的上下文場景使用條件，那麼它就是一個有上下文邊界的服務，這個定義來自DDD領域驅動設計。

　　微服務架構（Microservice Architecture）是一種架構概念，旨在通過將功能分解到各個離散的服務中以實現對解決方案的解耦。你可以將其看作是在架構層次而非獲取服務的類上應用很多

SOLID原則。微服務架構是個很有趣的概念，它的主要作用是將功能分解到離散的各個服務當中，從而降低系統的耦合性，並提供更加靈活的服務支持。

　　概念：把一個大型的單個應用程式和服務拆分為數個甚至數十個的支持微服務，它可擴展單個組件而不是整個的應用程式堆棧，從而滿足服務等級協議。

　　定義：圍繞業務領域組件來創建應用，這些應用可獨立地進行開發、管理和迭代。在分散的組件中使用雲架構和平臺式部署、管理和服務功能，使產品交付變得更加簡單。

　　本質：用一些功能比較明確、業務比較精練的服務去解決更大、更實際的問題。

微服務由來

　　微服務最早由Martin Fowler與James Lewis於2014年共同提出，微服務架構風格是一種使用一套小服務來開發單個應用的方式途徑，每個服務運行在自己的進程中，並使用輕量級機制通信，

通常是HTTP API，這些服務基於業務能力構建，並能夠通過自動化部署機制來獨立部署，這些服務使用不同的編程語言實現，以及不同數據存儲技術，並保持最低限度的集中式管理。

　　微服務（Microservice）這個概念是2012年出現的，作為加快Web和移動應用程式開發進程的一種方法，2014年開始受到各方的關註，而2015年，可以說是微服務的元年；越來越多的論壇、

社區、blog以及互聯網行業巨頭開始對微服務進行討論、實踐，可以說這樣更近一步推動了微服務的發展和創新。而微服務的流行，Martin Fowler功不可沒。這老頭是個奇人，特別擅長抽象歸納

和製造概念。特別是微服務這種新生的名詞，都有一個特點：一解釋就懂，一問就不知，一討論就打架。

　　Martin Fowler是國際著名的OO專家，敏捷開發方法的創始人之一，現為ThoughtWorks公司的首席科學家。在面向對

　　象分析設計、UML、模式、軟體開發方法學、XP、重構等方面，都是世界頂級的專家，現為Thought Works公司的首

　　席科學家。Thought Works是一家從事企業應用開發和——集成的公司。早在20世紀80年代，Fowler就是使用對象技

　　術構建多層企業應用的倡導者，他著有幾本經典書籍：《企業應用架構模式》、《UML精粹》和《重構》等。

　　　　　　　　　　　　　　　　　　　———— 百度百科

為什麼需要微服務？

在傳統的IT行業軟體大多都是各種獨立系統的堆砌，這些系統的問題總結來說就是擴展性差，可靠性不高，維護成本高。到後面引入了SOA服務化，但是，由於 SOA 早期均使用了匯流排模

式，這種匯流排模式是與某種技術棧強綁定的，比如：J2EE。這導致很多企業的遺留系統很難對接，切換時間太長，成本太高，新系統穩定性的收斂也需要一些時間。最終 SOA 看起來很美，但卻

成為了企業級奢侈品，中小公司都望而生畏。

　　技術為業務而生，架構也為業務而出現，當然SOA和微服務也是因為業務的發展而出現。出現SOA和微服務框架與業務的發展、平臺的壯大密不可分，下麵借用dubbo的網站架構發展圖和說

明：

單一應用架構
- 當網站流量很小時，只需一個應用，將所有功能都部署在一起，以減少部署節點和成本。
- 此時，用於簡化增刪改查工作量的數據訪問框架(ORM) 是關鍵。
垂直應用架構
- 當訪問量逐漸增大，單一應用增加機器帶來的加速度越來越小，將應用拆成互不相干的幾個應用，以提升效率。
- 此時，用於加速前端頁面開發的 Web框架(MVC) 是關鍵。
分散式服務架構
- 當垂直應用越來越多，應用之間交互不可避免，將核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。
- 此時，用於提高業務復用及整合的 分散式服務框架(RPC) 是關鍵。
流動計算架構
- 當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個調度中心基於訪問壓力實時管理集群容量，提高集群利用率。
- 此時，用於提高機器利用率的 資源調度和治理中心(SOA) 是關鍵。

　　平臺隨著業務的發展從 All in One 環境就可以滿足業務需求（以Java來說，可能只是一兩個war包就解決了）；發展到需要拆分多個應用，並且採用MVC的方式分離前後端，加快開發效率；在

發展到服務越來越多，不得不將一些核心或共用的服務拆分出來，其實發展到此階段，如果服務拆分的足夠精細，並且獨立運行，我覺得就可以將之理解為一個微服務了。

　　一、最期的單體架構帶來的問題

　　單體架構在規模比較小的情況下工作情況良好，但是隨著系統規模的擴大，它暴露出來的問題也越來越多，主要有以下幾點：

　　1.複雜性逐漸變高

比如有的項目有幾十萬行代碼，各個模塊之間區別比較模糊，邏輯比較混亂，代碼越多複雜性越高，越難解決遇到的問題。

　　2.技術債務逐漸上升

公司的人員流動是再正常不過的事情，有的員工在離職之前，疏於代碼質量的自我管束，導致留下來很多坑，由於單體項目代碼量龐大的驚人，留下的坑很難被髮覺，這就給新來的員工帶來很大的煩惱，人員流動越大所留下的坑越多，也就是所謂的技術債務越來越多。

　　3.部署速度逐漸變慢

這個就很好理解了，單體架構模塊非常多，代碼量非常龐大，導致部署項目所花費的時間越來越多，曾經有的項目啟動就要一二十分鐘，這是多麼恐怖的事情啊，啟動幾次項目一天的時間就過去了，留給開發者開發的時間就非常少了。

　　4.阻礙技術創新

比如以前的某個項目使用struts2寫的，由於各個模塊之間有著千絲萬縷的聯繫，代碼量大，邏輯不夠清楚，如果現在想用spring mvc來重構這個項目將是非常困難的，付出的成本將非常大，所以更多的時候公司不得不硬著頭皮繼續使用老的struts架構，這就阻礙了技術的創新。

　　5.無法按需伸縮

比如說電影模塊是CPU密集型的模塊，而訂單模塊是IO密集型的模塊，假如我們要提升訂單模塊的性能，比如加大記憶體、增加硬碟，但是由於所有的模塊都在一個架構下，因此我們在擴展訂單模塊的性能時不得不考慮其它模塊的因素，因為我們不能因為擴展某個模塊的性能而損害其它模塊的性能，從而無法按需進行伸縮。

　　二、微服務與單體架構區別

單體架構所有的模塊全都耦合在一塊，代碼量大，維護困難，微服務每個模塊就相當於一個單獨的項目，代碼量明顯減少，遇到問題也相對來說比較好解決。
單體架構所有的模塊都共用一個資料庫，存儲方式比較單一，微服務每個模塊都可以使用不同的存儲方式（比如有的用redis，有的用mysql等），資料庫也是單個模塊對應自己的資料庫。
單體架構所有的模塊開發所使用的技術一樣，微服務每個模塊都可以使用不同的開發技術，開發模式更靈活。

　　三、微服務與SOA區別　　

　　1、SOA喜歡重用，微服務喜歡重寫

　　SOA的主要目的是為了企業各個系統更加容易地融合在一起。說到SOA不得不說ESB(EnterpriseService Bus)。 ESB是什麼? 可以把ESB想象成一個連接所有企業級服務的腳手架。通過

service broker，它可以把不同數據格式或模型轉成canonical格式，把XML的輸入轉成CSV傳給legacy服務，把SOAP 1.1服務轉成 SOAP 1.2等等。它還可以把一個服務路由到另一個服務上，也可

以集中化管理業務邏輯，規則和驗證等等。它還有一個重要功能是消息隊列和事件驅動的消息傳遞，比如把JMS服務轉化成SOAP協議。各服務間可能有複雜的依賴關係。

　　微服務通常由重寫一個模塊開始。要把整個巨石型的應用重寫是有很大的風險的，也不一定必要。我們向微服務遷移的時候通常從耦合度最低的模塊或對擴展性要求最高的模塊開始，把它們

一個一個剝離出來用敏捷地重寫，可以嘗試最新的技術和語言和框架，然後單獨佈署。它通常不依賴其他服務。微服務中常用的API Gateway的模式主要目的也不是重用代碼，而是減少客戶端和

服務間的往來。API gateway模式不等同與Facade模式，我們可以使用如future之類的調用，甚至返回不完整數據。

　　2、SOA喜歡水平服務，微服務喜歡垂直服務

　　SOA設計喜歡給服務分層(如Service Layers模式)。我們常常見到一個Entity服務層的設計，美其名曰Data Access Layer。這種設計要求所有的服務都通過這個Entity服務層來獲取數據。這種

設計非常不靈活，比如每次數據層的改動都可能影響到所有業務層的服務。而每個微服務通常有它自己獨立的data store。我們在拆分資料庫時可以適當的做些去範式化(denormalization)，讓它不

需要依賴其他服務的數據。

　　微服務通常是直接面對用戶的，每個微服務通常直接為用戶提供某個功能。類似的功能可能針對手機有一個服務，針對機頂盒是另外一個服務。在SOA設計模式中這種情況通常會用到

Multi-ChannelEndpoint的模式返回一個大而全的結果兼顧到所有的客戶端的需求。

　　3、SOA喜歡自上而下，微服務喜歡自下而上

　　SOA架構在設計開始時會先定義好服務合同(service contract)。它喜歡集中管理所有的服務，包括集中管理業務邏輯，數據，流程，schema，等等。它使用Enterprise Inventory和Service

Composition等方法來集中管理服務。 SOA架構通常會預先把每個模塊服務介面都定義好。模塊系統間的通訊必須遵守這些介面，各服務是針對他們的調用者。SOA架構適用於TOGAF之類的架構

方法論。

　　微服務則敏捷得多。只要用戶用得到，就先把這個服務挖出來。然後針對性的，快速確認業務需求，快速開發迭代。

怎麼具體實踐微服務

　　要實際的應用微服務，需要解決一下四點問題：

　　1、客戶端如何訪問這些服務

　　2、每個服務之間如何通信

　　3、如此多的服務，如何實現？

　　4、服務掛了，如何解決？（備份方案，應急處理機制）

　　1、客戶端如何訪問這些服務

　　原來的Monolithic方式開發，所有的服務都是本地的，UI可以直接調用，現在按功能拆分成獨立的服務，跑在獨立的一般都在獨立的虛擬機上的 Java進程了。客戶端UI如何訪問他的？後臺有N

個服務，前臺就需要記住管理N個服務，一個服務下線/更新/升級，前臺就要重新部署，這明顯不服務我們拆分的理念，特別當前臺是移動應用的時候，通常業務變化的節奏更快。另外，N個小服

務的調用也是一個不小的網路開銷。還有一般微服務在系統內部，通常是無狀態的，用戶登錄信息和許可權管理最好有一個統一的地方維護管理（OAuth）。所以，一般在後臺N個服務和UI之間一般

會一個代理或者叫API Gateway，他的作用包括：

　　① 提供統一服務入口，讓微服務對前臺透明

　　② 聚合後臺的服務，節省流量，提升性能

　　③ 提供安全，過濾，流控等API管理功能

其實這個API Gateway可以有很多廣義的實現辦法，可以是一個軟硬一體的盒子，也可以是一個簡單的MVC框架，甚至是一個Node.js的服務端。他們最重要的作用是為前臺（通常是移動應用）提

供後臺服務的聚合，提供一個統一的服務出口，解除他們之間的耦合，不過API Gateway也有可能成為單點故障點或者性能的瓶頸。

　　用過Taobao Open Platform（淘寶開放平臺）的就能很容易的體會，TAO就是這個API Gateway。

　　2、每個服務之間如何通信

　　所有的微服務都是獨立的Java進程跑在獨立的虛擬機上，所以服務間的通信就是IPC（inter process communication），已經有很多成熟的方案。現在基本最通用的有兩種方式：

　　同步調用：

　　①REST（JAX-RS，Spring Boot）

　　②RPC（Thrift, Dubbo）

　　非同步消息調用(Kafka, Notify, MetaQ)

　　同步和非同步的區別：

　　一般同步調用比較簡單，一致性強，但是容易出調用問題，性能體驗上也會差些，特別是調用層次多的時候。RESTful和RPC的比較也是一個很有意思的話題。

　　一般REST基於HTTP，更容易實現，更容易被接受，服務端實現技術也更靈活些，各個語言都能支持，同時能跨客戶端，對客戶端沒有特殊的要求，只要封裝了HTTP的SDK就能調用，所以

相對使用的廣一些。RPC也有自己的優點，傳輸協議更高效，安全更可控，特別在一個公司內部，如果有統一個的開發規範和統一的服務框架時，他的開發效率優勢更明顯些。就看各自的技術積

累實際條件，自己的選擇了。

　　而非同步消息的方式在分散式系統中有特別廣泛的應用，他既能減低調用服務之間的耦合，又能成為調用之間的緩衝，確保消息積壓不會衝垮被調用方，同時能保證調用方的服務體驗，繼續乾

自己該乾的活，不至於被後臺性能拖慢。不過需要付出的代價是一致性的減弱，需要接受數據最終一致性；還有就是後臺服務一般要實現冪等性，因為消息發送出於性能的考慮一般會有重覆（保

證消息的被收到且僅收到一次對性能是很大的考驗）；最後就是必須引入一個獨立的broker，如果公司內部沒有技術積累，對broker分散式管理也是一個很大的挑戰。

　　3、如此多的服務，如何實現？

　　在微服務架構中，一般每一個服務都是有多個拷貝，來做負載均衡。一個服務隨時可能下線，也可能應對臨時訪問壓力增加新的服務節點。服務之間如何相互感知？服務如何管理？

　　這就是服務發現的問題了。一般有兩類做法，也各有優缺點。基本都是通過zookeeper等類似技術做服務註冊信息的分散式管理。當服務上線時，服務提供者將自己的服務信息註冊到ZK（或

類似框架），並通過心跳維持長鏈接，實時更新鏈接信息。服務調用者通過ZK定址，根據可定製演算法，找到一個服務，還可以將服務信息緩存在本地以提高性能。當服務下線時，ZK會發通知給

服務客戶端。

　　客戶端做：優點是架構簡單，擴展靈活，只對服務註冊器依賴。缺點是客戶端要維護所有調用服務的地址，有技術難度，一般大公司都有成熟的內部框架支持，比如Dubbo。

　　服務端做：優點是簡單，所有服務對於前臺調用方透明，一般在小公司在雲服務上部署的應用採用的比較多。

　　4、服務掛了，如何解決

　　前面提到，Monolithic方式開發一個很大的風險是，把所有雞蛋放在一個籃子里，一榮俱榮，一損俱損。而分散式最大的特性就是網路是不可靠的。通過微服務拆分能降低這個風險，不過如果

沒有特別的保障，結局肯定是噩夢。所以當我們的系統是由一系列的服務調用鏈組成的時候，我們必須確保任一環節出問題都不至於影響整體鏈路。相應的手段有很多：

　　①重試機制

　　②限流

　　③熔斷機制

　　④負載均衡

　　⑤降級（本地緩存）

　　這些方法基本都很明確通用，比如Netflix的Hystrix：https://github.com/Netflix/Hystrix

常見的設計模式和應用

　　有一個圖非常好的總結微服務架構需要考慮的問題，包括：

　　1、API Gateway

　　2、服務間調用

　　3、服務發現

　　4、服務容錯

　　5、服務部署

　　6、數據調用

六種常見的微服務架構設計模式：

　　1、聚合器微服務設計模式

　　這是一種最常見也最簡單的設計模式：

　　聚合器調用多個服務實現應用程式所需的功能。它可以是一個簡單的Web頁面，將檢索到的數據進行處理展示。它也可以是一個更高層次的組合微服務，對檢索到的數據增加業務邏輯後進一

發佈成一個新的微服務，這符合DRY原則。另外，每個服務都有自己的緩存和資料庫。如果聚合器是一個組合服務，那麼它也有自己的緩存和資料庫。聚合器可以沿X軸和Z軸獨立擴展。

　　2、代理微服務設計模式

　　這是聚合模式的一個變種，如下圖所示：

　　在這種情況下，客戶端並不聚合數據，但會根據業務需求的差別調用不同的微服務。代理可以僅僅委派請求，也可以進行數據轉換工作。

　　3、鏈式微服務設計模式

　　這種模式在接收到請求後會產生一個經過合併的響應，如下圖所示：

　　在這種情況下，服務A接收到請求後會與服務B進行通信，類似地，服務B會同服務C進行通信。所有服務都使用同步消息傳遞。在整個鏈式調用完成之前，客戶端會一直阻塞。因此，服務調

用鏈不宜過長，以免客戶端長時間等待。

　　4、分支微服務設計模式

　　這種模式是聚合器模式的擴展，允許同時調用兩個微服務鏈，如下圖所示：

　　5、數據共用微服務設計模式

　　自治是微服務的設計原則之一，就是說微服務是全棧式服務。但在重構現有的“單體應用（monolithic application）”時，SQL資料庫反規範化可能會導致數據重覆和不一致。因此，在單體應用

到微服務架構的過渡階段，可以使用這種設計模式，如下圖所示：

　　在這種情況下，部分微服務可能會共用緩存和資料庫存儲。不過，這隻有在兩個服務之間存在強耦合關係時才可以。對於基於微服務的新建應用程式而言，這是一種反模式。

　　6、非同步消息傳遞微服務設計模式

　　雖然REST設計模式非常流行，但它是同步的，會造成阻塞。因此部分基於微服務的架構可能會選擇使用消息隊列代替REST請求/響應，如下圖所示：

優點和缺點

　　1、微服務的優點：

　　關鍵點：複雜度可控，獨立按需擴展，技術選型靈活，容錯，可用性高

　　①它解決了複雜性的問題。它會將一種怪異的整體應用程式分解成一組服務。雖然功能總量不變，但應用程式已分解為可管理的塊或服務。每個服務都以RPC或消息驅動的API的形式定義了

一個明確的邊界；Microservice架構模式實現了一個模塊化水平。

　　②這種架構使每個服務都能夠由專註於該服務的團隊獨立開發。開發人員可以自由選擇任何有用的技術，只要該服務符合API合同。當然，大多數組織都希望避免完全無政府狀態並限制技術

選擇。然而，這種自由意味著開發人員不再有義務使用在新項目開始時存在的可能過時的技術。在編寫新服務時，他們可以選擇使用當前的技術。此外，由於服務相對較小，因此使用當前技術重

寫舊服務變得可行。

　　③Microservice架構模式使每個微服務都能獨立部署。開發人員不需要協調部署本地服務的變更。這些變化可以在測試後儘快部署。例如，UI團隊可以執行A | B測試，並快速迭代UI更改。

Microservice架構模式使連續部署成為可能。

　　④Microservice架構模式使每個服務都可以獨立調整。您可以僅部署滿足其容量和可用性限制的每個服務的實例數。此外，您可以使用最符合服務資源要求的硬體。

　　2、微服務的缺點

　　關鍵點（挑戰）：多服務運維難度，系統部署依賴，服務間通信成本，數據一致性，系統集成測試，重覆工作，性能監控等

　　①一個缺點是名稱本身。術語microservice過度強調服務規模。但重要的是要記住，這是一種手段，而不是主要目標。微服務的目標是充分分解應用程式，以便於敏捷應用程式開發和部署。

　　②微伺服器的另一個主要缺點是分散式系統而產生的複雜性。開發人員需要選擇和實現基於消息傳遞或RPC的進程間通信機制。此外，他們還必須編寫代碼來處理部分故障，因為請求的目的

地可能很慢或不可用。

　　③微伺服器的另一個挑戰是分區資料庫架構。更新多個業務實體的業務交易是相當普遍的。但是，在基於微伺服器的應用程式中，您需要更新不同服務所擁有的多個資料庫。使用分散式事務

通常不是一個選擇，而不僅僅是因為CAP定理。許多今天高度可擴展的NoSQL資料庫都不支持它們。你最終不得不使用最終的一致性方法，這對開發人員來說更具挑戰性。

　　④測試微服務應用程式也更複雜。服務類似的測試類將需要啟動該服務及其所依賴的任何服務（或至少為這些服務配置存根）。再次，重要的是不要低估這樣做的複雜性。

　　⑤Microservice架構模式的另一個主要挑戰是實現跨越多個服務的更改。例如，我們假設您正在實施一個需要更改服務A，B和C的故事，其中A取決於B和B取決於C.在單片應用程式中，您可以

簡單地更改相應的模塊，整合更改，並一次性部署。相比之下，在Microservice架構模式中，您需要仔細規劃和協調對每個服務的更改。例如，您需要更新服務C，然後更新服務B，然後再維修A.

幸運的是，大多數更改通常僅影響一個服務，而需要協調的多服務變更相對較少。

　　⑥部署基於微服務的應用程式也更複雜。單一應用程式簡單地部署在傳統負載平衡器後面的一組相同的伺服器上。每個應用程式實例都配置有基礎架構服務（如資料庫和消息代理）的位置

（主機和埠）。相比之下，微服務應用通常由大量服務組成。例如，每個服務將有多個運行時實例。更多的移動部件需要進行配置，部署，擴展和監控。此外，您還需要實現服務發現機制，使

服務能夠發現需要與之通信的任何其他服務的位置（主機和埠）。傳統的基於故障單和手動操作的方法無法擴展到這種複雜程度。因此，成功部署微服務應用程式需要開發人員更好地控制部署

方法，並實現高水平的自動化。

理想中的微服務架構

　　沒有什麼東西是完美的，網站架構也是這樣的，只有「比之前好一點」的架構或「目前最好的實現方式」，不存在理想中的架構，那麼理想中微服務架構應該是怎麼樣的呢，我覺得至少應該

有如下幾個特點：

能支持當前業務需求，當然這隻是最最基本的條件；
每個微服務都要去中心化，不存在單點故障；
每個微服務都要實現高可用、高負載，不會因為一個服務不可用而影響了整套業務流；
每個微服務都要高度通用化，即多種終端都可調用，不分語言和平臺；
服務部署或升級簡單，不會消耗大量人力並且部署過程不易出現人為錯誤；
微服務具有快速註冊與自動發現功能（例如dubbo框架）

　　當然，這隻是其中能想到的幾點，實際環境中用到的微服務框架有可能會根據實際業務需求優化出更加個性化的功能，也可能有些功能是不需要的。還是那句話，架構是服務於業務的，能快

速方便的滿足業務需求的架構才是好的架構，才是好的微服務架構。

淺識微服務架構