一个企业要均衡发展，就必须要在保证系统稳定的情况下合理降低开发成本。通常情况下，面对大型企业经常会遇到的高并发，大流量问题，很多企业会选择购买更多的服务器形成集群去解决问题，但是这样就避免不了要增加开发成本，我不禁思考，除了“花钱”这样的钞能力，是否有更完美的解决方案呢？

于是我就去搜索，是否有这样的例子来进行参考。还真被我找到了一个案例，这次的企业并不是一个传统的互联网企业，而是一个无代码开发平台，Zion，我不禁好奇，在一般情况下，在面对多业务高并发、高可用的场景需求时，无代码自身的集成能力和数据处理能力非常有限。他们是怎么解决这个问题的呢？我被每天仅20元服务器费用，支持万人级活动的案例吸引了进去。

首先看到的就是这个活动的介绍，前不久他们公司用Zion搭建的知识竞赛项目，在活动期间（2022.11.18-2022.12.1）承载了64.1万人次的访问并完成了219.2万次的答题，而这仅仅只使用了2核的服务器（高级版用户支付了7000元/年的费用）就完成了整个业务的支撑。相当于每天仅20元的服务器租赁费用就支撑了这万人级的业务，展示出了非凡的性价比，Zion是如何做到的呢？

我们知道，运行一个软件最主要产生费用的几个方面就是：

服务器算力费用应用服务器数据库服务器的对象存储费用（存储图片、视频等文件）流量费用短信等第三方服务费用

那么我们就从下面几个方面来解析

减少各种资源消耗优化数据传输降低请求的数量

Zion选用了graphql协议，利用它的特性在数据请求时将多个请求合并。这里以Zion的社区为例（Zion的社区就是用Zion做出来的）

如果想要显示红色区域的内容，传统的方式是需要请求帖子记录、发帖人信息、评论表中和这条帖子的相关记录、点赞中这条帖子的点赞记录、以及浏览记录等（也有部分做法是直接存储浏览数、点赞数，但这样的方式很影响未来的功能扩展性，比如想要显示某个人点赞过别人多少次，以及他点赞什么类型的文章最多就完全没有办法了）。这种传统的方式，可能这样一个内容就要多条请求来完成。

但利用Zion可视化配置并自动生成的api请求只需要如下一条api请求就可以完成数据的请求，这样只传输页面上需要的数据的方式，就极大的减少了请求的数量，也就节省了流量还带来了巨大的性能提升以及跨表查询的能力。

减少数据请求量

简单来说，就是Zion只读取和传输页面上需要显示的数据。以上面社区红色帖子的区域为例：Zion只通过一条请求就获得了全部需要使用的数据，包括问答标题、提问人信息、点赞数量、浏览数量以及评论数量。且未读取和传输任何不需要显示的数据。以下是用传统方法制作的社区，如果想要完成和上面相同的效果，需要发送5个请求，这里不占用太多篇幅，只贴出两张返回结果。可以看到，这样的方式不但请求量变多，还读取了很多不需要的数据，如例子中的文章内容、评论、type、version等等不需要的内容也都被读取和传输了过来。同时，像点赞数、评论数等聚合数据也需要依靠多个请求完成且也读取了非必要信息。

可以想象一下，这只是一个社区中的一篇帖子，如果这是一个10万用户有超过百万帖子浏览的社区呢？此时在性能上和资源消耗上将拉开巨大的差距。

在减少数据量的同时进一步压缩文件

Zion在默认情况下就会压缩返回结果，这点能大约节省80%-90%的流量。

减少额外请求

Zion在对数据库的操作行为中（mutation：增加、删除、修改/更新），会直接在结果中返回页面上继续需要的数据（在Zion中叫【结果数据】）。这就进一步减少了请求数量，也就进一步节省了流量和资源占用。

减少流量消耗根据屏幕压缩图片

Zion会根据屏幕像素实际大小进行服务器端自动改图片大小，显著降低带宽消耗（照片通常是5000*4000，列表在屏幕上的图通常是500*400，差100倍）补写一个腾讯的例子，为了适应显示的实际大小，往往需要存很多遍。

节省存储空间重复上传的文件只存一遍

经常会出现一个应用内的不同位置，需要多次上传同个图片或者视频等媒体文件的情况，此时实际上Zion在对象存储中只存储了一份而非多份，这就避免了很多存储空间的浪费。

不滥用json存储数据方式

Zion在数据存储方面，直接生成数据库的结构化的表，并帮用户维护，大约要省50%的空间。这样的方式下，除了大幅减少了空间占用，还带来了性能的极大提升。通过避免过度使用json方式存储数据，充分利用数据库里每一列的统计数据，让它的查询优化器产生最符合数据的查询计划。

强大的后端处理能力高并发应对能力

上面主要是说Zion如何通过减少各种资源的消耗来达到帮助用户省钱的目的，那么是不是说在这样的情况下就会牺牲应用的性能？

Zion以本文开始的案例为例，截取了活动最火爆的第一天的请求响应情况。可以看到峰值每小时独立用户数54,199，峰值每小时api请求数464,262，响应时间超过1s的请求数为53，换句话说就是99.99%的请求的响应时间在1秒以内，平均响应时间13毫秒。Zion用实际案例证明了，在减少资源的消耗的同时，Zion也带来了超高的用户体验，这样的情况在用户量超大或者数据量超大的情况下会显的更为明显。

亿级数据搜索能力

搜索是一个再常见不过的需求了，尤其是在19年-22年的疫情中，由于需要流动调查而对搜索速度提出了极高的要求。比如当一个人检测出了核酸阳性，就需要搜索出曾经在哪些场所和他扫码前后相邻10分钟的人，这就需要应用具备在万行数据甚至亿行数据级别的表中进行快速的搜索。而这也正是Zion十分擅长的部分。

Zion以一个用他们自身做出的驾校考试应用为例，截止目前其数据库的题库中共有93万道题目，2万多用户，累计答题次数已经达到了6555万次。可以想象这是一个高频在百万级题库中不停搜索的应用，那来看一下在这样的场景下Zion的实际表现。

以下统计中的第2行，是一个跨多个千万级别表的请求记录，可以看到截止目前这个应该已经请求了2147万余次，且平均每次的请求时间只用了46毫秒（ms_per_call表示平均每次请求用时，单位毫秒）。换句话说，做为一个使用者，数据表中是几十条数据还是上亿条数据，使用时你是完全不会有感觉的，而这也正常Zion在搜索上为开发者和使用者带来的巨大价值和体验优化。

大的思路可以借鉴，别人的方案也可以参考，但是真正落地过程中，细节上还会有无数的坑。另外，由于软硬件环境、技术栈、以及产品逻辑都没法做到完全一致，这些都会导致同样的业务场景，就算用相同的技术方案也会面临不同的问题，这些坑还得一个个趟。