OceanBase云平台简介-白红宇

云计算是信息技术与服务在 交付领域 的重大进步。由于能够以自助、动态伸缩、可计量的方式对共享计算资源池的按需访问，云计算在成本、速度和效率方面具有无与伦比的优势。云计算是这样一种模型：有了它，可以方便地随时随地按需通过网络访问共享的可配置计算资源（如网络、服务器、存储、应用程序和服务）池，且只需最少的管理工作或服务提供方交互即可快速供应和释放这些资源。

尽管AWS早在2002年就出现了，但云计算目前仍然处于其生命周期的初期，过去几年云计算一直在推动各种技术趋势的发展与融合，这些技术趋势包括服务器虚拟化、集群、服务化、大规模管理自动化等等。秉承着云计算服务化的思想，面向开发者的各种技术设施首先被服务化，典型的如存储、数据库、消息队列、搜索引擎、并行计算等都成为了云产品，逐步建立了成熟的云计算生态。其中数据库服务(DBaaS)属于云生态中比较基础的产品。

OceanBase是一个自研的分布式关系型数据库，从2010年立项到现在已经发展了六年，承载了蚂蚁众多核心业务并经受了双11的考验，OceanBase主要有以下特性：

可扩展，分布式系统，支持ACID、无缝扩容，兼具分布式系统与关系型数据库的优点。

高可用，具备多可用区部署能力，可抵御少数可用区失败。强一致性同步，不丢失数据。

兼容MySQL协议。MySQL用户可以无缝切换。

支持多租户，在数据库进程层面作资源隔离，极高的资源整合度。

高性能，内存型数据库，充分利用SSD等新硬件。

OceanBase的诸多特性为DBaaS提供了良好的支持，但其本身仍然只是一个数据库内核，具有很高的使用门槛，OCP(OceanBase Cloud Platform) 致力于打造基于OceanBase的数据库服务(DBaaS)，降低用户使用OceanBase的门槛及成本，为用户提供高效、稳定、易用的OceanBase数据库服务。

本文主要描述OCP的设计实现以及功能：

云计算概述

数据库服务(DBaaS)的需求

OCP如何基于OceanBase来做数据库服务

OCP的使用

云计算概述

NIST(美国国家标准技术研究所)对云计算描述了五个重要特征、三种服务模型和四种部署方式。

五个重要特征

按需自助服务

用户可以根据需要供应、监视和管理计算资源，无需管理员的帮助。自助式访问为云计算带来的最大优势是响应速度，只需要几分钟(而非几周或数月)，用户就可以作好准备工作，还可以很快对计算容量作出调整。 在云计算出现以前，企业为了获取相应的IT资源，需要经过购买服务器、联系IDC、部署等各个流程，云计算极大的节省了企业前期在IT资源方面的时间与经济成本。

资源池化

IT资源以非专用方式为多个应用程序和多个用户所共享。通过资源池化，云计算服务提供商可以通过规模化的优势来降低成本，以给用户带来更成本更低的服务。用户也可以通过在软件内部实现资源共享而节省成本。

快速伸缩

IT资源可以按需快速伸缩。在传统方式里，扩容是一件很麻烦的事情，缩容基本上是一项不可能完成的任务，而在云计算里，扩容/缩容都可以简单的通过几个按钮或几个API来完成且即时生效。

按使用量收费的服务

对每个应用程序和每个用户跟踪IT资源使用情况并按使用量收费，相比传统方式，用户可以大幅度减少资源浪费，降低使用成本。

广泛的网络访问

通过标准网络和异构设备提供计算服务。

三种服务模型

软件即服务 (SaaS)

通常通过Web浏览器将应用程序作为服务提供给最终用户。比如小微金融云、阿里云医疗云。SaaS通常按承租方的用户数进行计费。

平台即服务 (PaaS)

将应用程序开发和部署平台作为服务提供给开发人员以使便其使用该平台构建、部署和管理应用程序。通常包括数据库、中间件和管理工具， 比如IBM的Bluemix。

基础设施即服务(IaaS)

作为服务提供计算服务器、存储和网络硬件。通常，这种基础架构的硬件是虚拟的。因此，虚拟化、操作系统和管理软件也是IaaS的一部份，比较著名的例子如OpenStack、EC2。

四种部署方式

私有云

供单个组织独家使用,通常由组织的IT部门进行控制、管理和托管。私有云的托管和运营也可能外包给第三方服务供应商,但是私有云仍为一个组织独家使用。

公有云

供多个组织(承租方)共享使用,由第三方服务供应商托管和管理。公有云是一种外包形式。资源共享的程度不尽相同,共享的资源可以包括部分或全部的 设施、网络、存储、计算服务器、数据库、中间件和应用程序。

社区云

供希望利用一个公共云计算环境的一组相关组织使用。例如,一个社区可 能由一些不同的军事机构、某个地区的所有大学或某个大型制造商的所有供货商所组成。比如阿里云的金融云就类似社区云的概念。

混合云

是指单个组织对单个应用同时采用私有云和公有云以便兼具两者之优势的 情况。例如,在“云爆发”的情形中,一个组织可能在私有云上运行某个应用的稳态负载,但是当负载骤升时(例如,每个财季末或节庆季节),可以突然开始使用公有云的计算容量,当不需要这些资源时再将它们退回给池。

DBaaS

数据库属于基础和专业化程度较高的IT资源，具有一定的使用门槛，在规模较大的组织，一般需要专门的DBA来部署、配置、监控及优化数据库的使用。应用开发者在使用数据库的时候也需要申请资源并提交SQL审核。传统数据库的使用存在一些问题：

部署成本高，一般需要经历采购硬件、配置硬件、部署硬件、部署数据库、配置数据库等各个环节。

运营成本高，数据库的运行与维护需要专门的人员，且当需求增长时需要重新配置整个体系。

资源利用率不佳，比如CPU、存储等资源。

服务较差，交付周期较长，没有明确的SLA。

DBaaS意在将数据库打造为：

具有前面所描述的云计算五个重要特征的服务。

将使用数据库所需要的专业能力以产品的形式输出，降低用户使用数据库的成本。

从而使应用开发者可以自助、专注使用数据库，不需要关注数据库本身的运行状况。 DBaaS会负责数据库部署、配置、安全、扩容、容灾、监控、调优、备份等一切关于数据库本身的工作并且对应用开发者透明。DBaaS的终极目标是用户不需要关注数据库，就像通过IaaS，云用户不需要关注服务器、网络和存储一样，应用使用DBaaS，应该不需要数据库方面的专家或者雇佣专业的DBA团队。

根据云计算与数据库的基本特点，要实现DBaaS，我们需要关注的几个点：

一是自助化服务。这可以说是云产品与其它产品最根本的区别。是云计算在交付领域所作出的巨大变革。这意味着用户可以随时按需获取和管理资源，无需管理员的帮助。这不是给个界面让用户点一点这么简单的事情，而是对我们后端整套系统在功能方面是否能满足用户需求、系统是否足够稳定的全面考验。这对OceanBase来说的挑战更大。

二是资源池化，这可以说是云产品的基本特征，所以现在很多人一提起云，就想到了虚拟化。资源池化我理解主要有两层意思：
- 一层是资源集中化管理，避免资源泛滥，让快速伸缩成为可能，通过规模优势来降低成本，提高利用率，所以这里就带来了规模化管理、提升资源利用率以及长期处于高水位运行的稳定性的问题。
- 另外一层是资源隔离和整合度的问题，资源要集中使用以扩大规模，但不能相互影响，这需要对资源进行隔离，同时又不能造成资源浪费，所以又有资源整合的要求。数据库的资源隔离一般有三种方式：
  - 服务器隔离，用户申请数据库的时候，会为其在专用的服务器(一般为虚拟机)上建一个专用的数据库Amazon和阿里云的RDS即采用这种形式，这种方式资源隔离级别较高，但整合度较低。
  - 数据库隔离，共享一个数据库实例或进程，由数据库内部进行资源隔离，这种整合度较高，资源隔离也较好，微软的Azure采用这种形式。
  - Schema隔离，这种形式比较受限，一般用于某个特定的SaaS，数据库层面不做资源隔离。
一般说来，不管是哪种隔离方式，用户可以申请的资源上限都受限于数据库所在的物理机的性能，如果所需资源超出一台物理机，则需要用户进行数据分片，这就涉及到数据分布和分布式锁的问题，在扩展上无法做一透明，给用户带来的极大的不便，目前的DBaaS普遍存在这个问题。

三是云产品有多种部署需求。不同的部署带来的是不同的托管模式，在公有云上，由公有云的提供者来托管，这一类人员往往会比较专业，比如对我们来说，可能就是我们的产品实现者自己管理，对于问题排查或故障处理有较多的经验。但对于私有云的部署，一般是由私有云所有者的IT人员来托管，这一类人员基本不具备脱离产品来排查问题的能力，这对我们产品的稳定性、管理员操作的易用性以及问题诊断是一个巨大的考验。

OceanBase Cloud Platform(OCP)

做OceanBase云平台主要有两个原因，一方面然是由业务需求催生，比如我们集团、蚂蚁的业务都需要跑在云上，另外一方面也是出于OceanBase自身需要，随着OceanBase的逐年宣传，OceanBase在业界也有了不小的知名度，常常有客户来问，我们是不是可以使用OceanBase啦，因为作为一个才发展了五年的关系型数据库来说，无论是在开发者社区还是在开发者认知上，和传统关系型数据库相比，都还有很大的不足，我们可以通云产品的形式来快速弥补这个差距。

OceanBase的一些功能为DBaaS提供了非常好的支撑：

多租户支持。OceanBase在数据库层面实现了资源隔离，让弹性扩容、缩容变得简单，同时具有很高的资源整合度。

可扩展。用户规格不再受物理机性能限制。

多可用区容灾及数据强一致，为了高可用， DBaaS一般会采用数据和节点冗余的方式，比如主备同步，但一般主备同步可能在某些情况下造成数据不一致，给用户带来麻烦。OceanBase在数据库层面解决了这个问题，以使得我们可以提供更好的DBaaS。

OCP的功能设计：

ocp_arch_function

整个OCP一共分为三层，最上层是用户功能层，OCP主要有两类用户：

使用OceanBase作为应用程序数据库的用户，典型的比如集团的开发者，在需要使用数据库的时候，可以通过OCP来自助创建实例，查看资源使用情况以及问题诊断等，而不需要管理员或DBA介入，这里对OceanBase有一个比较大的考验，相较于传统关系型数据库来说，OceanBase还比较年轻，在功能和生态上还比较欠缺，用户在开发阶段出现的问题不容易排查，这是OCP要重点考虑的事情。

云管理员，需要管理资源池，进行必要的扩容、缩容，检查风险，控制售卖情况以及异常处理。相比于开发者的需求，云管理员的需求通常被忽略，造成在专有云难以运维的问题，OCP在这方面做了大量的功能，以解决规模化运维的问题以及保障运行稳定性。

中间层为OCP服务层，将OCP的各项功能以API的形式暴露出来，上层功能统一使用API来完成。内部各模块以微服务的形式存在。

底层是数据库层，包含多可用区部署的OceanBase，以及在每台机器上部署的Agent以采集机器、网络和OceanBase的运行数据。

详细架构：

ocp_arch_big

左边我们称之为控制链路，主要解决用户和云管理员的自助化服务问题，右上部份数据链路，通过SLB/ObProxy提供自容灾的数据链路。右下部份为数据分析处理平台，通过采集实时运行信息，保障服务稳定性，提升资源利用率。

如何使用

OCP希望可以实现应用开发人员在日常开发、故障排查、性能监控等使用过程中的自助化，不需要管理员介入从而提升效率。同时通过规模化运维、实时信息收集、故障自动化处理、异常识别等手段来帮助管理员以更低的成本来管理大规模的集群并同时降低机器成本等。

我们在阿里云上的名称为，目前还在邀请测试中，如果你的业务需要使用OceanBase，以及有任何问题或建议，都可以联系我们。