上云还是下云，最大挑战是什么？对话章文嵩、毕玄、王小瑞

https://xie.infoq.cn/article/827cad506d52eb7dd1296b6a0 AutoMQ x 阿里云云原生创新论坛火热报名中~

近半年来，公有云领域频频发生阿里云、滴滴等平台崩溃事件，与此同时，马斯克的“X 下云省钱”言论引起了广泛关注，一时间，“上云”和“下云”成为热议话题。在最近举办的 AutoMQ 云原生创新论坛上，AutoMQ 联合创始人兼 CEO 王小瑞作为圆桌主持人，与 AutoMQ 联合创始人兼 CSO 章文嵩、贝联珠贯创始人兼 CEO 林昊（毕玄）两位技术大咖，围绕上云与下云的趋势之争，以及面临的挑战展开思想碰撞。

本文根据现场对话总结整理，完整录屏可以在视频号“AutoMQ”或者 B 站“AutoMQ官方账号”观看。

Q1：云厂商的营收一路飙升，但同时又听到各种下云的案例，比如推特下云节省了 60% 的成本，未来趋势是什么？

章文嵩：我觉得上云肯定是大势所趋。因为云是给客户创造价值的，就云计算的本质来说是资源的聚合与复用，通过超卖的方式实现成本的降低，从而帮助客户实现成本节省，同时也为云厂商创造盈利机会。以一个简单的例子来说明，原本 A 用户和 B 用户分别在白天和晚上使用机器，每个时段都需要花费一个单位的成本。然而，云厂商的出现让 A 和 B 都不再需要购买机器，而是通过租赁的方式，付给云厂商较低的费用如 0.6，使得云厂商的收入 1.2 超过了 1 个单位的成本，实现了盈利，客户也省钱了。通过错峰使用，A 用户和 B 用户仍然可能没有消耗掉全部的计算资源，云厂商有机会还能将未使用的资源卖给其他用户，实现了资源的高效复用。另外还有研发资源的复用，随着系统规模的增大，边际成本降低，云计算成为一个能够持续创造价值的解决方案。比如美国的一份报告说明，在所有的 IT 支出里面，2022 年美国云计算的渗透率将近 10%，而 Gartner 预测到 2026 年，这一比例将上升至 20%。在中国，尽管 SaaS 行业发展尚未成熟，但 IaaS 和 PaaS 模式已经在云厂商中得到广泛应用。以阿里云为例，过去两年一直保持盈利，阿里云所有云资源的收入加在一块，大概是一年 1000 亿左右，阿里云市场份额占比 30%-40%，整个中国云市场的规模约为 3000 亿。通过工信部公布的中国整体 IT 行业的收入 10 万亿，可以得知中国云市场渗透率大概 3% 。当然中国未来 SaaS 空间会很大，所以美国如果四五年后达到 20% 的云渗透率，那中国有可能到 10% 以上的渗透率，未来 50% 甚至 70% 以上的渗透率，所以我觉得上云是大势所趋。

毕玄：创业后，我接触到了更真实的情况。以前代表阿里云拜访客户时，客户因我可能促使他们购买更多阿里云产品而避免说实话。现在作为中立方，客户更愿意分享真实想法。从整体趋势上来看，我坚信云计算有巨大增长空间。尽管中国云市场增速下降，甚至阿里云是比前两年有下滑，但这有很多综合原因，总体上我觉得云肯定还会继续增长。许多公司衡量云成本的方法很简单，即比较线下机器支出和搬到云上的费用。但考虑到人工成本，难以简单对比。大公司即使迁移到云上，人工成本仍然存在，因基础设施管理人员短期内难裁员。我之前跟某互联网头部公司的人聊到底是要往云上搬，还是继续保持自建的话题，核心还是要搬到云上，充分发挥云的弹性，而不是静态使用。纯静态用对大公司来讲成本难以平衡。弹性使用云，尤其是按量计费，就像现在中国按量计费比包年包月其实单价贵很多。在折扣谈判中，按量付费和包年包月分开谈，通常包年包月方案能获得更低的折扣，因为按量收入不确定性较大。另外一个问题是中国的按量错峰效应不够明显，云厂商对此不太热衷。尽管按量计费可能增加成本，但之前通过推演，我们发现在折扣谈判后，每天使用 8 小时左右能够实现成本打平。一些大公司进行了假设推演，从线下切换到按量计费和完全弹性系统，能显著节省成本。然而，由于技术改造较多，很多公司不愿采用这种方式，但我认为这是技术的趋势，很多公司一定会越来越弹性。对于大部分中小企业而言，云计算的灵活性比成本更为重要，因此它们更自然地采用云服务。从成本角度来看，随着技术的演进，整体用云的成本将逐渐降低，比自建更具优势。同时，云计算的应用不断增加也是因为壁垒的存在。在 AI 时代，大多数企业首选使用云而不是自建，因为自建的门槛较高，而云服务为业务快速创新提供了重要支持。

章文嵩老师补充 : 云厂商的核心追求指标是超卖率，因为超卖率是能够真正提高整个业务的经营效率。如果客户愿意购买包年包月，但又因为在一年 365 天中，很多时间客户并不需要使用这些资源，实际上增加了云厂商的利润。关键在于客户要有弹性，根据需求变化使用云，以节省成本，而不是根据峰值去保留资源。在上云方面，我这边是有个规模公式的，当基础设施规模较小时，在云上购买资源非常便宜；但随着基础设施规模的增大，成本上升的速率略有增加。自建的成本虽然一开始较高，但随着规模的增大，其斜率逐渐降低。两种模式的斜率不同，必然存在一个交叉点。在这个交叉点左侧，规模较小的情况下，使用云的成本较低，而自建的成本较高。然而，当规模超过一定阈值时，由于自建的起点较高但斜率较低，自建可能更加划算。云厂商针对交叉点右侧提供让利打折的机会，因为对于云厂商来说，已经投入的人力和各方面成本会随规模的进一步扩大而降低，使得边际成本更低。回到 Twitter 事例，Twitter 原来有三个数据中心，波特兰、Sacramento 和亚特兰大，应该做了类似的三活。马斯克挑战团队在仅六天内把三个数据中心缩减为两个节点，结果在平安夜他与工程师们直接关闭了位于 Sacramento 的一个数据中心，通过货车把服务器拉到波特兰数据中心。现在应该是双活架构，波特兰数据中心的服务器就富裕出来，把云上的资源优化并迁移了一部分到波特兰数据中心中，这一举措实现了约 10 亿美元的巨额成本节约，但他更多的成本节约主要来自人力资源方面。将员工数量从 8000 人裁减至 2000 人，美国工程师平均年薪 30 万美元，裁员的工资节约了近 18 亿美元，所以在总体运营成本上取得了显著的 60% 节约。然而，有些文章直接写 Twitter 下云节省 60% 了云资源成本，媒体的这个表达不正确，也容易误导观众。

Q2：云计算巨头都曾发生过大规模故障，公有云不稳定？

章文嵩： 作为曾在阿里云工作多年的前员工，我找相关同学了解到，故障的根本原因在于一个全局鉴权服务存在软件缺陷，导致正常鉴权请求被拒绝，而且没有很好的故障恢复预案。虽然有时候故障不可避免，但云厂商确实还有很多改进空间。首先，像全局依赖的中心系统应该是多区域多活的。当一个区域发生故障时，不应该影响其他区域的服务，流量应该迅速转移到其他可用的区域。这种架构可以最大程度地减少单点故障带来的影响。另外，即便是软件缺陷，我们也需要有充分的预案。在多个区域同时因为软件缺陷而宕机时，我们应该能够快速将其重启并拉起，以缩短止损时间。另外，提前演练这些预案是至关重要的，当触发潜在的软件缺陷时，有了相应的预案，一旦出现问题，重启就能够快速恢复服务。而不是在事发现场去查找问题，浪费宝贵的时间。另外，我认为云厂商也会因为这些不可靠的故障而承担一定代价的。通常，云厂商们都会按照一定的规则进行赔付，一般是不可用时长大概是 100 倍赔付规则，他们也会不断改进，避免再次陷入相同的故障。我相信随着云技术的不断改进，云系统会变得越来越可靠。云厂商的技术能力和系统可靠性在各方面都远远高于自建系统。一般情况下，自建系统可能规模较小，故障发生时都不太引人注意，但云厂商由于有大量客户在上面使用，故障的影响就更加显著。然而，正是因为有这么多的客户在不断使用云服务，云系统会得到更多的锤炼，变得越来越可靠。而且一定会比自建的系统可靠性高非常多倍，这是毋庸置疑的。

毕玄：对于故障问题，我认为云厂商相对来说故障次数要比自建系统更少。但云厂商通常因为集中化的特性，一次故障的影响面较大。相比之下，自建系统的故障可能并不为人所知，实际上累积的故障次数比云厂商会更多。总体而言，我认为用云是更好的选择。这实际上是一个自有团队的问题。许多公司还会选择使用云厂商 PaaS 的服务，因为很难找到具有专业技能的人才。在中国，从事基础设施技术的工程师数量相对较少，人才储备有限。这类人才通常待遇较高，我接触到的很多中小型客户群体，他们希望由专业公司提供服务，而不是自己搭建，因为自己搭建的话，一方面做不好，另一方面人才难以留住，这是一个非常现实的问题。因此，我认为在这些方面，云厂商的壁垒会越来越高。至于稳定性这个话题，没人敢说永远不会发生故障的。实际上，所有云厂商都曾出过严重的故障，没有一家例外，只是影响的程度取决于客户规模的大小。有时候我们会看到，阿里云发生故障时，有人回应说另一家云更好，也有人回应说另一家云可能存在更多问题，只是你不知道而已。总的来说，我相信云厂商的人才密度会更好，因此我也认为使用云服务总体上会更安全、更稳定。

Q3：如何做云上的成本治理，最优路径是什么？

毕玄： 从我接触的一些客户来看，许多企业在迁移到云平台后往往对云成本一无所知，尤其是大型集团公司。相较于繁琐的 IDC 流程，云的便利性导致一些公司对于机器的创建者和用途一无所知。因此，首次迁移到云上时，许多公司可能简单地将资源放上去，但缺乏对资源创建和用途的了解。这可能导致付费后公司在月底账单出来时才发现一些资源的存在，无法追溯。尽管这些费用必须支付给云厂商，但实时监控账单变化对成本管理至关重要。另外，我们认为在云上有很多复杂的用法，而许多公司目前还无法很好地应对。例如，资源包是一种优化成本的方式，实际上，在采购资源包的情况下，可能比原来的折扣更便宜。资源包的本质是为你提前准备好一些资源，当然，这需要一些算法，但技术含量并不是很高。有些公司购买存储资源包，就像购买手机流量一样，预先准备了一定量的资源，而这个资源在购买后必须在下个月内使用，否则不能退款。但如果公司确信能够充分利用这些资源，那么这笔钱肯定比折扣更便宜。我们知道对于很多公司来说，更省钱的方式是大量启用弹性化的机制，就像许多公司采用无服务器架构（Serverless）的方式一样。当然，这涉及许多新技术的投入，在一些公司中推动这一点可能并不那么容易。虽然这可以大幅降低成本，但要将其推广并真正应用到实践中是一项庞大的工程。相比之下，之前提到的改变采购策略、调整策略等相对来说更为简单，只需要进行一些调整即可。此外，公司还需要了解成本结构。在过去，成本分析可能并不被认为是非常重要的事项，但我们最近与一些金融、汽车等行业的客户进行合作时发现，他们非常关心集团公司的资金花在哪些部门，这些部门的业务情况，比如与业务 ROI 是否对齐。我们提到 IBM 之前收购的一家公司，主要做是做成本分析和分摊，以及与业务挂钩。例如，如果一个业务的目标是每日活跃用户（DAU），它将查看 DAU 的增长情况以及当月的 IT 支出变化情况，如果没有达到预期，管理层将进行问责。因此，这种产品在国外非常受欢迎。在中国，企业逐渐关注业务状态，对 ROI 等因素越发在意。对于 IT 结构，我将其分为业务系统、大数据和人工智能（AI）三类。业务系统的优化方案往往与业务方的具体情况紧密相关，涉及较大的实施代价。而大数据和 AI 在降成本方面展现出通用方案的可能性，这也是我们公司（贝联珠贯）主要专注的领域。在大数据方面，我们公司产品能帮客户降低 30%-40% 成本，AI 方面虽然目前降成本效果有限，但通用方案已实现 10% 的成本降低。总体而言，大部分公司目前最大的 IT 投入是业务系统，而大数据和 AI 投入较大的主要是头部公司。尽管大数据和 AI 很热门，但在 IT 支出上占据更高比例还需要时间。因此，我认为业务系统优化应根据实际情况进行。

章文嵩： 我有一个想法，除了明确成本，更重要的是将其与公司业务深度结合。以淘宝为例，作为一个买卖交易平台，其核心是交易。我们是否能算出每一笔交易的 IT 支出？比如通过计算一个月内的所有 IT 支出以及完成的订单数量，我们可以得知每一笔交易的成本。对于滴滴这样的出行平台，同样适用。它是一个撮合交易的平台，供需匹配也是其中的一环。我们可以计算每一笔交易的平均成本是多少钱。对于视频网站，观众每分钟观看视频，我们花费了多少钱呢？这实际上是可以提炼出来的，将其与业务深度结合，老板们更容易理解。比如，淘宝的客单价是多少？假设是 200 多块钱。而我们只花了几分钱的 IT 成本。其中的成本结构是什么样的？是谁支付的？过去与现在相比，哪些地方可以不断优化，持续降低运营成本？另一方面，例如从单活变为双活，这是增加的新投资，所有这些都需要清晰阐述。实际上，将成本结构与业务深度结合，不仅有助于运营优化，而且对于公司的客户沟通也非常有帮助。我在淘宝和滴滴的经验告诉我，通过将账单与核心业务本质结合，管理者能够清晰地理解 IT 成本和业务的关系。这确实是一种非常有效的方法。

Q4：如何确保系统的最终成本与业务保持一致？

章文嵩： 弹性是最关键的，系统能不能有随着业务需求进行弹性的能力？因为任何一家公司的业务需求都不是全天候平稳的，会有早晚高峰，甚至午休时的购物高峰。因此，如果我们按照需求曲线的最高点来分配资源，显然是不划算的，因为我们会为闲置的资源花费大量的资金。最理想的情况是，根据需求曲线的波动，我们的花费能够完全匹配需求曲线下的面积。实际上，这需要弹性，而弹性的能力并非易事，需要有一些共性的组件。如果每家公司都自己做弹性，涉及研发的方方面面，需要大量投入。然而，不同的企业，比如 A 企业和 B 企业，在弹性方面需要的一些公共组件是相似的。如果有一家企业已经实现了这些组件，那么 A 企业和 B 企业可以复用，这提高了效率。同时，做这些组件复用的企业也能够获利，因为它可以服务多家客户。每家公司实际上只需在某些模块上进行弹性改造，而不必对所有东西都进行改造。比如，像我们 AutoMQ 云原生的 Kafka，它在第一天就天然具备弹性，能够随着业务规模或云数仓自动伸缩，这样的组件是非常好的云原生创业机会。在云上部署时，为了获得弹性，我们要尽可能地复用一些标准组件，这对研发方面的投入是最低的，效率是最高的。当然，像之前提到的 Spot 实例，由于它们的特点是云厂商的库存资源，价格较低，但这样的 Spot 实例是随时可能被回收的。因此，如果应用程序能够适应，可能采用无状态的 Serverless 架构是一个解决方案，即使被回收了也没关系，其他地方可以接管过来。这实际上对应用程序提出了更高的要求，但在一些情况下，利用 Spot 实例这样的资源是可行的。

毕玄： 以前我在阿里带中间件团队的时候，我们一直在找降低成本的方向。给管理层汇报对于我们来说是一个很重要的任务，因为要说服管理层进行技术投入是非常重要的。从 2017 年左右，成本就成为我们的核心议题。就像正明（章文嵩）刚刚提到的，高层看待成本的指标就是——阿里的 1000 笔交易成本，也就是每完成 1000 笔交易，今年花了多少钱，明年花多少钱，后年花多少钱，他们只会问你这个问题。至于成本背后的含义，你可以有很多种理由，比如解释成本高的原因是我前面有一群人，交易效率不行，他们要更多的精细化运营等等，所以导致我要投更多机器。老板不会关心这些东西，他只关心你到底怎么给我降下去，方案是什么？所以过去我们在这方面每年都受到很大的挑战，这种偏业务型的指标确实挺好。此外，现在实施成本控制的方案，我认为在云上，弹性一定是永远的第一方案。因为你要回答高层的另一个问题，成本到底做到什么叫合理？如果你解释不清楚这个问题，那这个成本就永远都可以降，对老板来讲你觉得投 10 亿合理，老板说 10 亿太多，投 1 亿，这个是要有逻辑的，你需要向老板证明，如果我们每天的业务请求量是这样的，我所需的成本就是这个请求量覆盖的面积，这笔钱是必须花的。以前我们做中间件，这就是成本优化能做到的极致。这个极致从现在的技术表现上来看就是 Serverless，只不过 Serverless 现在要做到偏在线型的应用，全部 Serverless 化还是有相当大距离的。我们在阿里曾经推演过，如果我们只为面积付费，我们单笔交易成本应该能降到现在的 1/10。所以按照这个你推演了一个极致，老板每年就对你都不满意了，因为老板按照我们的逻辑推演后认为，成本应该降到现在的 1/10 才是合理的。我们明白技术上存在各种问题，所以现在 Serverless 肯定是大趋势。然而，观察当前的 Serverless，主要由云厂商和中立厂商提供，为大家设计了通用的 Serverless 方案。在这个 Serverless 的背后，可能是采用了按量付费的机器，很多创业公司和国外的成本优化公司采用类似的逻辑，先将应用投放到 Spot Instance 上运行，然后不够了再切换到按量付费，最后才考虑包年包月。这三层逻辑关系在国外为什么能够实现折扣券的存在呢？我们认为是因为国外许多应用的整体 IT 水平相对更高，业务的无状态能力更强，更容易进行迁移。在大数据和人工智能领域，许多公司背后都是通过大量使用这种逻辑来实现的，实际上，他们屏蔽了这一切，不需要你知道 Spot、按量、包年包月的背后逻辑，他们将这些逻辑完全封闭，卖给你时你觉得价格更便宜，但实际上他们仍然具有竞争优势。在这三层逻辑基础上，我们觉得是还可以加另外一个逻辑的，另外一个逻辑就是我们以前在阿里做的混部。在很多公司推行这个方案时，我们采用了类似国外公司的弹性策略，先 Spot，再按量，再包年包月。我们的逻辑是先混部，再 Spot，再按量，最后是包年包月。这是因为混部相当于价格是 0，而 Spot 实例是需要支付费用的。另外，Spot 实例的回收可能会导致问题，因为云厂商可能会多次回收实例。我们曾有客户经历被回收了 10 次，而其任务需要连续两个小时完成，无法中断。并非所有任务都支持断点功能，因此它如果两个小时之内被收回掉了，再购买一个 Spot Instance，在重来了 10 次以后它那个价格比按量和包年包月还高，所以这个时候你要处理很多乱七八糟的问题，包括跟云厂商，甚至有商务谈判等等，这种都不一定是技术问题。所以我们认为，实际上在技术层面，如果你按照这个方案推进，选择一个第三方或者具有研发投入能力的公司，我们觉得也可以自己投资。我们与一家大型公司合作，按照这个逻辑进行四层弹性方案，就像我刚刚说的混部 -Spot- 按量 - 包年包月，他们实施了这个方案，一年应该省下近 3000 万，按照这个方案推进，当然这可能需要一些业务投入。

Q5：对既有自建机房又使用云资源的大型互联网公司（小红书、快手）的建议？自建机房需要哪些组织能力和团队建设能力？

章文嵩： 自建的基础设施服务需要相应的研发投入。之前提到的自建和云服务的成本的交叉点，云厂商可以通过让利来提高吸引力。比如以一个拥有 5 万台服务器的互联网服务为例，考虑到硬件、托管和网络带宽资源等成本，每台机器年均花费约 2 万元，总计约 10 亿元。然而，自建还需要额外投入构建分布式系统、操作系统和数据库等，以及维护一个六七百人的研发团队，人员成本高达 5 亿。对比阿里云的规模，其年收入约 1000 亿元，阿里云应该是 2 万人，人员的成本估计要花掉 200 多亿，机器成本约占据 6、700 亿元，毛利约 300 亿元。如果扣除市场营销、人工成本费用，这个业务还是赚钱的，赚的不多，200 多亿人员成本对应一年六七百亿基础设施支出，阿里云是很有规模优势的，还有产品服务丰富度的优势。对于规模较大的互联网企业，比如 5 万台、10 万台机器，云厂商应对于这种体量的互联网用户，应该用这样的策略，了解他的成本结构，给他一个无法拒绝的 Offer。比如云厂商知道企业自建的成本结果是 15 亿，给企业 12 亿元的价格。这样对云厂商来说，规模采购会有一些成本的节约。此外，对于人员成本，如果云厂商能够保持较低的增长，尤其是在已有研发基地的情况下，也可以在整体利润中获得优势。所以，自建的成本很高且对社会无益，因为云厂商已经做得比自建要好。除非你的体量能达到百万台的机器规模，那就自建。

毕玄： 正如正明（章文嵩）所指出的，自建成本是许多公司在构建基础设施时面临的重大挑战。小红书等公司目前仍主要依赖云服务，这仅是考虑中的一种方案。相比之下，快手采用了大量自建，而云厂商若能真正影响中国头部互联网公司，其增长将是显著的，因为头部公司基本上都未完全迁移到云上。即便是头部互联网公司，如快手、美团、滴滴，虽然主要是自建基础设施，但也在一定程度上使用云服务。然而，这几家公司已经是中国顶级的互联网公司了，但自建团队仍然是一个复杂的问题，需要体系化的团队，而不仅仅是雇佣一两个人，还有 IDC 选址、服务器、网络、芯片等多方面的人才需求等问题。自建机房遇到的第一个问题是招不到人，即便明确知道需要招聘哪些人才，但实际面临的招聘难度非常大。以操作系统为例，拥有这方面经验的人才相对稀缺，而且他们多分布在大型科技公司中。招聘这些人不仅难度大，而且在大型科技公司中跳槽也相对困难。这些公司规模庞大，面临的问题多，因此有更大的发展空间。总体而言，这些公司虽然有足够的财力和意愿进行自建，但实际的执行过程非常痛苦。这凸显了人才密度是一个关键问题，不仅在中国，在国外也是一个有限的资源。

结束语

圆桌对话环节在意犹未尽中画上圆满的句号，三位大咖对话涵盖了上云趋势、系统可靠性、成本治理以及下云挑战等关键议题。为业界提供了深刻的见解和实践经验。由章文嵩与王小瑞老师创立的 AutoMQ 公司的 AutoMQ Kafka RC 版本发布了全新特性，包括多云兼容性适配，Spot 实例强制回收容灾、裸设备 WAL 等。也带来了新版本的全新指标，新版本除了有十倍的成本优势外，支持 4 分钟内完成从 0 到 1GiB/s 的极致弹性，同时在追赶读的场景下有读写隔离的天然优势。AutoMQ 即将发布完整的基准测试白皮书，将会揭秘更多的技术指标。欢迎大家体验！

END

关于我们

AutoMQ 是一家专业的消息队列和流存储软件服务供应商。AutoMQ 开源的 AutoMQ Kafka 和 AutoMQ RocketMQ 基于云对 Apache Kafka、Apache RocketMQ 消息引擎进行重新设计与实现，在充分利用云上的竞价实例、对象存储等服务的基础上，兑现了云设施的规模化红利，带来了下一代更稳定、高效的消息引擎。此外，AutoMQ 推出的 RocketMQ Copilot 专家系统也重新定义了 RocketMQ 消息运维的新范式，赋能消息运维人员更好的管理消息集群。

🌟 GitHub 地址：https://github.com/AutoMQ/automq-for-kafka

💻 官网：https://www.automq.com

👀 B 站：AutoMQ官方账号

🔍 视频号：AutoMQ

👉 扫二维码加入我们的社区群

关注我们，一起学习更多云原生干货