微服務(wù)是一種優(yōu)化資源的體系結(jié)構(gòu)方法，這些資源為復(fù)雜、快速、分布式基礎(chǔ)設(shè)施上的大規(guī)模服務(wù)和軟件提供計(jì)算、存儲(chǔ)和網(wǎng)絡(luò)。大多數(shù)有IT歷史的組織，傳統(tǒng)上都是在虛擬技術(shù)棧上構(gòu)建軟件，這些技術(shù)棧由操作團(tuán)隊(duì)手動(dòng)維護(hù)。今天，開(kāi)發(fā)人員大規(guī)模使用云服務(wù)來(lái)構(gòu)建應(yīng)用程序架構(gòu)和自動(dòng)化工作負(fù)載。面向機(jī)器架構(gòu)的時(shí)代正在過(guò)去——面向應(yīng)用程序的基礎(chǔ)設(shè)施正在流行。今天，這些資源提供了全堆棧的、開(kāi)發(fā)人員構(gòu)建應(yīng)用程序體系結(jié)構(gòu)所需的內(nèi)容。開(kāi)發(fā)團(tuán)隊(duì)需要為應(yīng)用程序架構(gòu)更全面地開(kāi)放資源，這證明了DevOps工具在功能強(qiáng)大的分布式架構(gòu)上運(yùn)行的深層需求。
對(duì)技術(shù)工具、服務(wù)和平臺(tái)的需求包含在構(gòu)成微服務(wù)的內(nèi)容。無(wú)限的計(jì)算、網(wǎng)絡(luò)和存儲(chǔ)資源的平衡，為運(yùn)行任意數(shù)量的服務(wù)提供了機(jī)會(huì)和障礙。就像任何一種過(guò)度興奮的、吸引技術(shù)社區(qū)注意的新方法一樣，在圍繞微服務(wù)的炒作中，往往沒(méi)有提及復(fù)雜性。從表面上看，開(kāi)發(fā)、部署和管理軟件的完美方法可能要比最初出現(xiàn)的方法復(fù)雜得多。因此這是一個(gè)讓公司深入了解業(yè)務(wù)目標(biāo)、團(tuán)隊(duì)開(kāi)發(fā)、工作流和用于構(gòu)建應(yīng)用程序架構(gòu)的服務(wù)的旅程。通常，對(duì)于那些技術(shù)背景與微服務(wù)的現(xiàn)代方法不匹配的人來(lái)說(shuō)，做出改變并不容易。微服務(wù)要求組織重新考慮運(yùn)行其業(yè)務(wù)的現(xiàn)有軟件體系結(jié)構(gòu)，以及組織如何適應(yīng)需要新的技術(shù)技能和文化轉(zhuǎn)變來(lái)匹配的實(shí)踐。這種實(shí)踐有風(fēng)險(xiǎn)，并不是每個(gè)人都能做到。
盡管如此，大約90%的開(kāi)發(fā)人員至少都在為一些工作負(fù)載考慮微服務(wù)架構(gòu)。然而，當(dāng)被更具體地問(wèn)及它們?cè)谏a(chǎn)應(yīng)用程序中的使用時(shí)，這個(gè)數(shù)字下降了。然而，與任何快速發(fā)展的新興技術(shù)一樣，要想理清所有的炒作，就要理解微服務(wù)如何實(shí)際應(yīng)用于日常工作。這有助于從微服務(wù)的實(shí)際基礎(chǔ)開(kāi)始，然后權(quán)衡軟件體系結(jié)構(gòu)本身的好處和缺點(diǎn)。
微服務(wù)的定義
微服務(wù)是一種基于將應(yīng)用程序構(gòu)建為小型服務(wù)集合的軟件開(kāi)發(fā)體系結(jié)構(gòu)方法。對(duì)于構(gòu)成“小型服務(wù)”的代碼量并沒(méi)有標(biāo)準(zhǔn)定義。一些專家說(shuō)，這與查詢服務(wù)運(yùn)行狀況時(shí)的“大小”有關(guān)。如果一個(gè)服務(wù)需要多個(gè)team來(lái)管理，那么它就太大了。每個(gè)服務(wù)都有自己獨(dú)特且定義明確的角色，在自己的流程中運(yùn)行，并通過(guò)HTTP應(yīng)用程序編程接口(API)或消息傳遞進(jìn)行通信。每個(gè)微服務(wù)都可以獨(dú)立于應(yīng)用程序中的所有兄弟服務(wù)進(jìn)行部署、升級(jí)、擴(kuò)展和重新啟動(dòng)。它們通常由自動(dòng)化系統(tǒng)編排，使實(shí)時(shí)應(yīng)用程序的頻繁更新成為可能，而不會(huì)影響最終用戶。
個(gè)人可能更習(xí)慣使用應(yīng)用程序的概念。但如今，一般的企業(yè)組織至少使用十幾種不同的軟件產(chǎn)品和集成。記錄業(yè)務(wù)開(kāi)銷(xiāo)、進(jìn)度跟蹤和工資管理等，是組織現(xiàn)在使用運(yùn)行在云服務(wù)上應(yīng)用程序的幾個(gè)例子。使用緊湊而專業(yè)的工具以提供優(yōu)雅用戶體驗(yàn)的方式完成每項(xiàng)工作是有意義的，類(lèi)似于個(gè)人應(yīng)用程序在社交網(wǎng)絡(luò)上發(fā)布照片、視頻和與他人聯(lián)系時(shí)所獲得的體驗(yàn)。微服務(wù)使用包含云服務(wù)的分布式體系結(jié)構(gòu)，以一種松耦合的模式組合在一起來(lái)進(jìn)行擴(kuò)展。就像樂(lè)高積木一樣，微服務(wù)中的組件可以在適當(dāng)?shù)奈恢脴?gòu)建一個(gè)統(tǒng)一的模型。
(微服務(wù)是小型、獨(dú)立擴(kuò)展和管理的服務(wù)。每個(gè)服務(wù)有其自己獨(dú)特和良好定義的角色，運(yùn)行自己的流程和通過(guò)HTTP API以或Messaging進(jìn)行溝通)
首先，開(kāi)發(fā)人員確定構(gòu)建項(xiàng)目所需的獨(dú)立服務(wù)“部分”，例如搜索、身份驗(yàn)證、消息傳遞和銷(xiāo)售處理。然后，從服務(wù)、庫(kù)和可用代碼片段、從開(kāi)源到交鑰匙企業(yè)解決方案的大雜燴中進(jìn)行選擇，并將所有內(nèi)容整合到一個(gè)功能應(yīng)用程序中。
云原生浪潮
云原生微服務(wù)的概念源于容器體系結(jié)構(gòu)的發(fā)展。
在基于容器的體系結(jié)構(gòu)之前，開(kāi)發(fā)人員需要構(gòu)建技術(shù)堆棧，然后將其部署到云服務(wù)或健壯的企業(yè)體系結(jié)構(gòu)上。這些應(yīng)用程序是面向機(jī)器的，并使用監(jiān)控軟件及其在云服務(wù)和企業(yè)上的性能的一系列工具進(jìn)行優(yōu)化。這是超越面向服務(wù)架構(gòu)(SOA)的一步，盡管有些人認(rèn)為SOA只是由供應(yīng)商重新命名以銷(xiāo)售相關(guān)產(chǎn)品的微服務(wù)，這是有一定道理的。
微服務(wù)可以被認(rèn)為是SOA的一種類(lèi)型。容器只是使方法更加廣泛可用，并降低了SOA帶來(lái)的風(fēng)險(xiǎn)程度。在虛擬機(jī)(VM)上運(yùn)行的SOA需要時(shí)間和投資來(lái)構(gòu)建、部署和運(yùn)行。VM運(yùn)行在操作系統(tǒng)上，而操作系統(tǒng)也必須進(jìn)行移植才能在SOA環(huán)境中運(yùn)行。這是一項(xiàng)繁重的手工工作，并且?guī)缀鯖](méi)有為尋找實(shí)際運(yùn)行SOA本身的好的方式而承擔(dān)風(fēng)險(xiǎn)的空間。
由Docker領(lǐng)頭，容器改變了游戲規(guī)則。Docker代表了SOA的發(fā)展和平臺(tái)即服務(wù)(PaaS)的時(shí)代。Docker通過(guò)其簡(jiǎn)單、易用和低風(fēng)險(xiǎn)推動(dòng)了采用率。它將Linux容器技術(shù)打包成開(kāi)發(fā)人員可以訪問(wèn)和使用的內(nèi)容。構(gòu)建、運(yùn)行和管理容器技術(shù)只需很少的開(kāi)銷(xiāo)——這與重量級(jí)的SOA世界形成了鮮明的對(duì)比，后者需要大量的投入，尤其是在網(wǎng)絡(luò)和存儲(chǔ)方面。
容器現(xiàn)在充當(dāng)微服務(wù)的底層基礎(chǔ)，通過(guò)API網(wǎng)關(guān)和gRPC等新方法連接。總體而言，容器使SOA可以通過(guò)簡(jiǎn)單地使技術(shù)更易于使用而大規(guī)模實(shí)施，所涉及的風(fēng)險(xiǎn)遠(yuǎn)遠(yuǎn)低于以往。微服務(wù)與DevOps、持續(xù)集成和持續(xù)交付(CI / CD)，以及容器的使用密切相關(guān)。事實(shí)上，“微服務(wù)”和“容器”這兩個(gè)術(shù)語(yǔ)經(jīng)常一起使用。但是，容器和微服務(wù)并不是一回事。微服務(wù)可以在容器內(nèi)運(yùn)行，但它也可以作為完全配置的虛擬機(jī)運(yùn)行。也就是說(shuō)，基于容器和開(kāi)源的平臺(tái)，如Docker和Kubernetes，是開(kāi)發(fā)、部署和管理微服務(wù)的一種非常有效的方法。容器空間中已經(jīng)存在許多成熟且健壯的工具、平臺(tái)和其他服務(wù)，這使得容器化非常適合基于微服務(wù)的應(yīng)用程序。
雖然容器和微服務(wù)獨(dú)立存在并且用于不同的目的，但它們經(jīng)常一起使用;它們甚至還被視為DevOps的好拍檔。容器是微服務(wù)的一種使能技術(shù)，這也是微服務(wù)通常在一個(gè)或多個(gè)容器中交付的原因。由于容器是隔離環(huán)境，因此無(wú)論用于創(chuàng)建每個(gè)微服務(wù)的編碼語(yǔ)言如何，它們都可用于快速安全地部署微服務(wù)。一旦基于微服務(wù)的應(yīng)用程序達(dá)到顯著的規(guī)模，在沒(méi)有容器的情況下幾乎不可能管理它。運(yùn)行在集群編排平臺(tái)(如Kubernetes或Mesos)之上的容器化微服務(wù)，包括在云中、本地或混合模式，是當(dāng)前對(duì)向外擴(kuò)展的云原生應(yīng)用程序的定義。
重要的是要注意雖然容器是將代碼打包到微服務(wù)中的“嚴(yán)格”方式，但也可以將整個(gè)單體應(yīng)用程序打包到容器中，而不需要?jiǎng)?chuàng)建微服務(wù)。隨著云計(jì)算的進(jìn)一步發(fā)展，以及更多組織從傳統(tǒng)基礎(chǔ)架構(gòu)中解放出來(lái)和/或開(kāi)始評(píng)估無(wú)服務(wù)器架構(gòu)的用例，打包可以而且很可能會(huì)發(fā)生變化。事實(shí)上，許多微服務(wù)的支持者表示，它們只是多云和無(wú)服務(wù)器計(jì)算的跳板，這是一種利用資源自動(dòng)化功能和填補(bǔ)應(yīng)用程序架構(gòu)空白的新興方法。
有行業(yè)專家認(rèn)為，將微服務(wù)和容器結(jié)合起來(lái)只是一個(gè)實(shí)施細(xì)節(jié)，而不是一個(gè)重要的抽象概念，除非在VM上有很多需要遷移到同一技術(shù)堆棧的傳統(tǒng)應(yīng)用程序。
微服務(wù)的好處
通過(guò)使小型自治團(tuán)隊(duì)能夠獨(dú)立開(kāi)發(fā)，部署和擴(kuò)展各自的服務(wù)，微服務(wù)基本上可以并行化開(kāi)發(fā) ——從而以指數(shù)方式加速生產(chǎn)周期。這種敏捷性是大型企業(yè)在多種報(bào)告中指出采用微服務(wù)所引用的首要原因，其次是改進(jìn)的可擴(kuò)展性。
微服務(wù)可以讓開(kāi)發(fā)人員不必浪費(fèi)時(shí)間重新解決已經(jīng)解決的技術(shù)問(wèn)題。持續(xù)集成和部署基本上構(gòu)建在微服務(wù)架構(gòu)中。微服務(wù)可以直接把很多基礎(chǔ)設(shè)施風(fēng)險(xiǎn)帶出項(xiàng)目。隨著基礎(chǔ)設(shè)施變得幾乎不可見(jiàn)，微服務(wù)團(tuán)隊(duì)可以進(jìn)行通常以小時(shí)周期運(yùn)行的快速迭代，從而持續(xù)降低錯(cuò)誤功能的風(fēng)險(xiǎn)，同時(shí)增加價(jià)值。
換句話說(shuō)，使用微服務(wù)，團(tuán)隊(duì)中的每個(gè)開(kāi)發(fā)人員都可以忘記底層基礎(chǔ)設(shè)施，專注于自己的項(xiàng)目。然后在生產(chǎn)中，如果單個(gè)項(xiàng)目模塊不能完全正確地工作在一起，那么很容易對(duì)它們進(jìn)行隔離、拆卸和重新配置，直到正確地工作為止。這些組件是松耦合的，就像樂(lè)高一樣。這種方式提供了使用可互換的部件在應(yīng)用程序體系結(jié)構(gòu)中大規(guī)模運(yùn)行的能力。它們的獨(dú)立和獨(dú)立結(jié)構(gòu)也帶來(lái)了安全性優(yōu)勢(shì)，因?yàn)楦菀淄ㄟ^(guò)自動(dòng)化和實(shí)施安全策略的現(xiàn)代安全平臺(tái)進(jìn)行控制。
隨著組織的發(fā)展，工程團(tuán)隊(duì)可以更輕松地?cái)U(kuò)展和維持速度。微服務(wù)架構(gòu)的主要好處不是技術(shù)，而在于團(tuán)隊(duì)開(kāi)發(fā)和人員管理。相比之下，當(dāng)代碼庫(kù)增長(zhǎng)到一定規(guī)模時(shí)，單體應(yīng)用程序變得無(wú)法適應(yīng)和管理。管理這種規(guī)模的應(yīng)用程序架構(gòu)的團(tuán)隊(duì)絕不能讓單體架構(gòu)失效。如果整體架構(gòu)失效了，那么業(yè)務(wù)也會(huì)隨之流失。因此編寫(xiě)腳本以防止應(yīng)用程序泄漏并在主要版本升級(jí)之間構(gòu)建各種補(bǔ)丁成為企業(yè)架構(gòu)師的重要優(yōu)先事項(xiàng)。功能是預(yù)先定義好的，并按照優(yōu)先級(jí)與整體相適應(yīng);客戶則被夾在中間，并且做出的強(qiáng)制性決策可能是短期的解決方法，但會(huì)帶來(lái)較長(zhǎng)期的問(wèn)題，例如定制化的腳本隨著時(shí)間推移而失效，并且依賴于具有企業(yè)基礎(chǔ)架構(gòu)記憶的人員。這本身是一個(gè)糟糕的體驗(yàn)，因?yàn)樾碌能浖?jí)可能無(wú)法解決客戶遇到的問(wèn)題。
一個(gè)主要問(wèn)題是(單體)應(yīng)用程序會(huì)變得極其復(fù)雜。它太大了，任何單個(gè)開(kāi)發(fā)人員都無(wú)法完全理解。因此修復(fù)bug和正確實(shí)現(xiàn)新特性將變得困難且費(fèi)時(shí)。更重要的是，這是一個(gè)惡性循環(huán)。如果代碼庫(kù)難以理解，那么將無(wú)法正確進(jìn)行更改。許多組織已經(jīng)達(dá)到了這樣一個(gè)階段，即管理單體應(yīng)用整體結(jié)構(gòu)的痛苦超過(guò)了采用新的微服務(wù)方法。微服務(wù)的采用是這類(lèi)組織的優(yōu)秀選擇，盡管它也有自己的挑戰(zhàn)。
微服務(wù)的缺點(diǎn)
微服務(wù)是經(jīng)典單體應(yīng)用的對(duì)立面，具有明顯的優(yōu)勢(shì)。但是，與任何正在發(fā)展的技術(shù)一樣，早期采用曲線可能很陡峭。目前，Netflix和PayPal等大公司最有效地采用了這種方法，由于強(qiáng)大的內(nèi)部資源和工程團(tuán)隊(duì)，這些公司已經(jīng)能夠轉(zhuǎn)向微服務(wù)架構(gòu)。
Netlify首席執(zhí)行官兼聯(lián)合創(chuàng)始人Mathias Biilmann表示:“當(dāng)你擁有一個(gè)非常龐大、資源豐富的企業(yè)，個(gè)人團(tuán)隊(duì)能夠管理每項(xiàng)服務(wù)并確?？芍赜眯院涂商剿餍詴r(shí)，這是非常棒的。”然而，對(duì)于其他人來(lái)說(shuō)，痛苦是真實(shí)存在的。根據(jù)有關(guān)報(bào)告，只有1%的企業(yè)使用微服務(wù)表示他們對(duì)架構(gòu)沒(méi)有任何挑戰(zhàn)。操作開(kāi)銷(xiāo)、日志記錄和監(jiān)視方面的挑戰(zhàn)以及缺乏技能被列為最主要的挑戰(zhàn)。離開(kāi)單一的應(yīng)用程序體系結(jié)構(gòu)意味著失去將所有部分粘合在一起的固定工作流。最常見(jiàn)的情況是，因?yàn)镮T團(tuán)隊(duì)主要負(fù)責(zé)集成和維護(hù)許多不同服務(wù)的基礎(chǔ)設(shè)施，采用微服務(wù)體系結(jié)構(gòu)會(huì)增加操作成本。團(tuán)隊(duì)必須在微服務(wù)遠(yuǎn)景與實(shí)際需要之間艱難地找到平衡，才能使其發(fā)揮作用并取得成功。
當(dāng)將整體分解為微服務(wù)時(shí)，將冒著一個(gè)非常分散的系統(tǒng)風(fēng)險(xiǎn)，開(kāi)發(fā)人員需要花費(fèi)大量的時(shí)間和精力將服務(wù)和工具粘合在一起，并且缺乏可以跨項(xiàng)目工作的常見(jiàn)模式和平臺(tái) 。為了真正利用微服務(wù)，需要能夠構(gòu)建可以實(shí)現(xiàn)一鍵設(shè)置的“膠水”供應(yīng)商。”
(遷移到微服務(wù)，通常為帶來(lái)了大量運(yùn)維挑戰(zhàn)，因?yàn)榧珊途S護(hù)很多不同服務(wù)的基礎(chǔ)設(shè)施責(zé)任落在了IT團(tuán)隊(duì))
LAMP堆棧的出現(xiàn)可以作為一個(gè)很好的對(duì)比。Linux、Apache web服務(wù)器、MySQL和 PHP等免費(fèi)工具為web開(kāi)發(fā)開(kāi)辟了新的可能性。但當(dāng)公司圍繞WordPress、Drupal和Joomla等項(xiàng)目構(gòu)建集成工具時(shí)，LAMP體系結(jié)構(gòu)才真正起飛。
在真正的微服務(wù)方法中，團(tuán)隊(duì)只運(yùn)行他們需要的小服務(wù)，而不運(yùn)行其它任何負(fù)載。但是，這種實(shí)施和編配工作已經(jīng)超出了許多中小型組織的工程范圍。將一個(gè)整體分割成許多更小的、獨(dú)立的服務(wù)在速度和敏捷性方面有許多優(yōu)勢(shì)，但也有許多挑戰(zhàn)。微服務(wù)架構(gòu)可以增加支持和維護(hù)的運(yùn)營(yíng)開(kāi)銷(xiāo)，因?yàn)槊總€(gè)服務(wù)都有自己的語(yǔ)言和要求。這也使得監(jiān)控和安全性變得更加復(fù)雜，因此需要更高水平的自動(dòng)化和工具。而且由于服務(wù)之間的通信現(xiàn)在通過(guò)網(wǎng)絡(luò)進(jìn)行，因此它會(huì)對(duì)服務(wù)發(fā)現(xiàn)、消息傳遞、緩存和容錯(cuò)產(chǎn)生新的要求，這些要求可能會(huì)給系統(tǒng)帶來(lái)壓力，如果處理不當(dāng)可能會(huì)導(dǎo)致性能問(wèn)題。雖然Service Mesh解決了許多這樣的問(wèn)題，但是引入一個(gè)沒(méi)有流量管理的Service Mesh服務(wù)，它自己就會(huì)產(chǎn)生一些問(wèn)題，這些問(wèn)題可能會(huì)導(dǎo)致更嚴(yán)重的性能問(wèn)題。
可以提前做所有想做的測(cè)試，并且這會(huì)對(duì)要發(fā)布的代碼相當(dāng)有信心。但是當(dāng)真正把它投入生產(chǎn)時(shí)，就會(huì)遇到各種各樣的問(wèn)題，因?yàn)閷?shí)際上并不知道代碼在生產(chǎn)中會(huì)如何表現(xiàn)。流量管理實(shí)際上是將部署與發(fā)布解耦。部署是指擁有新代碼、新版本并將其投入生產(chǎn)，但還不占用任何客戶流量?？梢宰鰺熿F測(cè)試、內(nèi)部測(cè)試，這些測(cè)試都在生產(chǎn)中運(yùn)行。當(dāng)發(fā)布一個(gè)版本時(shí)，就會(huì)開(kāi)始思考：要給這個(gè)新版本的代碼帶來(lái)什么樣的流量?如果有能力把流量控制到非常精細(xì)的水平的話，可以分割、控制、并逐步推出新的代碼更改。
沒(méi)有工程資源或技能將穩(wěn)定的基礎(chǔ)架構(gòu)與現(xiàn)有的開(kāi)源代碼和工具結(jié)合在一起的組織，很難 讓微服務(wù)的好處大于挑戰(zhàn)。操作和性能問(wèn)題也可能困擾那些沒(méi)有就其服務(wù)(依賴關(guān)系和版本兼容性)進(jìn)行溝通的團(tuán)隊(duì)，并且必須在生產(chǎn)失敗時(shí)撤回已經(jīng)寫(xiě)入的代碼。幸運(yùn)的是，微服務(wù)市場(chǎng)正在起飛。許多公司現(xiàn)在不僅生產(chǎn)微服務(wù)本身，還生產(chǎn)無(wú)縫連接它們所需的平臺(tái)、工具和框架。
微服務(wù)不適合所有人
分布式服務(wù)的基礎(chǔ)架構(gòu)已經(jīng)成熟，但是更高的效率只能來(lái)自于更好的聲明式系統(tǒng)，這些聲明式系統(tǒng)來(lái)自于改進(jìn)的自動(dòng)化技術(shù)和改進(jìn)的可觀察性。因?yàn)闆](méi)有任何微服務(wù)是完全相同的，這么做可能很棘手。它們的任何自定義工作流程就像雪花一樣。不同之處在于底層的體系結(jié)構(gòu)，以及如何適應(yīng)針對(duì)不同工作負(fù)載的微服務(wù)方法的不斷開(kāi)發(fā)。
設(shè)置邊界很重要，這樣微服務(wù)就不會(huì)被認(rèn)為是萬(wàn)靈藥或有趣項(xiàng)目的分支，因?yàn)槲⒎?wù)需要更多的管理。開(kāi)發(fā)者大批量地構(gòu)建微服務(wù)要追溯回2014年至2016年的鼎盛時(shí)期，這些開(kāi)發(fā)者在喝茶聊天的時(shí)候決定了新的微服務(wù)該怎么構(gòu)建。因此現(xiàn)在如果有幾十個(gè)團(tuán)隊(duì)決定創(chuàng)建自己的微服務(wù)，會(huì)發(fā)生什么?雖然管理是完全可能的，但是會(huì)犧牲效率，從而影響優(yōu)化和獲得更好性能的過(guò)程。
毫無(wú)疑問(wèn)，微服務(wù)是有效的。但是，一個(gè)構(gòu)建良好的單體應(yīng)用整體架構(gòu)也可以擴(kuò)展，并且在許多場(chǎng)景中仍然是很好的選擇。例如，運(yùn)行相同服務(wù)或工作程序的多個(gè)實(shí)例不一定需要微服務(wù)。創(chuàng)建不可伸縮的微服務(wù)也是完全可能的。因此在確定解決方案之前，首先考慮面臨的問(wèn)題是很重要的。
就基礎(chǔ)設(shè)施和技術(shù)支持而言，生態(tài)體系現(xiàn)已接近關(guān)鍵的規(guī)模。微服務(wù)正迅速成為DevOps工具包中的一個(gè)工具，從而更好、更深入地利用資源。這進(jìn)而創(chuàng)建了新的空間來(lái)交付額外的服務(wù)，從而進(jìn)一步實(shí)現(xiàn)聲明性的和優(yōu)雅的工作流、工具和平臺(tái)的潛力。
向著微服務(wù)過(guò)渡的業(yè)務(wù)和流程決策
云原生微服務(wù)是一種真正令人興奮的架構(gòu)演化，尤其是在構(gòu)建、部署和管理復(fù)雜分布式應(yīng) 用程序方面。然而，大多數(shù)圍繞微服務(wù)的討論直接涉及到技術(shù)：持續(xù)集成和部署、容器、 編排器等等。雖然技術(shù)實(shí)現(xiàn)很重要，但是還有一些更重要的事情需要考慮。
微服務(wù)必須與組織的目標(biāo)相適應(yīng)。開(kāi)發(fā)人員可以構(gòu)建微服務(wù)，但是體系結(jié)構(gòu)只有與業(yè)務(wù)目標(biāo)相結(jié)合時(shí)才有價(jià)值。因此必須提出關(guān)鍵問(wèn)題，從業(yè)務(wù)用例、現(xiàn)有團(tuán)隊(duì)、技能和職責(zé)開(kāi)始——采用微服務(wù)的決策取決于組織的目標(biāo)和遠(yuǎn)景。組織中具有實(shí)現(xiàn)復(fù)雜體系結(jié)構(gòu)經(jīng)驗(yàn)的人員必須提出一個(gè)重要的問(wèn)題，并在繼續(xù)前進(jìn)之前得到答案：我們是否適合微服務(wù)體系結(jié)構(gòu)?
Container Solutions的CEO和聯(lián)合創(chuàng)始人Jamie Dobson曾表示，客戶找過(guò)來(lái)希望使用微服務(wù)作為技術(shù)問(wèn)題的解決方案，實(shí)際上卻常常是組織問(wèn)題的技術(shù)解決方案。
評(píng)估云原生服務(wù)。評(píng)估企業(yè)采用云原生微服務(wù)與企業(yè)本身的關(guān)系，而與企業(yè)的規(guī)模、行業(yè)甚至實(shí)際技術(shù)關(guān)系不大。首先，從決策到執(zhí)行的微服務(wù)遷移應(yīng)該由企業(yè)的組織和管理方式驅(qū)動(dòng)：
商業(yè)模式：軟件可以差異化業(yè)務(wù)嗎?如果是這樣，開(kāi)發(fā)團(tuán)隊(duì)必須繼續(xù)增長(zhǎng)和擴(kuò)展，因?yàn)榻M織需要更多的資源和服務(wù)功能?；谖⒎?wù)的體系結(jié)構(gòu)允許更快的迭代開(kāi)發(fā)，可以在跨多個(gè)團(tuán)隊(duì)的工作流中使用。依賴專有的、統(tǒng)一解決方案的組織將不太適合微服務(wù)方法。系統(tǒng)記錄管理(ERP)到服務(wù)級(jí)別協(xié)議(SLA)類(lèi)的商業(yè)軟件協(xié)議意味著，如果企業(yè)選擇遵循將它們帶入微服務(wù)討論的路徑，那么它們將發(fā)生根本性的轉(zhuǎn)變。對(duì)于完全依賴于商業(yè)軟件平臺(tái)的組織來(lái)說(shuō)，實(shí)現(xiàn)微服務(wù)的成本可能會(huì)更高。微服務(wù)所需的在敏捷性和可伸縮性方面的工程支持和開(kāi)銷(xiāo)成本將超過(guò)它們的價(jià)值。
文化和內(nèi)部流程：微服務(wù)需要一套新的工具和流程，并打破舊的工具和流程。對(duì)于負(fù)責(zé)管理單體的組織來(lái)說(shuō)，突然改變工作流可能是一個(gè)困難的轉(zhuǎn)變。接受DevOps原則是微服務(wù)成功的關(guān)鍵。然而，舉例來(lái)說(shuō)，團(tuán)隊(duì)可能會(huì)抗拒從傳統(tǒng)的瀑布方法轉(zhuǎn)向敏捷方法。微軟首席云開(kāi)發(fā)布道師Bridget Kromhout曾表示，“如果你意識(shí)到所涉及的人有著他們自己的習(xí)慣而且他們也許在不遠(yuǎn)的未來(lái)就要退休了，那么這種抵制并不是完全不合理的，而且他們不喜歡一切改變的想法，他們只是以他們喜歡的方式看待問(wèn)題。”
微服務(wù)的基本復(fù)雜性在于應(yīng)用程序體系結(jié)構(gòu)本身：根據(jù)體系結(jié)構(gòu)，每個(gè)服務(wù)都需要自己的支持團(tuán)隊(duì)、工具和基礎(chǔ)設(shè)施。并不是每家公司都在正確的位置采取行動(dòng)。專家強(qiáng)調(diào)，并不是說(shuō)錯(cuò)誤地采用這種體系結(jié)構(gòu)是不可能的，只是這個(gè)過(guò)程會(huì)更長(zhǎng)或更復(fù)雜。對(duì)于許多有著錯(cuò)誤商業(yè)動(dòng)機(jī)或文化的組織來(lái)說(shuō)，成本將高于收益。Bridget Kromhout再次強(qiáng)調(diào)：不能通過(guò)實(shí)施正確的技術(shù)解決方案來(lái)解決組織中的每一個(gè)問(wèn)題，因?yàn)榻M織是復(fù)雜的系統(tǒng)，其中也有可能以不可預(yù)知方式行事的人。
那么，什么時(shí)候微服務(wù)不適合企業(yè)呢?
敏感行業(yè)：某些行業(yè)，例如金融服務(wù)和醫(yī)療保健，面臨法律、報(bào)告和合規(guī)要求，需要與新技術(shù)相協(xié)調(diào)?？勺匪菪砸蛩兀号c更年輕、更緊湊或更敏捷的組織相比，一家在商業(yè)領(lǐng)域經(jīng)營(yíng)數(shù)十年的全球性公司，尤其是平均員工保留時(shí)間超過(guò)10年的公司，很可能更難適應(yīng)向全新架構(gòu)的巨變。“停滯不前”的公司：這些是規(guī)避風(fēng)險(xiǎn)的公司，決策鏈很長(zhǎng)，層次結(jié)構(gòu)僵化。因此當(dāng)采用一種新的響應(yīng)性微服務(wù)范例時(shí)，這些組織并不十分適合，甚至可能會(huì)對(duì)所需的快速適應(yīng)產(chǎn)生抵觸。
New Relic的首席站點(diǎn)可靠性工程師Jonathan Owens表示，考慮轉(zhuǎn)向容器和微服務(wù)架構(gòu)的組織應(yīng)該問(wèn)自己以下問(wèn)題：您的運(yùn)營(yíng)團(tuán)隊(duì)向開(kāi)發(fā)人員提供了什么產(chǎn)品，該產(chǎn)品使用了什么抽象層? 該產(chǎn)品是否適合您的業(yè)務(wù)，還是容器更合適? 容器是否更好，以至于您愿意更改抽象層，從而更改運(yùn)營(yíng)團(tuán)隊(duì)提供的整個(gè)產(chǎn)品，以便使用它們?您是否已準(zhǔn)備好創(chuàng)建新角色來(lái)管理此新抽象的規(guī)模和可靠性?
沒(méi)有哪個(gè)組織會(huì)在一夜之間發(fā)生這樣的變化。從一個(gè)理想化的新架構(gòu)到第一個(gè)產(chǎn)品部署的過(guò)程需要改變?cè)S多想法并創(chuàng)建新的流程，這并不總是很有趣。尋找具有微服務(wù)專業(yè)知識(shí)且能夠做出必要的工具和架構(gòu)決策的工程師也很困難。這些專家包括難以捉摸的“全棧開(kāi)發(fā)人員”，他們了解每一層的應(yīng)用程序：從網(wǎng)絡(luò)和托管環(huán)境，到數(shù)據(jù)建模、業(yè)務(wù)邏輯、API和用戶界面以及用戶體驗(yàn)(UI / UX)。這些人處于獨(dú)特的位置，可以看到技術(shù)體系結(jié)構(gòu)和組織是如何相互關(guān)聯(lián)的。要實(shí)現(xiàn)成功的微服務(wù)轉(zhuǎn)換，組織需要一個(gè)按比例構(gòu)建的技術(shù)體系結(jié)構(gòu)，但維護(hù)該結(jié)構(gòu)的團(tuán)隊(duì)也同樣重要。
這就是為什么許多正在向微服務(wù)過(guò)渡的組織選擇與專業(yè)服務(wù)公司合作，這些公司專門(mén)幫助客戶使用各種不同的架構(gòu)來(lái)構(gòu)建云原生應(yīng)用程序。這些顧問(wèn)可以幫助評(píng)估組織對(duì)微服務(wù)的需求和適用性，或指導(dǎo)他們采用更合適的替代方案。
微服務(wù)最適合嗎?
對(duì)于由業(yè)務(wù)原因而采用微服務(wù)的組織，可以滿懷信心地帶領(lǐng)團(tuán)隊(duì)轉(zhuǎn)型。領(lǐng)導(dǎo)項(xiàng)目的團(tuán)隊(duì)在組織中具有重要地位，并可以開(kāi)始設(shè)置適合現(xiàn)有工作流的優(yōu)秀實(shí)踐。團(tuán)隊(duì)可以采用服務(wù)來(lái)推動(dòng)應(yīng)用程序體系結(jié)構(gòu)的整體開(kāi)發(fā)，并為組織使用更多資源運(yùn)行微服務(wù)做好準(zhǔn)備。
做準(zhǔn)備時(shí)需要技巧和人員管理。適合開(kāi)發(fā)團(tuán)隊(duì)的服務(wù)將定義微服務(wù)。團(tuán)隊(duì)的目標(biāo)是使微服務(wù)成為一個(gè)建立在其價(jià)值基礎(chǔ)上的“底座”，并不斷優(yōu)化開(kāi)發(fā)人員的體驗(yàn)。
評(píng)估應(yīng)用程序的職責(zé)是定義微服務(wù)應(yīng)用程序組件的第一步，Netlify首席技術(shù)官David Calavera曾表示，他是Docker和GitHub先前工作的微服務(wù)老手。確定應(yīng)用程序職責(zé)的相互依賴關(guān)系，這關(guān)系到微服務(wù)的結(jié)構(gòu)。Connascence是一個(gè)評(píng)估應(yīng)用程序組件和互連的衡量標(biāo)準(zhǔn)。因?yàn)閮蓚€(gè)或多個(gè)組件是并發(fā)的，所以如果改變其中一個(gè)組件，還必須更改另一個(gè)組件。
考慮到這種關(guān)系，可以更好地評(píng)估是否值得擁有不同的微服務(wù)，或者是否應(yīng)該保留的單體架構(gòu)。除了相互依賴之外，團(tuán)隊(duì)必須牢記將這些組件分離到微服務(wù)中會(huì)引入它們之間的網(wǎng)絡(luò)連接——這不可避免地增加了系統(tǒng)的復(fù)雜性。
應(yīng)用程序體系結(jié)構(gòu)開(kāi)發(fā)是個(gè)人和團(tuán)隊(duì)如何就他們自己以及重疊的編排進(jìn)行交互和通信的直接結(jié)果。很明顯在這一點(diǎn)上，像Kubernetes這樣的架構(gòu)正變得越來(lái)越重要。隨著越來(lái)越多的開(kāi)發(fā)人員添加進(jìn)來(lái)，應(yīng)用程序變得越來(lái)越復(fù)雜，體系結(jié)構(gòu)的總體復(fù)雜性也隨之增加。但是正如所看到的，這些應(yīng)用程序架構(gòu)并不適合所有人。
Calavera警告說(shuō):“您不希望以犧牲理想架構(gòu)為代價(jià)來(lái)增加不必要的復(fù)雜性。”
【責(zé)任編輯：華軒 TEL：（010）68476606】