引言：上篇文章介紹了微服務和單體架構的區別、微服務的設計、消息、服務間通信、數據去中心化，本篇會繼續深入微服務，介紹其它特性。
治理去中心化
通常“治理”的意思是構建方案，並且迫使人們通過努力達到組織的目標。SOA治理指導開發者開發可重用的服務，以及隨着時間推移，服務應該怎麼被設計和開發。治理建立了服務提供者和消費者之間對於服務的協定，告訴消費者能從服務提供獲取到什麼樣的支持。
SOA中有兩種常見的治理：
設計時的治理-定義和控制服務的創建、設計和服務策略的實施。
運行時的治理-確保執行過程的策略。
那麼微服務中的治理是什麼意思呢？
在微服務架構中，不同的微服務之間相互獨立，並且基於不同的平臺和技術。因此，沒有必要爲服務的設計和開發定義一個通用的標準。
總結微服務的治理去中心化如下：
微服務架構，在設計時不需要集中考慮治理。
每個微服務可以有獨立的設計、執行決策。
微服務架構着重培養通用/可重用的服務。
運行時的治理，比如安全級別保證（SLA），限制，監控，安全和服務發現，可以在API網關層處理。
服務註冊和發現
微服務架構下，有大量的微服務需要處理。由於微服務的快速和敏捷研發，他們的位置可能會動態變化。因此在運行時需要能夠發現服務所在的位置，服務發現可以解決這個問題。
服務註冊
註冊中心有微服務的實例和位置信息，微服務在啓動時向註冊中心註冊自己的信息，關閉時註銷。其它使用者能夠通過註冊中心找到可用的微服務和相關信息。
服務發現
爲了能找到可用的服務和他們的位置信息，需要服務發現機制。有兩種發現機制，客戶端發現和服務端發現。
客戶端發現 - 客戶端或者API網關通過查詢服務註冊中心或者服務的位置信息。
圖9：客戶端發現
客戶端/API網關必須調用服務註冊中心組件，實現服務發現的邏輯。
服務端發現 - 客戶端/API網關把請求發送到已知位置信息的組件（比如負載均衡器）。組件去訪問註冊中心，找到微服務的位置信息。
圖10：服務端發現
類似Kubernetes（http://kubernetes.io/v1.1/docs/user-guide/services.html ）這種微服務部署解決方案，就提供了服務器端的自動發現機制。
部署
微服務的部署方式也特別重要，以下是關鍵：
能夠獨立於其他微服務發佈或者取消發佈
微服務可以水平擴展（某一個服務比其他的請求量大）
快速構建和發佈
微服務之間的功能不相互影響
Docker（一個運行在linux上並且開源的應用，能夠協助開發和運維把應用運行在容器中）能夠快速部署微服務，包括關鍵幾點：
把微服務打包成Docker鏡像
啓動容器實例
改變實例的數量達到擴容需求
相對於傳統的虛擬機模式，利用docker容器，構建、發佈、啓動微服務將會變得十分快捷。
通過Kubernetes能夠進一步擴展Docker的能力，能夠從單個linux主機擴展到linux集羣，支持多主機，管理容器位置，服務發現，多實例。都是微服務需求的重要特性。因此，利用Kubernetes管理微服務和容器的發佈，是一個非常有力的方案。
圖11：構建和部署服務的容器
圖11，展示了零售應用的微服務部署。每個服務都在獨立的容器中，每個主機有兩個容器，通過kubernetes可以隨意調整容器的數量。
安全
在實際運行環境中，微服務的安全也非常重要。我們先看下單體架構下安全是如何實現的。
一個典型的單體應用，安全問題主要是“誰調用”，“調用者能做什麼”，“如何處理”。服務器接收到請求後，一般都在處理鏈條的最開始，通過安全組件來對請求的信息進行安全處理。
我們能直接把這種處理方式應用在微服務架構中嗎？答案是可以的，需要買個微服務都實現一個安全組件從資源中心獲取對應的用戶信息，實現安全控制。這是比較初級的處理方式。可以嘗試採用一些標準的API方式，比如OAuth2和OpenID。深入研究之前，可以先概括下這兩種安全協議以及如何使用。
OAuth2-是一個訪問委託協議。需要獲得權限的客戶端，向授權服務申請一個訪問令牌。訪問令牌沒有任何關於用戶/客戶端的信息，僅僅是一個給授權服務器使用的用戶引用信息。因此，這個“引用的令牌”也沒有安全問題。
OpenID類似於OAuth，不過除了訪問令牌以外，授權服務器還會頒發一個ID令牌，包含用戶信息。通常由授權服務器以JWT（JSON Web Token）的方式實現。通過這種方式確保客戶和服務器端的互信。JWT令牌是一種“有內容的令牌”，包含用戶的身份信息，在公共環境中使用不安全。
現在我們看下如何在網絡零售網站中應用這些協議保障微服務的安全。
圖12：通過OAuth2和OpenID解決安全問題
圖12中所示，是實現微服務安全的關鍵幾步：
所有的授權由授權服務器，通過OAuth和OpenID方式實現，確保用戶能訪問到正確的數據。
採用API網關方式，所有的客戶端請求有唯一入口。
客戶端通過授權服務器獲得訪問令牌，把令牌發送到API網關。
令牌在網關的處理 - API網關得到令牌後，發送到授權服務器獲得JWT。
網關把JWT和請求一起發送到微服務中。
JWT包含必要的用戶信息，如果每個微服務都能夠解析JWT，那麼你的系統中每個服務都能處理身份相關的業務。在每個微服務中，可以有一個處理JWT的輕量級的組件。
事務
在微服務中怎麼支持事務呢？事實上，跨多個微服務的分佈式事務支持非常複雜，微服務的設計思路是儘量避免多個服務之間的事務操作。
解決辦法是微服務的設計需要遵循功能自包含和單職責原則。跨越多個微服務支持分佈式事務在微服務架構中不是一個好的設計思路，通常需要重新劃定微服務的職責。某些場景下，必須要跨越服務支持分佈式事務，可以在每個微服務內部利用“組合操作”。
最關鍵的事情是，基於單職責原則設計微服務，如果某個服務不能正常執行某些操作，那麼這個服務是有問題的。那麼上游的操作，都需要在各自的微服務中執行回滾操作。
容錯設計
微服務架構相比較單體的設計而言，引入了更多服務，在每個服務級別會增加發生錯誤的可能性。一個服務可能由於網絡問題、底層資源等各種問題導致失敗。某個服務的不可能不應該影響整個應用的崩潰。因此，微服務系統必須容錯，甚至自動回覆，對客戶端無感知。
任何服務在任何時間都有可能出問題，監控系統需要能夠發現問題，並且自動恢復。微服務環境下有不少常用的模式。
線路中斷
微服務中請求的失敗率達到一定程度後，系統中的監控可以激活線路中斷。當正常請求的數量恢復到一定程度後，再關閉線路中斷的開關，使系統回覆到正常狀態。
這個模式可以避免不必要的資源消耗，請求的處理延遲會導致超時，藉此可以把監控系統做的更完善。
防火牆
一個應用會有很多微服務租車，單個微服務的失敗不應該影響整個系統。防火牆模式強調服務直接的隔離性，微服務不會受到其它微服務失敗的影響。
處理超時
超時機制是在確定不會再有應答的情況下，主動放棄等待微服務的響應。這種超時應該是可配置的。
哪些情況下，如何使用這些模式呢？大多數情況，都應該在網關處理。當微服務不可用或者沒有回覆時，網關能夠決定是否執行線路中斷或者啓動超時機制。防火牆機制同樣重要，網關是所有請求的唯一入口，一個微服務的失敗不應該影響到其它微服務。網關也是獲得微服務狀態、監控信息的中心。
微服務，企業集成，API管理
我們已經討論了微服務的架構和各種特性，以及如何應用在一個現代的IT系統中。同時也需要意識到，微服務不是解決所有問題的靈丹妙藥。盲目追求流行的技術概念並不能解決掉企業IT系統的問題。
微服務有很多優勢，但是僅靠微服務不能解決企業IT中的所有問題。例如，微服務需要去除ESB，但是現實的IT系統中，大量的應用和服務是基於ESB而不是微服務。集成現有的系統，需要一些集成總線。實際情況是，微服務和其它企業架構並存。
