微服務是否使SOA變得無關緊要?

科技小能手發表於2017-11-12
微服務

服務導向架構（簡稱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安全地置於能夠令其茁壯成長的運營團隊中。

本文轉自 RancherLabs 51CTO部落格，原文連結:http://blog.51cto.com/12462495/1926180


相關文章