究竟是客户差劲，还是腾讯云差劲？
摘要
腾讯云在一个客户成功案例中宣称其客户“技术能力参差不齐”，“对云产品不熟悉”，需要腾讯云“保驾护航”。但是认真研究就会发现，腾讯云服务CLB模型设计不合理，不像一个服务而更像一个安装器，界面泄漏实现细节，文档质量“参差不齐”，导致用户实在无法自助服务（Self Service），只能请腾讯云团队来驻场交付了。
背景
腾讯云针对该客户的成功案例有两篇文章，发表在腾讯云开发者公众号的：7天DAU超亿级，《羊了个羊》技术架构升级实战， 和发表在腾讯云公众号的：羊了个羊的“无准备之仗”：7天DAU破亿神话背后， 两篇文章大同小异，下面对其引用不再区分来源。
腾讯云指出客户的问题主要是
单点服务的性能瓶颈，再加上代码未进行充分优化，造成当时的系统最高只能承受5000的QPS
因此腾讯云提出三点优化：
在计算扩容层，依靠腾讯云云原生产品为原有技术架构升级，实现服务高可用；
为快速补齐运维能力，通过业务日志诊断程序性能，配合业务调优以减少服务器压力；
最后在安全防范领域，通过安全方案抵抗异常流量攻击。
这一段文字挺难读懂的，“计算扩容层”是个什么新发明的名词？第一条提到的高可用（High Availability）是用来消除单点故障（Single point of failure）以提高服务可用性（Availability）的，它和要解决的系统处理能力（Throughput）没有什么关系。第二条和第三条都是在降低服务器压力，那么最终是靠扩容出（Scale out）更多的节点还是靠优化单机能力+降低请求数达成了目标？
但是没关系，我们就认为这是实习生乱总结的，忽略它（问题1），直接看架构图。
然后严重的问题来了，腾讯云的优化把客户的架构改坏了！
客户的架构非常简单
下面是客户的原架构，原文引用
玩家流量通过一个LB进入，传输给几个POD进行游戏逻辑处理， 再将数据进行存储，其中，热数据存储在Redis中, 持久化数据存在MongoDB
这是常规架构，非常适合Web游戏，并不是文章声称的“有点简单”。
腾讯云“优化”后的架构复杂多了
然后腾讯改成了这样：
最大的不同在负载均衡
虽然两个架构图暗示客户的应用服务器在优化前用的是1-N虚拟机（问题2），而在优化后部署到了Kubernetes，实际上“《羊了个羊》在6月上线初期就采用了 TKE Serverless 的云原生方式部署”， 所以这一块其实没变。
两个架构图的差异只有两个
多了一个WAF
从一个CLB，改成了多个性能型CLB
架构图2的WAF显然画错了位置，SaaS型的WAF应该部署在CLB和玩家之间，负载均衡型WAF应该挂在CLB旁路， 架构图2这种WAF和CLB并列的部署法不伦不类。WAF和CLB两者同时对玩家暴露地址，这恐怕是在开玩笑。（问题3）
但是也让我们也忽略这个实习生水平的问题吧。问一个大问题：
为什么要从一个CLB改成多个CLB？
CLB是一个负载均衡服务，客户为什么应该从一个CLB实例改成多个CLB实例？既然有多个CLB，那么谁又来管理CLB的负载均衡？
我试图从腾讯云文档里找个说法，看到CLB定义如下
负载均衡（Cloud Load Balancer，CLB）是对多台 云服务器 进行流量分发的服务。
原文的云服务器四个字直接链接到Cloud Virtual Machine服务，然而上面架构图清楚的表明CLB可以对多个Kubernetes pods进行流量分发，所以这个定义是错的，或者至少过时了（问题4）。
但是忽略过时的部分，我们可以确认CLB是一个服务（Service），而不是一个安装器（Installer），因此用户自然的有三点期望：
负载均衡服务要能提供on demand能力，自动扩缩容以处理来自客户端的峰谷请求。
负载均衡服务应该自治，用户不需要关心LB节点的加入和退出。
负载均衡要有健康检查，以自动排除（deregister）不健康的后端节点。
CLB本身不能自动扩容
实际上，CLB在第一个自动要求上就挂了。根据腾讯云CLB的文档《实例规格对比》，CLB分为两大类：共享型和性能容量型，其中性能容量型又分标准型，高阶型1，高阶型2，超强型1。各位读者也不用去看文档了，这些花花绿绿型号的区别就是处理能力不同，名字越酷的能力越强， 比如超强型1的每秒新建连接数是100,000， 而共享型的每秒新建连接数只有二十分之一5,000。
最重要的是，这些实例之间不能自动转换，比如你买了个标准型CLB，等你流量上来的时候，它无法自动升级到超强型1。（问题5）你需要手动调用性能容量型变配API—顺便吐槽下，这个API名字太不知所云了—去升级你的共享型实例到性能容量型实例。至于性能容量型的亚型之间，无法升级。
这意味着什么？这意味着你和我，作为客户，需要对CLB做容量规划！也就是启动CLB的时候，我就要预估流量上限是多少，如果流量超出了我的预估，我就要手动换高型号，或者再手动多启动几个CLB。
这是一个很荒谬的要求，云服务天天说offload日常运维工作，却要求我预估流量。如果流量起来的时候，还需要我手动修改配置，那云服务的价值在哪里？
实际上CLB团队自己也被这个奇怪的模型搞晕了，上面文档是叫“共享型CLB”和“性能容量型CLB”， 而架构图分别叫“CLB”和“性能型CLB”， 而DescribeLoadBalancers的API文档里又叫“共享型集群的公网负载均衡实例”和“独占型集群的公网负载均衡实例”。（问题6）上面文档里有标准型等四种亚型，但是API文档里只有“SLA”一种亚型，是”超强型1“。（问题7）
不止文档被搞糊涂，CLB的Console也被搞晕了，根本就不支持用户选择共享还是独占。空口无凭，截图为证：（问题8）
最后，为了防止我们还没被搞糊涂，他们加发了一个通知：
为提供更加弹性、稳定、高质量的服务，从2021年11月2日00:00:00起，腾讯云所有负载均衡（Cloud Load Balancer）实例将进行架构升级，升级后所有负载均衡实例将提供并发连接数5万、每秒新建连接数5000、每秒查询数（QPS）5000的保障能力。
醒醒，这位同志，你醒醒，如果所有负载均衡实例的每秒新建连接数都变成5000的话， 你不是在升级架构，你是在降级我的实例啊。（问题9）
穿越这糟糕的设计和混乱的文档，我们就能看出架构图2的多CLB是怎么回事了：用来弥补CLB不能自动扩容的严重产品缺陷。但是文章没有勇气承认自己产品的问题，却指责客户“不熟悉云产品”，实在是不厚道。
这个丑陋的多CLB设计绕过了产品缺陷，但是又给用户引入了下一个负担：
CLB不能自动管理IP
普通云用户一般预期一个负载均衡实例会返回一个LB域名，然后客户把LB域名设置为自己域名的cname。
这个抽象的好处是：
用户不操心负载均衡服务底层是几个或者什么IP了
服务提供商可以自由的扩容，缩容，多AZ HA，甚至跨区域 DR。
但是CLB返回给用户的endpoint是一个固定的IP，因此架构图2中客户会得到多个CLB，并且客户需要手动的在域名记录中管理这个IP列表。（问题10）也就是说，客户在CLB之前又做了一层域名层次的负载均衡，还是手动的！
有多个CLB， 你就要多次部署SSL证书到多个CLB上。虽然腾讯云支持一键部署证书到CLB， 却不提供证书的自动更新。所以你开了几个CLB，一年后你就要手动更新几次证书。（问题11）
两个对负载均衡服务的期望都落空了，让我们看看第三个要求：自动检查节点健康。
CLB支持节点健康检查，但是。。。
实事求是， CLB确实支持节点的健康检查，虽然不能定制healthcheck endpoint寒酸了点（问题12），但是没关系，以后可以加这个特性。
但是有个问题以后就很难改了。健康检查API有个很明显的错别字:（问题13）
哥们，是Detail，不是什么Detial，没有这个Detial词，英文德文法文，日本平假，汉语拼音，台罗拼音，都没有这个词。
但是既然API这样写了，SDK就只能跟着错，所以：
Python SDK 写错别字
Go SDK 也写错别字
Java SDK 也写错别字
但是用户写代码很可能用正确拼写的 HealthStatusDetail，然后他们会被SDK抛出一个异常（问题14），所以，还是请改正吧。
CLB的API不完整，用户界面泄漏实现细节
一个云服务的用户要自己预估容量， 要自己替换实例升级型号，要自己管理DNS解析，要自己手动更新SSL证书，那还算哪门子服务？
要不我们用户干脆自己搭个Nginx算了？
实际上，CLB就是一个腾讯云帮你搭建的Nginx。CLB Console甚至还提供表单让你修改Nginx的配置项：
然而，这个能力在CLB API里不提供。
这就导致了两个问题：
这个特性不在API（参见修改负载均衡实例的属性API），因此用户无法通过可编程的SDK或者terraform调用，被限制住必须上Console手动配置。也就不可能采用Infrastructure as Code做自动化以落地DevOps。（问题15）
这种配置项是具体的Nginx实现，既然CLB提供出来了，那它就是用户界面的一部分，后面如果CLB团队想把Nginx改成Envoy或者其他，那就会造成向后不兼容性问题。实际上，腾讯云API确实很不稳定，2.0升级到3.0又大变了一次。（问题15）
话都说到这个份上， 要不真的去搭建Nginx？就这涉及到另外一个问题：
CLB把客户请求解密后以明文形式在共享网络发送
腾讯云实际上鼓励用户自行搭建Nginx，还有个专门的页面教客户怎么搭建Nginx，不过他们说
本文将为您详细介绍如何在 CentOS 系统下部署 Nginx 项目，适用于刚开始使用腾讯云的个人用户。
实际上，自行搭建并不适用于个人用户，个人用户还是用CLB比较方便。自行搭建Nginx更适合企业用户，因为CLB有一个安全隐患（问题16）：
CLB 对 HTTPS 进行代理，无论是 HTTP 还是 HTTPS 请求，到了 CLB 转发给后端 CVM 时，都是 HTTP 请求。这时开发者无法分辨前端的请求是 HTTP 还是 HTTPS。
其他用户可能不在乎，但是对我这种强监管行业用户来说，CLB把我客户加密的请求在一个其他用户可以配置的共享Nginx实例上解密了，然后以明文在共享网络传输，是绝对不可以接受的。对我们来说，HTTP只能用于localhost，任何其他流量都必须是HTTPS加密的，即使在VPC内部，更不用说在VPC之外。
总结
上面列举了16个问题，但是总结起来主要就是：
CLB服务的模型设计有天然缺陷，把容量，IP地址和证书的管理责任推给用户，没有尽到一个云服务最基本的责任。
CLB的Console提供API之外的能力，阻碍了客户自动化。
CLB的Console还造成抽象泄漏（Leaky abstraction），会阻碍服务升级或者造成向后兼容隐患。
CLB的安全设计没有考虑企业合规需求。
CLB的文档互相矛盾，取名混乱，甚至还有错别字，普通用户不可能看得懂，这才是用户“对云产品不熟悉”的根本原因。
其他疑问
对于这个成功案例，还有其他疑问。
秒级扩容是怎么回事？
文章称：
系统能够在秒级自动扩容了近万核容器资源
但是TKE所用的监控系统prometheus的默认采集频率是1分钟（参见 https://prometheus.io/docs/prometheus/latest/configuration/configuration/#duration ），所以这秒级扩容是怎么回事？你不能说60秒也是秒级吧
为什么用日志而不是指标？
文章称：
《羊了个羊》选择了开箱即用的日志服务 CLS，CLS 对游戏接口稳定性、异常调用趋势的监控可帮助他们快速观测产品质量 ，并第一时间获取到异常panic统计分析和告警 ；在游戏运营方面，玩家登录链路耗时/对局时间等数据亦可通过 CLS 分析、校验及处理，进而调整和提升游戏体验
链路耗时，对局时间都是很直观的metrics，为什么不用云监控服务（Cloud Monitor）服务而用更贵更不直观的日志服务CLS？另外基于日志的告警是不推荐的工程实践，因为相对指标来说，日志内容更容易可能被程序员无意修改从而使得告警静默失效。
世界上没有标准化架构
文章称：
针对不同赛道搭建标准化架构，为游戏公司的业务保驾护航。
这是一种很无知的说法，没有任何人可以定义标准化架构，理查德·斯托曼（Richard Stallman）都不行，你能做的最多的就是推荐参考架构（Reference Architecture）。
而且，参考架构也不应该来自云厂家，而是来自用户，就像最佳射击实践不会来自兵工厂的工程师，而只能来自战场上的士兵，即使工程师收入比士兵多，学历比士兵高，也不能改变这个规律。