查看原文
其他

究竟是客户差劲,还是腾讯云差劲?

马工在瑞典 瑞典马工 2023-03-08

摘要

腾讯云在一个客户成功案例中宣称其客户“技术能力参差不齐”,“对云产品不熟悉”,需要腾讯云“保驾护航”。但是认真研究就会发现,腾讯云服务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 的云原生方式部署”, 所以这一块其实没变。

两个架构图的差异只有两个

  1. 多了一个WAF

  2. 从一个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),因此用户自然的有三点期望:

  1. 负载均衡服务要能提供on demand能力,自动扩缩容以处理来自客户端的峰谷请求。

  2. 负载均衡服务应该自治,用户不需要关心LB节点的加入和退出。

  3. 负载均衡要有健康检查,以自动排除(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。

这个抽象的好处是:

  1. 用户不操心负载均衡服务底层是几个或者什么IP了

  2. 服务提供商可以自由的扩容,缩容,多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里不提供。

这就导致了两个问题:

  1. 这个特性不在API(参见修改负载均衡实例的属性API),因此用户无法通过可编程的SDK或者terraform调用,被限制住必须上Console手动配置。也就不可能采用Infrastructure as Code做自动化以落地DevOps。(问题15)

  2. 这种配置项是具体的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个问题,但是总结起来主要就是:

  1. CLB服务的模型设计有天然缺陷,把容量,IP地址和证书的管理责任推给用户,没有尽到一个云服务最基本的责任。

  2. CLB的Console提供API之外的能力,阻碍了客户自动化。

  3. CLB的Console还造成抽象泄漏(Leaky abstraction),会阻碍服务升级或者造成向后兼容隐患。

  4. CLB的安全设计没有考虑企业合规需求。

  5. 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)。

而且,参考架构也不应该来自云厂家,而是来自用户,就像最佳射击实践不会来自兵工厂的工程师,而只能来自战场上的士兵,即使工程师收入比士兵多,学历比士兵高,也不能改变这个规律。


您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存