什么是微服務(wù)

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

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

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

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

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

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

一些企業(yè)的SOA實(shí)施失敗了 - 因?yàn)樗麄儧](méi)有完全分析他們的業(yè)務(wù)能力模型，并認(rèn)為開(kāi)發(fā)Web服務(wù)意味著SOA或從大型供應(yīng)商購(gòu)買SOA套件會(huì)使他們啟用SOA或無(wú)法顯示SOA及其業(yè)務(wù)驅(qū)動(dòng)因素/目標(biāo)。

舉例

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

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

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

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

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

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

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

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

2）不認(rèn)真對(duì)待自動(dòng)化

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

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

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

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

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

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

4）依靠消費(fèi)者簽字

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

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

5）手動(dòng)配置管理

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

6）未使用版本控制

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

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

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

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

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

結(jié)論

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