[[249189]]

人體是不同系統(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)允許開發(fā)單個(gè)功能模塊。這種開發(fā)單一功能模塊的趨勢為大型和小型組織提高了靈活性，性能和成本效率，同時(shí)實(shí)現(xiàn)了持續(xù)測試和早期交付。但是，在我們深入研究微服務(wù)設(shè)計(jì)的基礎(chǔ)知識(shí)之前，讓我們先看看它的優(yōu)點(diǎn)。

微服務(wù)架構(gòu)的優(yōu)點(diǎn)

對(duì)于單一體系結(jié)構(gòu)，開發(fā)人員經(jīng)常面臨有限的可重用性和可伸縮性的挑戰(zhàn)。但是，通過微服務(wù)設(shè)計(jì)，可以將這個(gè)單元分解為不同的模塊，從而簡化開發(fā)，部署和維護(hù)。那么讓我們來看看微服務(wù)架構(gòu)的一些主要優(yōu)點(diǎn)：

技術(shù)靈活性

雖然單片架構(gòu)總是讓開發(fā)人員尋找“適合工作的正確工具”，但微服務(wù)架構(gòu)在一個(gè)封面下提供了多種技術(shù)的共存。可以用多種編程語言編寫不同的解耦服務(wù)。這不僅使開發(fā)人員能夠進(jìn)行實(shí)驗(yàn)，還通過添加其他功能和功能來擴(kuò)展其產(chǎn)品。

提高效率

微服務(wù)架構(gòu)加速了整個(gè)創(chuàng)建過程。與單個(gè)單元不同，團(tuán)隊(duì)可以同時(shí)處理軟件系統(tǒng)的多個(gè)組件。除了提高生產(chǎn)率之外，還可以更輕松地定位特定組件并專注于它們。單個(gè)組件的故障不會(huì)影響整個(gè)系統(tǒng)。相反，這也簡化了錯(cuò)誤定位和維護(hù)。

產(chǎn)品不是項(xiàng)目

根據(jù)Martin Fowler的說法，微服務(wù)架構(gòu)可以幫助企業(yè)創(chuàng)建“產(chǎn)品而不是項(xiàng)目。簡單來說，微服務(wù)架構(gòu)的使用允許團(tuán)隊(duì)聚集在一起并為業(yè)務(wù)創(chuàng)建功能而不是簡單的代碼。整個(gè)團(tuán)隊(duì)聚集在一起，為不同的功能做出貢獻(xiàn)。如果適用，這些可以進(jìn)一步用于不同的業(yè)務(wù)。此外，它還創(chuàng)建了一個(gè)自主的跨職能團(tuán)隊(duì)。

成功的微服務(wù)設(shè)計(jì)的基礎(chǔ)知識(shí)

現(xiàn)在我們知道微服務(wù)架構(gòu)的優(yōu)勢，但是，我們?nèi)绾螌?shí)現(xiàn)完美?我們是否了解微服務(wù)設(shè)計(jì)原則?設(shè)計(jì)微服務(wù)架構(gòu)的最佳實(shí)踐是什么?讓我們回答這些問題，看看成功的微服務(wù)設(shè)計(jì)的一些基礎(chǔ)知識(shí)。

1.功能范圍

通過不同團(tuán)隊(duì)同時(shí)實(shí)施開發(fā)和部署以建立或支持與產(chǎn)品分別獨(dú)特的功能，定義微服務(wù)的范圍成為非常重要的任務(wù)。雖然許多人擔(dān)心創(chuàng)建“太多”微小的微服務(wù)，但通常更常見的是這些微服務(wù)過載。

當(dāng)我們談?wù)撐⒎?wù)的范圍時(shí)，我們指的是獨(dú)立軟件模塊的功能。微服務(wù)作為幾乎無狀態(tài)系統(tǒng)的能力使其能夠獨(dú)立開發(fā)。因此，必須確定微服務(wù)將實(shí)現(xiàn)的功能。這有助于理解微服務(wù)的責(zé)任嗎?實(shí)現(xiàn)每個(gè)微服務(wù)應(yīng)該服務(wù)的預(yù)期功能。不僅要防止過載，還要服務(wù)于不同的場景。例如，在單片設(shè)置中多次調(diào)用一段代碼，創(chuàng)建微服務(wù)將使其更易于訪問和使用。最小化代碼量只會(huì)提高效率并避免膨脹的服務(wù)。

問題是關(guān)于如何定義微服務(wù)的范圍。雖然沒有明確定義的規(guī)則集來實(shí)現(xiàn)這一目標(biāo)，但如果您可以定義范圍，則可以使用一些指南或最佳實(shí)踐。以下是您可以用來定義微服務(wù)的一些步驟。

• 第一步是確定在各種模塊下復(fù)制的代碼片段。你經(jīng)?？吹剿鼈冎貜?fù)嗎?每次在不同的模塊中設(shè)置它們需要花費(fèi)多少精力?如果所有這些的答案都很高，那么微服務(wù)的范圍就是只處理重復(fù)的代碼片段。
• 您可以采取的另一個(gè)步驟是檢查模塊是否不依賴于其他模塊或更簡單的術(shù)語，檢查模塊是否可能與其余服務(wù)松散耦合。如果是這樣，那么微服務(wù)的范圍將是整個(gè)模塊的范圍。
• 在定義范圍時(shí)要考慮的另一個(gè)非常重要的指標(biāo)是檢查功能是否將用于重負(fù)載。這將檢查微服務(wù)是否必須在不久的將來擴(kuò)展。如果確實(shí)如此，那么將可擴(kuò)展位定義為微服務(wù)的范圍而不是將其與其他功能相結(jié)合是一個(gè)好主意。

2.高內(nèi)聚力與松耦合

任何微服務(wù)的主要?jiǎng)訖C(jī)是使服務(wù)彼此獨(dú)立。這意味著可以編輯，更新或部署新服務(wù)，而不會(huì)妨礙任何其他服務(wù)。如果相互依賴性很低，這是可能的。松散耦合的系統(tǒng)是一個(gè)服務(wù)對(duì)其他服務(wù)知之甚少或什么都不知道的系統(tǒng)。

在將整體架構(gòu)分解為更小的服務(wù)或組件時(shí)，將類似功能組合起來非常重要。將相關(guān)邏輯組合成單個(gè)單元是已知的內(nèi)聚。內(nèi)聚力越高，微服務(wù)架構(gòu)越好。較低的內(nèi)聚力表明不同服務(wù)之間的通信過多導(dǎo)致系統(tǒng)性能較差。

3.獨(dú)特的身份識(shí)別來源

遵循微服務(wù)設(shè)計(jì)的基本原則，任何服務(wù)都必須成為系統(tǒng)其余部分的唯一識(shí)別源。讓我們舉一個(gè)例子來理解這種情況。

在電子商務(wù)網(wǎng)站上下訂單后，向用戶提供訂單ID。生成此訂單ID包含有關(guān)訂單的所有信息。作為微服務(wù)，訂單ID是有關(guān)訂單服務(wù)的任何信息的唯一來源。因此，如果任何其他服務(wù)尋求關(guān)于訂單服務(wù)的信息，則訂單ID充當(dāng)信息源而不是其實(shí)際屬性。

4. API集成

將整體設(shè)計(jì)分解為多種服務(wù)意味著這些服務(wù)將協(xié)調(diào)并協(xié)同工作以形成系統(tǒng)。但是，這些服務(wù)如何溝通?想象一下，使用多種技術(shù)來創(chuàng)建不同的服務(wù)。它們?nèi)绾蜗嗷リP(guān)聯(lián)?

嗯，簡單的答案是使用API(應(yīng)用程序編程接口)。微服務(wù)設(shè)計(jì)的基礎(chǔ)是使用正確的API。這對(duì)于維護(hù)服務(wù)和客戶端調(diào)用之間的通信至關(guān)重要。輕松過渡和執(zhí)行對(duì)于正常運(yùn)行非常重要。

創(chuàng)建API時(shí)需要注意的另一個(gè)重要事項(xiàng)是業(yè)務(wù)領(lǐng)域。域的這種定義將簡化區(qū)分功能的過程。有幾個(gè)客戶端在系統(tǒng)外部。這些客戶端可以是其他應(yīng)用程序或用戶。無論何時(shí)調(diào)用業(yè)務(wù)邏輯，它都由適配器(消息網(wǎng)關(guān)或Web控制器)處理，該適配器返回請(qǐng)求并對(duì)數(shù)據(jù)庫進(jìn)行更改。

5.數(shù)據(jù)存儲(chǔ)隔離

為特定服務(wù)存儲(chǔ)的任何數(shù)據(jù)都應(yīng)該對(duì)該特定服務(wù)保密。這意味著對(duì)數(shù)據(jù)的任何訪問都應(yīng)歸服務(wù)所有。此數(shù)據(jù)只能通過API與任何其他服務(wù)共享。這對(duì)于保持對(duì)數(shù)據(jù)的有限訪問并避免“服務(wù)耦合”非常重要?；谟脩舻臄?shù)據(jù)分類很重要，可以通過命令和查詢責(zé)任分離(CQRS)來實(shí)現(xiàn)。

6.交通管理

一旦設(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)縮放”的過程來實(shí)現(xiàn)，該過程包括在需要時(shí)通過快速動(dòng)作持續(xù)跟蹤服務(wù)。在某些情況下，“斷路器模式”對(duì)于提供在呼叫中斷或服務(wù)無響應(yīng)時(shí)可用的任何不完整信息非常重要。

7.自動(dòng)化流程

獨(dú)立設(shè)計(jì)的微服務(wù)應(yīng)該能夠自行運(yùn)行。自動(dòng)化將實(shí)現(xiàn)自我部署和功能，而無需任何干預(yù)。此過程使服務(wù)本質(zhì)上具有云原生性，并且能夠在任何環(huán)境中部署。但要實(shí)現(xiàn)這一目標(biāo)，讓DevOps團(tuán)隊(duì)不斷致力于服務(wù)的發(fā)展是非常重要的。

8.最小數(shù)據(jù)庫表(最好是隔離表)

訪問數(shù)據(jù)庫表以獲取數(shù)據(jù)可能是一個(gè)漫長的過程。它可能需要時(shí)間和精力。在設(shè)計(jì)微服務(wù)時(shí)，主要?jiǎng)訖C(jī)應(yīng)該圍繞業(yè)務(wù)功能而不是數(shù)據(jù)庫及其工作。為了確保這一點(diǎn)，即使數(shù)據(jù)條目達(dá)到數(shù)百萬，微服務(wù)設(shè)計(jì)也應(yīng)該只有幾個(gè)表。除了最小數(shù)量，關(guān)注業(yè)務(wù)是關(guān)鍵。

9.持續(xù)監(jiān)測

想象一下，將單片架構(gòu)分解為微服務(wù)設(shè)計(jì)。這需要大量的時(shí)間和資源。在傳統(tǒng)工具的幫助下監(jiān)控所做的所有更改并不容易。插入數(shù)據(jù)層和緩存會(huì)提高性能，但卻難以監(jiān)控整個(gè)過程。

因此，為了設(shè)計(jì)微服務(wù)架構(gòu)，重要的是建立用于主動(dòng)監(jiān)視中心位置的數(shù)據(jù)存儲(chǔ)的過程。這有助于反映頻繁的變化，而不會(huì)影響系統(tǒng)的性能。在一個(gè)常見的場景中，微服務(wù)監(jiān)控工具將監(jiān)控單個(gè)服務(wù)，然后通過將數(shù)據(jù)存儲(chǔ)在一個(gè)集中位置來組合數(shù)據(jù)。這是遵循微服務(wù)設(shè)計(jì)原則的必要步驟。

實(shí)現(xiàn)API在成功的微服務(wù)架構(gòu)中扮演的關(guān)鍵角色。還必須有一個(gè)持續(xù)監(jiān)控API性能的過程。API性能監(jiān)控對(duì)于任何微服務(wù)架構(gòu)都至關(guān)重要，以確保功能在速度，響應(yīng)性和產(chǎn)品的整體性能方面始終如一。

微服務(wù)架構(gòu)的局限性

雖然微服務(wù)是降低整體結(jié)構(gòu)的最佳方式，但它有其自身的一些缺點(diǎn)。但在得出任何結(jié)論之前，讓我們來看看其中的一些。

1.開發(fā)環(huán)境超載

隨著應(yīng)用程序及其數(shù)據(jù)庫的增長，代碼庫也在不斷擴(kuò)展。隨著針對(duì)每個(gè)微服務(wù)的代碼擴(kuò)展，它會(huì)使每個(gè)加載的應(yīng)用程序的開發(fā)環(huán)境過載。這可能導(dǎo)致生產(chǎn)力的重大延遲。

2. DevOps復(fù)雜性

單功能微服務(wù)的開發(fā)和部署并非易事。使用多種技術(shù)并創(chuàng)建API來集中系統(tǒng)是一項(xiàng)挑戰(zhàn)。這需要一個(gè)經(jīng)驗(yàn)豐富的DevOps團(tuán)隊(duì)。采購這樣一個(gè)經(jīng)驗(yàn)豐富的DevOps團(tuán)隊(duì)對(duì)于維護(hù)基于微服務(wù)的應(yīng)用程序的復(fù)雜性至關(guān)重要。

3.增加資源和網(wǎng)絡(luò)使用

由于多個(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)營成本。

4.測試

測試應(yīng)用程序可能具有挑戰(zhàn)性，因?yàn)橛袉为?dú)的組件。與單片應(yīng)用程序相比，微服務(wù)需要更長的時(shí)間進(jìn)行測試，并且在出現(xiàn)任何錯(cuò)誤時(shí)更加復(fù)雜。有時(shí)，由于測試最終會(huì)影響整個(gè)應(yīng)用程序，可能會(huì)導(dǎo)致延遲。

5.安全

在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ù)的開銷。

6.應(yīng)用程序的復(fù)雜性

由于微服務(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)建新功能所需的技能將非常高。

7.高初始投資

微服務(wù)獨(dú)立運(yùn)行，它們需要獨(dú)立的容器或資源來運(yùn)行它們。每個(gè)項(xiàng)目可能有很多微服務(wù)一起工作，需要更高的投資來設(shè)置包括微服務(wù)，安全容器，負(fù)載平衡器，API網(wǎng)關(guān)等的所有集群。

這值得么?

在閱讀了微服務(wù)設(shè)計(jì)的基本原理之后，很明顯需要遵循一系列最佳實(shí)踐。但是，我們還觀察微服務(wù)設(shè)計(jì)原則如何通過打破單片架構(gòu)來簡化創(chuàng)建應(yīng)用程序的過程。但是，與此同時(shí)，在調(diào)整微服務(wù)架構(gòu)時(shí)需要克服某些挑戰(zhàn)。這些復(fù)雜性會(huì)影響運(yùn)營流程，但從長遠(yuǎn)來看，克服這些挑戰(zhàn)可以帶來優(yōu)化和更高效的應(yīng)用。

此外，它還可以克服延遲和缺陷，同時(shí)提高靈活性和性能。記住上面提到的，可以說微服務(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