构建云上企业数据库架构分为哪五步？

最新推荐文章于 2024-02-22 17:50:55 发布

weixin_33800593

最新推荐文章于 2024-02-22 17:50:55 发布

阅读量305

点赞数

文章标签：数据库运维网络

原文链接：https://yq.aliyun.com/articles/292769

版权

阿里巴巴高级数据库架构师黄欢欢在2017云栖大会苏州峰会上与大家分享了云上企业数据库架构之路。主要分享了构建企业级数据库架构包括异地多活、数据库容器化、混合云架构、计算存储分离和数据库与离线混布，其中包含X-DB、HDM等重要云产品。
以下是精彩视频内容整理：
做数据库架构需要满足三个基本需求。第一个问题是扩展，业务高速发展，单地资源容量受限；第二个问题是弹性，双十一对弹性扩展和收缩的需求；第三个问题是成本，在尽可能小的预算成本内完成业务目标。
为了满足这三个需求，阿里巴巴在数据库架构上做了很多探索和改进，包括异地多活升级、数据库容器化、混合云架构、计算存储分离和数据库与离线混布。

异地多活

从数据库的角度看异地多活，从设计原则上要遵循两个规则。第一，数据要从一个角度进行拆分，保证数据不会被双写；第二，单元内实现业务封闭，比如下单过程中要登录、扣库存、扣优惠，登录在一个单元里，扣库存跳到另外一个单元，这就会导致混乱。所以，数据库的设计比较简单：每个Region独立的DRDS集群，Region之间DTS数据实时传输。
多活的基础：DTS

DTS可以打通各种异构数据源间的数据流动，让数据发挥更大的业务价值，它源自阿里去IOE及异地多活架构的实践。典型的业务场景比如异地多活，单元间的数据同步可以通过DTS实时同步/分发，延迟都在秒级别内；另外，异构数据源之间的迁移同样可以通过DTS进行实现。
X-DB多region部署
不是所有数据都能在各个Region中写入，比如库存数据一般只在单点写、多点读，在这种业务场景下，如果使用原来的业务架构，当一个中心挂掉实现异地容灾时，由于单元之间的数据是异步同步的，切过来后可能出现数据不是强一致。对此，我们提供了第二代分布式关系型数据库X-DB。

库存业务通过X-DB多Region部署如图，主备5节点保证主节点每一个写日志一定需要同步超过3个以上的备节点才能够返回业务成功。所以，X-DB的优点包括以下四个方面：

Region级的强一致性，做到单个Region不可用0数据丢失；
高性能。跨Region强同步下依然保持高性能；
灵活的切换策略。优先切换同Region，定制跨Region切换顺序；
高伸缩性。可无限制的扩充Region/AZ的节点，可自由的调节Region/AZ内节点。

DB容器化

异地多活升级后，下一步开始尝试做数据库容器化。

一方面，我们做了AliSQL in Docker，通过统一的一层调度支持数据库二层调度，比如主备容器规格一样。AliSQL in Docker支持数据库业务逻辑的调度策略，构建了完善的资源隔离方案，已经做到了100%容器化；
另一方面，我们做了AliSQL in 高性能ECS，使用了SPDK+NVMe存储和DPDK网络，整体上测试得出，与同等规格物理机相比，虚拟化带来的损耗降到了最低，性能降低5%以下。
数据库容器化是数据库构建起可扩展架构的基础部分，只有做完容器化，才可能实现架构的进一步演进。

弹性混合云

在日常的流量下，用户可以跑在自建IDC下，大促期间使用弹性混合云架构，大促前将数据库弹性扩展上去，大促结束后将申请的ECS资源返还回去，扩上去和弹下来可以在一个月内完成。为什么我们有这么快的弹性伸缩能力？这依赖于新的云产品混合云数据库管理平台。

我们可以做到一键构建新的数据库云单元，混合云数据库管理主要提供三大块内容：

统一管理：HDM可以进行云上云下数据库统一管理；
快速弹性：比如原来数据库在云下，大促时在云上加只读节点，大促结束后再销毁只读节点。也可以在云上快速建立起大规格资源，支撑完业务后再弹下来，最大限度享受云资源的弹性能力；
容灾切换：自建IDC出现问题时，HDM提供了数据库容灾切换能力，包括云上切换云下，或云下切换云上。

计算存储分离

完成异地多活架构、数据库容器化和混合云架构后，我们仍然与应用不一样，应用容器化后可以快速调度，但数据库还不行，为什么？因为应用是无状态的，而数据库是有状态的，数据库下面拖有数据，如果有持久化数据，就没办法与应用一样做到弹性能力，因此，我们只有进行计算存储分离。
那么，为什么要做计算存储分离？原因有以下四点：
第一，要做更好的弹性能力就要把DB去状态化，将计算节点和存储分开，使调度变得更简单；
第二，解除计算和存储Bond，如果计算节点需要扩2倍、存储节点需要扩4倍，分别对计算和存储进行扩容。另外，将数据放在统一的存储里，磁盘碎片会大大减少；
第三，计算节点不再需要冗余，节省了成本；
第四，为数据库在线和离线任务的混部提供了基础。

数据库计算存储分离架构如图，AliSQL为计算层，计算层与存储层之间使用25G TCP/RDMA网络，存储层按照一定的规则和数据可靠性要求将数据打散在不同的Rack和集群中。
做计算和存储分离面临的技术挑战很大，对吞吐和时延的要求非常高。我们需要在各个维度做很多优化，包括：

分布式存储优化：长尾时延优化，写三反二；Partial recovery，降低对线上业务的影响。
数据库优化：AliSQL 吞吐优化，提升100%；原子写优化，关闭double write buffer，提高吞吐；时延接近本地盘。
软硬件优化：引入RDMA网络协议，SPDK用户态文件系统等。

DB与离线混部

为了进一步减少成本，我们将数据库与离线任务混部在一起。

实现计算存储分离后，离在线混部即成为可能，大促时可以借助离线机器计算资源，存储资源仍旧放在分布式存储中。可以看到，在大促时，将数据库计算节点弹到离线机器上去，与离线任务一起跑；在日常运行时，离线和在线任务调度到DB节点，提高资源利用率。那么，如何保障资源隔离呢？我们做了CPU独立socket，避免L3 cache干扰，同时进行了NetQos打标，保证优先级。此外，我们也在离在线混部时构建了弹性能力，使计算节点快上快下，MySQL BP和容器规格动态扩缩容。
通过异地多活、X-DB、容器化、混合云、计算存储分离以及DB离线混部共同构建了企业级数据库架构。

以上由云栖社区志愿者小组整理，毛鹤校审，编辑：郭雪梅