18个月构建Zilliz Cloud，公有云构建Serverless向量检索服务获得的一些教训

1、致谢

首先，我要感谢我们的忠实用户，正是他们让这一切成为可能。感谢你们一直以来的鼓励，支持我们撰写Zilliz Cloud背后的故事，这对其他正在构建云服务的朋友们可能有所帮助。我还要感谢Milvus社区的300多名贡献者的不懈努力，以及我们的CEO Charles，他总是支持我们尝试一些技术上天马行空的想法。 对于那些对使用向量检索服务感兴趣的读者，欢迎立即注册Zilliz Cloud，以获取100美元的免费额度。

2、引言

向量数据库可能是2023年数据库行业最热门的话题之一。在这篇文章中，我将分享我们如何在十八个月内从零开始，构建了基于全球最流行的开源向量数据库Milvus的云托管服务——Zilliz Cloud。在这十八个月里，我们不仅完成了从无到有构建一个完整云服务的历程，还经历了由于LLM爆火而带来的流量增长十倍的挑战。本文是一篇回顾性文章，旨在分享我们在这一过程中所做的设计决策和学到的宝贵经验。

Zilliz Cloud Dedicated Cluster- 旅程的开始

时间拨回到2022年5月，开源向量数据库Milvus 2.0版本经过几个主要版本的迭代，终于开始逐渐稳定下来。在与用户的交谈中，一个稳定的商业托管版本成了频繁提及的需求。作为Milvus背后的商业实体Zilliz，这似乎是开始商业化的好时机——我们拥有一支经验丰富的工程师团队、一个日渐成熟的产品，以及一群有迫切需求的忠实用户。我们决定设定一个雄心勃勃的目标：用六个月的时间推出我们的产品。

在项目启动前，我们首先梳理了当前的状况和目标:

我们已经具备了一个符合云原生的开源向量数据库，存储计算分离，微服务化，可以很容易的将这个架构部署到K8s集群内

架构.webp Milvus 架构

基于Kubernetes Operator，我们能够快速在公有云上部署服务，已经支持了一些用户在AWS和GCP上部署他们的生产服务。 我们具备了基础的可观测性能力，如监控和日志，但缺乏线上服务必需的报警功能。 除了上述内容，作为一个服务，我们还缺少很多要素，包括但不限于用户登录认证、计量计费、付费、网络、安全、Web控制台、OpenAPI、资源调度、工作流等等。

在六个月内完成这些模块看似是不可能完成的任务。我仔细列举了所有需要的模块，这个念头在我心中更加坚定。我不得不自问：我能利用哪些资源？能否通过简化工作来实现一个基本可用的版本？在这一思考过程中，我们形成了以下设计理念：

1、尽可能使用成熟的第三方产品，避免重复造轮子。

为了加快产品上市的步伐，我们决定尽可能地选择云服务和第三方服务作为依赖。

在构建基础组件方面，我们依赖了AWS的核心服务，包括EKS、EC2、S3、EBS和ALB等。同时，我们还使用了AWS管理的Kafka服务和RDS。在实践中，我们发现这些组件可以在后续实现多云支持时以较低的成本进行替换，从而极大地加速了我们构建多云支持的进程。由于GCP和Azure提供的消息队列组件与开源Kafka存在一些兼容性问题，因此我们最终决定基于Apache Bookkeeper重新实现了我们的分布式日志系统。令人惊讶的是，尽管分布式日志在云数据库中至关重要，但目前却没有成熟的开源或云解决方案可供选择。因此，我们正在考虑开源我们的分布式日志方案，以填补这一空白。

第三方SaaS公司在构建我们的加速平台方面发挥了关键作用。例如，在支付系统方面，我们选择了直接集成Stripe，尽管即使有了Stripe的接入，仍需处理大量的计量和税务工作。我们引入了http://Sugar.io，以对接多云的Marketplace。最近，我们开始考虑使用像Orb和Metronome这样的账单服务平台。在账户和登录方面，我们选择了Auth0，并随后增加了对谷歌登录的支持。我们的完整运维报警系统基于Pagerduty构建，因为它能够最快速地与我们的监控工具集成，并提供了灵活的通知规则定制能力。

2. 如无必要，勿增实体

根据奥卡姆剃刀原则，我们应该追求问题的简化而非复杂化。这一简约设计理念应当在产品的各个方面得以体现，具体包括以下几个方面：

技术的简约性：

在微服务化大行其道的背景下，我们最初的设计计划包括了60多个微服务。然而，这给开发和测试的协同带来了巨大挑战。为了简化架构，我们经过多次讨论后，最终的第一版产品仅包含不到10个核心微服务，如用户、账单、计费、CloudService、资源、元数据、调度等。这种简化使微服务之间的依赖关系更加清晰，同时也降低了测试成本。

功能的简约性：

第一版云平台的上线目标聚焦于最关键的用户操作路径，如注册、集群创建、计费、数据访问和用户反馈。为了保持产品的简约性，我们放弃了一些在关键链路上不那么重要的功能，比如规模扩展和数据备份。这样做大大减轻了我们的工作量。特别值得一提的是，我们将用户反馈路径列为必须实现的功能之一，第一版就支持了邮件反馈。后来，引入Zendesk工单系统后，我们获得了更多及时高质量的反馈。因此，我强烈建议在产品设计的早期阶段就提供有效的反馈途径。

设计的简约性：

云服务的设计应注重高效传达信息，吸引潜在用户的注意力。这要求产品设计需要足够克制，突出重点。当我们对某个功能是否真正符合用户需求存在不确定性时，可以通过快速灰度测试来验证，然后根据用户使用情况进行迅速调整。

3. 从Day 1开始思考Day2的问题

在云服务领域，敏捷开发与稳定可靠同样重要。为了能够实现在飞行中更换引擎的目标，我们必须在产品设计阶段留足够的扩展空间，以支持后续的迭代。

多云支持：

Zilliz云服务的目标是提供跨云和跨区域的服务。尽管最初只选择支持AWS，但在产品选择阶段，我们严格秉承云中立原则，对所有云服务提供商进行了深入研究，包括GCP、Azure和阿里云，以确保它们都具备提供类似服务的能力。此外，我们基于开源的Crossplane进行了大量改造，创建了一层名为“云代理”的基础设施层，这显著降低了实现多云支持的成本。

安全性：

尽管在某些AIGC用户看来，安全可能不是首要考虑因素，但我们从一开始就将数据安全视为首要任务。Zilliz云服务自第一天起严格按照云IAM标准控制所有数据访问权限，并对所有持久化数据和传输层数据进行加密。考虑到Zilliz云的多租户特性，我们也特别关注高性能网络隔离。在多种方案的尝试后，我们最终选择了云厂商提供的EKS网络增强组件，它在所有测试结果中表现最高效。此外，我们从设计之初就明确划定了数据层和控制层的交互界限，从而显著降低了我们推出BYOC产品的开发成本。

池化接口：

Zilliz云服务的一个重要设计理念是云的交换律，即完成的工作量=工作时长x单位机器性能x机器数量。相较于过去系统的设计重点在于优化单个机器的性能，Zilliz云更注重存储和计算的分离、负载均衡等基础能力。我们将微服务的边界明确定义，并逐步将日志服务、索引服务、元信息服务等替换为独立的池化服务，从而充分利用云资源的无限扩展特性来降低单个任务的工作时长。

运维友好：

与许多在AI热潮中兴起的向量数据库不同，Zilliz Cloud不仅针对开发者，更为运维人员设计。我们提供丰富的可视化界面、监控和日志报警服务，并持续努力提高服务的可用性和可管理性。Zilliz Cloud具备三AZ容灾能力和严格的SLA保证，有助于用户更快速地将业务落地生产环境。

在这些设计理念的加持下，我们在六个月的时间内发布了我们的商业版向量检索，也获取了我们第一批种子客户，以下是我们第一版的架构图。其中，虚线部分是第一期是有规划但还没有实现的组件。

云 架构.webp Zilliz Cloud 架构

Serverless - 从300美金到5美金的新用户成本

增长往往在意料之外的时刻发生。在经历了SaaS服务三个月稳定增长后，大模型应用和Zilliz Cloud增长随着AutoGPT的爆红达到了高峰。将向量数据库视为大模型长期记忆的观念逐渐被接受，Zilliz的用户数也因此迅速增长，日新增集群数量快速达到数百。

然而，业务增长也带来了两个主要挑战：稳定性和成本。尽管我们一直关注可扩展性，但突然到来的高流量峰值几乎使我们的所有服务陷入瘫痪，唯独核心数据库幸免于难。云服务提供商的扩容API受到了限流，我们的日志存储系统Loki在短短几天内两次被写满，导致许多服务因资源不足而被迫中断。

另一方面，最初采用的Zilliz Cloud免费试用策略，即向新注册用户赠送300 Credit以体验所有功能，随着用户数量的激增（其中大多数用户只是尝鲜），导致了我们的成本急剧上升，迫使我们重新审视商业模式。正是这两个痛点促使我们推出了Zilliz Cloud Serverless，这是一款更加灵活、门槛更低、更适合AIGC用户的产品。

面向RAG应用 - The holy grail is still out there

三要素.webp 向量检索三要素

对于RAG（Retrieval-Augmented Generation）系统，理想的解决方案需要着重考虑几个关键因素：

扩展性 - 这包括两个层面：

对于单个租户而言，需要能够扩展处理其数据。这意味着系统应能适应不同租户的数据量变化，无论是小规模还是大规模的数据处理。 在处理大量租户时，系统应能够有效支持百万级别的租户数量。这需要强大的数据管理和处理能力，以保证系统的稳定性和可靠性。 成本 - 对于单个知识库的成本控制至关重要。理想情况下，每个知识库的成本应该控制在1美元以下，而当前基于内存实现的向量索引，100万768维数据的成本甚至高于10美元。这个成本对于构建企业服务场景的SaaS公司而言是可以接受的，但对于ToC的消费级应用而言明显过高了

低延迟 - 尽管RAG场景对延迟的敏感性可能不及搜索和推荐领域，但向量检索的性能对于“Time-to-first-token”（即从请求开始到返回首个结果所需的时间）有显著影响。因此，保持低延迟是提升用户体验和系统响应速度的关键。

在这些挑战中，Zilliz Cloud 最初提供的解决方案在大数据量的扩展性和低延迟方面表现出色，超过了用户需求。然而，在处理众多租户和控制成本方面，SaaS方案未能完全满足用户需求。为此，我们设计了“Zilliz Serverless Tier”，这是一种旨在降低单个AIGC用户的门槛的服务模型。它提供了最具成本效益的存储选项和扩展能力，以满足上述挑战。

Serverless的整体架构

serverless架构.webp Zilliz Serverless架构

Zilliz Cloud Serverless引入了逻辑集群的概念，其中每个逻辑集群实际上对应一个物理集群中的数据库。我们通过数据库和基于API密钥的认证机制，在单个物理集群中为所有租户实现了逻辑隔离。在查询时，系统会根据API密钥确定用户需要访问的数据，并通过代理节点进行路由。

用户的数据写入操作首先发送到一组池化的日志节点，然后这些日志节点将数据写入WAL服务，并定期将数据整理到云对象存储中。CompactionService是一个池化服务，负责合并小文件和小段数据，而索引服务（Index Service）则负责为数据构建索引，然后由查询节点（Query Node）加载，以确保查询效率。

在查询阶段，为了提高效率，我们选择将所有数据加载到Query Node的本地磁盘，并在本地进行内存与磁盘的交换，从而使Serverless用户的存储成本比使用内存索引低10倍以上。然而，由于每个Query Node节点需要加载多个租户的数据，因此最大的挑战之一是在高效利用资源的同时，避免因租户热点问题而导致查询过载。

为了提高系统的稳定性，我们引入了以下三个重要机制：

分布式配额（Quota）系统：该系统基于一个集中式配额服务，动态分配资源配额，并根据查询节点的负载情况进行动态调整。这有助于确保每个租户的资源消耗合理。

基于负载监控的动态资源伸缩：引入了云资源调度器（Cloud Resource Scheduler）模块，它全面管理内存、磁盘、CPU负载以及请求排队情况，实现了物理资源的动态伸缩，以应对不同情况下的资源需求。

多级调度：我们实施了不同层次的资源调度，包括基于资源组的物理隔离、资源组内的负载均衡，以及单个节点上的查询和缓存调度，以确保多租户之间能够公平共享资源，避免任何单个租户过度占用资源。

通过Serverless服务，我们成功将单个用户的试用成本降低至5美金，并支持了数以万计的AIGC开发者。在即将推出的Zilliz Cloud新版本中，我们进一步提供了成本更低、更具弹性的Serverless解决方案。在这个新版本中，每个Serverless用户能够在一张表中处理数百万用户的数据，实现数据隔离，同时存储成本相比当前方案将降低十倍。我们也将在后续的文章中继续深入讨论Zilliz Cloud Serverless的技术细节，敬请期待。

3、基于开源软件打造云服务的六大经验

1、即便是云原生系统，转型为云SaaS服务依旧充满挑战：

将云原生数据库像Milvus这样转型为云SaaS服务远非易事。重点不仅仅是部署在EC2和EBS上那么简单。在开源数据库领域，用户需要深入掌握产品细节，才能通过KnobTuning实现水平扩展、故障恢复和性能优化。对于云服务而言，真正的挑战在于简化操作，同时提供高可靠性和弹性。我们必须考虑云环境的特定限制，比如S3的限流、Bucket数量限制和OpenAPI调用频率限制等，这样才能真正利用云计算的弹性和扩展能力。

2、克制的推出功能：

在产品早期阶段，继续构建新功能以吸引客户看似有吸引力，但实际上，聚焦于用户真正的痛点更为关键。我们发现，开源产品功能集合领先SaaS版本大约六个月是一个不错的折中选择，确保这些功能在提供服务之前已经经过充分的测试和改进。

3、设置恰当的限制以提升产品价值：

没有任何一个产品是完美的。以S3为例，尽管其接口简洁、经过长时间打磨，但依旧只有在合适的场景下才能最大化其价值。与开源产品的自由度不同，SaaS产品需要设置更为严格的限制来保护自身。这些限制不仅是产品的一部分，也是对用户的一种引导和教育。合理的限制能够指导用户更加聪明地使用产品，从而提高其整体价值和用户体验。

4、优选云中立依赖服务以简化流程和降低成本：

考虑云中立的依赖服务，如S3、EC2和K8s托管服务，这些在各大云平台上普遍存在的基础设施，可以显著降低多云适配的成本和复杂性。从项目开始就考虑跨云兼容性和简化将开源用户迁移到云的过程至关重要。尽管不同云服务商之间在实现上存在差异，但通过早期构建多云接口层，可以有效减少重复开发工作，提高整体效率。

5、关注Cloud FinOps以优化成本：

在云环境中，一些看似成本低廉的资源可能变得异常昂贵。例如，在我们没有进行云账单分析之前，从没考虑过ALB网络带宽的成本可能占据整体成本的关键部分。为了成本优化，除了最大化榨干性能优化空间外，深入研究云服务商提供的机型和服务限制也非常重要。例如，每块GP3云盘提供的3000 IOPs，通过在一台机器上绑定多块云盘并配置RAID，可以大幅提升磁盘的吞吐量，避免了为额外的Iops付出巨额的账单。

6、Open API的日益增加的重要性：

随着Agent使用的日益普及，Open API和相关文档的作用变得更为重要。传统云服务依靠Web控制台和用户界面来交付功能，但未来云服务的交互和集成将越来越依赖于OpenAPI。服务的自动化程度，Agent友好性和可观测性成为了未来云服务的重要评价指标。

4、尾声

回首过去的18个月，我们经历了一段异常精彩且充满挑战的旅程，时间仿佛被加速了三倍。这种快速的进展得益于几个关键因素：首先，大型语言模型（LLM）极大地提高了我们的编码效率；其次，用户对于大型模型的价值认识迅速达成一致，这也是我们新增用户的主要场景；最后，我们必须感谢那些我们所依赖的开源产品、SaaS工具和云服务提供商，他们提供的高效稳定服务对我们至关重要。我们特别要向Zilliz Cloud和Milvus的忠实用户致以崇高的敬意，正是你们细致而耐心的反馈，为我们提供了无价的建议和指导。无论是在SaaS、Serverless还是BYOC领域，我们坚信所做的一切都仅仅是一个开始，对成本，性能，扩展性和易用性的追求是没有止境的。如果你对向量数据库Zilliz Cloud感兴趣，请立即开始使用，如果您对我们的向量检索服务有任何疑问，欢迎查看我们的定价页面或直接联系我们。