理解微服務

當前微服務很熱，你們都號稱在使用微服務架構，但究竟什麼是微服務架構？微服務架構是否是發展趨勢？對於這些問題，咱們都缺少清楚的認識，本文基於做者在大型互聯網系統的服務化實踐和思考，和你們一塊兒探討微服務架構。本文主要內容包括：

1.   傳統SOA架構

2.   新型SOA架構

3.   服務設計方式

4.   深刻微服務

5.   微服務體系

6.   微服務系統架構

傳統SOA架構

說到微服務，離不開SOA，二者常常放一塊兒討論，首先咱們要了解SOA架構。

國外信息化起步較早，不少大公司前後建設了不少系統，好比從開始的ERP，到OA系統，到CRM系統等。因爲這些系統每每由不一樣的供應商提供，採用不一樣的技術，實施的時候也沒預先考慮到和現有系統集成，所以系統集成很是困難。

在2000年初的時候，兩個概念很是流行，一個是EAI（Enterprise application integration），即企業應用集成；還有一個是EII（Enterprise application integration），即企業信息集成。一個從應用的角度，一個從數據的角度，本質是一回事，都是怎麼把孤立的系統集成在一塊兒。

SOA架構源自於企業內部異構系統的集成，具體作法是各個系統對外提供粗粒度的服務，外部系統能夠經過相對標準的技術訪問，大體結構以下圖所示：

每一個遺留系統提供服務，該服務做爲系統的前置代理，對外提供訪問。全部這些服務部署在一箇中心化的平臺，稱之爲企業服務總線ESB（Enterprise Service Bus），ESB提供複雜處理，包括：

·        外部訪問

爲知足不一樣客戶端訪問需求，提供各類各樣的訪問協議，如WebService、HTTP、FTP、Email等，其中WebService是最典型的通信協議。

·        內部處理

請求進來後，須要一系列複雜處理，如對通信協議的解析，數據的序列化和反序列化，業務流程的編排和服務路由等。

2008年的時候，eBay基於Axis，開發了本身的SOA框架，各個系統經過建立服務，對外提供功能。如後臺搜索系統，自己是C++開發，經過對外提供Java服務，最終以WebService的方式，方便其餘系統（大可能是Java）調用搜索的功能。通過1年多的時間，整個SOA平臺已經有上百個服務，很大程度上方便了系統相互集成。

但咱們能夠看到，ESB是一個很重的機制。首先通信方式複雜，先後端涉及多種協議，因爲每次調用代價很高，服務通常提供粗粒度的接口，一次性儘可能完成更多處理。

ESB的中心化帶來了單點故障隱患，服務統一在ESB上進行部署，也限制了服務的水平擴展；此外ESB還包含不少業務相關的功能，如業務流程編排等，限制了業務擴展的靈活性。

不管對於服務的提供者仍是使用者，經過ESB這種方式集成，開發代價大，通訊效率低，所以這種傳統很重的SOA架構並無獲得大規模應用。

新型SOA架構

這裏應用直接調用服務，無需通過複雜的中心節點，使用輕量級的協議，通常是HTTP，數據格式也很簡單，好比JSON，由服務提供者直接解析協議和數據格式。同時每一個服務自己包含核心的業務封裝，提供給多個應用場景。

此外每一個服務獨立部署，提供更好的靈活性，包括業務功能擴展和處理容量水平擴展。

咱們能夠看到，新型SOA和傳統基於ESB的SOA相反，這裏是強化服務終端能力，弱化通道鏈接。

服務如何設計

隨着互聯網業務愈來愈複雜，新型的SOA架構不斷深刻發展，出現了多種服務設計模式。

1. 面向業務系統服務設計

面向業務系統SOA把原單體應用裏的業務邏輯層剝離出來，做爲單獨的服務對外提供。

舉一個電商的例子，這裏有兩個應用，顧客使用的商品詳情頁，展現商品的信息、商品庫存，商品價格；下單頁供顧客下單，涉及商品查詢、庫存扣減、生成訂單等。

頁面應用和服務關係以下圖所示：

商品詳情服務主要面向商品詳情頁提供數據接口，包括商品基本信息、價格信息、庫存信息，接口常常根據頁面須要，聚合這幾部分信息，提供粗粒度服務，服務底層自由訪問所須要的表。

訂單服務主要面向下單頁，其中商品信息能夠經過商品詳情服務獲取，無需單獨訪問庫表。而對於庫存，這裏是扣庫存場景，須要本身訪問庫存表，訂單信息也是如此。

面向業務系統的服務設計是比較直接的，每一個服務針對本身的「主應用」提供粗粒度服務，整體上看應用/服務/庫表是多對多的關係，若是服務設計得很差，容易致使總體網狀依賴，修改時，每每牽一髮動全身。此外對於新業務，須要單獨構建對應的服務，不利於業務創新。

2. 面向細分主題服務

面向特定主題/概念/要素構建細分服務，最終服務於該主題相關的全部業務場景，好比圍繞用戶構建用戶服務，對外供全部須要用戶信息的業務系統訪問，內部只訪問用戶相關的幾張表，結構以下圖所示：

面向細分主題的服務對數據是獨佔式訪問，不容許其它服務訪問本身的表，也不訪問外部的表，更好地實現對該主題相關的業務規則和底層數據的封裝。

3. 面向基礎系統服務

面向基礎系統服務屏蔽底層硬件的訪問細節，以更友好更透明地方式對外提供訪問，如短信服務、儲存服務、緩存服務等。咱們一直講軟件即服務，如今更進一步，硬件也是服務。

一般面向基礎系統服務經過底層系統的集羣或多路由，提供更可靠，更強處理能力的服務。

深刻微服務

微服務概念是Martin Fowler在2014年拋出，文中給出微服務的一系列特徵，但並無給出準肯定義。你們分別有本身的理解，尚未共識，基於本人的服務化實踐，我以爲微服務有兩大思想。

1. 簡單鏈接

經過傳統SOA方式鏈接客戶端和服務端，是很是痛苦的，涉及傳統很重的通信協議(DCOM/RMI/CORBA/WebService等)和複雜的數據格式(二進制/XML等)。在鏈接通道方面，微服務很輕，通常採用輕量級的通信協議（如HTTP）和簡單數據格式（如JSON）。

微服務無需中心節點提供複雜處理，特別是業務相關的處理，把業務的職責還給服務端，更靈活地響應業務變化。微服務構建好後，應該象水電煤同樣處處可用，沒有技術障礙，不一樣語言均可以互相調用。

2. 分散管理

分而治之是處理複雜問題的有效手段，微服務對系統拆分尤其完全，在多個方面實現對系統的分散管理：

·        分散業務

微服務聚焦細分業務領域，是對應業務規則的惟一入口，它把總體業務分割成一個個高內聚的小業務，簡化業務之間依賴關係。

·        分散數據

微服務獨佔式訪問對應的數據，服務和數據是一體的。它把總體數據分割成一塊塊數據，數據塊內部的表緊密相關，塊間數據相關性弱。在實施層面，每部分數據獨立schema，邏輯上分離，或者使用獨立數據庫，物理上隔離。

·        分散物理資源

藉助虛擬機和容器技術，一臺物理機能夠切分爲多套環境，很是適合微服務部署，對服務器資源更高效地利用，同時有些微服務面向基礎硬件封裝，提高了對物理資源的管理。

咱們能夠看到，傳統的基於ESB的服務不屬於微服務範疇，它既不體現簡單鏈接，也不體現分散管理（ESB甚至經過流程編排對業務集中管理）。相對於傳統重的SOA服務，新型SOA，不管是面向業務系統服務，面向細分主題服務，面向基礎系統服務都符合簡單鏈接的特性，所以均可以算微服務的範疇。

特別地，面向細分主題服務很好體現業務和數據的分散管理，面向基礎系統服務很好體現物理資源的分散管理，所以這二者更好地知足微服務思想，是更純粹的微服務。

這裏是一個電商庫存微服務的實例，但願幫助你們深刻了解微服務，大型B2C電商的庫存概念比較複雜，包括：

·        物理庫存（倉庫裏的實際庫存）

·        虛擬庫存（倉庫裏沒有，但能夠僞裝有，先拿出來賣，好比新版iPhone預售）

·        活動庫存（總庫存裏拿出一部分作活動，提供優惠價格促銷）

·        共享庫存（北京的庫存能夠共享出來，放到上海賣）

·        凍結庫存（庫存暫時被凍結部分，好比已下單但未發貨，此時前臺不可賣）

對於前臺來講，用戶可看到的庫存計算規則以下：

可售庫存=本地庫存（實際-凍結）+虛擬庫存（虛擬-凍結）+兄弟倉庫共享庫存(共享-凍結）

對於具體活動場景來講，可售庫存的規則不同，它等於活動庫存。

商品庫存是電商的核心數據，有數十個業務系統調用，大促時天天調用數十億次，每每在數百臺虛擬機/容器上部署，提供水平擴展，具體架構以下：

庫存微服務化設計有不少好處：

統一業務規則

庫存的計算規則很複雜，不一樣業務場景看到的庫存數量都不同，庫存微服務經過提供惟一的庫存訪問入口，統一對庫存相關規則進行封裝，方便各個業務場景使用，若是庫存規則有變化，變化也侷限於庫存微服務內部，外部業務代碼保持不變。

一致數據模型

庫存微服務只訪問庫存相關的四張表，它不訪問外部庫表，也不容許外部應用直接訪問這幾張表，收斂了對這些表的訪問入口，避免各個業務直接往表裏加字段，致使數據模型混亂。

此外，這些表獨立成庫，再加上只有庫存服務訪問，數據庫鏈接數能夠大大減小，避免數據庫鏈接數不夠。

各類內部優化

庫存微服務彙總全部讀寫接口，內部能夠作各類優化。好比緩存，因爲全部寫場景都在這裏，能夠經過寫後立刻更新方式，保證緩存的實時一致性。全部讀場景也在這裏，能夠經過合理設計，一個緩存知足多個讀場景需求，提高緩存使用效率。

庫存的變化是很是重要的系統狀態變化，庫存微服務在各個庫存變化點，提供庫存變化消息通知，以統一的消息命名方式和消息格式，保證相關方可以方便地接收庫存消息。

水平擴展

庫存服務天天訪問量很大，經過微服務方式能夠很方便地水平擴展，服務自己是部署在標準的虛擬機或容器內，經過雲的方式能夠動態收縮和擴容，1號店在大促的時候，就常常以租用公有云服務器的方式實現服務能力擴展。

你們能夠看到，微服務很適用業務高度複雜、業務共享性高、併發量大的場景，在電商，相似的場景還有訂單/商品/用戶/價格/支付等等，咱們能夠圍繞這些細分概念構造微服務。

微服務體系

隨着服務的不斷構建，一個完整的微服務體系以下圖所示：

最底下是基礎系統的服務，這些服務實現對底層系統功能的封裝，供之上各個業務使用，如短信/消息/存儲等服務，上層服務無需關注底層資源的物理位置和內部細節。

之上的共享服務基於細分主題，封裝企業各個維度的核心數據資源和業務規則，偏下層產品/用戶/訂單等都是主數據，共享性更強，偏上層的積分/抵用券/發票等，爲某幾個業務系統所使用，規則相對也更簡單。

系統服務爲企業總體系統提供基礎技術平臺，共享服務提供基礎業務平臺，二者一塊兒奠基企業信息系統的基礎。最上面的業務服務基於兩大基礎平臺，面向具體的業務系統提供服務。

在這裏，服務造成了明確的分層，調用規則以下：

·        上層能夠調用下層，好比共享服務調用系統服務，也能夠跨層調用，好比業務服務直接調用系統服務。

·        同層方面，業務服務能夠互相調用，組成更粗粒度服務，共享服務和系統服務都是細分服務，相互之間垂直正交，不容許相互調用。

經過服務細分和服務分層，微服務的職責定位明確，依賴關係清晰，整體上，整個系統變成層次化的依賴，而不是網狀依賴。

微服務系統架構

下圖是一個大型B2C電商系統實際的架構，上層是各類業務應用，底層是大量服務，而且服務分爲應用服務（面向業務）和基礎服務（面向共享主題），一個很是典型的微服務架構。

當前隨着網絡通訊技術的完善和雲計算的流行，包括容器化部署，客觀上，很好地解決微服務技術上的問題；主觀上，互聯網系統體量大、業務複雜，經過微服務的方式對系統進行深刻拆分是很天然的選擇。

微服務經過簡單鏈接簡化技術實現，經過分散管理簡化業務依賴，很好地平衡了技術複雜性和業務複雜性，在大型互聯網公司已經遍地開花。