服务拆分粒度应该多大?什么样的服务算好拆分比较好的服务?很多团队面临这样的问题,服务到底如何拆分,怎么样的拆分是合理的,拆分后新的微服务框架和老的系统如何做兼容运行,老系统如何逐步平滑过渡到微服务架构中,而且不影响线上业务运行,也不能影响正常的项目迭代。其实,业界没有标准的方式来指导如何做拆分。那作为银行企业,在微服务拆分这块有没有什么比较好的原则或者思路建议?
什么样的服务算拆分比较好的服务:判断一个服务拆分的好坏,就看微服务拆分完成后是否具备服务的自治原则,也就是这个服务自由自己的功能。比如用户服务,只负责用户的增删改查,如果又提供了订单查询的服务,那么就违背了服务自治原则。
服务拆分粒度应该多大:先按照业务功能分解模式以功能为维度拆分比如:
用户管理:管理用户相关的信息,例如注册、修改、注销或查询、统计等。
商品管理:管理商品的相关信息。
业务功能分解模式另外的优势在于在初级阶段服务拆分不会太小,等到业务发展起来后可以再根据子域 方式来拆分,把独立的服务再拆分成 更小的服务,最后到接口级别服务。
从银行来看,建议新系统或者非交易系统可以尝试使用微服务,拆分方式和粒度参考上述观点,这个过程主要是积累微服务实施的经营。