分而治之应该把握哪些原则呢

我们都知道，分而治之是一种处理复杂问题的通用方法，在系统架构中也是一种很重要的手段，架构的核心思想便是分而治之，那么，我们在使用分而治之这个核心思想的时候，应该把握哪些原则呢？

业务原则

1. 单一责任原则：对于一个微服务而言，具有有限的业务范围，可以帮助我们满足服务开发和交付的敏捷性；
2. 适当的边界：关注微服务的功能范围，一个服务的大小应该等于满足某个特定业务能力所需要的大小；
3. 业务分层： 从整体规划上把业务分层，形成单向依赖，避免微服务之间的网状依赖关系；
4. 颗粒度递增：设计初期先把业务划分到尽可能细，然后依据其它原则合并到适当颗粒度；
5. 非唯一依赖：至少被2个以上其它微服务依赖的功能模块，才有必要独立成一个微服务。

技术原则

1. 部署独立性：能独立于其它微服务部署，一个微服务故障不影响其它微服务；
2. 动态扩展：每个微服务都可以动态的进行x轴和z轴的扩展，并适应云环境下的自动化部署；（ 参考这里 ）
3. 领域和应用解耦：提供数据操作能力的领域服务和执行业务逻辑的应用服务解耦；
4. 避免产生频繁的跨库查询；
5. 避免产生频繁的分布式事务。

治理原则

1. 在业务分层的基础上，根据业务细分规则，对微服务分组；
2. 各个分组之间通过API网关集成；
3. 通过API网关实现级轻量级消息路由，鉴权；
4. 运行时管理，如服务降级，限流，监控等可在API网关实现，让微服务功能纯粹；
5. 避免通过数据库集成；
6. 避免部署多个版本来兼容。

分解的过程：面对一个系统，特别是前人没有做过的新系统，通常难以一下子设计出合适的架构。在架构设计的初期，通常都要经历一个不断探索的阶段。在架构设计过程中，架构分解是必不可少的的关键步骤。如何进行架构分解？从哪里入手开始进行分解？我们需要有一个架构分解的过程模型来指导分解过程，启发和探索架构分解的维度和线索，提高架构分解的效率。