BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

Vaughn Vernon使用反应式DDD对微服务中的不确定性建模

| 作者 Thomas Betts 关注 5 他的粉丝 ,译者 薛命灯 关注 12 他的粉丝 发布于 2017年10月13日. 估计阅读时间: 3 分钟 | QCon北京2018全面起航:开启与Netflix、微软、ThoughtWorks等公司的技术创新之路!

亲爱的读者:我们最近添加了一些个人消息定制功能,您只需选择感兴趣的技术主题,即可获取重要资讯的邮件和网页通知

微服务和反应式模型虽然很强大,但也带来了不确定性。开发人员总是对消息驱动的系统持有疑问:

  • 有人接收到我发出的消息了吗?
  • 他们对消息做出回应了吗?
  • 消息的顺序会不会被打乱了?

Vaughn Vernon在DDD探索大会的演讲中提到,DDD是回答上述问题的基础。使用通用语言(Ubiquitous Language)来描述由边界上下文(Bounded Context)组成的系统可以降低分布式系统的复杂度。不确定性应该成为通用语言的一部分,比如边界上下文之间的交互问题。

Vernon是“Implement Domain Driven Design”和“Reactive Messaging Patterns with the Actor Model”的作者,他认为为项目创建好上下文映射是至关重要的。从实际情况来看,业务的核心领域总会包含多个边界上下文,而上下文映射体现了边界上下文之间的关系。在建立上下文映射关系时,要专注在团队之间的关系上,而不是去关注技术细节,比如究竟是使用REST还是使用RPC。Vernon说,“集成对象比如何集成更加重要”。

Vernon看到了反应式系统的发展趋势,反应式行为存在于微服务之中,同时又超越了微服务。这并非什么新概念,他说,Eric Evans早就在业界推广事件模式。其核心思想就是对过去发生的事件作出反应,进而达到和谐的状态。

微服务和反应式行为带来了不确定性,包括事件顺序的不确定性和事件的重复性问题。Vernon强调说,“就算你使用的是Kafka,认为自己是在按顺序消费消息,但其实是在自欺欺人。如果任何一个消息可能出现乱序,那么所有消息都有可能出现乱序,你要为之做好应对准备”。

Vernon认为这种不确定性是很难得到消除的,因为我们已经习惯于阻塞调用、数据库锁等事物,并总是期待事物是按照一定顺序进行的。在反应式系统里,一些长久以来的信念开始土崩瓦解。或许,开发者会本能地创建出门面(facade)来隐藏不确定性,写出传统的非反应式代码,但Vernon认为我们应该要反其道而行之。

Vernon总结了自己处理不确定性的方式——“更少的查询,更多的事件”。事件告诉我们在过去某个时刻发生了什么。我们不知道系统现在处于什么状态,只知道事件发生时的状态以及在这一过程中发生了哪些变化。如何对这些事件作出反应式属于业务决策,包括如何处理乱序问题。Vernon引用了Pat Helland的论文“Life Beyond Distributed Transactions”:“在一个不能依赖分布式事务的系统里,必须在业务层面管理不确定性”。

Vernon列举了几中不同形式的不确定性,并提供了用于管理不确定性的简短代码。他强调这些代码只是业务决策的实现。业务必须拥抱不确定性,必须让业务决策者来对其进行建模,而不是在软件开发团队内部完成这件事情。不要通过创建门面来隐藏不确定性,而是尽你所能对不确定性进行建模。

查看英文原文:Vaughn Vernon Uses Reactive DDD to Model Uncertainty in Microservices

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT