一、引言

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

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

软件开发的同学，应该都听说过 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 时代首选的全栈式数据管理方案》 ，包括工具指南、用户案例分享等诸多内容。

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

互联网开发的核心是什么？

答案可能就是网站架构。你要选择一个合适的架构，用来组织代码，然后在服务器跑起来。

今天，我想给大家介绍，眼下最流行的一种网站架构。它非常合理，效果极佳，而且借助云服务商提供的工具，架设非常容易。

它就是本文的主题----边缘平台架构（edge platform）。

大家可能经常听到"edge"（边缘）这个词，但是未必了解它的意思。我尽量用通俗的语言，解释什么是边缘，什么是边缘平台架构，它的优势在哪里，以及怎样利用边缘平台，架设自己的网站。

一、从"服务器-客户端"谈起

为了理解边缘平台，需要从最基本、最传统的"服务器-客户端"（server-client）架构讲起。

在"服务器-客户端"的架构下，存在一个中心服务器，所有客户端都向它发出请求。

这种架构的优点是简单易行，缺点是中心服务器是一个单点依赖。一旦访问量大，可能会有性能问题，还可能中断服务。

而且，中心服务器的物理位置是固定不变的，导致用户的访问速度与地理距离有关。同样条件下，离服务器越近，访问速度越快；离服务器越远，访问速度越慢。

二、CDN 的出现

为了减轻中心服务器的负担，更是为了拉近与用户的地理距离，CDN 架构就出现了。

CDN 的想法很简单，就是在各地的机房中设置大量的节点服务器，把每次访问都不变的静态资源文件，复制到这些服务器上面。

用户访问时，涉及静态文件的请求就不会发到中心服务器，而是通过 DNS 系统，发到地理位置最靠近的节点服务器，由后者负责响应用户。

这样的设计，既减少了发往中心服务器的请求，也减少了用户与静态文件之间的物理距离，从而加快了访问速度。

三、边缘的概念

大家可能注意到了，CDN 架构中存在两种不同作用的服务器。

一种是中心服务器，负责数据计算和存储；另一种是节点服务器，负责发送静态资源文件。

由于节点服务器是在架构的外围，为了跟中心服务器相对应，人们就把起到外围辅助作用的节点服务器，称为"边缘服务器"（简称边缘）。

就像上图中，中心服务器在云端（cloud），它的外围是边缘服务器（edge），然后才是用户（user）。

边缘服务器有一个重要特征，它是距离用户最近的服务器。人们有时候提到"边缘"，就特指最靠近用户的那组节点服务器。

四、边缘平台架构

CDN 架构只是把静态文件放到了边缘服务器，数据计算和数据存储还是在中心服务器，对于用户来说，这部分可能还是很慢。

很自然地，大家就想到了，能不能把数据计算、数据存储也放到边缘服务器呢？

答案当然是完全可以。只要把数据计算设计成不涉及状态的云函数，把数据存储限制在没有一致性要求的数据，它们就都可以放到边缘服务器。这就是边缘计算和边缘存储的由来。

这样的话，数据计算、数据存储、文件下载，都由距离用户最近的边缘服务器处理，网站的响应速度就会整体提升。

由于边缘服务器这时具备多种功能，实际上就升级成了边缘平台，CDN 架构就变成了边缘平台架构。

在这种架构下，你的网站有许多个实例，分布在每一组边缘服务器上。用户访问的总是距离最近的那个实例。

注意，中心服务器这时还是存在的，只是它的工作主要变成了协调和同步边缘服务器，而不再是直接与客户端交互了，客户端只与最近距离的边缘服务器直接联系。

五、国外的边缘平台

国外很多新兴的云服务商，现在都主推边缘平台架构。

世界最大的 CDN 服务商 Cloudflare，早就不限于 CDN 服务了。它的边缘服务器除了存放静态文件，还可以进行云计算、数据库读写、图像处理等许多功能。

其他的云服务商 Vercel、Netlify、Netflix、Deno Deploy 提供的都是类似的服务。

国外的这些边缘平台，有一个最大的缺点，那就是服务器都在境外，基本没有中国大陆境内节点。

对于境内访问者，没有境内节点，就完全发挥不出边缘服务器响应速度快的优势。所以，如果你有境内的访问者，建议考虑使用国内的边缘平台。

六、腾讯云边缘平台 EdgeOne

根据官网，腾讯云的 EdgeOne 是"中国云服务商中首家提供安全加速一体化的边缘平台"。我自己也使用这个产品，对它比较熟悉。

下面，我就拿它举例，大家可以看看，真实的边缘平台是什么样的。

作为边缘平台，需要满足三个条件。

首先，必须有全球分布的大量节点。EdgeOne 基于腾讯云，目前全球节点有3200+，覆盖了100+的国家与地区。不管用户在哪个地方，都能找到就近的节点。

如果某个节点饱和或发生故障，也可以切换到其他节点，保证站点的可用性。

其次，必须有海量的带宽，否则难以经受大访问量的冲击。EdgeOne 的总带宽达到 160Tbps+，足以抵抗大流量业务的突增。

再次，必须集成大量功能，方便用户使用。EdgeOne 把腾讯云的能力，几乎都搬到了边缘服务器。具体来说，它集成了以下能力，有一些突出的技术亮点。

（1）全球的 CDN 加速。EdgeOne 是腾讯云的下一代 CDN，在底层对境内加速和境外加速分别作了适配，用户不再有感知。

（2）Web 应用防火墙。它不限制用户的 QPS（每秒请求数），提供智能 CC 防护，通过全平台流量分析，统计并识别正常业务和突增流程特征，制定动态适应策略。同时精准有效拦截 Web 漏洞威胁，抵御 SQL 注入、XSS 等多种攻击，保障站点健康可用。

（3）边缘函数。只需编写简单的函数，无需考虑服务器等基础设施，就可以在边缘节点上运行自己的代码。

（4）自定义安全策略。用户可以指定5条自定义拦截规则，实现个性化的管控需要。用户还可以实现基于黑名单及白名单的 IP 管控和区域封禁。

（5）DNS 解析服务。它的每个边缘节点上都预备域名解析能力，1个站点可以设置300个子域名。

（6）用户行为分析和日志记录。它会分析和监控异常流量，发现各种机器人爬虫，并提供详细的日志图表，以及各种访问者指标。

综上所述，边缘平台实际上是一种 All in one 的产品，属于 CDN 的升级版，多种功能集于一身，并提供简单的使用接口，极大地方便了用户。

这里插一句，EdgeOne 的产品全称是"边缘安全加速平台"，在边缘平台的产品基础上，特别突出了安全和加速两大特点，作为主要的功能卖点。

七、边缘平台的应用案例

读到这里，大家对边缘平台是什么产品，应该已经有一个大致的了解。

你可能还会有疑问，在真实的生产环境中，它的作用到底有多大？

下面是一些从 EdgeOne 官网摘录的真实案例，大家可以感受一下边缘平台对网站表现的巨大帮助。

（1）游戏行业。某大型热门游戏用了边缘平台以后，请求耗时改善60%，同时成功防护了 DDoS 攻击，攻击的峰值流量达到 2.04Tbps。

（2）社交文娱行业。某短视频的头部平台用了边缘平台，降低20%卡顿率和50%播放失败率，在部分东南亚国家性能改善高达100%，同时全面过滤海量攻击流量，保证直播等业务正常运行。

（3）电商零售行业。在边缘平台上，电商平台完成了所有商户域名的便捷接入，还能自动颁发和更新免费 HTTPS 证书。

（4）金融行业。边缘平台大幅提高金融服务的访问性能，保证网银、手机银行，信用卡都获得了安全加速。

（5）全球办公。在全球协同办公场景下，边缘平台优化国内与海外办公系统连接时的访问速度，提高办公效率和访问体验。

总之，只要你的网络服务，对访问速度和安全防护都有较高的要求，就可以考虑使用边缘平台。

尤其对于那些有出海需求的国内企业，既要全球加速，又要防御各类攻击，像 EdgeOne 这样的边缘平台应该是首选的网站架构。

八、边缘平台动手试

大家千万不要觉得，边缘平台是大企业的专用产品，个人和小企业其实也完全可以用上边缘平台。它的功能并不区分访问量的大小，都统一适用。

再说，看了这么长一篇介绍，你难道不想动手试试吗？只有亲自上手，才能真正学会。

EdgeOne 刚刚进行了产品更新，发布了基础版和个人版。下面，我就以它为例，演示一下如何上手边缘平台的两大核心功能----网站加速和安全防护。

（1）网站加速。这跟 CDN 的操作是一样的，只需要一步操作，把域名交给边缘平台接管就可以了。

进入EdgeOne 的主页，点击"立即使用"。

它会提示你"添加站点"，输入自己网站的域名即可。注意，该域名必须此时已经可以访问了。

然后，系统会问你选择哪一种套餐，初学者选择"个人版"即可。

接着，它会要求你设置加速区域和 DNS 接入模式。

加速区域就是哪些区域的边缘服务器将会生效，一共有三种可选----全球，中国大陆，中国大陆以外地区。

DNS 接入模式是最关键的部分，一般情况下，都是选择把域名的 DNS 服务器迁移到边缘平台。对于那些不方便迁移的用户，EdgeOne 还提供了另一种选择，将域名的 CNAME 记录指向 EdgeOne 即可。

然后就是最后一步，设置 DNS（或者 CNAME）的细节。

一旦 DNS 设置完成，边缘平台就会接管所有发往该域名的请求，分配给最近的边缘服务器，加速就自动实现了。

（2）安全防护。一旦边缘平台开始生效，就会检查所有请求，EdgeOne 会自动识别和过滤掉 DDoS 攻击和恶意请求。

这部分不需要用户设置，某些情况下，用户可能希望过滤掉具有指定特征的请求，那么就需要自定义拦截规则。

下图是设置某个服务的海外版，只接受海外用户访问，不接受来自中国大陆的请求。

下图则是同时设置两个条件，只有来自 IP 地址1.1.1.1的请求，才能访问指定路径（后台）。

九、总结

从上一节的操作步骤，大家可以看到，虽然边缘平台本身是一个复杂的产品，但是所有的复杂性都被封装了，用户的操作是非常简单的。

如果你希望自己的网站，对所有访问者都有良好的速度，能够应付瞬间的大流量，并且还有足够的服务器安全性，同时又不必支付高昂的费用，用多少付多少，那么 EdgeOne 这样的边缘平台架构就是你的最佳选择。

它把加速和防护赋予了每个开发者，让你的产品更安全、更易用、更开放，还节省成本。

EdgeOne 本次产品更新后，推出了力度很大的优惠，个人版第一年的费用不到4元/月，为大家学习和试用创造了良好的条件。

大家可以扫描加入产品交流群了解产品更多动态，或者访问这个链接，以优惠的价格用上边缘平台。

（完）