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

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

某大神总结的

1. 单一职责、高内聚低耦合
2. 服务粒度适中
3. 考虑团队结构
4. 以业务模型切入
5. 演进式拆分
6. 避免环形依赖与双向依赖

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