https://www.infoq.cn/article/31IdBpWgTQZU7e5-uwh1

核心要點(diǎn)

• 從一個(gè)易于抽取的小候選功能開(kāi)始，以便于盡早獲得微服務(wù)的體驗(yàn)；
• 要預(yù)先重點(diǎn)關(guān)注構(gòu)建和部署自動(dòng)化以及監(jiān)控；
• 盡早處理橫切性的關(guān)注點(diǎn)，避免給生產(chǎn)效率帶來(lái)負(fù)面的影響，比如為單體應(yīng)用繼續(xù)增加功能或者為每個(gè)微服務(wù)重新實(shí)現(xiàn)橫切性的關(guān)注點(diǎn)；
• 將系統(tǒng)的事件驅(qū)動(dòng)功能設(shè)計(jì)得易于演化，考慮采用事件流的方案以減少數(shù)據(jù)副本的成本并降低添加新微服務(wù)的門(mén)檻；
• 需要注意，轉(zhuǎn)換至微服務(wù)的過(guò)程并不是獨(dú)立運(yùn)轉(zhuǎn)的。相反，它受到很多環(huán)境因素的影響。當(dāng)心那些阻礙你前進(jìn)或拖你后腿的環(huán)境因素，對(duì)它們進(jìn)行相應(yīng)的調(diào)整，或者至少要在整個(gè)組織中意識(shí)到這些問(wèn)題。

在開(kāi)展微服務(wù)的過(guò)程中，了解要考慮哪些因素可能是非常有挑戰(zhàn)性的事情，對(duì)于小團(tuán)隊(duì)來(lái)講更是如此。遺憾的是，沒(méi)有可以直接使用的金科玉律。每個(gè)過(guò)程都是不同的，因?yàn)槊總€(gè)組織面臨的都是不同的環(huán)境。在本文中，我將從初創(chuàng)公司的角度分享我們學(xué)習(xí)到的經(jīng)驗(yàn)和面臨的挑戰(zhàn)，以及我下次引入微服務(wù)時(shí)，會(huì)在哪些方面采取不同的做法。

從單體應(yīng)用到微服務(wù)的旅程該如何開(kāi)始？

最初，從各個(gè)方面看，我都是從單體應(yīng)用開(kāi)始的：我們整個(gè)團(tuán)隊(duì)基于一個(gè)相互協(xié)作的產(chǎn)品開(kāi)展工作，將其實(shí)現(xiàn)為同一個(gè)代碼庫(kù)并且基于同一個(gè)技術(shù)棧。在一段時(shí)間內(nèi)，這種方式能夠很好地運(yùn)轉(zhuǎn)。

隨著時(shí)間的推移，所有的事情都在演化：團(tuán)隊(duì)在增長(zhǎng)，我們?yōu)楫a(chǎn)品不斷添加越來(lái)越多的特性，代碼庫(kù)變得越來(lái)越大，用戶(hù)的數(shù)量也在不斷增長(zhǎng)。這聽(tīng)起來(lái)非常不錯(cuò)，對(duì)吧？但是……

現(xiàn)在，要完成一件事情需要非常長(zhǎng)的時(shí)間：會(huì)議、討論和決策都要比以往消耗更長(zhǎng)的時(shí)間。職責(zé)無(wú)法清晰地劃分，明確具體責(zé)任需要花費(fèi)一定的時(shí)間，比如當(dāng)出現(xiàn)了 bug 的時(shí)候。我們的過(guò)程變得更加緩慢，生產(chǎn)效率也受到了影響。

我們添加的特性越多，產(chǎn)品使用起來(lái)就越復(fù)雜。產(chǎn)品的可用性和用戶(hù)體驗(yàn)因?yàn)椴粩嗟奶匦孕薷亩軗p。我們不但沒(méi)有很好地解決用戶(hù)的問(wèn)題，反而讓他們更加困惑。

因?yàn)椴捎脝误w軟件架構(gòu)，我們很難在不影響整個(gè)系統(tǒng)的情況下添加新的特性，釋放新的變更也變得非常復(fù)雜，即便我們只修改了幾行代碼，也需要重新構(gòu)建和部署整個(gè)產(chǎn)品。這導(dǎo)致部署會(huì)具有很高的風(fēng)險(xiǎn)性，因此部署的頻率也不那么頻繁，因?yàn)樾绿匦缘陌l(fā)布非常緩慢。

因此，對(duì)系統(tǒng)進(jìn)行分離和轉(zhuǎn)換的需求就出現(xiàn)了。

在三年前，我們改變了產(chǎn)品策略。我們關(guān)注可用性和用戶(hù)體驗(yàn)的提升并將我們的產(chǎn)品 JUST SOCIAL 拆分成了多個(gè)獨(dú)立的應(yīng)用，其中每個(gè)應(yīng)用負(fù)責(zé)特定的場(chǎng)景。我們不斷演化這個(gè)理念，提供不同的應(yīng)用來(lái)共享文檔、實(shí)時(shí)交流、管理任務(wù)、共享可編輯的內(nèi)容和協(xié)作的新聞以及管理 profile。

同時(shí)，我們將整個(gè)團(tuán)隊(duì)拆分成了多個(gè)更小的團(tuán)隊(duì)，并為每個(gè)團(tuán)隊(duì)分派了特定的一組協(xié)作應(yīng)用（collaboration app），從而實(shí)現(xiàn)定義了良好的職責(zé)劃分。我們想要建立自治化的團(tuán)隊(duì)，能夠讓他們按照自己的節(jié)奏獨(dú)立地圍繞系統(tǒng)不同的組成部分開(kāi)展工作，將跨團(tuán)隊(duì)的影響降低到最小。

在將我們的產(chǎn)品拆分為多個(gè)獨(dú)立的協(xié)作應(yīng)用并將團(tuán)隊(duì)分為多個(gè)更小的團(tuán)隊(duì)之后，接下來(lái)順理成章的步驟就是將自治性和靈活性反映到軟件架構(gòu)中，這是通過(guò)引入微服務(wù)實(shí)現(xiàn)的。

我們引入微服務(wù)的驅(qū)動(dòng)力在于讓系統(tǒng)的不同組成部分能夠?qū)崿F(xiàn)自治，讓他們按照自己獨(dú)立的節(jié)奏開(kāi)展工作，將跨團(tuán)隊(duì)的影響降到最低。通過(guò)獨(dú)立地開(kāi)發(fā)、部署和擴(kuò)展協(xié)同應(yīng)用，我們希望能夠快速地發(fā)布變更。

我們的微服務(wù)之旅首先是從識(shí)別適合采取微服務(wù)的候選功能開(kāi)始的。為了識(shí)別合適的候選功能，我們必須要考慮如何建模良好服務(wù)的核心概念。核心概念遵循服務(wù)間松耦合和服務(wù)內(nèi)高內(nèi)聚的原則。服務(wù)內(nèi)的高內(nèi)聚通常反映在保持相關(guān)行為的一致性方面。在領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)中，相關(guān)行為反應(yīng)為限界上下文（Bounded Context）。限界上下文是領(lǐng)域模型中的語(yǔ)義邊界，服務(wù)會(huì)負(fù)責(zé)定義良好的一個(gè)業(yè)務(wù)功能，限界上下文會(huì)對(duì)服務(wù)進(jìn)行描述。

在我們的場(chǎng)景中，我們使用協(xié)作應(yīng)用作為高層級(jí)的限界上下文，它反映了粗粒度的服務(wù)邊界。這是一個(gè)很好的起點(diǎn)，后續(xù)我們會(huì)將它們拆分為更加細(xì)粒度的服務(wù)層。

我們首先從 JUST DRIVE 的限界上下文開(kāi)始，也就是負(fù)責(zé)文檔管理的協(xié)作應(yīng)用。每個(gè)文檔都是由作者創(chuàng)建的。作者相關(guān)的數(shù)據(jù)來(lái)自 profile，而后者又是由 profile 管理的限界上下文來(lái)進(jìn)行管理的，這個(gè)功能依然位于單體應(yīng)用中。

我們從頭構(gòu)建了一個(gè)共存（co-existing）的服務(wù)。它實(shí)際上并不完全與當(dāng)前功能的相同，相反，我們引入了新的 UI、添加了更多的特性并將數(shù)據(jù)結(jié)構(gòu)做了重大的變更。新服務(wù)的限界上下文包括負(fù)責(zé)業(yè)務(wù)邏輯的領(lǐng)域模型、編排用例的和管理事務(wù)的應(yīng)用服務(wù)以及輸入輸出的適配器，比如 REST 端點(diǎn)和用于持久化管理的適配器。新服務(wù)會(huì)獨(dú)占文檔狀態(tài)，也就是說(shuō)，它是唯一能夠讀取和寫(xiě)入文檔的服務(wù)。

如前文所述，每個(gè)文檔都是由作者創(chuàng)建的，作者的數(shù)據(jù)來(lái)源于單體應(yīng)用所管理的 profile 數(shù)據(jù)。

那么問(wèn)題就來(lái)了，新服務(wù)和單體應(yīng)用之間該如何交互呢？

為了避免每次展現(xiàn)文檔的時(shí)候都從 profile 服務(wù)中獲取作者數(shù)據(jù)，我們?cè)谛碌姆?wù)中保留了相關(guān)作者數(shù)據(jù)的一個(gè)本地副本。只要不破壞數(shù)據(jù)的所有權(quán)，數(shù)據(jù)冗余是沒(méi)有問(wèn)題的，在我們這個(gè)場(chǎng)景中，只要 profile 相關(guān)的限界上下文依然獨(dú)占 profile 狀態(tài)即可。

由于本地副本和原始的數(shù)據(jù)會(huì)隨著時(shí)間的推移而產(chǎn)生差異，所以單體應(yīng)用需要在 profile 更新的時(shí)候通知我們。在 profile 發(fā)生變化的時(shí)候，單體應(yīng)用會(huì)發(fā)布一個(gè) ProfileUpdatedEvent 事件，新服務(wù)需要訂閱這個(gè)事件。新服務(wù)消費(fèi)該事件并相應(yīng)地更新本地副本。

這種事件驅(qū)動(dòng)的服務(wù)集成方式降低了服務(wù)之間的耦合，因?yàn)槲覀儸F(xiàn)在不需要跨上下文遠(yuǎn)程直接查詢(xún)單體應(yīng)用了。這種方式增加了自治性，新服務(wù)能夠?qū)Ρ镜馗北咀鋈魏问虑?#xff0c;而且能夠讓數(shù)據(jù)連接（join）更加高效，因?yàn)樗梢允褂帽镜馗北具B接作者數(shù)據(jù)，無(wú)需通過(guò)網(wǎng)絡(luò)。

我們從頭構(gòu)建了一個(gè)共存的服務(wù)，并且為了實(shí)現(xiàn)數(shù)據(jù)復(fù)制的目的，引入了事件驅(qū)動(dòng)形式的服務(wù)交互。

我們遇到了什么挑戰(zhàn)以及是如何解決的

從頭開(kāi)始構(gòu)建共存的服務(wù)通常是一種很好的分解策略，當(dāng)你想要擺脫某些東西的束縛時(shí)，更是如此，比如想要脫離過(guò)時(shí)的業(yè)務(wù)邏輯或者現(xiàn)有的技術(shù)棧。但是在解耦第一個(gè)服務(wù)的時(shí)候，我們一次性做了太多的事情。如前文所述，我們不僅從頭構(gòu)建了一個(gè)共存的服務(wù)，還引入了新的 UI、添加了更多的特性，還對(duì)數(shù)據(jù)結(jié)構(gòu)做了重大的變更。在開(kāi)始的時(shí)候，我們承擔(dān)了太多的責(zé)任，所以在很晚的時(shí)候才看到結(jié)果。但是，在開(kāi)始階段，快速得到結(jié)果以獲取使用微服務(wù)的經(jīng)驗(yàn)和信心是非常重要的。

在下一個(gè)備選服務(wù)中，我們采取了不同的方式。我們關(guān)注 chat 應(yīng)用的高層級(jí)限界上下文，并遵循自上而下的漸進(jìn)式分解策略，逐步抽取已有的代碼。我們首先將 UI 抽取為單獨(dú)的 Web 應(yīng)用，并在單體應(yīng)用側(cè)引入了 REST-API，這樣被抽取出來(lái) Web 應(yīng)用可以訪(fǎng)問(wèn)該 API。在這一步，我們可以獨(dú)立地開(kāi)發(fā)和部署 Web 應(yīng)用，從而能夠?qū)?UI 進(jìn)行快速迭代。

在抽取完 UI 之后，我們就可以更進(jìn)一步，解耦業(yè)務(wù)邏輯。分解業(yè)務(wù)邏輯會(huì)對(duì)代碼帶來(lái)重大的變更。根據(jù)依賴(lài)關(guān)系，我們可能需要提供一個(gè)臨時(shí)的 REST API 供單體應(yīng)用使用，以解決業(yè)務(wù)邏輯抽取后所帶來(lái)的問(wèn)題。此時(shí)，我們依然共享相同的數(shù)據(jù)存儲(chǔ)。

為了實(shí)現(xiàn)非耦合的獨(dú)立服務(wù)，我們最終需要切分?jǐn)?shù)據(jù)存儲(chǔ)，以確保新服務(wù)能夠獨(dú)占 chat 的狀態(tài)。

在每個(gè) chat 討論中，都會(huì)涉及到參與者。chat 參與者的數(shù)據(jù)來(lái)源于單體應(yīng)用中的 profile 數(shù)據(jù)。如前面描述的 DRIVE 樣例類(lèi)似，我們保存一個(gè) chat 參與者數(shù)據(jù)的本地副本，并訂閱 ProfileUpdatedEvent 事件，從而讓本地副本數(shù)據(jù)與單體應(yīng)用中原始數(shù)據(jù)的保持同步。

從此處開(kāi)始，我們就可以繼續(xù)從單體應(yīng)用中抽取下一個(gè)限界上下文，或者將我們的粗粒度服務(wù)隨后拆分為更細(xì)粒度的服務(wù)。

另外一項(xiàng)挑戰(zhàn)是對(duì)授權(quán)的處理

幾乎對(duì)于每個(gè)服務(wù)，我們都會(huì)面臨如何授權(quán)的問(wèn)題。我為你描述一個(gè)背景：授權(quán)處理是非常細(xì)粒度的，一直向下延伸到領(lǐng)域?qū)ο蠹?jí)別。每個(gè)協(xié)作應(yīng)用都要控制其領(lǐng)域?qū)ο蟮臋?quán)限，比如文檔的權(quán)限是由該文檔所在的父文件夾的授權(quán)設(shè)置來(lái)控制的。

另一方面，授權(quán)不僅僅是細(xì)粒度的，還依賴(lài)于服務(wù)之間的交互，在某些場(chǎng)景下，領(lǐng)域?qū)ο蟮氖跈?quán)還依賴(lài)于父領(lǐng)域?qū)ο蟮氖跈?quán)信息，而父領(lǐng)域?qū)ο蟮氖跈?quán)信息是位于其他服務(wù)中的，比如，要讀取某個(gè)內(nèi)容頁(yè)相關(guān)的文檔或者為內(nèi)容頁(yè)添加文檔的話(huà)，需要依賴(lài)于這個(gè)頁(yè)面的授權(quán)設(shè)置，而這個(gè)頁(yè)面的授權(quán)配置位于與文檔本身不同的服務(wù)中。

因?yàn)檫@些復(fù)雜的需求，解決分布式授權(quán)的問(wèn)題給我們帶來(lái)了很大的困擾，而且我們沒(méi)有在早期提供解決方案。這樣帶來(lái)的結(jié)果完全適得其反。其中一個(gè)后果就是我們添加了一個(gè)新的服務(wù)到單體應(yīng)用中，而單體應(yīng)用其實(shí)早就已經(jīng)解決過(guò)授權(quán)的問(wèn)題了。我們讓單體應(yīng)用變得更大了，而不是讓它變得更小。另外一個(gè)后果就是，我們開(kāi)始在每個(gè)服務(wù)上都實(shí)現(xiàn)授權(quán)。起初，這種做法看上去是合理的，因?yàn)槲覀冏畛醯募僭O(shè)是授權(quán)屬于領(lǐng)域模型所在的限界上下文，但是我們忽略了服務(wù)之間的依賴(lài)關(guān)系。所以，我們不斷地來(lái)回復(fù)制數(shù)據(jù)，增加了沖突的風(fēng)險(xiǎn)。

長(zhǎng)話(huà)短說(shuō)：我們最終將授權(quán)處理合并到了一個(gè)中心化的微服務(wù)中。

與中心化服務(wù)一并出現(xiàn)的是引入分布式單體應(yīng)用的風(fēng)險(xiǎn)。當(dāng)修改系統(tǒng)中的某一部分時(shí)，你必須要同時(shí)修改其他的組成部分，這是已引入分布式單體應(yīng)用的強(qiáng)烈信號(hào)。以我們的場(chǎng)景為例，當(dāng)引入需要授權(quán)的新協(xié)作應(yīng)用時(shí)，我們需要同時(shí)修改中心化的授權(quán)服務(wù)。我們同時(shí)遇到了單體應(yīng)用和分布式應(yīng)用的缺點(diǎn)：服務(wù)是緊耦合的，而且服務(wù)還需要通過(guò)緩慢、不穩(wěn)定的網(wǎng)絡(luò)來(lái)進(jìn)行通信。

于是，我們提供了一個(gè)通用的契約，這個(gè)契約屬于授權(quán)服務(wù)，所有的下游服務(wù)都必須要遵守該契約。在我們的場(chǎng)景中，服務(wù)會(huì)將授權(quán)相關(guān)的行為轉(zhuǎn)換成授權(quán)服務(wù)能夠理解的契約，授權(quán)服務(wù)不需要額外的轉(zhuǎn)換。這種轉(zhuǎn)換是在每個(gè)下游服務(wù)中發(fā)生的，而不是在中心化的授權(quán)服務(wù)中發(fā)生的。這種通用契約能夠確保我們?cè)谝胄碌姆?wù)時(shí)，不需要同時(shí)修改和重新部署中心化的認(rèn)證服務(wù)了。有個(gè)先決條件是這個(gè)通用的契約是穩(wěn)定的，或者說(shuō)至少向下兼容，否則的話(huà)，我們會(huì)將問(wèn)題轉(zhuǎn)移給下游服務(wù)，這會(huì)導(dǎo)致它們需要不斷進(jìn)行更新。

我們學(xué)習(xí)到了什么

在開(kāi)始階段需要特別注意，最好從易于提取的小型服務(wù)開(kāi)始，以便于快速得到結(jié)果并獲取使用微服務(wù)的早期經(jīng)驗(yàn)。如果要處理粗粒度的大型服務(wù)，就我們而言，將拆分過(guò)程分為增量式的步驟會(huì)更加易于管理，例如增量式地由上到下進(jìn)行分解，也就是每次只執(zhí)行一個(gè)可管理的步驟。

盡早處理橫切性的關(guān)注點(diǎn)非常重要，這樣能夠避免適得其反的后果，比如不斷擴(kuò)大單體應(yīng)用而不是縮減它，或者在每個(gè)服務(wù)中都重新實(shí)現(xiàn)橫切性的關(guān)注點(diǎn)。

在引入中心化的橫切服務(wù)時(shí)，需要注意不要引入分布式單體應(yīng)用。在這種情況下，通用且穩(wěn)定的契約能夠幫助我們避免出現(xiàn)分布式單體應(yīng)用。

要設(shè)計(jì)易于演化的系統(tǒng)，事件驅(qū)動(dòng)的服務(wù)交互方式是實(shí)現(xiàn)服務(wù)間高度解耦的關(guān)鍵。事件可以用作通知，也可以用于生成數(shù)據(jù)副本（關(guān)于事件驅(qū)動(dòng)的狀態(tài)轉(zhuǎn)移，參見(jiàn)上文關(guān)于從頭構(gòu)建共存服務(wù)的內(nèi)容），我們還可以通過(guò)長(zhǎng)期保留事件將事件存儲(chǔ)作為主要的數(shù)據(jù)源。

當(dāng)事件單純用于通知的目的時(shí)，其他上下文中的額外數(shù)據(jù)通常會(huì)以跨上下文查詢(xún)的方式直接進(jìn)行請(qǐng)求，比如 REST 請(qǐng)求。我們可能會(huì)更喜歡遠(yuǎn)程查詢(xún)的簡(jiǎn)潔性，而不愿處理本地維護(hù)數(shù)據(jù)集所帶來(lái)的開(kāi)銷(xiāo)，在數(shù)據(jù)集會(huì)不斷增長(zhǎng)的情況下更是如此。但是遠(yuǎn)程查詢(xún)?cè)黾恿朔?wù)之間的耦合性，并且在運(yùn)行時(shí)將服務(wù)綁定在了一起。

我們可以將對(duì)其他上下文的遠(yuǎn)程查詢(xún)進(jìn)行內(nèi)部化處理，這是通過(guò)引入相關(guān)跨上下文數(shù)據(jù)的本地副本來(lái)實(shí)現(xiàn)的。如上面的 JUST DRIVE 樣例所述，為了避免每次展現(xiàn)文檔的時(shí)候都從 profile 服務(wù)中請(qǐng)求相關(guān)的作者數(shù)據(jù)，我們復(fù)制了作者數(shù)據(jù)，并在文檔微服務(wù)中保留了一個(gè)本地副本。我們需要保證副本數(shù)據(jù)和原始數(shù)據(jù)的同步，這意味著當(dāng)原始數(shù)據(jù)變化的時(shí)候，要立即同步我們的本地副本。為了獲取已修改數(shù)據(jù)的通知，服務(wù)需要訂閱包含數(shù)據(jù)變化的事件并相應(yīng)地更新本地副本。在本例中，事件是用來(lái)生成數(shù)據(jù)副本的，這樣能夠避免遠(yuǎn)程查詢(xún)并降低服務(wù)之間的耦合性。這種方式也能實(shí)現(xiàn)更好的自治性，因?yàn)榉?wù)能夠?qū)Ρ镜馗北緢?zhí)行任何操作。

對(duì)于事件驅(qū)動(dòng)服務(wù)的交互，我們?cè)谠缙诰鸵肓?Apache Kafka，這是一個(gè)分布式、具有容錯(cuò)性、可擴(kuò)展的日志提交服務(wù)。最初，我們使用 Apache Kafka 的主要目的是實(shí)現(xiàn)通知和生成數(shù)據(jù)副本的功能。最近，我們引入 Apache Kafka Streams 作為共享的事實(shí)源，以減少數(shù)據(jù)復(fù)制的開(kāi)銷(xiāo)并實(shí)現(xiàn)服務(wù)的高可插拔性，降低新服務(wù)進(jìn)入的壁壘。

流是無(wú)界有序且持續(xù)更新的結(jié)構(gòu)化數(shù)據(jù)記錄組成的序列。數(shù)據(jù)記錄有一個(gè) key-value 對(duì)組成。

當(dāng)你的服務(wù)在 Apache Kafka 流上下文中啟動(dòng)時(shí)，Kafka 主題將會(huì)加載到你的流中，你可以在服務(wù)的范圍內(nèi)處理它。主題通常是一個(gè)邏輯分類(lèi)，表明了哪些服務(wù)可以發(fā)布和訂閱。每個(gè)流都會(huì)緩沖到一個(gè)狀態(tài)存儲(chǔ)中，這是一個(gè)輕量級(jí)的基于硬盤(pán)的數(shù)據(jù)。加載的流會(huì)在你自己的代碼中使用，不會(huì)在 Kafka 代理中運(yùn)行，它運(yùn)行在你的微服務(wù)進(jìn)程中。流能夠讓數(shù)據(jù)出現(xiàn)在任何需要的地方，這會(huì)增強(qiáng)性能和自治性。

Apache Kafka 提供了一個(gè) Stream API。Stream 可以借助領(lǐng)域特定語(yǔ)言（Domain Specific Language，DSL）進(jìn)行連接、過(guò)濾、分組或聚合，流中的每條消息都可以使用類(lèi)似函數(shù)的操作進(jìn)行處理，比如映射、轉(zhuǎn)換或窺探等。

在實(shí)現(xiàn)流處理的時(shí)候，通常會(huì)同時(shí)需要流以及進(jìn)行功能增強(qiáng)的數(shù)據(jù)庫(kù)。Kafka 的 Streams API 通過(guò)對(duì)流和表的核心抽象提供了該功能。在流和表之前其實(shí)存在緊密的關(guān)聯(lián)關(guān)系，也就是所謂的流 - 表二元性（stream-table duality）。流可以看做表的變更日志，流中的每條數(shù)據(jù)記錄都捕獲了表中的一次狀態(tài)變更。表可以視為快照，對(duì)應(yīng)于流中每個(gè) key 的最新值。

當(dāng)我們想要展現(xiàn)一條文檔及其作者數(shù)據(jù)時(shí)，借助 Kafka Streams，我們可以這樣做：文檔服務(wù)根據(jù) document 主題創(chuàng)建一個(gè) KStream，并根據(jù) profile 主題得到的作者相關(guān) profile 數(shù)據(jù)來(lái)完善該文檔。在這個(gè)增強(qiáng)的過(guò)程中，文檔服務(wù)會(huì)根據(jù) profile 主題創(chuàng)建 KTable。現(xiàn)在，我們可以將流和表進(jìn)行連接，并將它的結(jié)果保存為新的狀態(tài)存儲(chǔ)，這樣就可以在外部進(jìn)行訪(fǎng)問(wèn)了，運(yùn)行方式類(lèi)似于內(nèi)置的 Materialized View。每當(dāng) profile 或文檔更新的時(shí)候，它相關(guān)的 Materialized View 也會(huì)進(jìn)行更新。

將 Apache Kafka Streams 與其他的事件驅(qū)動(dòng)方式進(jìn)行對(duì)比的話(huà)，它不需要維護(hù)本地副本，這減少了維護(hù)數(shù)據(jù)副本和保持?jǐn)?shù)據(jù)同步的開(kāi)銷(xiāo)。Apache Kafka Streams 會(huì)將數(shù)據(jù)推送到需要的地方，并且運(yùn)行在與服務(wù)相同的進(jìn)程中。它增加了可插拔性，你可以插入新的服務(wù)并立即使用流，不需要搭建額外的數(shù)據(jù)存儲(chǔ)。它能夠減少開(kāi)銷(xiāo)，增強(qiáng)性能、自治性并降低新服務(wù)的進(jìn)入壁壘。

這個(gè)轉(zhuǎn)換的過(guò)程并不是隔離運(yùn)行的，它會(huì)受到各種環(huán)境因素的影響：團(tuán)隊(duì)的規(guī)模、結(jié)構(gòu)和技能都會(huì)影響到怎樣做才是可控的，尤其是在開(kāi)始階段，如果是一個(gè)的團(tuán)隊(duì)并且 DevOps 經(jīng)驗(yàn)很欠缺的話(huà)，將會(huì)對(duì)轉(zhuǎn)換的速度造成一定的影響。

你的轉(zhuǎn)換過(guò)程還會(huì)受到一個(gè)因素的影響，那就是你依然要處理遺留的系統(tǒng)。維護(hù)它所耗費(fèi)的時(shí)間會(huì)相應(yīng)地減少進(jìn)行轉(zhuǎn)換的時(shí)間。運(yùn)行時(shí)環(huán)境也會(huì)影響這個(gè)過(guò)程。你是在內(nèi)部環(huán)境中運(yùn)行還是作為云原生應(yīng)用運(yùn)行？你是否能夠依賴(lài)托管服務(wù)，比如托管的 API- 網(wǎng)關(guān)，還是需要自行搭建和維護(hù)？

如果你的策略是在短期內(nèi)引入新特性的話(huà)，那么就會(huì)面臨決策上的糾結(jié)，那就是將新需求在何處實(shí)現(xiàn)：如果作為新的獨(dú)立服務(wù)的話(huà)，會(huì)耗費(fèi)一定的時(shí)間，如果采取快捷的方式，將其添加到單體應(yīng)用上，那就會(huì)帶來(lái)讓單體應(yīng)用越來(lái)越大，而不能對(duì)其進(jìn)行縮減的風(fēng)險(xiǎn)。

注意那些阻礙前進(jìn)或減緩速度的環(huán)境因素，并相應(yīng)地調(diào)整它們，或者至少在你的組織中引起注意。記住: 每一次過(guò)程都是不同的，你的過(guò)程可能和我們的完全不同。

如果下次繼續(xù)引入微服務(wù)的話(huà)，在哪些方面的做法會(huì)有所不同

首先，我會(huì)檢查組織的戰(zhàn)略是否與微服務(wù)的目標(biāo)相一致，那就是最大化產(chǎn)品的敏捷性以及獨(dú)立快速地發(fā)布變更，例如，如果你的組織關(guān)注較長(zhǎng)的發(fā)布周期并希望將所有內(nèi)容部署在一起，那么微服務(wù)可能不是最佳選擇，因?yàn)闊o(wú)法充分利用微服務(wù)的優(yōu)勢(shì)。

如果你決定采用微服務(wù)的話(huà)，每個(gè)人都必須投入其中，包括管理層。每個(gè)人都需要意識(shí)到這個(gè)過(guò)程是非常復(fù)雜和耗時(shí)的，當(dāng)你還沒(méi)有多少經(jīng)驗(yàn)的時(shí)候更是如此。

與產(chǎn)品相符的、跨功能的、自治的團(tuán)隊(duì)可以很好地與微服務(wù)架構(gòu)模式協(xié)作，但是應(yīng)該盡早考慮向 DevOps 文化的轉(zhuǎn)變。每個(gè)團(tuán)隊(duì)都應(yīng)該為持續(xù)的迭代做好準(zhǔn)備，并且能夠開(kāi)發(fā)、發(fā)布、運(yùn)維和監(jiān)控他們負(fù)責(zé)的服務(wù)。

將單體應(yīng)用拆分成多個(gè)獨(dú)立的服務(wù)，只是整個(gè)過(guò)程的一部分，而如何運(yùn)維它們則是另外一回事兒。你擁有的服務(wù)越多，它們的自動(dòng)化構(gòu)建和部署流程就變得越重要。

如果我重做一次的話(huà)，我將從一個(gè)易于抽取的小型候選服務(wù)開(kāi)始，不僅要關(guān)注它的拆分，還要關(guān)注構(gòu)建和部署的自動(dòng)化，并預(yù)先監(jiān)控第一個(gè)服務(wù)，它可以作為后續(xù)服務(wù)的基礎(chǔ)。要搭建這個(gè)基礎(chǔ)環(huán)境，可能需要從每個(gè)組抽取一個(gè)人形成一個(gè)臨時(shí)的任務(wù)組。

每個(gè)微服務(wù)從一開(kāi)始就應(yīng)該有自己的 CI/CD 管道。另一個(gè)需要考慮的問(wèn)題是將每個(gè)微服務(wù)進(jìn)行容器化，從而能夠得到輕量級(jí)、封裝好的運(yùn)行時(shí)環(huán)境，它能夠在各個(gè)階段中保持一致，如果你以后想要在云環(huán)境中運(yùn)行服務(wù)的話(huà)，更需如此。

另外，還需要盡早考慮監(jiān)控的問(wèn)題，包括日志聚合。監(jiān)控不僅包括服務(wù)器，還包括服務(wù)指標(biāo)，如請(qǐng)求延遲、吞吐量和錯(cuò)誤率，以便于跟蹤服務(wù)的健康狀況和可用性。要形成結(jié)構(gòu)化和標(biāo)準(zhǔn)化的日志輸出，如時(shí)間格式（如 ISO8601）和時(shí)區(qū)（如 UTC），并引入具有 correlation id 和日志聚合的請(qǐng)求上下文，這有助于問(wèn)題的診斷和剖析。

很多事情需要預(yù)先處理，這非常耗時(shí)并且需要得到整個(gè)組織的關(guān)注。微服務(wù)是實(shí)現(xiàn)最大化產(chǎn)品敏捷性的投資，而不在于削減成本。

為了保持在市場(chǎng)上的競(jìng)爭(zhēng)力，產(chǎn)品的敏捷性和持續(xù)改進(jìn)是區(qū)別于競(jìng)爭(zhēng)對(duì)手的關(guān)鍵因素。微服務(wù)可以提升產(chǎn)品的敏捷性并持續(xù)改善，但是它需要每個(gè)人的貢獻(xiàn)，包括管理者。

關(guān)于作者

Susanne Kaiser 是來(lái)自德國(guó)漢堡的獨(dú)立技術(shù)咨詢(xún)師，她曾經(jīng)擔(dān)任過(guò)初創(chuàng)公司的 CTO，并將該公司的 SaaS 解決方案從單體架構(gòu)遷移為微服務(wù)架構(gòu)。她具有計(jì)算機(jī)科學(xué)的背景，在軟件開(kāi)發(fā)和軟件架構(gòu)方面有超過(guò) 15 年的經(jīng)驗(yàn)，經(jīng)常在國(guó)際性的技術(shù)會(huì)議上演講。

查看英文原文：Microservices From a Startup Perspective

轉(zhuǎn)載于:https://www.cnblogs.com/davidwang456/articles/10405075.html

總結(jié)

以上是生活随笔為你收集整理的从初创公司的角度来看微服务的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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