不知不觉，扛过了2019、2020两届北京智源大会的举办，团队能提供的线上服务能力也从几千人规模到毫无压力支持大几十万人。
两届会议表面上都是风平浪静，实际背后让人心惊肉跳，2019年智源大会，上线前一天，合作的视频提供商说播放器兼容性有问题，告知我们换版本；2020年智源大会，科技部部长/北京市市长连线前一刻，重新上线播放器，第一天稳到不行的网络，前一天从下午开始就拉着好几名网络工程师搞到凌晨四点…
先聊聊2020 北京智源大会吧。
写在前面
因为今年疫情的缘故，项目时间点无法尽早明确，实际项目执行周期非常短，项目关联干系人又多的情况下，为了确保每个模块不出问题，事必躬亲成为了常态，从项目立项沟通、外包模块设计、内外部 Code Review、上线性能优化、压力测试、HotPatch、线上运维、会场网络…
加上多个项目并行，过程中冷暖自知。期间种种，不一而足，工作上的时间多了，项目的结果安全了，和家人的沟通自然就更少了，媳妇的抱怨和生气次数也越来越多，媳妇对不起鸭，我会改变哒。
过程中也非常感谢团队小伙伴，和同事们、合作伙伴的给力支持和理解。
相比较去年，今年的系统基本都是“Powered By BAAI Tech Team” or “Powered By soulteary”，所以“压力”比去年自然是更大一些，而且战线和范围也更大了，除了看的见的东西外，还有通知系统、监控系统等一系列“幕后英雄”。
2020 北京智源大会
闭上眼睛，回看智源大会，脑袋里会涌现出几个词：
- 全链路双备份、国内外同时直播
- 性能有基础要求、满足瞬间高并发
- 内容安全、降级下线
- 缺人、Delay、干不完
那么就跟随这些关键词展开吧。
全链路双备份
今年的智源大会的主战场搬到了网上，嘉宾规模和会议规格比去年扩大的不少，与之而来的还有海量的关注和潜在的直播观众，如何保障直播从软件到硬件都没有问题，成为了一个亟需解决的问题。
线路保障
这是一个看起来不是那么困难的事情，但是实际执行过程中，却充满了艰辛。原计划在酒店进行的会议，在沟通讨论后改到了在新的办公场所：智源清华中心。
园区拉线和酒店稍有区别，没有那么简单，在费尽沟通之后，我们拉到了两条独立运营商的宽带，但是这两条宽带，在大会开幕前一天到当天凌晨还在不停断线，直至大会当天凌晨4点还在拉着会场网络工程师和园区网络工程师在调试，最后在同事的帮助协调下，我们将线路切换为园区专线，有惊无险。
如果当天网络依旧故障，我们的后招还有4G网络聚合设备、5G路由器，做临时热替换，在损失流畅的情况下，可以保障直播继续。
此外大会期间我随身带3台手机，4张手机卡，覆盖三个服务商，随时准备冲到主会场进行网络替换。
硬件保障
想要在会议期间提供稳定的网络，不光是买宽带就完事了，还需要配合合适的网络设备，就像是你想在家稳定上网，除了给移动/联通/电信交钱外，还需要准备一台性能强劲的路由器一样。
为了大会的稳定运行，我们准备了两套“防火墙、交换机、行为管理、无线控制器、AP、NAC…”，毕竟之前量子芯座办公区在更换网络设备过程中，网络设备掉链子折腾了一天还历历在目。
如果设备故障，大会期间快速拔线插线，可以让网络迅速切换。同时，会场也布置了双份的无线 AP，如果有一台下线，另外一台在控制端切换服务状态，即可快速恢复服务，当然，也准备了超六类有线网线，提供更稳定的网络。
除此之外，还做了网络策略，对导播台、会议秘书的电脑都做了流量保障和优先策略，避免万一有人不小心抢占带宽，影响了网络。
直播保障
这里是一个天坑，在大会开始前，我们曾和两家视频供应商沟通，对方都信誓旦旦的表示，我们可以帮你们做定制，然而到了开会前一两周，纷纷表示，自己的开发说做不了，无法定制。
此时，在决定视频对所有人公开可见之前，大会报名人数已超两万，而且报名者包含国内、海外，自建视频直播服务风险比较高，播放器的开发定制也存在比较高的项目风险。
庆幸的是，去年年末我和小伙伴已经使用阿里云直点播整过了八场线下会议、线上直播，在重新调试之后，看到播放器兼容性和网络流畅度满足需求，所以这里选择使用阿里云作为方案之一。
在导师&老板刘老师的帮助下，我们幸运的和哔哩哔哩、爱奇艺的技术团队取得了联系，将哔哩哔哩直播选为我们另外一个方案。而哔哩哔哩的工程师也在大会开始前将播放器如期上线，满足了我们直播双方案保障的诉求。
瞬间高并发
之前在“大厂里”享受着基础技术设施的红利不觉得高并发有什么，做toB项目则更加偏重功能而非某时刻性能，自己出来拉团队搞发现小细节还是有不少的。尤其是团队有效开发人员不足，需要优化改进外包团队项目时，性能问题成为了一个逃不掉的问题。
从宏观到微观，先简单聊聊。
水平扩展
早在去年组建团队的时候，就多次提到和要求我们做的项目尽可能应用层无状态，利于扩展，所以大会开始前，我们只需要将个别需要持久化的数据从应用层剥离掉，做好解耦，就能够做到大规模扩容，套用流行的话来说，我们的架构天生 Cloud Native。
平时几台4c8g 的服务器中使用容器运行着的应用，在大会期间，根据需求扩容到所需要的核心数的机器和实例数即可。
扩容分为几个层面：
- 最外层网络带宽
- 连接带宽到服务器的负载均衡
- 应用服务器的数量
- 服务器上跑的应用的实例数
- 应用使用的缓存服务、数据库服务
- 监控从点变面，运维摘除从单机到小组
这里每一块都能展开不少，有机会单独写写吧。
语言和框架选择、数据处理
考虑开发效率，我们选择了最好的语言 PHP 作为会议系统后端 API，考虑到语言下限和生态繁荣，我们选择了 Node 作为 前端展示层。
在拆分日志、合理调整 FPM 配置、合理使用应用内存、本地远程缓存、Node 实例数量之后，大会期间最后一次压测，PHP / Node 服务分别跑过了 5万 和 10万并发连接， TPS 都在 1万以上（带宽会限制性能结果，测试过程尽量调整带宽到合理水位）。
至于框架，PHP 选择了国内万年常青的 ThinkPHP，而 Node 选择不乱跟风，使用目前全球生态和应用数量依旧是第一的 Express 。
之前提到了我们将日志拆分，做了不落盘的操作，静态资源90%以上都扔到了CDN，页面/接口数据还设计了 LRU ，所以磁盘不存在被打死的问题，在应用设计上，在尽可能避免缓存击穿，避免出现慢查询、调整好链接池，基本就及格了。
细节优化
Code Review 和外包项目重写（全部/部分）是一件窒息的事情，这里真的不想展开了，尤其是在和多家外包公司合作之后。庆幸的是，有的公司在多次合作后，是能够交付我们及格的产品的，还算是比较省心，但是项目时间风险管理这块，真的得看天，除非你根本不要求项目质量，应付了事就够了。
有类似状况的团队，作为过来人的建议，如果有选择，还是招募自己人，或者建立稳定合作关系吧，沟通起来更高效，项目风险会低非常多。
内容安全、服务降级
相比较花里胡哨的功能，作为北京向世界展示AI的窗口之一，我们需要保证内容也是安全的，但是安全从来不是一个点，而是一个面，我们自低向上来聊聊。
代码安全
前文提到，我们有使用外包团队，外包团队的代码和我们生产是分开仓库的。所有的项目完毕之后，人肉 review 并合并到生产仓库进行进一步验收测试。
这样保障了不会提交一些乱七八糟的东西，和问题到线上。
对于管理后台类的项目，上线时，会将地址改变，整个项目添加 Basic Auth 、SSO 等防止越权访问。
访问安全
管理端的项目，还需要搭配 SLB、应用访问策略来保障指定 IP 可以访问的 IP 白名单。
类似方案还有只有跳板机可以访问生产，并且仅限部分IP或者指定加密方案登陆，这样可以进一步减少来自外部的风险。
以及，流量进入仅允许走负载均衡，流量出口则使用做了安全策略组的 EIP 或者 SNAT。
数据安全
数据库是安全的底限，线上数据库需要根据实际情况分配不同的账号以及访问IP白名单，避免未授权的机器连上去胡搞乱搞。以及存在数据库内的数据根据实际场景进行加密处理。
这里额外提一下用户数据安全，在早期建设的过程中，我们设计了无密码的模式，即不存储任何用户密码，统一使用 SSO / 手机验证码进行登陆，退一万步来说，假如有一天发生极其恶劣的事件，除了报警追凶外，我们的用户在网络上的关联账号不会受到一丝风险。
服务安全
这里提一个观点，如果一件事做不到及格线，那就不做，如果一个服务达不到其他服务的平均值，那就下线。
完全硬着头皮上，没有Plan B的东西，大概率是要出问题的。
在大会初期，我们计划使用 Rocket.Chat 作为视频直播过程中的聊天工具，但是在人力紧张的状况下，我们难以保障性能稳定和服务可靠，于是就果断拿掉了这个服务。
内容安全
在大会开始前两天，在播放页面/服务端写了一百来行代码，搞了一个小功能，每几秒获取服务端配置，进行快速的页面调整：切换播放线路、切换播放器模式、动态下发消息配置…
前文提到的阿里云直播中还带有基础的内容视频安全过滤，我们没有大张旗鼓对外的社区也接入了腾讯的内容安全审查。
毕竟天知道国外的专家们会说出什么大家神经敏感的话来，尤其是疫情期间。
干不完的活
这里暴露了人力上、组织上、技术基础、项目规划上多种问题，而人力不足又是一切的死锁。短时间内，可以靠降低服务要求，拉长准备时间，人员加班来解决问题，但是这不是常态手段。
经常有朋友线上线下问我：“新项目启动，有没有资源干个活”、“忙死在业务里，没成长”、“项目出现瓶颈，攻关不掉，进行不下去了”…
所以说，该招聘还是得招聘，该培养还是得培养。“养兵千日，用兵一时” 大家都听过，但是它的出处和原话其实是：《南史·陈暄传》:“兵可千日而不用，不可一日而不备。”，不要做单单短期重视技术价值（高估），而长期低估技术价值的事情。
额外说一些，从资本角度来看，技术部门是成本部门，工程师、设计师干不满工作时间就是“不划算”的，但是从发展角度来看，不同的工种在协作过程中是有“时间差”（依赖次序）的，适当给他们空间和资源去成长，对于项目和团队整体的收益和价值比“用满”他们的时间，更划算：我们要的是高质量漂亮的结果，而非闲鱼式的按部就班打满几个小时卡，应付了事的给出项目结果。
2019 北京智源大会
2019 北京智源大会是八个月前的事情了，当时主要战场是线下：国家会议中心。
回想起2019的大会，也是问题不断。
相比较今年的线上会议，只要不开播，技术都还有开发的时间不同，线上会议开始前，预热的时候，系统就必须是基础完备的。
在收到明确大会的开始时间点后，我们实际只有不到一个月时间来准备票务活动系统、支付系统、用户系统，以备线下活动使用。配合之前采购的服务，用网络上的话来说，应该是“稳了”，谁知道…
在聊我们自建的服务前，先说说外部采购的程序吧。
两套外部采购的程序
我们都知道淘宝的出现和一套三方商城代码的改造脱不开关系。
我们当时类似，不同的是，我们当时有对外采购两套系统，一套是“活动票务系统”、一套是“社区系统”。
前者交付给我们的时候，基本是重写了一套，原来的代码有 1个G，非常难以维护，交付过程中对方的技术负责人离职回老家了，所有事情交托给了新入职的一名工程师，这位小伙伴十分靠谱，在大会结束后，也加入了我们的团队。
庆幸的是，在一起封闭开发的过程中，我们搞定了整套票务系统，并扩展了它的能力，满足了基础的活动需求，对接了支付宝和微信、用户系统。
后者则没有这么幸运，简直是社区的血泪史的开端。
多次和社区创始人、相关社区运营的同学沟通，感觉人都比较靠谱和上心，让我们觉得项目不需要花太多精力，看着甘特图推进，定期检查项目状态就够了。
但是随着项目推进，出现/暴露了以下几个问题：
- 技术团队因拖欠工资问题面临解散，实际进度堪忧
- 产品即将被头条收购，技术团队基本是去非留，后续维护问题堪忧
- 技术团队想要在交付过程中试验将产品从单体应用升级为容器服务，过程中卡在了攻关上，浪费了一周恢复了单体架构才解决问题
- 项目部署开发、产品均无详细的部署文档和维护文档，多次催要不得，后续无法维护
- 招标过程中出现了其他的问题，乙方主动退出招标过程
问题纠缠在一起之后，产生了化学反应，最终项目流产。这是因为这里，我们觉得或许应该组建技术团队，而非全部都假手于外包。然而，当时因为各种人事原因，还未能组建团队，一切都基于“志愿者”和“朋友帮忙”。
于是我不得已上线了Flarum 作为临时替换方案，当时还总结了一篇文章： 使用 Docker 和 Traefik 搭建 Flarum 轻论坛应用 ，之后便是不断的试错，切换主流的论坛开源项目，以及当前小心翼翼的上线基于 lobsters 的新社区。
时至今日，智源社区 Beta 已经上线，新版本也即将全量上线，被大厂收购的社区也恢复了正常的运营，仿佛一切都是两条毫无关联的平行线，什么都没有发生过。
自建的服务
这里主要聊聊用户系统和SSO系统，因为最初是多套系统上线，所以不得不将用户系统直接抽象出来，并支持 SSO 应用授权，考虑到国内用户的习惯，需要支持微信扫码登录等需求。
在基础选型的时候，由于有维护之前 WP4SAE 巅峰时期十数万用户的使用经验，很自然的使用了这套全球第一 CMS ，简单几十行完成软件 WAF，基于开源社区的插件，很快的就搞定了 OAuth Server等需求，而性能问题参考15年的文章《天下武功，唯快不破》照顾下方方面面和之前的 WP4SAE 插件做做细节优化，公开使用不成问题，这块近期也会优化后上线，或许我们会推出一套开源的系统，可以满足中小团队快速完成 IDaaS 的诉求。
而SSO这块其实是做了一套 SSO PROXY 的功能，Node 几百行代码，轻松完成高性能的鉴权转发。
其他
回忆智源大会也是一件费体力的事情，原谅我不继续回忆了。
最后
随着2020 北京智源大会的结束，也意味着我没有了必须加班的理由，需要好好的规划个人、团队、家庭、项目几个方面的事情。
坦白说，从去年年底到目前，在智源加的班远超之前在阿里云、碾压美团、更别提时薪巅峰新浪之流了。遇到不顺心的时候，真的是在扪心自问，为什么要扔掉股票、放弃年终，来这里加班呢？
而这一切在看到 Zoom 聊天室、微博等社交媒体上用户对于大会的肯定的时候，都变的“值得”了。
–EOF