科技战“疫”，Rainbond助力咸阳市疫情管控应用快速交付，支撑大用户并发

2020年的春节与往年不同，突如其来的新型冠状病毒肺炎自华中始，并向全国各地蔓延，冲淡了原有年味儿的喜庆热闹。从23号武汉封城，到多地纷纷效仿，最后到一级响应预警，全国各地都是严阵以待。面对严峻疫情防控形势，社会各界齐心协力抗击疫情，好雨科技也积极投入到抗击疫情的实际行动中。

咸阳市大数据管理局是咸阳市政府下属机构，负责咸阳全市信息化建设、大数据管理和信息网络运行维护等工作。2019年，咸阳大数据管理局以Rainbond为基座，建设咸阳市的智慧社会操作系统，智慧社会操作系统的主要任务是连接资源、连接应用、连接数据、连接用户，2019年底已经完成智慧社会操作系统的主体建设工作。

挑战

2月4日，由于复工返岗高峰的到来，大规模的人口流动重新启动，为遏制疫情蔓延扩散，做好外来返工人员的防控和服务工作，咸阳市大数据需要用最短的时候完成咸阳市疫情登记应用和相关管控应用的开发和上线，并在3天内完成整个咸阳市130万人信息上报和管控服务。

在这过程中面对两大个挑战：

1. 咸阳大数据管理局的工作人员也在家办公，疫情防控应用必须在短时间开发完成，需要高效的远程协作，并支撑应用快速迭代上线和业务不间断升级。

2. 应用要支撑130万人短时间访问要求，在某些时间点会有大量并发，需要快速完成性能优化，支撑大并发。

通过Rainbond实现远程协作、快速迭代开发和持续交付

疫情来的非常突然，导致整个业务的开发上线时间非常短暂。在几天内完成开发，上线，并且立刻接受大压力的考验，君知其难也。不得不承认，业务上线前的压力测试结果并不尽人意。但是任务就在那里，必须被完成。负责智慧社会操作系统的所有工程师都拿出了自己的看家本领，力保线上业务正常运行。

“咸阳市外来人口登记业务”是一个前后端分离的业务系统。主要包含了前端页面、后台服务、缓存、数据库、短信业务5个服务组件。

1，通过Rainbond实现远程协作

疫情的到来，迫使很多企业的员工必须在家远程办公，如何远程协作才能在如此短暂的时间内完成业务的开发并上线，对于工程师们是一项艰巨的挑战。

通过将开发——测试——上线全流程所需的资源全部部署于Rainbond，这样，通过Rainbond提供的应用控制台，即可完成全流程远程协作。这一切只需要工程师们可以在家里通过VPN访问到Rainbond应用控制台即可。

整个流程的简要描述：

• 开发测试人员均可以通过vpn访问到Rainbond控制台。

• 开发人员向部署在Rainbond内部的Gitlab管理需求并远程提交代码。

• 通过代码部署业务应用并上线。

• 测试人员通过部署在Rainbond内部的自动化测试工具对业务应用进行测试。

• 测试人员提交issue到Gitlab来反馈BUG。

• 开发人员获取反馈，更新迭代代码。

• 通过提交信息中包含的关键字，触发应用自动构建，自动将更新上线。

• 上线后如发现新的问题隐患，通过Rainbnond版本管理功能一键回滚到上个稳定版本。

2，快速上线与回滚

业务的开发没办法一蹴而就，任何一个业务都需要代码的迭代更新，统计业务的开发人员通过基于Webhook实现的自动构建功能，将代码快速部署到线上。

开发人员在提交代码时，将指定的触发关键字加入commit信息，即可触发Rainbond自动构建该服务组件。Rainbond将自动完成代码拉取、构建、滚动更新上线的全流程。整个过程更加智能、更加自动化。

然而并非所有的代码更新都是正向的，一旦发现代码更新后线上业务出现了问题，那么如何快速回滚到上一个稳定版本，就变成了一个问题。在这次实战中，统计业务的开发人员利用了Rainbond自带的版本管理功能实现一键快速回滚。

3，服务组件图形化编排

当开发人员部署好所有的服务组件之后，如何让它们彼此之间能够通过依赖关系正常通信，互相调用呢？实战中非常好的一个实践是借助于Rainbond平台基于拓扑图实现的图形化服务组件编排。

抛弃以往复杂的配置方式，在web界面上简单的拖拉拽即可实现服务组件的编排。对于开发人员而言，这样的方式既感性又方便。

• 切换到应用拓扑图界面。

• 点击“切换到编辑模式”。

• 从下游服务组件的六角形拖拽一条线到上游服务组件即可。

通过多次的拼装，在简单的服务组件之间就会形成复杂的拓扑，组件间彼此就可以相互调用，正常运作了。

应用实时性能监控和优化，支持5000+并发

想要在3天内完成整个咸阳市130万人信息上报和管控服务，可以预见到这将会是一个高并发场景。这个场景，将对平台网关的抗并发能力、容器平台的承载能力、统计业务的处理能力、数据库性能四个方面提出较高水平的需求。如何探测整条链路的瓶颈，并加以处理以提高综合吞吐能力，就成了打赢这次“实战”的关键点。

• 负载均衡降低网关压力

• 支持业务实例自动故障迁移。

• 实例数量自动伸缩。

• 业务升级滚动更新不间断。

• 服务组件间通信通过插件治理。

• 性能分析插件迅速发现业务瓶颈。

1，网关节点和计算节点伸缩

网关节点集群的流量被全局负载均衡器所负载，这是业内处理并发最常用的手段之一。根据Nginx的轮询算法，将流量均匀分配到所有网关节点，大大降低了单一网关节点的压力。使其处理更高层的 Http 协议更加从容不迫。

Rainbond容器云平台的计算节点，支持分布式部署。这样的部署方式对于抗并发最大的意义在于：一旦某台计算节点由于压力过大而崩溃，Rainbond健康检测机制会在短时间内将故障节点上运行的业务容器实例进行自动迁移，始终保持业务正常运行。

2，通过应用市场快速复制应用，用户分流

项目负责人早在业务上线前，就已经预料到大并发场景。所以在规划开始阶段，就将咸阳市所有区县进行分组，最终决定部署4套相同的业务来为不同的分组提供服务，这样可以在业务处理能力这个层面进行人为的分流。大幅度降低单个统计业务系统的压力。

在这里，Rainbond内部市场功能发挥了作用，开发人员只需要手动构建部署第一套业务系统，然后发布到内部应用市场，即可快速复制出另外3个业务系统。而且一旦业务需要升级，只需要将源业务系统升级后再次发布，Rainbond内部市场提供的版本管理功能会自动识别升级，其它复制业务系统可以基于提示一键升级。

整个过程和以往人力部署的情况相比，人员的投入、操作的复杂程度、操作耗时都成倍的下降了。

3，应用根据用户量弹性伸缩

Rainbond提供服务组件的伸缩功能，只需要一键，就可以为当前服务组件快速伸缩出多个实例，并且自动提供负载均衡。这将大幅度降低单个实例处理业务的压力。

在“咸阳市外来人口登记业务”的所有组件中，我们为前端页面、后台服务这两个服务组件都伸缩了最多5个实例，这两个服务组件也是经常进行实时更新的组件，基于多个实例，Rainbond提供滚动更新的功能，使业务的升级不会影响到线上的业务运行。

上图中，显示的就是一次构建完成后的滚动更新过程。

为了能够让业务流量过大时，可以自动扩展实例数量，我们还设置了基于内存使用率来触发的自动伸缩功能。在运维层面更加自动化。

4，专门针对数据库进行优化

在如同“咸阳市外来人口登记业务”这样一个业务系统中，数据库的吞吐能力直接影响整个业务系统的综合吞吐能力。在这个层面，我们做了这样几件事情来提高数据库性能：

• Mysql本身的性能优化：添加 max_connections 参数，提供Mysql所能提供的最大连接数。

• 为后台服务安装出口网络治理插件，设置TCP最大连接数，从ServiceMesh微服务治理的层面，提高了后台服务到Mysql数据库之间依赖关系的通信能力。需要注意的一点，是该插件默认内存设置太小，我们需要点击更新内存来提高设置。

• 提高Mysql读写磁盘的能力：Rainbond应用市场默认提供的Mysql应用，均使用了共享存储类型的持久化存储来挂载Mysql数据目录。在这里，我们将其更改为本地存储类型。这样做的目的在于使用宿主机节点的本地磁盘代替Rainbond系统使用的共享存储，牺牲Mysql故障迁移的能力来换取性能的大幅度提升。这样的交易是否合理，取决于我们的数据库是否已经由于磁盘IO性能而达到了瓶颈。

5，通过实时性能分析插件，监控和优化应用

为了更好的监控“咸阳市外来人口登记业务”各个服务组件的压力情况，我们为前端页面、后台服务、数据库分别安装了Rainbond自带的服务实时性能分析插件。业务运行期间，这个插件为我们带来很多的有用信息，多次帮助开发人员发现业务系统的不足之处，使开发人员可以在业务雪崩宕机之前修正代码并上线。

对于前端页面、后台服务这样的基于Http协议提供服务的组件，插件将提供平均响应时间、吞吐率、在线人数三项实时数据，以及最近5分钟耗时URL排行、历史数据等持续性数据。

• 通过分析排行中请求所有资源或接口的平均时间， 可以很方便的分析出当前业务系统的瓶颈在哪里，并据此调优代码。

• 根据历史数据，我们发现当前组件在24小时内响应时间一直正常，在线人数峰值1600人同时在线，吞吐率根据人类作息时间正常起伏波动。

而对于Mysql数据库而言，服务实时性能分析插件提供的信息最大不同，在于最近5分钟排行将替代为Mysql数据查询、更新等操作的排行。

• 一次真实的经历是，一段时间内Mysql的平均响应时间不断在上升，后台服务处理能力随之急剧下降。危机边缘，开发人员立刻分析5分钟耗时排行，发现耗时排在第一位的查询语句引用了临时表，是一个慢查询语句，并且已经在Mysql内产生了堆积阻塞查询的现象。发现这个现象后立刻采取行动建立了索引，Mysql的响应时间缓慢的情况随之缓解。

6， 其它优化

除了上述这些优化， 我们还做了其它许多事情来提高系统的抗并发能力。

• 优化代码参数，很多开发框架天生带有最大连接数管理机制，例如对于Spring Boot项目而言，就需要调节server.tomcat.max-connections server.tomcat.max-threads

• 优化短信验证业务流程，在大并发情况下，业务系统请求外部资源（例如短信业务）时，也需要考量该外部业务本身的并发限制。尽量以异步任务的方式处理，不要陷入外部资源一旦请求超限，不再响应导致了自身业务流程受阻，最后阻塞了业务的运行。

• 关注出口网络治理插件与服务实时性能分析插件的内存设置，避免内存过小导致插件OOM，并随之影响业务服务组件的运行。

• 关注业务服务组件实例内存占用，避免内存分配过小导致的OOM。

总结

现在 咸阳市疫情填报应用 已经度过了流量高峰期。整个填报期间，4套业务系统平均在线人数保持在4000人以上，峰值达到5000+。智慧社会操作系统没有出现一次宕机情况，始终稳定承载填报应用正常运行。后续，智慧社会操作系统将继续承载“重点人员监控系统”、“疫情可视化”等其他疫情管控系统，持续为咸阳市抗击“新冠”疫情作出自己的贡献。