用户可以增量地构建微服务，同时根据需要维护原始的单片应用程序 。这不是一个“非此即彼”的问题，而是以对业务有意义的速度公开用户需要的额外数据和功能 。
构建与业务需求一致的微服务设计微服务来解决特定的、密切相关的业务问题，因为类似的问题往往需要类似的数据 。将微服务与业务问题结合起来意味着除非业务发生变化，否则用户的微服务不太可能需要改变 。例如，一家电子商务企业可以有一个处理支付的微服务，另一个处理库存管理的微服务，还有一个处理运输的微服务 。对交付工作流所做的任何更改只会影响交付微服务 。
将微服务边界与业务用例保持一致，可以减少意外或偶然更改的风险，因为功能被封装在一个服务中 。在更复杂的用例中，业务工作流跨越多个微服务并不罕见，不过为了保持一致性，任何原子操作都应该保留在单个服务中 。
尽量减少微服务的数量微服务不需要很小 。事实上，人们可能会发现，将微服务简单地看作是针对业务问题子集的专用服务是很有帮助的 。许多人陷入的主要陷阱之一是为每一个功能构建微服务，最终往往会有数百或数千个服务!事件驱动微服务架构的目标不是构建尽可能多的服务，而是使用合适的工具来实现专用的解决方案 。
在添加业务功能时，需要先查看是否可以合理地将其与现有服务集成 。如果能够以一种似乎是对现有服务的合理扩展的方式添加功能，那么这样做可能比构建一个新的、可能不必要的服务更有意义 。例如，扩展的库存管理功能应该在库存管理微服务中，而不是在另一个类似但不同的微服务中 。
并不是所有模块从一开始就必须是微服务 。一个合理的设计选择是使用具有健康API边界和关注点分离的模块化整体框架对解决方案实现原型化 。用户可以将整个原型单体视为单个(大型)微服务，根据需要从事件流中读取和写入 。一旦用户的业务用例变得更加明确，就可以根据需要将选择的模块拆分为自己的微服务 。只在必要的时候引入新的微服务，不要忘记少即是多，尤其是刚开始的时候 。
使用目录来跟踪事件流和服务当用户创建更多的微服务和事件流时，将需要一些方法来管理、发现和跟踪使用情况和元数据 。目录有两个主要功能：
（1）发现谁拥有事件流，它包含什么数据，以及它使用什么模式和结构 。
（2）发现哪些微服务已经存在，谁拥有它们，它们负责哪些事件流和API 。
在开始时，可以使用共享电子表格这样简单的东西对元数据进行编目 。随着业务的增长，确实需要转向专用的元数据服务 。Apache Atlas是一种常见的开源选择，不过更简单的答案是向云计算服务提供商寻求解决方案(例如Confluent cloud的Stream Catalog) 。
创建由认可的工具、语言和框架组成的工具箱事件驱动微服务的优点之一是，它为更广泛的技术选择打开了大门，包括各种编程语言、框架、数据库和工具 。这对于创新和可访问性来说是件好事，但如果开发者使用太多不同的技术，特别是鲜为人知的或流行的选择，就会成为一个问题 。
要解决这个问题，需要将关键利益相关者召集在一起，并决定将支持的技术工具箱 。这不应该过度的限制，但是用户不希望不必要地支持工具和技术，因为这会增加成本、复杂性和管理开销 。应用程序模板、代码生成器、事件生成器、测试框架、监视框架和编程语言只是用户可以在工具箱中找到的一些示例 。
如果开发人员想要脱离工具箱，需要确保他们有充分的理由这样做，例如，为了实现某些他们无法通过其他方式创建的所需业务功能 。在这种情况下，使用他们的经验作为扩展工具箱以包含新选项的案例研究 。但是要小心，因为每个新添加的内容都需要努力支持 。
作为一般规则，用户的目标应该是使开发人员尽可能容易地构建和维护其所需的微服务 。用户甚至可以创建一个快速启动函数，生成一个带有服务骨架的Github回购，构建测试框架，等等 。
充分利用集成和单元测试事件驱动的微服务非常适合完全集成和单元测试 。作为事件驱动微服务的主要输入形式，可以很容易地组合事件以涵盖广泛的输入和极端情况 。事件模式约束了需要测试的值的范围，并为组合输入测试流提供了必要的结构 。
用户通常可以通过加载带有特定事件的输入来“黑盒测试”其微服务，看看会产生什么结果 。对于Kafka特定的事件，Kafka有一个内置的、基于JAVA的内存测试代理 。通过启动代理，用户能够以编程方式生成事件并评估生成的结果 。
推荐阅读
- 结合使用React和其他技术的七种方法
- 如何用ChatGPT设计出可控制的代码？
- 如何快速删除Excel里的多个空行？
- 如何修炼迷人气质？多做这6个瑜伽体式，滋润肌肤，展现身材美
- 电话录屏怎么做？手把手教你如何录屏通话过程
- 大家知道微信如何解除已绑定的银行卡吗
- 微信如何录屏聊天记录？看完就知道了
- 大家知道如何关闭花呗吗
- 医美|涂口红时如何让口红质感更高级？
- 饮食|如何逼自己瘦下来？8个提高代谢的减肥小技巧，从168瘦到104