微服務架構強調的第一個重點就是業務系統需要徹底的組件化和服務化，原有的單個業務系統會拆分爲多個可以獨立開發，設計，運行和運維的小應用。這些小應用之間通過服務完成交互和集成。每個小應用從前端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日誌的服務進行日誌記錄，而其它服務只提供服務目錄和訪問控制即可。
作者：何明璐
鏈接：https://www.zhihu.com/question/37808426/answer/93335393
來源：知乎
著作權歸作者所有，轉載請聯繫作者獲得授權。
本文爲閱讀《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啦）。
以一個公司爲例：有基層員工 有管理層 有老闆，最初大家都聽老闆指揮，誰幹什麼誰幹什麼，根據需要，你可能今天干A事情，明天干B事情，後來人越來越多了，事情也越來越多了，做事情的效率越來越多，管理也很混亂，就開始做部門劃分（服務化），專門部門做專門事情的，IT部門只做研發，人事部門只做招聘； 這個時候就無法避免的發生跨部門協作（服務器調用）， 但是你怎麼知道有這樣一個部門可以做這個事情呢，就要依賴行政部門（註冊中心），新成立的部門要在行政哪裏做一個備案（服務註冊），然後公佈一下，讓其他部門知道了（服務發佈），大家就可以在新的工作秩序裏面嗨皮的上班了，這個時候依然是在公司的組織架構中運轉；
上述就是我理解的SOA的概念
微服務沒有具體的實施過，通過自己的一些理解嘗試解釋一下，勿噴！
微服務有一定SOA的概念在裏面，只是在粒度中，微服務更加下一點，比如說用戶業務服務：登錄 註冊 個人中心 包含3個業務，都有userService 提供的，但是在微服務中，登錄會被獨立出來一個服務，註冊也會被獨立出來，相對SOA的粒度更新，業務場景耦合更低；
另外微服務強調一個去中心化，上述的公司的組織架構會被打散，沒有老闆，沒有管理層，每一個人都是一個服務，做着自己的事情，雖然沒有完全想明白，把自己的理解放出來，大家可以探討一下
先說明觀點：SOA與微服務不存在衝突問題，他們是相輔相承的！ SOA不是針對某一個系統的架構設計，他更多是針對整個企業的架構設計，他所解決的是更高層的整個企業各業務領域的整合問題。其實微服 務的概念非常像早期的Cobra，微服務是針對某單一業務功能的原子化架構設計，是解決下層具體業務實現的架構設計方法。微服務的顆粒度要求是一個funtion（）這樣的級別，一個單獨的funtion是不能匹配業務的，那麼肯定需要在其上層有一個實現調度的東西，Api Gateway就被提出來了。Api Gateway的主要作用是管理api,調度，轉換，拼裝，這這些是不是很熟悉？沒錯，它就是SOA架構中的核心:企業服務總線的作用。因此，微服務負責訪問數據庫封裝成服務，服務被註冊到esb，在esb中被轉換和拼裝，然後再給界面層使用。
手機碼字太累，先說那麼多。
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.
原文：https://www.zhihu.com/question/37808426