我們可以先來看下什麼是微服務和SOA再來說他們之間的差別。

微服務

微服務 (Microservices) 就是一些協同工作小而自治的服務。

❝

2014年，Martin Fowler 與 James Lewis 共同提出了微服務的概念，定義了微服務是由以單一應用程式構成的小服務，自己擁有自己的行程與輕量化處理，服務依業務功能設計，以全自動的方式部署，與其他服務使用 HTTP API 通訊。同時服務會使用最小的規模的集中管理 (例如 Docker) 能力，服務可以用不同的程式語言與資料庫等元件實現 。「維基百科」

❞

拿 helloworld 程式來舉栗子，想象一下你是 helloworld 公司的 CTO（老闆還缺人嗎？會寫程式碼的那種），假設你們公司的 helloworld 業務遍佈全球，需要編寫不同語種的 helloworld 版本，分別輸出英語、日語、法語、俄語...現在世界有6000多種語言（奇怪的知識又增加了）。

有人會說這還不簡單我用switch case語句就完事了，同學，不要較真我就是舉個例子，現實中的業務比 helloworld 複雜多了。好了，我們姑且認為按語言輸出是個龐大複雜的工作，這時候就可以用微服務架構了，架構圖如下：

微服務架構

合久必分，鑑於「單體應用程式」有上述的缺點，單個應用程式被劃分成各種小的、互相連線的微服務，一個微服務完成一個比較單一的功能，相互之間保持獨立和解耦合，這就是微服務架構。

微服務與SOA

「面向服務的體系結構」 SOA (Service-Oriented Architecture) 聽起來和微服務很像，但 SOA 早期均使用了匯流排模式，這種匯流排模式是與某種技術棧強繫結的，比如：J2EE。這導致很多企業的遺留系統很難對接，切換時間太長，成本太高，新系統穩定性的收斂也需要一些時間，最終 SOA 看起來很美，但卻成為了企業級奢侈品，中小公司都望而生畏。

此外，實施SOA時會遇到很多問題，比如通訊協議（例如SOAP)的選擇、第三方中介軟體如何選擇、服務粒度如何確定等，目前也存在一些關於如何劃分系統的指導性原則，但其中有很多都是錯誤的。SOA並沒有告訴你如何劃分單體應用成微服務，所以在實施SOA時會遇到很多問題。

這些問題在微服務框架中得到很好的解決，你可以認為微服務架構是SOA的一種特定方法。

關於微服務更詳細的你可以在我的這篇文章找到更多線索「面試都在問的微服務、RPC、服務治理...一文幫你徹底搞懂！」https://www.toutiao.com/i6812227529684812292/

微服務架構強調的第一個重點就是業務系統需要徹底的元件化和服務化，原有的單個業務系統會拆分為多個可以獨立開發，設計，執行和運維的小應用。這些小應用之間透過服務完成互動和整合。每個小應用從前端web ui，到控制層，邏輯層，資料庫訪問，資料庫都完全是獨立的一套。在這裡我們不用元件而用小應用這個詞更加合適，每個小應用除了完成自身本身的業務功能外，重點就是還需要消費外部其它應用暴露的服務，同時自身也將自身的能力朝外部發布為服務。

如果一句話來談SOA和微服務的區別，即微服務不再強調傳統SOA架構裡面比較重的ESB企業服務匯流排，同時SOA的思想進入到單個業務系統內部實現真正的元件化。

詳細講概念前我們可以先看下從單體應用到微服務架構的變化圖。

把這個核心搞清楚後，再來看下網上找到的對微服務架構的一些定義和闡述：

微服務可以在“自己的程式”中執行，並透過“輕量級裝置與HTTP型API進行溝通”。關鍵在於該服務可以在自己的程式中執行。透過這一點我們就可以將服務公開與微服務架構（在現有系統中分佈一個API）區分開來。在服務公開中，許多服務都可以被內部獨立程序所限制。如果其中任何一個服務需要增加某種功能，那麼就必須縮小程序範圍。在微服務架構中，只需要在特定的某種服務中增加所需功能，而不影響整體程序。微服務不需要像普通服務那樣成為一種獨立的功能或者獨立的資源。定義中稱，微服務是需要與業務能力相匹配，這種說法完全正確。不幸的是，仍然意味著，如果能力模型粒度的設計是錯誤的，那麼，我們就必須付出很多代價。如果你閱讀了Fowler的整篇文章，你會發現，其中的指導建議是非常實用的。在決定將所有元件組合到一起時，開發人員需要非常確信這些元件都會有所改變，並且規模也會發生變化。服務粒度越粗，就越難以符合規定原則。服務粒度越細，就越能夠靈活地降低變化和負載所帶來的影響。然而，利弊之間的權衡過程是非常複雜的，我們要在配置和資金模型的基礎上考慮到基礎設施的成本問題。

再強調下即：

首先對於應用本身暴露出來的服務，是和應用一起部署的，即服務本身並不單獨部署，服務本身就是業務元件已有的介面能力釋出和暴露出來的。瞭解到這點我們就看到一個關鍵，即我們在進行單個應用元件設計的時候，本身在元件內部就會有很大介面的設計和定義，那麼這些介面我們可以根據和外部其它元件協同的需要將其釋出為微服務，而如果不需要對外協同我們完全可以走內部API介面訪問模式提高效率。

其次，微服務架構本身來源於網際網路的思路，因此元件對外發布的服務強調了採用HTTP Rest API的方式來進行。這個也可以看到在網際網路開放能力服務平臺基本都採用了Http API的方式進行服務的釋出和管理。從這個角度來說，元件超外部暴露的能力才需要釋出為微服務，其本身也是一種封裝後的粗粒度服務。而不是將元件內部的所有業務規則和邏輯，元件本身的底層資料庫CRUD操作全部朝外部發布。否則將極大的增加服務的梳理而難以進行整體服務管控和治理。

微服務的基本思想在於考慮圍繞著業務領域元件來建立應用，這些就應用可獨立地進行開發、管理和加速。在分散的元件中使用微服務雲架構和平臺使部署、管理和服務功能交付變得更加簡單。

對於網際網路談到微服務架構一定會談到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），其二微服務應用之間只能透過Service API進行互動，其三一般執行在雲虛擬機器或更輕的Docker容器上。

API Gateway，這實際上微服務架構裡面的很重要的內容，其作用類似於傳統企業內部的ESB服務匯流排，只是更加輕量和高效能來解決微服務的管控和治理問題。而對於負載均衡，快取，路由，訪問控制，服務代理，監控，日誌等都屬於基本的服務管控內容，也是API Gateway需要考慮的核心能力。

Scale Cube的3D模型，描述的相當好，即透過微服務架構實施後擴充套件性的變化。

1. Y軸：本質是應用的分解，即將傳統的單體應用分解為多個微服務應用。2. X軸：水平彈性擴充套件能力，即透過負載均衡來實現水平彈性擴充套件，但是DB問題無法解決，引入33. Z軸：當單個微服務應用引入了DB彈性擴充套件能力要解決的時候，我們引入了對資料庫進行拆分和DaaS

對於微服務架構的好處前面在講單體應用的問題的時候已經談到了，微服務架構正好是解決這些問題。而對於微服務架構的不足，簡單總結如下：

1. CAP原則：由於服務無狀態和引入了分散式，較難解決事務一致性問題。2. 整合複雜：任何徹底的分解都將帶來整合的複雜度，即模組在整合時候需要外部微服務模組更多的配合。3. 部署問題：稍大專案都涉及到上100個服務節點部署，還涉及到部署後的配置，擴充套件和監控問題。

第二篇 使用API閘道器構建微服務

首先說下這篇文章的引入場景，以一個亞馬遜購物網站的手機APP訂單檢視介面來舉例，如果是一個單體應用，那麼所有的介面需要獲取資訊都透過單體應用統一一個地址提供的多個Service API獲取。但是轉變為微服務架構後可以看到對於會員管理，商品管理，訂單管理，財務結算管理等都已經拆分為了不同的微服務模組，需要從不同的服務提供地址呼叫不同的微服務模組提供的Service API來返回資料。

在原文裡面我們看到對於客戶端和微服務模組間點對點直接通訊提了三個問題，如下：

1. 問題一：客戶端需求和每個微服務暴露的細粒度 API 不匹配2. 問題二：部分服務使用的協議對 web 並不友好，如二進位制RPC或AMQP訊息等。3. 問題三：會使得微服務難以重構，如服務拆分或服務組合的場景。

那麼我們從傳統的ESB能力來對上面三個問題進行一個說明，第一個問題即可能涉及到細粒度的API組合，類似組合服務無法做；其二是可能存在協議轉換的問 題要解決；其三即服務透明的問題，即需要對客戶端提供一個統一的服務目錄以使底層服務透明。由於以上問題，引入了API服務閘道器的概念，再次強調，對於API服務閘道器即使微服務架構裡面的輕量服務匯流排，解決服務管控和治理相關問題。文中對API Gateway給出如下說明：

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 閘道器變成了開發瓶頸。

簡單來說，在我們期望的去中心化和全分散式架構中，閘道器又成了一箇中心點或瓶頸點，正是由於這個原因我們在閘道器設計的時候必須考慮即使API Gateway宕機也不要影響到服務的呼叫和執行。

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平臺和微服務架構實現中仍然是大量以採用Rest API介面為主。而對於訊息格式的選擇，可以看到在使用RestAPI介面的時候，更多的是採用了Json訊息格式而非XML，對於SOAP WebService則更多采用了XML訊息格式。如果採用Thrift則還可以採用二進位制訊息格式以提升效能。第四篇 服務發現的可行方案以及實踐案例首先還是先說場景，看似簡單的服務註冊和服務目錄庫管理為何會變複雜，其主要的原因還是在結合了雲端PaaS和Docker容器部署後，對於微服務模組部 署完成後提供出來的IP地址是動態在變化的，包括模組在進行動態叢集擴充套件的時候也需要動態接入新的服務提供IP地址。正是由於這個原因引入了服務發現和管 理的困難度。在文章中提到了兩種服務發現模式，即客戶端發現模式和服務端發現模式，分開描述如下：

服務客戶端發現模式

使用客戶端發現模式時，客戶端決定相應服務例項的網路位置，並且對請求實現負載均衡。客戶端查詢服務登錄檔，後者是一個可用服務例項的資料庫；然後使用負 載均衡演算法從中選擇一個例項，併發出請求。客戶端從服務註冊服務中查詢，其中是所有可用服務例項的庫。客戶端使用負載均衡演算法從多個服務例項中選擇出一 個，然後發出請求。

注：這是類似Dubbo實現機制一樣的兩階段模式，即任何一個服務的消費都需要分兩個步驟進行，第一步首先是訪問服務註冊庫（更多是API GateWay提供的一個能力）返回一個已經動態均衡後的服務可用地址，第二步即客戶端和該地址直接建立連線進行服務消費和訪問。

在這種模式的實現中有兩個重點，其一是動態負載均衡演算法，其二是服務閘道器需要能夠對原始服務提供點進行實時的心跳檢測以確定服務提供的可用性。

Netflix OSS 是客戶端發現模式的絕佳範例。Netflix Eureka 是一個服務登錄檔，為服務例項註冊管理和查詢可用例項提供了 REST API 介面。Netflix Ribbon 是 IPC 客戶端，與 Eureka 一起實現對請求的負載均衡。

缺點：底層的IP雖然動態提供出去了，但是最終仍然暴露給了服務消費方，再需要進一步做安全和防火牆隔離的場景下顯然是不能滿足要求的。

服務端發現模式

客戶端透過負載均衡器向某個服務提出請求，負載均衡器查詢服務登錄檔，並將請求轉發到可用的服務例項。如同客戶端發現，服務例項在服務登錄檔中註冊或登出。在原文中有圖示，基本看圖就清楚了，即在服務註冊庫前新增加了一個Load Balancer節點。注：這兩個節點感覺是可以合併到API GateWay的能力中去的。

服務端發現模式兼具優缺點。它最大的優點是客戶端無需關注發現的細節，只需要簡單地向負載均衡器傳送請求，這減少了程式語言框架需要完成的發現邏輯。並且 如上文所述，某些部署環境免費提供這一功能。這種模式也有缺點。除非負載均衡器由部署環境提供，否則會成為一個需要配置和管理的高可用系統元件。服務登錄檔

服務登錄檔需要高可用而且隨時更新。客戶端能夠快取從服務登錄檔中獲取的網路地址，然而，這些資訊最終會過時，客戶端也就無法發現服務例項。因此，服務登錄檔會包含若干服務端，使用複製協議保持一致性。

首先可以看到服務登錄檔本身不能是單點，否則存在單點故障，當服務登錄檔有多臺伺服器的時候同時需要考慮服務註冊庫資訊在多臺機器上的實時同步和一致。我們操作和配置服務註冊資訊的時候往往只會在一個統一的服務管控端完成。

其次如果服務註冊伺服器宕機是否一定影響到服務本身的消費和呼叫，如果考慮更高的整體架構可用性，還可以設計對於服務註冊庫資訊在客戶端本地進行快取，當服務登錄檔無法訪問的時候可以臨時讀取本地快取的服務註冊庫資訊併發起服務訪問請求。

對於服務登錄檔，文章提供了三種選擇，感覺最常用的實現仍然是基於ZooKeeper進行的。

Etcd – 高可用、分散式、一致性的鍵值儲存，用於共享配置和服務發現。Consul – 發現和配置的服務，提供 API 實現客戶端註冊和發現服務。Apache ZooKeeper – 被分散式應用廣泛使用的高效能協調服務。

如前所述，服務例項必須在登錄檔中註冊和登出。註冊和登出有兩種不同的方法。方法一是服務例項自己註冊，也叫自注冊模式（self-registration pattern）；另一種是採用管理服務例項註冊的其它系統元件，即第三方註冊模式。（原文有詳細機制描述，不再累述）

雖然方法一把服務例項和服務登錄檔耦合，必須在每個程式語言和框架內實現註冊程式碼。但是在自己實現完整微服務架構中，考慮到PaaS平臺下微服務模組的動 態部署和擴充套件，採用方法1相當來說更加容易實現。但是方法1仍然不能代替服務註冊庫本身應該具備的服務節點的心跳檢測能力。

SOA架構強調的是整體企業IT架構，而企業IT架構包括應用架構、資料架構、技術架構，SOA架構及方法論幫助企業制定正確的IT架構戰略，將企業系統劃分為不同的服務，增強系統間的靈活性的同時，為企業搭建一個統一的IT治理體系。微服務架構更多則側重於應用架構，或者說應用開發的技術架構。

早期SOA剛興起時，提到SOA，經常想到ESB，ESB定位是透過熱拔插方式實現系統的整合、互聯互通，SOA是一個概念，ESB做支撐落地SOA，SOA架構更加偏重於企業資產的複用，資源服務化管理，解決異構應用的對接和服務化。

微服務強調服務拆分儘可能小，服務相互獨立無互相依賴，儘可能使用簡單協議如REST，微服務更加強調服務的自治性，每個模組模組能夠單獨部署，這樣一方面簡化了模組重組排列的方式，但同時將每一個應用拆分為單獨的部署工程增加了工程下測試、運維的難度。

微服務首先是一個架構思想，和它同一層面的東西有SOA，SOA是一種粗粒度、松耦合的的服務架構，強調的是異構系統之間的通訊和解耦合，而微服務架構強調的是系統按業務邊界做細粒度的拆分和部署：

兩者有個最明顯的區別，SOA的通訊使用企業服務匯流排ESB，微服務的通訊使用輕量級通訊協議如Restful。

單體架構 基於ESB（企業服務匯流排）的SOA架構 網際網路技術發展的必然產物微服務架構

單體架構和SOA架構系統部署，管理相對簡單，但系統健壯性，靈活性，擴充套件性相對一般，適合業務，使用者量，變化相對穩定的場景。

微服務架構系統靈活性，健壯性，擴充套件性好，特別適合需求變化迅速的場景。但系統複雜度高，部署，管理難度大。

東軟的微服務架構做的不錯，具體可以去官網看看，https://platform.neusoft.com/

微服務架構系統靈活性，健壯性，擴充套件性好，特別適合需求變化迅速的場景。但系統複雜度高，部署，管理難度大。微服務除了開發期框架之外，還有需要一系列的執行期中介軟體支撐，如API閘道器，服務註冊中心，統一配置中心等。 目前國內比較成熟的吧，東軟有一支團隊在做，他們網站是 https://platform.neusoft.com/

筆者目前就職於國內知名網際網路公司，做過toG和toB的私有化專案的微服務架構設計，也做過大型產品層面的微服務架構設計，就SOA和微服務架構的區別這個問題，來談一談我的看法。

不同的聲音

某些針對微服務架構的批評聲稱微服務其實就是SOA，並沒有新鮮的內容。在某些層面，它們的確有些相似。SOA和微服務架構都是特定的架構風格，它們都以一系列服務的方式來把一個系統組織在一起。但如果深入研究，你就會發現微服務和SOA之間巨大的差異。

SOA與微服務差異

SOA與微服務的差異主要體現在三個方面：服務間通訊、資料管理、服務規模：

1 服務間通訊

SOA和微服務架構通常採用完全不同的技術棧：

SOA採用智慧管道，如Enterprise Service Bus(ESB，是包含了業務和訊息處理的智慧管道），往往採用重量級協議，例如SOAP或其他WS*標準；

微服務使用啞管道，例如訊息代理，或者服務之間點對點通訊，例如restfull請求或者grpc類的輕量級協議。

2 資料管理

SOA和微服務架構在處理資料的方式上也不盡相同:

SOA採用全域性資料模型並共享資料庫；

微服務架構則是每個服務都有自己的資料模型和資料庫。更進一步,每一個服務一般都擁有屬於它自己的領域模型。（筆者後續會有文章專門講述領域模型設計）

3 服務規模

SOA和微服務架構之間的另一個重要區別就是服務的尺寸（規模）：

SOA善於整合大型、複雜的單體應用程式；

微服務則是拆分為較小的服務

SOA與微服務架構圖

一個典型的SOA系統架構如下：

一個典型的微服務架構如下：

SOA粗暴理解：把系統按照實際業務，拆分成剛剛好大小的、合適的、獨立部署的模組，每個模組之間相互獨立。

每個模組之間都能獨立執行，不會缺少某個程式無法使用的情況，有比較強的容錯率，多服務的情況服務之間的治理、還有問題的排查就會以幾何程度增加，但是同時也增加了服務的高可用性 ，橫向擴充套件能力。

需要透過中介軟體來達成服務之間的溝通。

微服務架構強調的第一個重點就是

業務系統需要徹底的元件化和服務化，原有的單個業務系統會拆分為多個可以獨立開發，設計，執行和運維的小應用。這些小應用之間透過服務完成互動和整合。每個小應用從前端web ui，到控制層，邏輯層，資料庫訪問，資料庫都完全是獨立的一套。在這裡我們不用元件而用小應用這個詞更加合適，每個小應用除了完成自身本身的業務功能外，重點就是還需要消費外部其它應用暴露的服務，同時自身也將自身的能力朝外部發布為服務。

如果一句話來談SOA和微服務的區別，即微服務不再強調傳統SOA架構裡面比較重的ESB企業服務匯流排，同時SOA的思想進入到單個業務系統內部實現真正的元件化。

國內做的不錯的有天翎、泛微、藍凌、道一。這些產品都有一些微服務化的版本。可以去下載參考一下

SOA：面向服務的架構，是一種設計方法，其中包含多個服務， 服務之間透過相互依賴最終提供一系列的功能。微服務架構:和 SOA 類似，可以說是在 SOA 上做的昇華。強調的一個重點是“業務需要徹底的元件化和服務化”，可拆分為多個可以獨立開發、設計、執行的小應用。

相對傳統的SOA，微服務架構的優勢在於：

1 易於開發和維護；

2單個微服務啟動較快；

3區域性修改容易部署；

4 技術棧不受限；

5 按需收縮。

從上面來看，微服務架構確實彌補解決了SOA單體架構的缺陷，這也是我們公司現在採用天翎MyApps的主要原因之一，在使用者體驗、資料庫管理、專案管理等方面體現了強大的技能。