微服務是否使SOA變得可有可無?

服務導向架構（簡稱SOA，service-oriented architecture）已經死亡?你可能會這麼想。

但其實否則。的確，隨着新技術的出現，SOA自己的價值可能已經大不如前，可是SOA的遺產仍在推進微服務市場發展。

將SOA原則歸入微服務的設計和構建是確保您的產品或服務長期處於有利地位的最佳方式。今後意義上講，理解SOA，對於在微服務世界中取得成功相當重要。

在本文中，我將解釋設計微服務應用程序時應採用哪些SOA原則。

介紹

現在，在移動終端開發環境中，代碼爲王，構建具備RESTful界面的服務變得史無前例的容易，將其鏈接到數據存儲就能夠了。若是你想要更進一步，就把幾個公共軟件服務（免費或付費）整合在一塊兒，這樣你就能夠擁有一個知足需求的持續交付流水線。歡迎來到現代Web和徹底buzzworthy兼容的應用程序開發過程。

在許多方面，微服務是SOA的直接產物，有點像服務世界的朋克搖滾。沒有嚴格的規則，只是一些基本原則讓全部人保持大致想法一致。就像朋克搖滾，微服務最初信奉的是一種按本身的節奏來的行業倫理。此後微服務一直在不斷髮展，一些架構方式開始讓微服務轉變爲主流。不光是使用微服務的dot com或Web公司——全部的公司都對此感興趣。

定義

爲體現本討論的目的，如下是我將要使用的定義。

• 微服務：特定業務功能的實現，使用隊列或RESTful（JSON）接口做爲單獨的可部署工件，能夠用任何語言編寫，並利用持續交付流水線。

• SOA：基於組件的架構，其目標是在組織內部跨技術組合促進重用。這些組件須要鬆耦合，能夠是集中管理的服務或庫，並要求組織使用單個技術棧來最大限度地實現可重用性。

基於微服務的開發的優勢

正如您所知，微服務具備SOA所缺少的幾個很好的特性：

• 容許規模較小、自給自足的團隊擁有支持特定業務功能的產品/服務，這大大提升了他們渴望的業務敏捷性和IT響應能力。

• 自動構建和測試，雖然可能不及SOA，如今是關鍵的籌碼。

• 容許團隊使用他們想要的工具，主要圍繞使用哪一種語言和IDE。

• 以敏捷爲基礎的開發與直接訪問業務。微服務和移動開發團隊已經成功地向企業展現了技術人員如何適應並接受不斷反饋的業務。以往，瀑布式軟件交付方法受制於沒必要要的開銷和交付日期延長的影響，隨着業務的變化，開發團隊一開始建立的產品，在交付時經常沒法知足業務需求。甚至像Rational Unified Process（RUP）這樣的迭代開發方法在業務、產品開發和開發人員進行實際工做之間都有抽象層。

• 對服務的最小粒度的廣泛瞭解。關於「添加客戶端業務功能仍是客戶端管理業務功能」的爭論一直存在，這並不完美，但至少二者均可以被實際運營業務的業務方所瞭解。你可能不肯相信，但技術並非全部業務（對於世界上大多數企業而言）。回溯到SOA仍是行業霸主時期，一些服務只執行一個數據庫操做，其餘服務則在系統中添加客戶端，當IT缺少一致的標準，就會致使業務的混亂。

SOA如何助力？

看完這些定義後，你可能會想：「微服務聽起來好得多」。的確，這正是將來發生演變的緣由，只是它拋棄了許多在SOA世界中得到的經驗教訓。它放棄了SOA嘗試實現的全部美好的事物，由於這一領域的IT供應商們爲了推出更多的產品，而改變了一切。

企業集成模式（定義企業如何採用新技術或概念）是微服務利用SOA世界所作的工做的關鍵所在。每一個參與整合空間的人均可以從這些模式中獲益，然而它們只是概念，微服務是實現這些概念的一種很好的技術方法。

下面，我列出了微服務生態系統中應用SOA原理得到巨大成功的另外兩個領域。

API網關（née ESB）

微服務鼓勵點對點鏈接，每一個客戶端均可以按本身的方式處理日期和其餘細微之處。因爲大多數公司提供的微服務的數量急劇增長，這種方式不可持續。

所以，在SOA環境中，企業服務總線（ESB）旨在爲不一樣應用程序提供通訊方式。SOA本來打算將ESB用於服務組件之間進行傳輸—而不是整個企業的中心。廠商推進，大公司購買，人們對這種模式的評價十分糟糕。

ESB中成功的產品已經轉變爲今天的API網關供應商，便於單一組織集中管理它們所呈現的端點，併爲那些多年來還沒有觸及但對業務相當重要的舊式服務 (一般是soa/soap) 提供轉換服務。

首要標準

SOA具備WS- *標準。此標準雖然嚴厲，但在很大程度上保證了互用性。這些標準，特別是像WS-Security和WS-Federation這類更常見的標準，容許企業調用在其合做夥伴系統中使用的服務——雖然它們只是一個清單，任何人都能理解。

微服務已經開始造成一套正式標準，也帶來了一票提供相應服務的供應商。OAuth和OpenID認證框架就是兩個很好的例子。隨着微服務的成熟，在內部構築一切是有趣、充實、且對自身有益的，但最終使人沮喪的是，隨着新特性的引入，它會產生大量的技術債務，代碼不斷地須要被修改。

標準正迅速整合的另外一面是API設計和描述。在SOA世界中，有一種方法。對人而言它既沒有美感，又幾乎不可讀，可是Web服務定義語言(WSDL)是一種通用的標準化的編目網絡服務的格式。

截至2017年4月，全部主要的參與者（包括谷歌、IBM、Microsoft、MuleSoft和Salesforce.com)都參與了提供構建RESTful api的工具，這些都是OpenAPI倡議的成員。曾經那個有多個標準（JSON API、WASL、RAML和Swagger）的破碎市場，如今變成了能夠用單一方式描述全部內容。

結論

SOA源於一組概念，它們與微服務架構具備相同的核心概念。SOA落後是由於是驅動了太多管理，而「僅僅讓它工做」是不夠的。

爲了使微服務繼續生存下去，利用這些服務的團隊不只須要汲取以往的寶貴經驗， 並使用敏捷開發的方法從新引入它們，此外還需採起適當的反治措施，防止SOA管理機制的重演。接下來還需把 ITIL安全地置於可以令其茁壯成長的運營團隊中。