背景
哲言任何事情都在变化，唯一不变的就是变化。
这个时代在变化，业务系统的访问请求压力也在无时无刻不变化着，更有一些人为的促销活动、节日、事件会带来业务访问高峰期。现有资源扛不住就需要调取更多资源一起来抗，也就是通过扩展系统资源、让系统程序和数据运行能够稳定运行，让整个业务架构更具有弹性。
作为业务架构，要能够应对需求的变化。
解决问题
各种原因带来的流量高峰、低估，云平台上的各层资源均需要动态扩展进行支撑。
解决方案
系统扩展的方式包括横向扩展、纵向扩展，也有人提到按照Z轴来扩展，不同的资源可以有针对性的选择扩展方式。系统扩展重点在云主机、数据库的扩展，网络、存储本身提供有自动扩展能力所以会相对更容易。
纵向扩展计算资源
纵向扩展是指为云主机等资源升级配置，初始创建资源时选择的1核1G的低配置云主机，在需要扩展时可以选择升级为2核4G或者8核16G的云主机。
需要注意的是云主机升级配置往往需要进行重启，这对于一些不方便重启云主机的场景下不方便。UCloud通过修改操作系统内核，支持部分地区的云主机热升级特性，即在无需重启的情况下完成配置升级。在云平台上云主机向上升级配置比较容易，向下降低配置就比较麻烦了，一般都没有支持。
特殊场景下不能重启云主机，才会选择纵向扩展云主机配置，除此之外不建议通过纵向扩展来提升整个架构应对业务压力的方式，而是建议通过下面介绍的横向扩展方式。
横向扩展计算资源
系统压力增大需要更多资源，可以通过横向扩展的方式，比如原来有10台云主机支撑1000人进行访问，简单来算2000人需要20台云主机，则再创建10台云主机即可。
还有一个场景，最初创建的10台云主机配置是1核1G，经过1年的发展这些云主机配置太低了，想把这10台云主机升级到4核8G，这时该怎么选择？选择纵向扩展还是横向扩展？最佳实践是横向扩展，一方面为了支撑业务横向扩展优先级要高于纵向扩展，通过更多数量的云主机来支撑业务压力，同时还能避免云主机级别的故障提升业务高可用；另一方面通过把这10台1核1G的云主机挂在到负载均衡后端节点上，另外再创建10台4核8G的云主机并部署相同的业务，这个阶段就是由20台云主机共同提供服务，然后从负载均衡后端节点中逐步移除1核1G的云主机并释放实例，最终完成1核1G云主机“升级”到4核8G云主机。通过平滑替换的方式，而不是中断业务或纵向升级配置。
负载均衡
通过负载均衡通过VServer监听前端请求，并根据均衡算法转发到后端服务节点（云主机或物理云主机，目前还不支持负载均衡的嵌套）。需要重点关注的是云主机的状态数据怎么存储，状态的幂等性设计。
- 健康检查
负载均衡后端服务节点支持健康检查，包括两种方式：端口检查和Head检查，通过心跳包来判断后端服务节点是否“正常运行”，通过端口检查只能监测出服务器是否运行不能保证Apache等服务器是否启动、应用能否正确访问；Head检查也只能监测出指定的接口是否运行正常，应用级更详细的是否运行正常还需要更多监控工具实现。
- 状态数据存储
状态数据不能写在云主机本地，通过在Redis中读取实现共享状态数据。
自动伸缩
通过负载均衡能够进行横向扩展云主机、物理云主机等资源，不过还是手动的方式，如前面设计原则，尽量避免手动操作而要实现自动化的响应处理机制。通过自动伸缩可以根据监控指标进行自动伸缩。
自动伸缩时需注意以下问题：
- 镜像
镜像为应用和数据的集合，可以从计算单元生成，便于横向扩展时直接使用镜像启动计算单元，避免了每次启动计算单元都需要重新部署一套应用。但是镜像中的业务需要将会话保存在各个计算单元均可以访问的存储单元中，例如Redis、Memcached、消息队列等。
- 时延
进行扩展时首先需要下发指令执行扩展动作，随后引用服务镜像的计算单元启动，启动完成后加入均衡后可以提供服务。计算单元启动需要一定时间，一般在几分钟左右，一次扩展多个计算单元时并行启动，在未能提供服务之前，原有计算单元压力会继续增大，必须在系统满负荷之前完成扩展的计算单元启动。在进行扩展时需要考虑这个时间延迟，可以提前启动扩展操作。
- 防止抖动
例如在CPU达到60%时增加一个计算单元，在低于30%时减少一个计算单元，有可能在达到60%时增加了一个计算单元，随后CPU降低为30%，此时又会减少一个计算单元，CPU又会达到60%，一直重复执行增加计算单元、减少计算单元。此时需要增加一个冷却时间，即执行增加或减少动作后冷却时间内不会再执行增加或减少操作以避免重复执行增加、减少计算单元的操作。
- 自动化进行实现弹性伸缩
进行横向扩展，常见的有以下几种方式，包括手动新建计算单元并加入到均衡器中、自动策略伸缩、定时任务自动伸缩。其中自动策略伸缩是横向扩展和自动化进行结合的效果。运行机制如下：
- 控制器监测原有资源单元平均CPU；
- CPU达到60%时，激活扩展程序；
- 扩展程序根据配置好的启动模板，使用模板中指定的镜像启动计算单元；
- 计算单元启动完成后加入到均衡单元中，返回第1步继续监测；
- 如果CPU低于30%时，激活缩减程序；
- 缩减程序根据策略选择计算单元进行停止服务并释放计算单元，返回第1步继续监测。
- 和可用区/地域均衡模式进行配合使用
对于电商系统在每天24小时的请求量分布不均匀，晚上17:00-23:00是访问高峰期，每周中周五至周日也是访问高峰期。电商应用还经常举办抢购、促销活动，都会造成访问高峰。在进行系统架构时需要考虑的就是可伸缩性，云计算提供便捷的伸缩机制，我们需要用到横向扩展模式。手动创建云主机，然后在每台云主机上手动部署应用是不可取的，我们还需要一种快捷的横向扩展方式，使用自动伸缩可以及时的扩展云主机以应对用户访问。在用户访问量较少时及时的释放云主机，以便节省费用。释放云主机时更加智能的做法是检测云主机的创建时间，云主机一般按照小时收费，因此等待云主机距离下一小时收费还有几分钟时释放更为划算。
可设置以下UAS规则，在每天访问高峰期前后多创建10台云主机，不能在19:00执行任务，因为创建云主机并启动需要几分钟时间，最佳实践是提前一段时间执行伸缩任务。自动伸缩UAS还支持根据CPU等因素执行伸缩任务。在下面的规则中，可以看到云主机云主机平均CPU高于60%时自动创建2台云主机，云主机云主机平均CPU低于30%时自动移除2台云主机，从而保证云主机云主机 CPU负载保持在合理范围内。
纵向扩展计算资源
主从实例
云平台支持对云数据库UDB-MySQL实例的主库（Master）创建从库（Slave），支持跨可用区创建从库，即主库实例与从库部署在不同可用区。例如数据库主库在北京二可用区B创建，则从库可以在北京二可用区C创建，实现可用区级别的数据库容灾能力。另外可以在每个可用区创建只读从库，用于分担数据库读请求压力。
读写分离
关系型数据库在OLTP业务下96.87%都在等待读I/O，而处理器计算仅仅占了5.3%，要提高数据库的QPS性能，关键的一点是提高系统的IO能力。另外大多数业务对数据库的访问，是读大于写，典型的如电商、O2O、互联网金融等业务，读写比例可以达到 5:1 甚至 10:1 。部署一主多从的主从复制集群， 进而将读请求分发给多个数据库节点并行处理。考虑到大部分业务对数据库的访问以读居多， 读写分离能够给数据库性能带来明显的增益。
分布式数据库
业务存储的数据量增多和访问量增大，都构成对单机数据库的挑战；在海量数据时代，传统的单机数据库在容量和性能上，都存在瓶颈，明显不能满足业务发展的要求；数据量达到一定量级后，单机数据库的数据库备份、还原等运维操作需要长时间才能完成，失败概率增加，给日常运维工作带来风险。
支持自动化水平拆分（只需要在建表语句中指定拆分键和分片数量），屏蔽了系统扩缩容的细节，让复杂的节点增删、数据迁移等操作对用户透明。同时提供丰富的监控和告警， 以及自动和手动备份功能，做到系统运行状态尽在掌握，具备数据库全生命周期运维管控能力。
网络与存储
网络与存储相对比较容易扩展，一般都是云平台提供自适应，无需介入。这里不再展开，大家思考下。
- EIP按流量计费，带宽包；
- ULB、VPC等无需扩展，云平台自行调度资源来保证高可用；
- 云硬盘，只是偶尔扩展，挂载数量有限制，大量的数据不建议保存到云硬盘；
- 对象存储，平台根据存储的文件量进行自适应扩展。
Burst In / Out
非常多的应用部署在云计算平台，但部分用户还拥有一些物理资源，将所有应用迁移上云后这些物理资源将会被闲置。部分应用基于数据安全考虑等需要将应用部署在客户本地或将数据存储在本地。一方面客户本地资源有限，另一方面这些资源不容易扩展，因此可以使用云计算和本地部署结合的混合架构来解决，将一些计算任务放在云计算进行，在应用遇到突发访问请求时将更多请求分发到云计算平台进行处理。如何实现计算任务和应用服务在客户本地和云计算平台之间进行弹出/缩入，如何实现这种动态转移还需要一套完整的机制来保证。
在伸缩机制在混合云架构中客户本地与云计算平台之间进行弹出/缩入操作。在本地资源不能满足需求时在云端使用镜像新建计算单元，计算单元上的服务准备完成后，将用户的请求一部分分发到云端新建的计算单元上。云端的计算单元还可以在云端进行横向扩展，使云端计算单元的数量增加或减少。当访问量很少时逐步释放云端的计算单元，直至云端计算单元全部释放完成，所有服务架构缩入客户本地内部，用户的请求将只会分发到客户本地，不会分发到云端。
系统弹性伸缩，你遇到了哪些问题，有什么办法和最佳实践？期待你的故事。
UCloud启云学院《进阶云架构师》培训近期采取线上直播形式+微信群运营模式，除了讲师解答这些问题，还有配套动手实验让你学以致用。
