一、引言

大部分人使用 AI，大概都跟我一样，停留在初级阶段。

平时，就是向 AI 提问（又称聊天），偶尔也用一些现成的服务：生成图片、生成代码、翻译文章等等。但是，时间久了，就觉得不够用，很多个性化需求，根本找不到工具，需要自己想办法。

我想，这是很多人面临的问题：如果深入使用 AI，就必须自己做开发。

今天，我就介绍一种 AI 开发的简单方法，没有那么高的门槛，普通人也可以上手。

二、AI 开发的三种模式

按照从难到易，我把 AI 开发分成三种模式。

（1）自建模型：自己搭建 AI 模型，并寻找数据进行训练。

这种模式难度高，成本大，必须是 AI 专业人士或大公司，才会使用。

（2）API 调用：自己编写脚本，去调用他人运行的模型 API。

这种模式要求使用者必须会编程，优点是适应性强，什么需求都能编程解决，缺点是编写和调试脚本要花不少时间，还要自己部署服务端。

（3）工作流模式：采用 AI 服务商提供的工作流（workflow），编排每个步骤，形成自动化操作。

这种模式最简单，不懂编程的人也能上手，可以不编写脚本，有现成的服务端，省时省事。缺点是受限于 AI 服务商提供的能力，对方不提供，就做不了。

我是 AI 新手，就选择了最后这种模式，尝试 AI 开发。

三、GPT 商店和 Copilot 模板

很多 AI 大厂都提供"工作流模式"，允许开发者在他们的模型上，定制自己的应用。

最有名的大概就是 OpenAI 公司的 GPT 商店。

它开放 ChatGPT 的底层能力，让开发者定制某个领域的专用 GPT，比如学术论文的 GPT、处理 Excel 文件的 GPT 等等。

微软的 Copilot 也有类似的功能，叫做"模板"（template）。

不过，这些都是国外的服务，需要收费，服务器在境外。好在国内有免费的替代品，我就选择了国内产品。

四、工作流演示

我先演示一下，工作流的操作界面。大家就能明白，它是怎么回事了。

工作流其实就是把一个 AI 应用，分成若干个步骤。每个步骤是一个节点，你在上面设置这一步的操作，然后所有节点按照流程，完成任务。

上图是扣子 AI（coze.cn）的工作流编排界面，包含四个节点。

扣子是字节跳动旗下、免费的 AI 应用开发平台。使用过程非常直观，就是在网页画布上，通过图形化操作，一步步创建 AI 应用。我就用它来演示。

它的开发页面左侧是不同类型的节点，下图是其中一部分。

新建节点时，点击对应类型就可以了。一般来说，第一步总是新建"模型节点"或"插件节点"。

新建模型节点后，如果你想用自己的数据训练模型，可以在项目管理页面上，新建一个知识库，上传数据文件。然后在工作流里面，创建一个"知识库节点"。

如果你想启用持久记忆能力，记住用户的历史对话，那么可以新建数据库，保存用户数据，然后在工作流创建"数据库节点"。

所有节点设置完毕，这个 AI 应用就可以运行了。最后一步，就是发布该应用。

扣子会让你选择发布渠道（上图），目前支持发布到商店（在扣子平台使用）、第三方平台（在飞书、抖音、微信使用），以及 API 和 SDK（在用户自己的软件使用）。

以上就是工作流模式的使用界面，只是一个简单介绍，大家有一个大概的理解就可以了，具体操作可以看文档。

它还是很容易上手的，熟练以后，开发一个 AI 应用，一两个小时就可以搞定。

五、工作流开发的例子

为了加深理解，我举一个实际开发的例子。某餐饮企业想要搭建一个 AI 应用，用来分析用户的点评。

为此新建一个工作流，基本功能只需要三个节点----输入节点、分析用户点评的 AI 模型节点、输出节点。

然后，把这个工作流发布成 API。用户的点评传入这个 API，它就会返回一段 JSON 数据，里面有 AI 模型识别出的用户评价（正面、负面、中性），以及点评关键词（环境/服务/菜品）。

上图是这个工作流的预览调试界面，输入了一段真实的点评，运行结果以 JSON 格式返回。

可以看到，AI 识别出该用户对产品是中评，对环境是差评，对上菜速度是好评。

六、模板功能

工作流除了自己使用，还可以保存成模板（template），发布到模板商店，让别人使用和借鉴。

在模板商店，你可以看到官方和其他用户搭建好的工作流，目前已经有上千个，还在快速增长。

这些工作流可以直接使用，也可以作为模板复制。用户复制模板后，对它们进行学习和修改，将其改造为适合自己的应用。

对于模板作者来说，可以对模板设置价格，实现变现。

很多模板提供非常有意思的功能，值得一看。比如，"抖音转小红书"的模板。

你输入一个抖音的短视频链接，AI 自动生成10个可用标题和一段文案，你可以把它们连同视频一起发到小红书。

七、教程：情感故事爆文专家

网上已经有不少工作流模板的开发教程，大家可以去搜一下。

我看到一篇"情感故事爆文专家"的模板教程，非常有趣。情感类的网文现在流量很好，作者就开发了一个 AI 应用，专门生成这类文章。

先看成品，点击这个模板链接，体验一下它的效果。你输入一个文章主题，比如

一对情侣在大学里认识，毕业后分手，10年后再次相遇。

这个 AI 应用会输出文章的大纲和正文。

还带有配图，可以直接发布。

它背后的工作流，大致分成六个节点。

1. 开始节点：接收用户输入的文章主题
2. AI 模型节点：通过 AI 模型，根据文章主题，生成文章的大纲。
3. 扩写节点：根据文章大纲，进行内容扩写，生成正文。
4. 内容总结节点：根据正文，生成文章的内容总结。
5. 文生图节点：根据内容总结，生成文章配图。
6. 结束节点：汇总所有内容，输出结果。

设置完成后，点击"发布"按钮，这个 AI 应用就可以直接使用了。

八、结束语

工作流模式相比自己从头写，容易和快捷很多，服务端也一起解决了。如果你有 AI 开发的需求，可以试试这种模式。

下一步不妨就从文档开始，做出你的第一个工作流节点，发布到模板商店。

任何开发问题（估计肯定会遇到），可以加入官方咨询群去问，下面是微信群二维码。

我遇到问题，就咨询扣子的同学。他们告诉我，现在正好有两个活动，有大量的奖品，建议我参加。

我看了觉得很不错，下面把活动信息转发出来。如果你正好做了模板，就不要错过。

（1）模板比赛

工作流开发完成后，上架到模板商店，现在可以获取奖励。

你可以对模板设置价格（官方审核通过后），实现模板变现，他人复制模板需要付费。在活动期间，官方根据模板复制的数量，会发放1000元到10000元的奖金，以及随机抽取的50个无线充电器的纪念奖。

（2）万圣节抽奖

官方现在有一个万圣节抽奖，在那里上传你的照片，会得到一张万圣节主题照，以及一次抽奖机会。

抽奖的奖品有 iPhone 16 Pro Max、Switch、咖啡机。

（完）

一、引言

上周，我参加了腾讯全球数字生态大会。

今天，就跟大家分享，我的一点收获，就是理解了多集群工具。

软件开发的同学，应该都听说过 Kubernetes 吧。它是一个容器管理工具，本身很复杂。

可想而知，同时管理多个 Kubernetes 集群的工具，一定更复杂。但是，我这次发现，多集群其实很好理解。

当时，大会有一个演讲，关于腾讯的一个新服务，跟多集群管理有关，叫做 TKE AppFabric，讲得很浅显，我一下就听懂了。

下面，我尽量用最简单的语言，解释什么是 Kubernetes，什么是多集群工具，什么是最简单的使用方法。

二、从 Docker 讲起

为了理解 Kubernetes，需要从 Docker 讲起。

2013年，Docker 诞生，创造性地将软件应用的运行环境与源代码打包在一起，做成一个容器镜像（image）。

容器镜像本身是一个二进制文件，可以直接发布。其他机器只要安装了 Docker，就能运行这个文件。它能让软件运行在一个虚拟环境（称为"容器"）里面，从而保证运行环境和开发环境一致，避免了环境配置、启动报错等等麻烦事。

更重要的是，容器镜像是一个标准化文件，不管软件使用什么语言开发，最后做成容器，都是一个格式。因此，就可以用一个工具去处理所有容器项目的发布，完全忽略开发语言的差异。

正是因为 Docker 提供了标准化、一站式的软件运行流程，才为后来通用的"容器应用管理工具"铺平了道路。

现在，Docker 已经成为软件部署的标准。不管软件是以源码发布，还是以容器镜像发布，最后都部署运行在 Docker 里面。

三、微服务架构

Docker 出现后，大大简化了软件部署，变成只需运行容器镜像。很自然地，开发者就开始考虑，能不能把单体的巨型软件，拆分成为多个组件（即多个容器）部署？

早期的企业级大型应用，通常都是一个巨大的单体软件（monolithic），包含不同功能的多个组件。哪怕只修改一个组件，也需要把整个软件重新部署一次。

现在的实践则是，把较大的功能组件拆分出来，每一个组件都是一个独立的服务，作为一个 Docker 容器单独发布和部署。

于是，单体软件就变成了多个 Docker 容器组成的软件系统，这就是现在流行的"微服务架构"（microservices）。软件包含多个微服务，每个微服务对应一个 Docker 容器。

四、容器管理工具 Kubernetes

微服务意味着，每次发布都涉及大量不同的容器，管理它们就成了一种挑战。容器管理工具就应运而生。

各种容器管理工具之中，名气最大的非 Kubernetes 莫属。

它是谷歌开发的一款开源软件，因为词首K和词尾s之间有8个字符，所以常常写成 K8s。它已经成为事实上的容器管理标准。

具体来说，它主要有以下功能。

（1）统一的硬件接口。开发者不必关注底层的硬件细节，不管底层服务器有什么差异，都被抽象成统一的操作接口。

（2）自动扩展。它可以根据软件负载情况，快速完成水平扩展。

（3）高可用。当某个容器失败时，它会自动重启或替换掉该容器，保证流量流向可用的节点。如果软件发布出现问题，还能自动回滚。

（4）其他功能。它还具有服务发现、负载均衡、资源监控等大量相关功能，同时带有庞大的插件和扩展，以及活跃的社区。

五、多集群是什么？

Kubernetes 的底层就是一组服务器，上面运行着许多容器。每个 Kubernetes 实例，就被称为一个集群（cluster）。

普通的软件应用，只要一个集群就够了。但是，出于下面提到的原因，企业级应用往往需要部署在多个集群。

多集群（multi cluster）可以在同一个机房，也可以在不同机房。实际应用中往往是后者，即分布在不同机房，这时如果集群来自不同的云服务商，或者是不同性质的云，就称为"多云"（multicloud）。

多集群的主要考虑如下。

（1）容灾。如果一个集群出问题，那么还有另一个集群，可以保证可用。

（2）隔离。集群之间可以做到非常强的物理隔离，从而实现上层用户（租户）的隔离。

（3）灵活性。多云有助于减少供应商锁定，可以根据需求选择最合适的基础设施和服务。

（4）合规性。不同地区可能有不同的监管要求，多集群可以为每个集群实施更精细的安全策略和访问控制。

六、多集群的挑战

多集群虽然有上一节的好处，但是复杂性也随之加倍，为使用者带来了许多挑战。

（1）配置和管理复杂性。所有集群需要一致的配置和部署，尽量消除差异。

（2）网络连接和延迟。如何保证不同地理位置的集群，有安全可靠的连接，同时最大限度地减少延迟。

（3）服务发现和负载均衡。某个服务如何发现不同集群中的其他服务，以及如何让不同集群负载均衡。

（4）监控。所有集群的指标和日志，最好汇集在一起，便于集中式监控。

（5）安全和访问控制。多集群的安全策略、访问控制、凭证管理都变得更加复杂，需要仔细规则和逐一设置。

七、多集群工具及其问题

为了解决上面的挑战，就诞生了专门的多集群管理工具，比如 Argo CD、Rancher Fleet、Karmada 等。

它们可以看作是开发者与 Kubernetes 之间的中间层，解决集群管理的复杂性。

问题是，要使用它们，必须先学会 Kubernetes，再去学习这些工具本身。这是巨大的学习成本，所以多集群工具不是针对应用开发者，而是针对集群管理员。

现实中，多集群是高度专业的领域，其他领域的开发者根本看不懂。开发者完成软件开发后，会把应用交给集群管理员，让后者去部署。

这对双方都很麻烦。一方面，开发者不能决定部署策略，也不了解底层资源，许多情况下可能不得不接触容器管理。另一方面，集群管理员会被迫介入应用层，一旦发生底层资源的调整，还需要通知开发者，让其参与进来保证应用的运行。

八、面向应用的多集群助手 TKE AppFabric

怎样才能让开发者更简单地使用多集群呢？

腾讯云的解决方案，就是增加一个面向应用的中间层，把多集群工具这一层隐藏，降低使用门槛，这种服务就起名为 TKE AppFabric。

它的名字中，TKE 指的是"腾讯云容器服务"（Tencent Kubernetes Engine），AppFabric 指的是把应用容器像织物一样编织在一起。

它面向应用开发者，定位就是"向上服务好应用，向下管理好集群"，可以看作是应用的多集群助手。

由于封装了多集群工具这一层，所以它没有复杂的专业术语，特别好懂，开发者能够快速理解和上手，不用关心底层资源，甚至不需要知道"集群"这个概念。

它的简单性，体现在下面几个方面。

首先，它使用开发者更容易理解的"可用区"（availability zone）。应用部署时，你只需要指定在哪几个区（比如广州1区、上海1区），也就是部署位置，就可以了。

整个过程都面向应用，跟 Kubernetes 解耦。这一方面，有利于开发者将更多精力放在业务上面，另一方面使得云服务商可以充分调配资源，提高资源利用率。同时，集群的升级和维护，上层用户也是无感的。

其次，它简化了设置，采用声明式设置，只需要写好声明文件即可，进一步降低了学习成本。

再次，它封装了 Kubernetes 跟应用运行相关的一些功能，让其更易用，各种监控指标和日志也汇集在一个地方，更容易发现。

九、多集群案例：腾讯健康

腾讯健康就架设在 TKE AppFabric 之上，我们通过它，来看看怎么使用多集群架设大型服务。

下图就是腾讯健康的后台架构。

上图中，网关（gateway）是访问入口，下面同时部署了三个可用区：zone1，zone2 和 zone3。它们部署在不同的机房。

这三个可用区是一模一样的，每个区都部署一个系统实例。每个系统实例包含三个层层依赖的应用：app1 依赖于 app2，app2 依赖 app3。这三个应用本身，每一个都是容器组（app pods）。

这样的架构有三个好处，可以保证高可用和负载均衡。

（1）容灾部署。如果一个可用区出现故障，可以切换到另一个可用区（比如 zone1 的 app2 出现故障，可以切换到 zone2 的 app2），保证可用。

（2）路由控制。自动为用户分配就近的可用区，提高访问速度。

（3）灰度发布。新功能可以先在单个可用区进行灰度验证，完成之后再全可用区发布，降低发布风险。

根据现场演讲，所有腾讯内部资源上云的业务，比如 QQ、腾讯会议、音视频业务都会部署在 TKE AppFabric 上面。今年第四季度，它就会对外试运行，明年一季度正式对外开放。

十、总结

对于采用"微服务架构"的企业级应用，如果业务比较重要，需要高可用，那么多个 Kubernetes 集群几乎是必然的选择。

如果公司有专门的团队，你可以选择自己来做多集群管理，否则可以考虑云服务商的工具。

我相信，越来越多的云服务商，以后可能会同时提供两套工具：一套是原始的多集群工具，专门供高级用户使用，另一套就是 TKE AppFabric 那样的面向应用、隐藏多集群细节的助手工具，供普通开发者使用。

对多集群或者 TKE AppFabric 感兴趣的同学，可以微信扫描下面的二维码，查看产品手册。

（完）

一、引言

AI 怎么用于编程？

目前有各种尝试，最激进的大概是 Vercel 公司的 v0.dev。

你告诉它，想要什么网站，它就给你几张设计图。你选一张，它就生成写好的网页。

这很有未来感，想要什么程序，机器帮你写。但是实际上，它只能生成网页 UI（用户界面），无法生成互动脚本，并且其他的 UI（比如手机 App 页面），它都无法生成。

这反映了 AI 的局限，至少现阶段，AI 无法取代程序员，只能充当编程助手。

根据我的使用体会，作为编程助手，AI 的作用非常大，能够大大节约程序员的时间，显著提高编程效率和代码质量。

今天，我就来测评两款 AI 编程助手，看看孰强孰弱，顺便也作为一个入门教程，向还没用过的同学，展示它们的用法。

大家看了以后，就能明白，为什么编程已经离不开 AI 了，它真的能让程序员如虎添翼。

二、GitHub Copilot 和豆包 MarsCode 简介

我要测评（或者说介绍）的两款 AI 编程助手，分别是 GitHub Copilot 和豆包 MarsCode。

GitHub Copilot 是最早出现的 AI 编程助手，也是市场占有率和知名度最高的一个。

它是微软出品，底层是 OpenAI，又依托着世界最大的程序员社区，自然是实力非凡。

豆包 MarsCode 是基于豆包大模型打造的智能开发工具。

它的背后是字节跳动，本来是内部工具，据说字节超过70%的工程师都在用，每月贡献百万行量级的代码。

6月26日，它正式在北京对外发布，外界可以免费使用，属于新鲜出炉。

它们都来自大厂，有足够的代表性，而且功能相近，下面就来看看，国产 AI 能否替代国外主流产品。

三、使用环境

AI 编程助手一般不单独使用，而是作为 IDE（集成开发环境）的插件，在编辑器界面提供各种 AI 功能。

我选择的 IDE 是目前最流行的 VS Code。此外，豆包 MarsCode 还支持 Jetbrains IDE，Copilot 则支持更多。

大家在 VS Code 插件市场搜索 Copilot 和 MarsCode，就能找到它们。下面是安装后的页面。（上图为 Copilot，下图为豆包 MarsCode，后面都是这个顺序。）

如果你没有 VS Code，甚至也没有其他 IDE，问题也不大。豆包 MarsCode 提供免费的云 IDE（下图），无需下载和安装，直接在浏览器使用，并且内置数十款开发模板，还可以拉取 GitHub 仓库，用起来很方便。

GitHub 也有云 IDE，就是它的 CodeSpace，里面也能用 Copilot。不过，每月使用60小时之后，就要收费，这里就不推荐了。

四、聊天功能

AI 编程助手的主要用户界面，就是一个聊天窗口，用户向它提出各种问题。

我首先问了一个问题"什么是 CAP 定理？"，测一下它们的聊天功能。

可以看到，它们的回答都是准确的、可用的，Copilot 的格式编排稍微好一点。

第二个问题"请推荐学习 JavaScript 的书籍"，两者的回答差不多。

聊天的问题不限于编程，什么样的问题都可以问，比如"2025年春节是什么时候"，它们的回答也没问题。

不过，这个功能的日常使用场景，应该是查找软件文档，真的好用。

五、代码生成

接下来，就来测 AI 编程助手的最主要功能：自动代码生成，让它来写代码。

使用很简单，只要有按键输入，它就会自动建议后面的代码是什么。

你可以将其当作参考，也可以按下 Tab 键，接受它为正式代码。如果想逐个单词确认，按下 Ctrl + 右箭头（Mac 为 Cmd + 右箭头）。

我让 AI 生成一个检验电话号码的函数。

上面的代码，除了第一行"// 验证电话号码"是我输入的，后面都是 AI 生成的。

这段代码完全正确，并且还有两个地方令人很满意。（1）因为文件的后缀名是 JS，所以它们自动生成的是 JavaScript 代码；（2）它们验证的是中国的手机号码，而我并没有明确给出这一点，它们是自己推断的。

有点奇怪的是，Copilot 和豆包 MarsCode 给出的代码是一样的。莫非它们使用同样的材料训练？

我又加了一个条件，要求包括手机和座机两种情况。它们给出的代码还是（基本）一样。

这个环节，它们打平。另外，如果对给出的实现不满意，Copilot 可以按下 Ctrl + Enter，会有多种实现供选择（下图）。

豆包 MarsCode 则是在代码建议时，有一个浮动工具栏，可以切换多种实现（下图的箭头）。

值得一提的是，豆包 MarsCode 还有一个特色功能"代码补全 Pro"，不需要手动给出提示，根据现有代码，自动预测下一个改动点，并给出推荐代码。

这个功能需要自己在设置里面打开（下图）。

打开以后，它就会加强代码预测。首先，在期望触发代码推荐的地方，按下 Ctrl + Shift + Enter 主动触发推荐，然后你按下 Tab 采纳。

这时，它会预测下一个改动点，点击 Tab 就可以跳转到那里。这在代码修改的场景中非常有用，修改了一个地方，它帮你跳到下一个（预测的）改动点，并给出推荐代码。普通的代码补全做不到这一点。

六、生成注释，代码解释

除了生成代码，AI 的另一个重要作用，就是生成编程文档，也就是代码的文字说明。

文档功能主要有两种：注释和代码解释。首先，Copilot 的注释需要自己手动生成。

豆包 MarsCode 则在代码上方有生成注释的快捷按钮。

点击后会唤起/doc命令，用起来相对方便一点。

至于代码解释功能，我觉得相比之下，豆包 MarsCode 更好一些，Copilot 太冗长了，有点不易读。

七、其他功能

（1）代码翻译

它们都能够将一种语言的代码，翻译成另一种语言。

我试了 JS 代码翻译成 Python，没有任何问题。豆包 MarsCode 还会自动将翻译后的代码，保存成当前目录下的一个单独文件。

（2）生成单测

单元测试写起来很麻烦，AI 能够自动生成，真是省事不少。

同一段代码，Copilot 生成了4个测试用例，豆包 MarsCode 生成了5个。

并且，豆包 MarsCode 对测试用例有文字总结（下图），这很有用，可惜 Copilot 没有。

我认为，在这个环节，豆包 MarsCode 做得比较好。

（3）修正错误

AI 还可以自动修改报错的代码。如果测试用例或者自动构建没有通过，它会解释报错的原因，并给出修改建议。这里就不举例了。

八、总结

经过上面的一系列测试，两者的表现总体相差不大。我认为，国产 AI 编程助手完全可以替代 GitHub Copilot，而且在某些细节上做得更好。

GitHub Copilot 的优势在于功能较多（比如调用终端命令），而且它的训练材料可能比较多，在一些小众语言上也许表现更好一点。

但是，它是收费的，每月10美元，而 豆包 MarsCode 是免费的，单单这一点就值得推荐后者。

目前，豆包 MarsCode 只是一个初期的版本，后面会不断增加功能。但是，对于大多数程序员，现有功能已经完全够用了。

另外，我在使用中明显感到，豆包 MarsCode 的响应速度更快，毕竟服务器是在国内。相比 Copilot 的境外服务器，这也是一个优势。

总之，豆包 MarsCode 值得大家试用，体验一下国产 AI 的进步。如果你从来没接触过 AI 编程助手，就更不应该错过这种提高效率的编程神器了。

（完）

一、简介

今天，跟大家分享一些企业级的互联网技术。

我要介绍的就是分布式数据库（distributed database）。我尽量用通俗的语言，说清楚它的概念、产品和用法，文末还会提供学习资料下载。

分布式数据库堪称最重要的数据库，几乎所有你知道的大型互联网服务，都运行在它之上。

平时，我们自己开发，接触的都是单机数据库（又称集中式数据库），就是数据库只运行在一台服务器上。

（图片说明：左侧的单个数据库服务器，支撑着整个应用。）

分布式数据库指的是，数据库系统分布在多台服务器。

(图片说明：单个数据库分布在多台服务器上，共同支撑应用。)

在宏观层面，金融、电信、航空、物流、电商等国民经济的重要产业，都离不开分布式数据库。

如果没有它，我们很难想象生活会变成什么样，比如12306那样的购票网站，就没法提供服务了。

在个人层面，当你从初级开发者成长为大型项目的架构师，就多多少少会遇到分布式数据库。

设计架构时，除非只用一台服务器，否则就免不了要考虑，数据在多台服务器之间如何拆分和保存。

总之，产品做大以后，分布式数据库是避不开的。对于个人来说，这也意味着事业和能力的进步。

二、分布式数据库的优点

分布式数据库为什么那么重要？因为它有一些单机数据库无法比拟的优点。

（1）更安全。分布式数据库包含多个节点，不管是放在同一个机房，还是不同机房，都要比单机数据库安全得多。

（2）高可用。如果单个数据库节点故障下线，其他节点还可以照常工作，不会单点失败。

（3）性能更好。对于大数据、大计算量的任务，分布式数据库可以并行处理，大大缩短处理时间。

（4）体验更好。当数据库分布在多个机房，可以为用户分配就近的数据库节点，提供更好的响应速度。

三、分布式数据库的难点

虽然有上面这些优点，但是分布式数据库的使用并不普及，小公司一般不用它，这是为什么？

主要原因是，分布式数据库有两大问题，阻碍了它的普及：成本高和复杂性。

分布式数据库属于"异地多活"，提供了额外的冗余性，来保障数据安全，成本高自不必多言。

它的复杂性主要体现在下面几点。

（1）一致性问题。如何保证不同节点的数据一致？如果节点的数据不一致怎么办？

（2）通信问题。怎样保证节点之间的通信可靠？如果通信延迟或失败怎么办？

（3）分区问题。如果拆分大型数据表，数据储存在不同的节点，那么拆分策略、节点间的数据迁移可能会非常复杂。

（4）优化问题。如果来自多个节点的数据需要组合，查询就必须优化以提高性能。

四、CAP 定理

大家可能知道，有一条著名的 CAP 定理，说的就是分布式系统（包括分布式数据库）无法克服的局限性。

分布式系统有三大目标----数据一致（Consistency）、高可用（Availability）、数据分区（Partition tolerance）。

CAP 定理告诉我们，三大目标无法同时满足，最多只能同时做到两个。在数据分区的前提下，要么为了（强）一致性，舍弃高可用；要么为了高可用，舍弃（强）一致性。

因此，任何分布式数据库都做不到完美，只能是三大目标的某种取舍和均衡。

五、分布式数据库的产品

分布式数据库的历史非常悠久，市场上至少有上百种产品，有开源的，也有闭源的。

几乎所有的分布式数据库，既可以单机使用（即作为单机数据库），也可以多机联合，分布式使用。因此，很多我们熟悉的单机数据库，其实也是分布式数据库。

开源的分布式数据库，比较有名的是 Postgres 和 MySQL（关系型数据库），以及 MongoDB 和 CockroachDB（非关系型数据库）。

商业数据库里面，最有名的就是 Oracle。它是分布式数据库事实上的标准，大企业一般都选择用它。

六、国产数据库 TDSQL

下面，我选择国产数据库 TDSQL 作为示例，介绍分布式数据库的功能和用法。

TDSQL 是腾讯的产品，属于国内领先的分布式数据库。腾讯的几乎所有关键业务，比如微信、QQ、腾讯音乐、腾讯游戏等等，都运行在它之上，经受了高强度、海量的实战考验。

外部很多大公司也在用它，比如小红书、拼多多、B 站、海尔、深圳地铁等等。

它完全按照金融级的标准打造，属于金融级数据库，注重安全、高可用、高并发，客户目前超过50万。在国内金融行业，它服务 TOP10 银行中的7家，已经助力30余家金融机构的核心系统改造。

TDSQL 是完全的国产数据库，特别强调 Oracle 的兼容，企业现有的 Oracle 数据库可以平滑迁移，它的成本要比 Oracle 低很多。如果国内企业有国产化和供应链安全的考虑，它是很好的替代品。

它的产品能力和自主研发，通过了国家认证（《中国信息安全测评中心的安全可靠测评结果公告（2023年第1号）》），对于国有企业的技术选型，这也是很重要的考虑之一。

最后，TDSQL 是腾讯云对外公开的一个服务，任何人都可以使用。只要在网页上点击几下，就开通了，非常容易上手。

七、分布式数据库的功能

我们通过 TDSQL，看看分布式数据库有哪些功能。

（1）强同步复制。分布式数据库往往采用主从式架构，一个集群有一个主节点（master）和若干个从节点（slave）。系统支持节点之间的强同步复制，以保证数据一致。

具体来说，写入数据时，主节点会等待从节点返回操作成功消息，然后才向用户返回结果，这样保证了主节点和从节点的数据完全一致。

（2）事务一致性。系统为每一笔事务提供全局唯一数字序列，每个节点都可以查询事务的执行情况，保证在分布式环境下的事务一致性。

（3）自动拆分。分布式数据库的大型数据表，往往需要进行拆分，储存在不同的节点。TDSQL 支持自动水平拆分（分表），将数据均匀写入到不同节点，查询时也自动聚合返回。

对于用户来说，分表是透明的，完全可以无视，业务端看到的就是一张逻辑完整的表，无需感知后端的分表细节。

（4）高度可扩展。当数据库性能或容量不足时，TDSQL 可以不停机扩展，只需在控制台点击，就可自动升级完成。系统内的数据迁移、数据均衡和路由切换，都是自动的。

（5）高度灵活性。用户可以在线变更表结构；遇到某些类型的故障，系统可以自动恢复；所有节点，不管是主节点还是从节点，都可进行读写。

（6）产品管控能力。TDSQL 对开发者友好，提供大量监控工具，实时监控和告警，每日推送详细的健康探查报告。

腾讯云有一个专门的云服务 DBbrain，利用机器学习、大数据、专家经验引擎等手段，为用户的数据库提供性能、安全、管理等功能。

比如，它会全方位诊断和优化 SQL，发现性能瓶颈，让 SQL、事务、业务流水全链路可观测，可视化展现死锁等异常，易于理解。

它很大程度上了替代了人工 DBA，将传统的人工运维变成智能化服务。

TDSQL 还有一个 AI 智能问答系统（下图）。它基于知识库与小模型训练，快速准确地响应用户查询，相当于一个智能客户，提供专业且个性化的解答。

八、TDSQL 的用法

下面，我来演示一下 TDSQL 的用法，很简单，在网页上开通后，你就可以使用分布式数据库了。

第一步，在 TDSQL 的官网上，进入产品控制台。

第二步，在控制台页面，选择数据库服务器所在的地域（跟你的云服务器应该是同一个地域），以及数据库引擎，然后点击"新建"按钮。

目前 TDSQL 有三种引擎：MySQL、自研的 TDStore 和 PostgreSQL。不管哪一种引擎，都具备一样的容灾能力和高可用，并且兼容 Oracle。

第三步，会跳出一个配置页面，让你选择数据库配置。不同的配置，价格不一样。

其中有一项，问你要不要开通"强同步"。

强同步可以确保主节点和从节点的数据一致性。如果你的应用不要求强一致，更在意快速返回结果，这里可以选择"异步"。

第四步，配置完成后，会进入付款环节，然后数据库就开通了，你的分布式数据库就已经在线了。

使用时，需要先连接数据库，分成内网连接和外网连接，这里可以参考文档。需要注意，如果开通外网连接，数据库就暴露在公网上，任何人都可以请求，必须注意安全风险。

连接数据库以后，就可以执行 SQL 语句了，到了这一步，就跟使用普通数据库没有任何区别。分布式数据库的 SQL 与单机数据库，基本是一样的。

九、TDSQL 的最佳实践

分布式数据有一些最佳实践，下面举出三个（以 MySQL 引擎为例）。

（1）如何将数据导入分布式数据库

这分成两种情况。第一种情况是将现有的单机实例，导入到新建的分布式实例。操作步骤如下（详细命令见文档）。

1. 导出单机数据库的表结构和数据，拿到两个 SQL 文件。
2. 打开数据库的表结构文件，设置每个表的主键（primary key），以及分片依据的 shardkey。
3. 将修改后的两个 SQL 文件，上传到云服务器，导入到分布式数据库。

第二种情况是将现有的一个分布式实例，导入到另一个分布式实例。操作步骤与上面一样，只是少了第二步，不需要指定主键和 shardkey，因为原来就有了。（详细命令见文档）。

（2）如何分片

分片（sharding）是分布式数据库的核心问题之一：到底要架设多少个数据分区？数据在多个分区如何分布？

分片数量取决于，整个数据库预估的最大并发，以及每个分片能够处理的请求数量，可以用下面的公式计算。

读写并发性能 = ∑（分片性能 * 分片数量）

单个分片的性能，主要与实例的 CPU / 内存数量相关。单个分片规格越高、分片数量越多，数据库系统的处理能力越强。

除了性能，分片还要考虑容量问题。一般来说，单个分片至少存储5000万行数据。

（3）如何配置硬件

分布式数据库的硬件，下面给出三个推荐的配置。

A. 测试功能。

这种情况不要求性能，只用来验证系统，建议配置2个节点，每个节点 2GB 内存 + 25GB 硬盘。

B. 业务发展初期。

这种情况数据规模较小，增长快，建议配置2个节点，每个节点 16GB 内存 + 200GB 硬盘。

C. 业务发展稳定期。

这种情况根据业务实际情况配置，可以配置4个节点，每个节点硬件为：(当前业务峰值 * 增长率) / 4。

十、总结

总的来说，当代的分布式数据库产品，将自身的大量复杂性，都隐藏了起来，为用户提供一个易用的操作接口。

一般来说，不建议自己搭建分布式数据库，即使你有专门的数据库工程师和运维工程师，成本也会非常高。使用云服务商的产品，是更经济更省事的选择。

就拿 TDSQL 来说，它有两个版本：集群版和基础版。前者是多节点的，供企业在生产环境使用；后者是单节点的，费用较低，专门供个人使用，但功能是一样的，很适合个人开发者学习或者尝试分布式数据库。

（完）

福利内容

在这个 AI 时代，如何使用云服务，助力企业的数据管理？

下面是三个国内大厂的真实案例。

案例一：微信读书的"AI 问书"。这个功能让 AI 来回答读者提问，关于海量的书籍内容的各种问题。

案例二：海峡银行核心系统升级。省级银行如何使用 TDSQL，将核心系统升级为分布式数据库。

案例三：极光大数据平台的架构优化。极光（URORA）是国内领先的开发者服务提供商，数据量近百 PB，节点过千，文件4亿，应该如何优化架构？

它们来自腾讯云内部编写的资料 《AGI 时代首选的全栈式数据管理方案》 ，包括工具指南、用户案例分享等诸多内容。

现在可以免费下载，只需微信扫描下方二维码。如果你关注国内真实环境中的企业级开发，不妨看看。

本文通过直播的方式分享笔者完全用AI驱动开发的方式开发上线一款产品的全流程。