eBay Cloud 基于 MongoDB 的 CMDB 经验分享

2011 年，eBay 启动了私有云项目 eBay Cloud，并于 2012 启动其管理系统 Configuration Management Service（CMS）的研发。根据其团队描述，CMS 是一个高性能的配置管理服务，对配置元数据进行持久化，支持 RESTful API 以及 Java 和 Python 的客户端库。

CMS 的研发和运维团队有部分成员在上海研发中心。近日，InfoQ 中文站与 eBay Cloud Service 团队资深软件开发工程师苏良飞进行了沟通，了解该团队最近的发展情况。

嘉宾简介

苏良飞，现在 eBay Cloud Service 团队工作。开发了 eBay Cloud Service 的 Configuration Management Service(CMDB) 和 Load Balancer Management Service。主要关注 Java 服务器端开发和分布式系统开发。

InfoQ：先介绍一下您所在的 eBay Cloud Service 团队吧。

苏良飞：我目前所在的团队属于 eBay Cloud Service 里的 Cloud Foundation。我们团队目前在上海有 5 个研发人员，都是开发 Java 服务器端程序（Core Java SE），另外数据库知识（SQL database、MongoDB、Cassandra）以及服务器的运维也是我们所必须的技能。

我们团队现在主要职责是 CMS（Configuration Management Service）系统的开发和运维。KPI 的设置与产品的发展是一致的，主要包括：

• 产品新功能的开发和改进
• 线上 CMS 的整合（CMS 在各个组的采纳率是我们的目标之一）
• 线上 CMS 可用性的监控和维护
• 基于 CMS 数据的报表和监控

CMS 这个项目是在 12 年中启动，原型系统在 13 年初线上部署。在 2013 年里我们开始进行线上数据的整合（包括和不同部门间的整合），对不同部门的实施访问控制，对代码进行了一次较大规模的调整，在 2013 年还开始了基于 CMS 数据的 validation，目标是对 eBay site 上的环境进行冗余和风险的监控（一些服务在部署时因为缺少整体的数据视图，导致缺乏必要的冗余或者是不充分冗余），还对 CMDB 的数据修改实现了基于 Cassandra 的 audit。

目前 CMS 项目工作重点是：

• 核心系统新功能：
  • 新的查询功能的上线
  • 多 mongo repl-set 的分片实现
• 整合
  • 与更多的内部工具整合，目前还只有 eBay 的 cloud 服务在 CMS 上运行。eBay 网站的实时监控正在和 CMS 做整合
• 系统运维
  • CMS 有 5 个 9 的可用性要求
• 周边系统开发：
  • audit 的 snapshot 功能
  • 基于 CMS 的 JSON data 进行数据的分析（上述的 site 环境监控）

InfoQ：CMDB 作为 Cloud 系统中的统一数据存储，在设计的时候主要关注哪些能力？

苏良飞：CMDB 在设计中的一些主要考虑点是：

1. 读写不均衡，典型的读大于写的用例
2. 配置系统的数据量不算太大，可以尽量的使用 memory
3. CMDB 的表结构的改动比较频繁，系统要能提供尽量平滑的表结构改动
4. 对于日常的查询，CMDB 应该能提供方便的查询语言

前三点是我们采用 MongoDB 的出发点，而对于第四点我们实现了自己的查询语言来提供跨表的查询功能。

InfoQ：从 CMDB 上线运作之后，你评估这套系统设计的好的地方在哪里，又有哪些地方是一开始没有考虑到的？遇到的最大的挑战是什么，又是如何解决的？

苏良飞：上线之后，从用户的角度，看到了读写的消耗时间的下降，CMS 的查询语言提供了方便的数据查询能力，权限控制使得不同组的权限更加明确，这些都是和已有系统相比的带来的好处。

CMS 的查询语言是为了提供用户在 MongoDB 做跨表查询和提供更方便的数据查询功能而实现的，上线后用户提了很多查询需求，比如对于对象图中的反向查询，树形查询，子查询，这几个功能都是一开始没考虑到的。

遇到的比较大挑战主要有：

1. 数据量增加后的查询分页处理。现在的 NoSQL 查询系统一般要求做多表链接时至少其中的一个表能够完全导入到服务器的内存中。而我们通过转移部分工作到客户端，解除了这个限制，实现了一个 iterator 模式的数据分页。
2. 系统可用性的挑战： MongoDB 的一些限制，比如 MongoDB 在比较大的数组建索引时会出现数据写操作很慢的情况，因为 MongoDB 是数据库级别的读写锁，这样的一个写操作会使得整个的系统延迟变的很高。为此，我们加入用户控制（rate limit）、模型修改（避免大数组索引，把引用关系存到多端）、以及基于内存的节流阀（throttling）来控制用户的行为和保证系统的可用性。

InfoQ：eBay Cloud 系统包含哪些组件，各自之间的关系是怎样的，各自是哪个团队在维护？

苏良飞：目前 eBay Cloud 正在迁移往基于 OpenStack 开发的云平台。这一块包含了 OpenStack compute/network/glance/keystong/storage。而 OpenStack 覆盖比较弱的 load balancer / dns 部分，eBay 自己开发并向社区贡献了设计和代码。

OpenStack 对 BareMetal（物理机）的支持还不成熟，eBay 在这块使用了自己开发的 Stratus（由上海的团队负责）。 对 cloud 的 configuration 统一的存储是在 CMS 中，CMS 存储为上层的 PaaS 和 remediation 提供了数据源。在 OpenStack 和 CMS 之间是通过异步的消息队列监听进行数据同步。

InfoQ：整个 eBay Cloud 系统现在的运行情况如何？目前主要的工作重点是什么？

苏良飞：eBay 的 cloud 中跑着 4w+ 的物理机和 6w+ 的虚拟机，大部分流量都跑在 eBay Cloud 提供的虚拟机上。目前的工作重点是 OpenStack cloud 系统的扩展和可靠性：

1. Nova 扩展性
2. SDN 的应用
3. 如上提到的 eBay 自己研发的若干 OpenStack 模块