微服務與SOA的實踐應用對比

微服務是一種架構設計模式。在微服務架構中，業務邏輯被拆分成一系列小而松散耦合的分布式元件，共同構成了較大的應用。每個元件都被稱為微服務，而每個微服務都在整體架構中執行着單獨的任務，或負責單獨的功能。每個微服務可能會被一個或多個其他微服務調用，以執行較大應用需要完成的具體任務；系統還為任務執行——比如搜尋或顯示圖檔任務，或者其他可能需要多次執行的任務提供了統一的解決處理方式，并限制應用内不同地方生成或維護相同功能的多個版本。

使用微服務架構還提供這樣一種機制：增加新加入開發者的生産效率，并減少新功能的推廣時長。每個微服務的代碼庫與相關工具集都很有限；開發者無需再去了解龐大而複雜的系統，隻需了解自己所做的那部分微服務相關子集，便能貢獻生産力。由于無需考慮應用的現有部分使用了什麼語言或工具集，或者較大應用的其他開發者是否了解這些語言和工具，隻需使用目前任務最趁手的工具，是以微服務開發起來非常迅速。

為了充分利用速度優勢，讓小團隊開發成為可能，團隊需要自主權；他們必須能迅速作出決定，避免過度監管。要想支援這一點，工作團隊應當包括所有相關人員，從産品經理到釋出運作人員。由于微服務元件是松散耦合并通過API通訊的，各方在大多決定時擁有高度自主權并不會影響應用的整體功能。隻要微服務能釋出API，并能用這些API執行所需的功能，整體系統就能運作良好。

由于在一個微服務架構中有許多獨立的元件，在彈性網絡（比如公共或私有雲）上使用現代化的DevOps對于確定整體系統在大多數情況下正常運轉就顯得尤為重要。特别是像與額外執行個體的自動部署相關聯的健康與負載自動監控（為了盡可能減少未充分利用的執行個體）這樣的東西在很多情況下就變得至關重要。

服務導向式架構（SOA）是內建多個較大元件（一般是應用）的一種機制，它們将整體構成一個彼此協作的套件。一般來說，每個元件會從始至終執行一塊完整的業務邏輯，通常包括完成整體大action所需的各種具體任務與功能。元件一般都是松耦合的，但這并非SOA架構模式的要求。

盡管沒有嚴格要求，SOA一般使用某種集中式管理，比如審查委員會、主架構師或架構委員會來嚴格定義每個系統元件應當做什麼，如何執行。相同類型的功能可能會按需在多個元件中分别定義與記錄，而每個元件所使用的語言與工具集有可能是集中确定與統一的，也可能不是。SOA可能使用任何類型的SDLC、組織架構或符合這種管理的開發模型；靈活、瀑布、看闆管理或者一些組合形式都是可用而不違反SOA原則的。

此外，現代化的DevOps和雲部署對SOA當然很有效，在這種系統中縮減元件數量并非必需。但在這些系統中，就算在最好的情況下，一些較大的元件也可能太過複雜而難以實作自動化，在最壞的情況下甚至完全無法實作。

舉個例子，自動化部署的一個标準可能得需要100%通過一套自動化測試。這将確定現有的功能在新版本中仍舊可用（沒有回歸），而新功能也按照預期實作。随着功能互動越來越多，看似不相關的開發工作意外破壞現有功能某些方面的可能性有所增加。

此外一些測試可能很敏感，由于壞境或網絡因素而出現失敗個例。在100個測試案例中，5%的随機測試出現1%的失敗率不會對普通釋出造成大的阻礙。而在成千上萬的測試中，同樣的幾率可能會造成較大影響，很多時候會造成至少一個随機故障。是以，即便要釋出的版本沒有什麼實際的錯誤，也會因為無法通過這條标準而無法部署。

我們來看一個線上購物網站。這個網站會有一些不同的功能，比如産品目錄、使用者帳号還有購物車等等。

使用SOA的開發公司一般會将購物網站拆分成主要的業務邏輯組，并将每個部分作為獨立應用分别開發，最後內建到一起。

舉個例子，整個購物車及其所有功能是由一大群人所開發的一個應用，他們需要了解整個購物車的工作機制，以便能夠修改。在這個應用中，是代碼負責顯示物品、增加或移除購物車商品、檢視庫存、處理運費選項、處理稅率計算、處理匯率、在更改時更新顯示并将最終的訂單細節發到使用者郵箱裡（還有其他等等）。用來顯示購物車商品的代碼包括在購物車應用中，可能與在浏覽目錄視圖中用來顯示商品名稱的代碼截然不同，進而造成需要維護的兩套代碼相似但不相同，還可能造成大應用UX上的某些不一緻。

使用微服務架構的開發公司會将購物車切分成較小的任務導向服務。不再是購物車應用了，而可能是稅率計算服務、添加/移除商品服務、運費服務、匯率服務和最終訂單撰寫服務。購物車功能可能也會用到一些常用的服務——它們會用在購物應用的很多地方，比如顯示商品服務、顯示産品圖檔服務、檢視庫存服務、使用者支付偏好服務以及郵件服務。而“購物車”、“産品目錄、“使用者賬戶”之間并沒有分界，通用代碼被封裝成各種服務，待需要時用在各種功能中。

當公司向中心授權組織請求展示産品時，必須修改展示來源，還得将浏覽統計添加到購物應用中。在SOA架構中，産品目錄應用和購物車應用必須獨立各自更新，以展現變更。

需要對兩個應用進行重測試，以確定變更沒有影響其他功能，然後再重新部署。如果在這兩個有改動的應用中還有其他功能有所變更，這一過程可能會進一步拖延（取決于開發進度的實作情況），而無法釋出。一旦重新部署，負責展示的新機制速度可能明顯要比舊機制慢，進而成為瓶頸。

延遲會導緻客戶投訴，然後問題被報告給管理層。有管理者決定要通過向整個産品目錄應用與購物車應用部署額外執行個體，以處理額外的負載，應對延遲問題（如果有适當的監控與部署規則，這可能是自動執行的）。由于整個應用需要擴充，整個過程需要大量的額外處理能力與存儲空間，在未執行額外部署的情況下，很多功能可能隻能勉強運作。

而在微服務這裡，隻需進行一項改變——更新産品展示服務。這項服務可以獨立進行快速的更改、測試與部署，而不會影響到大系統中的其他部分。此外，一旦發現瓶頸（很可能是通過自動化監控），無需向産品目錄功能或者購物車服務所使用的其他服務部署更多執行個體，就能（可能是自動的）部署這項服務的額外執行個體，進而限制了支援額外部署所需的資源。

以上所有都是建立在想要釋出一個大型線上商店，向各地各類人等售賣各類産品的假設上。如果假設你隻想向美國境内的客戶販賣一種商品，并且隻使用UPS作為物流的話。大量架構與複雜的線上商店都是沒有必要的。

雖然仍需追蹤使用者資訊、提供購物車與結算功能、展示産品資訊與圖檔，甚至一些評論評價，但每一項功能所需都比複雜的線上商店要少得多。産品分類需求、計算不同運費選項的需求、系統處理增加/移除延時差異的需求還有所有其他綜合商城所需的功能都不再需要。

在這種情況下，使用SOA将購物車、使用者賬戶與産品展示元件與網站相內建可能要比使用微服務架構（像上面描述的那樣有更為細緻的元件定義）更有意義。在這種簡單的設定中，不僅每個較大的元件被降低到複雜程度可控的範圍内，而且實作這類網站所需的開發與其他員工的人數都會很少，無需将小型獨立團隊進行拓展。

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

總結：

功能

SOA

微服務

元件大小

大塊業務邏輯

單獨任務或小塊業務邏輯

耦合

通常松耦合

總是松耦合

公司架構

任何類型

小型、專注于功能交叉的團隊

管理

着重中央管理

着重分散管理

目标

確定應用能夠互動操作

執行新功能，快速拓展開發團隊

哪種适合你的公司呢？完全取決于你的選擇。

<a href="http://geek.csdn.net/news/detail/51826" target="_blank"></a>

本文轉自UltraSQL51CTO部落格，原文連結：http://blog.51cto.com/ultrasql/1910480 ，如需轉載請自行聯系原作者