為什么80%的碼農(nóng)都做不了架構(gòu)師？>>> ??

概述

微服務(wù)是一種架構(gòu)，其中的大型、復(fù)雜的軟件應(yīng)用程序由一個(gè)或多個(gè)更小的服務(wù)組成。每個(gè)微服務(wù)僅負(fù)責(zé)完成一項(xiàng)代表一種小業(yè)務(wù)能力的任務(wù)。這些微服務(wù)可使用任何編程語(yǔ)言開發(fā)。微服務(wù)是一種架構(gòu)，其中的大型、復(fù)雜的軟件應(yīng)用程序由一個(gè)或多個(gè)更小的服務(wù)組成。每個(gè)微服務(wù)僅負(fù)責(zé)完成一項(xiàng)代表一種小業(yè)務(wù)能力的任務(wù)。這些微服務(wù)可使用任何編程語(yǔ)言開發(fā)。

微服務(wù)架構(gòu)

微服務(wù)是相對(duì)較小的自主服務(wù)，它們合作完成工作。每個(gè)服務(wù)都實(shí)現(xiàn)一種業(yè)務(wù)需求。

微服務(wù)架構(gòu)是 Martin Fowler 和 James Lewis 定義的一種架構(gòu)風(fēng)格。他們將這種風(fēng)格描述為"一種使用小型服務(wù)構(gòu)建系統(tǒng)的架構(gòu)方法，每個(gè)服務(wù)都在自己的進(jìn)程中，它們通過輕量型協(xié)議進(jìn)行通信"。

每個(gè)服務(wù)都是相互獨(dú)立開發(fā)和部署的。每個(gè)微服務(wù)都專注執(zhí)行一個(gè)它所擅長(zhǎng)的相對(duì)較小的任務(wù)。

以下各節(jié)將重點(diǎn)介紹典型的微服務(wù)架構(gòu)的一些特征，讓您大體了解該架構(gòu)。

小型且專注于業(yè)務(wù)領(lǐng)域

小并不能充分描述微服務(wù)，使用這個(gè)詞只是為了嘗試表明微服務(wù)相對(duì)于整體式應(yīng)用程序的大小。在此上下文中，小的定義可能在各個(gè)系統(tǒng)中各不相同，而且沒有規(guī)則來定義服務(wù)必須有多小。

微服務(wù)通常負(fù)責(zé)一個(gè)精細(xì)的工作單元，所以它在規(guī)模上相對(duì)較小。一條著名的指導(dǎo)原則是"兩塊披薩的團(tuán)隊(duì)規(guī)模"方案，意思是說，如果兩塊披薩不能將整個(gè)團(tuán)隊(duì)喂飽，那么這個(gè)開發(fā)微服務(wù)的團(tuán)隊(duì)可能太大了。微服務(wù)必須足夠小，使得團(tuán)隊(duì)中的每個(gè)人都能理解該服務(wù)的整體設(shè)計(jì)和實(shí)現(xiàn)。另外，它的大小必須足以讓團(tuán)隊(duì)在必要時(shí)輕松地維護(hù)或重寫服務(wù)。

微服務(wù)的另一個(gè)重要特征是，每個(gè)服務(wù)專注負(fù)責(zé)一項(xiàng)精細(xì)的業(yè)務(wù)。Vaughn Vernon 在他撰寫的圖書《實(shí)現(xiàn)領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)》中定義了術(shù)語(yǔ)業(yè)務(wù)領(lǐng)域。他將業(yè)務(wù)領(lǐng)域定義為，"某個(gè)組織執(zhí)行的操作和它執(zhí)行操作的環(huán)境。"他還指定，"每個(gè)組織都有自己獨(dú)特的知識(shí)范圍和操作方式。這個(gè)理解范圍和它執(zhí)行操作的方法就是它的領(lǐng)域。"被分解為微服務(wù)的單元實(shí)際上就是領(lǐng)域內(nèi)的業(yè)務(wù)實(shí)體，這意味著每個(gè)微服務(wù)處理完成一個(gè)完整的業(yè)務(wù)任務(wù)。例如：Mortgage Services 是一個(gè)業(yè)務(wù)領(lǐng)域。Loan Origination 是該領(lǐng)域中一個(gè)可能的微服務(wù)。Loan Refinancing 可能是同一個(gè)領(lǐng)域中的另一個(gè)微服務(wù)。跨服務(wù)邊界的調(diào)用和更改通常很耗資源，必須避免。擁有這些服務(wù)的團(tuán)隊(duì)成為相應(yīng)業(yè)務(wù)領(lǐng)域或子領(lǐng)域的專家，而不是任意技術(shù)領(lǐng)域的專家。

與技術(shù)中立

開發(fā)微服務(wù)的團(tuán)隊(duì)必須使用他們熟悉的技術(shù)。不要規(guī)定開發(fā)團(tuán)隊(duì)?wèi)?yīng)該使用何種編程語(yǔ)言。讓開發(fā)人員自由選擇對(duì)任務(wù)最有意義的技術(shù)和執(zhí)行任務(wù)的人。這種工作方式能夠充分利用團(tuán)隊(duì)成員擁有的最佳技術(shù)和技能。微服務(wù)架構(gòu)仍需要技術(shù)決策；舉例而言，使用具象狀態(tài)傳輸 (REST) 應(yīng)用編程接口 (API) 訪問更好一些，還是使用某種類型的排隊(duì)來訪問更好一些？但是，一般而言，您可以為微服務(wù)架構(gòu)選擇廣泛范圍內(nèi)的任何技術(shù)。

松散耦合

松散耦合對(duì)基于微服務(wù)的系統(tǒng)至關(guān)重要。每個(gè)微服務(wù)都必須采用使其與其他服務(wù)的關(guān)聯(lián)很小的方式來設(shè)計(jì)接口。這樣，在更改一個(gè)服務(wù)并部署它時(shí)，就無(wú)需更改和重新部署系統(tǒng)的其他部分。

為了避免服務(wù)之間的耦合，必須了解導(dǎo)致緊密耦合的原因。緊密耦合的一個(gè)原因是通過 API 公開服務(wù)的內(nèi)部實(shí)現(xiàn)。這種公開方式將服務(wù)的使用者與它的內(nèi)部實(shí)現(xiàn)綁定在一起，從而導(dǎo)致更高的耦合度。在這種情況下，如果更改微服務(wù)的內(nèi)部架構(gòu)，可能還需要更改服務(wù)的使用者，否則就會(huì)破壞使用者。這可能會(huì)增加更改的成本，給實(shí)現(xiàn)更改帶來潛在隱患，進(jìn)而增加服務(wù)中的技術(shù)債務(wù)。必須避免任何導(dǎo)致公開服務(wù)的內(nèi)部實(shí)現(xiàn)的方法，以確保微服務(wù)之間松散耦合。

另一個(gè)錯(cuò)誤是讓服務(wù)的 API 太過精細(xì)。如果 API 太過精細(xì)，服務(wù)之間的調(diào)用可能變得太過頻繁，也就是說，會(huì)通過網(wǎng)絡(luò)執(zhí)行更多的調(diào)用。除了前綴的性能問題，過度頻繁的通信還可能造成緊密耦合。因此，設(shè)計(jì)服務(wù)接口的方式必須能夠最大限度地減少網(wǎng)絡(luò)中執(zhí)行的來回調(diào)用。

必須避免一個(gè)服務(wù)內(nèi)的實(shí)現(xiàn)過于分散，方法是將表示業(yè)務(wù)實(shí)體的相關(guān)屬性、行為放在盡可能相近的地方。將相關(guān)屬性放在一個(gè)微服務(wù)中；如果更改某個(gè)屬性或行為，可以在一個(gè)位置更改它并快速部署該更改。否則，必須在不同部分中執(zhí)行更改，然后同時(shí)一起部署這些散亂的部分；這會(huì)導(dǎo)致這些部門之間緊密耦合。

每個(gè)微服務(wù)必須有自己的源代碼管理存儲(chǔ)，以及用于構(gòu)建和部署的交付管道。這樣即可在必要時(shí)部署每個(gè)服務(wù)，而不需要與其他服務(wù)的所有者進(jìn)行協(xié)調(diào)。如果您有兩個(gè)服務(wù)，而且始終在一次部署中一起發(fā)布這兩個(gè)服務(wù)，這可能表明兩個(gè)服務(wù)最好合并為一個(gè)服務(wù)，而且必須對(duì)當(dāng)前服務(wù)執(zhí)行更多分解工作。松散耦合還支持更頻繁、更快速的部署，最終提高應(yīng)用程序?qū)ζ溆脩粜枨蟮捻憫?yīng)能力。

容易觀察

微服務(wù)架構(gòu)要求您能夠可視化系統(tǒng)中所有服務(wù)的健康狀態(tài)，以及它們之間的連接。這使您能快速找到并響應(yīng)可能發(fā)生的問題。實(shí)現(xiàn)可視化的工具包含一種全面的日志機(jī)制，能夠記錄日志，存儲(chǔ)日志，并使日志容易搜索，以便執(zhí)行更有效的分析。

向系統(tǒng)中配置和添加的新服務(wù)越多，讓這些服務(wù)變得可觀察就會(huì)越難。因?yàn)樵谔砑痈鄤?dòng)態(tài)部分時(shí)，微服務(wù)架構(gòu)會(huì)增加復(fù)雜性，所以觀察設(shè)計(jì)必須明確，使可視化的日志和監(jiān)視數(shù)據(jù)能為分析提供有幫助的信息。

自動(dòng)化

自動(dòng)化是有效設(shè)計(jì)和實(shí)現(xiàn)軟件應(yīng)用程序的一個(gè)重要要求。對(duì)于微服務(wù)，自動(dòng)化是一個(gè)至關(guān)重要但又充滿挑戰(zhàn)的任務(wù)。除了需要在生產(chǎn)中運(yùn)行系統(tǒng)之外，微服務(wù)架構(gòu)還向系統(tǒng)的實(shí)現(xiàn)引入了更多復(fù)雜性。在處理的機(jī)器和組件數(shù)量較少時(shí)，可能可以接受手動(dòng)配置機(jī)器，安裝中間件，部署組件，或者手動(dòng)登錄到服務(wù)器并收集日志，以及執(zhí)行其他手動(dòng)任務(wù)。但是，當(dāng)組件數(shù)量增加時(shí)，在某個(gè)時(shí)刻后，您可能無(wú)法使用手動(dòng)方法。

自動(dòng)化可幫助組建一個(gè)服務(wù)器并安裝必要的運(yùn)行時(shí)環(huán)境。然后，只需使用幾行代碼，就能快速將微服務(wù)放在這些運(yùn)行時(shí)環(huán)境上。這種自動(dòng)化使您能編寫微結(jié)構(gòu)代碼，訪問用于部署生產(chǎn)服務(wù)的準(zhǔn)確的工具鏈，從而及早發(fā)現(xiàn)問題。自動(dòng)化是連續(xù)集成和連續(xù)交付方法的核心推動(dòng)力量。如果您想將微服務(wù)架構(gòu)的復(fù)雜性保持在控制范圍內(nèi)，推崇自動(dòng)化文化是關(guān)鍵。為此，您需要一種綜合的、端到端的方法，以便在整個(gè)軟件開發(fā)生命周期中推廣自動(dòng)化。這個(gè)生命周期涉及通過一些操作執(zhí)行測(cè)試驅(qū)動(dòng)開發(fā)，比如 IBM Bluemix? Garage Method。

有界上下文

開發(fā)模型時(shí)，請(qǐng)記住識(shí)別它的有界上下文，即模型的有效范圍。有界上下文是具有明確邊界的模型，模型在該邊界內(nèi)是沒有歧義的。如果您不在模型周圍設(shè)置一條邊界，最終使用的上下文可能不在您的應(yīng)用程序內(nèi)。適合應(yīng)用程序的某個(gè)部分的上下文不得適合另一個(gè)部分，即使它們具有相同的名稱，而且指向相同的實(shí)體。例如，如果您構(gòu)建一個(gè)預(yù)約系統(tǒng)，則必須知道客戶的基本信息。但是，如果您在賬單上下文中有一個(gè)賬單系統(tǒng)，您可能希望在其中包含客戶的聯(lián)系信息和支付信息，而在預(yù)約系統(tǒng)上下文中，不需要該信息。如果您嘗試在多個(gè)地方重用完全相同的客戶模型，可能會(huì)在系統(tǒng)中導(dǎo)致不一致的行為。這是一個(gè)放入預(yù)約系統(tǒng)的上下文中的簡(jiǎn)單模型，包含一些除客戶名稱外的行為。

例如，您可能決定在客戶模型上包含某種形式的驗(yàn)證，以確保擁有足夠的信息來向他們收賬。如果您不夠小心，驗(yàn)證可能意外地阻止您使用客戶模型安排預(yù)約；這不是那您想要的行為。賬單系統(tǒng)可能要求客戶擁有有效的信用卡，然后才能保存更改。但是，如果缺少信用卡信息，則會(huì)阻止您將客戶預(yù)約信息保存到預(yù)約系統(tǒng)中，這是不合理的。

在這個(gè)示例中，您有兩個(gè)上下文，但它們之間的邊界是模糊和重疊的。Eric Evans 在他撰寫的圖書《領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)》中說道"模型僅在特定的上下文內(nèi)有效。因此，最好顯式定義應(yīng)用該模型的上下文。您可以避免損壞該上下文內(nèi)的模型，將它嚴(yán)格保持在這些邊界內(nèi)，并避免被外部問題分心或混淆。"

當(dāng)顯示定義了有界上下文后，通常能看到您是否擁有一個(gè)嘗試擴(kuò)展到多個(gè)上下文中的模型元素。在這個(gè)示例中，您希望在預(yù)約系統(tǒng)中保持簡(jiǎn)單的客戶視圖，而在賬單上下文中提供包含聯(lián)系信息和賬單信息的更完整的客戶視圖版本。在兩個(gè)不同的類中定義客戶的這兩個(gè)視圖，然后將它們放在不同的應(yīng)用程序中。Eric Evans 建議，通過為每個(gè)上下文提供它們自己的團(tuán)隊(duì)、代碼庫(kù)、數(shù)據(jù)庫(kù)模式和交付管道，讓有界上下文保持分離。

有界上下文的原則在微服務(wù)架構(gòu)中至關(guān)重要。可使用這些原則作為指導(dǎo)，正確地確定系統(tǒng)并將其分解為微服務(wù)。明確定義有界上下文（意味著業(yè)務(wù)領(lǐng)域是通過顯式邊界分離的），有助于推斷系統(tǒng)中最終包含的微服務(wù)。擁有有界上下文，還有助于正式化不同服務(wù)之間的交互，有效且高效地構(gòu)建它們之間的接口。

采用微服務(wù)架構(gòu)的原因

本節(jié)將介紹采用微服務(wù)架構(gòu)的一些主要原因。微服務(wù)架構(gòu)是產(chǎn)品或服務(wù)所有者跟上或超越 IT 行業(yè)的快速發(fā)展節(jié)奏的推動(dòng)因素之一。

現(xiàn)有整體式應(yīng)用程序面臨的挑戰(zhàn)

在整體式應(yīng)用程序中，大部分邏輯都部署在一個(gè)集中化、單一的運(yùn)行時(shí)環(huán)境或服務(wù)器中，并在其中運(yùn)行。整體式應(yīng)用程序通常很大，由一個(gè)大型團(tuán)隊(duì)或多個(gè)團(tuán)隊(duì)構(gòu)建。采用此方法，各個(gè)團(tuán)隊(duì)需要花更多精力和統(tǒng)籌安排才能執(zhí)行更改或部署。

隨著時(shí)間的推移，整體式模型中已引入了更好的架構(gòu)模式，有助于顯著提高架構(gòu)的靈活性。例如，一種著名的模式是模型-視圖-控制器 (MVC)，它將應(yīng)用程序分解為層和合理的組件。這些模式有多種優(yōu)點(diǎn)，比如更快的初始開發(fā)、更簡(jiǎn)單的應(yīng)用程序治理，等等。但是，整體式模型也有缺點(diǎn)，尤其是在當(dāng)今環(huán)境中的技術(shù)瞬息萬(wàn)變的背景下。

整體式方法可能帶來許多挑戰(zhàn)，有以下四點(diǎn)：

龐大的應(yīng)用程序代碼庫(kù)

龐大的代碼庫(kù)可能給希望熟悉代碼的開發(fā)人員帶來困擾，尤其是團(tuán)隊(duì)的新成員。龐大的應(yīng)用程序代碼庫(kù)可能還會(huì)讓應(yīng)用程序開發(fā)過程中使用的開發(fā)環(huán)境工具和運(yùn)行時(shí)容器不堪重負(fù)。最終，這會(huì)導(dǎo)致開發(fā)人員效率降低，可能會(huì)阻止對(duì)執(zhí)行更改的嘗試。

不頻繁的更新

在典型的整體式應(yīng)用程序中，大部分（幾乎是全部）邏輯組件都部署在單一運(yùn)行時(shí)容器中，并在其中運(yùn)行。這意味著要更新對(duì)某個(gè)組件的一處細(xì)微更改，必須重新部署整個(gè)應(yīng)用程序。另外，如果需要推廣細(xì)微但關(guān)鍵的應(yīng)用程序更改，則需要投入大量精力來對(duì)未更改的部分運(yùn)行回歸測(cè)試。這些挑戰(zhàn)意味著整體式應(yīng)用程序很難連續(xù)交付，這導(dǎo)致部署次數(shù)減少，對(duì)需要的更改的響應(yīng)變慢。

依賴單一類型的技術(shù)

對(duì)于整體式模型，由于應(yīng)用更改方面的挑戰(zhàn)，以增量方式采用新技術(shù)或技術(shù)棧開發(fā)框架的新版本會(huì)變得很困難。最終，整體式架構(gòu)應(yīng)用程序通常必須一直使用這一種技術(shù)，這最終會(huì)阻礙應(yīng)用程序跟上新的發(fā)展趨勢(shì)。

可擴(kuò)展性

可擴(kuò)展性是整體式架構(gòu)面臨的最大挑戰(zhàn)之一。Martin Abbot 和 Michael Fisher 在他們合著圖書《可擴(kuò)展的藝術(shù)》中介紹了一種查看系統(tǒng)的可擴(kuò)展性的有用方式；他們使用了一種三維可擴(kuò)展性模型或擴(kuò)展立方體。在此模型中，通過在負(fù)載平衡器后運(yùn)行克隆版本來擴(kuò)展應(yīng)用程序稱為 X 軸擴(kuò)展或水平復(fù)制。另外兩種擴(kuò)展是 Y 軸擴(kuò)展（或功能分解）和 Z 軸擴(kuò)展（或數(shù)據(jù)分割），Y 軸擴(kuò)展通過拆分不同實(shí)體來實(shí)現(xiàn)擴(kuò)展，Z 軸擴(kuò)展通過拆分類似實(shí)體來實(shí)現(xiàn)擴(kuò)展。由于整體上的凝聚性，典型的整體式應(yīng)用程序通常只能在擴(kuò)展立方體的一個(gè)維度上擴(kuò)展。隨著生產(chǎn)環(huán)境收到更多請(qǐng)求，該應(yīng)用程序通常采用的垂直擴(kuò)展方式是添加更多資源供其使用，或者克隆到多個(gè)副本來進(jìn)行響應(yīng)。這種擴(kuò)展方式低效且很耗資源。

當(dāng)應(yīng)用程序達(dá)到一定規(guī)模時(shí)，開發(fā)團(tuán)隊(duì)必須拆分為更小的團(tuán)隊(duì)，每個(gè)小團(tuán)隊(duì)專注于一個(gè)特定的功能區(qū)域，各團(tuán)隊(duì)彼此獨(dú)立工作，而且通常位于不同地理位置。但是，由于應(yīng)用程序的各部分間的自然凝聚性，需要各個(gè)團(tuán)隊(duì)協(xié)力執(zhí)行更改和重新部署。圖 1 顯示了擴(kuò)展立方體。

圖 1. 擴(kuò)展立方體

適用于各種涉眾的微服務(wù)

使用微服務(wù)架構(gòu)的最重要目的是，解決整體式模型面臨的難題。本節(jié)將從應(yīng)用程序的不同涉眾角度，介紹微服務(wù)方法如何幫助解決整體式系統(tǒng)的問題。

對(duì)于業(yè)務(wù)所有者

作為業(yè)務(wù)所有者，您希望您的服務(wù)適用于新客戶和業(yè)務(wù)需求。但是，在整體式模型中，由于龐大的代碼庫(kù)，為滿足業(yè)務(wù)需求而執(zhí)行并推廣更改的過程會(huì)很緩慢。這個(gè)過程緩慢的另一個(gè)原因是，各個(gè)組件和層之間有嚴(yán)格的內(nèi)部限制和依賴關(guān)系。

微服務(wù)架構(gòu)原則是圍繞高靈活性和恢復(fù)能力而建立的。這兩個(gè)特征有助于快速推廣更改。這有助于業(yè)務(wù)所有者更快地收到反饋，調(diào)整業(yè)務(wù)和投資戰(zhàn)略，從而讓客戶滿意和提高市場(chǎng)競(jìng)爭(zhēng)力。

從資源分配的角度講，由于團(tuán)隊(duì)更小且更專注，所以可以更輕松地測(cè)量和可視化效率。然后，業(yè)務(wù)所有者可以更輕松地制定投資決策，可將資源從低業(yè)務(wù)影響區(qū)域轉(zhuǎn)移到高業(yè)務(wù)影響區(qū)域。

對(duì)于服務(wù)管理人員

作為服務(wù)管理團(tuán)隊(duì)成員，您希望協(xié)調(diào)各個(gè)團(tuán)隊(duì)的管理操作負(fù)擔(dān)更少，以便您可以提高服務(wù)的生產(chǎn)力。整體式模型需要做大量的工作。活動(dòng)之間需要的協(xié)調(diào)更多，因?yàn)檎w式應(yīng)用程序通常擁有龐大的業(yè)務(wù)范圍，以及許多基礎(chǔ)架構(gòu)和操作接觸點(diǎn)。因此，對(duì)應(yīng)用程序的每次更改都可能需要不同涉眾多次評(píng)審和批準(zhǔn)。微服務(wù)架構(gòu)推崇利用自助服務(wù)，在服務(wù)交付管道的每個(gè)階段利用自動(dòng)化。

這有助于減少服務(wù)管理團(tuán)隊(duì)的日常管理協(xié)調(diào)。

微服務(wù)架構(gòu)中的一個(gè)重要原則是高可觀察性。高可觀察性功能為服務(wù)管理團(tuán)隊(duì)提供了必要的工具，以便更好地監(jiān)督系統(tǒng)中或產(chǎn)品中的每個(gè)微服務(wù)的狀態(tài)。這有助于提高服務(wù)管理效率。

對(duì)于開發(fā)人員

作為加入團(tuán)隊(duì)的新開發(fā)人員，您希望快速熟悉源代碼，以便快速上手并帶來成果。典型整體式應(yīng)用程序中的代碼庫(kù)很大，可能阻礙您并潛在地延長(zhǎng)學(xué)習(xí)曲線。對(duì)于所有開發(fā)人員，龐大的代碼庫(kù)會(huì)增加載入開發(fā)環(huán)境中并運(yùn)行的負(fù)擔(dān)，從而導(dǎo)致生產(chǎn)力降低。

龐大的代碼庫(kù)可能讓代碼評(píng)審和其他合作開發(fā)活動(dòng)面臨更大壓力。此外，在處理更改時(shí)，破壞其他功能的風(fēng)險(xiǎn)可能導(dǎo)致開發(fā)人員對(duì)創(chuàng)新和增強(qiáng)應(yīng)用程序猶豫不決。然而，微服務(wù)更小且更輕量，這可以縮短新開發(fā)人員的學(xué)習(xí)曲線。微服務(wù)還可以幫助消除加載和運(yùn)行的繁重負(fù)擔(dān)，鼓勵(lì)引入突破性的更改，從而幫助提高生產(chǎn)力和創(chuàng)新水平。

從整體式應(yīng)用程序向微服務(wù)轉(zhuǎn)變

虛構(gòu)公司A的業(yè)務(wù)問題

虛構(gòu)公司 A 是一家電子商務(wù)公司，它使用了一個(gè)名為 Customer Order Service 的基于 Java EE 的傳統(tǒng) Web 應(yīng)用程序來提供在線購(gòu)買服務(wù)和運(yùn)營(yíng)業(yè)務(wù)。盡管該應(yīng)用程序能很好地處理業(yè)務(wù)，但公司 A 已開始努力響應(yīng)新的業(yè)務(wù)需求。這些需求包括：

• 接觸使用移動(dòng)設(shè)備的客戶
• 基于對(duì)客戶在互聯(lián)網(wǎng)上的個(gè)人行為的洞察，改善客戶體驗(yàn)
• 擴(kuò)展基礎(chǔ)架構(gòu)，以便處理來自新客戶和現(xiàn)有客戶的更多請(qǐng)求保持較低的 IT 成本
• 以及其他需求

目前的客戶訂購(gòu)服務(wù)應(yīng)用程序的設(shè)計(jì)不支持在業(yè)務(wù)領(lǐng)域中執(zhí)行更改，而且無(wú)法應(yīng)用新技術(shù)來加速創(chuàng)新。圖 3 介紹了當(dāng)前的整體式應(yīng)用程序的邏輯架構(gòu)概述。

圖 3. 當(dāng)前的整體式應(yīng)用程序

公司 A 希望改變客戶訂單服務(wù)應(yīng)用程序，以便從業(yè)務(wù)和技術(shù)角度促進(jìn)和更好地處理更改，它擁有一些主要的業(yè)務(wù)需求：

• 新系統(tǒng)必須是經(jīng)過進(jìn)化的，意味著它必須能靈活地處理更改。
• 在將流量從當(dāng)前系統(tǒng)轉(zhuǎn)移到新構(gòu)建的系統(tǒng)的過程中，不允許宕機(jī)。
• 新應(yīng)用程序必須能基于發(fā)送給系統(tǒng)的有效負(fù)載來按需或自動(dòng)擴(kuò)展，以便應(yīng)對(duì)動(dòng)態(tài)的購(gòu)物行為模式。
• 新系統(tǒng)必須支持利用新興技術(shù)來促進(jìn)創(chuàng)新。

采用微服務(wù)來實(shí)現(xiàn)一種革命性的架構(gòu)

采用微服務(wù)架構(gòu)的主要?jiǎng)訖C(jī)是，解決很難更改的傳統(tǒng)整體式架構(gòu)的問題。微服務(wù)方法支持對(duì)架構(gòu)的每個(gè)組成部分執(zhí)行更改。對(duì)于業(yè)務(wù)需求，公司 A 非常適合在構(gòu)建新系統(tǒng)時(shí)采用微服務(wù)架構(gòu)。

公司 A 應(yīng)用最佳實(shí)踐和模式將現(xiàn)有的整體式應(yīng)用程序轉(zhuǎn)變?yōu)楦痈锩缘募軜?gòu)，以期最終將應(yīng)用程序遷移到微服務(wù)架構(gòu)上。

執(zhí)行以下主要步驟和活動(dòng)：

演化戰(zhàn)略

要擁有一種轉(zhuǎn)型案例分析中的整體式應(yīng)用程序的合適戰(zhàn)略，必須發(fā)現(xiàn)和考慮不同的模式和建議實(shí)踐。

識(shí)別要轉(zhuǎn)變?yōu)槲⒎?wù)的候選功能

在這一步中，選擇應(yīng)用程序的相對(duì)較小的組件或功能片段。從這些功能片段，可配置新微服務(wù)來讓這些片段更有利于經(jīng)常或漸進(jìn)式的更改。

數(shù)據(jù)訪問模式

因?yàn)閿?shù)據(jù)是 IT 系統(tǒng)中最重要的資產(chǎn)，所以一個(gè)關(guān)鍵步驟是在轉(zhuǎn)變?yōu)槲⒎?wù)架構(gòu)的過程中采取正確的數(shù)據(jù)訪問方法。

安全和治理

"安全和治理"將介紹如何在更加分布式的新模型中管理應(yīng)用程序的組件，以及如何處理安全挑戰(zhàn)。

性能和可擴(kuò)展性

解決整體式應(yīng)用程序的可擴(kuò)展性問題時(shí)，微服務(wù)架構(gòu)（擁有更多分布式特征）帶來了性能挑戰(zhàn)。

DevOps 和自動(dòng)化

自動(dòng)化是讓微服務(wù)方法成為可能的推動(dòng)因素。

?

轉(zhuǎn)載于:https://my.oschina.net/feinik/blog/862704

總結(jié)

以上是生活随笔為你收集整理的微服务的正确理解方式的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。