背??景当监控平台发现流量突然增加，业务系统应用或链接监控出现一定范围的告警，此时我们排查问题的方向是：APP或网站是否被访问过遭受DDOS、CC、暴力破解等攻击；合作推广带来的业务流量增加，应用系统压力过大；是否因为连接数爆满，事务死锁，导致数据库压力过大；以上几种情况在处理生产故障的过程中都是比较常见的。这一次，我们将在应用系统压力过大的场景下解释横向扩展的方向。需求当应用系统压力过大时，除了临时调整线程数或直接水平扩展来解决问题外，更深入的代码优化和调用环节上的耗时接口都会滞后。因此，我们决定采用横向扩展的方式来应对过大的系统压力。这个时候，如何实现快速扩张就成了我们关注的焦点。在传统架构下，应用横向扩展我们需要做的关键步骤如下：闲置服务器资源；系统标准化部署步骤（应用发布、标准目录、配置发布、应用启动）；应用程序启动自动健康检查；应用启动后自动连接到负载均衡或注册中心；应用横向扩展后同步到系统监控平台；CMDB资产同步添加到对应的业务组；应用服务器同步到堡垒机；在主环节，除了提前准备好闲置的服务器资源，节省不必要的时间，其他的都需要根据我们系统架构和运维平台的实际情况进行适配。我这里只是提供一个思路。假设一个比较主流的架构是：CMDB，基础设施统一管理Zabbix监控，统一健康检查JumpServer堡垒机，服务器统一登录管理SpringCloud框架Eureka注册中心Apollo配置中心解决方案这里通过管道支持运维自动化，实现应用的水平扩展，将不同层次的原子模块以流水线的形式排列，满足不同运维场景的功能需求。根据系统架构，应用水平扩展流水线实现所涉及的功能模块已在上图中标出，其中：CMDB+事件推送网关，可通过CMDB触发Zabbix监控堡垒中资产的自动同步空闲服务器资源分配；基础组件安装，实现Java环境的自动配置，包括标准部署目录、JDK环境、管理脚本等；当然我们默认的idleserver已经根据操作系统的初始化（配置初始化、标准用户、其他安全基线）下发了，所以我们在这边就不多做介绍了。Apollo配置中央级原子模块，实现应用的配置和发布；系统监控级原子模块，应用扩容后的健康检查同步加入监控平台；具体实现1.构建我们只需要输入应用名称，新应用IP，版本号，就可以实现应用的水平扩展，但是目前只支持一个一个的扩展，不支持批量水平扩展。2.建设成果通过流水线各阶段的时间统计，应用扩容成本主要是版本发布过程中的启动时间。3.Pipeline@Library('shared-library')_pipeline{agentanyoptions{timestamps()}stages{stage('Basiccomponentinitialization'){steps{script{buildjob:'init_system',parameters:[text(名称：'HOST_IP'，值：“${HOST}”），字符串（名称：'PLAYBOOK'，值：'software_install.yml'），字符串（名称：'TAG'，值：'java，filebeat'）]}}}stage('应用初始化'){steps{script{java_deploy.InitApp("${APP_NAME}")}}}stage('拉取Yunweiconfig配置'){steps{script{java_deploy.PullFromYunweiconfig("${APP_NAME}")}}}stage('从Artifactory中拉取包文件'){steps{script{java_deploy.PullFromArtifactory("${APP_NAME}","${VERSION}")}}}stage('apolloupdate'){steps{script{apollo.ApolloDeploy("${APP_NAME}")}}}stage('版本发布'){steps{script{app_port=apollo.ApolloGetPort("${APP_NAME}")java_deploy.DeployApp("${APP_NAME}","${VERSION}","${HOST}")ip_port="${HOST}"+':'+"${app_port}"//健康检查java_deploy.HealthCheck("${ip_port}")}}}stage('添加zabbix健康检查'){steps{script{app_prot=apollo.ApolloGetPort("${APP_NAME}")//println("testpass")println("${app_prot},${HOST}")ip_port="${HOST}"+':'+"${app_prot}"buildjob:'zabbix_newalert',parameters:[string(name:'APP_NAME',value:"${APP_NAME}"),string(名称:'IP_PORT',value:""),string(name:'HTTP_URL',value:"${ip_port}")]}}}}}PK容器相对于传统架构，操作系统CPU和内存资源阈值粒度太粗，无法及时准确扩容；另外，对于批量扩容，需要提前准备好资源，相对于容器方案方面来说不够灵活，需要提前优化。传统的IP地址分配架构无法自动分配IP地址。生产环境使用DHCP，不仅会造成keepalived切换脑裂，还会因为lease问题导致其他问题。但是云原生架构可以自定义IP池，所以后续的扩展会使用IP池中的地址。以上几点是基于本次应用的自动横向扩展。对比容器使用中的要点，印象还是比较深刻的。总结一下这场PK，虽然传统阵型输了，但也不是彻底的败北。至少我发现只要细心，坚持标准化、原子化、场景化的原则，我们还是有很大的提升空间的。容器给了我们目标和方向，剩下的就交给我们了
