人體是不同系統(tǒng)的組合，其中大多數(shù)系統(tǒng)是獨(dú)立的，并且作為一個(gè)整體協(xié)同工作盈厘。每個(gè)系統(tǒng)都有自己的特定功能。所有具有多種其他支持框架的器官構(gòu)成了一個(gè)功能完備的機(jī)構(gòu)」俦撸現(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)。
微服務(wù)架構(gòu)的優(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)：
技術(shù)靈活性
雖然單片架構(gòu)總是讓開(kāi)發(fā)人員尋找“適合工作的工具”池凄，但是微服務(wù)架構(gòu)在一個(gè)掩護(hù)下提供了多種技術(shù)的共存。不同的解耦服務(wù)可以用多種編程語(yǔ)言編寫(xiě)谅辣。這不僅使開(kāi)發(fā)人員能夠進(jìn)行試驗(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)率之外蚣录，還可以更輕松地定位特定組件并專(zhuān)注于它們割择。單個(gè)組件的故障不會(huì)影響整個(gè)系統(tǒng)。相反萎河，這也簡(jiǎn)化了錯(cuò)誤定位和維護(hù)荔泳。
產(chǎn)品不是項(xiàng)目
根據(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ì)叹侄。
成功的微服務(wù)設(shè)計(jì)的基礎(chǔ)知識(shí)
現(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í)。
1.功能范圍
通過(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ù)的一些步驟学辱。
1乘瓤、第一步是確定在各種模塊下復(fù)制的代碼片段环形。你經(jīng)常看到它們重復(fù)嗎衙傀？每次在不同的模塊中設(shè)置它們需要花費(fèi)多少精力抬吟？如果所有這些的答案都很高，那么微服務(wù)的范圍就是只處理重復(fù)的代碼片段统抬。
2拗军、您可以采取的另一個(gè)步驟是檢查模塊是否不依賴(lài)于其他模塊或更簡(jiǎn)單的術(shù)語(yǔ)，檢查模塊是否可能與其余服務(wù)松散耦合蓄喇。如果是這樣，那么微服務(wù)的范圍將是整個(gè)模塊的范圍交掏。
3妆偏、在定義范圍時(shí)要考慮的另一個(gè)非常重要的指標(biāo)是檢查功能是否將用于重負(fù)載。這將檢查微服務(wù)是否必須在不久的將來(lái)擴(kuò)展盅弛。如果確實(shí)如此钱骂，那么將可擴(kuò)展位定義為微服務(wù)的范圍而不是將其與其他功能相結(jié)合是一個(gè)好主意。
2.高內(nèi)聚力與松耦合
任何微服務(wù)的主要?jiǎng)訖C(jī)是使服務(wù)彼此獨(dú)立挪鹏。這意味著可以編輯见秽，更新或部署新服務(wù)，而不會(huì)妨礙任何其他服務(wù)讨盒。如果相互依賴(lài)性很低解取，這是可能的。松散耦合的系統(tǒng)是一個(gè)服務(wù)對(duì)其他服務(wù)知之甚少或什么都不知道的系統(tǒng)返顺。
在將整體架構(gòu)分解為更小的服務(wù)或組件時(shí)禀苦，將類(lèi)似功能組合起來(lái)非常重要。將相關(guān)邏輯組合成單個(gè)單元是已知的內(nèi)聚遂鹊。內(nèi)聚力越高振乏，微服務(wù)架構(gòu)越好。較低的內(nèi)聚力表明不同服務(wù)之間的通信過(guò)多導(dǎo)致系統(tǒng)性能較差秉扑。
3.獨(dú)特的身份識(shí)別來(lái)源
遵循微服務(wù)設(shè)計(jì)的基本原則慧邮，任何服務(wù)都必須成為系統(tǒng)其余部分的唯一識(shí)別源。讓我們舉一個(gè)例子來(lái)理解這種情況舟陆。
在電子商務(wù)網(wǎng)站上下訂單后误澳，向用戶(hù)提供訂單ID。生成此訂單ID包含有關(guān)訂單的所有信息吨娜。作為微服務(wù)脓匿，訂單ID是有關(guān)訂單服務(wù)的任何信息的唯一來(lái)源。因此宦赠，如果任何其他服務(wù)尋求關(guān)于訂單服務(wù)的信息陪毡，則訂單ID充當(dāng)信息源而不是其實(shí)際屬性米母。
4. API集成
將整體設(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ù)和客戶(hù)端調(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è)客戶(hù)端在系統(tǒng)外部吏饿。這些客戶(hù)端可以是其他應(yīng)用程序或用戶(hù)踪危。無(wú)論何時(shí)調(diào)用業(yè)務(wù)邏輯，它都由適配器（消息網(wǎng)關(guān)或Web控制器）處理猪落，該適配器返回請(qǐng)求并對(duì)數(shù)據(jù)庫(kù)進(jìn)行更改贞远。
5.數(shù)據(jù)存儲(chǔ)隔離
為特定服務(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ù)耦合”非常重要∶弁伲基于用戶(hù)的數(shù)據(jù)分類(lèi)很重要杂曲，可以通過(guò)命令和查詢(xún)責(zé)任分離（CQRS）來(lái)實(shí)現(xiàn)。
6.交通管理
一旦設(shè)置了API并且系統(tǒng)啟動(dòng)并運(yùn)行袁余，不同服務(wù)的流量就會(huì)有所不同擎勘。流量是客戶(hù)端發(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í)例诈胜。
這也可以使用稱(chēng)為“自動(dòng)縮放”的過(guò)程來(lái)實(shí)現(xiàn)豹障，該過(guò)程包括在需要時(shí)通過(guò)快速動(dòng)作持續(xù)跟蹤服務(wù)。在某些情況下焦匈，“斷路器模式”對(duì)于提供在呼叫中斷或服務(wù)無(wú)響應(yīng)時(shí)可用的任何不完整信息非常重要血公。
7.自動(dòng)化流程
獨(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ā)展是非常重要的。
8.最小數(shù)據(jù)庫(kù)表（最好是隔離表）
訪問(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)鍵漓帚。
9.持續(xù)監(jiān)測(cè)
想象一下母债，將單片架構(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ù)架構(gòu)的局限性
雖然微服務(wù)是降低整體結(jié)構(gòu)的最佳方式。然而庄敛，它有其自身的一些缺點(diǎn)俗壹。但在得出任何結(jié)論之前，讓我們來(lái)看看其中的一些藻烤。
1.開(kāi)發(fā)環(huán)境超載
隨著應(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)力的重大延遲。
2. DevOps復(fù)雜性
單功能微服務(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)重要倾芝。
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)營(yíng)成本。
4.測(cè)試
測(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)致延遲莫瞬。
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ù)的開(kāi)銷(xiāo)尝哆。
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ú)立的容器或資源來(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)大的軟件秽晚。
擴(kuò)展閱讀
從 Spring Cloud 看一個(gè)微服務(wù)框架的「五臟六腑」
JavaEE架構(gòu)之傳統(tǒng)三層架構(gòu)，集群架構(gòu)筒愚，分布式架構(gòu)赴蝇，微服務(wù)架構(gòu)
基于 Spring Boot 和 Spring Cloud 實(shí)現(xiàn)微服務(wù)架構(gòu)
Java SSM框架相關(guān)基礎(chǔ)面試題整理
譯文：https://cloud.tencent.com/developer/article/1361549
原文：https://dzone.com/articles/9-fundamentals-to-a-successful-microservice-design
