第三届智源大会背后的那些事

差不多一年前，我曾写过一篇文章介绍了前两届大会背后的事情：《两届北京智源大会的背后的那些事》。遵循惯例，记录下本届智源大会的一些事情。

今年我和我的团队伙伴们依旧作为“大后方”的一员，负责各种系统相关的建设，以及社区产品的完善。工作内容看似乏善可陈，实际克服了重重困难，如同大会系统表面上依旧风平浪静，实际背后依旧存在让人心惊肉跳的“各种调整”。如果少一份坚持，或许今年会议形式就只能使用纯线下模式了。

如果说去年最刺激的是“科技部部长/北京市市长连线前一刻，重新上线播放器”，今年则进步了一些，在前一天凌晨，我们完成了系统交付以及各种压力测试。感谢一起“肝”项目许久，大会期间一同值守，一起“逆转结果”的各位团队小伙伴。

先来聊聊上面提到的“各种调整”和为什么会“心惊肉跳”吧。

关于“各种调整”

说到调整，会发现今年应对大会这场战斗，团队存在太多不同方向的调整和挑战：产品功能、技术架构、人事调整、以及我个人和团队心态上的调整。

产品上，从 2019 年至今，我们经历了“寄托希望于外采现成系统”、“寄托希望于知名开源产品配合简单的本地化调整”、“认真梳理需求并只实现核心需求”三个阶段。某个角度来看，踩过了许多组织在成长过程中踩过的坑：“战术准备充分，战略准备不足”。前期轻敌导致后续付出了个人认为的许多不必要的成本、以及损失了非常多的时间窗口和机会。产品需求清晰逐步明确的过程中，因为各种原因和压力，产品方向转变、摇摆，对于团队成员来说缺乏明确的挑战，这对于所有人来说都是一种伤害。虽然付出了代价，但好在我们度过了这一阶段，或许很快可以调整进入下一阶段。

去年年末，因为工作重心的变化，有几位一起战斗了一年的团队成员离开了团队，部分产品团队专业岗位缺失，导致团队作战能力在短期内受到了明显的影响，我们不得不思考更适合当前团队协作的方式，以及坚持更核心的产品功能开发和调整，避免做任何短期功能浪费精力。于此同时，因为种种原因，我们错误的引入了一位看似资历比较老的成员，作为产品方向上的把关者。这个错误的决定，险些导致本届大会线上系统的全面流产。庆幸的是，经过这件事，团队变的更加团结和自驱：用更少的资源打更大规模的战斗，团队每个成员在专业能力上都有了非常明显的进步，和更深的默契。过程中我个人对于“坚持正确而不是容易的事情”的理解和体味也更深刻了。与此同时，运营兄弟团队的一些方向和人员的变化，导致运营和产品也存在脱节问题，这意味着依赖“强运营引导的社区产品”离地运行了，对于社区类型的产品来说是一个非常危险的信号。

架构上，初期产品经验和开发资源不足，各系统、模块上亟待解决解决的问题累计下来越来越多，有关乎性能的问题，有关乎安全的问题，甚至也有关乎基础功能交互的问题，越是复杂的系统，针对其进行调整和解决的时间成本也就越高，然而大会留给我们的时间真的不多，治标又治本的方式，显然在此刻走不通，需要妥协。以及因为在关键时期错误的用人决策，导致大量有效的可进行产品验证的时间被浪费，所有的产品功能、技术决策不得不更慎重，杜绝出现返工、同时避免上线后无法运营管理。

在这样的状况下，团队度过了年后的第一个季度。直至距离会议召开前的两个月，我个人陷入了迷茫和挣扎状态：这样下去我们真的能够做到我们想要的产品吗？这个过程和结果真的是我想要追求的吗？

作为“产品和技术负责人”，我的状态也难免影响到团队。看到陷入迷茫、焦虑，但是依旧在坚持推进的小伙伴，我个人的心态和情感是非常复杂的。自我拷问的过程中，感激各位朋友们的倾听和开解、感激媳妇的妥协和理解，理智最终还是战胜了感性，责任心战胜了趋利避害。 迅速送走影响产品推进的成员，和伙伴们思考如何简化产品，满足最基础的功能，如何在几乎无运营介入的情况下，让一个运营性质的产品流程转起来，有了明确的方向，剩下的就是投入时间和耐心、以及汗水，大会临召开的一个月里，团队小伙伴开启了超负荷模式，白天正常上班，晚上持续和外包一起联合调试、以及进行大量方案尝试和功能修正，我个人则更多把精力集中在梳理瓶颈，解决架构问题上。

接着，聊聊我们是如何“逆转”原本大概率失败的结果的。

“逆转”结果

五月初，项目重新开始的时候，我个人听到大家提到最多的词是“好慌好没底”，对于未知和不确定的事情，有风险的事情，本能上有恐慌和焦虑是正常的 。 当时总是安慰大家说“没问题，能解决的，没问题，有我呢”。到时间过半，看到大家更加聚焦具体功能开发和优化、以及联调的具体事务时，或许此刻大家已经有了一些“对于未来不确定结果的希望”，总是打趣的说“诶呀，完了要崩了”。在最后一周的时候，各系统开始集成、各服务开始进行扩容和压测演练，此刻我听到最多的是“够了、扛得住、没问题”。“善变”的人们比机器还是可爱的多 。

今年仅阿里云直播调用的统计出的峰值PV就在大几百万，更不论各系统间的调用，以及几秒调用一次的几个配置接口服务，最前端的应用高峰时期持续接近10万连接，对于一个很窄的垂直领域来说，数据其实很不错了，去年使用 GoAccess 就能完成数据分析，而今年则不得不使用 Clickhouse 来辅助计算各种结果。相比较去年缺少个别省市（我记得是少边远地区）的访客，今年覆盖了全国各个省份（包含港澳台地区），以及有更多的头部海外国家地区在关注我们，明年如果有机会，我会试着对播放过程中的质量做一些监控和提升。

记得5月31日 “预讲会演练” 的前一天晚上，在场地遇到两位院长，皆被询问“会崩吗”，当时回复 “不会、如果出问题，我们会切换至兜底方案，全力保障播放正常”。对于架构方案，以及实测结果，我非常有信心。并且过程中还有兄弟团队帮忙联系云服务商做一些基础监控保障，同样感激在心。

那么，就和 2020 的总结一样，展开来聊聊，我们做了哪些事情，来逆转原本可能会很糟糕结果。

首先聊聊常规意义上的资源保障。

线路和硬件保障

硬件资源可以简单分为线上、线下两部分。

线下相对简单，但是同样重要，本次会议，我们在“中关村国家自主创新示范区会议中心”，该区域网络可操作性不比去年在园区，可以拉两个不同运营商的网络作为互备，再备份两种不同的无线聚合网络作为备份，这次只能使用一家服务商，无线网络也只能用单个CPE作为备份。并且因为本次是线下线上同步召开，线下参会人数众多，很难保障无线质量。

因为“手牌极其有限”，所以，只好专注于保障核心网络设备稳定性，以及资源利用率。最简单也最重要的莫过于给所有的网络设备加一套“UPS”，避免出现断电长时间影响直播，以及准备两套不同供电模式的直播设备（感谢我们的合作伙伴，在苛刻的时间里，完成了这些事情）。关于网络稳定性保障，除了增加备份之外，还有两个点是大家经常忽略的：验证备份切换机制是否稳定生效、资源能否仅对核心工作设备提供。

最恶劣的环境，莫过于室外潜在的人群聚集处，比如报名处，因为无法拉有线宽带，一般会采用无线设备为签到设备（笔记本、签到码机）提供网络。然而如果可能因为无线设备多（签到者和手机数量多）出现“集体信号不好的现象”，遇到这个场景，签到设备签到效率会大幅降低，导致人员堆积。

最简单具备可操作性的方案便是添加设备，参与资源竞争，采取增设CPE设备扩大带宽的方式、甚至是多家运营商线路来提升网络可靠性。当然，更加粗暴的兜底方案是切换签到方案，选择对网络依赖更低的策略。

线上服务器资源保障

考虑到成本消耗，我们分别在会议开始前一周、会议开始前三天、会议开始前一天进行了云服务资源扩容，将日常使用核心数量扩充了数倍，让程序在有资源冗余的情况下迎接挑战。并进行了充分的压力测试：直接上大流量进行验证，不断打挂系统、直到系统打不死、或者能够快速恢复为止。

这里扩容的思路无非两种，横向扩充机器数量，线性提升吞吐能力，纵向扩充机器核心数量，暴力提升程序响应时间和吞吐能力。我们根据各个服务的场景和特性，以及部署组网模式，混合采用了这两种方案。所有能够无状态运行的服务，一律使用低配置多节点模式提供服务，反之，提升数量的过程中，也需要提升规格，提升容错。

直播线路备份保障

去年大会之后，我们便开始尝试使用自己的云服务线路进行直播，放弃使用外部服务商，一来资源限制更少，二来沟通交互成本更少。在经过一年非常多场会议的验证后，慢慢习惯了以阿里云资源为主，哔哩哔哩线路为辅的模式开展直播服务，还是同样的双方案保障，但是优先级有了变更，并且今年除了开幕式和闭幕式之外，只在我们自己的系统平台上进行直播，整体可控性高了非常多。

这里十分感谢哔哩哔哩的团队，在去年就为我们提供了直播保障方案。

去年关于应用保障，我使用的标题关键词是“瞬间高并发”，今年我觉得使用“持续抗压”更为贴切，其中 Nginx 的广泛使用（NJS 服务聚合、高性能缓存模块、动静分离、数据打点等），为我们减少了不少压力。

关于解决瞬间高并发的话题，去年已经聊过了，解决问题的手段真挺多的，在不限流的情况下，围绕主流打法不外乎：让程序尽可能更快的执行，并尽可能更快的将计算结果送达请求侧，腾出资源进行其他请求的计算。

展开聊聊今年的一些执行细节吧。

今年除了和去年一样根据不同业务属性、场景划分网关流量外，额外做了一些调整：增加了不止一个VPC内网网关，进一步提升了服务间调用的性能，缩短了最终服务用户接口的响应时间。启用了多个并行网关，搭配传统的 DNS 负载均衡来横向提升连接数和减少建立连接时的等待时间。

运行时选择

针对潜在瞬间压力特别大的聊天和审核服务，使用 Node 和 Go 提供服务，作为 Serverless / CloudNative 一等公民，两者的抗压和扩展能力都非常好，前者对于“热更新”更有一套，结合使用可以偷不少懒。另外，尽可能使用拥有更高性能的高版本语言/程序 Runtime ，如相对最新的 PHP 8、Node 16、Go 1.16、Nginx 1.20 （之于 NJS）等。

可以使用 Nginx / Node / NginxJS 作为各种服务的外挂，在尽可能不改动原有服务代码逻辑的情况下，通过路由劫持，添加一层弱缓存，减少“慢的”程序执行次数，以及“更慢”的内部网络请求。

在极端场景下，使用缓存优先于数据库落地的方式提供服务，分布式多副本缓存的可靠性还是比较靠谱的，唯一需要的注意的是云服务商可能会存在不告知的情况下，进行网络切换，产生应用到缓存服务网络不可达的状况。这时做好容错，甚至多区域多节点就显得十分有必要。如果应用不需要强一致，连接本地启动的缓存服务，则可以提升更高的吞吐，至于一致性，后台开进程同步、按照请求定期刷新、甚至放任不管都可以。

这里有不少小技巧，包括使用 Nginx 配合容器健康检查、使用 Nginx 各种高性能模块完成内容强一致的内存缓存、以及使用 Nginx NJS 做一些接口数据聚合和缓存。

关于静态资源类的高并发，最简单的方式是扔到 CDN 上，但是你一定有非常多的场景是不能完全使用 CDN 解决的，比如你想要极低的响应时间、以及更确定的可访问性和一致性。那么这个时候，如果对应用作“动静分离”，则可以简单快速的让应用性能提升至少2个数量级，甚至更多，而动态内容，也并非不可以使用 Nginx 之类的高性能服务器作一些“缓存”、以及数据预热。

这里有一类资源比较特殊，属于动态查询后计算生成，但是可以接受一定时间范围内的缓存，以往通常做法是使用开发语言针对计算结果进行直接返回，涉及到分布式多机多节点的场景下，这个计算结果需要存储远端存储空间，做不少“简单却麻烦”的活。其实这个场景也可以使用 Nginx 进行本机缓存，满足当前节点上各实例计算结果可缓存可共享即可，十几行配置下来，虽然做不到将不必要计划简化到“1”，但是计算压力可以骤减到“节点个数”，从计算机角度来看，也差不多了。

2020年的时候，为曾经写过一套简单的脚本，搭配服务端下发命令，可以做到快速的修改页面内容，控制页面呈现内容，以及交互行为，但是这还远远不够，在今年大会，我们新增去年想做却没有做的，学术活动直播过程中的聊天功能，并选择性的在会议中开放这项功能，前文提到我们运营资源不足，所以这里的运营审核，势必是由我们团队来进行兜底的。为了降低审核成本，我们对接了两家云服务商的内容审核接口，对所有评论进行无差别的审核，这样首先可以降低至少80%的工作量，搭配“禁言”、“撤回”功能，可以保障内容在会议过程是相对安全的。

我们按照系统场景进行了监控面板的划分，比如常规的“报名场景”、“官网场景”、“直播场景”、“聊天评论”。在每一个面板中，可以快速的看到我们关注的各种指标：CPU、内存、负载、连接数、丢包率、常规错误响应个数。

之所以没有使用短信报警的方案，是因为在6年前，我还在美团做统计业务的时候，曾经为一些业务加上了短信和IM报警功能，一旦业务前端出现问题，便会将错误相关信息发送给负责人。虽然服务设计了重复错误不发送的功能，但是在大量用户一瞬间涌入的场景下，你会发现“防火墙”设计总会出现这样、那样的漏判，导致一瞬间出现海量的短信，造成“事实误报”，形成打扰，可能是小问题，但是在大量报警出现的状况下，很容易问题上升，与解决问题无益。

还有一些内容，和去年差不多，这里就不过多赘述了。

关于我个人的变化

坦白说，我个人感觉今年上半年是我来智源之后收获最大的半年，包括并不仅限前文提到的，生活上、工作上都出现了未有的挑战。以往我会要求自己心态尽量平和，甚至会试着压抑自己的冲动，把自己扔到技术世界里“泡一会”、或者到游戏世界里“畅玩一番”，来平静自己或者转移注意力，这是一种实实在在的逃避，也是一种对于时间的低效使用。

这段时间里，我彻底想通了一件事，如果目标足够清晰，心态不可能不平和，去追寻足够清晰的，满足组织需求、满足个人诉求的目标才是真正每个人该做的事情。以及意识到没有必要避讳“one man army”的问题，当然尽可能还是要发挥团队协同，将战斗力翻倍。

这就不得不提到上半年里和不少朋友、师长聊天，有的是我作为过来人开导朋友，更多的是，朋友听我倾诉，帮助我调整心态，以及为我提供一些额外的挑战和机会。这里不能一一致谢，但是我相信你们应该知道我说的就是你呀，: )

总的来看，在第一个季度个人规划提到的一些东西，基本都有稳定进行和落地。在《2021 年第一个双月总结》中，我提到了“技术和分享”、“团队建设”、“生活相关”的三个方面的事情：

• 其中技术分享中的 “Nginx 和 NJS”，我和我的团队已经在实际业务中投入生产，并验证了它的靠谱程度；而可以用于我们接下来多个外包团队合作方的通用标准开发环境，也已经完成的差不多了，只待文档化后投入实际生产；
• 团队建设部分，我认为我们在经历挑战后，很好的将团队基础效率有效的提升了上来；
• 生活部分提到的搬家，也已经完成，虽然是被动搬家，但是好在新的屋子的整体条件远远好于之前。

在“2020 岁末总结”中的文末，提到过一句我觉得比较有意思的话“许多后悔，都是基于不敢”，今年许多事情上，我觉得相比较以往，我确实更加勇敢、果断了一些。

随着 2021 北京智源大会的结束，完成了对师长们的承诺，是时候做一些更有价值和挑战的事情啦。

“花开堪折直须折，莫待无花空折枝。”