将系统分解为微服务的策略
极客时间编辑部
讲述:丁婵大小:1.16M时长:02:32
几年前,Internovus 的 CTO 弗拉迪·克诺夫(Vladik Khononov)和他的团队决定开始使用微服务,但是几个月后,他们发现自己陷入了巨大的混乱之中。因为他们在 serverless 框架、平台和消息机制上投入了精力,但是在思考如何将系统分解为微服务方面却思考很少。
对他们来说,起始的信条就是服务越小越好。这直接导致他们构建了一个分布式单体结构(distributed monolith),在接下来的几年中,他们一直试图摆脱这些微小的服务,并且评估了不同的分解策略。
克诺夫指出,通用语言(ubiquitous language)在领域驱动设计(Domain-Driven Design,DDD)中是基础实践,该实践的一种实现方式就是用领域专家的语言与他们进行对话。
目前,克诺夫还没有找到一种简单的方式来评估一个系统的设计,但是他相信,现在已经有了足够多的启发式设计准则将系统分解为微服务。他认为最有用的几项包括:
始终分解至限界上下文等级。除非有充分的理由,否则不要进一步分解,分布式系统有它们自己所面临的挑战。
核心子域是公司挣钱的区域。在进行分解时,要确保获取领域的知识和恰当的子域。
购买或采用通用子域。
为了支持核心域,需要支持子域。它们通常非常稳定和简单,在早期阶段就可以进行进一步的分解,直至使其成为实体服务。
采用一致性的需求,来寻找必须放到同一个服务中的函数或方法。
确保事件是显式和自描述的。使用私有事件作为实现细节,而将公共事件作为服务的公开接口。
寻找按照相同频率进行变化的服务,它们可能进行合并,减少复杂性。
评估每个服务的接口。如果觉得服务范围太广的话,那么它可能会拆分为更小的服务。
克诺夫总结道,随着系统中服务的平均规模变得越来越小,将会从一个大泥球般的单体系统,通过限界上下文实现相对较大的服务,进而转化为微服务。但是,如果继续让服务变得更小的话,那么最终将会形成一个分布式的大泥球。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》,如需阅读全部文章,
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示,欢迎踊跃留言。
收起评论