「微服務架構」七種微服務反模式

什麼是微服務

流行語經常爲進化的概念提供背景，並且需要一個良好的 “標籤” 來促進對話。微服務是一個新的“標籤”，它定義了我個人一直在發現和使用的領域。文章和會議描述了一些事情，我慢慢意識到，過去幾年我一直在發展自己的個人經歷。雖然有關微服務的行業和專業討論已經成爲 Netflix，亞馬遜和谷歌等公司以及成功完成這項工作的從業者的焦點，但我有一些個人經驗可以爲成功的微服務實施提供見解。

任何架構的三個標準和最常見的業務驅動因素是：

事實上，我們所有人都在努力在日常工作中這樣做。SOA 創建了一個業務一致的軟件框架，使企業能夠實現這一目標。幾家大型軟件供應商已經出現並聲稱他們的產品套件可以使企業提供 SOA。

如果您沒有合適的人員，文化和投資，SOA 將無法實現業務價值。微服務架構與 SOA 並沒有根本的不同，目標和目標是相同的，但是方法略有改進，事實上，我只是說微服務僅僅是 SOA 可擴展的。微服務使應用程序 / 系統迫切需要從單一實現轉移到服務於許多應用程序的分佈式分散服務平臺。微服務是獨立的，它將敏捷性和應用程序演變視爲企業數字化轉換。微服務的成功取決於服務獨立性和服務靈活性。

我將微服務定義爲 “通過構建細粒度服務以支持分佈和組織爲功能域的業務功能來提供 SOA 的方法”。沒有模式是魔術棒或銀彈。您應該正確構思和定製模式企業應該專注於解決支持架構所需的項目以構建自適應平臺。

一些企業的 SOA 實施失敗了 - 因爲他們沒有完全分析他們的業務能力模型，並認爲開發 Web 服務意味着 SOA 或從大型供應商購買 SOA 套件會使他們啓用 SOA 或無法顯示 SOA 及其業務驅動因素 / 目標。

舉例

經驗的一個例子可能會澄清這一點。在過去的一份工作中，該企業的目標是提高敏捷性，客戶體驗並降低成本。我們決定構建一個標準的多租戶 SOA 平臺。該方法旨在開發細粒度的服務，以便我們可以經常進行更改，併爲平臺部署小的，可管理的更改。如果我們今天採用相同的方法，我們可能會稱之爲微服務架構。那時我們沒有這個詞，但它纔有意義。

服務是基於業務能力模型建模的，第一個版本進展順利。它們是基於 JMS 同步服務的 XML，主要側重於提供向代理，Web 和語音通道應用程序公開的聲明平臺所需的功能。它使我們能夠爲我們的應用程序無縫部署頻繁，小的更改和 A / B 功能支持。

當需求逐漸增加（並且它們總是如此）時，由於應用程序和消費者之間的集成複雜性，很難快速發佈解決方案。集成，功能測試和生產發佈需要緊密協調。隨着業務開始擴展，更改頻率比初始版本高出 10 倍，並且由於交付生命週期中的大多數任務都是手動的，因此上市時間不符合業務預期。很快，由於糟糕的微服務自動化和生命週期管理導致交付熵，我們的目標都沒有實現。

經驗教訓 - 不要做這些事情，而是...... 做其他事情

這讓我分享了我在旅途中學到的一些課程，以便您在使用微服務上路時能夠密切關注這些項目

1）內聚混亂（Cohesion Chaos）

我們開發了一項服務，以獲取客戶信息，旨在提取客戶政策信息，個人信息和他們註冊的計劃。一段時間以來，它開始做的不僅僅是獲取客戶信息。隨着新要求的出現，該服務經歷了頻繁的更改和部署。它無法擴展並滿足所需的可用性。它成了衆所周知的 “泥球大球”。它是怎麼到達那裏的？對於初學者來說，沒有關於功能性關注分離的治理。如果一個有影響力的消費者要求在這一項服務中加入不相關的邏輯來減少往返行程，那麼這個功能就毫無疑問地被打了。也許網關或 BPM 層本可以避免這種情況，但是沒有時間...... 只是時間來制定另一個業務功能點。

預防性治療是爲了管理與服務無關的業務功能。服務必須與業務能力明確對齊，不應試圖在其邊界之外做某事。關注的功能分離對於架構管理至關重要，否則會破壞敏捷性，性能和可伸縮性，最終建立緊密耦合的架構，導致傳遞熵和內聚混亂。

2）不認真對待自動化

我們沒有自動部署策略和 ops 服務監控（運行時 QoS 指標）。它顯然增加了部署期間的運營費用和手動錯誤。多次生產部署導致配置錯誤導致中斷。這些服務始終以 HA 模式部署，因此容器數量是服務總數的 3 倍。操作團隊無法手動處理每項服務的配置。經過一段時間後，操作人員開始抱怨架構效率低下，因爲他們無法處理增加的容器數量。

這是什麼疫苗？配方有多種成分。如果您還沒有這樣做，持續部署是每個企業都應該追求的必須投資和文化變革。至少，如果你沒有辦法自動測試和部署 - 不要做微服務。微服務的目標是以我們需要改變的速度來提高敏捷性; 質量保證涉及每項服務都具有自動化單元，功能，安全性和性能測試。當我們開發與我們無法控制的服務集成的服務時，服務虛擬化是另一個強大的概念。

3）分層服務架構

人們用 SOA 做出的一個常見錯誤是誤解了如何實現服務的可重用性。團隊主要關注技術凝聚力，而不是關於可重用性的功能。例如，若干服務用作數據訪問層（ORM）以將表公開爲服務; 他們認爲這將是高度可重複使用的。這創建了由橫向團隊管理的人工物理層，這導致了交付依賴性。創建的任何服務都應該是高度自治的 - 意味着彼此獨立。

創建多個技術，物理層的服務只會導致交付複雜性和運行時效率低下。我們最終擁有包裝服務，編排服務，業務服務和數據服務。這些服務模型提供了技術問題。各個團隊成立以管理這些層，最終導致業務邏輯蔓延，沒有單一的業主能力，失去效率，總是有一個責備遊戲。

服務中的層的邏輯分離很好，但是，不應該有任何進程外調用。嘗試將服務視爲一個原子業務實體，它必須實現一切以實現所需的業務功能。自包含服務比分層服務更具自主性和可擴展性。在多個服務中重寫一些常用代碼是完美的，這很好，並且保持自治級別是一個很好的權衡。最重要的是，沒有技術問題分開的服務，而是必須根據業務能力將它們分開。由於這種特性，集裝箱化的概念正在蓬勃發展。

4）依靠消費者簽字

我們有來自三個不同渠道的多個應用程序所消耗的服務，即代理，網絡和語音。代理渠道是我們的主要渠道，因此服務必須等待他們在投入生產之前簽字。它延遲了語音和 Web 應用程序的生產版本。是什麼將這三個通道緊緊地聯繫在一起？

當涉及通道特定功能時，該服務不是鬆散耦合的。爲您的服務提供獨立性。您提供的每項服務都必須具有測試套件，該套件應涵蓋所有當前和未來消費者的所有服務功能，安全性，性能，錯誤處理和消費驅動測試。這必須作爲自動迴歸測試的構建管道的一部分包含在內。

5）手動配置管理

當我們開始做大量服務（並且由於缺乏服務生命週期治理而導致的不可避免的蔓延表現）時，管理每個服務的配置失控。由於密碼錯誤，URL 錯誤，值不正確等配置失敗，我們的大部分生產部署都不順利。手動管理這些變得越來越難。如果我們只使用應用程序配置管理工具作爲 PaaS 或 CD 的一部分...... 但我們沒有。

6）未使用版本控制

天真地，我們認爲只需要一個版本的服務。然後我們開始添加主要的次要版本以適應多個消費者和頻繁的變化。最終，每個版本都必須是主要版本，因爲服務依賴於消費者簽名。結果，容器的數量增加得非常快，並且管理它們變得非常痛苦。缺乏運行時治理是導致此問題的另一個方面。有些企業愚蠢地試圖避免版本控制。假設變更是不可避免的，需要對服務進行架構。制定策略來管理向前兼容的服務更改，並讓您的消費者優雅地升級。否則，它將導致消費者緊密綁定到服務版本並在發生更改時中斷。

隨着微服務世界所期望的服務數量的增長，複雜性也在增長。有一個版本控制策略，可以讓消費者進行優雅的遷移，並確保提供商可以透明地部署更改，而不會影響任何人。限制生產中並排主要版本的數量並管理它們。

7）在每個服務中構建網關

我們沒有 API 網關，我們沒有運行時治理（我們不知道誰在什麼時間消耗什麼以及以什麼速度消費）。我們開始在每個服務中實現最終用戶身份驗證，限制，協調，轉換和路由等。它增加了每個服務的複雜性，並且我們失去了從服務到服務的實現的一致性，因此我們不知道誰實現了什麼和哪裏。最重要的是，我們的一些服務是爲滿足一個消費者的非功能性需求而構建的，而不是另一個。如果我們有一個網關，應用一些數據過濾和豐富模式就可以做到。要是。

投資 API 管理解決方案，以集中，管理和監控一些非功能性問題，並且還可以消除消費者管理多個微服務配置的負擔。可以使用 API 網關編排可以減少 Web 應用程序往返的跨功能微服務。

結論

微服務的目標是解決三個最常見的問題，即改善客戶體驗，高度敏捷地滿足新要求，並通過將業務功能作爲細粒度服務來降低成本。這不是一個靈丹妙藥，需要一個規範的平臺，以高質量的敏捷方式提供服務。從其他錯誤中學習（我的）並避免在架構和交付過程中列出的上述模式。這是我們談論集裝箱化，雲採用等之前的第一步。我希望本文能爲您的企業提供一些思考，並在將這些反模式編織到您的架構之前解決這些反模式。大多數項目將推動組織內部的文化變革，不能僅靠自己完成，確保與您的高管和高級領導者建立夥伴關係。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/uVCZPFNFT3jeMmxJdLAxZQ

猜你喜歡