什么是微服務

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

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

• 提高敏捷性 - 及時響應業(yè)務需求以便業(yè)務增長的能力

• 改善客戶體驗 - 改善客戶體驗，從而減少客戶流失

• 降低成本 - 降低添加更多產(chǎn)品，客戶或業(yè)務解決方案的成本

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

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

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

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

舉例

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

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

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

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

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

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

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

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

2）不認真對待自動化

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

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

3）分層服務架構

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

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

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

4）依靠消費者簽字

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

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

5）手動配置管理

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

6）未使用版本控制

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

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

7）在每個服務中構建網(wǎng)關

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

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

結論

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

本文 :https://architect.pub/micro-service-architecture-seven-micro-service-anti-patterns
討論：知識星球【首席架構師圈】或者加微信小號【ca_cto】或者加QQ群【792862318】
公眾號 ?	【jiagoushipro】 【架構師酒館】 精彩圖文詳解架構方法論，架構實踐，技術原理，技術趨勢。 我們在等你，趕快掃描關注吧。
微信小號 ?	【ca_cea】 50000人社區(qū)，討論：企業(yè)架構，云計算，大數(shù)據(jù)，數(shù)據(jù)科學，物聯(lián)網(wǎng)，人工智能，安全，全棧開發(fā)，DevOps，數(shù)字化. ?
知識星球	【首席架構師圈】向大咖提問，近距離接觸，或者獲得私密資料分享。	?
喜馬拉雅	【超級架構師】路上或者車上了解最新黑科技資訊，架構心得。	【智能時刻，架構君和你聊黑科技】
微博	【架構師酒館】	智能時刻
網(wǎng)站	CIO(首席信息官)	https://cio.ceo
網(wǎng)站	CIO,CTO和CDO	https://cioctocdo.com
網(wǎng)站	架構師實戰(zhàn)分享	https://architect.pub? ?
網(wǎng)站	程序員云開發(fā)分享	https://pgmr.cloud
官網(wǎng)	行天智能科技咨詢公司	https://xingtian.ai
網(wǎng)站	開發(fā)者閑談	https://developer.chat
網(wǎng)站	首席隱私官內(nèi)參	https://cpo.work
網(wǎng)站	首席安全官內(nèi)參	https://cso.pub????
網(wǎng)站	CIO內(nèi)參	https://cio.cool
網(wǎng)站	CDO內(nèi)參	https://cdo.fyi
網(wǎng)站	CXO內(nèi)參	https://cxo.pub
網(wǎng)站	首席架構師社區(qū)	https://jiagoushi.pro

謝謝大家關注，轉發(fā)，點贊和點在看。