从零开始搭建MongoDB数据库服务？

数据库即服务』其实可以认为是PaaS的一种变种，主要关注点在数据库上，客户不再需要去自己部署数据库，而是只需要按需使用由服务提供商提供的数据库即可，数据库的维护都交给服务提供商来完成，这样客户只需关注应用本身即可。

_MongoDB_008_jpeg

我们来具体看一下使用『数据库即服务』和原来有什么不同，这里除了列举传统全部DIY的方式之外，还对比了一种利用IaaS来自建数据库的方式，这也是现在比较常见的一种做法。我们看到传统方式，需要做很多事情，这当中还需要涉及多个团队来协作，非常不容易。然后看看第二种方式，利用IaaS来自建，这里以阿里云的云服务器ECS为例，这种方式和刚刚相比，省了不少事，但是仍然是比较麻烦的，也可能还需要涉及跨团队协作。我们再来看看如果是使用『数据库即服务』呢？只需要点下页面上的部署按钮，就可以等着用了，已经进化为完全自助服务了。从时间上来看，第一种方式可能需要花费数月，第二种可能需要花费数天，第三种则只需要数小时即可。可见『数据库即服务』的优势还是很明显的。

_MongoDB_009_jpeg

所以说为什么要『即服务』，其实是一个进化的趋势。我们经常说人不能太懒，但是懒这个字用在程序猿身上可能并不是不好的东西，因为懒，促使我们会去自动化。最早我们通过人肉操作，下载软件，编译部署，然后配置。有一天我们发现经常需要这么干很累很浪费时间，就开始写脚本来完成这些操作，生产力开始提高。等到规模更大的时候，比如要同时管理数十台数百台机器，这时候可能分发脚本也嫌麻烦了，开始写一些自动化的工具来做这个事情。到最高级阶段，就是完全实现自助服务，这是懒的最高境界。

_MongoDB_010_jpeg

MongoDB简介 说完了『即服务』以及其重要性，接下来我们看一下今天的另一个主角：MongoDB，因为有些同学可能对这个不了解，所以还是简单介绍一下。

_MongoDB_011_jpeg

首先，MongoDB是什么呢，它是一个Document Store，文档型数据库，也是我们经常说的NoSQL。根据DB-Engines的数据库排名，MongoDB长期霸占着NoSQL老大的地位，现在是数据库界一位重量级选手。

_MongoDB_012_jpeg

事实上，MongoDB可以称为是一种NewSQL，它融合了传统关系型数据库和NoSQL的一些优点。最左边的3个能力是来自于关系型数据库。首先，它具备丰富的查询语句和二级索引。通过这点，用户可以以足够复杂的方式来访问和组织数据。第二点，强一致性。MongoDB支持一个灵活的一致性模型。你可以选择使用强一致性，或最终一致性，取决于你的业务场景。第三点，MongoDB能很好的集成到多企业现有技术架构中。右边3个能力 来自NoSQL，首先是灵活的数据模型，MongoDB的文档模型允许动态修改schema，不用担心有任何的性能影响。其次是高性能和高可扩展性，MongoDB可以轻松进行水平扩展，从而带来更高的吞吐和更低的延迟。最后，是全球部署，也就是高可用。接下来我们就来具体讲下MongoDB的几个关键特性。

_MongoDB_013_jpeg

MongoDB的关键特性主要是3个，第一个就是灵活动态的文档模型，第二个是高可用副本集，第三个是MongoDB的水平扩展，也就是sharding。

_MongoDB_014_jpeg

MongoDB以一种叫做BSON（二进制JSON）的存储形式将数据作为文档存储。具有相似结构的文档通常被组织成集合。可以把集合看成类似于关系数据库中的的表：文档对应的是行，字段对应的是列。 MongoDB将一条记录的所有数据聚合在一个文档中，而在关系数据库中则倾向于将数据分布在多个表中。这样做有几个好处，一是由于数据聚集，减少了多表JOIN的需求，这样只需要读一次就可以读到所有数据，在性能上会有很大优势。 另外，这种模型更加接近我们平时编程语言中的对象结构，可以方便开发者进行数据映射。 最后就是这种模型是schema-less的，也就是在MongoDB中不需要像关系数据库一样去事先定义每个表的schema。MongoDB一个集合内的文档之间可以拥有不同的结构，可以轻松为一个新的文档添加和减少字段，不会有任何的性能影响。这个特性非常适合开发一些新产品，可以快速迭代。 当然，过于灵活就可能导致混乱。有时候我们想要求文档必须要有某些字段，某些字段必须要有固定的类型。为此，MongoDB提供了一个文档验证功能来对文档的格式进行约束。

_MongoDB_015_jpeg

接下来说MongoDB的第二个关键特性，高可用副本集（也可以翻译成复制集）。 Mongodb副本集由一组Mongod实例（进程）组成，包含一个Primary节点和多个Secondary节点，Mongodb Driver（客户端）的所有数据都写入Primary，Secondary从Primary同步写入的数据，以保持副本集内所有成员存储相同的数据集，提供数据的高可用。

上图是一个典型的Mongdb副本集，包含一个Primary节点和2个Secondary节点。 副本集通过replSetInitiate命令（或mongo shell的rs.initiate()）进行初始化，初始化后各个成员间开始发送心跳消息，并发起Primary选举操作，获得『大多数』成员投票支持的节点，会成为Primary，其余节点成为Secondary。 这里『大多数』的定义是副本集内可投票成员的一半以上，当副本集内存活成员数量不足大多数时，整个副本集将无法选举出Primary，此时副本集将无法提供写服务，处于只读状态。通常建议将副本集成员数量设置为奇数，因为偶数个节点能容忍的节点失效和比他少1个节点的奇数个节点是一样的，但是可以节省一个节点的数据存储成本。

除了初始化的时候会进行选举，MongoDB副本集的高可用服务体现在，当副本集中没有Primary节点时，选举都会进行。比如当Primary节点宕机时，剩下的Secondary节点中会选举出新的Primary（只需要满足大多数成员存活的条件）。选举使用的算法是基于Raft协议，但是可以通过为节点配置选举优先级对选举结果进行控制。

此外需要提一下，有一些比较常见的特殊的Secondary。一个是Hidden，Hidden节点和普通的Secondary的区别是它是对Driver隐藏的节点，也就是客户端无法访问到Hidden，另外就是它的选举优先级是0，也就是它不能被选举为Primary。Hidden节点上拥有数据，因此通常会用来作一些运维任务，如数据备份、计算分析等。 另外还有一个是Arbiter，Arbiter是只参与投票，但是不存储数据的节点，这可以用在对可用性有要求，又要严格控制成本的场景。 此外还有如Priority0节点、Delayed节点等。

_MongoDB_016_jpeg

MongoDB提供了一种水平扩展的方式，叫做sharding，通过这种方式对数据库进行扩容，对应用是透明的。通过sharding，可以将一个集合的数据散到多个shard节点上。这里每个shard都可以是一组副本集。应用程序通过一个路由节点（mongos）来访问sharding集群的数据。有了sharding，mongodb就可以突破单机的限制，比如磁盘、内存和IOPS等，从而提供更强大的服务能力。

_MongoDB_017_jpeg

Sharded cluster由Shard、Mongos和Config server 3个组件构成。Mongos本身并不持久化数据，Sharded cluster所有的元数据都会存储到Config Server，而用户的数据则会分散存储到各个shard。Mongos启动后，会从config server加载元数据，开始提供服务，将用户的请求正确路由到对应的Shard。 Sharded cluster支持将单个集合的数据分散存储在多个shard上，用户可以指定根据集合内文档的某个字段即shard key来分布数据，目前主要支持2种数据分布的策略，范围分片（Range based sharding）或hash分片（Hash based sharding）。 范围分片下，文档是根据其shard key的值进行分片。shard key的值相邻近的文档比较有可能会被放在同一个shard上，这种方式适用于需要使用范围查询的业务。 哈希分片下，文档根据其shard key的hash值进行分片。这会保证数据分布比较均匀，但是不利于范围查询。 随着数据量的增多，MongoDB也会自动在后台对数据以chunk为单位进行负载均衡。

_MongoDB_018_jpeg

如何搭建一个MongoDB『数据库即服务』 接下来介绍一下今天的重点内容，如何搭建一个MongoDB数据库即服务。

_MongoDB_019_jpeg

首先，在我看来，数据库即服务，应该具备这些特性：自动化、按需服务、弹性、安全、高可用和可量化。第一个，自动化，这是非常关键的，是实现自助服务的基础，所有可以被自动化操作的流程都应该被自动化，不需要人工干预。第二个，按需服务，数据库即服务应该是由用户驱动的，后台应该要有一个工作流的机制来对需求进行响应。第三个，弹性，可以按需动态扩缩容。第四个，安全，这是毋庸置疑的。第五个，高可用，宕机自动切换。第六个，可量化，服务的使用量可以被衡量、报告并且是可控的。

_MongoDB_020_jpeg

此图为数据库即服务应具备的功能大图。主要包括生命周期管理、容灾体系、监控报警、数据管理和增值服务。生命周期管理包括数据库实例的新建、释放、扩缩容等，这是数据库即服务最基础的功能。容灾体系包括高可用、备份恢复，甚至更高级的如异地容灾/多活等等。监控报警一方面就是服务使用量的监控，另一方面则是报警，包括服务不可用的报警，以及一些监控数据异常的报警。数据管理指的就是可以方便的对数据进行管理，如可以提供一些图形化界面等。增值服务包括审计、诊断服务等。其中审计是数据库的一个非常重要的功能，一方面可以帮助查证问题，另一方面可以为一些数据分析或诊断提供数据源。诊断服务一方面跟踪服务的资源使用量，为是否需要扩缩容提供决策依据，另一方面主要为慢查询提供优化建议。

_MongoDB_021_jpeg

数据库即服务的核心架构就是工作流引擎，这是实现自动化及按需服务的基础。

_MongoDB_022_jpeg

生命周期管理功能包括数据库实例的新建、释放、扩缩容以及迁移。新建一个数据库实例包括分配资源（主要是主机资源）、安装数据库、初始化配置。对MongoDB来说，副本集涉及多个节点，涉及到资源的分配策略，Sharding更多。另外副本集还需要一些初始化工作，sharding需要有一个各组件的组合。释放实例比较简单，主要是资源的回收。扩缩容可以分为本地和跨机的扩缩容，其实跨机的扩缩容就是迁移。对于MongoDB来说，迁移可以直接利用MongoDB的添加节点自动同步的特性，还是比较方便的。

_MongoDB_023_jpeg

生命周期管理功能主要涉及这几个组件，包括资源管理、规格及配置管理、软件栈管理和负载均衡。资源管理主要是指主机资源的管理，这里主机可以是物理机，也可以是虚拟机，如云主机等。资源管理主要负责资源的分配和回收，此外还包括如何实施资源隔离。规格及配置管理一个是需要为数据库实例制定一些规格，以方便扩容和缩容，另一方面是负责数据库相关配置的维护。软件栈管理则包括数据库软件以及其依赖的软件的安装维护等，包括操作系统。除了这些，还需要一个负载均衡组件来保证数据库实例在资源上的分布的均衡，当有主机资源需要下线的时候，能够做到自动对其上的数据库实例进行迁移。

_MongoDB_024_jpeg

对于MongoDB来说，在实施资源分配策略时需要注意的一点是需要保证不要破坏副本集原本的高可用特性。虽然MongoDB副本集自带了高可用，但是如果你把副本集的所有节点都分布在一台物理机上，那如果这个物理机挂了，整个副本集都没用了。所以一个起码的原则是要保证MongoDB多副本的主机安全性，尽可能够做到机架安全。

_MongoDB_025_jpeg

现在我们的MongoDB数据库即服务的架构可以稍微扩充一下了，多了资源服务、规格及配置服务、软件栈服务以及负载均衡服务这几个组件。

_MongoDB_026_jpeg

接下来看一下容灾体系，这包括高可用、备份/恢复、异地容灾/多活。高可用需要有一个负责健康检查的巡检服务，另外还需要有一个容灾切换的组件。备份/恢复也是容灾体系非常重要的一环，这里有一个很容易被忽视的事情是需要做备份的有效性验证。如果备份不是有效的，那等于没有备份。异地容灾/多活是比较高级的容灾能力，实施起来比较复杂，有兴趣的同学可以参考我之前做过的一个分享 MongoDB异地容灾多活实践

_MongoDB_027_jpeg

MongoDB副本集自带了高可用，我们还需要做什么工作呢？主要是需要保证容灾切换的一个可控。以一个经典的3节点P/S/H副本集为例，一方面我们可以通过配置选举优先级的方式来保持Primary和Secondary的角色稳定性。另一方面，我们希望在任意时刻，用户都可以有两个节点是可访问的，因此我们需要对节点宕机后的副本集做一些reconfig操作，保证宕机节点最终都会变成Hidden，然后统一对Hidden进行处理，比如重搭等。

_MongoDB_028_jpeg

容灾体系第二个比较重要的点就是备份恢复。备份主要需要做的是需要提供自动/手动的备份方式以及支持一些灵活的备份策略制定，如备份周期/备份保留时间等。恢复主要是看对恢复的形态做成什么样，是覆盖原来的实例还是克隆出一个新的实例来，还有就是恢复的粒度，这取决于备份能力，是只能恢复到某个全量备份，还是可以恢复到任意时间点。关于备份存储，我们要求的最要 能力是高可靠性。另外就是刚刚提过的备份有效性验证，不能等到火烧眉毛了才发现备份不可用，需要防范于未然。

_MongoDB_029_jpeg

​​关于MongoDB的备份方法，相关的文档和分享已经有很多了，这里再简单提一下。全量备份从实施方式上可以分为两种，逻辑备份和物理备份。其中逻辑备份主要使用官方提供的mongodump/mongorestore工具。物理备份则可以在文件系统或是更底层的逻辑卷、块设备这层去做。

_MongoDB_030_jpeg

从各个指标上对比逻辑备份和物理备份，在备份和恢复效率上，物理备份的优势比较明显，不过逻辑备份在兼容性上会比较好。

_MongoDB_031_jpeg

MongoDB的增量备份主要通过持续的抓取oplog来实现。有了全量备份加增量备份，就可以实现恢复到任意时间点。

_MongoDB_032_jpeg

至此，我们的MongoDB数据库即服务的架构又可以得到一个比较大的扩充，主要增加了高可用以及备份相关的一些服务。

_MongoDB_033_jpeg

接下来看下数据库的监控报警，性能监控​主要涉及性能数据的采集、存储和展示。采集粒度越细越好，最好能做到秒级。报警则可以分为可用性的报警和性能数据的报警。

_MongoDB_034_jpeg

具备监控报警能力后的架构图已经有点满了，这里报警服务可以通过巡检服务和性能数据存储收集相关数据。

_MongoDB_035_jpeg

来看最后一个增值服务，一个是审计，主要涉及审计日志的采集、存储和分析。另一个是诊断服务，一个是资源使用量上的诊断，另外一个是慢查询的诊断，可以做一些索引推荐等。

_MongoDB_036_jpeg

这就是我们的MongoDB数据库即服务的完整架构，可以看到组件还是比较多的，做一个数据库即服务还不是那么容易哈。

_MongoDB_037_jpeg

​​​​​​最后做一下总结，我认为数据库即服务的核心特性有两点，一个是资源池化，另外一个是服务可量化。资源池化后才可以进行资源的自动管理，而我们需要的服务是要能够被量化的，并且是可控的。现在回顾一下之前的一键安装数据库，其实背后有许多工作要做。这里顺便做下广告，如果觉得自己搭建一个数据库即服务太麻烦，可以考虑使用现成的云服务，比如阿里云MongoDB数据库服务：）你想要的全都有！