一般系统的服务划分有以下两种维度： 按模块划分 这个比较适用于偏业务的场景：复杂的系统，最好先按业务领域横向拆分成可独立部署的子系统，每个子系统内部再按技术纵向拆分
一般系统的服务划分有以下两种维度：
按模块划分
这个比较适用于偏业务的场景：复杂的系统，最好先按业务领域横向拆分成可独立部署的子系统，每个子系统内部再按技术纵向拆分成不同的子模块。
按角色划分
这个比较适用于基础服务类的场景：一个大系统，每个服务看起来关联都很紧密，存在相互的调用关系。这时候可以考虑它们各自承担的角色和使命。
核心原则
单一职责：能不能用一句话说清楚这个服务的职责？非要分成两句话，那就分成两个服务。
在核心原则的基础上，符合下面的原则是一个比较好的实践：
松散耦合原则
可复用性原则
服务自治原则
可发现性原则
可组合性原则
服务自治、可发现性相对难理解一些，展开一下。
服务自治
当一个服务的逻辑单元由自身的领域边界内所控制，不受其他外界条件的影响（外界条件带有不可预测性），且运行环境是自身可控，完全自给自足，我们认为这个服务是自治的。
自治的服务自身可以很好的对稳定性做把控。
可发现性
因为服务是被用来复用的，如果在服务设计过程中，并不能发现一个已经存在的服务，而需要重新建立多个同样逻辑元旦的服务，会极大增加管理和维护成本。
服务发现主要有两种：
1.设计时发现（人）
服务设计人员和研发人员在研发一个新的服务时，可以通过搜索服务仓库的元数据信息，查看服务仓库是否已存在此服务，没有才重新开发。
2.运行时发现(程序)
服务的消费者可以通过服务注册中心查到特定服务的接口调用地址调用。
要根据系统的规模和人员配置情况。
比如如果系统一个系统的日活跃用户在万级和千万级，粒度肯定是不一样的。同样，基于系统规模带来的产出，那么开发人员数量也会相应不同。比较好的一个实践是一个人独立负责一个到两个服务。多人维护一个服务，交互成本非常高。
关注静儿公众号，不定期漫画技术推送~