微服务拆分的原则?

按分享的经验来看,是需要将无关的功能都进行拆分,我理解就是原子化拆分。但现实业务场景中对于传统的应用系统,已经存在了大量的业务逻辑处理。这种迁移是一个比较长期且痛苦的事情,如何解决?

3回答

尘世随缘尘世随缘  技术总监 , 上海某互联网金融公司
counship俞好龙三味线等赞同了此回答
系统的迁移或者重构本身就是一个非常漫长和痛苦的过程,可以先以接口的方式来迁移。在网关或者Nginx层做分发。比如/user/query_user这个接口,20%的流量切到新的服务上,80%的流量还是老的服务上。万一新系服务出现问题还可以再迁移到老的服务。等一段时间后流量逐步增加 50%,8...显示全部

系统的迁移或者重构本身就是一个非常漫长和痛苦的过程,可以先以接口的方式来迁移。在网关或者Nginx层做分发。比如/user/query_user这个接口,20%的流量切到新的服务上,80%的流量还是老的服务上。万一新系服务出现问题还可以再迁移到老的服务。等一段时间后流量逐步增加 50%,80%,100%,然后这个接口老系统就废除了,由新服务来提供服务。以此类推。

收起
 2019-07-10
浏览340
狄俄尼索斯狄俄尼索斯  软件架构设计师 , UProject
前面有同学答了DDD拆分,这一套方法论太理论化了,实际场景很难用上。根据经验来看,已有系统尽量不要动,新开发功能用微服务架构,可以从已有代码中复用代码,但是千万别大规模修改已有代码。 新的微服务划分时候,有几点原则可参考一下: 按功能重要程度拆分不同微服务 数据尽量内聚,...显示全部

前面有同学答了DDD拆分,这一套方法论太理论化了,实际场景很难用上。根据经验来看,已有系统尽量不要动,新开发功能用微服务架构,可以从已有代码中复用代码,但是千万别大规模修改已有代码。

新的微服务划分时候,有几点原则可参考一下:

  1. 按功能重要程度拆分不同微服务
  2. 数据尽量内聚,不要拆出太多分布式事务,当前分布式事务是业界难题
  3. 依赖分层,不要有循环依赖
收起
 2019-07-20
浏览224
李宁李宁  软件架构设计师 , 博云
服务拆分大的前提可以参考DDD领域驱动设计。进一步讲,业务需要考虑三方面问题:1.服务边界切分;2.服务依赖梳理;3.服务交互规范标准;服务边界切分需要依赖”低耦合,高内聚“的原则,明切业务单元的边界,尽可能减少同一个业务的不同服务单元的调用依赖;服务依赖,需要明确一个业务构成...显示全部

服务拆分大的前提可以参考DDD领域驱动设计。进一步讲,业务需要考虑三方面问题:1.服务边界切分;2.服务依赖梳理;3.服务交互规范标准;服务边界切分需要依赖”低耦合,高内聚“的原则,明切业务单元的边界,尽可能减少同一个业务的不同服务单元的调用依赖;服务依赖,需要明确一个业务构成过程中的服务依赖关系,避免出现回环依赖,双向依赖的场景。最好的方式是实现链式依赖调用;服务交互规范,从协议以及数据传输规范层面说明服务与服务之间的交互方式,包括采用的通信协议,数据传递格式等;
服务迁移的过程中,首先要考虑接口变化情况,对于前后端分离的架构,可以采用restful的方式进行,尽可能避免接口的平凡变更。同时复用原有的业务代码实现。线上迁移过程中,可以利用负载路由的控制实现逐步发布。

收起
 2019-07-16
浏览266

提问者

beatles_wang项目经理, 中国大地财产保险股份有限公司

问题状态

  • 发布时间:2019-07-10
  • 关注会员:4 人
  • 问题浏览:1112
  • 最近回答:2019-07-20
  • 关于TWT  使用指南  社区专家合作  厂商入驻社区  企业招聘  投诉建议  版权与免责声明  联系我们
    © 2019  talkwithtrend — talk with trend,talk with technologist 京ICP备09031017号-30