CrowdCast.io的技术博客地址: https://crowdcast.io/blog/topic/code
整体印象
比起Zoom和Google Meet，CrowdCast更像是一个Panel Hosting，主要是少量的几个人在视频，然后把视频发送给成千上万的观众来看。比如演唱会，脱口秀等现场直播节目。同时Crowdcast又提供观众互动环节。他们的技术博客主要写的是如何更好地提供视频服务，以及在提供视频服务期间所遇到的技术问题。
阅读进度
最后一篇读的是2020/08/06的Scaling Crowdcast
博客摘要
系统设计 | Source
Scaling Crowdcast
COVID-19期间，Crowdcast与其他网络视频业务一样发展十分迅速。比如我所知道的，认知科学和认知神经科学好几个大的会议都是在这个平台上，经常一次就是一两千人同时在线。而且Crowdcast确实有很多功能让这几个大会的组织者和参与者很喜欢。但是快速增长也就意味着整个产品需要迅速扩大规模，于是就有了这篇文章。
用户开度增长对产品的基础设施造成了冲击
从美国开始封城，Crowdcast服务使用数目每两周增加了50%，在线用户和直播数量从3月1日到4月1日涨了10倍，而且还在涨。这个增幅还是挺可观的（原文有图）。
Crowdcast的应用逻辑是搭在Firebase上的，结果Firebase本身并不是很容易扩展。看起来他们或者用了Firebase的实时数据库，或者是Firestore来作为他们的后端数据库。但是同时连接数泰达的时候，Firebase的连接就会超时，用户就加载不出来。结果同时在线36,000人的Hay Festival就出现了问题，需要Festival组织者来协调参会人员，减少对Crowdcast的连接。这个对于用户来说就是非常不好的体验。
应对措施
首先是理解问题出在哪里：理解各种流量，并且分辨出什么流量产生问题。这就需要流量跟踪，需要有监视系统来区分各种流量来源，用处之类的。
然后就是建立缓存。找到了系统最热的部分之后，可以对常见的数据设置缓存，从而使得类似的查询直接从缓存里面读结果，而不增加数据库的负担。这样似乎确实有好处。但是缓存的问题时修改的信息不会及时更新，所以需要有更新缓存的机制。不过文章里面没有仔细说民整个缓存的读写和更新机制。
另外就是把聊天功能从原始数据库剥离出去，做成一个新的微服务。文章没有说把这的新的微服务是怎么实现的，所以具体内容不得而知。不过结果是进一步降低了数据库的负担。
读后感
分离微服务，缓存，流量分析，Firebase痛点
这篇文章说Firebase的痛点的时候让我想起之前在HackerNew的一个讨论。这个讨论提到Firebase是一个很不错的服务提供商，新创公司可以利用它来快速迭代和扩展自己的服务或者产品。但是Firebase的一个缺点就是不容易扩展。新创公司一旦选择了Firebase，容易被整个环境“固着”，等到需要扩展的时候，需要花大力气来迁移到别的服务（比如K8S？）。我现在也用了Firebase的Serverless的服务，感觉扩展性问题会是所有Serverless服务的一个痛点。
在他们讨论聊天功能的时候，我猜想他们是把整个产品所有的服务基本上都放到同一个数据库上面了？之前的文章似乎说了他们用了其他的Docker环境才对。所以不知道怎么回事。Firebase只提供了一个实时数据库接口，似乎没有多个不同的实例，这样的设计似乎也不奇怪。但是我还是挺惊讶的，多个产品公用同一个数据库的话，一挂就全挂啊。
最后，流量分析和缓存这个部分确实挺重要的。很多时候需要造新的工具来分析流量。缓存设计上的各种平衡也是个技术活，但是可惜这里没有深入地说。
系统设计 | Source
Broadcasting WebRTC Over Low Latency Dash
这里的大概意思是设计了一个中间层，一边用编码发布端的视频（使用Headless Chrome），一边向订阅端发送视频。重要的是订阅端的网络请求可能比发布端提供内容的时间更早，但是通过HTTP组块仍然能够让订阅端及时获得发布端的信息。
文章说这个比直接用WebRTC连接发布端和订阅端的延迟要更低，从15秒降到了3秒。
读后感
我没有很理解这个技术为什么可以让网络延迟更低。 文中提到的MPEG-DASH似乎是一个编码标准。
系统设计 | Source
How WebRTC Scales
之前，WebRTC设计的时候是peer-to-peer连接的，也就是所有的订阅者就直接连接到发布者的浏览器端。这个时候，在发布视频的时候（比如开会或者演讲），发布段会根据所有的订阅者的带宽来发送的视频质量（通过设定比特率）。于是，带宽最差的订阅者就可以以一己之力拉低整个所有人观看的视频质量（发布者会以最低比特率向所有人发布视频）。
但是用WebRTC来做广播服务的时候，并不需要所有的Peer之间都互相连接，于是Selective Forwarding Unit (SFU) 的引入了一个服务器连接所有浏览器，然后把发布端（Publisher）的数据包发送到每一个订阅端（Subscriber）的浏览器。这样就把接入发布端的所有连接放到了SFU后面，发布端就只有一个连接了。这样就可以扩展订阅端的量。但是这个时候，还是没有解决比特率的问题，因为订阅者会告诉SFU需要的比特率，然后SFU会选最小的反馈给发布端。
使用Simulcast，让发布端向SFU发送多种比特率编码的视频
浏览器编码器最近提供了一个新的发布端功能，叫做Simulcast。这个功能使得发布端可以同时向SFU发送多个不同比特率编码的视频流，这样SFU可以根据订阅端的带宽来分发不同质量的视频。当然，这样的结果就是发布端的CPU等计算资源需求更大。
但是SImulcast有个问题，就是2018年的时候，不是所有浏览器的所有视频编码系统都可以使用这个功能。当时主要的编码系统是VP8和H264，结果Chrome和Firefox的VP8视频可以实现Simulcast功能，但是H264编码视频不可以；而Safari当时只支持H264，所以导致Crowdcast需要推荐用户使用Chrome/Firefox，然后需要给Safari来写个程序来转码。
图片来自Crowdcast
可扩展的视频编码 Scalable Video Coding (SVC)
一个新的想法是在编码器层面解决多比特率的问题：让编码器允许发布端讲不同比特率的视频编码成不同的层（Layer），然后高清层在低清层的基础上直接加入信息，这样一层一层叠加。当SFU向订阅端发送的时候，可以根据订阅端的带宽，选择不同层次的清晰程度（比特率）来发送视频。
图片来自Crowdcast
读后感
用中间层解耦合，不同层增量信息（比特率），视频编码
感觉SVC这个想法蛮合理的，不知道为什么现在才实现。可能是视频编码本身的问题就很复杂吧。这个想法有点像高斯金字塔（Gaussian Pyramid）来平衡不同的空间分辨率和信息量。
SFU那个P2P的连接解耦的想法挺有意思的。计算机里面真的是，有什么问题，加一个中间层来解决。
视频编码以及浏览器层面的视频处理这方面的问题我是完全不懂，VP8，VP9，H264，H265这几个编码方式有时间可以了解一下。
公司文化 | Source
Engineers: Ship code on Day 1
这篇文章说Crowdcast希望达到一个目标：所有新的员工第一天就能直接提交上线产品的代码（Ship Production Code）。这个做法还是蛮激进的，因为很多刚入职的员工可能连整个开发环境都没有搞清楚。但是仔细看了一下发现，这里所谓的“第一天提交的”上线产品代码，很有可能是一行小改动，比如CSS错位啊之类的。
这个文章有一个特点，就是这个目标是对整个公司和员工共同的要求。如果这个目标失败了，错的并不一定是新员工，而可能是经理、管理者和公司。如果管理者能够承担足够的责任，并且帮助员工达到这个目标，我觉得还是可以考虑的。
目标的设定原因和新人的常见问题
这个目标之所以设定，有时候新员工可能遇到几个常见的问题。
- 花费太长时间设置工作环境和熟悉工作环境。这种时候往往员工需要的是及时的帮助，而不是盲目地自己找解决方法。这个时候应该通过整个企业的文化让新员工愿意问问题，寻求帮助，从而节省整个团队在不必要的方面浪费的时间。
- 盲目地阅读代码和文档是没有用的。学习往往在项目进行中进行，脱离项目直接读文档或者代码，往往并不能提高效率。虽然扩展阅读确实能够增加广度，但是不应该用这种理由来阻碍项目的开展。
设定这个目标的好处
- 减少了员工在上述问题上浪费时间。
- 明确了整个团队的重心是注重结果，而不仅仅是过程。
- 减少了工作流程上的问题。因为整个团队都在为了这个目标而努力，所以整个工作流程都被修整得流水线化，每一个步骤都清晰明了。
- 要求了领导层要靠得住。整个管理层都需要达到这个要求做出努力，并且能够可靠地为新员工提供帮助。
读后感
如果这个要求是对公司管理层和新员工共同的要求，而且管理层能够做出足够的努力来搭建一套简单易懂的工作流程，帮助新员工提高效率，我觉得是可取的。文章里提到的新员工常见的问题确实是切中要点的。在这种情况下，环境中的脚手架（Scaffolding）确实能够帮助新人的成长和适应。