什么是微服務(wù)

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

任何架構(gòu)的三個標(biāo)準(zhǔn)和最常見的業(yè)務(wù)驅(qū)動因素是：

• 提高敏捷性 - 及時響應(yīng)業(yè)務(wù)需求以便業(yè)務(wù)增長的能力
• 改善客戶體驗 - 改善客戶體驗，從而減少客戶流失
• 降低成本 - 降低添加更多產(chǎn)品，客戶或業(yè)務(wù)解決方案的成本

事實上，我們所有人都在努力在日常工作中這樣做。SOA創(chuàng)建了一個業(yè)務(wù)一致的軟件框架，使企業(yè)能夠?qū)崿F(xiàn)這一目標(biāo)。幾家大型軟件供應(yīng)商已經(jīng)出現(xiàn)并聲稱他們的產(chǎn)品套件可以使企業(yè)提供SOA。

如果您沒有合適的人員，文化和投資，SOA將無法實現(xiàn)業(yè)務(wù)價值。微服務(wù)架構(gòu)與SOA并沒有根本的不同，目標(biāo)和目標(biāo)是相同的，但是方法略有改進，事實上，我只是說微服務(wù)僅僅是SOA可擴展的。微服務(wù)使應(yīng)用程序/系統(tǒng)迫切需要從單一實現(xiàn)轉(zhuǎn)移到服務(wù)于許多應(yīng)用程序的分布式分散服務(wù)平臺。微服務(wù)是獨立的，它將敏捷性和應(yīng)用程序演變視為企業(yè)數(shù)字化轉(zhuǎn)換。微服務(wù)的成功取決于服務(wù)獨立性和服務(wù)靈活性。

我將微服務(wù)定義為“通過構(gòu)建細(xì)粒度服務(wù)以支持分布和組織為功能域的業(yè)務(wù)功能來提供SOA的方法”。沒有模式是魔術(shù)棒或銀彈。您應(yīng)該正確構(gòu)思和定制模式企業(yè)應(yīng)該專注于解決支持架構(gòu)所需的項目以構(gòu)建自適應(yīng)平臺。

一些企業(yè)的SOA實施失敗了 - 因為他們沒有完全分析他們的業(yè)務(wù)能力模型，并認(rèn)為開發(fā)Web服務(wù)意味著SOA或從大型供應(yīng)商購買SOA套件會使他們啟用SOA或無法顯示SOA及其業(yè)務(wù)驅(qū)動因素/目標(biāo)。

舉例

經(jīng)驗的一個例子可能會澄清這一點。在過去的一份工作中，該企業(yè)的目標(biāo)是提高敏捷性，客戶體驗并降低成本。我們決定構(gòu)建一個標(biāo)準(zhǔn)的多租戶SOA平臺。該方法旨在開發(fā)細(xì)粒度的服務(wù)，以便我們可以經(jīng)常進行更改，并為平臺部署小的，可管理的更改。如果我們今天采用相同的方法，我們可能會稱之為微服務(wù)架構(gòu)。那時我們沒有這個詞，但它才有意義。

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

當(dāng)需求逐漸增加（并且它們總是如此）時，由于應(yīng)用程序和消費者之間的集成復(fù)雜性，很難快速發(fā)布解決方案。集成，功能測試和生產(chǎn)發(fā)布需要緊密協(xié)調(diào)。隨著業(yè)務(wù)開始擴展，更改頻率比初始版本高出10倍，并且由于交付生命周期中的大多數(shù)任務(wù)都是手動的，因此上市時間不符合業(yè)務(wù)預(yù)期。很快，由于糟糕的微服務(wù)自動化和生命周期管理導(dǎo)致交付熵，我們的目標(biāo)都沒有實現(xiàn)。

經(jīng)驗教訓(xùn) - 不要做這些事情，而是......做其他事情

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

1）內(nèi)聚混亂（Cohesion Chaos）

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

預(yù)防性治療是為了管理與服務(wù)無關(guān)的業(yè)務(wù)功能。服務(wù)必須與業(yè)務(wù)能力明確對齊，不應(yīng)試圖在其邊界之外做某事。關(guān)注的功能分離對于架構(gòu)管理至關(guān)重要，否則會破壞敏捷性，性能和可伸縮性，最終建立緊密耦合的架構(gòu)，導(dǎo)致傳遞熵和內(nèi)聚混亂。

2）不認(rèn)真對待自動化

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

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

3）分層服務(wù)架構(gòu)

人們用SOA做出的一個常見錯誤是誤解了如何實現(xiàn)服務(wù)的可重用性。團隊主要關(guān)注技術(shù)凝聚力，而不是關(guān)于可重用性的功能。例如，若干服務(wù)用作數(shù)據(jù)訪問層（ORM）以將表公開為服務(wù);他們認(rèn)為這將是高度可重復(fù)使用的。這創(chuàng)建了由橫向團隊管理的人工物理層，這導(dǎo)致了交付依賴性。創(chuàng)建的任何服務(wù)都應(yīng)該是高度自治的 - 意味著彼此獨立。

創(chuàng)建多個技術(shù)，物理層的服務(wù)只會導(dǎo)致交付復(fù)雜性和運行時效率低下。我們最終擁有包裝服務(wù)，編排服務(wù)，業(yè)務(wù)服務(wù)和數(shù)據(jù)服務(wù)。這些服務(wù)模型提供了技術(shù)問題。各個團隊成立以管理這些層，最終導(dǎo)致業(yè)務(wù)邏輯蔓延，沒有單一的業(yè)主能力，失去效率，總是有一個責(zé)備游戲。

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

4）依靠消費者簽字

我們有來自三個不同渠道的多個應(yīng)用程序所消耗的服務(wù)，即代理，網(wǎng)絡(luò)和語音。代理渠道是我們的主要渠道，因此服務(wù)必須等待他們在投入生產(chǎn)之前簽字。它延遲了語音和Web應(yīng)用程序的生產(chǎn)版本。是什么將這三個通道緊緊地聯(lián)系在一起？

當(dāng)涉及通道特定功能時，該服務(wù)不是松散耦合的。為您的服務(wù)提供獨立性。您提供的每項服務(wù)都必須具有測試套件，該套件應(yīng)涵蓋所有當(dāng)前和未來消費者的所有服務(wù)功能，安全性，性能，錯誤處理和消費驅(qū)動測試。這必須作為自動回歸測試的構(gòu)建管道的一部分包含在內(nèi)。

5）手動配置管理

當(dāng)我們開始做大量服務(wù)（并且由于缺乏服務(wù)生命周期治理而導(dǎo)致的不可避免的蔓延表現(xiàn)）時，管理每個服務(wù)的配置失控。由于密碼錯誤，URL錯誤，值不正確等配置失敗，我們的大部分生產(chǎn)部署都不順利。手動管理這些變得越來越難。如果我們只使用應(yīng)用程序配置管理工具作為PaaS或CD的一部分......但我們沒有。

6）未使用版本控制

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

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

7）在每個服務(wù)中構(gòu)建網(wǎng)關(guān)

我們沒有API網(wǎng)關(guān)，我們沒有運行時治理（我們不知道誰在什么時間消耗什么以及以什么速度消費）。我們開始在每個服務(wù)中實現(xiàn)最終用戶身份驗證，限制，協(xié)調(diào)，轉(zhuǎn)換和路由等。它增加了每個服務(wù)的復(fù)雜性，并且我們失去了從服務(wù)到服務(wù)的實現(xiàn)的一致性，因此我們不知道誰實現(xiàn)了什么和哪里。最重要的是，我們的一些服務(wù)是為滿足一個消費者的非功能性需求而構(gòu)建的，而不是另一個。如果我們有一個網(wǎng)關(guān)，應(yīng)用一些數(shù)據(jù)過濾和豐富模式就可以做到。要是。

投資API管理解決方案，以集中，管理和監(jiān)控一些非功能性問題，并且還可以消除消費者管理多個微服務(wù)配置的負(fù)擔(dān)。可以使用API網(wǎng)關(guān)編排可以減少Web應(yīng)用程序往返的跨功能微服務(wù)。

結(jié)論

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