微服务架构时遇到的第一个问题就是如何划分服务的边界。
在实际项目中通常会采用两种不同的方式划分服务边界，即通过业务职能(Business Capability)或是 DDD 的限界上下文(Bounded Context)。
由于没有一种算法和固有规则让我们参考，导致我们只能像创造艺术品一样去划分服务。
只要它好看、合理、高效即可。
而艺术品，就代表了不同的人、不同的业务、不同的管理方式会带来不同的划分方式。
按什么划分
按接口（业务）分
比如把商品展示的接口都放到一个单体写，那样这个单体挂了，购买的人不受影响。
不同的服务解决不同业务问题。
问题就是公共模块（鉴权、底层方法）我要写多套。
适用于中型团队，因为公共模块也不是天天改。
最大程度将业务耦合性降低，A模块挂了不影响B模块，而且模块可以分配给不同的人，单独治理。
线下麻烦点，但是线上稳定点。
举例：账号模块，此时可能是每个单体里面都有一套账号数据生成代码，然后用同一个git维护，一旦更新了就所有单体都要更新。
尽管也是模块化逻辑，但是最终它还是会打包并部署为单体式应用。
问题
- 代码冗余严重。
- 单机扛不住只能上负载均衡，查日志可能要查多台机器。更新也是，要批量上代码。
- 数据库难以隔离，尤其是用户这种量最多的数据，可能一个bug导致全盘慢。
- 故障无法转移，A机器挂了， B机器的代码是一样的，基本也会挂。
- 影响的是一个整体业务，无法降级，无法熔断。挂就是一个业务挂。
按模块（数据）分
不同的服务提供不同的数据。
我认为这才是真正的微服务，服务的切分，如果不切分库，那将毫无意义。
适用于大型公司，业务量很大，每个模块都是一个小团队负责。
最大程度减少沟通成本。
因为当人员数量上来后，最大的消耗并不是编码时间，而是沟通时间。
举例：我将账号集中到一个服务，所有人需要账号信息都找我来拿，然后我这边用负载均衡、集群保证我的高可用，如果有人要更新用户数据，要我走我的接口，要么走我的消息队列，我来维护账号数据的一致性。
围绕业务或者数据构建，服务关注单一业务。服务间采用轻量级的通信机制，可以全自动独立部署，可以使用不同的编程语言和数据存储技术。微服务架构通过业务拆分实现服务组件化，通过组件组合快速开发系统，业务单一的服务组件又可以独立部署，使得整个系统变得清晰灵活。
分多细
细的好处：
- （1）服务都能够独立部署
- （2）扩容和缩容方便，有利于提高资源利用率
- （3）拆得越细，耦合相对会减小
- （4）拆得越细，容错相对会更好，一个服务出问题不影响其他服务
- （5）扩展性更好
细的坏处：
- （1）拆得越细，系统越复杂
- （2）系统之间的依赖关系也更复杂
- （3）运维复杂度提升
- （4）监控更加复杂
- （5）出问题时定位问题更难
微的粒度还关乎着库的分离。
怎么选择
我的建议是：
一步步来
其实架构真的是分久必合、合久必分。
- 当你觉得两个代码没有什么业务耦合的时候，就可以分离了。
- 当你觉得一个数据要调用多个服务的，就要合并了。
在最开始在对业务领域不是特别熟悉的时候，按照部门职能进行划分，例如账号、财务等。
- 注意划分的时候要闭环，不要相同的功能散落到几个部门当中
在系统稳定之后，积累了相关的业务经验和微服务开发经验之后，再考虑使用 DDD 限界上下文进行划分
- 如果可以闭环的解决一个用户场景，那么它应该是一个微服务
- 还可以根据访问频率进行区分划分，将用户高频访问的部分划分为一个服务
- 还可以根据读写进行划分
- CQRS: 将应用程序分为两部分：命令端和查询端。命令端处理程序创建，更新和删除请求，并在数据更改时发出事件。查询端通过针对一个或多个物化视图执行查询来处理查询，这些物化视图通过订阅数据更改时发出的事件流而保持最新。
举例：
- 账号服务，开始是一个服务，只有昵称、头像、性别等。
- 后面加入了VIP、装备系统、背包等等。
- 于是把这些都拆成了一个个服务，毕竟是没有耦合关系的。
- 后来发现取一个用户的数据，需要调用七八个子服务，好麻烦，代码合并又很难受。
怎么办？
架构就是一层加一层。
再加个中间层，用来组装数据，需要账号所有信息的就调用它就好了。
对外聚合，对内拆分。
总结
架构是慢慢演进出来的，要根据业务和实际环境来选择架构和演进架构。
持续迭代，持续重构。