在今年的全球架构师大会上，来自DAZN的方案架构师Ivan Rigoni给我们分享了DAZN是如何做到每十分钟处理百万请求的，本文尝试从笔者自己理解的角度来和大家分享一下DAZN的实现。也许你还没有听说过DAZN这个公司，它是一个体育流媒体，主要提供体育赛事直播和视频点播服务。

问题的概述

这次演讲本身是一个系统设计的面试题，当然也是基于DAZN真实的架构演变进行抽象的。我们知道DAZN作为一个体育赛事的直播平台，每天都有很多新用户慕名而来，尤其是一些大型赛事正在进行的时候。当一个新用户来到DAZN，他需要进行注册付费才能够观看相关的赛事。而这个付费注册的过程需要调用第三方API来实现，是一个同步的call（transactional），需要一定的时间才能完成。而DAZN作为一个同时服务超过200个国家的体育直播平台，通常来说每秒需要新注册的用户超过1600个，当有大型赛事举办的时候，峰值可能会超过3000/s。我们的目标就是如何让新用户在这个量级的QPS下能够快速完成注册，并及时开始观看直播。

我们可以假设最初架构是如下所示的，有一个单体架构的前后端，它需要调用external的同步call来进行payment和subscribe，它的QPS是1600 tps （峰值可能达到3000），目标是能够让用户不被这个流程所block，及时观看直播。

初始架构

我们先来从最直观的初始架构聊起，简单的示意图如下所示：

从流程的角度来看，前端直接调用后端进行注册，这个时候需要首先调用一个外部的付费平台来进行支付，这是一个同步的调用，直到它返回成功，我们就可以把相关的信息保存到注册平台，等注册平台把所有的信息都创建完毕并返回之后，就可以给用户返回一个token，用户就可以播放直播了，流程图如下所示：

这种架构的优点一目了然，大概有下面这几个：

1. 如果需要扩展，就直接增加单体架构的instance就可以了，比较方便。
2. 整个系统的交互很简单，所有的都是sequential和transactional，没有什么race condition。

当然缺点也很明显：

1. 假如你需要扩展，可能需要整体扩展，而不是只扩展瓶颈的部分，这必然会导致资源的浪费。
2. 从安全性的角度来说，你的代码是一个整体，你可以通过RPC访问所有的信息，比如数据库，storage，外部的调用等等，很难从security角度进行一些分离。
3. 整个代码的release周期比较长，因为大家都在上面修改，任何有问题的修改都可能导致所有的修改roll back。
4. 同样的代码库也意味着所有的team都使用同样的语言，很难让不同team使用它们熟悉的语言来进行编程。
5. 因为整个都是单体架构，所以一个endpoint的性能很容易会成为性能的瓶颈。

优化架构

从上面的架构的缺点来看，我们其实可以从以下几个方面的思路来着手：

1. 把到外面的external call改成一个async的call，再加入queue来进行处理。这样的优化需要保证最终一致性。
2. 把单体架构改成单个component，比如微服务。
3. 注意failure的处理，也就是尽量做到无状态。

基于这个思想，我们来对上面的架构图进行一些修改：

这里我们引入了一个Payment Façade，这个façade的引入就把对external的call和我们之前的单体架构的后端进行了隔离。同时把之前的payment分成了两个部分一个是preauth，一个是真正的payment call，你可以理解preauth就是去验证一下用户输入的信用卡信息是否有效，这个过程相对来说速度要比做一个payment快很多，如下面的流程图所示：当我们知道用户的信用卡信息是有效的，我们会把这个相关的信息加入到subs queue，并同时向用户返回一个可用的token，这个时候用户的最终付费操作并没有完成，但是他就可以进行直播的播放了。

那付费操作如何进行呢，我们从subs queue中取出数据，然后进行真正的扣费的操作，并在扣费成功后加入到subscription相关的平台。这里因为我们信用卡信息是有效的，所以扣费操作百分之八九十的情况下都是会成功的，所以当一切都成功的情况下并不需要让用户感知。而对于那百分之十左右的扣费失败的情况，我们则需要把刚刚给用户的token revoke了，让他不能继续观看直播，并显式的告知用户你的付费信息有问题，可能需要改正，并进而引导用户修改相关的支付信息。

这样修改之后有下面这些好处：

1. 单体架构和外面的调用进行了隔离，不会受他们的性能影响。
2. 用户能够更快地开始观看直播，而不需要等待支付信息的完成。
3. 有了façade之后，我们假如需要改变第三方的payment平台之类的就会非常方便，而且我们可以单独针对façade这一层做一些监控之类的，可以有针对性地进行优化。
4. 从安全性的角度来说，现在只有façade这个component可以访问第三方，这样一来安全性的控制就会得到提升。

进一步分解单体架构

显然微服务是一个很好的优化，因此从单体架构可以转变成如下所示的微服务架构，一个很重要的点就是一般来说这种转变也伴随着组织架构的转变，当然这个可能超出了技术层面的考虑：

我们可以把前端改成各种小的服务，比如Auth，播放等等；同样后端也可以分成Auth，Checkout等等各种各样的微服务。这样做的好处如下：

1. 从可靠性的角度来讲，单个服务出问题可能不会导致整个网站的瘫痪。
2. 从扩展的角度来说，我们只要针对服务层面的traffic进行扩展就好了，比如说修改密码的服务和播放直播的traffic显然不在一个量级，我们可以有针对性的进行扩展。
3. 当然我们可以针对单个服务进行deploy，这样整个deploy的周期就大大缩短了。
4. 各个team也可以自由决定他们使用的语言了。
5. 安全性的角度来看，针对各个服务的security控制会相对更加容易一点。

当然这种架构的改变时间很长，也很复杂。从大的角度来说，这种改变有两种大的方法，一种就是全部重写一个V2，然后在某个时间点进行切换。另外一种则是让两者共存一起开发，经过一段时间的共存之后再最终切换，如下所示：

DAZN使用的是后面这种方法，大概的做法如下：

首先在原有的Legacy的code之上加一层proxy，随着新的架构不断开发，可以通过proxy层来不断切换，从而最终达到只使用新的架构的结果：

一些趟过的坑

最后Ivan分享了DAZN在整个架构演变过程中的一些经验和教训，个人觉得很有启发意义：

1. 单体架构和微服务。DAZN在早期作为一个startup的时候，面临了一些抉择，他们认为快速推出服务，及时得到用户的反馈更重要，所以他们当时选择了买一个基本的单体架构系统，当有了足够用户之后再进行refactor并不迟。
2. 架构不是创建的而是应运而生的。说白了我们的系统设计是要符合当下需求的，并不是说开始“完美”的架构就是好的，不同用户量下的架构是不同的，所以一步一步来进行优化架构才是正确的做法。
3. 在deliver产品到用户之前，做好各种假设的测试。
4. 花费足够的时间来了解requirement的各个细节，而不是被动的接受就好了。
5. 在你做任何架构演变的过程中，用文档的方式记录下来你为什么要做这些架构的演变。

总结

本文基于Ivan的演讲总结了DAZN的架构演变，希望你能从中学习到一个startup的技术架构成长过程。