当考虑云计算资源成本时，云虚拟机的价格常常难倒不少小企业。这时，有人认为，选择云原生架构可能是一个更经济高效的选择。云原生架构可以通过容器化技术和服务器无状态设计来提高资源利用率，从而降低成本。此外，云原生架构还可以实现更快的部署速度、更高的可伸缩性和更好的性能，有助于降低长期成本。

那么，具体怎么实现？方案又可不可行？第八期《开源漫谈》，我们邀请了3位嘉宾：马工、李令辉和李冠宇，一起来分享一下，云原生架构替代云虚拟机有哪些好办法。

• 马工，在北欧从事 Infra 工程师，公众号《瑞典马工》主理人。

• 李令辉，云原生数据库 clapdb 创始人，前乘法云 CTO，美洽 CTO，滴滴出行首席架构师。目前致力于基于云上的基础设施新范式，提供新时代的分析型数据服务。

• 李冠宇，微信生态领域 MVP，就职于相关团队担任技术产品经理、架构师；为多家企业组织提供上云架构和微信生态产品咨询服务，公众号《咋用云》。

马工：有人认为，云原生架构可能是一个比虚拟机更经济高效的选择，它可以通过容器化技术和无服务器来提高资源利用率，从而降低成本，还能获得更快的部署速度和更高的伸缩性。那么今天我们就通过一个案例来仔细地分析一下，这种说法究竟有没有道理，云原生架构究竟能带来哪些好处？

李冠宇：我做了一个手绘的架构图，大家在这里可以看到，其实就两个核心的云产品，一个是对象存储，一个是 CDN。

首先这个九毛九架构的客户，是一个预制菜小商家，他自己不懂技术，希望以最低的成本实现扫二维码跳转第三方小程序来查看礼盒的使用场景。就是他的二维码贴到不同规格的礼盒里，当购买者扫描礼盒上的二维码之后，就会自动跳转到这个小商家的小程序里，能够看到礼盒里有多少个菜品，每个菜品都是啥。整个都是一个礼盒信息的展示，不涉及线上购买。

我在做方案时用到了这两个公有云最基础的产品，一个是对象存储，一个是 CDN，完成了整个交付。整个开发过程包括沟通的时间，也就一个小时。后续整体运行到现在半年多了，都非常平稳，也没有做一些维护的工作，期间还承受过两次大规模的访问。商家用了腾讯云自带的一个对象存储的客户端来修改商品信息，发布频率大概一年两次。

所以它是一个典型的读多写少的场景。这个架构也很常见，它主要就是面向读多写少的静态数据分发场景，比如企业的网站，都会用对象存储+ CDN 的这种架构来分发一些静态网站数据，比如图片、视频、JS、HTML 和 CSS 文件等等。那么，在这个需求中，很多小程序开发者可能会认为，如果要做一个联网的小程序，那么必须要有一个服务器，就感觉服务器跟联网小程序是划等号的。但实际上来说，不需要。像这种读多写少的典型场景，它仍然在 CDN +对象存储的适用范围内，不光能够给浏览器分发静态文件，还能够当做服务端来给前端调用。

马工：如果我是个没有任何云原生经验的人，我可能会弄个虚拟机，打开之后域名就指向这个虚拟机，这个虚拟机装一个 Apache 返回来，如果需要更复杂一些的话，我再装一个 MySQL。最后，虚拟机要维护，域名要维护，MySQL 要维护， Apache 如果有安全漏洞，我要维护，所以这个其实还是挺麻烦的。而且，它的访问量其实不大，哪怕一个最小的虚拟机，也是过剩的。

李冠宇：对，其实它每天访问不到一万次，每次满打满算来 500KB 的话，也花不了多少，一个月的消耗不到一块钱，加上云厂商给的每个月的免费额度，它甚至不花钱，1年都花不了多少钱。

如果大家跟我一样有做过微小型用户的架构，比如说喜欢使用微盟，有赞这种去搭建的，这些用户有一些共通的场景，他们会用三点来评估一个方案好不好：

第一是易用性。因为本身没有技术，但需要很多服务，比如需要防盗链、防火墙、IP 限频、就近分发这些去包装自己，那做虚拟机的话技术门槛就太高了，后期运维也需要成本；

第二是可靠性。用户买服务的时候，希望就跟买房子一样，能够直接住进去，而不希望三天两头要维护。所以他们希望服务在运行过程中能够保持稳定，尽可能不需要任何的运维干预，除了最基本的消耗之外，不希望出现时不时的故障，然后找人维护。如果出现故障的话，可以自愈。

从这两个角度出发的话，上面的方案就是性价比最高的了。

用这套架构的话，第一个好处：高可用免运维。对象存储和 CDN 都是云计算厂商非常成熟的产品，在持续运行方面，不用担心会挂掉，即使挂掉了，也不需要方案提供者去做，云厂商会自动给它自愈，通过云厂商自己的维护，就能达到这种效果。

第二个好处也是可用性，CDN 可以缓存到边缘节点，加快访问速度，而且 CDN 跟对象存储也提供一些安全防护或者是上限阈值的设置，可以应对一些攻击手段，全程自动化处理。比如腾讯云和阿里云，都提出了一些安全的 SDN 或者是 EDG one 这种产品，其实就是安全的 CDN 能力保护。

另外，对象存储的防盗链、IP 限频，在高可靠和可用性方面来说，低成本用户本身用得不多。小用户本身访问不多，流量的洪峰来了之后，可能会吃掉相当大一部分费用。但如果在运营厂商上开一个服务器，那流量成本可能更高。因为现在电信运营商的对象存储和服务器的流量可能是一致的，其他的话都是 IP 流量会比对象存储或者 CDN 的流量费要高一些。如果说直接预制一个带宽，99块钱一年，预制三兆的带宽，但流量过来之后，撑不撑得起这么大的访问量？所以本身来说，商家是要在低成本的基础上实现高可靠的，这种情况本身就很苛刻，你没有办法通过自建或者用虚拟机来搞。

马工：也就是说，用云的话，用多少付费多少，它有足够的弹性。如果是自建的话，就要按最高峰来规划我的容量，但其实99%的时间没有用上那个最高峰，可如果没有那个高峰流量的能力，高峰来的时候又会给客户业务带来很大的损失。

李冠宇：对，这其实就跟用户买保险一样，我就为了他的最高峰去做一个保险，但他们觉得我就要按现成的付费，那这样的话大部分人都不会去做了。

李令辉：我来泼个冷水。你这里讲的 CDN，你要说 CDN 是云原生，我相信很多听众是不同意的。这个东西存在那么多年了，怎么就云原生了？这个是有争议的。如果你的高可用、你的成本、防盗链，什么都是靠 CDN 来做，那么你很难解释这个架构是一个云原生架构，和传统架构有什么不同？因为如果按照你的逻辑来说，流量成本是关键，那后面起不起虚拟机有那么关键吗？

李冠宇：CDN 它的分发是这样，但是实际上来说，CDN 它上面有很多功能的，这些能力并不属于一个非常裸的东西。比如说自建，用一些 IDC2.0 的厂商去做，他们不会提供这种安全的能力，因为我首先要做的是易用性。

李令辉：像一年发布两次的这种用户，他其实用什么都不重要，按我的理解，如果我是他的话，我就直接发在 CDN 上，我也不回源。因为我也没有变化，我回什么源？别说对象存储了，我什么都不需要。我这个静态站我用什么不行？

我这个问题，代表了一些从传统视角来看这个架构的人。因为架构不仅仅代表的是技术上的先进性。比如说9块9和99中间的差值当然很小，但 Total cost of ownership 我们要考虑进去。比方说，你的工资是老板付的吗？不。是甲方、是你们的平台帮老板支付的。如果老板想自己雇佣你的话，那么这个成本要不要加上？如果他要找个外包，八成外包是会用虚拟机的，但你这个架构他未必会。

李冠宇：我明白，如果作为一个外包的角色在市场上做这种工作，我可以不搞这个东西，我可以把这个东西直接写成一个完全部署的脚本，做成微盟有赞那种形式。别人如果要报价，我把我自己的人力加进去，然后加上这个服务，报价1000。因为我整个用的云原生的东西，我不用去做持续性的维护。

李令辉：所以我觉得你这个架构其实还有个亮点，像对象存储这样非常成熟和稳定的 Pass 服务，它降低了运维难度和运维成本，因为即使找个外包去做，那后续找外包维护的成本也不低。但是用了这个，就能省去运维成本。所以，我们不能只看做这个项目的成本，还要看维护这个项目成本。维护项目成本中，对大部分小企业来说，服务器成本都是小头了。

因为，它就不可能比人的工资贵，至少以中国现在的工资水平来说。所以如何让一个架构简单到几乎不需要人去维护，我觉得这个架构才是有价值的，对于中小企业来说。

因为，架构本质是追求可维护性的。架构对计算机来说有什么区别？没什么区别。对我们人来说才有区别。对计算机来说都是二进制，都是指令集在跑。所以本质上来说，一个架构如果很复杂，需要考虑很多层面，比如这个虚拟机我买的存储够不够，我买的内存够不够，不够了怎么办？需要迁移？这些东西都是包括在隐含成本里的。但你这个架构，因为用了更简单的 API，有更成熟的服务，这些服务都自带了。

所以我觉得这是架构的一个亮点，如果只从开发者的角度来说，他往往觉得我更熟悉 java，我为什么要搞这个我不会写。但对于真正为这个账单买单的人来说，他要考虑的不应该只是服务器成本，（甚至最后考虑服务器成本），首先需要考虑的是长久性的人力资源的投入，即开发成本+维护成本。

马工：我想问个问题，你刚刚提到了 Total cost of ownership，这种硬件成本占 TCO 多大的比例算是行业平均水平？

李令辉：不同行业差别非常大。比如说，对于视频网站公司来说，流量成本就是最大头，别的都像送的。因为流量特别贵，尤其是中国，西方 Netflix 的流量占整个全网流量的10%+，它的硬件成本都没有成为大头，你想吧。其实严格来说，硬件成本对于大中型企业来说一般都不是大头。对于小型企业的话，看多小吧，看你这个企业是做什么的。比如说做全世界网站备份的那个公司，主要成本就是服务器和存储。但是对于冠宇的那种客户来说，这个硬件成本，不管是9块9、99、999都非常低，都可以认为是1%一2%，这种用户他最不在乎的就是服务器成本。

马工：也就是说，我们优化服务器成本其实都是在小数点后面好几位做优化？

李令辉：是这样的，所以我一直不同意我们做云原生架构讲的道理是给它优化服务器成本，因为这件事情对于大部分企业来说，他听完就没兴趣了。我举个实际的例子，很多企业比如说互联网大厂，我就不说是哪一家，整个服务器硬件成本、就整个技术成本可能也就占个百分之二三十。你们可以自己上财报看，很多互联网大厂都有财报，整个研发成本占公司总成本的百分之多少。这本身就是个小头，这里面的大头是人员工资和股权激励。去掉之后，服务器成本真的没有多高，摊销之后就更低了。所以，往往三年的服务器，他用五年的，你说搬到云上能省钱，他们肯定就梗着脖子说那我的服务器都买了，我以后可以不收钱，我就交个电费，交个价位费，带宽费就行了。

从这个角度来说，想降服务器成本这件事是错的，因为服务器成本本来就不是大家最 care 的事情。但实际上来说，原来为了维护一个自建的复杂的架构，你需要在各环节部署专家，否则你遇到问题是解决不了的。但现在普通的小厂哪里去请到这样的专家？所以我觉得，云原生架构，是更好的分工，你起码能够跨互联网，把这个专家请到你公司来。社会的进步不就是协作。本质上来说，用成熟的架构，就是把专业的事情交给专业的人，自己专注于自己的业务。每个公司都有自己擅长的东西和不擅长的东西，我就没有见过一个重建 Linux 的，因为都不擅长。

马工：如果要扩展的话？比如说我要加个支付服务的话，你这个还能玩吗？是不是我要把虚拟机搬回来？

李冠宇：不用。CDN 服务它只做静态分发。我的观点是只有适合场景的推荐架构，没有标准的架构，所以它只适合上面这种读多写少的小程序。如果是标准的业务服务器的话，就会有计算服务，那就会用到下面这种架构了：

像刚才那种图片什么的，可以通过 CDN 服务去做静态分发；

对于一些请求，像注册之类的，它肯定是落到数据库里，那就必须要通过一个计算服务。计算服务是处理客户端的动态请求，包括回动态的一些数据，然后连接数据库和对象存储。客户端可能会有一些直接上传的文件，直接去到对象存储，计算服务负责在上传文件的时候做一个预授权。它的整个逻辑是这样子的：

如果要上传文件，客户端要先向业务服务器请求预授权的链接，通过云服务厂商的访问控制，在业务服务器里获取临时密钥，然后返回一个预签名的链接，客户端直接通过这个预签名的链接，在特定时间上传文件到这一个路径下，到对象存储里。业务服务器会跟对象存储通信，验证文件上传是否可行。这就是客户端直传到对象存储。

回到计算服务，你可以根据你的不同需求，去用服务器或云函数，也可以用容器服务，去做整个计算服务。它核心就是计算服务、数据库和对象存储。数据库是做结构化，主要做动态的结构处理的，对象存储是做一些非结构化的数据，或者是需要静态分发的东西，通过 CDN 流传出去。它是三个核心。

这两年，像微信提出的微信云开发、微信托管以及阿里云的云开发，如果细分的话，其实都是计算、数据库和存储这三家，它其实是一个存算分离的结构。在这种情况下，它其实都是给你固化了的，可以满足非常多的场景需求了，算是一个半推荐的、能够适应很多场景的情况。

这里的计算服务，还可以写一些关于后端的逻辑，然后去调用数据库、调用对象存储。

马工：这些计算服务具体体现在各个云厂家的产品上是对应哪些？

李冠宇：各个云厂商的计算类。比如说服务器其实也算，但是服务器我并不提倡，我提倡的是存算分离，所以服务器本身可以是无状态的，只专做计算，所有持久化的数据都是放在数据库或者对象存储里。

当然，如果你不需要，或者请求不多，服务器很难受、不适应，那就可以用云函数来替换。像目前云开发、Laf，都是用云函数类型或者容器的形式来替换这个计算服务。这样客户端请求它会以最小资源来运行，最大程度上简化计算服务。

但如果说需要一个非常持久的、感觉每一秒都会有很多人来进，那么可能就需要一个比较大的服务器或服务器集群，或者通过弹性伸缩来做。

马工：你的意思就是说，我们不应该用文件系统？

李冠宇：文件系统可以做缓存，但是它并不能做持久，反正我不推荐。存算分离的话，如果服务器遇到了瓶颈，可以用弹性伸缩解决，可以根据业务的请求来做峰值的灵活调整。计算服务可以扩展，数据库也可以扩展。如果这个架构，放在虚拟机上的话，那就要关心磁盘是否被写满，是否需要扩展磁盘；如果数据库在虚拟机里，那么数据库爆炸了怎么办？这时候你只能把它包装成一个巨大的一体机。但是一体机再大也是有限的，不可能无限大，你总会陷入瓶颈。

大家对此怎么看呢？快留言说说你的经验吧～

直播回放如下，错过的赶紧扫码看看回放吧↓↓↓