標籤：

SOA和微服務架構的區別？

01-07

謝多人邀請，其實前面幾位的回答已經差不多了，在這裡僅談下自己的簡單總結。

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

如果一句話來談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），其二微服務應用之間只能通過Service
API進行交互，其三一般運行在雲虛擬機或更輕的Docker容器上。


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


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

1. Y軸：本質是應用的分解，即將傳統的單體應用分解為多個微服務應用。

2. X軸：水平彈性擴展能力，即通過負載均衡來實現水平彈性擴展，但是DB問題無法解決，引入3

3. 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：面向服務架構，java級企業開發的首選。

微服務：採用一組服務的方式來構建一個應用，服務獨立部署在不同的進程中，不同服務通過一些輕量級交互機制來通信，例如 RPC、HTTP 等，服務可獨立擴展伸縮，每個服務定義了明確的邊界，不同的服務甚至可以採用不同的編程語言來實現，由獨立的團隊來維護。簡單的來說，一個系統的不同模塊轉變成不同的服務！而且服務可以使用不同的技術加以實現！

SOA我想我就不用細說了，使用java EE開發過的都知道其中的具體流程和步驟，J2EE的確在統一開發中有著很好的使用，但是隨著模塊功能的不斷擴展或者變動，對於其中一點的維護可能會影響到整體的項目。

所以有了微服務，徹底的將耦合性再次的降低了。為什麼要講我實習呢，因為微服務的使用會隨著單一進程的傳統應用被拆分為一系列的多進程服務後，意味著開發、調試、測試、集成、監控和發布的複雜度都會相應增大。 必須要有合適的自動化基礎設施來支持微服務架構模式，否則開發、運維成本將大大增加。所以自動化運維是十分必要的。

總的說來，微服務有以下幾個特徵：1. 通過服務實現組件化；2. 按業務能力來劃分服務與組織團隊；3. 服務即產品；4. 智能終端與啞管道；5. 去中心統一化；6. 基礎設施自動化；7. Design for failure；8. 進化設計

具體大家可以參考：http://blog.csdn.net/mindfloating/article/details/24583369

SOA

SOA的提出是在企業計算領域，就是要將緊耦合的系統，劃分為面向業務的，粗粒度，松耦合，無狀態的服務。服務發布出來供其他服務調用，一組互相依賴的服務就構成了SOA架構下的系統。

基於這些基礎的服務，可以將業務過程用類似BPEL流程的方式編排起來，而BPEL反映的是業務處理的過程，這些過程對於業務人員更為直觀，調整也比hardcode的代碼更容易。

當然企業還需要對服務治理，比如服務註冊庫，監控管理等。

我們知道企業計算領域，如果不是交易系統的話，並發量都不是很大的，所以大多數情況下，一台伺服器就容納將許許多多的服務，這些服務採用統一的基礎設施，可能都運行在一個應用伺服器的進程中。雖然說是面向服務了，但還是單一的系統。

微服務

而微服務架構大體是從互聯網企業興起的，由於大規模用戶，對分散式系統的要求很高，如果像企業計算那樣的系統，伸縮就需要多個容納續續多多的服務的系統實例，前面通過負載均衡使得多個系統成為一個集群。

但這是很不方便的，互聯網企業迭代的周期很短，一周可能發布一個版本，甚至可能每天一個版本，而不同的子系統的發布周期是不一樣的。

而且，不同的子系統也不像原來企業計算那樣採用集中式的存儲，使用昂貴的Oracle存儲整個系統的數據，二是使用MongoDB，HBase，Cassandra等NOSQL資料庫和Redis，memcache等分散式緩存。

那麼就傾向採用以子系統為分割，不同的子系統採用自己的架構，那麼各個服務運行自己的Web容器中，當需要增加計算能力的時候，只需要增加這個子系統或服務的實例就好了，當升級的時候，可以不影響別的子系統。這種組織方式大體上就被稱作微服務架構。

微服務與SOA相比，更強調分散式系統的特性，比如橫向伸縮性，服務發現，負載均衡，故障轉移，高可用。互聯網開發對服務治理提出了更多的要求，比如多版本，比如灰度升級，比如服務降級，比如分散式跟蹤，這些都是在SOA實踐中重視不夠的。

Docker容器技術的出現，為微服務提供了更便利的條件，比如更小的部署單元，每個服務可以通過類似Node.js或Spring Boot的技術跑在自己的進程中。可能在幾十台計算機中運行成千上萬個Docker容器，每個容器都運行著服務的一個實例。隨時可以增加某個服務的實例數，或者某個實例崩潰後，在其他的計算機上再創建該服務的新的實例。

這就是我對SOA和微服務架構區別的一點理解。

首先，可以肯定的是SOA和微服務的確是一脈相承的，大神Martin Fowler提出來這一概念可以說把SOA的理念繼續升華，精進了一步。其核心思想是在應用開發領域，使用一系列微小服務來實現單個應用的方式途徑，或者說微服務的目的是有效的拆分應用，實現敏捷開發和部署 ，可以是使用不同的編程語言編寫。而SOA可能包含的意義更泛一些，更不準確一些。

其次，從實現方式上，兩者都是中立性，語言無關，協議跨平台，相比SOA，微服務框架將能夠帶來更大的敏捷性，並為你構建應用提供更輕量級、更高效率的開發。而SOA更適合大型企業中的業務過程編排、應用集成。另外還有微服務甚至是去ESB、去中心化、分散式的，而SOA還是以ESB為核心，大量的WS標準實現。

再次，從服務粒度上，既然是微，必然微服務更倡導服務的細粒度，重用組合，甚至是每個操作（或方法）都是獨立開發的服務，足夠小到不能再進行拆分。而SOA沒有這麼極致的要求，只需要介面契約的規範化，內部實現可以更粗粒度，微服務更多為了可擴充性、負載均衡以及提高吞吐量而去分解應用，但同時也引發了打破數據模型以及維護一致性的問題。

最後，從部署方式上，這個是最大的不同，對比Monolithic（有人翻譯為單體）的Java EE部署架構，通過展現層打包WARs，業務層劃分到JARs最後部署為EAR一個大包，而微服務則打開了這個黑盒子，把應用拆分成為一個一個的單個服務，應用Docker技術，不依賴任何伺服器和數據模型，是一個 全棧應用，可以通過自動化方式獨立部署，每個服務運行在自己的進程中，通過輕量的通訊機制聯繫，經常是基於HTTP資源API，這些服務基於業務能力構建，能實現集中化管理（因為服務太多啦，不集中管理就無法DevOps啦）。

很久以前的一天，Martin 在跟好友的交流中悟到了一種很棒的架構設計。他總結了一下，然後告訴了好友，好友說，這不是新鮮東西，早有人總結了，叫做 SOA。

Martin 很高興，開始在公司內外推廣 SOA。結果，不停有人質疑和挑戰他。

你這不是 SOA 吧？SOA 這裡應該是如此這般的。對，這裡我對 SOA 的理解是這樣的。你看，這本 SOA 的書說的和你說的有出入。粒度？SOA 沒有談到這個呀，你這不是 SOA。分層跟 SOA 沒有關係，你為什麼要說這個呢？…

Martin 沒辦法，心一橫，老子就叫它 Martin"s SOA。老子發明的詞，老子就是最高權威，有最終解釋權。還有誰不服？

同事們一看，這思想本身很不錯，值得推廣，但叫 Martin"s SOA 太沒品了吧？還是要取個好一點的名字，最好還能跟 SOA 有某種暗示傳承。乾脆就叫 Microservices 好了，又新，又有服務含在其中。

Martin 忿忿地接受了這個建議，心裡想著：媽的，明明就是 SOA，一群傻逼非要逼我取個新名字。

後來 Martin 發現每次提一個東西就會收到舊惡傻勢力對解釋權的挑戰，所以每次要提一個什麼概念，都去發明一個新詞，免得一群人在那一邊質疑挑戰，一邊大談「我的理解」。

這就是微服務、敏捷、精益企業、持續集成、持續交付背後的故事。

一個名詞產生之後，命名者的解釋權就會隨著時間而弱化（比如 Cooper 發明的 Persona 就被無數設計師亂用）。敏捷已經有點爛了，等微服務也爛了，我們還會發明新詞。

實在沒轍，都是被逼的啊。

以一個公司為例：有基層員工 有管理層 有老闆，最初大家都聽老闆指揮，誰幹什麼誰幹什麼，根據需要，你可能今天干A事情，明天干B事情，後來人越來越多了，事情也越來越多了，做事情的效率越來越多，管理也很混亂，就開始做部門劃分（服務化），專門部門做專門事情的，IT部門只做研發，人事部門只做招聘； 這個時候就無法避免的發生跨部門協作（伺服器調用）， 但是你怎麼知道有這樣一個部門可以做這個事情呢，就要依賴行政部門（註冊中心），新成立的部門要在行政哪裡做一個備案（服務註冊），然後公布一下，讓其他部門知道了（服務發布），大家就可以在新的工作秩序裡面嗨皮的上班了，這個時候依然是在公司的組織架構中運轉；

上述就是我理解的SOA的概念

微服務沒有具體的實施過，通過自己的一些理解嘗試解釋一下，勿噴！

微服務有一定SOA的概念在裡面，只是在粒度中，微服務更加下一點，比如說用戶業務服務：登錄 註冊 個人中心 包含3個業務，都有userService 提供的，但是在微服務中，登錄會被獨立出來一個服務，註冊也會被獨立出來，相對SOA的粒度更新，業務場景耦合更低；

另外微服務強調一個去中心化，上述的公司的組織架構會被打散，沒有老闆，沒有管理層，每一個人都是一個服務，做著自己的事情，雖然沒有完全想明白，把自己的理解放出來，大家可以探討一下

先說明觀點：SOA與微服務不存在衝突問題，他們是相輔相承的！ SOA不是針對某一個系統的架構設計，他更多是針對整個企業的架構設計，他所解決的是更高層的整個企業各業務領域的整合問題。其實微服 務的概念非常像早期的Cobra，微服務是針對某單一業務功能的原子化架構設計，是解決下層具體業務實現的架構設計方法。微服務的顆粒度要求是一個funtion（）這樣的級別，一個單獨的funtion是不能匹配業務的，那麼肯定需要在其上層有一個實現調度的東西，Api Gateway就被提出來了。Api Gateway的主要作用是管理api,調度，轉換，拼裝，這這些是不是很熟悉？沒錯，它就是SOA架構中的核心:企業服務匯流排的作用。因此，微服務負責訪問資料庫封裝成服務，服務被註冊到esb，在esb中被轉換和拼裝，然後再給界面層使用。

手機碼字太累，先說那麼多。

最準確的說法：微服務是SOA的一種實現

最符合實際的說法：微服務是去ESB的SOA

背後實際上是兩種思想的分歧：分布還是集中

當然這裡說的不是服務的分布和集中。服務肯定是分布的，這是大前提，是SOA的本質理念之一。分歧在於對服務的治理，是分布還是集中。

一個三甲醫院的誕生

道理大家都說的差不多了，孫老師今天給大家講個故事。

話說1979年，又是一個春天，莆田鄉下的赤腳醫生吳大牛被改革的春風吹的心潮澎湃，說干就干，吳大牛趁著夜色朦朧找大隊支書彙報了彙報思想，第二天就承包了村衛生室，開啟了自己的在醫療圈的傳奇歷程。

鄉村診所大家都知道，沒什麼複雜的東東，房子只有一間，一個大櫃檯中間隔開，一半是診療兼候診區，一半是藥房，看病就直接找醫生，如果前面有人就自己找個位子坐下，排隊等一會，秩序倒也井然，看完病了醫生直接給抓藥，然後下一個繼續，也不需要護士和藥劑師，吳大牛一個人全部包辦。

辛辛苦苦忙碌了十年，時間來到了八九年，又是一個春天，昔日的單身漢吳大牛已成為十里八鄉的知名人物，媳婦娶上了不說，家裡還增加了一對雙胞胎兒子，二層的小洋房也甚是氣派。可是也有煩心事，儘管鄉村診所擴大到了兩間，媳婦還偶爾能去幫幫忙，但是醫生還是只有自己一個，天天從早忙到晚掙的都是一份錢，想多掙點怎麼辦？吳大牛日思夜想，還真給他想出來一招，怎麼辦，擴大規模，多招幾個醫生一起干。原來吳大牛隻能治頭疼腦熱和跌打損傷，現在新招了一個醫科大學的畢業生劉小明專治感冒發燒，又從鄰村請來了老大夫李阿花專治婦科病，現在一個普通的小診所就變成了有三個獨立科室加一個公共藥房（吳大牛媳婦負責）的小醫院了，吳大牛是外科主任兼院長，收入那可比之前翻了三番。人逢喜事精神爽，大牛院長請縣裡的書法名家為新醫院書寫了牌匾--「博愛醫院」，挑了一個黃道吉日正式掛了上去。

一晃十年過去了，又是一個春天，吳大牛的博愛醫院已經發展到了內科外科婦科五官科骨科生殖科六個科室，每個科室3到5名醫生不等，也耗費巨資購進了血夜化驗B超等先進儀器，大牛院長也早已脫離了醫療一線，成為了專職的管理者，但是醫院的大事小事大家都找他，就這三十多號員工搞的他每天是焦頭爛額，想再擴大規模實在是有心無力了。要說還是大學生有水平，老部下劉小明給大牛院長獻了一計，把各個科室獨立出去，讓各個科室主任自己管理，大牛院長只管科室之間的協調和醫院發展的大事，這樣既能調動基層的積極性，又能把大牛院長解放出來擴大生產抓大事謀大事，豈不妙哉？就這樣，博愛醫院的新一輪改革轟轟烈烈的展開了。

又是一個十年，又是一個春天，大牛院長已成為本地知名的企業家，博愛醫院也發展到了二十三個科室數百名員工，發展中也出現了新問題，由於各個科室獨立挂號、收費、化驗，有的科室整天忙忙碌碌效益好，有的科室就相對平庸些，連分到的各種檢查儀器都不能滿負荷運行，整個醫院養了不少閑人。這時候大牛院長視野也開闊了，請來了管理專家進行了頂層設計，把原來分散到各個科室的非核心服務全部收歸集中管理，把原來二十三個挂號窗口整合為十個，二十三個收費窗口整合為八個，集中布設在一樓大廳為全院服務，還把分散在各個科室的檢查儀器集中起來成立獨立的檢驗科，也為全院服務，這樣人人有活干，整個醫院的服務能力又上了一個新台階，這輪改革後博愛醫院通過了各級部門的鑒定成為了遠近馳名的三甲醫院，吳大牛也換身一變成為了博愛集團的CEO兼董事長，下一步就準備IPO上市了。

說到這裡大家可能有點糊塗，這個跟微服務有嘛關係？在孫老師看來，大牛診所的1.0階段就相當於軟體開發的單體結構，一個程序員打天下，從頭編到尾，很難做大做強。大牛診所的2.0階段就相當於軟體開發的垂直結構，各科室按照業務劃分，很容易橫向擴展。博愛醫院的1.0階段就相當於軟體開發的SOA結構，除了藥房（資料庫）外各個服務獨立提供（科室主任負責），但需要大牛院長（ESB匯流排）來協調。博愛醫院的2.0階段就相當於軟體開發的微服務結構，公共服務院內共享，科室主任管理功能弱化（只管醫生業務），優點是擴容方便，哪個部門缺人直接加，不用看上下游，資源利用率高，人員和設備效率高。

為什麼要變呢？小診所有小診所的活法，大醫院有大醫院的驕傲。

無他，天下熙熙，皆為利來；天下攘攘，皆為利往。

原文鏈接：多研究些架構，少談些框架（1） -- 論微服務架構的核心概念

微服務架構和SOA區別

微服務現在辣么火，業界流行的對比的卻都是所謂的Monolithic單體應用，而大量的系統在十幾年前都是已經是分散式系統了，那麼微服務作為新的理念和原來的分散式系統，或者說SOA（面向服務架構）是什麼區別呢？

我們先看相同點：

  • 需要Registry，實現動態的服務註冊發現機制；
  • 需要考慮分散式下面的事務一致性，CAP原則下，兩段式提交不能保證性能，事務補償機制需要考慮；
  • 同步調用還是非同步消息傳遞，如何保證消息可靠性？SOA由ESB來集成所有的消息；
  • 都需要統一的Gateway來匯聚、編排介面，實現統一認證機制，對外提供APP使用的RESTful介面；
  • 同樣的要關注如何再分散式下定位系統問題，如何做日誌跟蹤，就像我們電信領域做了十幾年的信令跟蹤的功能；

那麼差別在哪？

  • 是持續集成、持續部署？對於CI、CD（持續集成、持續部署），這本身和敏捷、DevOps是交織在一起的，我認為這更傾向於軟體工程的領域而不是微服務技術本身；
  • 使用不同的通訊協議是不是區別？微服務的標杆通訊協議是RESTful，而傳統的SOA一般是SOAP，不過目前來說採用輕量級的RPC框架Dubbo、Thrift、gRPC非常多，在Spring Cloud中也有Feign框架將標準RESTful轉為代碼的API這種仿RPC的行為，這些通訊協議不應該是區分微服務架構和SOA的核心差別；
  • 是流行的基於容器框架還是虛擬機為主？Docker和虛擬機還是物理機都是架構實現的一種方式，不是核心區別；

微服務架構的精髓在切分

  • 服務的切分上有比較大的區別，SOA原本是以一種「集成」技術出現的，很多技術方案是將原有企業內部服務封裝為一個獨立進程，這樣新的業務開發就可重用這些服務，這些服務很可能是類似供應鏈、CRM這樣的非常大的顆粒；而微服務這個「微」，就說明了他在切分上有講究，不妥協。無數的案例證明，如果你的切分是錯誤的，那麼你得不到微服務承諾的「低耦合、升級不影響、可靠性高」之類的優勢，而會比使用Monolithic有更多的麻煩。
  • 不拆分存儲的微服務是偽服務：在實踐中，我們常常見到一種架構，後端存儲是全部和在一個資料庫中，僅僅把前端的業務邏輯拆分到不同的服務進程中，本質上和一個Monolithic一樣，只是把模塊之間的進程內調用改為進程間調用，這種切分不可取，違反了分散式第一原則，模塊耦合沒有解決，性能卻受到了影響。

分散式設計第一原則 -- 「不要分布你的對象」

  • 微服務的「Micro」這個詞並不是越小越好，而是相對SOA那種粗粒度的服務，我們需要更小更合適的粒度，這種Micro不是無限制的小。

如果我們將兩路（同步）通信與小/微服務結合使用，並根據比如「1個類=1個服務」的原則，那麼我們實際上回到了使用Corba、J2EE和分散式對象的20世紀90年代。遺憾的是，新生代的開發人員沒有使用分散式對象的經驗，因此也就沒有認識到這個主意多麼糟糕，他們正試圖重複歷史，只是這次使用了新技術，比如用HTTP取代了RMI或IIOP。

微服務和Domain Driven Design

一個簡單的圖書管理系統肯定無需微服務架構。既然採用了微服務架構，那麼面對的問題空間必然是比較宏大，比如整個電商、CRM。

如何拆解服務呢？

使用什麼樣的方法拆解服務？業界流行1個類=1個服務、1個方法=1個服務、2 Pizza團隊、2周能重寫完成等方法，但是這些都缺乏實施基礎。我們必須從一些軟體設計方法中尋找，面向對象和設計模式適用的問題空間是一個模塊，而函數式編程的理念更多的是在代碼層面的微觀上起作用。

Eric Evans 的《領域驅動設計》這本書對微服務架構有很大借鑒意義，這本書提出了一個能將一個大問題空間拆解分為領域和實體之間的關係和行為的技術。目前來說，這是一個最合理的解決拆分問題的方案，透過限界上下文（Bounded Context，下文簡稱為BC）這個概念，我們能將實現細節封裝起來，讓BC都能夠實現SRP（單一職責）原則。而每個微服務正是BC在實際世界的物理映射，符合BC思路的微服務互相獨立松耦合。

微服務架構是一件好事，逼著大家關注設計軟體的合理性，如果原來在Monolithic中領域分析、面向對象設計做不好，換微服務會把這個問題成倍的放大

以電商中的訂單和商品兩個領域舉例，按照DDD拆解，他們應該是兩個獨立的限界上下文，但是訂單中肯定是包含商品的，如果貿然拆為兩個BC，查詢、調用關係就耦合在一起了，甚至有了麻煩的分散式事務的問題，這個關聯如何拆解？BC理論認為在不同的BC中，即使是一個術語，他的關注點也不一樣，在商品BC中，關注的是屬性、規格、詳情等等（實際上商品BC這個領域有價格、庫存、促銷等等，把他作為單獨一個BC也是不合理的，這裡為了簡化例子，大家先認為商品BC就是商品基礎信息）， 而在訂單BC中更關注商品的庫存、價格。所以在實際編碼設計中，訂單服務往往將關注的商品名稱、價格等等屬性冗餘在訂單中，這個設計解脫了和商品BC的強關聯，兩個BC可以獨立提供服務，獨立數據存儲

小結

微服務架構首先要關注的不是RPC/ServiceDiscovery/Circuit Breaker這些概念，也不是Eureka/Docker/SpringCloud/Zipkin這些技術框架，而是服務的邊界、職責劃分，劃分錯誤就會陷入大量的服務間的相互調用和分散式事務中，這種情況微服務帶來的不是便利而是麻煩。

DDD給我們帶來了合理的劃分手段，但是DDD的概念眾多，晦澀難以理解，如何抓住重點，合理的運用到微服務架構中呢？

我認為如下的幾個架構思想是重中之重

  • 充血模型
  • 事件驅動

花了很長時間去研究到底什麼是微服務，說下我的學習心得。

1.微服務是借用 SOA 的架構風格來構建單一產品的架構形式。

當然這個單一產品有點模糊，是需要根據自身業務來理解的。例如，一套電商系統就是一個單一產品，雖然它肯定是要包含用戶子系統、支付子系統、庫存管理子系統等等。傳統的構建方式，是通過進程內組件的方式來實現這些子系統，例如 Java 的 Spring Bean 等等。而微服務下，這些子系統是通過彼此獨立的服務的方式來構建，服務間通過且僅應該通過 rpc 或者 restful api 的方式來通信。

SOA 更多的是一種架構風格，一種通過彼此獨立的服務來構建系統的風格，它的範疇要比微服務大的多，例如 SOA 架構的系統里，可以有很多產品，外部的訪問點可以有多個，任何 SOA 里的系統都可以單獨為外界提供服務，用戶可能單獨使用其中的某個系統，所以 SOA 系統中需要的是一個消息匯流排；而微服務是一個單一產品，對外只能有一個訪問點，回到電商的例子，用戶是不可能單獨使用庫存子系統，用戶使用的肯定是一個完整的電商系統，因此微服務需要的是一個 API 網關。

2.什麼才是真正的微服務

我理解，除了通過跨進程介面來訪問服務外，微服務最核心的是數據獨立，即產品中不會有多個服務去共享同一個數據源，一個數據源一定只被一個服務專享，這裡要澄清下微服務中同一個服務還包括通過負載均衡下同一類服務的一群服務，這裡用「個」代「類」。

為什麼要強調數據獨立，現在的架構設計，可以說100%的都會要求架構設計低耦合高內聚，這方面的好處不多說，寫過幾年程序的都有心得。那麼在一個複雜產品（系統）中，最大的耦合是什麼呢，實際上是數據耦合，正是數據耦合導致我們的產品成為一個「巨」系統難以拆分。例如電商系統中，顯示用戶的訂單，還需要拿到些例如用戶電話號碼、地址之類的信息，因為開發時新的開發工程師不了解系統，沒有通過用戶服務直接從資料庫拿了用戶信息，就這樣訂單系統和用戶系統耦合了，雖然他們是兩個服務。結果就是有一天發現訂單系統壓力太大，升級或者拆分資料庫，卻因為和用戶的數據耦合在一塊不得不連帶升級用戶的服務，或者想要改進用戶的服務，卻發現訂單系統使用了同一份數據格式，結果用戶系統的修改導致了訂單系統的不可用。一個成熟的產品，往往要歷經數年的開發，資料庫一旦共享，數據之間的耦合就會越來越深，最終發現除了推倒重來外沒有人再能理清裡面的脈絡！

所以，服務間數據獨立、僅通過介面互相訪問才是評判是否是微服務系統的標誌（SOA倒不強調這個），而不是通過服務的大小，實際上，因為微服務的「微」字，給很多人包括我學習時造成了很大的困擾，甚至有位經驗豐富的架構師告訴我，微服務就是一個介面一個服務。另外，數據源要求彼此獨立，實際上也告訴了我們該如何切分服務，就是通過考察數據源如何獨立、隔離，來劃分各個服務。

3.那些 API 網關、熔斷、負載均衡和服務發現或者Docker什麼的是評判是否是微服務的嗎？

除了 API 網關在概念上是必需的，其它那些實際上不是微服務的核心概念里需要的，它們要麼是用來讓微服務可以運行的更好的工具，或者是能實際落地的工具。

API 網關：微服務是一個產品，所以一個產品必然需要一個統一的訪問入口，通過 API 網關，客戶端的請求才會導航到真正的服務上。

熔斷：微服務概念本身可以不要這個服務，但真正的生產環境是必需的。開發過分散式系統的工程師應該有感受，當某個服務特別慢時，依賴它的服務的請求就會堆積在這裡，導致整個系統的處理全部變慢（雪崩效應），這時候通過熔斷，我們給過多的請求直接返回錯誤，至少保證系統能夠運行下去。

負載均衡：負載均衡本身不多說，這裡只提一下為什麼微服務推薦用 restful api 的方式，restful 是基於 http 的，一方面請求無狀態才利於搞負載均衡，另一方面針對 http 的負載方案最多也最廉價。

服務發現：一個產品有那麼多的服務，哪個服務沒上線或者崩潰了，依賴它的服務是需要知道的。

Docker：還是，一個產品有那麼多的服務，可能會使用不同的語言編寫，可能會使用不同類型的數據源，有時候是MySQL，有時候是 Mongo 這樣的 NOSQL，部署一次懂點運維的會知道有多繁瑣和容易出錯，藉助 Docker，和各種編織工具，我們可以像在 iPhone 上安裝 APP 一樣快速部署，可以說是 Docker 讓微服務成為了現實中可落地的方案。

表示一臉懵圈......

下圖根據《微服務設計》一書中整理而來：

來自於：http://mp.weixin.qq.com/s/pMf-8pihbqy0SATk87389A

大部分公司並不需要微服務 - SDK.CN - 中國領先的開發者服務平台

面向服務和面向數據！

先說觀點：對傳統的微服務做法不是很看好。但是對豎直拆分+用jar包組裝這種方式很看好

給個直觀的表格

soa --- 性能低，開銷大，開發成本高（需多個項目），無事務支持，模塊化成都高

jar包組合 --- 性能高，開銷低，開發成本高（需多個項目），有事務支持，模塊化程度高

介面 --- 性能高，開銷低，開發成本低，有事務支持，模塊化程度不高容易被突破

如果你發現你的soa架構有類似的困擾，可以考慮下這個解決方案。

you should instead think of microservices as a specific approach for SOA in the same way that XP or Scrum are specific approaches for Agile software development.

SOA（面向服務的架構）是一種軟體架構，應用程序的不同組件通過通信協議向其他組件提供服務。通信可以包含簡單的數據傳遞，也可以是兩個或兩個以上的服務相互協調的服務。這些不同的服務執行一些小型的功能，例如驗證付款、創建用戶帳戶或登錄。

SOA不在於如何模塊化應用程序，而是如何通過集成分散式、分離維護和部署的軟體組件來組合應用程序。通過技術和標準使組件更容易在網路上通信，特別是IP網路。

SOA中有兩個主要角色:服務提供者和服務使用者。軟體代理可以同時扮演兩個角色。使用者層是用戶(應用程序的其他組件或第三方)與SOA交互的點，而提供者層由SOA中的所有服務組成。

SOA的名字起源於90年代中期，Gartner公司首先認識到了這一軟體架構的新興趨勢，並將它推廣到全球範圍。Gartner成功推動了SOA架構模式的深入發展。不過，分散式服務作為軟體架構則可以追溯到80年代初。

2微服務

在某種程度上，微服務是面向服務架構演進的下一步。這種架構是開發軟體、web或移動應用程序作為獨立服務套件的一種特殊方式。服務只提供一個特定的業務功能，如用戶管理、用戶角色、購物車、搜索引擎、社交媒體登錄等。此外，服務與服務之間彼此完全獨立，這意味著它們可以用不同的編程語言編寫，並使用不同的資料庫。集中式的服務管理幾乎是不存在的，微服務使用輕量級HTTP、REST或Trift API來進行內部通信。

微服務這個詞起源於2011年5月在威尼斯舉行的軟體架構師研討會。2012年5月，還是這一組人決定將「微服務」作為名字。不過在此之前，微軟、亞馬遜、Netflix和Facebook等主要科技公司已經在微服務領域工作了10多年。還有一些人把他們稱為「微web服務」或「細粒度SOA」。

乍一看，微服務似乎在談論與SOA同樣的事情。然而，微服務領域的先驅馬丁·弗勞爾說，應該把SOA看作是一套微服務的超集。

那麼，區別在哪裡?

如同上面的表格所展示的：

開發——在這兩種架構中，都可以使用不同的編程語言和工具開發服務，將技術的多樣性引入到開發團隊，在多個團隊中組織開發。但是，在SOA中，每個團隊需要了解公共通信機制。通過微服務，服務可以獨立於其他服務操作和部署。因此，更容易頻繁地部署新版本的微服務，或獨立擴展服務。

「邊界上下文」——SOA鼓勵共享組件，而微服務則試圖通過「邊界上下文」最小化共享。「邊界上下文」指組件和數據作為一個最小依賴項的單個單元的耦合。由於SOA依賴於多個服務來實現業務請求，因此構建在SOA上的系統比微服務慢。

通信——在SOA中，ESB可能成為影響整個系統的單一故障點。由於每個服務都是通過ESB進行通信，如果其中一個慢下來，就可以通過對該服務的請求阻塞ESB。而微服務的容錯能力要好得多。例如，如果一個微服務有內存故障，那麼只會影響這一個服務，其他微服務將繼續定期處理請求。

互操作性——SOA通過其消息傳遞中間件組件，使用多個異構協議。微服務試圖通過減少集成的選擇數量來簡化體系結構模式。因此，如果希望在異構環境中使用不同的協議集成多個系統，則需要考慮SOA。如果所有服務都可以通過相同的遠程協議訪問，微服務是更好的選擇。

範圍——SOA和微服務的主要區別在於大小和範圍。微服務的前綴「Micro」指的是內部組件的顆粒度，它比SOA要小得多。微服務中的服務組件通常只有一個目的。而SOA服務包括更多的業務功能，可以視為完整的子系統。

3結論

不能簡單地說一個架構比另一個更好，這主要取決於企業構建的應用程序的目的。SOA更適合於需要與其他應用程序集成的更大、更複雜的環境。也就是說，較小的應用程序並不適合SOA，因為它們不需要消息傳遞中間件組件。另一方面，微服務更適合於較小的、分區良好的基於web的系統。如果正在開發移動或web應用程序，那麼微服務將給開發人員更大的控制權。總之，微服務和SOA服務於不同的目的，是完全不同類型的架構。

微服務架構模式成熟之前，軟體領域討論的比較多的是SOA的架構模式。SOA早在1996年就由Gartner提出，作為面向服務的架構模式，SOA的理念是對於複雜的企業IT系統，按照不同的、可重用的粒度劃分，將功能相關的一組功能提供者組織在一起為消費者提供服務。SOA在實際的發展過程中並不順利，隨著ESB(Enterprise Service Bus)、Web Service、SOAP等技術出現，SOA才漸漸落地。但其主要解決的是企業內部不同IT資源之間的信息共享、互通等問題，相當長時間內的發展依賴於企業級軟體匯流排的進展，而這類軟體匯流排總體上厚重、大而全，但相互之間由不同的軟體廠家提供，自成體系無法互通，從而又制約了其發展。從SOA的面向服務而言，其與微服務架構模式中的服務化這類思想是基本一致的。落地實踐的過程中，微服務與SOA又有著明顯的區別。--《雲計算架構技術與實踐 第二版》

微服務與SOA區別

微服務：隔離；自己關注自己的一畝三分地

倉儲營銷資金 不同領域的劃分。。31個省份城市 但是大家可以一起溝通

語言貨幣身份證的基礎；把公司分成不同職能部門。。

是數據不斷拆分的過程。寫js的。。

5個1：一份數據；一組服務；一組獨立機器；一個團隊；一個原則

單sql單表；頂多加個索引；複雜sqlGG

優化sql

一個sql只查一張表。join，核心欄位等等，一個是業務更複雜；呈現網路化特徵；原有的oracal到了瓶頸期；應用伺服器資源配比

mysql 應用系統 1:1

沒實現微服務的：1:2

緩存 消息 文件 關係資料庫演變為各種各樣的

soa架構的實現策略，會有一些畫像

oracal

大資料庫

微服務里數據是隔離的；在不同的資料庫里；看情況；強調數據相互獨立；對應專屬的應用伺服器

服務和數據是散的；但是完成的東西是一樣的。操作還是一步。

物流軌跡 掃描信息

財務

把槍系統

要別的等著。。

不同的功能有不同的容器單元；部署可單獨擴容，功能之間相互隔離；

穩定 安全 獨立部署 獨立開發

1、介面 調用 比web servis 輕量

某節點掛了 會觸發很多應用節點信息掛掉；越底層影響越大----雪崩

因此需要：

資源隔離

資源限流

服務去中心化；部署去中心化

分散式架構 去中心化架構----弱中心化

配置中心 用戶中心

-----------------用戶中心-----------------------

核心是ID ；僅僅是ID；帶著密碼

登錄支付寶的時候可以用一系列的賬號 比如淘寶賬戶

收貨地址 積分賬戶

身份證一樣；ID；晶元

------------升級到會員平台------------------------

積分等基礎職能；支持了很多的業務

----------賬戶體系-----------

註冊賬戶是最基本的要求，根據ID能找到跟你相關的數據和業務

和支付寶互通起來；實現打通，就像身份證一樣

-----------------------------------------------------------------------------

越基礎的地方抽象成月基礎的東西

信息裁剪；百億調用量

HSF 只有java來服務的。。旺旺會涉及到c ，應用場景里沒有跨語言

穩定性產品 不是功能性產品；是否經歷過穩定性事件；也許沒有很多的功能。

應用啟動時加http鏈接，is ok？伺服器是不是好的。。檢測

A調用B團隊 文檔中心

有再多的人也不會有太多的團隊

hsf應用系統提供了哪些服務

了解提供了哪些服務

熔斷---降級--

客戶端熔斷 調庫存 調商品詳情 調價格等 調各種信息

1、菜鳥：到了一個什麼值 計算運費自動斷掉--業務方案：賠償---手動---做開關-硬熔斷

2、服務端的熔斷，客戶端覺得沒問題的時候，服務端就把包袱卸掉，手動和自動結合

3、帶來隱患的先關掉，做一堆開關，，，開關的常態化。。。放在配置中心裡。

交易好幾千台機器。

限流---我只能提供10000的量，超過就限制。

常態化的降級就是熔斷。。無線的團隊的工作內容 分工交互邊界---13年 移動互聯網

一堆需求，比如 地址 等 相同的提供技術方案或者包等等。。一萬個功能點。。

作為用戶中心

是 是自動的還是

是斷點的還是集群的

推薦閱讀：

TAG:面向服務的架構SOA | 微服務架構 |