将系统分解为微服务的策略是什么

发布时间:2022-01-14 09:21:18 作者:柒染
来源:亿速云 阅读:135

今天就跟大家聊聊有关将系统分解为微服务的策略是什么,可能很多人都不太了解,为了让大家更加了解,小编给大家总结了以下内容,希望大家根据这篇文章可以有所收获。

几年前,Vladik Khononov和他的团队决定开始使用微服务,但是几个月后他们发现自己陷入了巨大的混乱之中。他在最近于伦敦Skills Matter举行的DDD eXchange 2018会议上指出,造成这一现象的原因在于,他们只专注于采用酷炫的新技术,而没有关注更加基础的东西,比如模块化以及如何实现模块化。他们在serverless框架、平台和消息机制上投入了精力,但是在 思考如何将系统分解为微服务方面却思考很少,换句话说,也就是如何寻找边界并将不同的功能按照边界进行划分。

Khononov是Internovus的CTO,对他和他的团队来说,起始的信条就是服务越小,它就会越好。这直接导致他们构建了一个分布式单体结构(distributed monolith),在接下来的几年中,他们一直试图摆脱这些微小的服务并且评估了不同的分解策略。

限界上下文(Bounded context)

Khononov指出通用语言(ubiquitous language)在领域驱动设计(Domain-Driven Design,DDD)中是基础实践,该实践的一种实现方式就是以领域专家的语言与他们进行对话。有时候,你会发现对于相同的业务概念,他们会有不同的心智模型,或者使用相同的术语描述不同的理念,如果这样的话,就预示着这些理念属于不同的限界上下文。从一开始,Khononov和他的团队就使用这些方法来发现定义服务的边界,每个边界内都会成为一个服务。他指出,这些服务代表了很广泛的业务领域,有时候会导致一个限界上下文涵盖多个业务子域。

业务子域

下一步,他们使用这些业务子域作为边界,然后为每个业务子域创建一个服务。在Khononov的经验中,子域和服务之间建立一对一的关系是DDD社区非常常见的方式,但是他们并没有满足于此,而是继续努力实现更小的服务。

业务实体

深入研究子域,他们发现了业务实体和流程,然后他们将其抽取到单独的服务中。开始的时候,这种终极方式失败得很惨,但是Khononov指出在随后的项目中,它取得了更大的成功。

 

就这三种策略来说,Khononov指出,使用限界上下文能够帮助他们找到最大的有效单体边界,然而,尽管它是一个可行的工作模型,但是他认为这种方式并没有很好地匹配微服务的理念。在业务子域和实体间选择的时候,他认为最好的分解等级依赖于正在构建的系统及其用例。他强调,微服务的理念实际上并不是关于单个服务内部如何实现的,而是关于服务之间如何交合和耦合的。

系统分解为微服务的阈值是由微服务所属的用例来定义的。

Khononov还没有找到一种简单的方式来评估一个系统的设计,但是他相信现在已经有了足够多的启发式设计准则,帮助我们将系统分解为微服务。他认为最有用的几项包括:

Khononov在总结中指出,随着系统中服务的平均规模变得越来越小,你将会从一个大泥球般的单体系统,通过限界上下文实现相对较大的服务,进而转化为微服务。但是,他强调,如果你继续让服务变得更小的话,那么最终将会形成一个分布式的大泥球。

看完上述内容,你们对将系统分解为微服务的策略是什么有进一步的了解吗?如果还想了解更多知识或者相关内容,请关注亿速云行业资讯频道,感谢大家的支持。

推荐阅读:
  1. 微服务是什么?微服务架构又是什么?
  2. 1.1 将序列分解为多个变量

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

微服务

上一篇:interfac与类class互相转换的方法是什么

下一篇:springboot整合quartz定时任务框架的方法是什么

相关阅读

您好,登录后才能下订单哦!

密码登录
登录注册
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》