2同行回答
很遗憾，微服务拆分没有标准，更多是经验，以下内容是从我写的书籍上复制的。
我们从高内聚低耦合、业务模型、读写模式、演进式拆分、阶段性合并这些角度再来介绍服务拆分原则。
1.高内聚、低耦合
高内聚、低耦合是软件工程中的概念，在软件设计中通常用耦合度和内聚度作为衡量模块独立程度的标准，这个标准在微服务拆分中同样适用。从功能粒度来看，高内聚指每个服务尽可能只完成一件事（ 最大限度地 聚合）；低耦合指减少外部服务依赖，尽量避免服务调用服务。从数据库角度来看，每个服务都需要单独使用独立的数据库，如果外部的服务需要使用数据，则必须通过接口方式来调用，杜绝外部服务通过直 连 数据库的方式获取数据。
2.业务模型
有了高内聚低耦合的前提，就可以通过业务模型维度来做服务拆分，比如将用户、商品、订单、评论都拆分为独立的服务，把相关的业务都聚合在同一个服务中，这样不仅可以避免 跨 数据库所引发的数据一致性问题，还可以减少调用外部服务。这种拆分在初期阶段粒度会较粗，可以通过后续的迭代频率或吞吐量大小来衡量是否需要继续拆分。
3.按读写模式拆分
当业务量达到一定阶段时，就需要考虑按读写模式拆分服务，即把同一类型服务的读和写操作拆分到不同的服务上。比如，在正常情况下 User 表会被划分为用户服务（ user-service ），提供用户信息查询接口（ UserReadService ）和用户信息写入接口 (UserWriteService) ，假设线上用户的服务读写比例差距非常大，有 90% 的读操作和 10% 的写操作，此时可以考虑把 UserReadService 和 UserWriteService 分别拆分为独立的服务发布，同时增加 UserReadService 的副本数量，以保障服务的稳定性。
4.演进式拆分
微服务拆分是不可能一气呵成的，需要根据业务的发展来持续拆分和演进，称之为演进式拆分，在演进过程中一定要去积极了解业务及公司的发展方向。比如在微服务重构的初级阶段， App 首页的产品列表和搜索页的产品列表由同一个服务提供，在后续需求迭代中 App 首页的产品列表需求迭代非常频繁，如果仅仅将产品列表需求拆分成首页列表服务和搜索页列表服务是不行的，因为在后续迭代中需要首页列表服务做到个性化（即千人千面）的风格。所以，可以将产品列表服务拆分为如表 2-1 所示的服务。
收起正常拆分原则：1参考 AKF 扩展立方体 ；2前后端分离；3无状态原则；4 Restful 通信原则
收起