關於微服務是什麼，面向服務的體系結構（SOA）又是什麼，兩者之間有何關聯真是衆說紛紜、困惑頗多。很多人都加入了這場討論，從ThoughtWorks的Martin Fowler到Cap Gemini的Steve Jones全都參與了進來。
微服務是什麼？
微服務是一種架構設計模式。在微服務架構中，業務邏輯被拆分成一系列小而鬆散耦合的分佈式組件，共同構成了較大的應用。每個組件都被稱爲微服務，而每個微服務都在整體架構中執行着單獨的任務，或負責單獨的功能。每個微服務可能會被一個或多個其他微服務調用，以執行較大應用需要完成的具體任務；系統還爲任務執行——比如搜索或顯示圖片任務，或者其他可能需要多次執行的任務提供了統一的解決處理方式，並限制應用內不同地方生成或維護相同功能的多個版本。
使用微服務架構還提供這樣一種機制：增加新加入開發者的生產效率，並減少新功能的推廣時長。每個微服務的代碼庫與相關工具集都很有限；開發者無需再去了解龐大而複雜的系統，只需理解自己所做的那部分微服務相關子集，便能貢獻生產力。由於無需考慮應用的現有部分使用了什麼語言或工具集，或者較大應用的其他開發者是否瞭解這些語言和工具，只需使用當前任務最趁手的工具，因此微服務開發起來非常迅速。
爲了充分利用速度優勢，讓小團隊開發成爲可能，團隊需要自主權；他們必須能迅速作出決定，避免過度監管。要想支持這一點，工作團隊應當包括所有相關人員，從產品經理到發佈運行人員。由於微服務組件是鬆散耦合並通過API通訊的，各方在大多決定時擁有高度自主權並不會影響應用的整體功能。只要微服務能發佈API，並能用這些API執行所需的功能，整體系統就能運作良好。
由於在一個微服務架構中有許多獨立的組件，在彈性網絡（比如公共或私有云）上使用現代化的DevOps對於確保整體系統在大多數情況下正常運轉就顯得尤爲重要。特別是像與額外實例的自動部署相關聯的健康與負載自動監控（爲了儘可能減少未充分利用的實例）這樣的東西在很多情況下就變得至關重要。
SOA是什麼？
服務導向式架構（SOA）是集成多個較大組件（一般是應用）的一種機制，它們將整體構成一個彼此協作的套件。一般來說，每個組件會從始至終執行一塊完整的業務邏輯，通常包括完成整體大action所需的各種具體任務與功能。組件一般都是鬆耦合的，但這並非SOA架構模式的要求。
儘管沒有嚴格要求，SOA一般使用某種集中式管理，比如審查委員會、主架構師或架構委員會來嚴格定義每個系統組件應當做什麼，如何執行。相同類型的功能可能會按需在多個組件中分別定義與記錄，而每個組件所使用的語言與工具集有可能是集中確定與統一的，也可能不是。SOA可能使用任何類型的SDLC、組織架構或符合這種管理的開發模型；敏捷、瀑布、看板管理或者一些組合形式都是可用而不違反SOA原則的。
此外，現代化的DevOps和雲部署對SOA當然很有效，在這種系統中縮減組件數量並非必需。但在這些系統中，就算在最好的情況下，一些較大的組件也可能太過複雜而難以實現自動化，在最壞的情況下甚至完全無法實現。
舉個例子，自動化部署的一個標準可能得需要100%通過一套自動化測試。這將確保現有的功能在新版本中仍舊可用（沒有迴歸），而新功能也按照預期實現。隨着功能交互越來越多，看似不相關的開發工作意外破壞現有功能某些方面的可能性有所增加。
此外一些測試可能很敏感，由於壞境或網絡因素而出現失敗個例。在100個測試案例中，5%的隨機測試出現1%的失敗率不會對普通發佈造成大的阻礙。而在成千上萬的測試中，同樣的機率可能會造成較大影響，很多時候會造成至少一個隨機故障。因此，即便要發佈的版本沒有什麼實際的錯誤，也會因爲無法通過這條標準而無法部署。
直接對比——建立購物車
我們來看一個在線購物網站。這個網站會有一些不同的功能，比如產品目錄、用戶帳號還有購物車等等。
使用SOA的開發公司一般會將購物網站拆分成主要的業務邏輯組，並將每個部分作爲獨立應用分別開發，最後集成到一起。
舉個例子，整個購物車及其所有功能是由一大羣人所開發的一個應用，他們需要了解整個購物車的工作機制，以便能夠修改。在這個應用中，是代碼負責顯示物品、增加或移除購物車商品、查看庫存、處理運費選項、處理稅率計算、處理匯率、在更改時更新顯示並將最終的訂單細節發到用戶郵箱裏（還有其他等等）。用來顯示購物車商品的代碼包括在購物車應用中，可能與在瀏覽目錄視圖中用來顯示商品名稱的代碼截然不同，從而造成需要維護的兩套代碼相似但不相同，還可能造成大應用UX上的某些不一致。
使用微服務架構的開發公司會將購物車切分成較小的任務導向服務。不再是購物車應用了，而可能是稅率計算服務、添加/移除商品服務、運費服務、匯率服務和最終訂單撰寫服務。購物車功能可能也會用到一些常用的服務——它們會用在購物應用的很多地方，比如顯示商品服務、顯示產品圖片服務、查看庫存服務、用戶支付偏好服務以及郵件服務。而“購物車”、“產品目錄、“用戶賬戶”之間並沒有分界，通用代碼被封裝成各種服務，待需要時用在各種功能中。
當公司向中心授權組織請求展示產品時，必須修改展示來源，還得將瀏覽統計添加到購物應用中。在SOA架構中，產品目錄應用和購物車應用必須獨立各自更新，以體現變更。
需要對兩個應用進行重測試，以確保變更沒有影響其他功能，然後再重新部署。如果在這兩個有改動的應用中還有其他功能有所變更，這一過程可能會進一步拖延（取決於開發進度的實現情況），而無法發佈。一旦重新部署，負責展示的新機制速度可能明顯要比舊機制慢，從而成爲瓶頸。
延遲會導致客戶投訴，然後問題被報告給管理層。有管理者決定要通過向整個產品目錄應用與購物車應用部署額外實例，以處理額外的負載，應對延遲問題（如果有適當的監控與部署規則，這可能是自動執行的）。由於整個應用需要擴展，整個過程需要大量的額外處理能力與存儲空間，在未執行額外部署的情況下，很多功能可能只能勉強運行。
而在微服務這裏，只需進行一項改變——更新產品展示服務。這項服務可以獨立進行快速的更改、測試與部署，而不會影響到大系統中的其他部分。此外，一旦發現瓶頸（很可能是通過自動化監控），無需向產品目錄功能或者購物車服務所使用的其他服務部署更多實例，就能（可能是自動的）部署這項服務的額外實例，從而限制了支持額外部署所需的資源。
以上所有都是建立在想要發佈一個大型在線商店，向各地各類人等售賣各類產品的假設上。如果假設你只想向美國境內的客戶販賣一種商品，並且只使用UPS作爲物流的話。大量架構與複雜的在線商店都是沒有必要的。
雖然仍需追蹤用戶信息、提供購物車與結算功能、展示產品信息與圖片，甚至一些評論評價，但每一項功能所需都比複雜的在線商店要少得多。產品分類需求、計算不同運費選項的需求、系統處理增加/移除延時差異的需求還有所有其他綜合商城所需的功能都不再需要。
在這種情況下，使用SOA將購物車、用戶賬戶與產品展示組件與網站相集成可能要比使用微服務架構（像上面描述的那樣有更爲細緻的組件定義）更有意義。在這種簡單的設置中，不僅每個較大的組件被降低到複雜程度可控的範圍內，而且實現這類網站所需的開發與其他員工的人數都會很少，無需將小型獨立團隊進行拓展。
相似卻不相同
微服務與SOA有很多相同之處。兩者都屬於典型的、包含鬆耦合分佈式組件的系統結構。但是兩種架構背後的意圖是不同的：SOA嘗試將應用集成，一般採用中央管理模式來確保各應用能夠交互運作。微服務嘗試部署新功能，快速有效地擴展開發團隊。它着重於分散管理、代碼再利用與自動化執行。
總結：
| 功能 | SOA | 微服務 |
|---|---|---|
| 組件大小 | 大塊業務邏輯 | 單獨任務或小塊業務邏輯 |
| 耦合 | 通常鬆耦合 | 總是鬆耦合 |
| 公司架構 | 任何類型 | 小型、專注於功能交叉的團隊 |
| 管理 | 着重中央管理 | 着重分散管理 |
| 目標 | 確保應用能夠交互操作 | 執行新功能，快速拓展開發團隊 |
哪種適合你的公司呢？完全取決於你的選擇。
原文鏈接: Microservices Versus SOA in Practice
譯文轉自：http://geek.csdn.net/news/detail/51826
深入閱讀：淺析深究什麼是SOA？