atititi.soa 微服務區別聯繫優缺點.doc 1. 應用微服務的動機，跟傳統巨石應用的比較1 2. 面向服務架構（SOA） esb2 3. 微服務架構（Microservices）2 4. 微服務架構特征（Characteristics）3 4.1. 通過服務實現組件化 vs 通過庫（

atititi.soa 微服務區別聯繫優缺點.doc

1. 應用微服務的動機，跟傳統巨石應用的比較

web應用程式發展的早期，大部分web工程是將所有的功能模塊(service side)打包到一起並放在一個web容器中運行，很多企業的Java應用程式打包為war包。其他語言(Ruby，Python或者C++)寫的程式也有類似的問題。

假設你正在構建一個線上商店系統：客戶下訂單、核對清單和信用卡額度，並將貨物運輸給客戶。很快，你們團隊一定能構造出如下圖所示的系統。

這種將所有功能都部署在一個web容器中運行的系統就叫做巨石型應用。巨石型應用有很多好處：IDE都是為開發單個應用設計的、容易測試——在本地就可以啟動完整的系統、容易部署——直接打包為一個完整的包，拷貝到web容器的某個目錄下即可運行。

但是，上述的好處是有條件的：應用不那麼複雜。對於大規模的複雜應用，巨石型應用會顯得特別笨重：要修改一個地方就要將整個應用全部部署(PS：在不同的場景下優勢也變成了劣勢);編譯時間過長;回歸測試周期過長;開發效率降低等。另外，巨石應用不利於更新技術框架，除非你願意將系統全部重寫(代價太高你願意老闆也不願意)。

作者:: 綽號:老哇的爪子（全名：：Attilax Akbar Al Rapanui 阿提拉克斯阿克巴阿爾拉帕努伊）漢字名：艾龍， EMAIL:[email protected]

轉載請註明來源： http://www.cnblogs.com/attilax/

2. 面向服務架構（SOA） esb

面向服務架構 SOA 思想概念的提出已不是什麼新鮮事，大概在10年前就有不少相關書籍介紹過。當時 java 企業應用領域 J2EE 依然是主流，應用程式被部署在龐大統一的符合 J2EE 規範的容器中運行，在單一進程中提供所有的功能。而 SOA 提出的一些架構原則，在當時看來無疑是革命性的。由於業已存在的大量單一龐大的應用，按照 SOA 的思想和架構原則來改造無疑相當於推翻重新開發一遍，在成本上很難接受。因此早期的 SOA 通常和另外一個術語關聯在一起——ESB（企業服務匯流排）。當時在 SOA 的實施思路上無一例外的選擇了 ESB 模式來整合集成大量單一龐大的應用，以保護企業前期投入成本。因此 ESB 其實是 SOA 特定歷史階段的一種實現方式。

3. 微服務架構（Microservices）

對微服務架構我們沒有一個明確的定義，但簡單來說微服務架構是：

採用一組服務的方式來構建一個應用，服務獨立部署在不同的進程中，不同服務通過一些輕量級交互機制來通信，例如 RPC、HTTP 等，服務可獨立擴展伸縮，每個服務定義了明確的邊界，不同的服務甚至可以採用不同的編程語言來實現，由獨立的團隊來維護。

4. 微服務架構特征（Characteristics）

4.1. 通過服務實現組件化 vs 通過庫（library）

傳統實現組件的方式是通過庫（library），傳統組件是和應用一起運行在進程中，組件的局部變化意味著整個應用的重新部署。通過服務來實現組件，意味著將應用拆散為一系列的服務運行在不同的進程中，那麼單一服務的局部變化只需重新部署對應的服務進程。另外將服務作為組件可以更明確的定義出組件的邊界，因為服務之間的調用是跨進程的，清晰的邊界和職責定義是設計時必須考慮的。

　微服務哲學還給企業提供了框架，用於思考如何拆分應用，以一種可擴展成不同部分的應用形式。其中一個較好的方法是把應用拆分成獨立的容器，使用內部應用相互通信，而不是使用傳統的SOA進行內部應用通信，Anuff說。

有了微服務，電腦的最小單元就是最小的Docker容器，10行的node.js代碼

4.2. 去中心統一化 vs 統一的技術平臺

傳統應用中傾向採用統一的技術平臺或產品來解決所有問題。不是每個問題都是釘子，也不是每個解決方案都是一個錘子。問題有其具體性，解決方案也應有其針對性。用最適合的技術方案去解決具體的問題，在大一統的傳統應用中其實很難做到，而微服務的架構意味著，你可以針對不同的業務服務特征選擇不同的技術平臺或產品，有針對性的解決具體的業務問題。

4.3. 7. Design for failure

正因為將服務獨立在不同的進程中後，引入了額外的失敗因素。任何時刻對服務的調用都可能因為服務方不可用導致失敗，這就要求服務的消費方需要優雅的處理此類錯誤。這其實是相對傳統應用開發方式的一個缺點，不過隨著一些開源服務化框架的出現，對業務開發人員而言適當的屏蔽了類似的錯誤處理，不過開發人員依然需要知道對服務的調用是完全不同於進程內的方法或函數調用的

5. 服務劃分有兩個原則要遵循：單一職責原則每個工具都小而美

(1)每個服務應該儘可能符合單一職責原則——Single Responsible Principle，即每個服務只做一件事，並把這件事做好;(

(2)2)參考Unix命令行工具的設計，Unix提供了大量的簡單易用的工具，例如grep、cat和find。每個工具都小而美。

6. 比較soa

　微服務架構和SOA是不一樣的。但高層次的想法源於對龐大應用程式的沮喪。Martin Fowler在一片文章中的解釋比這個全面得多。把你的應用程式作為服務套件，而不是一個緊密耦合整體的代碼來創建時，更容易修改和維護——特別是需要全天候運行的Internet應用程式。只要重構和重新部署幾個服務，並不需要重裝並重新釋放整體

6.1. 相似卻不相同

微服務與SOA有很多相同之處。兩者都屬於典型的、包含松耦合分散式組件的系統結構。但是兩種架構背後的意圖是不同的：SOA嘗試將應用集成，一般採用中央管理模式來確保各應用能夠交互運作。微服務嘗試部署新功能，快速有效地擴展開發團隊。它著重於分散管理、代碼再利用與自動化執行。

總結：

功能	SOA	微服務
組件大小	大塊業務邏輯	單獨任務或小塊業務邏輯
耦合	通常松耦合	總是松耦合
公司架構	任何類型	小型、專註於功能交叉的團隊
管理	著重中央管理	著重分散管理
目標	確保應用能夠交互操作	執行新功能，快速拓展開發團隊

7. 案例:shop

按照功能和資源劃分後，就形成下麵圖3的架構圖。分解後的微服務架構包含多個前端服務和後端服務。前端服務包括Catalog UI(用於商品搜索和瀏覽)、Checkout UI(用於實現購物車和下單操作);後端服務包括一些業務邏輯模塊，我們將在巨石應用中的每個服務模塊重構為一個單獨的服務。

服務。這麼做有什麼問題呢?

8. 微服務架構的關鍵問題

8.1. 1. 微服務架構的通信機制

(1)客戶端與伺服器之間的通信

，客戶端可以向micro service發起RESTful HTTP請求，但是會有這種情況發生：客戶端為了完成一個業務邏輯，需要發起多個HTTP請求，從而造成系統的吞吐率下降，再加上無線網路的延遲高，會嚴重影響客戶端的用戶體驗。

為瞭解決這個問題，一般會在伺服器集群前面再加一個角色：API gateway，由它負責與客戶度對接，並將客戶端的請求轉化成對內部服務的一系列調用。這樣做還有個好處是，服務升級不會影響到客戶端，只需要修改 API gateway即可。加了API gateway之後的系統架構圖如圖5所示。

(2)內部服務之間的通信

內部服務之間的通信方式有兩種：基於HTTP協議的同步機制(REST、RPC);基於消息隊列的非同步消息處理機制(AMQP-based message broker)。

8.2. 2. 分散式數據管理

(1)處理讀請求

(2)處理更新請求

當一份數據位於多個服務上時，必須保證數據的一致性。

分散式事務(Distributed transactions)使用分散式事務非常直觀，即要更新Customer Service上的信用卡額度，就必須同時更新其他服務上的副本，這些操作要麼全做要麼全不做

9. 重構巨石型應用

在實際工作中，很少有機會參與一個全新的項目，需要處理的差不多都是存在這樣那樣問題的複雜、大型應用。這時候如何在維護老服務的同時，將系統漸漸重構為微服務架構呢?

不要讓事情更壞，有新的需求過來時，如果可以獨立開發為一個服務，就單獨開發，然後為老服務和新服務直接編寫膠水代碼(Glue Code)——這個過程不容易，但這是分解巨型服務的第一步，如圖7所示;

識別巨石型應用中的可以分離出來當做單獨服務的模塊，一般適合分離的模塊具有如下特點：兩個模塊對資源的需求是衝突的(一個是CPU密集型、一個是IO密集型);授權鑒定層也適合單獨分離出一個服務。每分離出一個服務，就需要編寫對應的膠水代碼來與剩下的服務通信，這樣，在逐漸演進過程中，就完成了整個系統的架構更新。

10. 參考

微服務與SOA之間差了一個ESB(2) - 51CTO.COM.htm

面向服務與微服務架構 - 瞬息之間 - 博客頻道 - CSDN.NET.htm

微服務（Microservice）那點事 - 開源中國社區.htm

atititi.soa 微服務 區別 聯繫 優缺點.doc