什么是微服務

流行語經常為進化的概念提供背景，并且需要一個良好的“標簽”來促進對話。微服務是一個新的“標簽”，它定義了我個人一直在發現和使用的領域。文章和會議描述了一些事情，我慢慢意識到，過去幾年我一直在發展自己的個人經歷。雖然有關微服務的行業和專業討論已經成為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管理解決方案，以集中，管理和監控一些非功能性問題，并且還可以消除消費者管理多個微服務配置的負擔?？梢允褂肁PI網關編排可以減少Web應用程序往返的跨功能微服務。

結論

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