课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
微服务架构开发我们在前几期的文章中已经给大家介绍过很多次了,而本文我们就继续来学习一下,微服务架构拆分需要注意哪些问题。
1)未成功做出抽象
在实际开发过程中,大家都有一个体会,设计阶段只考虑了一些常见的服务,但是发现项目中有大量可以重用的逻辑,并应该做成单独服务。
当我们在做服务拆分时,遗漏了服务的结果是有一些业务逻辑被分散到各个服务中,并不断重复。
2)抽象程度过高
抽象程度过高的一个特征是得到的限界上下文极端的微小。
抽象程度过高带来的成本有:更多的微服务部署带来的运维压力、开发调试难度提高、服务间通信带来的性能开销、跨服务的分布式事务协调等。因此抽象不是越高越好,应根据实际业务需要和成本考虑。
那相应的,微服务到底应该多小呢?
业界流传一句话来形容,微服务应该多小:“一个微服务应该可以在二周内完成重写“。
这句话可能只是一句调侃,如果真的作为微服务应该多微的标准是不可取的。
微服务的大小应该取决于划分限界上下文时各个限界上下文内聚程度。
3)错误抽象
对微服务或DDD理解不够。模型具有二义性,被放到不同的限界上下文。
例如,订单中的收货地址、用户配置的常用地址以及地址库中的标准地址。
这三种地址虽然名称类似,但是在概念上完全不是一回事
假如架构师将”地址“划分到了标准地址库中,势必会造成用户上下文和系统配置上下文、订单上下文存在不必要的耦合。
【免责声明】本文系本网编辑部分转载,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题,请在30日内与管理员联系,我们会予以更改或删除相关文章,以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。