开着飞机换引擎？揭秘阿里巴巴的数据库运维

作者 | 谭宇

编辑 | 李夏昕

阿里巴巴的数据库是怎样演化的？阿里巴巴数据库管控中台发展过程中遇到了哪些问题？

阿里巴巴集团拥有超大的数据库实例规模，在快速发展的过程中，从物理器到容器、从独占到混布、从本地盘到存储计算分离、从集团内到大促云资源，从开源的 MySQL 到自研分布式数据库，数据库运维管控工作不断地进行自我革新与进化。

阿里巴巴数据库管控中台发展过程中遇到了哪些问题？有什么解决办法？运维工作有哪些革新？我们就这些问题采访到了阿里巴巴数据库事业部高级技术专家谭宇（茂七）。另外，谭宇也会在 CNUTCon 全球运维技术大会的“数据库运维”专场给大家带来分享。

  InfoQ：阿里巴巴的数据库是怎样演化的？

谭宇：阿里巴巴的数据库演化之路想必为很多人所熟知，从 IOE 到开源数据库再到自研分布式数据库，主要是从业务需求、成本以及稳定性等几个方面进行的。从业务需求来看，传统的 IOE 架构很难满足互联网业务的快速发展，所以这里有了从 IOE 到开源数据库的演进。后续随着数据库规模的急剧提升，数据中心和业务的全球化，开源数据库在生产成本和管理成本上面临很大的问题，同时新硬件、软硬件结合等技术的发展让我们看到了自研数据库的契机。

  InfoQ：阿里巴巴现在有哪些自研数据库？都有什么特点？

谭宇：现在数据库的概念比较宽泛，NoSQL、流式计算、图等领域都有称作数据库的产品。在 OLTP 方面，整个阿里集团，包括蚂蚁金服一共有三个比较出名的自研数据库，每种数据库都有各自的侧重。例如，蚂蚁金服的 OceanBase 主要侧重在金融领域，提供永不丢失数据、金融级的数据库服务；阿里云的 PolarDB 则侧重于提供给云上客户 CloudNative 的数据库服务，在价格、易用性、生态兼容方面非常注重；集团的 X-DB 则是从集团的复杂业务演化而来，要解决集团业务的诸多难题（如全球部署、异地多活、冷热数据分离、HTAP、超大规模实例、成本等问题），立足于给用户提供更灵活的功能选择、更便捷的管理方式。除此之外我们也有时序数据库 TSDB、分布式数据库 DRDS、分析型数据库 ADS 等，用来解决不同领域的问题。

  InfoQ：从开源的 MySQL 到自研分布式数据库，阿里巴巴的运维工作都做了哪些革新？

谭宇：在支持自研数据库的初期，运维工作的复杂度更高。数据库特别是 OLTP 数据库具有很高的门槛，所以一个自研的数据库永远不可能在上线前准备好。我们内部将由开源数据库到自研数据库的迁移比喻为“开着飞机换引擎”，要在不影响业务的情况下更换数据库，这对运维工作要求非常高，需要具备随时切换及回滚的能力。

  阿里巴巴的数据库管控和实现方式是什么样的？

谭宇：像很多系统一样，我们的管控也在不断演化，管控系统本身从早期的工具到现在的产品化、平台化，架构上我们先后做了服务拆分、前后端分离等，服务方面基本做到了自助化，管理方面逐渐从多终端管理走到集中化管理。数据库本身的运行环境也由原来的物理机到了容器、存储计算分离、在 / 离线混部等形态，整个系统差不多长这个样子。

DBPaaS

最底层是我们支持的环境与数据库引擎，集团本身是一个超大的混合云，比如在全球化部署的形态下，不同的地域由于技术或政策原因可能会用上不同的基础设施，收购过来的公司也有自己的环境，大促时会直接使用公有云资源，这些都对我们的管理水平提出了更高的要求。中间层是我们平台主要的功能，包括运维部署、备份恢复、告警与高可用等。上层是我们的控制台与一些企业级的功能，用来处理业务相关或不同 BU 之间的不同需求。我们在做完这些以后，发现这也是业界的一个普遍需求，于是，我们就把这个平台在云上进行了输出，详细可以查看我们的 HDM 产品，HDM 可以很好地进行混合云场景下的数据库管理，让数据库像应用一样进行弹性和容灾。

HDM

  InfoQ：不同规模下的数据库管控方式有什么不同？

谭宇：规模可以说是一切问题的根源。在规模小的时候，对实现方式和系统的稳定性要求都没那么高，系统可以很灵活，就算在实现过程中犯了什么错误，也都非常容易补救。但规模变大以后，技术实现难度变高了，以监控系统为例，1,000 个实例和 100,000 个实例是截然不同的，1,000 个实例可能做个简单的采集就行了，但 100,000 个实例你就必须得上流式计算和分布式存储了。再以运维操作为例，操作 1,000 个实例和操作 100,000 个实例也有非常大的不同，操作 1,000 个实例可能不用太关注任务成功率，也可能不用太关注效率，任务执行过程中发生宕机等异常情况也不会多，但操作 100,000 个实例就不一样了，随时可能出现宕机等异常，失败 1% 就会导致大量的问题。所以在规模大的时候，对系统稳定性的极度要求、对异常情况的处理会让系统变得很复杂。

  InfoQ：在数据库管控中台发展过程中，您遇到过什么挑战？是怎么解决的？

谭宇：数据库管控中台或者类似的系统非常复杂，可以说处处都是挑战，中间有很多次都想放弃。一定要总结的话，我觉得有几点，第一是人的问题，管控系统的技术栈非常深，从前端到 DB 再到网络、内核都有涉及，对人的要求非常高。第二是需求与实现的平衡，运维类的系统需求非常繁琐，难以抽象，甚至短期及临时需求非常多，如何做到平衡是一件非常难的事情。第三就是系统稳定性建设的事情，运维系统的基线在于稳定，但运维变更引起的故障历来是最多的，怎么去解决这个问题很难。

  InfoQ：容器化给数据库带来的好处、问题和解决方法都有哪些？

谭宇：第一个好处是，容器自身带来的的好处，比如标准化、解决环境问题、交付速度等。另外一个就是让数据库也具备可调度的能力，再结合存储计算分离等技术可以给数据库运维带来很大的改变。问题主要是性能方面和管理方面，性能可以通过各种优化及新硬件去解决，也接受一定的性能损耗。管理方面有利有弊，但引入容器肯定是更复杂了，比如在出现问题的时候人工都可能就难以处理了，必须要借助工具、平台。

  InfoQ：您认为数据库运维未来的发展方向是怎样的？

谭宇：从历史看未来，运维从工具到各种 as-a-Service，从数据驱动运维到今天的 AIOps，还有各种自治系统，比如自治数据库，其本质都是资源的交付、服务与管理水平的提升，这也是云一直在解决的问题。所以我认为运维的未来就是这几方面的持续提升，真正做到让业务专注在业务，不再为容量等事情担心；同时在成本方面做到极致。所以我们今年内部一个很重要的目标就是绝大部份数据库实例完全托管，不需要人再接收报警，由系统整个完成容量、异常等处理。

---

作者简介

谭宇， 2009 年加入阿里， 先后参与过 TFS(淘宝分布式文件系统）、Tair(淘宝分布式缓存) 以及 OceanBase(分布式数据库) 等几大分布式系统的开发，对分布式系统和数据库领域有很大的兴趣。目前负责阿里巴巴集团数据库中台建设，支撑了集团数据库在容器化、存储计算分离、在离线混部、大规模迁移建站以及智能运维等技术探索与落地。

CNUTCon 将于 2018 年 11 月 16 日 -17 日在上海·光大会展中心大酒店举办，本届 CNUTCon 面向各行业对运维 & 容器技术感兴趣的中高端技术人员，聚焦 AIOps 相关技术及优秀实践，谭宇将在 CNUTCon 上分享阿里巴巴数据库运维发展与实践，重点讲述数据库管控中台发展过程中遇到的问题以及阿里巴巴的解决方法，希望能帮助大家去理解阿里巴巴的数据库管控方法与实现方式，不同规模下数据库管控，理解容器化、存储计算分离、混部给数据库带来的好处、问题及解决方式。