为什么微服务需要事件驱动架构?

作者:Joe McKendrick 编译:沈建苗

微服务承诺有助于分解单体式应用程序,并实现服务的一致交付。但若没有帮助,微服务完成不了这项工作。这时候,事件驱动架构(EDA)闪亮登场。

Solace的首席技术官Jonathan Schabowsky在下面专访中较深入地阐述了微服务日益与EDA融合的趋势。他认为,如果组织想充分利用基于微服务的业务应用程序,真正理解EDA至关重要。

问:您如何从微服务采用方面看待这个行业?

Schabowsky:我们看到更多的微服务被纳入到转型项目中,将单体式应用程序分解成独立部署的服务。O’Reilly的最新研究调查表明,61%的企业已采用了微服务。不过凭我的经验,这些公司中只有一小部分能够将事件驱动微服务整合到转型项目中。

问:该研究调查还表明,近 40%的企业尚未深入采用微服务。问题卡在哪里?

Schabowsky:当然,微服务的应用比想象的来得复杂。实际上,微服务带来了诸多问题:它可能很脆弱,与现有的遗留生态系统并不很好地吻合。并非所有微服务都一样,并不总是提供所承诺的更高的可扩展性和敏捷性。

一大障碍是服务分解悖论——微服务越小,需要的服务就越多,因典型的分布式系统问题(比如网络延迟)而导致稳定性和性能问题。因此,用户体验也会受到影响。分解与延迟最小化性能最大化的架构之间存在一种平衡或取舍。

问:遗留集成是否对实现微服务架构提出了挑战?

Schabowsky:这里存在着脱节现象——许多现有系统驻留在本地,而微服务可能驻留在私有云和公共云。广域网常常不稳定、不可预测,数据在广域网上传输因而可能很棘手、很费时,还有物联网、大数据和移动设备带来的种种挑战。这给微服务项目带来了重大风险。

较旧的系统更新起来并非易事,但另一方面,微服务需要快速又灵活。实施的旧系统依赖老化的通信协议,而微服务依赖API和开放协议。大多数遗留系统将部署在本地,而大多数微服务驻留在云端。物联网网络等新系统使用高度专业化的协议,但大多数微服务API和框架并不支持它们。事件驱动架构消除了遗留系统与微服务之间的这种不匹配。

问:请描述一下事件驱动架构在微服务环境中的工作原理。

Schabowsky:EDA将数据从静态变为动态。比如说,数据库中的静态数据变成完全流动的数据——即使关键业务事件实时发生,数据仍可使用。光有充分利用REST的微服务是不够的。

问:请举事件驱动架构方面的一个实例。

Schabowsky:想象一下为银行发放的新信用卡实施营销活动。有了EDA,你可以更轻松地分析账户创建事件(比如期初余额和地址),并在后续营销活动中使用这些元数据。其他公司可以通过结合EDA和微服务,构建一种高度分布式、可扩展、可用、容错和可扩展的系统,这种系统能够实时使用、处理、聚合和关联大量事件或信息。

现代事件平台还必须协助DevOps自动化,并为开发人员提供几乎完全自助式的流程。企业需要能够在瞬息万变的环境下顺势而为。它们需要能适应其需求的应用程序,事件驱动微服务可以实现这一点。

问:事件驱动微服务方面的工具怎么样?准备就绪了吗?

Schabowsky:同步请求/回复微服务方面的工具已到位,但遗憾的是,数据收集和通信方面被严重忽视,这意味着微服务之间异步事件驱动交互方面的工具现在严重滞后。许多网关和服务网格或API管理解决方案专注于同步、请求/回复交换模式。要注意的是,这些工具并不与遗留系统集成起来。

我们以往看到的事件/消息传递工具与今天的敏捷开发方法不兼容,在DevOps或自助环境中无法顺畅地使用。但事件/消息传递最适合分布式计算的特性。缺少事件/消息传递工具的这种现状使组织无法奉行事件驱动理念,无法使用事件驱动架构来发掘微服务架构的潜力。

问:这时候编排有了用武之地?

Schabowsky:正如我在前面的服务分解悖论中提到,服务越小,它独自为最终用户提供的价值就越小。真正的价值来自这些微服务的编排。想想作曲家创作用到多种乐器的乐谱。然后将每个乐谱和每个音乐家视为微服务,实际上是复杂交响乐的一部分。如果企业有许多复杂应用程序,就需要这样的编排。微服务可能生成事件,但并不控制何时处理事件,这由其他服务来完成,因此需要微服务编排。

参考链接:https://www.zdnet.com/article/when-microservices-need-event-driven-architecture/

K8S中文社区微信公众号

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址