譯者 | 李睿

審校 | 重樓

許多組織在其發(fā)展過(guò)程中達(dá)到了這樣一個(gè)階段，即曾經(jīng)為他們提供良好服務(wù)的單一應(yīng)用程序開始阻礙他們的發(fā)展。也許業(yè)務(wù)需要現(xiàn)有架構(gòu)無(wú)法支持的新功能，或者需要更靈活的方法來(lái)存儲(chǔ)和訪問(wèn)應(yīng)用程序的數(shù)據(jù)。團(tuán)隊(duì)成長(zhǎng)、相互沖突的性能需求和新的競(jìng)爭(zhēng)性技術(shù)也會(huì)對(duì)單一的代碼庫(kù)構(gòu)成挑戰(zhàn)。采用事件驅(qū)動(dòng)的微服務(wù)架構(gòu)可以幫助企業(yè)應(yīng)對(duì)這些挑戰(zhàn)。

微服務(wù)通過(guò)將這些應(yīng)用程序劃分為專門構(gòu)建的小型服務(wù)，克服了單一應(yīng)用程序的局限性，這些服務(wù)可以根據(jù)它們要解決的業(yè)務(wù)問(wèn)題進(jìn)行定制。它們?yōu)槠髽I(yè)提供了選擇自己認(rèn)為合適的編程語(yǔ)言、框架和數(shù)據(jù)庫(kù)的自由。微服務(wù)可以根據(jù)自己的需要重新建模、管理和存儲(chǔ)數(shù)據(jù)，從而為企業(yè)提供了完全控制如何最好地解決業(yè)務(wù)問(wèn)題的能力。

在事件驅(qū)動(dòng)的微服務(wù)架構(gòu)中，系統(tǒng)通過(guò)產(chǎn)生和消費(fèi)事件進(jìn)行通信。這些事件驅(qū)動(dòng)的服務(wù)從輸入事件流（例如Apache Kafka主題）中消費(fèi)事件，并應(yīng)用其特定的業(yè)務(wù)邏輯，發(fā)出自己的輸出事件，為請(qǐng)求響應(yīng)訪問(wèn)提供數(shù)據(jù)，與第三方API通信，或執(zhí)行其他所需的操作。

考慮事件驅(qū)動(dòng)的微服務(wù)是否適合自己?

如果用戶正在考慮一個(gè)事件驅(qū)動(dòng)的微服務(wù)架構(gòu)，第一步是確保它是自己所需要的。與許多技術(shù)決策一樣，也存在權(quán)衡。單一應(yīng)用程序通常與其數(shù)據(jù)存儲(chǔ)緊密耦合，為其他內(nèi)部功能提供快速的數(shù)據(jù)訪問(wèn)。但它們根據(jù)內(nèi)部數(shù)據(jù)模型提供數(shù)據(jù)，根據(jù)底層技術(shù)提供性能和訪問(wèn)。例如，鍵值存儲(chǔ)會(huì)導(dǎo)致糟糕的關(guān)系數(shù)據(jù)庫(kù)，兩者都不能很好地替代存儲(chǔ)松散結(jié)構(gòu)的文檔。

如果用戶發(fā)現(xiàn)自己正在編寫(或使用)批量導(dǎo)出數(shù)據(jù)API，那么可能已經(jīng)為事件驅(qū)動(dòng)微服務(wù)做好了準(zhǔn)備，這是最常見的跡象之一。類似地，如果用戶正在編寫定期輪詢作業(yè)，以便將數(shù)據(jù)從一個(gè)數(shù)據(jù)庫(kù)提取到另一個(gè)數(shù)據(jù)庫(kù)中。這些是臨時(shí)數(shù)據(jù)通信層的示例。用戶實(shí)際上并不需要與該數(shù)據(jù)相關(guān)聯(lián)的單體的業(yè)務(wù)功能，只是需要這些數(shù)據(jù)，然后可能用于繼續(xù)編寫自己的新業(yè)務(wù)功能。

從歷史上看，在從聯(lián)機(jī)事務(wù)處理(OLTP)系統(tǒng)提取數(shù)據(jù)以進(jìn)行聯(lián)機(jī)分析處理(OLAP)時(shí)，通常會(huì)發(fā)現(xiàn)這種模式。但是，隨著數(shù)據(jù)、性能需求和業(yè)務(wù)需求的大量增長(zhǎng)，這些相同的提取和加載模式現(xiàn)在普遍適用于任何只需要公共業(yè)務(wù)數(shù)據(jù)來(lái)完成其功能的操作系統(tǒng)。事件驅(qū)動(dòng)的微服務(wù)提供了一種以不可變事件日志的形式訪問(wèn)歷史數(shù)據(jù)和新數(shù)據(jù)的方法。

當(dāng)用戶需要以一致的方式向多個(gè)部門和團(tuán)隊(duì)提供對(duì)同一組數(shù)據(jù)的訪問(wèn)時(shí)，事件驅(qū)動(dòng)的微服務(wù)也是一個(gè)很好的解決方案。例如，如果銷售數(shù)據(jù)被打包為事件流，分析團(tuán)隊(duì)可以簡(jiǎn)單地訂閱它，并確信他們使用的是與執(zhí)行團(tuán)隊(duì)看到的完全相同的銷售數(shù)據(jù)。事件流為數(shù)據(jù)通信層提供了基礎(chǔ)，消除了點(diǎn)對(duì)點(diǎn)、特設(shè)、專用連接的糾結(jié)網(wǎng)絡(luò)，并用一組易于使用的流代替它們。

利用現(xiàn)代云服務(wù)

用戶創(chuàng)建的每個(gè)新服務(wù)(微型或其他)都需要部署管道、容器管理、監(jiān)控和擴(kuò)展服務(wù)。與單個(gè)單一服務(wù)相比，數(shù)十個(gè)微服務(wù)需要更多的開銷和管理。這種開銷被稱為“微服務(wù)稅”。簡(jiǎn)化和自動(dòng)化操作將有助于降低成本，但這在歷史上需要大量投資才能實(shí)現(xiàn)。

如今，用戶可以更多地依賴托管云服務(wù)來(lái)減少微服務(wù)稅。在這個(gè)時(shí)代，在Kubernetes上部署、管理、監(jiān)控和擴(kuò)展Dockerized服務(wù)是非常常見和容易的。同樣，通過(guò)云服務(wù)(如Confluent Cloud)創(chuàng)建和管理Kafka主題比以往任何時(shí)候都更容易。

密切關(guān)注“托管”和“完全托管”服務(wù)之間的區(qū)別。選擇完全托管的服務(wù)可以讓用戶繼續(xù)實(shí)際運(yùn)行業(yè)務(wù)，將所有維護(hù)、監(jiān)視、擴(kuò)展和安全需求外包給其服務(wù)提供商。依靠云服務(wù)，可以對(duì)微服務(wù)進(jìn)行原型化和實(shí)驗(yàn)，而無(wú)需預(yù)先支付任何“微服務(wù)稅”。用戶可以簡(jiǎn)單地嘗試它們，并采用對(duì)其最有幫助的部分和技術(shù)。

從小處著手，在現(xiàn)有系統(tǒng)的基礎(chǔ)上構(gòu)建

遷移到微服務(wù)架構(gòu)不應(yīng)該是一個(gè)反復(fù)更換的過(guò)程。首先，確定滿足實(shí)際業(yè)務(wù)需求的特定用例。例如，用戶可能需要從一個(gè)數(shù)據(jù)庫(kù)中的四個(gè)不同關(guān)系表中獲取和重新建模數(shù)據(jù)，以支持新的基于文檔的搜索功能。如何將現(xiàn)有的非流數(shù)據(jù)源集成到事件驅(qū)動(dòng)的架構(gòu)中?

Kafka Connect是將數(shù)據(jù)庫(kù)表引導(dǎo)到自己的事件流中的絕佳選擇。用戶可以連接到大量的本地?cái)?shù)據(jù)庫(kù)和云數(shù)據(jù)庫(kù)、快照歷史數(shù)據(jù)、過(guò)濾數(shù)據(jù)、屏蔽列等等。用戶的源數(shù)據(jù)庫(kù)仍然獨(dú)立于Kafka Connect，讓其在不影響現(xiàn)有系統(tǒng)的情況下增量地獲取重要的業(yè)務(wù)數(shù)據(jù)。

用戶可以增量地構(gòu)建微服務(wù)，同時(shí)根據(jù)需要維護(hù)原始的單片應(yīng)用程序。這不是一個(gè)“非此即彼”的問(wèn)題，而是以對(duì)業(yè)務(wù)有意義的速度公開用戶需要的額外數(shù)據(jù)和功能。

構(gòu)建與業(yè)務(wù)需求一致的微服務(wù)

設(shè)計(jì)微服務(wù)來(lái)解決特定的、密切相關(guān)的業(yè)務(wù)問(wèn)題，因?yàn)轭愃频膯?wèn)題往往需要類似的數(shù)據(jù)。將微服務(wù)與業(yè)務(wù)問(wèn)題結(jié)合起來(lái)意味著除非業(yè)務(wù)發(fā)生變化，否則用戶的微服務(wù)不太可能需要改變。例如，一家電子商務(wù)企業(yè)可以有一個(gè)處理支付的微服務(wù)，另一個(gè)處理庫(kù)存管理的微服務(wù)，還有一個(gè)處理運(yùn)輸?shù)奈⒎?wù)。對(duì)交付工作流所做的任何更改只會(huì)影響交付微服務(wù)。

將微服務(wù)邊界與業(yè)務(wù)用例保持一致，可以減少意外或偶然更改的風(fēng)險(xiǎn)，因?yàn)楣δ鼙环庋b在一個(gè)服務(wù)中。在更復(fù)雜的用例中，業(yè)務(wù)工作流跨越多個(gè)微服務(wù)并不罕見，不過(guò)為了保持一致性，任何原子操作都應(yīng)該保留在單個(gè)服務(wù)中。

盡量減少微服務(wù)的數(shù)量

微服務(wù)不需要很小。事實(shí)上，人們可能會(huì)發(fā)現(xiàn)，將微服務(wù)簡(jiǎn)單地看作是針對(duì)業(yè)務(wù)問(wèn)題子集的專用服務(wù)是很有幫助的。許多人陷入的主要陷阱之一是為每一個(gè)功能構(gòu)建微服務(wù)，最終往往會(huì)有數(shù)百或數(shù)千個(gè)服務(wù)!事件驅(qū)動(dòng)微服務(wù)架構(gòu)的目標(biāo)不是構(gòu)建盡可能多的服務(wù)，而是使用合適的工具來(lái)實(shí)現(xiàn)專用的解決方案。

在添加業(yè)務(wù)功能時(shí)，需要先查看是否可以合理地將其與現(xiàn)有服務(wù)集成。如果能夠以一種似乎是對(duì)現(xiàn)有服務(wù)的合理擴(kuò)展的方式添加功能，那么這樣做可能比構(gòu)建一個(gè)新的、可能不必要的服務(wù)更有意義。例如，擴(kuò)展的庫(kù)存管理功能應(yīng)該在庫(kù)存管理微服務(wù)中，而不是在另一個(gè)類似但不同的微服務(wù)中。

并不是所有模塊從一開始就必須是微服務(wù)。一個(gè)合理的設(shè)計(jì)選擇是使用具有健康A(chǔ)PI邊界和關(guān)注點(diǎn)分離的模塊化整體框架對(duì)解決方案實(shí)現(xiàn)原型化。用戶可以將整個(gè)原型單體視為單個(gè)(大型)微服務(wù)，根據(jù)需要從事件流中讀取和寫入。一旦用戶的業(yè)務(wù)用例變得更加明確，就可以根據(jù)需要將選擇的模塊拆分為自己的微服務(wù)。只在必要的時(shí)候引入新的微服務(wù)，不要忘記少即是多，尤其是剛開始的時(shí)候。

使用目錄來(lái)跟蹤事件流和服務(wù)

當(dāng)用戶創(chuàng)建更多的微服務(wù)和事件流時(shí)，將需要一些方法來(lái)管理、發(fā)現(xiàn)和跟蹤使用情況和元數(shù)據(jù)。目錄有兩個(gè)主要功能：

（1）發(fā)現(xiàn)誰(shuí)擁有事件流，它包含什么數(shù)據(jù)，以及它使用什么模式和結(jié)構(gòu)。

（2）發(fā)現(xiàn)哪些微服務(wù)已經(jīng)存在，誰(shuí)擁有它們，它們負(fù)責(zé)哪些事件流和API。

在開始時(shí)，可以使用共享電子表格這樣簡(jiǎn)單的東西對(duì)元數(shù)據(jù)進(jìn)行編目。隨著業(yè)務(wù)的增長(zhǎng)，確實(shí)需要轉(zhuǎn)向?qū)Ｓ玫脑獢?shù)據(jù)服務(wù)。Apache Atlas是一種常見的開源選擇，不過(guò)更簡(jiǎn)單的答案是向云計(jì)算服務(wù)提供商尋求解決方案(例如Confluent cloud的Stream Catalog)。

創(chuàng)建由認(rèn)可的工具、語(yǔ)言和框架組成的工具箱

事件驅(qū)動(dòng)微服務(wù)的優(yōu)點(diǎn)之一是，它為更廣泛的技術(shù)選擇打開了大門，包括各種編程語(yǔ)言、框架、數(shù)據(jù)庫(kù)和工具。這對(duì)于創(chuàng)新和可訪問(wèn)性來(lái)說(shuō)是件好事，但如果開發(fā)者使用太多不同的技術(shù)，特別是鮮為人知的或流行的選擇，就會(huì)成為一個(gè)問(wèn)題。

要解決這個(gè)問(wèn)題，需要將關(guān)鍵利益相關(guān)者召集在一起，并決定將支持的技術(shù)工具箱。這不應(yīng)該過(guò)度的限制，但是用戶不希望不必要地支持工具和技術(shù)，因?yàn)檫@會(huì)增加成本、復(fù)雜性和管理開銷。應(yīng)用程序模板、代碼生成器、事件生成器、測(cè)試框架、監(jiān)視框架和編程語(yǔ)言只是用戶可以在工具箱中找到的一些示例。

如果開發(fā)人員想要脫離工具箱，需要確保他們有充分的理由這樣做，例如，為了實(shí)現(xiàn)某些他們無(wú)法通過(guò)其他方式創(chuàng)建的所需業(yè)務(wù)功能。在這種情況下，使用他們的經(jīng)驗(yàn)作為擴(kuò)展工具箱以包含新選項(xiàng)的案例研究。但是要小心，因?yàn)槊總€(gè)新添加的內(nèi)容都需要努力支持。

作為一般規(guī)則，用戶的目標(biāo)應(yīng)該是使開發(fā)人員盡可能容易地構(gòu)建和維護(hù)其所需的微服務(wù)。用戶甚至可以創(chuàng)建一個(gè)快速啟動(dòng)函數(shù)，生成一個(gè)帶有服務(wù)骨架的GitHub回購(gòu)，構(gòu)建測(cè)試框架，等等。

充分利用集成和單元測(cè)試

事件驅(qū)動(dòng)的微服務(wù)非常適合完全集成和單元測(cè)試。作為事件驅(qū)動(dòng)微服務(wù)的主要輸入形式，可以很容易地組合事件以涵蓋廣泛的輸入和極端情況。事件模式約束了需要測(cè)試的值的范圍，并為組合輸入測(cè)試流提供了必要的結(jié)構(gòu)。

用戶通常可以通過(guò)加載帶有特定事件的輸入來(lái)“黑盒測(cè)試”其微服務(wù)，看看會(huì)產(chǎn)生什么結(jié)果。對(duì)于Kafka特定的事件，Kafka有一個(gè)內(nèi)置的、基于Java的內(nèi)存測(cè)試代理。通過(guò)啟動(dòng)代理，用戶能夠以編程方式生成事件并評(píng)估生成的結(jié)果。

對(duì)于基于容器的微服務(wù)集成測(cè)試，用戶可以啟動(dòng)自己的容器化并行Kafka實(shí)例，或者直接插入云集群。制作并消費(fèi)事件，然后在最后剝離所有內(nèi)容。

對(duì)于單元測(cè)試，微服務(wù)類似于大多數(shù)其他應(yīng)用程序架構(gòu)。使用單元測(cè)試和測(cè)試所有函數(shù)，以確保輸出與預(yù)期輸出匹配。單元測(cè)試對(duì)于確保應(yīng)用程序在第一次部署時(shí)就能正常工作，以及防止任何意外的機(jī)會(huì)至關(guān)重要。

事件流滿足不同的需求

事件驅(qū)動(dòng)的通信并不新鮮，但是大多數(shù)現(xiàn)代組織的需求已經(jīng)發(fā)生了變化。數(shù)據(jù)集已經(jīng)變得越來(lái)越大，單一的整體結(jié)構(gòu)已經(jīng)不足以處理現(xiàn)代組織的所有復(fù)雜和多樣化的需求。事件驅(qū)動(dòng)的微服務(wù)提供了一種強(qiáng)大而靈活的方式來(lái)滿足當(dāng)今的需求。事件流構(gòu)成了數(shù)據(jù)通信的基礎(chǔ)，為其他服務(wù)提供了可靠的事實(shí)來(lái)源，供它們?cè)谡J(rèn)為合適的情況下消費(fèi)和使用。

與此同時(shí)，微服務(wù)為使用正確的工具解決業(yè)務(wù)問(wèn)題提供了靈活性和選擇。如今的現(xiàn)代云服務(wù)意味著用戶在平臺(tái)上花費(fèi)的時(shí)間要少得多，而在問(wèn)題上花費(fèi)的時(shí)間要多得多。希望以上內(nèi)容為人們提供了在組織中開始使用這個(gè)令人難以置信的強(qiáng)大和靈活的模型所需的基礎(chǔ)知識(shí)。

原文標(biāo)題：How to get started with event-driven microservices，作者：Adam Bellemare