扩展性

添加新功能时对现有系统的其它应用无影响，这就意味着需要取预测系统的未来变化，但是预测变化本身又是复杂的：

• 不能每个设计点都考虑可扩展性
• 不能完全不考虑可扩展性
• 所有的预测都存在出错的可能性

为了降低预测变化的复杂性，首先对于预测的未来不应太远，其次可以使用分层隔离变化

实现可扩展的架构设计：拆分

扩展维度

• 横向扩展：增加机器资源以提升性能与处理能力
• 纵向扩展：增强单机资源以提升

应用扩展

实际应用场景中，一般会是3种扩展方式组合使用：

X

无状态服务，水平克隆出许多系统，通过负载均衡分配请求

有状态服务则需要进行状态剥离，使用外部服务器存储状态

这种扩展可以弹性扩缩容，做性能规划也可以通过量化的方式计算得到，不用考虑到业务，复制出来的机器环境应该都是同构的

Y

基于功能或者服务分割

不同的服务功能、资源互不干扰，数据一致性可以得到保证。这种扩展与业务耦合在一起

Z

面向查找分割，基于用户、请求或者数据分割

加速读操作，可以实现有状态服务，是一种技术上的扩展，没有业务耦合

数据扩展

ES的数据存储架构就是通过扩展X、Z的方式来分布的

当我们根据业务来扩展时，就是扩展的Y

X

• 传统关系型数据的读写分离 一写多读
• NoSQL的多副本
• 缓存

没有强一致性 只有最终一致性 但是复制起来很简单 多副本的数据可用性很高

Y

根据不同的信息类型，分割为不同的数据库，即分库，例如产品库，用户库等

拥有数据故障隔离、强一致性的优势 但是该方式与业务耦合

Z

按照一定算法，进行分片

可以加速读、没有扩展上线，不需要考虑业务、数据强一致性

组织扩展

每个团队内部有XZ扩展，各个团队通过Y划分

流程扩展

常见的流程：ITIL、ITSM、6西格玛、CI/CD

架构流程：JAD联合架构设计、ARB架构评审会

CMMI软件成熟度模型来评价流程

扩展性实现

X：无状态化 + 容器 + Serverless

Z：多副本 + 读写分离 + 数据分片

Y：业务分离 + 服务化

• 使用消息队列对上下游应用解耦
• 使用分布式服务将业务与服务分离，服务都是一些可复用的服务，添加新功能时，只要调用已有的服务即可