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

写在前面

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

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

值班室 - 阳山厅(给大家打个码)

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

关于“各种调整”

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

产品上,从 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 北京智源大会的结束,完成了对师长们的承诺,是时候做一些更有价值和挑战的事情啦。

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

–EOF