譯者 | 李睿

審校 | 重樓

許多組織在其發展過程中達到了這樣一個階段，即曾經為他們提供良好服務的單一應用程序開始阻礙他們的發展。也許業務需要現有架構無法支持的新功能，或者需要更靈活的方法來存儲和訪問應用程序的數據。團隊成長、相互沖突的性能需求和新的競爭性技術也會對單一的代碼庫構成挑戰。采用事件驅動的微服務架構可以幫助企業應對這些挑戰。

微服務通過將這些應用程序劃分為專門構建的小型服務，克服了單一應用程序的局限性，這些服務可以根據它們要解決的業務問題進行定制。它們為企業提供了選擇自己認為合適的編程語言、框架和數據庫的自由。微服務可以根據自己的需要重新建模、管理和存儲數據，從而為企業提供了完全控制如何最好地解決業務問題的能力。

在事件驅動的微服務架構中，系統通過產生和消費事件進行通信。這些事件驅動的服務從輸入事件流（例如Apache Kafka主題）中消費事件，并應用其特定的業務邏輯，發出自己的輸出事件，為請求響應訪問提供數據，與第三方API通信，或執行其他所需的操作。

考慮事件驅動的微服務是否適合自己?

如果用戶正在考慮一個事件驅動的微服務架構，第一步是確保它是自己所需要的。與許多技術決策一樣，也存在權衡。單一應用程序通常與其數據存儲緊密耦合，為其他內部功能提供快速的數據訪問。但它們根據內部數據模型提供數據，根據底層技術提供性能和訪問。例如，鍵值存儲會導致糟糕的關系數據庫，兩者都不能很好地替代存儲松散結構的文檔。

如果用戶發現自己正在編寫(或使用)批量導出數據API，那么可能已經為事件驅動微服務做好了準備，這是最常見的跡象之一。類似地，如果用戶正在編寫定期輪詢作業，以便將數據從一個數據庫提取到另一個數據庫中。這些是臨時數據通信層的示例。用戶實際上并不需要與該數據相關聯的單體的業務功能，只是需要這些數據，然后可能用于繼續編寫自己的新業務功能。

從歷史上看，在從聯機事務處理(OLTP)系統提取數據以進行聯機分析處理(OLAP)時，通常會發現這種模式。但是，隨著數據、性能需求和業務需求的大量增長，這些相同的提取和加載模式現在普遍適用于任何只需要公共業務數據來完成其功能的操作系統。事件驅動的微服務提供了一種以不可變事件日志的形式訪問歷史數據和新數據的方法。

當用戶需要以一致的方式向多個部門和團隊提供對同一組數據的訪問時，事件驅動的微服務也是一個很好的解決方案。例如，如果銷售數據被打包為事件流，分析團隊可以簡單地訂閱它，并確信他們使用的是與執行團隊看到的完全相同的銷售數據。事件流為數據通信層提供了基礎，消除了點對點、特設、專用連接的糾結網絡，并用一組易于使用的流代替它們。

利用現代云服務

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

如今，用戶可以更多地依賴托管云服務來減少微服務稅。在這個時代，在Kubernetes上部署、管理、監控和擴展Dockerized服務是非常常見和容易的。同樣，通過云服務(如Confluent Cloud)創建和管理Kafka主題比以往任何時候都更容易。

密切關注“托管”和“完全托管”服務之間的區別。選擇完全托管的服務可以讓用戶繼續實際運行業務，將所有維護、監視、擴展和安全需求外包給其服務提供商。依靠云服務，可以對微服務進行原型化和實驗，而無需預先支付任何“微服務稅”。用戶可以簡單地嘗試它們，并采用對其最有幫助的部分和技術。

從小處著手，在現有系統的基礎上構建

遷移到微服務架構不應該是一個反復更換的過程。首先，確定滿足實際業務需求的特定用例。例如，用戶可能需要從一個數據庫中的四個不同關系表中獲取和重新建模數據，以支持新的基于文檔的搜索功能。如何將現有的非流數據源集成到事件驅動的架構中?

Kafka Connect是將數據庫表引導到自己的事件流中的絕佳選擇。用戶可以連接到大量的本地數據庫和云數據庫、快照歷史數據、過濾數據、屏蔽列等等。用戶的源數據庫仍然獨立于Kafka Connect，讓其在不影響現有系統的情況下增量地獲取重要的業務數據。

用戶可以增量地構建微服務，同時根據需要維護原始的單片應用程序。這不是一個“非此即彼”的問題，而是以對業務有意義的速度公開用戶需要的額外數據和功能。

構建與業務需求一致的微服務

設計微服務來解決特定的、密切相關的業務問題，因為類似的問題往往需要類似的數據。將微服務與業務問題結合起來意味著除非業務發生變化，否則用戶的微服務不太可能需要改變。例如，一家電子商務企業可以有一個處理支付的微服務，另一個處理庫存管理的微服務，還有一個處理運輸的微服務。對交付工作流所做的任何更改只會影響交付微服務。

將微服務邊界與業務用例保持一致，可以減少意外或偶然更改的風險，因為功能被封裝在一個服務中。在更復雜的用例中，業務工作流跨越多個微服務并不罕見，不過為了保持一致性，任何原子操作都應該保留在單個服務中。

盡量減少微服務的數量

微服務不需要很小。事實上，人們可能會發現，將微服務簡單地看作是針對業務問題子集的專用服務是很有幫助的。許多人陷入的主要陷阱之一是為每一個功能構建微服務，最終往往會有數百或數千個服務!事件驅動微服務架構的目標不是構建盡可能多的服務，而是使用合適的工具來實現專用的解決方案。

在添加業務功能時，需要先查看是否可以合理地將其與現有服務集成。如果能夠以一種似乎是對現有服務的合理擴展的方式添加功能，那么這樣做可能比構建一個新的、可能不必要的服務更有意義。例如，擴展的庫存管理功能應該在庫存管理微服務中，而不是在另一個類似但不同的微服務中。

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

使用目錄來跟蹤事件流和服務

當用戶創建更多的微服務和事件流時，將需要一些方法來管理、發現和跟蹤使用情況和元數據。目錄有兩個主要功能：

（1）發現誰擁有事件流，它包含什么數據，以及它使用什么模式和結構。

（2）發現哪些微服務已經存在，誰擁有它們，它們負責哪些事件流和API。

在開始時，可以使用共享電子表格這樣簡單的東西對元數據進行編目。隨著業務的增長，確實需要轉向專用的元數據服務。Apache Atlas是一種常見的開源選擇，不過更簡單的答案是向云計算服務提供商尋求解決方案(例如Confluent cloud的Stream Catalog)。

創建由認可的工具、語言和框架組成的工具箱

事件驅動微服務的優點之一是，它為更廣泛的技術選擇打開了大門，包括各種編程語言、框架、數據庫和工具。這對于創新和可訪問性來說是件好事，但如果開發者使用太多不同的技術，特別是鮮為人知的或流行的選擇，就會成為一個問題。

要解決這個問題，需要將關鍵利益相關者召集在一起，并決定將支持的技術工具箱。這不應該過度的限制，但是用戶不希望不必要地支持工具和技術，因為這會增加成本、復雜性和管理開銷。應用程序模板、代碼生成器、事件生成器、測試框架、監視框架和編程語言只是用戶可以在工具箱中找到的一些示例。

如果開發人員想要脫離工具箱，需要確保他們有充分的理由這樣做，例如，為了實現某些他們無法通過其他方式創建的所需業務功能。在這種情況下，使用他們的經驗作為擴展工具箱以包含新選項的案例研究。但是要小心，因為每個新添加的內容都需要努力支持。

作為一般規則，用戶的目標應該是使開發人員盡可能容易地構建和維護其所需的微服務。用戶甚至可以創建一個快速啟動函數，生成一個帶有服務骨架的GitHub回購，構建測試框架，等等。

充分利用集成和單元測試

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

用戶通常可以通過加載帶有特定事件的輸入來“黑盒測試”其微服務，看看會產生什么結果。對于Kafka特定的事件，Kafka有一個內置的、基于Java的內存測試代理。通過啟動代理，用戶能夠以編程方式生成事件并評估生成的結果。

對于基于容器的微服務集成測試，用戶可以啟動自己的容器化并行Kafka實例，或者直接插入云集群。制作并消費事件，然后在最后剝離所有內容。

對于單元測試，微服務類似于大多數其他應用程序架構。使用單元測試和測試所有函數，以確保輸出與預期輸出匹配。單元測試對于確保應用程序在第一次部署時就能正常工作，以及防止任何意外的機會至關重要。

事件流滿足不同的需求

事件驅動的通信并不新鮮，但是大多數現代組織的需求已經發生了變化。數據集已經變得越來越大，單一的整體結構已經不足以處理現代組織的所有復雜和多樣化的需求。事件驅動的微服務提供了一種強大而靈活的方式來滿足當今的需求。事件流構成了數據通信的基礎，為其他服務提供了可靠的事實來源，供它們在認為合適的情況下消費和使用。

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

原文標題：How to get started with event-driven microservices，作者：Adam Bellemare