從面向服務架構（SOA）學習：微服務時代應該借鑑的5條經驗教訓

【編者按】本文做者爲 Matt McLarty，經過介紹 SOA 的興衰變化，總結了微服務應該借鑑的5條經驗教訓。文章系國內 ITOM 管理平臺 OneAPM 編譯呈現。

SOA 的興衰變化讓咱們更瞭解如何充分利用微服務

正如筆者在上文《微服務架構是敏捷軟件架構》中提到的，筆者對微服務架構的第一反應，就是質疑它跟面向服務架構（SOA）有何區別。還有不少人將這兩種架構聯繫在一塊兒。詹姆斯·劉易斯和馬丁·福勒在他們的權威博客中包含了一個側邊欄，進行微服務和 SOA 的對比。對此，懷疑派作出的迴應是兩者之間並沒有不一樣。實際上，在「微服務」這個名詞出現以前，使用微服務的亞馬遜和 Netflix 都談到它們使用的是面向服務的架構。兩年多以後，關於微服務架構是否是 SOA 的爭辯帶來了大量的文章。

爲何人們這麼熱衷於對比微服務和 SOA，並且還投入這麼大的激情？雖然微服務和 SOA 在不少層面上能夠相互區分——架構風格、實施案例、相關技術——可是它們在技術發展全景中起到了一樣驚人的做用。它們都有望轉變整個格局，並且都成功吸引了一大批擁護者。簡單來講，微服務和 SOA 都以架構開始，可是最終都成了一場運動。

惋惜啊，如今 SOA 在 IT 業內基本上被視爲一場失敗的運動，而不少爲它投入時間、金錢和精力的人的傷痛依然清晰可見。這就是爲何你們有這麼大的熱情來對比較微服務和 SOA。要想了解微服務與 SOA 辯論的背景，回顧 SOA 運動的歷史很是重要：它的動力是什麼，以及最終致使失敗的緣由是什麼。

SOA 的興衰

1996年,高德納公司的分析員 Roy Schulte對面向服務架構作出了以下定義：

面向服務架構是一種多層信息處理技術，能幫助企業在多個應用和使用模式之間分享邏輯和數據。

雖然 SOA 很早就得到了這個定義，直到2002年，網絡服務出現以後，SOA 纔在行業內獲得普遍應用。儘管 SOAP/XML 的初衷是爲徹底不一樣的企業之間提供服務器到服務器的網絡溝通，它們很快就被企業架構師們選擇使用，他們一直在評估將網絡做爲新渠道、並操控新技術的方法。做爲一種鏈接應用、互聯網友好、預計能節省大量開支的方法，網絡服務在這些企業中迅速風靡。這種方法被貼上了「面向服務架構」的標籤，SOA 運動就此誕生。

隨着 SOA 運動的興起，一個新的集成模式出現了，用於推進 SOA 鬆散的鏈接原則：企業服務總線（ESB）。不少人如今已經忘了 ESB 模式旨在輕便、無處不在，這與當時通用的軸輻式企業應用集成（EAI）是大相徑庭的。實際上，ESB 概念自己就是爲了應對 EAI 代理的總體式特徵帶來的問題而生的，例如軟件交付變慢，過於依賴其餘團隊以及可管理性太差等。

最初的 ESB 部署版本是個恰當地集成協做服務節點的網絡，讓人聯想到微服務運動採用的「智能端點啞管道（smart endpoints and dumb pipes）」原則。然而，隨着 ESB 的理念獲得更加普遍的使用，它引起了一個新的含義。2002年高德納公司預言 ESB 模式將在2005年被絕大多數公司採用，軸輻式 EAI 中間件的代理商們得以說服不少業內人士，ESB 不是一種模式，而是用於企業軟件集成的一箇中間件產品。他們把 EAI 代理產品包裝成 EBS，消費者們還真的願意買帳。

正如高德納公司的預言，到了2005年，實施 EBS 成了必不可少的事。IT 公司成立了集中的交付部門來管理 EBS 基礎架構，而且參與公司各部門的集成項目。ESB 爲那些主張 SOA 的企業架構師提供了改造應用環境任務的立足點。他們利用這個立足點要實現兩個目的：控制和保持一致性。

SOA 項目領導爲控制需求辯護的理由是要確保那些支撐企業商業目標的服務的開發和使用。這就催生了 SOA 管理的分支運動，由此誕生了自有軟件產品類別。創建一致性的努力包括嘗試定義標準的企業數據模式，還有一套擴展的代理導向標準（整體的網絡服務），旨在減小網絡服務平臺之間的內部操做。技術模板、規範標準、集中的命令和控制文化，全部這些都讓本該輕量化的 EAI 替代者愈來愈沉重。SOA 迷失了發展方向。

SOA 的設計初衷是加速項目交付，提升 IT 敏捷性，減小集成成本。然而，SOA 使用者，也就是使用發展到如今的 SOA 的人們，發現它實際上帶來了更多複雜性和瓶頸，並且部署 SOA 基礎構架的費用（基於 ESB、註冊和服務平臺模板）過多。

到了2009年，人們再也不質疑 SOA 方法，而是直接棄用。RESTful Web API——一種鏈接網絡有機進化的應用的方式——做爲 SOAP 服務的輕量級備選出現了。雲架構的分佈式本質對集中的 ESB 拓撲安置是個挑戰。從公司層面和文化層面來講，敏捷運動在促進分散化和團隊自治。這些因素加起來，和其餘因素一塊兒讓 SOA 退出了主流。

SOA 經驗教訓

討論微服務和 SOA 是否相同是個錯誤的問題。那有什麼關係呢？正確的問題應該是問微服務運動可以從 SOA 借鑑什麼。出了什麼問題？如下是五條重要的經驗教訓。

1. 堅守目標。SOA 運動在偏離了最初的增長敏捷性和下降成本的目標以後，偏離了正途。實施者們過分關注 SOA 的技術，忽略了他們試圖解決的商業問題。2009年發佈的 SOA 宣言只是對主流 SOA 運動作出的迴應，而不是它的原則的具體體現。雖然業務排列是微服務運動宣稱的特徵，可是它也面臨偏離軌道的風險。已經有實例代表，技術專家總結說，若是他們把應用集裝箱化，就是在「實施微服務」了。爲了成功實施微服務，在考慮實際可用的技術以前，咱們必須專一於目標、但願實現的益處和原則。

2. 從成功開始。儘管 SOA 在全盛時期使用率之高曠古絕倫，可是並無什麼公共實例能夠證實它的承諾。很明顯，SOA 最開始是由一個行業分析員提出的純概念模型。與之相反，微服務架構是根據對無數企業的實際軟件開發的觀察提取出來的。亞馬遜和 Netflix 只是這種風格的兩個旗手。並且，微服務的範圍很是普遍，除了技術以外，還包括模型、原則、文化和企業特徵。這樣很健康，由於它推崇的不是一個理想化的模型，而是真實模型。隨着微服務實施的參考內容變動，模型也應該隨之進化。

3. 視角很重要。在 SOA 運動中，有不少例子代表，衝突的意願致使了它偏離正軌。技術管理人員搭建了集權式的帝國，而不是逐漸灌輸文化的變動。企業架構師堅持標準化，卻沒有清晰的目標。代理商們修改 ESB 的定義來適應他們的產品，而不是反過來。依然可惜 SOA 初始定義被遺棄的架構師，但願能再次從新定義產品的代理商，對 SOA 中間件付出大量投入的企業 IT 商店，這些手持斧頭反對 SOA 運動的人，對微服務心懷警戒也是能夠理解的。不過，不要由於反對 SOA 的證據就給微服務定罪。思想開明，傾聽全部聲音，可是要確保檢查確認來源。質疑每一個人的動機，包括你本身的。

4. 尋求和諧，而不是絕對。SOA 最初的目標是平衡的，例如加快產品上市速度，同時下降集成成本。基於集中制的根基，SOA 運動在實踐中摒棄了這兩個目標，轉而追求應用集成的控制和標準化。這是個極端而又失衡的定位。微服務運動的核心就是隨着規模擴大，改進軟件交付速度，提升系統安全性。這些是和諧的目標。然而，考慮到微服務及其敏捷根源的分散式遺產，也存在實施者偏離正軌，帶來過多團隊自治，於是犧牲安全性的風險。這在行業內已有前車可鑑。重要的是確保存在制衡力量來支撐目標，並堅持核心原則。

5. 模型和原則可以持續，技術卻不會。在微服務與 SOA 的爭辯中，有一點是達成共識的：微服務架構符合最初 SOA 對軟件系統分解爲分散耦合服務的願景。那就是一個模型。並且，最初的 SOA 原則諸如業務排列、依賴最小化和服務契約等，都與微服務的原則一致。兩者之間最大的不一樣在於技術。這具備兩面性。技術進化速度很是快。在很大程度上，技術運動均可以歸結到新技術帶來的原則。對於微服務運動來講，這意味着今天風頭正勁的技術明天可能就會過期。各類 Docker 都有得意的日子，可是微服務使用者應該擁抱模型和原則，而且作好技術被淘汰的準備。

微服務運動使人激動。在合成已被證實的原則和新技術、文化實踐方面，它的確還很新。它是不是 SOA 的成功版本、進化版本或者反面版本都可有可無。微服務會出現，留下印記，而後被下一個運動替代，接着是下下一個，永不停歇。目前，微服務運動的成員決定了它將會留下怎樣的印記。但願它能從 SOA 運動吸收經驗教訓，保持和諧狀態，從而幫助企業實現大規模的速度與安全的優化。

本文系 OneAPM 工程師編譯整理。OneAPM 能爲您提供端到端的 Java 應用性能解決方案，咱們支持全部常見的 Java 框架及應用服務器，助您快速發現系統瓶頸，定位異常根本緣由。分鐘級部署，即刻體驗，Java 監控歷來沒有如此簡單。想閱讀更多技術文章，請訪問 OneAPM 官方技術博客。

本文轉自 OneAPM 官方博客

原文地址：http://www.javaworld.com/article/3080611/application-development/learning-from-soa-5-lessons-for-the-microservices-era.html