一文详解新一代OceanBase云平台

OB君：9月21日，OceanBase 2.0 在云栖大会上重磅发布。咱们将在接下来的时间里为你们持续推出 “ OceanBase 2.0 技术解析系列” 文章，分别从 可运维性、分布式架构、数据可用性、性价比及兼容性 五个方面对OceanBase 2.0的产品新特性及其背后的技术原理进行深刻的解析。本文将带你全面解析新一代的OceanBase云平台，更多内容欢迎持续关注本系列！

本文做者：笑言

现任蚂蚁金服OceanBase团队技术专家，2014年加入阿里巴巴，从事领域涉及分布式事务中间件、中间件高可用，目前主要负责OCP 2.0系统的建设工做。

原文：

OceanBase云平台（OceanBase Cloud Platform，如下简称OCP）是一款专门用来管理OceanBase数据库集群的管控平台。经过OCP，能够一键安装、部署、升级OceanBase集群，监控集群的运行状态，建立和维护运维任务，而且对应用开发者透明。OCP伴随着OceanBase而诞生，至今已经从1.0全面进入2.0时代。

OCP 1.0由zookeeper、kafka、Jstorm、Hbase、OTS、OBAgent、obztools等十余个组件构成，各组件协同，在阿里巴巴集团内部，管控了超过5000个OceanBase服务节点，每秒处理监控指标超过100万次。

然而，功能和架构如此复杂的系统在向云转型的时候遇到了两个艰难的问题——部署成本高而且运维复杂。这两个问题对OceanBase的快速输出形成了巨大的障碍。在照搬集团内部技术架构的过程当中，系统的表现甚至不如某些开源系统。

问题老是能够在历史中找到答案。英特尔公司成立之初主营业务是半导体存储器芯片，不少年来，英特尔就是“存储芯片”的同义词。然而几年后，英特尔在本身开创的存储器领域被 5 家来自日本的电子公司甩到了后面。

图为英特尔三巨头，从左至右分别为安迪·格鲁夫、鲍勃·诺伊斯和戈登·摩尔

英特尔的两个创始人格鲁夫问摩尔，“ 若是咱们下台了，公司再任命一个新CEO，你以为他会怎么办？” 摩尔不假思索地回答，“他会放弃存储器业务。”，“那咱们为何不这么作呢？”。因此，诞生了全球最大的处理器巨头。

那么，对于OCP团队来讲，若是让咱们从新来架构OCP 2.0的话，咱们该怎么作呢？

1、场景的变化

1. 基础设施的变化

阿里集团基础设施包括了若干自建独立机房，机房之间经过高带宽低延时高效骨干网络相链接，即便跨城的机房之间网络传输丢包率也很低。

构建于高质量基础设施之上的开源组件，好比zookeeper，可靠性很高。然而，对于大多数企业级客户，有些是租用第三方机房，有些不具有三机房条件，基础网络的可靠性也不高，延时不稳定，开源产品运行故障率很高，OCP的SLA没法获得保证。

2. 业务的变化

众所周知，阿里双十一所面临的高并发场景是极端的，须要投入大量的基础设施资源、人力资源来保障系统的稳定运行。而外部业务因为其差别性，每每对基础设施的投入成本比较敏感。OCP的近十个组件的部署成本很高。

阿里集团因为其业务须要，好比HBase、JStorm等主流的开源产品都有专门的团队维护，专业的技术力量为OCP系统提供了强大的后背。而后，在外部输出的时候，OCP系统显得孤立无援。

综上两点，若干开源组件依赖，对OCP的可靠性带来了挑战，也引入了较高的部署成本。

2、OCP 2.0的诞生

OCP做为直接面向应用开发者的在线系统，同时承担了超大规模OceanBase集群的监控和运维工做。在对接企业级业务系统的场景下，至少须要具有如下能力：

• 对于在线系统，须要提供持续且稳定的高可用服务
• 对成本敏感的企业用户，要求OCP在占用少许机器资源的同时，提供高并发访问
• 尽量少的运维人员投入，要求系统可以实现无人值守
• 提供可定制、可扩展的产品能力，可在线升级

综上，OCP 2.0在架构设计上，进行了完全的自我革命，彻底抛弃了1.0时代对若干开源组件的依赖，OCP层面坚持去中心化的设计理念，将全部的状态信息集中到OceanBase数据库。

所以，带来的最直接的收益就是极大的缩短了服务链路，在架构层面保证了系统的运行质量，同时，去掉了开源软件的部署成本。

3、OCP 2.0解决方案

OCP 2.0由运维链路、监控链路、诊断链路、数据链路、高可用链路、基础设施等若干子系统。每一个子系统又切分红数十个甚至上百个小服务，每一个服务实现一个独立的业务逻辑，服务间弱依赖，带来了开发语言以及系统框架选择的灵活性。

1. 基础设施

考虑到外部场景的基础硬件多样性，OCP 2.0提供了统一资源调度层，将物理机、Docker、ECS等归入资源池统一管理，提供标准化接口屏蔽底层差别，并经过规模化来下降整体成本。同时，标准化IT资源，有利于完成应用服务的快速伸缩。

OCP 2.0统一计算平台提供了标准化的计算能力、任务编排能力，可根据简单定制完成实时、半实时、周期、定时等各种计算需求。支持各类计算任务，包括shell、python、java、http等，可以知足常见的计算需求，还支持将应用自定义的java、python等代码投递到计算平台，实现按业务需求对系统扩展。

2. 高可用链路

OCP 2.0对安全问题很是重视，引入了流量控制保证系统运行时安全，引入了租户隔离保证业务之间数据安全。同时，系统引入全链路跟踪机制，监控完整的服务流转路径，尽量缩短异常诊断路径，下降运维对人工介入的需求。

3. 运维链路

OCP 2.0承担了OceanBase集群、实例、租户、主机等维度的白屏化运维操做。不一样于集团内部有DBA团队承担全部数据库运维操做，外部每每按照组织结构或业务部门来划分数据库实例，各司其职，所以OCP 2.0划分了系统管理员、应用管理员、应用开发人员三个角色，每一个角色有各自的用户视角，每一个角色承担部分运维功能，不只符合用户行为，更加强了数据库安全性。

依托于统一计算平台，作到了运维任务的全程可监控。只要是运行于计算平台的计算任务，计算平台会分配一个独立的进程负责任务执行，同时，把运行时IO流、错误流实时推送到浏览器端，作到计算过程所见即所得。

4. 监控链路

OceanBase的监控对象包含集群、租户、服务节点、SQL等多个维度，包含上千个监控项，计算每个监控项都会记录若干乃至上百条监控日志。OCP 2.0将监控信息存储到OceanBase数据库，可以使用日志副原本尽量下降存储成本。

OCP 2.0提供了灵活的监控指标定制能力。在以往的存储模型选型中一般会遇到宽窄表的选择，若是采用宽表做为监控存储模型，一旦监控指标发生变化，会形成锁表；若是采用窄表，能够较好应对指标变化，可是会形成储存空间的浪费，不够经济，而且监控指标变化会引发计算逻辑变化，系统维护成本高。OCP 2.0利用了OceanBase增量数据写内存、按期转储的特性，采用宽表做为监控指标存储模型，同时DDL不锁表。

5. 诊断链路

OCP 2.0将集团内部沉淀已久的智能数据库诊断优化产品以及集团DBA的数据库优化经验集成，以统一视角展现。提供了数据库资源的诊断与建议、SQL诊断与优化、慢SQL诊断等经常使用功能。

6. 数据链路

OCP 2.0提供了经常使用的数据备份、恢复、历史库等功能。并与ODC、OMS等系统集成，提供了数据导入导出、DDL导入导出，以及数据全量、增量迁移等功能，可作到在不停机的状况下，将mysql、oracle等主流关系数据库数据导入OceanBase。

结语

OCP 2.0的架构思路是去依赖、去状态，以及尽量缩短服务请求的执行路径。在知足高并发、高性能、高可用的基础上，可以快速输出；而且开放了Open-SDK，给了应用参与到OCP插件开发、快速适配业务变化的能力。

架构是一种平衡的艺术，而最好的架构一旦脱离了它所适应的场景，一切都是空谈。OCP 2.0去掉了kafka、jstorm等计算平台，实时性相对变差了，可是仍然在可接受范围内，换来的是大幅下降了资源占用成本以及提高了系统可用性，整体来讲，得远大于失。

加入咱们：

OceanBase 现诚聘云平台研发专家/架构师、云产品研发专家/算法专家，感兴趣的同窗能够直接发送简历到 OceanBase-Public@list.alibaba-inc.com，咱们等的就是你！