人體是不同系統(tǒng)的組合，其中大多數(shù)系統(tǒng)是獨(dú)立的，并且作為一個(gè)整體協(xié)同工作。每個(gè)系統(tǒng)都有自己的特定功能。所有具有多種其他支持框架的器官構(gòu)成了一個(gè)功能完備的機(jī)構(gòu)?，F(xiàn)在，如果應(yīng)用于軟件系統(tǒng)，這就是微服務(wù)架構(gòu)的概念。
在技術(shù)方面，微服務(wù)系統(tǒng)允許開(kāi)發(fā)單個(gè)功能模塊。這種開(kāi)發(fā)單一功能模塊的趨勢(shì)為大型和小型組織提高了靈活性，性能和成本效率，同時(shí)實(shí)現(xiàn)了持續(xù)測(cè)試和早期交付。但是，在我們深入研究微服務(wù)設(shè)計(jì)的基礎(chǔ)知識(shí)之前，讓我們先看看它的優(yōu)點(diǎn)。
對(duì)于單一體系結(jié)構(gòu)，開(kāi)發(fā)人員經(jīng)常面臨有限的可重用性和可伸縮性的挑戰(zhàn)。但是，通過(guò)微服務(wù)設(shè)計(jì)，可以將這個(gè)單元分解為不同的模塊，從而簡(jiǎn)化開(kāi)發(fā)，部署和維護(hù)。那么讓我們來(lái)看看微服務(wù)架構(gòu)的一些主要優(yōu)點(diǎn)：
雖然單片架構(gòu)總是讓開(kāi)發(fā)人員尋找“適合工作的正確工具”，但微服務(wù)架構(gòu)在一個(gè)封面下提供了多種技術(shù)的共存?？梢杂枚喾N編程語(yǔ)言編寫(xiě)不同的解耦服務(wù)。這不僅使開(kāi)發(fā)人員能夠進(jìn)行實(shí)驗(yàn)，還通過(guò)添加其他功能和功能來(lái)擴(kuò)展其產(chǎn)品。
微服務(wù)架構(gòu)加速了整個(gè)創(chuàng)建過(guò)程。與單個(gè)單元不同，團(tuán)隊(duì)可以同時(shí)處理軟件系統(tǒng)的多個(gè)組件。除了提高生產(chǎn)率之外，還可以更輕松地定位特定組件并專注于它們。單個(gè)組件的故障不會(huì)影響整個(gè)系統(tǒng)。相反，這也簡(jiǎn)化了錯(cuò)誤定位和維護(hù)。
根據(jù)Martin Fowler的說(shuō)法，微服務(wù)架構(gòu)可以幫助企業(yè)創(chuàng)建“產(chǎn)品而不是項(xiàng)目。簡(jiǎn)單來(lái)說(shuō)，微服務(wù)架構(gòu)的使用允許團(tuán)隊(duì)聚集在一起并為業(yè)務(wù)創(chuàng)建功能而不是簡(jiǎn)單的代碼。整個(gè)團(tuán)隊(duì)聚集在一起，為不同的功能做出貢獻(xiàn)。如果適用，這些可以進(jìn)一步用于不同的業(yè)務(wù)。此外，它還創(chuàng)建了一個(gè)自主的跨職能團(tuán)隊(duì)。
現(xiàn)在我們知道微服務(wù)架構(gòu)的優(yōu)勢(shì)，但是，我們?nèi)绾螌?shí)現(xiàn)完美？我們是否了解微服務(wù)設(shè)計(jì)原則？設(shè)計(jì)微服務(wù)架構(gòu)的最佳實(shí)踐是什么？讓我們回答這些問(wèn)題，看看成功的微服務(wù)設(shè)計(jì)的一些基礎(chǔ)知識(shí)。
通過(guò)不同團(tuán)隊(duì)同時(shí)實(shí)施開(kāi)發(fā)和部署以建立或支持與產(chǎn)品分別獨(dú)特的功能，定義微服務(wù)的范圍成為非常重要的任務(wù)。雖然許多人擔(dān)心創(chuàng)建“太多”微小的微服務(wù)，但通常更常見(jiàn)的是這些微服務(wù)過(guò)載。
當(dāng)我們談?wù)撐⒎?wù)的范圍時(shí)，我們指的是獨(dú)立軟件模塊的功能。微服務(wù)作為幾乎無(wú)狀態(tài)系統(tǒng)的能力使其能夠獨(dú)立開(kāi)發(fā)。因此，必須確定微服務(wù)將實(shí)現(xiàn)的功能。這有助于理解微服務(wù)的責(zé)任嗎？實(shí)現(xiàn)每個(gè)微服務(wù)應(yīng)該服務(wù)的預(yù)期功能。不僅要防止過(guò)載，還要服務(wù)于不同的場(chǎng)景。例如，在單片設(shè)置中多次調(diào)用一段代碼，創(chuàng)建微服務(wù)將使其更易于訪問(wèn)和使用。最小化代碼量只會(huì)提高效率并避免膨脹的服務(wù)。
問(wèn)題是關(guān)于如何定義微服務(wù)的范圍。雖然沒(méi)有明確定義的規(guī)則集來(lái)實(shí)現(xiàn)這一目標(biāo)，但如果您可以定義范圍，則可以使用一些指南或最佳實(shí)踐。以下是您可以用來(lái)定義微服務(wù)的一些步驟。
第一步是確定在各種模塊下復(fù)制的代碼片段。你經(jīng)?？吹剿鼈冎貜?fù)嗎？每次在不同的模塊中設(shè)置它們需要花費(fèi)多少精力？如果所有這些的答案都很高，那么微服務(wù)的范圍就是只處理重復(fù)的代碼片段。
您可以采取的另一個(gè)步驟是檢查模塊是否不依賴于其他模塊或更簡(jiǎn)單的術(shù)語(yǔ)，檢查模塊是否可能與其余服務(wù)松散耦合。如果是這樣，那么微服務(wù)的范圍將是整個(gè)模塊的范圍。
在定義范圍時(shí)要考慮的另一個(gè)非常重要的指標(biāo)是檢查功能是否將用于重負(fù)載。這將檢查微服務(wù)是否必須在不久的將來(lái)擴(kuò)展。如果確實(shí)如此，那么將可擴(kuò)展位定義為微服務(wù)的范圍而不是將其與其他功能相結(jié)合是一個(gè)好主意。
任何微服務(wù)的主要?jiǎng)訖C(jī)是使服務(wù)彼此獨(dú)立。這意味著可以編輯，更新或部署新服務(wù)，而不會(huì)妨礙任何其他服務(wù)。如果相互依賴性很低，這是可能的。松散耦合的系統(tǒng)是一個(gè)服務(wù)對(duì)其他服務(wù)知之甚少或什么都不知道的系統(tǒng)。
在將整體架構(gòu)分解為更小的服務(wù)或組件時(shí)，將類似功能組合起來(lái)非常重要。將相關(guān)邏輯組合成單個(gè)單元是已知的內(nèi)聚。內(nèi)聚力越高，微服務(wù)架構(gòu)越好。較低的內(nèi)聚力表明不同服務(wù)之間的通信過(guò)多導(dǎo)致系統(tǒng)性能較差。
遵循微服務(wù)設(shè)計(jì)的基本原則，任何服務(wù)都必須成為系統(tǒng)其余部分的唯一識(shí)別源。讓我們舉一個(gè)例子來(lái)理解這種情況。
在電子商務(wù)網(wǎng)站上下訂單后，向用戶提供訂單ID。生成此訂單ID包含有關(guān)訂單的所有信息。作為微服務(wù)，訂單ID是有關(guān)訂單服務(wù)的任何信息的唯一來(lái)源。因此，如果任何其他服務(wù)尋求關(guān)于訂單服務(wù)的信息，則訂單ID充當(dāng)信息源而不是其實(shí)際屬性。
將整體設(shè)計(jì)分解為多種服務(wù)意味著這些服務(wù)將協(xié)調(diào)并協(xié)同工作以形成系統(tǒng)。但是，這些服務(wù)如何溝通？想象一下，使用多種技術(shù)來(lái)創(chuàng)建不同的服務(wù)。它們?nèi)绾蜗嗷リP(guān)聯(lián)？
嗯，簡(jiǎn)單的答案是使用API（應(yīng)用程序編程接口）。微服務(wù)設(shè)計(jì)的基礎(chǔ)是使用正確的API。這對(duì)于維護(hù)服務(wù)和客戶端調(diào)用之間的通信至關(guān)重要。輕松過(guò)渡和執(zhí)行對(duì)于正常運(yùn)行非常重要。
創(chuàng)建API時(shí)需要注意的另一個(gè)重要事項(xiàng)是業(yè)務(wù)領(lǐng)域。域的這種定義將簡(jiǎn)化區(qū)分功能的過(guò)程。有幾個(gè)客戶端在系統(tǒng)外部。這些客戶端可以是其他應(yīng)用程序或用戶。無(wú)論何時(shí)調(diào)用業(yè)務(wù)邏輯，它都由適配器（消息網(wǎng)關(guān)或Web控制器）處理，該適配器返回請(qǐng)求并對(duì)數(shù)據(jù)庫(kù)進(jìn)行更改。
為特定服務(wù)存儲(chǔ)的任何數(shù)據(jù)都應(yīng)該對(duì)該特定服務(wù)保密。這意味著對(duì)數(shù)據(jù)的任何訪問(wèn)都應(yīng)歸服務(wù)所有。此數(shù)據(jù)只能通過(guò)API與任何其他服務(wù)共享。這對(duì)于保持對(duì)數(shù)據(jù)的有限訪問(wèn)并避免“服務(wù)耦合”非常重要?；谟脩舻臄?shù)據(jù)分類很重要，可以通過(guò)命令和查詢責(zé)任分離（CQRS）來(lái)實(shí)現(xiàn)。
一旦設(shè)置了API并且系統(tǒng)啟動(dòng)并運(yùn)行，不同服務(wù)的流量就會(huì)有所不同。流量是客戶端發(fā)送給特定服務(wù)的呼叫。在現(xiàn)實(shí)世界中，服務(wù)可能運(yùn)行緩慢，從而導(dǎo)致調(diào)用花費(fèi)更多時(shí)間?；蛘叻?wù)可能充斥著呼叫。在這兩種情況下，性能都會(huì)受到影響，甚至導(dǎo)致軟件或硬件崩潰。
這種高流量需求需要管理。呼叫和被叫的特定方式是流暢的流量的答案。服務(wù)應(yīng)該能夠終止任何導(dǎo)致延遲并影響性能的實(shí)例。
這也可以使用稱為“自動(dòng)縮放”的過(guò)程來(lái)實(shí)現(xiàn)，該過(guò)程包括在需要時(shí)通過(guò)快速動(dòng)作持續(xù)跟蹤服務(wù)。在某些情況下，“斷路器模式”對(duì)于提供在呼叫中斷或服務(wù)無(wú)響應(yīng)時(shí)可用的任何不完整信息非常重要。
獨(dú)立設(shè)計(jì)的微服務(wù)應(yīng)該能夠自行運(yùn)行。自動(dòng)化將實(shí)現(xiàn)自我部署和功能，而無(wú)需任何干預(yù)。此過(guò)程使服務(wù)本質(zhì)上具有云原生性，并且能夠在任何環(huán)境中部署。但要實(shí)現(xiàn)這一目標(biāo)，讓DevOps團(tuán)隊(duì)不斷致力于服務(wù)的發(fā)展是非常重要的。
訪問(wèn)數(shù)據(jù)庫(kù)表以獲取數(shù)據(jù)可能是一個(gè)漫長(zhǎng)的過(guò)程。它可能需要時(shí)間和精力。在設(shè)計(jì)微服務(wù)時(shí)，主要?jiǎng)訖C(jī)應(yīng)該圍繞業(yè)務(wù)功能而不是數(shù)據(jù)庫(kù)及其工作。為了確保這一點(diǎn)，即使數(shù)據(jù)條目達(dá)到數(shù)百萬(wàn)，微服務(wù)設(shè)計(jì)也應(yīng)該只有幾個(gè)表。除了最小數(shù)量，關(guān)注業(yè)務(wù)是關(guān)鍵。
想象一下，將單片架構(gòu)分解為微服務(wù)設(shè)計(jì)。這需要大量的時(shí)間和資源。在傳統(tǒng)工具的幫助下監(jiān)控所做的所有更改并不容易。插入數(shù)據(jù)層和緩存會(huì)提高性能，但卻難以監(jiān)控整個(gè)過(guò)程。
因此，為了設(shè)計(jì)微服務(wù)架構(gòu)，重要的是建立用于主動(dòng)監(jiān)視中心位置的數(shù)據(jù)存儲(chǔ)的過(guò)程。這有助于反映頻繁的變化，而不會(huì)影響系統(tǒng)的性能。在一個(gè)常見(jiàn)的場(chǎng)景中，微服務(wù)監(jiān)控工具將監(jiān)控單個(gè)服務(wù)，然后通過(guò)將數(shù)據(jù)存儲(chǔ)在一個(gè)集中位置來(lái)組合數(shù)據(jù)。這是遵循微服務(wù)設(shè)計(jì)原則的必要步驟。
實(shí)現(xiàn)API在成功的微服務(wù)架構(gòu)中扮演的關(guān)鍵角色。還必須有一個(gè)持續(xù)監(jiān)控API性能的過(guò)程。API性能監(jiān)控對(duì)于任何微服務(wù)架構(gòu)都至關(guān)重要，以確保功能在速度，響應(yīng)性和產(chǎn)品的整體性能方面始終如一。
雖然微服務(wù)是降低整體結(jié)構(gòu)的最佳方式，但它有其自身的一些缺點(diǎn)。但在得出任何結(jié)論之前，讓我們來(lái)看看其中的一些。
隨著應(yīng)用程序及其數(shù)據(jù)庫(kù)的增長(zhǎng)，代碼庫(kù)也在不斷擴(kuò)展。隨著針對(duì)每個(gè)微服務(wù)的代碼擴(kuò)展，它會(huì)使每個(gè)加載的應(yīng)用程序的開(kāi)發(fā)環(huán)境過(guò)載。這可能導(dǎo)致生產(chǎn)力的重大延遲。
單功能微服務(wù)的開(kāi)發(fā)和部署并非易事。使用多種技術(shù)并創(chuàng)建API來(lái)集中系統(tǒng)是一項(xiàng)挑戰(zhàn)。這需要一個(gè)經(jīng)驗(yàn)豐富的DevOps團(tuán)隊(duì)。采購(gòu)這樣一個(gè)經(jīng)驗(yàn)豐富的DevOps團(tuán)隊(duì)對(duì)于維護(hù)基于微服務(wù)的應(yīng)用程序的復(fù)雜性至關(guān)重要。
由于多個(gè)組件協(xié)同工作，因此在某種程度上彼此進(jìn)行通信非常重要。此通信將導(dǎo)致網(wǎng)絡(luò)使用量增加。這需要高速可靠的網(wǎng)絡(luò)連接。此外，運(yùn)行這些應(yīng)用程序的費(fèi)用也會(huì)增加。所有服務(wù)都單獨(dú)運(yùn)行，增加了運(yùn)營(yíng)成本。
測(cè)試應(yīng)用程序可能具有挑戰(zhàn)性，因?yàn)橛袉为?dú)的組件。與單片應(yīng)用程序相比，微服務(wù)需要更長(zhǎng)的時(shí)間進(jìn)行測(cè)試，并且在出現(xiàn)任何錯(cuò)誤時(shí)更加復(fù)雜。有時(shí)，由于測(cè)試最終會(huì)影響整個(gè)應(yīng)用程序，可能會(huì)導(dǎo)致延遲。
在Web應(yīng)用程序方面，安全性至關(guān)重要。使用微服務(wù)，實(shí)現(xiàn)這一點(diǎn)很困難。當(dāng)存在獨(dú)立模塊的集群時(shí)，每個(gè)模塊都需要遵守為整個(gè)系統(tǒng)定義的認(rèn)證和授權(quán)規(guī)范。
除此之外，每個(gè)模塊可能與其他模塊通信，跟蹤數(shù)據(jù)流變得非常困難。需要其他措施，例如具有負(fù)載平衡的API網(wǎng)關(guān)，以確保行為一致。這些額外的步驟導(dǎo)致每個(gè)微服務(wù)的開(kāi)銷。
由于微服務(wù)是獨(dú)立組件，因此每個(gè)微服務(wù)通常都有一個(gè)最適合其需求的技術(shù)堆棧。例如，機(jī)器學(xué)習(xí)模塊可能使用python堆棧，而計(jì)量服務(wù)可能使用Java堆棧，UI服務(wù)可能使用MEAN堆棧。這會(huì)導(dǎo)致復(fù)雜性，因?yàn)橘Y源池和管理和構(gòu)建新功能所需的技能將非常高。
微服務(wù)獨(dú)立運(yùn)行，它們需要獨(dú)立的容器或資源來(lái)運(yùn)行它們。每個(gè)項(xiàng)目可能有很多微服務(wù)一起工作，需要更高的投資來(lái)設(shè)置包括微服務(wù)，安全容器，負(fù)載平衡器，API網(wǎng)關(guān)等的所有集群。
在閱讀了微服務(wù)設(shè)計(jì)的基本原理之后，很明顯需要遵循一系列最佳實(shí)踐。但是，我們還觀察微服務(wù)設(shè)計(jì)原則如何通過(guò)打破單片架構(gòu)來(lái)簡(jiǎn)化創(chuàng)建應(yīng)用程序的過(guò)程。但是，與此同時(shí)，在調(diào)整微服務(wù)架構(gòu)時(shí)需要克服某些挑戰(zhàn)。這些復(fù)雜性會(huì)影響運(yùn)營(yíng)流程，但從長(zhǎng)遠(yuǎn)來(lái)看，克服這些挑戰(zhàn)可以帶來(lái)優(yōu)化和更高效的應(yīng)用。
此外，它還可以克服延遲和缺陷，同時(shí)提高靈活性和性能。記住上面提到的，可以說(shuō)微服務(wù)架構(gòu)對(duì)于成功的軟件系統(tǒng)是必要的。
包括PayPal，Twitter，LambdaTest和Netflix 在內(nèi)的許多企業(yè)都支持微服務(wù)架構(gòu)的可靠性，以部署更具可擴(kuò)展性，功能性和強(qiáng)大的軟件。
原文標(biāo)題《9 Fundamentals of a Successful Microservice Design》
作者：Akshay Pai
聯(lián)系客服
