微服务架构思考

一、从需求的角度去考虑

服务拆分的缺点：

1.每个服务都需要单独的机器部署，浪费资源,增加运维负担；
2.服务拆分后会产生分布式事务、跨库事务、跨库分页；
3.服务较多时，服务之间的依赖关系复杂，不好治理；
4.拆分后不便于排查问题，不便于debug；
5.特殊业务的服务归属问题难以决定，当一个接口即可以放在A这边，又可以放在B这边或放在A这边A觉得不合适，放在B这边B觉得也不合适，即A觉得A要解耦，B应该内聚，而B恰恰相反，觉得自己的服务要解耦，让其他服务内聚，会出现双方架构上的争论；
7.技术难度增加：一些服务拆分的细节问题需要考虑，定时任务问题，缓存问题等；

服务拆分的优点：

1.将服务拆分后代码整洁，模块分明，逻辑清晰，降低业务复杂度，减少不同业务之间的表的关联查询；
2.服务拆分将提高迭代速度和质量：服务拆分后一个模块的版本回退不会影响另一个（如果API不变的话），这样可以先开发后决定是否提交测试；开发之间的依赖较少，可以流水线似的进行交付；
3.以服务为单位建立AB双角色的负责人机制：传统的以业务为单位建立负责人机制容易出现甩锅现象，以服务为单位时，你在代码上为别人提供服务的同时也要在开发过程中提供相关的服务；
4.降低耦合，一个模块更新升级对其他模块影响小
5.负载：
6.水平扩展、垂直拆分容易
7.让各模块职责明确，边界清晰，业务不会乱成一团，否则新加功能时只知道往整体塞，但不知道各个业务之间的联系和职责，导致最后系统越来也复杂。
8.一个人一个模块可以伴随着个人的成长进行模块的优化，前提是需要经常由架构做代码review。

服务拆分的粒度：

通过确定哪些优点你优先考虑，哪些缺点你可以接受来决定服务的粒度。

二、从迭代的角度去考虑

每个迭代会引起系统代码的变动，从下面三个维度去考虑架构是否方有以下耦合

依赖的两个层次：

1.系统间依赖：一个系统的变动影响其他系统;
2.系统内依赖：一个模块的变动影响同一个系统内的其他模块；

影响的两个层次：

1.接口依赖：一个单元接口参数的变动会引起另一个单元实现的变动
2.服务依赖：一个单元停止服务会导致另一个单元不能正常提供服务

变动的两个层次：

1.改变依赖：一个单元的修改或一个接口的修改会影响到另一个单元
2.新增依赖：一个单元的增加或一个接口的增加会影响到另一个单元

服务拆分的粒度：

服务的拆分需要根据具体业务的重要性来决定细到哪一个层次。