企业微服务建设难点:微服务拆分原则及思路建议探讨?

服务拆分粒度应该多大?什么样的服务算好拆分比较好的服务?很多团队面临这样的问题,服务到底如何拆分,怎么样的拆分是合理的,拆分后新的微服务框架和老的系统如何做兼容运行,老系统如何逐步平滑过渡到微服务架构中,而且不影响线上业务运行,也不能影响正常的项目迭代。其实,业界没有标准的方式来指导如何做拆分。那作为银行企业,在微服务拆分这块有没有什么比较好的原则或者思路建议?

3回答

尘世随缘尘世随缘  技术总监 , 上海某互联网金融公司
sdsfan80赞同了此回答
什么样的服务算拆分比较好的服务:判断一个服务拆分的好坏,就看微服务拆分完成后是否具备服务的自治原则,也就是这个服务自由自己的功能。比如用户服务,只负责用户的增删改查,如果又提供了订单查询的服务,那么就违背了服务自治原则。服务拆分粒度应该多大:先按照业务功能分解模...显示全部

什么样的服务算拆分比较好的服务:判断一个服务拆分的好坏,就看微服务拆分完成后是否具备服务的自治原则,也就是这个服务自由自己的功能。比如用户服务,只负责用户的增删改查,如果又提供了订单查询的服务,那么就违背了服务自治原则。
服务拆分粒度应该多大:先按照业务功能分解模式以功能为维度拆分比如:
用户管理:管理用户相关的信息,例如注册、修改、注销或查询、统计等。
商品管理:管理商品的相关信息。
业务功能分解模式另外的优势在于在初级阶段服务拆分不会太小,等到业务发展起来后可以再根据子域 方式来拆分,把独立的服务再拆分成 更小的服务,最后到接口级别服务。
从银行来看,建议新系统或者非交易系统可以尝试使用微服务,拆分方式和粒度参考上述观点,这个过程主要是积累微服务实施的经营。

收起
 2020-04-25
浏览252
顾黄亮顾黄亮  技术总监 , 苏宁消费金融有限公司
sdsfan80赞同了此回答
某大神总结的 单一职责、高内聚低耦合 服务粒度适中 考虑团队结构 以业务模型切入 演进式拆分 避免环形依赖与双向依赖 显示全部

某大神总结的

  1. 单一职责、高内聚低耦合
  2. 服务粒度适中
  3. 考虑团队结构
  4. 以业务模型切入
  5. 演进式拆分
  6. 避免环形依赖与双向依赖
收起
 2020-04-21
浏览276
匿名用户匿名用户
这个问题太难回答了。我认为微服务拆分要从两个方面考虑,一方面业务逻辑的拆分,一方面架构拆分。两个维度一起考虑会达到很好的效果。单从业务上去说什么客户中心、交易中心、决策、清算,整体服务调用链路是比较乱的。单从架构上去考虑拆分,银行业务是很琐碎的,特别啰嗦,应对变...显示全部

这个问题太难回答了。
我认为微服务拆分要从两个方面考虑,一方面业务逻辑的拆分,一方面架构拆分。两个维度一起考虑会达到很好的效果。
单从业务上去说什么客户中心、交易中心、决策、清算,整体服务调用链路是比较乱的。单从架构上去考虑拆分,银行业务是很琐碎的,特别啰嗦,应对变化不断的业务场景又不能快速迭代。

收起
 2020-04-14
浏览372
yinzhijie 邀答

提问者

yinzhijie系统工程师, 浦发

问题状态

  • 发布时间:2020-04-13
  • 关注会员:4 人
  • 问题浏览:1118
  • 最近回答:2020-04-25