BT

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

Vaughn Vernon谈微服务和领域驱动设计

| 作者 Jan Stenberg 关注 34 他的粉丝 ,译者 谢丽 关注 11 他的粉丝 发布于 2016年8月3日. 估计阅读时间: 3 分钟 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。

虽然单体应用程序也可以实现相当好地建模,但它们常常会演变成一团乱麻。究其原因是单体应用程序内的多个领域模型错综复杂地交织在一起。根据Vaughn Vernon的经验,这种情况在几周或几个月内就会出现。在今年早些时候举行的Scala Days大会上,他在演讲中表达了这样的观点。

Vernon是《实现领域驱动设计》和《通过Actor模型实现响应式消息处理模式》这两本书的作者。他指出,当应该保持独立的领域模型混在了一起,互相无法区分时,就很难或者不可能和业务及领域专家一起从逻辑上推断模型,让应用或系统比单体应用程序还糟糕。

单体应用程序的一个替代方案是微服务,但我们如何定义一个微服务?它有多大?有时候,人们提出使用代码行定义微服务的大小,Vernon见过以数十行为标准的,也见过一上千行为标准的,但他不主张采用这样一种既宽泛又不准确的定义。

此外,有些企业号称有数以百计的微服务,但又不知道或者不关心准确数值。他们认为,不值得花费时间和精力去弄清它们的实际使用情况,因为,只是让它们运行起来的话,成本会很低。Vernon对此作出了回应。他不同意这样的观点。他指出,别的不说,基础设施对于许多微服务如何运行,如何在故障情况下保持弹性,有重大的影响。

Vernon建议采用一种规定性的方法确定一个系统里微服务的大小和数量:使用领域驱动设计(DDD)的方法,尤其是有界上下文。他指出,在微服务社区里,有时候会将有界上下文定义成只有一个实体,但他发现那不大可能。相反,Vernon支持借助通用语言在大小确定的有界上下文中建模微服务,并提到了Sam Newman的著作《构建微服务》。

在开始使用微服务的时候,Vernon建议从每个有界上下文一个微服务开始。他认为,即使我们能够在一个有界上下文中找出多个本身可以视为微服务的组件,但它们的内聚性和协同关系意味着它们应该一起放在一个服务里。他还建议,一个服务和一个有界上下文应该是一个可部署的单元。尽管如此,根据经验,他们可能会采用更细的粒度,为一个有界上下文创建更多的微服务和可部署单元,可能是因为扩展性方面的原因。

除了实体之外,通用语言还包括命令和事件消息。通过发布最终供其他微服务使用的事件,消息可以用在事件驱动的架构中。在演讲总结阶段,Vernon展示了一个构建微服务的例子。该例子使用了Actor模型,并使用AkkaScala实现。

查看英文原文:Vaughn Vernon on Microservices and Domain-Driven Design

评价本文

专业度
风格

您好,朋友!

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

获得来自InfoQ的更多体验。

告诉我们您的想法

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

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

应用层面的事还是不要和领域模型混为一谈比较好 by l db

我是觉得部署,服务划分这些应用层面的事,最好是和领域模型的规划设计不要扯上直接的关系比较好。事实上有大量的服务是会跨边界的,但有一致性的要求,如果按这么做就需要做分布式事务,然而分布式事务目前还并不能在理论层面优雅的保证,也会增加很多复杂度。

允许的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通知我

1 讨论

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


找回密码....

Follow

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

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

Like

内容自由定制

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

Notifications

获取更新

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

BT