[[249189]]

人體是不同系統(tǒng)的組合，其中大多數(shù)系統(tǒng)是獨立的，并且作為一個整體協(xié)同工作。每個系統(tǒng)都有自己的特定功能。所有具有多種其他支持框架的器官構(gòu)成了一個功能完備的機構(gòu)?，F(xiàn)在，如果應(yīng)用于軟件系統(tǒng)，這就是微服務(wù)架構(gòu)的概念。

在技術(shù)方面，微服務(wù)系統(tǒng)允許開發(fā)單個功能模塊。這種開發(fā)單一功能模塊的趨勢為大型和小型組織提高了靈活性，性能和成本效率，同時實現(xiàn)了持續(xù)測試和早期交付。但是，在我們深入研究微服務(wù)設(shè)計的基礎(chǔ)知識之前，讓我們先看看它的優(yōu)點。

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

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

技術(shù)靈活性

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

提高效率

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

產(chǎn)品不是項目

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

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

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

1.功能范圍

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

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

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

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

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

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

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

3.獨特的身份識別來源

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

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

4. API集成

將整體設(shè)計分解為多種服務(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è)計的基礎(chǔ)是使用正確的API。這對于維護服務(wù)和客戶端調(diào)用之間的通信至關(guān)重要。輕松過渡和執(zhí)行對于正常運行非常重要。

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

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

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

6.交通管理

一旦設(shè)置了API并且系統(tǒng)啟動并運行，不同服務(wù)的流量就會有所不同。流量是客戶端發(fā)送給特定服務(wù)的呼叫。在現(xiàn)實世界中，服務(wù)可能運行緩慢，從而導(dǎo)致調(diào)用花費更多時間。或者服務(wù)可能充斥著呼叫。在這兩種情況下，性能都會受到影響，甚至導(dǎo)致軟件或硬件崩潰。

這種高流量需求需要管理。呼叫和被叫的特定方式是流暢的流量的答案。服務(wù)應(yīng)該能夠終止任何導(dǎo)致延遲并影響性能的實例。

這也可以使用稱為“自動縮放”的過程來實現(xiàn)，該過程包括在需要時通過快速動作持續(xù)跟蹤服務(wù)。在某些情況下，“斷路器模式”對于提供在呼叫中斷或服務(wù)無響應(yīng)時可用的任何不完整信息非常重要。

7.自動化流程

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

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

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

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

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

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

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

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

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

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

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

2. DevOps復(fù)雜性

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

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

由于多個組件協(xié)同工作，因此在某種程度上彼此進行通信非常重要。此通信將導(dǎo)致網(wǎng)絡(luò)使用量增加。這需要高速可靠的網(wǎng)絡(luò)連接。此外，運行這些應(yīng)用程序的費用也會增加。所有服務(wù)都單獨運行，增加了運營成本。

4.測試

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

5.安全

在Web應(yīng)用程序方面，安全性至關(guān)重要。使用微服務(wù)，實現(xiàn)這一點很困難。當(dāng)存在獨立模塊的集群時，每個模塊都需要遵守為整個系統(tǒng)定義的認(rèn)證和授權(quán)規(guī)范。

除此之外，每個模塊可能與其他模塊通信，跟蹤數(shù)據(jù)流變得非常困難。需要其他措施，例如具有負(fù)載平衡的API網(wǎng)關(guān)，以確保行為一致。這些額外的步驟導(dǎo)致每個微服務(wù)的開銷。

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

由于微服務(wù)是獨立組件，因此每個微服務(wù)通常都有一個最適合其需求的技術(shù)堆棧。例如，機器學(xué)習(xí)模塊可能使用python堆棧，而計量服務(wù)可能使用Java堆棧，UI服務(wù)可能使用MEAN堆棧。這會導(dǎo)致復(fù)雜性，因為資源池和管理和構(gòu)建新功能所需的技能將非常高。

7.高初始投資

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

這值得么?

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

此外，它還可以克服延遲和缺陷，同時提高靈活性和性能。記住上面提到的，可以說微服務(wù)架構(gòu)對于成功的軟件系統(tǒng)是必要的。

包括PayPal，Twitter，LambdaTest和Netflix 在內(nèi)的許多企業(yè)都支持微服務(wù)架構(gòu)的可靠性，以部署更具可擴展性，功能性和強大的軟件。

原文標(biāo)題：9 Fundamentals of a Successful Microservice Design