对系统可扩展性性的理解

一、可扩展性定义

可扩展性指系统为了应对将来需求变化而提供的一种扩展能力，当有新的需求出现时或容量出现问题时，系统不需要或者仅需要少量修改就可以支持，无须整个系统重构或者重建。基本可以定义为，系统架构扩展性=系统架构适应业务变化能力+容量变化的能⼒。

二、架构设计标准

可扩展性是架构设计的一部分，需要遵循架构设计的标准
合适：考量系统和业务的矛盾点，比如一个只有几QPS的系统是没有必要搞服务拆分和微服务这一套的，只是能够服务好业务，做好业务支持就可以了。
简洁：尽量少的引入一些中间件和设计模式，中间件和设计模式会造成系统一些额外的维护成本
可演进：为未来业务的发展留好足够的空间，如大规模重构后和业务发展不一致，这就是严重的错位。

三、可扩展性复杂性来源

系统架构扩展性设计复杂度来源-变化和规模：
能预测变化吗？架构师通常在设计的时候会进行预测，但预测本身存在一定的概率失败的可能，如果要把每一个系统的每一个变化点都考虑到的话，会增加很多不必要的工作量，就会违背“合适、简洁”的架构原则，通常情况下对于变化会缺乏预测的标准，只能通过架构师、团队负责人根据自己的经验进行判断。即使预测非常准确的情况下，如何在实现上能够准确的应对变化，也是非常有难度的，为了增加扩展性需要梳理并组织组件与组件的关系、类与类之间的关系，这些梳理和重组的过程本身反过来也会增加系统的复杂度。

规模复杂分为业务规模复杂和容量规模复杂，在一些B端系统中，业务逻辑、历史逻辑、功能分支特别多，在发展过程中拆分的服务也很多，这就造成了业务复杂的必要条件，此外还有一些复杂的逻辑，多个微服务之间的依赖等，共同组成了业务的复杂性。容量规模主要看系统所应对的请求量，比如10QPS和100万QPS在扩展性设计上的考量是完全不一样的。在数据层面3万的数据和3亿的数据，在数据存储层面的设计是完全不一样的，是不是要分库分表，需不需要引入缓存这都是扩展性需要考量的因素。

四、可扩展性目标

虽然在系统的可扩展性方面没有标准化的公式，但依然可以尽量量化一些目标，系统架构扩展性设计的目标：在“合适、简洁、可演进”的原则下保持开发成本⽐变化收益处于O(n) ~O(log(n))之间，其基本含义是做相似或者同样的需求所花费的时间要比之前所花费的时间要少，最终会达到O(log(n))这样一种状态，随着接入的需求的增加而花费的成本并没有明显的增加。

五、可扩展性方法

总体来说是将问题进行拆解，封装和隔离变化，将复杂的问题简单化，把问题的规模缩小，通过这种方式尽可能的降低每次改动的影响和范围，合理的拆是扩展设计中的核心，下面从面向业务和面向容量两个部分去看如何进行拆解。

5.1、面对业务拆分

在拆分之前往往需要一些依据，这些依据源于对于业务的分析，业务的过去、业务的现在和业务的未来趋势等，行业内有不同的方法论，如用例分析，四色建模、领域驱动等，基本都是领域设计中常用的一些方法，其用意是帮助相关同学理清业务特征。首先是架构纬度的拆分，具体来看有服务化架构拆分（最终的特点是隔离不同服务间的职责）、分层架构拆分（每层隔离关注点）以及内核架构拆分（内核稳定、插件扩展），服务化架构是根据业务的功能抽象业务职责，把这些职责分配到不同的服务中去，某一个功能或者职责修改的时候就只需要修改某一个服务就可以了，通过职责的划分将修改范围限定在比较小的范围内。分层架构是在架构拆分后，在一个子服务中进行的逻辑划分，分层的好处是上次的修改不需要触及下层。内核架构主要的应用场景是通用功能的插件化，比如说用户登陆，虽然有短信登陆、微信登录、密码登陆等，但核心流程的token处理、验票等是不变的，核心流程基本是不变的，而最常变化的是具体的业务登陆流程，这些流程的改变不会影响其他流程和内核。

5.1.1、服务化拆分

服务化架构拆分从时间顺序上看有两种方式，第一种就是SOA，它拆分的粒度比较大，比如交易系统、财务系统等等，它们通过ESB总线进行通信，需要深入了解数据内容。后来提出了微服务的概念，它拆分的粒度比较小，系统间的通信就靠统一的协议即可，但微服务也存在着一些陷阱，如：单个服务不够轻量化，服务化拆分的依据在于业务建模和业务的划分，还需要考虑服务的技术特性，比如可靠性、性能以及易变性和扩展性等进行划分，总体来说就是根据业务特性拆分后还需要根据技术特性再进一步的拆分是比较合适的；服务拆分过于小，就会加重服务间交互复杂度的提升，导致整个服务的扩展性不足，还会记一步影响研发效率，比如原来一个需求需要改两个工程，现在可能需要改六个；另外一个就是微服务本身需要强大的基础设置，比如排查问题的trace、日志中心以及服务监控、注册、发现和路由的机制等。

5.1.2、分成拆分

分层架构的基本思想是每层隔离关注点，在逻辑分层的时候要保证每层之间的差异足够明显，在信息传递过程中需要穿透分层各层的时候，虽然增加了一定的工作量，但让无序的穿透变成了有序的两两关联，也是增加了系统可扩展的能力；每层的关注点是相似的，这样就可以通过一些层内的范式来降低实现的复杂度。

5.1.3、内核拆分

内核架构主要是功能相近但解决不同场景适配的问题，内核架构的关键是对多类插件的管理，在内核中维护一套插件的注册表，在注册表中有插件的必要信息以及如何加载需要的参数等等，其次还需要考虑一些插件与插件间的通信过程等。此外需要明确的是内核架构的核心思想是需要一个稳定的业务模型，插件化是一种常见的实现方式，具体的技术有SPI、TMF以及SWAK等。

5.1.4、其他

此外还有一些其他的架构来提醒系统的扩展能力，如事件驱动架构、反应式架构等，其本质是异步化；另外还有一些配置化的方式来提高系统的可扩展能力，如规则配置化以及流程配置化，其本质是系统能力的抽象。

5.2、面向容量的拆分

应有容量的拆分，要看应用的状态，如果是无状态的，那进行水平扩展即可，如果有有状态的，那需要提取出状态数据，将数据维护在三方（数据库，缓存等）中，将应用变成无状态的，然后进行水平状态，其本质是应用一定是无状态的。在数据容量层面，关系型数据库在扩展方面具备的一些方法：提升存储能力：垂直分库、水平分库；提升写能力：垂直分库、水平分库、水平分表；提升读能力：垂直分库、水平分库、水平分表、一主多从；DDL：水平分库、水平分表，但这些分库分表的方式存在缺点也比较明显，比如事务一致性问题、分页排序以及主键分配等，在采取对应策略时需要重点衡量。另外在分布式存储方面，单机的性能和成本等无法满足数据容量的扩展，就需要考虑分布式存储所需要的关注的重点，如关注一致性，那么中心化的方式是比较合理的，如关注可用性，那么去中心化的方式是可以考虑的，比如redis的集群模式。

六、预测变化

虽然预测变化比较困难，但也不是完全无迹可寻，还有一些痕迹，可以从四个方面考虑，考虑客户：分析客户的终极目标；考虑对手：学习对手，取其精华；考虑整体：站的更高、上级、上下游等；考虑自身：了解细节、指标、数据和ROI等。

参考

https://blog.51cto.com/u_13643065/6139366
https://blog.51cto.com/u_13979417/2920213
https://bbs.huaweicloud.com/blogs/358120
https://www.cnblogs.com/lovesqcc/p/17325515.html
https://cloud.tencent.com/developer/article/1791286
https://cloud.tencent.com/developer/article/2016483
https://discretetom.github.io/posts/scalability/