从单机百万 tpmc 到分布式千万 tpmc，GaussDB 性能提升的 3 个关键技术剖析

作者：乌龟哥哥

2022 年 9 月 30 日
上海
本文字数：3537 字
阅读完需：约 12 分钟

前言

当我们需要业务的快速上线时，但是传统的方式的话呢很难以去快速达到，但数通网络开放可编程平台的话能够提供一种可行的解决方案。

对于集成商来说，当需要把某个厂商的控制器或者设备集成到客户的 OSS 系统，会面临着非常多的接口对接工作。在数通网络平台，可以帮助集成商减少开发时间和成本。

对于设备商品来说，当把某设备推入到一个已存在的网络，需要和这个设计和这个网络已有运维系统对接。会涉及到去适配企业的一些标准接口的一些问题。数通网络提供一种快速的开发模式，可以使我们的设备尽快的和企业标准相对齐。

对于高校来说，高校经常会有一些维护网络诉求。或者一些课题的研究，技术创新等， AOC 是一个技术创建的理想平台。

对于大学生来说，写毕业论文需要一些实验性的数据去支撑论文。那么我们的数通网络开放可编程平台可以提供一个可操作实验平台。

对于课余个人开发者来说，通过数通网络开放可编程平台，在应对一些项目的时候，会有更多的选择，有更多的机遇。

点击并拖拽以移动

编辑

图表 1 数通网络开放平台适合人群

网络运维面困难与挑战

网络运维面临困难

上线周期长是现在各个厂商遇到了一个普遍的困难。

网络运维在历史发展中间经历了几个阶段：

首先网络初始阶段，此时网络比较小。运维人员可以通过手敲命令行的方式来对网络进行运维。但随着网络规模的慢慢的增长，敲击命令行的方式效率较低。此时会有一些命令行的脚本来提高网络执行效率，但是网络的运维复杂度并没有降低。

随着 SDN 技术，网络控制器的出现。可以基于特定的解决方案和产品来简化网络运维。同时也会遇到一个问题。控制器提供的这种高度的自动化能力和我们对网络的自主操控能力两者之间是存在矛盾，自动化程度越高，也意味着我们对网络的自主可控性也就越低，就缺少方法能够达成完美诉求。

当前的 5G 时代，业务与厂商耦合是制约业务快速上线的主要因素，但是缺少系统的网络平台来实现功能。

点击并拖拽以移动

编辑

图表 2 传统的“人流量”人工操作维护模式

以 Windows 为例，客户对网络操作平台能力诉求

Windows 电脑平台有各种各样的硬件，例如鼠标，键盘，内存，主板等各种硬件。而且这些硬件会有不同的厂商，不同厂商针对于不同的时期的会推出不同的版本，不同的产品。

那么 windows 是如何对这些电脑硬件进行控制的话呢？它是通过驱动来对这些设备硬件进行控制。但要给上层的应用开放这些可以操控硬件的接口。无论上层的设备硬件如何去替换，换成不同厂商的不同型号是固定不变的形式。所以这种模型映射的能力就是从上层固定不变的 windows 上传 app。去适配换成不同硬件能够提供的这些驱动的接口。

这种模型转换的能力，是 windows 的基本能力。那么同的，数通网络操作平台也是具备同样能力。

点击并拖拽以移动

编辑

图表 3 以 Windows 为例，客户对网络操作平台能力诉求

数通网络可开放编程平台介绍

面对网络运维的严峻挑战，开放可编程系统以 YANG 模型驱动为基础，提供了端到端的开放可编程能力：设备驱动可编程、网络业务可编程、开放设备和业务北向接口，并且提供了安全可靠的保障机制。

数通网络可开放编程平台叫做 AOC，是 Asia Open Container 敏捷开放容器的一个缩写。他的下方对接网络设备，通过三种协议来对网络设备进行管控。上方对接 iOS 系统。

点击并拖拽以移动

编辑

图表 4 AOC 开放可编程平台所需具备的架构和能力

SND 包：网元驱动包（Specific NE Driver Pkg），为开放可编程系统提供与网元交互的数据模型。
SSP 包：业务包（Specific Service Plugin Pkg），定义了完成一套网络级业务配置对应的数据模型。该数据模型通常包含一个 Jinja2 模板文件、一个 Python 映射脚本和业务 YANG 模型。
系统通过加载业务包，可以进行业务配置下发，实现新业务的快速构建。

点击并拖拽以移动

编辑

图表 5 Yang 模型驱动

在传统的开发流程中间，设计人员完成设计之后，开发人员进行 API 的代码开发界面开发，业务的流程开发以及数据库的开发。如果使用 IOC， API 代码开发，界面开发和数据库开发都不需要再去开发代码。模型驱动帮助客户大家自动开发。意思也就是说，如果我们模型定义好，这三个能力 API 的代码开发界面的开发和数据库的开发，会有机制去帮助大家完成事务机制。

我们在去做一些网络变更时。最怕的是变更失败，如果一个网络操作变更失败了，那么我们需要在最短的时间之内去把这个网络恢复到我们变更之前的状态，以免对原有网络上的这些业务造成影响。传统方式的话在做网络变更的时候，工程师坐在电脑前面。她对设备进行敲命或者是说去运行一些命令行的啊脚本的模式来对设备一台一台的去进行配置。

那么当有任何的网络失败的时候，测试工程师需要从屏幕上面就感知到这个网络的失败，同时之后编辑命令语句，执行回滚操作，来把网络回滚到下发配置之前的状态。在使用 IOC 后，工程师在界面上面点击一下鼠标触发。如果有任何的网络失败，会自动的去感知网络失败，自动的去完成这些回滚的操作，把网络回滚到配置之前的这个状态。不用去担心会对现网的业务有任何的影响。

点击并拖拽以移动

编辑

图表 6 事务机制:失败自动回滚，保障配置安全

我们以前在做一些命令行的阶段，要写一些命名好的脚本，或者是一些命令行的模板。针对某一个接口，都要去写增删改查四个操作的一个。通过命令行模板，只需要去创建接口。而删改查这三个接口自动地去完成，代码开发工作量减少 75%，四个接口我就只需要实现一个了，这就是 mapping 机制。

点击并拖拽以移动

编辑

图表 7 Mapping：支撑极简代码

通过外部反馈可以让操作人员清楚具体配置是什么，来作为网络变更的最后一次检查的机制，这就是配置预览。传统方式是脚本进行网络业务变更，需要一台设备，一台设备的去进行变更。当第一台设备变更完之后，后续设备才能够去进行。因为命令行它是一种人际交互，必须需要等人去等设备的反馈。在 AOC 平台上，当业务配置涉及到某个设备，可以在五台设备同时下发，设备执行效率提高五倍。

点击并拖拽以移动

编辑

图表 8 配置预览

点击并拖拽以移动

编辑

图表 9 高效的业务配置

AOC 有 SSP 针对北向业务。OSS 对接对应企业标准，南向会存在设备驱动，我们在进行配置时就存在两种配置，一种是 OSS 系统跟 AOC 之间的配置。第二种配置是 AOC 和南向设备网元具体下发命令行的配置。通过 AOC 平台，我们进行每一次交互都可以记录下来的。以后有问题定位或者业务巡检时，都可以有据可查。因此 AOC 平台提供了两个配置历史记录能力，一个是北向配置历史记录，一个是南向的配置历史记录。