如何开始使用事件驱动的微服务

译者 | 李睿
审校 | 重楼
许多组织在其发展过程中达到了这样一个阶段,即曾经为他们提供良好服务的单一应用程序开始阻碍他们的发展 。也许业务需要现有架构无法支持的新功能,或者需要更灵活的方法来存储和访问应用程序的数据 。团队成长、相互冲突的性能需求和新的竞争性技术也会对单一的代码库构成挑战 。采用事件驱动的微服务架构可以帮助企业应对这些挑战 。

如何开始使用事件驱动的微服务

文章插图
微服务通过将这些应用程序划分为专门构建的小型服务,克服了单一应用程序的局限性,这些服务可以根据它们要解决的业务问题进行定制 。它们为企业提供了选择自己认为合适的编程语言、框架和数据库的自由 。微服务可以根据自己的需要重新建模、管理和存储数据,从而为企业提供了完全控制如何最好地解决业务问题的能力 。
在事件驱动的微服务架构中,系统通过产生和消费事件进行通信 。这些事件驱动的服务从输入事件流(例如Apache Kafka主题)中消费事件,并应用其特定的业务逻辑,发出自己的输出事件,为请求响应访问提供数据,与第三方API通信,或执行其他所需的操作 。
考虑事件驱动的微服务是否适合自己?如果用户正在考虑一个事件驱动的微服务架构,第一步是确保它是自己所需要的 。与许多技术决策一样,也存在权衡 。单一应用程序通常与其数据存储紧密耦合,为其他内部功能提供快速的数据访问 。但它们根据内部数据模型提供数据,根据底层技术提供性能和访问 。例如,键值存储会导致糟糕的关系数据库,两者都不能很好地替代存储松散结构的文档 。
如果用户发现自己正在编写(或使用)批量导出数据API,那么可能已经为事件驱动微服务做好了准备,这是最常见的迹象之一 。类似地,如果用户正在编写定期轮询作业,以便将数据从一个数据库提取到另一个数据库中 。这些是临时数据通信层的示例 。用户实际上并不需要与该数据相关联的单体的业务功能,只是需要这些数据,然后可能用于继续编写自己的新业务功能 。
从历史上看,在从联机事务处理(OLTP)系统提取数据以进行联机分析处理(OLAP)时,通常会发现这种模式 。但是,随着数据、性能需求和业务需求的大量增长,这些相同的提取和加载模式现在普遍适用于任何只需要公共业务数据来完成其功能的操作系统 。事件驱动的微服务提供了一种以不可变事件日志的形式访问历史数据和新数据的方法 。
当用户需要以一致的方式向多个部门和团队提供对同一组数据的访问时,事件驱动的微服务也是一个很好的解决方案 。例如,如果销售数据被打包为事件流,分析团队可以简单地订阅它,并确信他们使用的是与执行团队看到的完全相同的销售数据 。事件流为数据通信层提供了基础,消除了点对点、特设、专用连接的纠结网络,并用一组易于使用的流代替它们 。
利用现代云服务用户创建的每个新服务(微型或其他)都需要部署管道、容器管理、监控和扩展服务 。与单个单一服务相比,数十个微服务需要更多的开销和管理 。这种开销被称为“微服务税” 。简化和自动化操作将有助于降低成本,但这在历史上需要大量投资才能实现 。
如今,用户可以更多地依赖托管云服务来减少微服务税 。在这个时代,在Kube.NETes上部署、管理、监控和扩展Dockerized服务是非常常见和容易的 。同样,通过云服务(如Confluent Cloud)创建和管理Kafka主题比以往任何时候都更容易 。
密切关注“托管”和“完全托管”服务之间的区别 。选择完全托管的服务可以让用户继续实际运行业务,将所有维护、监视、扩展和安全需求外包给其服务提供商 。依靠云服务,可以对微服务进行原型化和实验,而无需预先支付任何“微服务税” 。用户可以简单地尝试它们,并采用对其最有帮助的部分和技术 。
从小处着手,在现有系统的基础上构建迁移到微服务架构不应该是一个反复更换的过程 。首先,确定满足实际业务需求的特定用例 。例如,用户可能需要从一个数据库中的四个不同关系表中获取和重新建模数据,以支持新的基于文档的搜索功能 。如何将现有的非流数据源集成到事件驱动的架构中?
Kafka Connect是将数据库表引导到自己的事件流中的绝佳选择 。用户可以连接到大量的本地数据库和云数据库、快照历史数据、过滤数据、屏蔽列等等 。用户的源数据库仍然独立于Kafka Connect,让其在不影响现有系统的情况下增量地获取重要的业务数据 。


推荐阅读