SOA和微服務架構的區別
阿新 • • 發佈：2019-02-02
微服務架構強調的第一個重點就是業務系統需要徹底的元件化和服務化，原有的單個業務系統會拆分為多個可以獨立開發，設計，執行和運維的小應用。這些小應用之間通過服務完成互動和整合。每個小應用從前端web ui，到控制層，邏輯層，資料庫訪問，資料庫都完全是獨立的一套。在這裡我們不用元件而用小應用這個詞更加合適，每個小應用除了完成自身本身的業務功能外，重點就是還需要消費外部其它應用暴露的服務，同時自身也將自身的能力朝外部發布為服務。
如果一句話來談SOA和微服務的區別，即微服務不再強調傳統SOA架構裡面比較重的ESB企業服務匯流排，同時SOA的思想進入到單個業務系統內部實現真正的元件化。
把這個核心搞清楚後，再來看下網上找到的對微服務架構的一些定義和闡述：
再強調下即：
首先對於應用本身暴露出來的服務，是和應用一起部署的，即服務本身並不單獨部署，服務本身就是業務元件已有的介面能力釋出和暴露出來的。瞭解到這點我們就看到一個關鍵，即我們在進行單個應用元件設計的時候，本身在元件內部就會有很大介面的設計和定義，那麼這些介面我們可以根據和外部其它元件協同的需要將其釋出為微服務，而如果不需要對外協同我們完全可以走內部API介面訪問模式提高效率。
其次，微服務架構本身來源於網際網路的思路，因此元件對外發布的服務強調了採用HTTP Rest API的方式來進行。這個也可以看到在網際網路開放能力服務平臺基本都採用了Http API的方式進行服務的釋出和管理。從這個角度來說，元件超外部暴露的能力才需要釋出為微服務，其本身也是一種封裝後的粗粒度服務。而不是將元件內部的所有業務規則和邏輯，元件本身的底層資料庫CRUD操作全部朝外部發布。否則將極大的增加服務的梳理而難以進行整體服務管控和治理。
微服務的基本思想在於考慮圍繞著業務領域元件來建立應用，這些就應用可獨立地進行開發、管理和加速。在分散的元件中使用微服務雲架構和平臺使部署、管理和服務功能交付變得更加簡單。
對於網際網路談到微服務架構一定會談到Devops即開發測試和部署運維的一體化。當我們的單體應用以及拆分為多個小應用後，雖然整體架構可以鬆耦合和可擴充套件，但是如果拆分的元件越多，這些元件之間本身的整合和部署運維就越複雜。即任何一個元件，當他依賴的外部其它應用元件越多的時候，整個整合，部署和聯調測試的過程就越複雜。這些如果完全靠我們手工去完成一是增加工作量，一是增加出錯概率。
原來談元件化開發談的最多的是單個元件的持續整合，包括配置環境整合，自動打包部署，自動化的冒煙測試等。對於微服務架構下首先仍然是要做好單個元件本身的持續整合，其次在這個基礎上增加了多個元件的打包部署和元件間的整合。裡面的核心思想就是Devops的思路，希望能夠實現開發設計到部署運維的一體化。
由於微服務架構裡面強調了單個元件本身是可以在獨立的程序裡面執行，各個元件之間在部署的時候就能夠做到程序級別的隔離。那麼一臺伺服器我們可能需要初始化幾十個甚至更多的程序來進行應用元件的部署。為了保持程序的隔離性，我們可以用虛擬機器，但是當幾十個程序都完全用獨立的虛擬機器就不現實的，而這個問題的解決剛好就是利用PaaS平臺裡面的輕量Docker容器來做這個事情，每個Docker是獨立的容器剛好又完全做到程序級別的隔離，資源佔用率又最小，這些特點剛好滿足微服務架構的開發測試和自動化部署。
前面這些問題思考清楚後就是考慮所有暴露的微服務是否需要一個統一的服務管控和治理平臺，按照當前微服務架構的整體思路，雖然單個服務的實現和釋出仍然是在元件內部完成的，但是這些元件暴露的服務本身的呼叫情況，服務本身的安全，日誌和流量控制等仍然需要一個統一的SOA服務管理平臺來完成。
由於微服務儘量都是通過HTTP API的方式暴露出去的，因此這種服務管理平臺不需要像傳統企業內部的ESB服務匯流排這麼重。但是最基本的服務註冊，服務代理，服務釋出，服務簡單的路由，安全訪問和授權，服務呼叫訊息和日誌記錄這些功能還是需要具備。類似淘寶的Dubbo架構，即可以做為微服務架構下的服務管控平臺。
對於這種服務管控平臺，核心需要討論的就是服務每次呼叫本身的訊息傳遞，輸入和輸出日誌是否需要記錄，當前就有兩種做法，一種是不記錄，管理平臺只負責服務註冊和目錄釋出，安全授權，實際的服務訪問仍然是兩個元件之間的點對點連線完成，這種方式下整個架構下獲取更高的效能，同時服務管理平臺也不容易成為大併發服務訪問下的單點瓶頸；另外一種方式就是完全記錄，在這種方式下就需要考慮服務管理平臺本身的叢集化不是，高併發下的效能問題。而個人建議最好的方式還是SOA服務管理平臺應該提供兩種管理能力，同時僅僅對核心的需要Log日誌的服務進行日誌記錄，而其它服務只提供服務目錄和訪問控制即可。
===========2016.6.8日更新，增加Chris Richardson微服務系列讀書筆記
本文為閱讀《Chris Richardson 微服務系列》的閱讀筆記，具體原文參考：「Chris Richardson 微服務系列」服務發現的可行方案以及實踐案例 ， 裡面有另外四篇的連結，當前daocloud已經更新到第5篇事件驅動架構。
第一篇 微服務架構的優勢和不足
文中強調的單體應用的場景，我在前面很多談元件化和服務化的文章裡面已經都談到過了，即一個應用系統裡面的模組沒有辦法做到徹底解耦，如果要實現按元件單獨部署是不可能的，相互之間仍然有大量內部不可見依賴而導致了模組間無法拆分。
那麼單體應用本身帶來的問題主要有哪些？
1.系統複雜：內部多個模組緊耦合，關聯依賴複雜，牽一髮而動全身。
2.運維困難：變更或升級的影響分析困難，任何一個小修改都可能導致單體應用整體執行出現故障。
3.無法擴充套件：無法拆分部署，出現效能瓶頸後往往只能夠增加伺服器或增加叢集節點，但是DB問題難解決
正是由於這些原因需要考慮引入微服務架構（實質仍然是單個應用本身的元件化和服務化），對於微服務文章裡面有一個詳細說明如下：一個微服務一般完成某個特定的功能，比如訂單管理、客戶管理等。每個微服務都是一個微型應用，有著自己六邊形架構，包括商業邏輯和各種介面。有的微服務通過暴露API 被別的微服務或者應用客戶端所用；有的微服務則通過網頁 UI 實現。在執行時，每個例項通常是一個雲虛擬機器或者 Docker容器。
從這個定義和說明仍然需要做一些關鍵理解，即在我前面談微服務的文章裡面談到過的，即核心的幾點包括了，其一足夠構成一個獨立小應用（從DB到UI），其二微服務應用之間只能通過ServiceAPI進行互動，其三一般執行在雲虛擬機器或更輕的Docker容器上。
APIGateway，這實際上微服務架構裡面的很重要的內容，其作用類似於傳統企業內部的ESB服務匯流排，只是更加輕量和高效能來解決微服務的管控和治理問題。而對於負載均衡，快取，路由，訪問控制，服務代理，監控，日誌等都屬於基本的服務管控內容，也是APIGateway需要考慮的核心能力。
Scale Cube的3D模型，描述的相當好，即通過微服務架構實施後擴充套件性的變化。
1. Y軸：本質是應用的分解，即將傳統的單體應用分解為多個微服務應用。
2. X軸：水平彈性擴充套件能力，即通過負載均衡來實現水平彈性擴充套件，但是DB問題無法解決，引入3
3. Z軸：當單個微服務應用引入了DB彈性擴充套件能力要解決的時候，我們引入了對資料庫進行拆分和DaaS
對於微服務架構的好處前面在講單體應用的問題的時候已經談到了，微服務架構正好是解決這些問題。而對於微服務架構的不足，簡單總結如下：
1. CAP原則：由於服務無狀態和引入了分散式，較難解決事務一致性問題。
2. 整合複雜：任何徹底的分解都將帶來整合的複雜度，即模組在整合時候需要外部微服務模組更多的配合。
3. 部署問題：稍大專案都涉及到上100個服務節點部署，還涉及到部署後的配置，擴充套件和監控問題。
第二篇 使用API閘道器構建微服務
首先說下這篇文章的引入場景，以一個亞馬遜購物網站的手機APP訂單檢視介面來舉例，如果是一個單體應用，那麼所有的介面需要獲取資訊都通過單體應用統一一個地址提供的多個ServiceAPI獲取。但是轉變為微服務架構後可以看到對於會員管理，商品管理，訂單管理，財務結算管理等都已經拆分為了不同的微服務模組，需要從不同的服務提供地址呼叫不同的微服務模組提供的ServiceAPI來返回資料。
在原文裡面我們看到對於客戶端和微服務模組間點對點直接通訊提了三個問題，如下：
1. 問題一：客戶端需求和每個微服務暴露的細粒度 API 不匹配
2. 問題二：部分服務使用的協議對 web 並不友好，如二進位制RPC或AMQP訊息等。
3. 問題三：會使得微服務難以重構，如服務拆分或服務組合的場景。
那麼我們從傳統的ESB能力來對上面三個問題進行一個說明，第一個問題即可能涉及到細粒度的API組合，類似組合服務無法做；其二是可能存在協議轉換的問題要解決；其三即服務透明的問題，即需要對客戶端提供一個統一的服務目錄以使底層服務透明。由於以上問題，引入了API服務閘道器的概念，再次強調，對於API服務閘道器即使微服務架構裡面的輕量服務匯流排，解決服務管控和治理相關問題。文中對APIGateway給出如下說明：
API 閘道器是一個伺服器，也可以說是進入系統的唯一節點。這與面向物件設計模式中的 Facade 模式很像。API閘道器封裝內部系統的架構，並且提供 API給各個客戶端。它還可能還具備授權、監控、負載均衡、快取、請求分片和管理、靜態響應處理等功能。
API 閘道器負責服務請求路由、組合及協議轉換。客戶端的所有請求都首先經過 API 閘道器，然後由它將請求路由到合適的微服務。API閘道器經常會通過呼叫多個微服務併合並結果來處理一個請求。它可以在 web 協議（如 HTTP 與 WebSocket）與內部使用的非web 友好協議之間轉換。
API 閘道器還能為每個客戶端提供一個定製的 API。通常，它會向移動客戶端暴露一個粗粒度的 API。以產品詳情的場景為例，API閘道器可以提供一個端點（/productdetails?productid=xxx），使移動客戶端可以通過一個請求獲取所有的產品詳情。API閘道器通過呼叫各個服務（產品資訊、推薦、評論等等）併合並結果來處理請求。
API閘道器的優點和缺點
對於API閘道器的優點，其實是類似傳統ESB企業服務匯流排的優點，即實現服務透明，同時對於服務執行過程中的日誌，安全，路由，快取等問題進行統一配置和處理，而不需要每個微服務API實現時都去考慮。如開源的Dubbo服務匯流排即可以看作是一個API閘道器的實現。
API閘道器和ESB的一些重要區別點在於API閘道器更加輕量和高效能，它不需要去考慮太多遺留系統和諸多協議的適配，其次也不需要考慮服務整合過程中的大量資料轉換和對映。同時為了提升服務閘道器的效能，一般API閘道器在實現過程中不會去記錄詳細的資料傳輸日誌，或者類似Dubbo架構資料傳輸根本就不會通過API閘道器。
使用 API 閘道器的最大優點是，它封裝了應用程式的內部結構。客戶端只需要同閘道器互動，而不必呼叫特定的服務。API閘道器也有一些不足。它增加了一個我們必須開發、部署和維護的高可用元件。還有一個風險是，API 閘道器變成了開發瓶頸。
簡單來說，在我們期望的去中心化和全分散式架構中，閘道器又成了一箇中心點或瓶頸點，正是由於這個原因我們在閘道器設計的時候必須考慮即使APIGateway宕機也不要影響到服務的呼叫和執行。
API閘道器的設計和實現
對於大多數應用程式而言，API 閘道器的效能和可擴充套件性都非常重要。因此，將 API 閘道器構建在一個支援非同步、I/O非阻塞的平臺上是合理的。有多種不同的技術可以實現一個可擴充套件的 API 閘道器。在 JVM 上，可以使用一種基於 NIO的框架，比如 Netty、Vertx、Spring Reactor 或 JBoss Undertow 中的一種。一個非常流行的非JVM 選項是 Node.js，它是一個基於 Chrome JavaScript 引擎構建的平臺。
另一個方法是使用 NGINX Plus。NGINX Plus 提供了一個成熟的、可擴充套件的、高效能 web伺服器和一個易於部署的、可配置可程式設計的反向代理。NGINX Plus可以管理身份驗證、訪問控制、負載均衡請求、快取響應，並提供應用程式可感知的健康檢查和監控。
對於API閘道器需要實現底層多個細粒度的API組合的場景，文章推薦採用響應式程式設計模型進行而不是傳統的非同步回撥方法組合程式碼。其原因除了採用回撥方式導致的程式碼混亂外，還有就是對於API組合本身可能存在並行或先後呼叫，對於採用回撥方式往往很難控制。
基於微服務的應用程式是一個分散式系統，必須使用一種程序間通訊機制。有兩種型別的程序間通訊機制可供選擇。一種是使用非同步的、基於訊息傳遞的機制。有些實現使用諸如JMS 或 AMQP 那樣的訊息代理，而其它的實現（如 Zeromq）則沒有代理，服務間直接通訊。另一種程序間通訊型別是諸如 HTTP或 Thrift 那樣的同步機制。通常，一個系統會同時使用非同步和同步兩種型別。它甚至還可能使用同一型別的多種實現。總之，API閘道器需要支援多種通訊機制。
注：如果服務是同步呼叫可以看到微服務模組之間本身是沒有徹底解耦的，即如果A依賴B提供的API，如果B提供的服務不可用將直接影響到A不可用。除非同步服務呼叫在API閘道器層或客戶端做了相應的快取。因此為了徹底解耦，在微服務呼叫上更建議選擇非同步方式進行。
對於大多數基於微服務的應用程式而言，實現 API 閘道器，將其作為系統的唯一入口很有必要。API閘道器負責服務請求路由、組合及協議轉換。它為每個應用程式客戶端提供一個定製的 API。API閘道器還可以通過返回快取資料或預設資料遮蔽後端服務失敗。
第三篇 微服務架構中的程序間通訊
基於微服務的分散式應用是執行在多臺機器上的；一般來說，每個服務例項都是一個程序。因此，如下圖所示，服務之間的互動必須通過程序間通訊（IPC）來實現。
對於微服務架構的互動模式，文章從兩個維度進行了描述，即
一對一：每個客戶端請求有一個服務例項來響應。
一對多：每個客戶端請求有多個服務例項來響應。
同步模式：客戶端請求需要服務端即時響應，甚至可能由於等待而阻塞。
非同步模式：客戶端請求不會阻塞程序，服務端的響應可以是非即時的。
對於分為這兩個維度進行描述意義不太大，對於同步模式往往只能是1對1，而且還需要同步等待容易引起阻塞，而對於非同步模組往往採用訊息機制來實現，同時配合訊息中介軟體可以進一步實現訊息的釋出訂閱。而對於EDA事件驅動架構要看到其本質也是伊布訊息中介軟體和訊息的釋出訂閱。
非同步訊息機制可以做到最大化的解耦，對於資料CUD的場景可以看到是比較容易通過非同步訊息機制實現的，但是會進一步引入事務一致性問題，即在採用非同步訊息機制後往往通過BASE事務最終一致性來解決事務層面的問題。而對於查詢功能可以看到是比較難通過非同步訊息API實現的，在引入這個之前可以看到需要考慮兩方面的問題並解決。
其一是服務閘道器需要有資料快取能力，以解決無法從源端獲取資料的場景。其二是前端開發框架本身需要支援非同步呼叫和資料裝載模式，特別是對於資料查詢功能對於使用者來講，在前端的感受仍然需要時同步的。即通過非同步方式返回了查詢資料後可以動態重新整理前端展示介面。
服務版本的問題：這是不可避免要遇到的問題，特別是對於RestAPI呼叫，由於Json格式本身無Schema返回更加容易忽視了對服務版本的管理和控制。要知道對於Json資料格式變化仍然會導致RestAPI呼叫後處理失敗。因此服務版本仍然採用大小版本管理機制比較好，對於小版本變更則直接對原有服務進行覆蓋同時對所有受影響的服務消費端進行升級；而對於大版本升級則本質是新增加了一個新服務，而對於舊版本服務逐步遷移和替代。
處理區域性失敗：文中提到了Netfilix的服務解決方案，對於失敗問題的解決要注意常用的仍然是服務超時設定，斷路器機制，流量控制，快取資料或預設值返回等。不論採用哪種失敗處理策略，都需要考慮應該儘量減少服務呼叫失敗或超時對終端使用者造成的影響。
基於請求/響應的同步 IPC
使用同步的、基於請求/響應的 IPC機制的時候，客戶端向服務端傳送請求，服務端處理請求並返回響應。一些客戶端會由於等待服務端響應而被阻塞，而另外一些客戶端可能使用非同步的、基於事件驅動的客戶端程式碼，這些程式碼可能通過Future 或者 Rx Observable封裝。然而，與使用訊息機制不同，客戶端需要響應及時返回。這個模式中有很多可選的協議，但最常見的兩個協議是 REST 和Thrift。
Thrift 也能夠讓你選擇傳輸協議，包括原始 TCP 和 HTTP。原始 TCP 比 HTTP 更高效，然而 HTTP對於防火牆、瀏覽器和使用者來說更友好。文中對於兩種實現方式已經描述的相當詳細，可以看到當前網際網路OpenAPI平臺和微服務架構實現中仍然是大量以採用RestAPI介面為主。
而對於訊息格式的選擇，可以看到在使用RestAPI介面的時候，更多的是採用了Json訊息格式而非XML，對於SOAPWebService則更多采用了XML訊息格式。如果採用Thrift則還可以採用二進位制訊息格式以提升效能。
第四篇 服務發現的可行方案以及實踐案例
首先還是先說場景，看似簡單的服務註冊和服務目錄庫管理為何會變複雜，其主要的原因還是在結合了雲端PaaS和Docker容器部署後，對於微服務模組部署完成後提供出來的IP地址是動態在變化的，包括模組在進行動態叢集擴充套件的時候也需要動態接入新的服務提供IP地址。正是由於這個原因引入了服務發現和管理的困難度。
在文章中提到了兩種服務發現模式，即客戶端發現模式和服務端發現模式，分開描述如下：
服務客戶端發現模式
使用客戶端發現模式時，客戶端決定相應服務例項的網路位置，並且對請求實現負載均衡。客戶端查詢服務登錄檔，後者是一個可用服務例項的資料庫；然後使用負載均衡演算法從中選擇一個例項，併發出請求。客戶端從服務註冊服務中查詢，其中是所有可用服務例項的庫。客戶端使用負載均衡演算法從多個服務例項中選擇出一個，然後發出請求。
注：這是類似Dubbo實現機制一樣的兩階段模式，即任何一個服務的消費都需要分兩個步驟進行，第一步首先是訪問服務註冊庫（更多是APIGateWay提供的一個能力）返回一個已經動態均衡後的服務可用地址，第二步即客戶端和該地址直接建立連線進行服務消費和訪問。
在這種模式的實現中有兩個重點，其一是動態負載均衡演算法，其二是服務閘道器需要能夠對原始服務提供點進行實時的心跳檢測以確定服務提供的可用性。
Netflix OSS 是客戶端發現模式的絕佳範例。Netflix Eureka是一個服務登錄檔，為服務例項註冊管理和查詢可用例項提供了 REST API 介面。Netflix Ribbon 是 IPC 客戶端，與Eureka 一起實現對請求的負載均衡。
缺點：底層的IP雖然動態提供出去了，但是最終仍然暴露給了服務消費方，再需要進一步做安全和防火牆隔離的場景下顯然是不能滿足要求的。
服務端發現模式
客戶端通過負載均衡器向某個服務提出請求，負載均衡器查詢服務登錄檔，並將請求轉發到可用的服務例項。如同客戶端發現，服務例項在服務登錄檔中註冊或登出。在原文中有圖示，基本看圖就清楚了，即在服務註冊庫前新增加了一個LoadBalancer節點。注：這兩個節點感覺是可以合併到API GateWay的能力中去的。
服務端發現模式兼具優缺點。它最大的優點是客戶端無需關注發現的細節，只需要簡單地向負載均衡器傳送請求，這減少了程式語言框架需要完成的發現邏輯。並且如上文所述，某些部署環境免費提供這一功能。這種模式也有缺點。除非負載均衡器由部署環境提供，否則會成為一個需要配置和管理的高可用系統元件。
服務登錄檔
服務登錄檔需要高可用而且隨時更新。客戶端能夠快取從服務登錄檔中獲取的網路地址，然而，這些資訊最終會過時，客戶端也就無法發現服務例項。因此，服務登錄檔會包含若干服務端，使用複製協議保持一致性。
首先可以看到服務登錄檔本身不能是單點，否則存在單點故障，當服務登錄檔有多臺伺服器的時候同時需要考慮服務註冊庫資訊在多臺機器上的實時同步和一致。我們操作和配置服務註冊資訊的時候往往只會在一個統一的服務管控端完成。
其次如果服務註冊伺服器宕機是否一定影響到服務本身的消費和呼叫，如果考慮更高的整體架構可用性，還可以設計對於服務註冊庫資訊在客戶端本地進行快取，當服務登錄檔無法訪問的時候可以臨時讀取本地快取的服務註冊庫資訊併發起服務訪問請求。
對於服務登錄檔，文章提供了三種選擇，感覺最常用的實現仍然是基於ZooKeeper進行的。
Etcd – 高可用、分散式、一致性的鍵值儲存，用於共享配置和服務發現。
Consul – 發現和配置的服務，提供 API 實現客戶端註冊和發現服務。
Apache ZooKeeper – 被分散式應用廣泛使用的高效能協調服務。
如前所述，服務例項必須在登錄檔中註冊和登出。註冊和登出有兩種不同的方法。方法一是服務例項自己註冊，也叫自注冊模式（self-registrationpattern）；另一種是採用管理服務例項註冊的其它系統元件，即第三方註冊模式。（原文有詳細機制描述，不再累述）
雖然方法一把服務例項和服務登錄檔耦合，必須在每個程式語言和框架內實現註冊程式碼。但是在自己實現完整微服務架構中，考慮到PaaS平臺下微服務模組的動態部署和擴充套件，採用方法1相當來說更加容易實現。但是方法1仍然不能代替服務註冊庫本身應該具備的服務節點的心跳檢測能力。
如果一句話來談SOA和微服務的區別，即微服務不再強調傳統SOA架構裡面比較重的ESB企業服務匯流排，同時SOA的思想進入到單個業務系統內部實現真正的元件化。
把這個核心搞清楚後，再來看下網上找到的對微服務架構的一些定義和闡述：
微服務可以在“自己的程式”中執行，並通過“輕量級裝置與HTTP型API進行溝通”。關鍵在於該服務可以在自己的程式中執行。通過這一點我們就可以將服務公開與微服務架構（在現有系統中分佈一個API）區分開來。在服務公開中，許多服務都可以被內部獨立程序所限制。如果其中任何一個服務需要增加某種功能，那麼就必須縮小程序範圍。在微服務架構中，只需要在特定的某種服務中增加所需功能，而不影響整體程序。
微服務不需要像普通服務那樣成為一種獨立的功能或者獨立的資源。定義中稱，微服務是需要與業務能力相匹配，這種說法完全正確。不幸的是，仍然意味著，如果能力模型粒度的設計是錯誤的，那麼，我們就必須付出很多代價。如果你閱讀了Fowler的整篇文章，你會發現，其中的指導建議是非常實用的。在決定將所有元件組合到一起時，開發人員需要非常確信這些元件都會有所改變，並且規模也會發生變化。服務粒度越粗，就越難以符合規定原則。服務粒度越細，就越能夠靈活地降低變化和負載所帶來的影響。然而，利弊之間的權衡過程是非常複雜的，我們要在配置和資金模型的基礎上考慮到基礎設施的成本問題。
再強調下即：
首先對於應用本身暴露出來的服務，是和應用一起部署的，即服務本身並不單獨部署，服務本身就是業務元件已有的介面能力釋出和暴露出來的。瞭解到這點我們就看到一個關鍵，即我們在進行單個應用元件設計的時候，本身在元件內部就會有很大介面的設計和定義，那麼這些介面我們可以根據和外部其它元件協同的需要將其釋出為微服務，而如果不需要對外協同我們完全可以走內部API介面訪問模式提高效率。
其次，微服務架構本身來源於網際網路的思路，因此元件對外發布的服務強調了採用HTTP Rest API的方式來進行。這個也可以看到在網際網路開放能力服務平臺基本都採用了Http API的方式進行服務的釋出和管理。從這個角度來說，元件超外部暴露的能力才需要釋出為微服務，其本身也是一種封裝後的粗粒度服務。而不是將元件內部的所有業務規則和邏輯，元件本身的底層資料庫CRUD操作全部朝外部發布。否則將極大的增加服務的梳理而難以進行整體服務管控和治理。
微服務的基本思想在於考慮圍繞著業務領域元件來建立應用，這些就應用可獨立地進行開發、管理和加速。在分散的元件中使用微服務雲架構和平臺使部署、管理和服務功能交付變得更加簡單。
對於網際網路談到微服務架構一定會談到Devops即開發測試和部署運維的一體化。當我們的單體應用以及拆分為多個小應用後，雖然整體架構可以鬆耦合和可擴充套件，但是如果拆分的元件越多，這些元件之間本身的整合和部署運維就越複雜。即任何一個元件，當他依賴的外部其它應用元件越多的時候，整個整合，部署和聯調測試的過程就越複雜。這些如果完全靠我們手工去完成一是增加工作量，一是增加出錯概率。
原來談元件化開發談的最多的是單個元件的持續整合，包括配置環境整合，自動打包部署，自動化的冒煙測試等。對於微服務架構下首先仍然是要做好單個元件本身的持續整合，其次在這個基礎上增加了多個元件的打包部署和元件間的整合。裡面的核心思想就是Devops的思路，希望能夠實現開發設計到部署運維的一體化。
由於微服務架構裡面強調了單個元件本身是可以在獨立的程序裡面執行，各個元件之間在部署的時候就能夠做到程序級別的隔離。那麼一臺伺服器我們可能需要初始化幾十個甚至更多的程序來進行應用元件的部署。為了保持程序的隔離性，我們可以用虛擬機器，但是當幾十個程序都完全用獨立的虛擬機器就不現實的，而這個問題的解決剛好就是利用PaaS平臺裡面的輕量Docker容器來做這個事情，每個Docker是獨立的容器剛好又完全做到程序級別的隔離，資源佔用率又最小，這些特點剛好滿足微服務架構的開發測試和自動化部署。
前面這些問題思考清楚後就是考慮所有暴露的微服務是否需要一個統一的服務管控和治理平臺，按照當前微服務架構的整體思路，雖然單個服務的實現和釋出仍然是在元件內部完成的，但是這些元件暴露的服務本身的呼叫情況，服務本身的安全，日誌和流量控制等仍然需要一個統一的SOA服務管理平臺來完成。
由於微服務儘量都是通過HTTP API的方式暴露出去的，因此這種服務管理平臺不需要像傳統企業內部的ESB服務匯流排這麼重。但是最基本的服務註冊，服務代理，服務釋出，服務簡單的路由，安全訪問和授權，服務呼叫訊息和日誌記錄這些功能還是需要具備。類似淘寶的Dubbo架構，即可以做為微服務架構下的服務管控平臺。
對於這種服務管控平臺，核心需要討論的就是服務每次呼叫本身的訊息傳遞，輸入和輸出日誌是否需要記錄，當前就有兩種做法，一種是不記錄，管理平臺只負責服務註冊和目錄釋出，安全授權，實際的服務訪問仍然是兩個元件之間的點對點連線完成，這種方式下整個架構下獲取更高的效能，同時服務管理平臺也不容易成為大併發服務訪問下的單點瓶頸；另外一種方式就是完全記錄，在這種方式下就需要考慮服務管理平臺本身的叢集化不是，高併發下的效能問題。而個人建議最好的方式還是SOA服務管理平臺應該提供兩種管理能力，同時僅僅對核心的需要Log日誌的服務進行日誌記錄，而其它服務只提供服務目錄和訪問控制即可。
===========2016.6.8日更新，增加Chris Richardson微服務系列讀書筆記
本文為閱讀《Chris Richardson 微服務系列》的閱讀筆記，具體原文參考：「Chris Richardson 微服務系列」服務發現的可行方案以及實踐案例 ， 裡面有另外四篇的連結，當前daocloud已經更新到第5篇事件驅動架構。
第一篇 微服務架構的優勢和不足
文中強調的單體應用的場景，我在前面很多談元件化和服務化的文章裡面已經都談到過了，即一個應用系統裡面的模組沒有辦法做到徹底解耦，如果要實現按元件單獨部署是不可能的，相互之間仍然有大量內部不可見依賴而導致了模組間無法拆分。
那麼單體應用本身帶來的問題主要有哪些？
1.系統複雜：內部多個模組緊耦合，關聯依賴複雜，牽一髮而動全身。
2.運維困難：變更或升級的影響分析困難，任何一個小修改都可能導致單體應用整體執行出現故障。
3.無法擴充套件：無法拆分部署，出現效能瓶頸後往往只能夠增加伺服器或增加叢集節點，但是DB問題難解決
正是由於這些原因需要考慮引入微服務架構（實質仍然是單個應用本身的元件化和服務化），對於微服務文章裡面有一個詳細說明如下：一個微服務一般完成某個特定的功能，比如訂單管理、客戶管理等。每個微服務都是一個微型應用，有著自己六邊形架構，包括商業邏輯和各種介面。有的微服務通過暴露API 被別的微服務或者應用客戶端所用；有的微服務則通過網頁 UI 實現。在執行時，每個例項通常是一個雲虛擬機器或者 Docker容器。
從這個定義和說明仍然需要做一些關鍵理解，即在我前面談微服務的文章裡面談到過的，即核心的幾點包括了，其一足夠構成一個獨立小應用（從DB到UI），其二微服務應用之間只能通過ServiceAPI進行互動，其三一般執行在雲虛擬機器或更輕的Docker容器上。
APIGateway，這實際上微服務架構裡面的很重要的內容，其作用類似於傳統企業內部的ESB服務匯流排，只是更加輕量和高效能來解決微服務的管控和治理問題。而對於負載均衡，快取，路由，訪問控制，服務代理，監控，日誌等都屬於基本的服務管控內容，也是APIGateway需要考慮的核心能力。
Scale Cube的3D模型，描述的相當好，即通過微服務架構實施後擴充套件性的變化。
1. Y軸：本質是應用的分解，即將傳統的單體應用分解為多個微服務應用。
2. X軸：水平彈性擴充套件能力，即通過負載均衡來實現水平彈性擴充套件，但是DB問題無法解決，引入3
3. Z軸：當單個微服務應用引入了DB彈性擴充套件能力要解決的時候，我們引入了對資料庫進行拆分和DaaS
對於微服務架構的好處前面在講單體應用的問題的時候已經談到了，微服務架構正好是解決這些問題。而對於微服務架構的不足，簡單總結如下：
1. CAP原則：由於服務無狀態和引入了分散式，較難解決事務一致性問題。
2. 整合複雜：任何徹底的分解都將帶來整合的複雜度，即模組在整合時候需要外部微服務模組更多的配合。
3. 部署問題：稍大專案都涉及到上100個服務節點部署，還涉及到部署後的配置，擴充套件和監控問題。
第二篇 使用API閘道器構建微服務
首先說下這篇文章的引入場景，以一個亞馬遜購物網站的手機APP訂單檢視介面來舉例，如果是一個單體應用，那麼所有的介面需要獲取資訊都通過單體應用統一一個地址提供的多個ServiceAPI獲取。但是轉變為微服務架構後可以看到對於會員管理，商品管理，訂單管理，財務結算管理等都已經拆分為了不同的微服務模組，需要從不同的服務提供地址呼叫不同的微服務模組提供的ServiceAPI來返回資料。
在原文裡面我們看到對於客戶端和微服務模組間點對點直接通訊提了三個問題，如下：
1. 問題一：客戶端需求和每個微服務暴露的細粒度 API 不匹配
2. 問題二：部分服務使用的協議對 web 並不友好，如二進位制RPC或AMQP訊息等。
3. 問題三：會使得微服務難以重構，如服務拆分或服務組合的場景。
那麼我們從傳統的ESB能力來對上面三個問題進行一個說明，第一個問題即可能涉及到細粒度的API組合，類似組合服務無法做；其二是可能存在協議轉換的問題要解決；其三即服務透明的問題，即需要對客戶端提供一個統一的服務目錄以使底層服務透明。由於以上問題，引入了API服務閘道器的概念，再次強調，對於API服務閘道器即使微服務架構裡面的輕量服務匯流排，解決服務管控和治理相關問題。文中對APIGateway給出如下說明：
API 閘道器是一個伺服器，也可以說是進入系統的唯一節點。這與面向物件設計模式中的 Facade 模式很像。API閘道器封裝內部系統的架構，並且提供 API給各個客戶端。它還可能還具備授權、監控、負載均衡、快取、請求分片和管理、靜態響應處理等功能。
API 閘道器負責服務請求路由、組合及協議轉換。客戶端的所有請求都首先經過 API 閘道器，然後由它將請求路由到合適的微服務。API閘道器經常會通過呼叫多個微服務併合並結果來處理一個請求。它可以在 web 協議（如 HTTP 與 WebSocket）與內部使用的非web 友好協議之間轉換。
API 閘道器還能為每個客戶端提供一個定製的 API。通常，它會向移動客戶端暴露一個粗粒度的 API。以產品詳情的場景為例，API閘道器可以提供一個端點（/productdetails?productid=xxx），使移動客戶端可以通過一個請求獲取所有的產品詳情。API閘道器通過呼叫各個服務（產品資訊、推薦、評論等等）併合並結果來處理請求。
API閘道器的優點和缺點
對於API閘道器的優點，其實是類似傳統ESB企業服務匯流排的優點，即實現服務透明，同時對於服務執行過程中的日誌，安全，路由，快取等問題進行統一配置和處理，而不需要每個微服務API實現時都去考慮。如開源的Dubbo服務匯流排即可以看作是一個API閘道器的實現。
API閘道器和ESB的一些重要區別點在於API閘道器更加輕量和高效能，它不需要去考慮太多遺留系統和諸多協議的適配，其次也不需要考慮服務整合過程中的大量資料轉換和對映。同時為了提升服務閘道器的效能，一般API閘道器在實現過程中不會去記錄詳細的資料傳輸日誌，或者類似Dubbo架構資料傳輸根本就不會通過API閘道器。
使用 API 閘道器的最大優點是，它封裝了應用程式的內部結構。客戶端只需要同閘道器互動，而不必呼叫特定的服務。API閘道器也有一些不足。它增加了一個我們必須開發、部署和維護的高可用元件。還有一個風險是，API 閘道器變成了開發瓶頸。
簡單來說，在我們期望的去中心化和全分散式架構中，閘道器又成了一箇中心點或瓶頸點，正是由於這個原因我們在閘道器設計的時候必須考慮即使APIGateway宕機也不要影響到服務的呼叫和執行。
API閘道器的設計和實現
對於大多數應用程式而言，API 閘道器的效能和可擴充套件性都非常重要。因此，將 API 閘道器構建在一個支援非同步、I/O非阻塞的平臺上是合理的。有多種不同的技術可以實現一個可擴充套件的 API 閘道器。在 JVM 上，可以使用一種基於 NIO的框架，比如 Netty、Vertx、Spring Reactor 或 JBoss Undertow 中的一種。一個非常流行的非JVM 選項是 Node.js，它是一個基於 Chrome JavaScript 引擎構建的平臺。
另一個方法是使用 NGINX Plus。NGINX Plus 提供了一個成熟的、可擴充套件的、高效能 web伺服器和一個易於部署的、可配置可程式設計的反向代理。NGINX Plus可以管理身份驗證、訪問控制、負載均衡請求、快取響應，並提供應用程式可感知的健康檢查和監控。
對於API閘道器需要實現底層多個細粒度的API組合的場景，文章推薦採用響應式程式設計模型進行而不是傳統的非同步回撥方法組合程式碼。其原因除了採用回撥方式導致的程式碼混亂外，還有就是對於API組合本身可能存在並行或先後呼叫，對於採用回撥方式往往很難控制。
基於微服務的應用程式是一個分散式系統，必須使用一種程序間通訊機制。有兩種型別的程序間通訊機制可供選擇。一種是使用非同步的、基於訊息傳遞的機制。有些實現使用諸如JMS 或 AMQP 那樣的訊息代理，而其它的實現（如 Zeromq）則沒有代理，服務間直接通訊。另一種程序間通訊型別是諸如 HTTP或 Thrift 那樣的同步機制。通常，一個系統會同時使用非同步和同步兩種型別。它甚至還可能使用同一型別的多種實現。總之，API閘道器需要支援多種通訊機制。
注：如果服務是同步呼叫可以看到微服務模組之間本身是沒有徹底解耦的，即如果A依賴B提供的API，如果B提供的服務不可用將直接影響到A不可用。除非同步服務呼叫在API閘道器層或客戶端做了相應的快取。因此為了徹底解耦，在微服務呼叫上更建議選擇非同步方式進行。
對於大多數基於微服務的應用程式而言，實現 API 閘道器，將其作為系統的唯一入口很有必要。API閘道器負責服務請求路由、組合及協議轉換。它為每個應用程式客戶端提供一個定製的 API。API閘道器還可以通過返回快取資料或預設資料遮蔽後端服務失敗。
第三篇 微服務架構中的程序間通訊
基於微服務的分散式應用是執行在多臺機器上的；一般來說，每個服務例項都是一個程序。因此，如下圖所示，服務之間的互動必須通過程序間通訊（IPC）來實現。
對於微服務架構的互動模式，文章從兩個維度進行了描述，即
一對一：每個客戶端請求有一個服務例項來響應。
一對多：每個客戶端請求有多個服務例項來響應。
同步模式：客戶端請求需要服務端即時響應，甚至可能由於等待而阻塞。
非同步模式：客戶端請求不會阻塞程序，服務端的響應可以是非即時的。
對於分為這兩個維度進行描述意義不太大，對於同步模式往往只能是1對1，而且還需要同步等待容易引起阻塞，而對於非同步模組往往採用訊息機制來實現，同時配合訊息中介軟體可以進一步實現訊息的釋出訂閱。而對於EDA事件驅動架構要看到其本質也是伊布訊息中介軟體和訊息的釋出訂閱。
非同步訊息機制可以做到最大化的解耦，對於資料CUD的場景可以看到是比較容易通過非同步訊息機制實現的，但是會進一步引入事務一致性問題，即在採用非同步訊息機制後往往通過BASE事務最終一致性來解決事務層面的問題。而對於查詢功能可以看到是比較難通過非同步訊息API實現的，在引入這個之前可以看到需要考慮兩方面的問題並解決。
其一是服務閘道器需要有資料快取能力，以解決無法從源端獲取資料的場景。其二是前端開發框架本身需要支援非同步呼叫和資料裝載模式，特別是對於資料查詢功能對於使用者來講，在前端的感受仍然需要時同步的。即通過非同步方式返回了查詢資料後可以動態重新整理前端展示介面。
服務版本的問題：這是不可避免要遇到的問題，特別是對於RestAPI呼叫，由於Json格式本身無Schema返回更加容易忽視了對服務版本的管理和控制。要知道對於Json資料格式變化仍然會導致RestAPI呼叫後處理失敗。因此服務版本仍然採用大小版本管理機制比較好，對於小版本變更則直接對原有服務進行覆蓋同時對所有受影響的服務消費端進行升級；而對於大版本升級則本質是新增加了一個新服務，而對於舊版本服務逐步遷移和替代。
處理區域性失敗：文中提到了Netfilix的服務解決方案，對於失敗問題的解決要注意常用的仍然是服務超時設定，斷路器機制，流量控制，快取資料或預設值返回等。不論採用哪種失敗處理策略，都需要考慮應該儘量減少服務呼叫失敗或超時對終端使用者造成的影響。
基於請求/響應的同步 IPC
使用同步的、基於請求/響應的 IPC機制的時候，客戶端向服務端傳送請求，服務端處理請求並返回響應。一些客戶端會由於等待服務端響應而被阻塞，而另外一些客戶端可能使用非同步的、基於事件驅動的客戶端程式碼，這些程式碼可能通過Future 或者 Rx Observable封裝。然而，與使用訊息機制不同，客戶端需要響應及時返回。這個模式中有很多可選的協議，但最常見的兩個協議是 REST 和Thrift。
Thrift 也能夠讓你選擇傳輸協議，包括原始 TCP 和 HTTP。原始 TCP 比 HTTP 更高效，然而 HTTP對於防火牆、瀏覽器和使用者來說更友好。文中對於兩種實現方式已經描述的相當詳細，可以看到當前網際網路OpenAPI平臺和微服務架構實現中仍然是大量以採用RestAPI介面為主。
而對於訊息格式的選擇，可以看到在使用RestAPI介面的時候，更多的是採用了Json訊息格式而非XML，對於SOAPWebService則更多采用了XML訊息格式。如果採用Thrift則還可以採用二進位制訊息格式以提升效能。
第四篇 服務發現的可行方案以及實踐案例
首先還是先說場景，看似簡單的服務註冊和服務目錄庫管理為何會變複雜，其主要的原因還是在結合了雲端PaaS和Docker容器部署後，對於微服務模組部署完成後提供出來的IP地址是動態在變化的，包括模組在進行動態叢集擴充套件的時候也需要動態接入新的服務提供IP地址。正是由於這個原因引入了服務發現和管理的困難度。
在文章中提到了兩種服務發現模式，即客戶端發現模式和服務端發現模式，分開描述如下：
服務客戶端發現模式
使用客戶端發現模式時，客戶端決定相應服務例項的網路位置，並且對請求實現負載均衡。客戶端查詢服務登錄檔，後者是一個可用服務例項的資料庫；然後使用負載均衡演算法從中選擇一個例項，併發出請求。客戶端從服務註冊服務中查詢，其中是所有可用服務例項的庫。客戶端使用負載均衡演算法從多個服務例項中選擇出一個，然後發出請求。
注：這是類似Dubbo實現機制一樣的兩階段模式，即任何一個服務的消費都需要分兩個步驟進行，第一步首先是訪問服務註冊庫（更多是APIGateWay提供的一個能力）返回一個已經動態均衡後的服務可用地址，第二步即客戶端和該地址直接建立連線進行服務消費和訪問。
在這種模式的實現中有兩個重點，其一是動態負載均衡演算法，其二是服務閘道器需要能夠對原始服務提供點進行實時的心跳檢測以確定服務提供的可用性。
Netflix OSS 是客戶端發現模式的絕佳範例。Netflix Eureka是一個服務登錄檔，為服務例項註冊管理和查詢可用例項提供了 REST API 介面。Netflix Ribbon 是 IPC 客戶端，與Eureka 一起實現對請求的負載均衡。
缺點：底層的IP雖然動態提供出去了，但是最終仍然暴露給了服務消費方，再需要進一步做安全和防火牆隔離的場景下顯然是不能滿足要求的。
服務端發現模式
客戶端通過負載均衡器向某個服務提出請求，負載均衡器查詢服務登錄檔，並將請求轉發到可用的服務例項。如同客戶端發現，服務例項在服務登錄檔中註冊或登出。在原文中有圖示，基本看圖就清楚了，即在服務註冊庫前新增加了一個LoadBalancer節點。注：這兩個節點感覺是可以合併到API GateWay的能力中去的。
服務端發現模式兼具優缺點。它最大的優點是客戶端無需關注發現的細節，只需要簡單地向負載均衡器傳送請求，這減少了程式語言框架需要完成的發現邏輯。並且如上文所述，某些部署環境免費提供這一功能。這種模式也有缺點。除非負載均衡器由部署環境提供，否則會成為一個需要配置和管理的高可用系統元件。
服務登錄檔
服務登錄檔需要高可用而且隨時更新。客戶端能夠快取從服務登錄檔中獲取的網路地址，然而，這些資訊最終會過時，客戶端也就無法發現服務例項。因此，服務登錄檔會包含若干服務端，使用複製協議保持一致性。
首先可以看到服務登錄檔本身不能是單點，否則存在單點故障，當服務登錄檔有多臺伺服器的時候同時需要考慮服務註冊庫資訊在多臺機器上的實時同步和一致。我們操作和配置服務註冊資訊的時候往往只會在一個統一的服務管控端完成。
其次如果服務註冊伺服器宕機是否一定影響到服務本身的消費和呼叫，如果考慮更高的整體架構可用性，還可以設計對於服務註冊庫資訊在客戶端本地進行快取，當服務登錄檔無法訪問的時候可以臨時讀取本地快取的服務註冊庫資訊併發起服務訪問請求。
對於服務登錄檔，文章提供了三種選擇，感覺最常用的實現仍然是基於ZooKeeper進行的。
Etcd – 高可用、分散式、一致性的鍵值儲存，用於共享配置和服務發現。
Consul – 發現和配置的服務，提供 API 實現客戶端註冊和發現服務。
Apache ZooKeeper – 被分散式應用廣泛使用的高效能協調服務。
如前所述，服務例項必須在登錄檔中註冊和登出。註冊和登出有兩種不同的方法。方法一是服務例項自己註冊，也叫自注冊模式（self-registrationpattern）；另一種是採用管理服務例項註冊的其它系統元件，即第三方註冊模式。（原文有詳細機制描述，不再累述）
雖然方法一把服務例項和服務登錄檔耦合，必須在每個程式語言和框架內實現註冊程式碼。但是在自己實現完整微服務架構中，考慮到PaaS平臺下微服務模組的動態部署和擴充套件，採用方法1相當來說更加容易實現。但是方法1仍然不能代替服務註冊庫本身應該具備的服務節點的心跳檢測能力。