1、前言

本人小菜在支付宝数据平台实习半年，主要业务均是离线场景，原以为今年是刷不上双11了，但幸运的是，运营支撑部门准备开发一套线上场景的应用，需要用到数据平台这边的系统，更幸运的是，我负责了部分数据平台这边的部分数据出口系统。该套应用双11当天也需要使用，所以呢，我也算是凑了凑双11开发的热闹。

在这过程虽然对于双11相关的开发事宜了解不是很多，但是或多或少有所耳闻，在这里将我的一些心得体会记录下来。

2、内部机制

我面向的这个应用的开发流程和普通的应用开发流程基本一致，提前2-3个月开发完毕，开发周期约1个半月。

开发需要做的第一件事：需要与各个关联应用的owner沟通协商，沟通内容大概就是需求是否能够满足；平均TPS/峰值TPS大约多少；如果需要开发周期多长，我负责的主要数据相关的接口，结果是需求暂时无法满足，得重新开发新接口；TPS似乎有点高，得压测后评估新的服务器容量；半个人月开发一周测试。这个结果也还算okay，基本就是时间的问题，与他们协商好新接口以及联调的时间即可自行开发了。

开发需要做的第二件事：具体开发过程大同小异了，开发完毕后需要进行联调以及测试，同时要对新的接口进行压测，压测完毕后才是重点——服务器容量水位评估，用以评估在当前的水平下，需要多少台机器才能够撑得住预估TPS。具体的评估方法在这里就不细说了，阿里技术嘉年华中有篇PPT，就讲了容量水位的评估，《如何利用应用自己的数据来保证系统的稳定》，和我用的类似但不完全相同。

开发需要做的第三件事：联调完毕，压测完毕，机器扩容也完毕。在我这个小菜看来，我的系统就可以发布了，后经运维再三提醒与要求，给接口加上了服务开发，方便在各个活动中进行服务的升降级。公司内部有自己的分布式资源管理组件，可很方便的实现应用开关，基本的实现思路可以看一下这篇博客：《java分布式系统开关功能设计》

由于接的这个项目并非支付宝关键链路上的系统，所以系统优先级会比较低，我上层的应用做的限流机制也比较轻便。业务方会评估我系统的应用容量，配置报警机制，在超过容量阈值的时候报警，同时人工干预进行系统限流。具体的限流实现也较为简单，分布式资源管理系统推送限流概率，比如说0.9，业务则会通过Random过滤掉约为10%的请求，直接抛弃掉，好像也很弱的样子。当然，这是属于应用级的限流，也有系统级的限流，比如淘宝那边的TMD，支付宝这边的SLA，都没有深入了解，如TMD是nginx的一个组件，应该是在接入层做的限流，如限流控制在500TPS，那么第501个请求则直接抛弃。运维方面，在双11前几天也会提前查看机器状态信息，如负载、请求量、日志情况，针对不同的情况作出不同的调整，比如动态给数据库集群增添机器、修改报警阈值等。

3、后记

以上便是我这个双11相关工作周边游荡的编外人员所接触到的双11内部机制，无论是理解还是实践都比较肤浅，不过还有机会深入双11核心工作滴，木哈哈哈！

双11前两天我那系统的请求量还是挺可观的，比平常翻了十翻，但是双11当天请求量却掉回解放前。应该是被限流了，不是关键链路上的就是悲惨啊！！！