1.SOA

SOA = Service-Oriented Architecture，SOA 中文定義是面向服務架構。

SOA首先要關注的是如何根據業務劃分子系統，然後是子系統間如何協作，最後才是子系統內部實現。SOA設計可以很有效支援前面兩步，在SOA體系裡，每個子系統是獨立的服務，服務介面體現子系統協作關係，至於子系統內部，直接作為黑盒子處理。

所以對於複雜系統，首先採用SOA垂直切分子系統(業務劃分子系統)，然後使用分層設計水平切分單個子系統，服務化把傳統的分層設計往前更推進一步。

SOA是一種粗粒度、鬆耦合服務架構，服務之間通過簡單、精確定義介面進行通訊，不涉及底層程式設計介面和通訊模型。是整合多個較大元件（一般是應用

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

在 SOA 程式中，公開服務旨在公開每個業務功能，以便服務可得到儘可能多的重用。這樣，每個新專案就不需要經歷再次與後端系統執行整合的痛苦。典型的使用者是嘗試將全新的使用者介面放在舊記錄系統上的內部應用程式。在這樣做時，整合非常困難，而且會花費很大一部分的 IT 專案預算。如果可以通過可重用的介面公開公司的所有核心功能，就可以大大削減專案成本。SOA 旨在節省成本，而不是創造新收入。

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

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

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

特徵

• 面向服務（ Service-Oriented ）
• 鬆耦合（Loose-Coupling）
• 模組化（Modular）
• 分散式計算（Distributed Computing）
• 平臺無關性（Independent Platform）
• 集中管理（Center Government）

技術

• Web Services
  Web Services 技術演進的目的在於解決分散式計算中，統一異構系統的服務呼叫的通訊協議。前期的Web Services有XML-PRC、WSDL、SOAP等技術，不但解決了Windows平臺COM+以及Java 平臺RMI無法跨平臺的問題，而且使用了可讀性強的本文協議替代了複雜的二進位制協議，如CORBA技術。現代的WebServices 技術主要代表有REST等。
• Message Queue
  Message Queue 技術設計的目的主要有兩個方面，從架構上來說，訊息佇列服務幫助系統之間依賴關係解耦；從技術上來看，訊息佇列為系統提供非同步處理的能力，解決了併發同步呼叫導致資源消耗過集中和過快等問題，將上下游系統的資料結構提供了統一的傳輸介質。
• ESB
  ESB 則是 SOA 集大成實現。

2.微服務

微服務是一種架構設計模式。而架構則是“技”的實現與“術”的策略相輔相成。“術”的策略需要分析使用場景，進行合理地劃分業務邊界，實現“業以類聚”，然而“技”的實現則通過特定的技術在實現業務邏輯之時，更多的考慮實現過程中的效率性、測試的便利性、維護的可持續性，達到“技以群分”的目的。微服務是一種細粒度的SOA，細粒度更多的體現在“取其精華，去其糟粕”。在微服務架構中，業務邏輯被拆分成一系列小而鬆散耦合的分散式元件，共同構成了較大的應用。每個元件都被稱為微服務，而每個微服務都在整體架構中執行著單獨的任務，或負責單獨的功能。每個微服務可能會被一個或多個其他微服務呼叫，以執行較大應用需要完成的具體任務。

微服務與單體應用的區別

與微服務相對應的是單體式應用（即Monolithic Application）模式，

它將一個應用程式以一個業務需求視為一個整體，所有功能都放入一個應用程式中執行。企業應用系統架構通常可分為三層：前端表示層（即Web介面）、業務邏輯層、持久層，單體式應用模式通常將這三層封裝成單個的Web應用程式。比如，Web應用程式發展的早期，大部分Web工程是將所有的功能模組（service side）打包到一起並放在一個web容器中執行，很多企業的Java應用程式打包為war包，或者是分層結構，如表現層/應用層/領域層/資料層，這主要是水平切分的思想。其他語言（Ruby，Python或者C++）寫的程式也有類似的情況。

Monolithic比較適合小專案，優點是：

• 開發簡單直接，集中式管理
• 基本不會重複開發
• 功能都在本地，沒有分散式的管理開銷和呼叫開銷

它的缺點也非常明顯，特別對於網際網路公司來說（不一一列舉了）：

• 開發效率低：所有的開發在一個專案改程式碼，遞交程式碼相互等待，程式碼衝突不斷
• 程式碼維護難：程式碼功能耦合在一起，新人不知道何從下手
• 部署不靈活：構建時間長，任何小修改必須重新構建整個專案，這個過程往往很長
• 穩定性不高：一個微不足道的小問題，可以導致整個應用掛掉
• 擴充套件性不夠：無法滿足高併發情況下的業務需求

如下圖所示：傳統的web開發方式，所有的功能打包在一個WAR包裡，基本沒有外部依賴（除了容器），部署在一個JEE容器（Tomcat，JBoss，WebLogic）裡，包含了DO/DAO，Service，UI等所有邏輯。

而微服務架構則反其道而行之，藉由很多小型的服務，共同組合成完整的服務程式。微服務所設計的每個微服務都要非常容易被拋棄、被替換。擁抱不斷變化的業務，快讀迭代開發。微服務設計目標是降低系統複雜度，提高開發生產力，是適合敏捷方法快速建立持續改進的系統，例如網際網路應用。

微服務架構雲化方案一般融合Docker和DevOps技術，解決租戶隔離和統一開發平臺的需求。

例如以建設企業辦公樓為例，微服務藉助DevOps工具，使用服務化的建築預製件快速搭建需要的辦公樓（室），其中內含水電等都是獨立的。

微服務與SOA的區別

其實服務化架構（SOA）已經可以解決大部分企業的需求了，那麼我們為什麼要研究微服務呢？先說說它們的區別：

• 微服務架構強調業務系統需要徹底的元件化和服務化，一個元件就是一個產品，可以獨立對外提供服務
• 微服務不再強調傳統SOA架構裡面比較重的ESB企業服務匯流排
• 微服務強調每個微服務都有自己獨立的執行空間，包括資料庫資源
• 微服務架構本身來源於網際網路的思路，因此元件對外發布的服務強調了採用HTTP Rest API的方式來進行
• 微服務的切分粒度會更小，微服務是一種細粒度的SOA
• 微服務與SOA相比，更強調分散式系統的特性，比如橫向伸縮性，服務發現，負載均衡，故障轉移，高可用。網際網路開發對服務治理提出了更多的要求，比如多版本，比如灰度升級，比如服務降級，比如分散式跟蹤，這些都是在SOA實踐中重視不夠的。
• SOA將應用程式的功能公開為更容易訪問的服務介面，使得在下一代應用程式中使用它們的資料和邏輯變得更容易。SOA 似乎擁有 企業範圍，應用程式在該範圍內彼此通訊。SOA 通過應用程式之間的標準化介面來公開服務。微服務架構似乎擁有 應用程式範圍，僅關注一個應用程式內的結構和元件。

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

下面進一步解釋上表所述的不同之處：

• 開發方面 - 在這兩種體系結構中，可以使用不同的程式語言和工具開發服務，從而將技術多樣性帶入開發團隊。開發可以在多個團隊中組織，但是在SOA中，每個團隊都需要了解常見的通訊機制。另一方面，使用微服務，服務可以獨立於其他服務執行和部署。因此，頻繁部署新版本的微服務或獨立擴充套件服務會更容易。您可以在這裡進一步閱讀有關微服務的這些好處。

• “上下文邊界” - SOA鼓勵元件的共享，而微服務嘗試通過“上下文邊界”來最小化共享。上下文邊界是指以最小的依賴關係將元件及其資料耦合為單個單元。由於SOA依靠多個服務來完成業務請求，構建在SOA上的系統可能比微服務要慢。

• 通訊 - 在SOA中，ESB可能成為影響整個系統的單一故障點。由於每個服務都通過ESB進行通訊，如果其中一個服務變慢，可能會阻塞ESB並請求該服務。另一方面，微服務在容錯方面要好得多。例如，如果一個微服務存在記憶體錯誤，那麼只有該微服務會受到影響。所有其他微服務將繼續定期處理請求。

• 互操作性 - SOA通過訊息中介軟體元件促進了多種異構協議的使用。微服務試圖通過減少整合選擇的數量來簡化架構模式。因此，如果您想要在異構環境中使用不同協議來整合多個系統，則需要考慮SOA。如果您的所有服務都可以通過相同的遠端訪問協議訪問，那麼微服務對您來說是一個更好的選擇。

• 大小Size - 最後一點但並非最不重要的一點，SOA和微服務的主要區別在於規模和範圍。微服務架構中的字首“微”是指內部元件的粒度，意味著它們必須比SOA架構的服務往往要小得多。微服務中的服務元件通常有一個單一的目的，他們做得很好。另一方面，在SOA服務中通​​常包含更多的業務功能，並且通常將它們實現為完整的子系統。

例項對比——建立購物車

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

使用SOA的開發公司一般會將購物網站拆分成主要的業務邏輯組，並將每個部分作為獨立應用分別開發，最後整合到一起。

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

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

為什麼要微服務？

• 效率的需要
  應用進行微服務化後，規模和體積變得更加輕量級，在編譯、打包、分發、部署等環節節約了時間，開發上效率提升。
• 質量的需要
  微服務應用面向持續整合友好，自動化編譯、單元和整合測試用例執行和迴歸，提高應用整體質量。
• 穩定的需要
  當應用大而全時，往往牽一髮而動全身，其中一個服務出現問題，整體受到牽動效應。整體穩定性得不到保證，因此，經過微服務化後，應用由原來的服務內部組裝到服務自由組合，一旦關聯服務存在問題，整體應用可以選擇性地降級或熔斷等措施，待問題服務恢復，一切照常執行。
• 運維的需要
  微服務應用具備自動化編譯、打包、分發、部署和運維的能力。傳統的應用不但需要開發、還需要測試和運維人員，微服務應用實現後，將理想化的全棧（Full-Stack）工程師變為可能。
• 成長的需要
  微服務能夠更好，更快地適配新技術，比如目前流行的Apache Kafka。而工程人員需要接觸新的技術，為未來可能的技術選型做好準備。我的建議在一些不那麼重要的微服務應用中，可以嘗試一些新的技術，在其提供的功能與實際需要之間，找到一些自己的理解，也是自我成長的需要。
• 簡化開發的需要
  每個微服務的程式碼庫與相關工具集都很有限；開發者無需再去了解龐大而複雜的系統，只需理解自己所做的那部分微服務相關子集，便能貢獻生產力。由於無需考慮應用的現有部分使用了什麼語言或工具集，或者較大應用的其他開發者是否瞭解這些語言和工具，只需使用當前任務最趁手的工具，因此微服務開發起來非常迅速。

我個人理解，Microservice是SOA的傳承，但一個最本質的區別就在於Smart endpoints and dumb pipes，或者說是真正的分散式的、去中心化的。Smart endpoints and dumb pipes本質就是去ESB，把所有的“思考”邏輯包括路由、訊息解析等放在服務內部（Smart endpoints），去掉一個大一統的ESB，服務間輕（dumb pipes）通訊，是比SOA更徹底的拆分。

為什麼不必微服務？

• 場景單一
  當應用的場景單一時，沒有必要非得微服務，因為它本身就是微服務，例如一些靜態的通告頁面。
• 邏輯簡單
  當應用邏輯簡單時，同樣也違背了微服務的初衷，因為微服務是為了解決複雜業務邏輯而衍生，因此這種情況下也不必實施微服務。
• 業務漸逝
  首先，我解釋一下“漸逝”，也就是逐漸消逝的意思。當應用所關注的業務趨於消逝狀態時，儘管有實施的空間，但無實施的必要。因為這樣的應用隨時可能不復存在，好比沒有必要去對BB機或者簡訊業務大張旗鼓的重構一般。
• “老成持重”
  老成持重的原意是形容人做事情老練和沉穩。這裡我引用了這個成語，是為了方便記憶，需要將其拆開，單獨解釋。
  “老”是指年老的應用，多久算得上年老呢？個人經驗，應用服役年齡超過三年以上。
  “成”則表示應用的規模已成形，業務上幾乎不再變化，比如通知應用。
  “持”說明應用的場景還將持續較長時間。
  “重”表示應用所處的位置舉足輕重，不能隨時重構，比如交易應用。
  當應用符合其中一條以上的特徵時，該應用不必實行微服務。
• 技術盲從
  微服務並不適合每個應用程式。目前微服務社群中的一種悖論是，讓新的、相對簡單的、具有高度凝聚性資料模型的應用程式採用微服務的概念，這樣做不會獲得任何優勢。另外，將一個複雜的現有應用程式重構到微服務架構中是一項繁重的工作。如果不是在舊版或新式應用程式上，您會何時使用微服務？一種 建議是，在以傳統方式編寫的應用程式達到複雜性的拐點之前，不要使用微服務。但是，要讓此方法發揮作用，則需要從一開始就編寫一個適當構建的應用程式，並選擇在正確的時刻執行過渡。
  這一點是我最為關注，也是最擔心朋友觸犯的。我們同為工程人員，對技術的追求毋容置疑，可是千萬不能因為技術而技術，新的技術推出或是解決現有問題，或是提供便利性，可是也有誇大其詞的成分。理性地評估和謹慎地實施，更是我們更要關注的地方。技術困難挑戰聰明才智，理智對待則考驗情緒控制。

客戶端如何訪問這些服務？

原來的Monolithic方式開發，所有的服務都是本地的，UI可以直接呼叫，現在按功能拆分成獨立的服務，跑在獨立的一般都在獨立的虛擬機器上的Java程序了。客戶端UI如何訪問他的？後臺有N個服務，前臺就需要記住管理N個服務，一個服務下線/更新/升級，前臺就要重新部署，這明顯不服務我們拆分的理念，特別當前臺是移動應用的時候，通常業務變化的節奏更快。另外，N個小服務的呼叫也是一個不小的網路開銷。還有一般微服務在系統內部，通常是無狀態的，使用者登入資訊和許可權管理最好有一個統一的地方維護管理（OAuth）。

所以，一般在後臺N個服務和UI之間一般會一個代理或者叫API Gateway，他的作用包括

提供統一服務入口，讓微服務對前臺透明
聚合後臺的服務，節省流量，提升效能
提供安全，過濾，流控等API管理功能
我的理解其實這個API Gateway可以有很多廣義的實現辦法，可以是一個軟硬一體的盒子，也可以是一個簡單的MVC框架，甚至是一個Node.js的服務端。他們最重要的作用是為前臺（通常是移動應用）提供後臺服務的聚合，提供一個統一的服務出口，解除他們之間的耦合，不過API Gateway也有可能成為單點故障點或者效能的瓶頸。

一般用過Taobao Open Platform的就能很容易的體會，TAO就是這個API Gateway。

服務之間如何通訊？

因為所有的微服務都是獨立的Java程序跑在獨立的虛擬機器上，所以服務間的通訊就是IPC（inter process communication），已經有很多成熟的方案。現在基本最通用的有兩種方式。這幾種方式，展開來講都可以寫本書，而且大家一般都比較熟悉細節了，就不展開講了。

• 同步呼叫
  
  • REST（JAX-RS）
  • RPC（Dubbo）
• 非同步訊息呼叫(Kafka, Notify, MetaQ)
  

一般同步呼叫比較簡單，一致性強，但是容易出調用問題，效能體驗上也會差些，特別是呼叫層次多的時候。RESTful和RPC的比較也是一個很有意思的話題。一般REST基於HTTP，更容易實現，更容易被接受，服務端實現技術也更靈活些，各個語言都能支援，同時能跨客戶端，對客戶端沒有特殊的要求，只要封裝了HTTP的SDK就能呼叫，所以相對使用的廣一些。RPC也有自己的優點，傳輸協議更高效，安全更可控，特別在一個公司內部，如果有統一的開發規範和統一的服務框架時，他的開發效率優勢更明顯些。就看各自的技術積累實際條件，自己的選擇了。

而非同步訊息的方式在分散式系統中有特別廣泛的應用，他既能減低呼叫服務之間的耦合，又能成為呼叫之間的緩衝，確保訊息積壓不會沖垮被呼叫方，同時能保證呼叫方的服務體驗，繼續幹自己該乾的活，不至於被後臺效能拖慢。不過需要付出的代價是一致性的減弱，需要接受資料最終一致性；還有就是後臺服務一般要實現冪等性，因為訊息傳送出於效能的考慮一般會有重複（保證訊息的被收到且僅收到一次對效能是很大的考驗）；最後就是必須引入一個獨立的broker，如果公司內部沒有技術積累，對broker分散式管理也是一個很大的挑戰。

如何實踐

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

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

這麼多服務，怎麼找?

在微服務架構中，一般每一個服務都是有多個拷貝，來做負載均衡。一個服務隨時可能下線，也可能應對臨時訪問壓力增加新的服務節點。服務之間如何相互感知？服務如何管理？這就是服務發現的問題了。一般有兩類做法，也各有優缺點。基本都是通過zookeeper等類似技術做服務註冊資訊的分散式管理。當服務上線時，服務提供者將自己的服務資訊註冊到ZK（或類似框架），並通過心跳維持長連結，實時更新連結資訊。服務呼叫者通過ZK定址，根據可定製演算法，找到一個服務，還可以將服務資訊快取在本地以提高效能。當服務下線時，ZK會發通知給服務客戶端。

• 客戶端做：優點是架構簡單，擴充套件靈活，只對服務註冊器依賴。缺點是客戶端要維護所有呼叫服務的地址，有技術難度，一般大公司都有成熟的內部框架支援，比如Dubbo。
• 服務端做：優點是簡單，所有服務對於前臺呼叫方透明，一般在小公司在雲服務上部署的應用採用的比較多。
  

這麼多服務，服務掛了怎麼辦？

前面提到，Monolithic方式開發一個很大的風險是，把所有雞蛋放在一個籃子裡，一榮俱榮，一損俱損。而分散式最大的特性就是網路是不可靠的。通過微服務拆分能降低這個風險，不過如果沒有特別的保障，結局肯定是噩夢。我們剛遇到一個線上故障就是一個很不起眼的SQL計數功能，在訪問量上升時，導致資料庫load彪高，影響了所在應用的效能，從而影響所有呼叫這個應用服務的前臺應用。所以當我們的系統是由一系列的服務呼叫鏈組成的時候，我們必須確保任一環節出問題都不至於影響整體鏈路。相應的手段有很多：

• 重試機制
• 限流
• 熔斷機制
• 負載均衡
• 降級（本地快取）

微服務的困境

微服務的優點和缺點（或者說挑戰）一樣明顯。

• 優點

  • 開發簡單
  • 技術棧靈活
  • 服務獨立無依賴
  • 獨立按需擴充套件
  • 可用性高

• 缺點（挑戰）

  • 多服務運維難度
  • 系統部署依賴
  • 服務間通訊成本
  • 資料一致性
  • 系統整合測試
  • 重複工作
  • 效能監控

由大量微型服務組合而成的微服務應用，其特徵是每一個微服務都是獨立執行，且每個服務能夠各自擴充套件，甚至可以用不同的程式語言來開發同一個業務所需的各個微服務。微服務架構雖然具備彈性、可擴充套件性的優點，但它也帶來了管理大量服務的複雜性，特別是微型服務的數量極多的情況更為明顯。要構建分散式微服務架構的應用，往往只有大型網際網路公司才有能力完成。

這裡有一個圖非常好的總結微服務架構需要考慮的問題，包括

• API Gateway
• 服務間呼叫
• 服務發現
• 服務容錯
• 服務部署
• 資料呼叫

微服務的新生

隨著容器技術的成熟，過去實現難度很高的微服務架構，開始“飛入尋常百姓家”。容器技術可以將各種微型程式打包成可獨立執行的映像，釋出到任何可用的容器平臺上執行。開發者只要將業務應用所需的所有功能程式打包成一個個的Docker映像，部署到各個容器中就能實現提供不同功能的微服務。這樣開發者就可以通過同樣的工具和技術來管理大量的微服務，而不用自己維護微服務架構技術。