如何设计可扩展架构

架构设计复杂度模型

业务复杂度和质量复杂度是正交的

业务复杂度

业务固有的复杂度，主要体现为难以理解、难以扩展，例如服务数量多、业务流程长、业务之间关系复杂

质量复杂度

高性能、高可用、成本、安全等质量属性的要求

架构复杂度应对之道

复杂度等级	业务复杂度	质量复杂度	架构模式
1	低	低	框架，如LAMP、SSH
2	高	低	SOA、DDD、微服务
3	低	高	集权、缓存、Reactor、分片、副本
4	高	高	融合所有模式

架构设计环

可扩展复杂度模型

可扩展（extensibility）：系统适应变化的能力，包含可理解和可复用两个部分

可伸缩（scalability）：系统通过添加更多资源来提升性能的能力

可扩展复杂度模型

“拆分”复杂度分析和设计

拆分复杂度模型

拆分粒度

两个复杂度

内部复杂度

又称为“单体复杂度”，指单个对象内部的复杂度，例如传统的单体系统，所有业务都在一个系统里面

可以用参与的开发人数来衡量单个拆分对象的复杂度（三个火枪手原则）

例如：3个人负责一个子系统/子模块是比较合理的，20个人在同一个子系统上开发，则内部复杂度过高

外部复杂度

又称为“群体复杂度”，指拆分后的多个对象之间的关系复杂度

可以用业务流程涉及对象数量来衡量外部复杂度

例如：1次用户请求需要5个子系统参与是比较合理的，如果需要20个子系统参与，则外部复杂度过高

平衡的艺术

内外平衡原则

内部复杂度和外部复杂度是天平的两端，一方降低，另一方必然升高，关键在于平衡

先粗后细原则

如果你把握不准，那么就先拆少一些，后面发现有问题再继续拆分

“封装”复杂度分析和设计

封装复杂度模型

预测的艺术

2年原则

只预测2年内的变化，不要试图预测10年后的变化

3次原则

预测没有把握就不要封装，等到需要的时候重构即可

封装的技巧