+倍性能提升全过程优酷账号绑定淘宝账号的TPS从到的优化历程.docxVIP

10+倍功能提升全过程--优酷账号绑定淘宝账号的TPS从500到5400的优化历程 2021年的双11在淘宝上买买买的时候，天猫和优酷土豆一起做了联合促销，在天猫双11当天购物满XXX元就赠送优酷会员，这个过程需要用户在优酷侧绑定淘宝账号（登录优酷、供应淘宝账号，优酷调用淘宝API实现两个账号绑定）和赠送会员并让会员权益生效（看收费影片、免广告等等） 这里涉及到优酷的两个部门：Passport（在上海，担任登录、绑定账号，下文中的优化过程次要是Passport部分）；会员（在北京，担任赠送会员，保证权益生效） 在双11活动之前，Passport的绑定账号功能一直在运转，只是没有遇到过大促销带来的挑战 会员部分的架构改造 接入两头件DRDS，让优酷的数据库支持拆分，分解MySQL压力 接入两头件vipserver来支持负载均衡 接入集团DRC来保障数据的高可用 对业务进行改造支持Amazon的全链路压测 次要的压测过程 上图是压测过程中次要的阶段中问题和改进,次要的问题和优化过程如下： docker bridge网络功能问题和网络中缀si不均衡 （优化后：500-1000TPS) 短连接导致的local port不够 （优化后：1000-3000TPS） 生产环境snat单核导致的网络延时增大 （优化后能达到测试环境的3000TPS） Spring MVC Path带来的过高的CPU消耗 （优化后：3000-4200TPS) 其他业务代码的优化（比如特别、agent等） （优化后：4200-5400TPS) 优化过程中遇到的比如淘宝api调用次数限流等一些业务问题就不列出来了 Passport部分的压力 由于用户进来后先要登录并且绑定账号，实际压力先到Passport部分，在这个过程中最开头单机TPS只能到500，经过N轮优化后基天性达到5400 TPS，下面次要是阐述这个优化过程 Passport 核心服务分两个： Login 次要处理登录恳求 userservice 处理登录后的业务规律，比如将优酷账号和淘宝账号绑定为了更好地利用资源每台物理加上部署三个docker 容器，跑在不同的端口上（8081、8082、8083），通过bridge网络来相互通讯 Passport机器大致结构 说明：这里的500 TPS到5400 TPS是指登录和将优酷账号和淘宝账号绑定的TPS，也是促销活动次要的瓶颈 userservice服务网络相关的各种问题 太多SocketConnect特别（如上图） 在userservice机器上通过netstat也能看到大量的SYN_SENT形态，如下图： 由于docker bridge通过nat来实现，尝试去掉docker，让tomcat直接跑在物理机上 这时SocketConnect特别不再消灭 从新梳理一下网络流程 docker(bridge)—-短连接—访问淘宝API（淘宝open api只能短连接访问），功能差，cpu都花在si上； 假如 docker(bridge)—-长连接到宿主机的某个代理上（比如haproxy）—–短连接—访问淘宝API， 功能就能好一点。问题可能是短连接放大了Docker bridge网络的功能损耗 当时看到的cpu si格外高，截图如下： 去掉Docker后，功能有所提升，连续通过perf top看到内核态查找可用的Local Port消耗了比较多的CPU，gif动态截图如下（可以点击看高清大图）： 留意图中ipv6_rcv_saddr_equal和inet_csk_get_port 总共占了30%的CPU 一般来说一台机器可用Local Port 3万多个，假如是短连接的话，一个连接释放后默认需要60秒回收，30000/60 =500 这是或许的理论TPS值 同时观看这个时候CPU的次要花在sy上，最抱负确定是期望CPU次要用在us上，截图如下： sy占用了30-50%的CPU，这太不科学了，同时通过 netstat 分析连接形态，的确看到很多TIME_WAIT： 于是让PE修改了tcp相关参数：降低 tcp_max_tw_buckets和开启tcp_tw_reuse，这个时候TPS能从1000提升到3000 优化到3000 TPS后上线连续压测 竟然功能又回到了500，太懊丧了，其实最开头账号绑定慢，Passport这边就怀疑taobao api是不是在大压力下不稳定，程序员一般都是认为本人没问题，有问题的肯定是对方 ：） ，taobao api那边给出调用数据都是1ms以内就前往了（alimonitor监控图表）。 于是怀疑从优酷的机器到淘宝的机器两头链路上有瓶颈，但是需要设计方案来证明这个问题在链路上，要不各个环节都会认为本人没有问题的，当时Passport的