oceanbase云平台（下面简称OCP）是一个专门用于管理oceanbase数据库集群的控制平台。通过OCP，oceanbase集群可以一键安装、部署和升级，监控集群的运行状态，创建和维护运行任务，并对应用程序开发者透明。OCP诞生于oceanbase，从1.0全面进入2.0时代。

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

然而，在向云转型过程中，功能和结构如此复杂的系统遇到了两个困难的问题——部署成本高，运行维护复杂。这两个问题极大地阻碍了oceanbase的快速输出。在复制集团内部技术结构的过程中，系统的性能甚至不如一些开源系统。

所以，对OCP团队而言，如果让他们重新建立OCP2.0，该怎么办？

一、场景的变化

1、基础设施的变化

阿里集团的基础设施包括几个自建独立机房，通过高带宽、低延迟、高效的骨干网络连接机房。即使是跨城机房，网络传输的丢失率也很低。

开源组件，如zookeeper，构建在高质量的基础设施上，具有很高的可靠性。但对于大多数企业级客户来说，有的是租第三方机房，有的不具备第三方机房条件，基础网络可靠性低，延迟不稳定，开源产品运行故障率高，无法保证OCP的SLA。

2、业务变化

众所周知，阿里双十一面临的高并发场景是极端的，需要投入大量的基础设施资源和人力资源来保证系统的稳定运行。然而，由于其差异，外部业务往往对基础设施的投资成本敏感。OCP最近十个组件的部署成本非常高。

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

综上所述，一些开源组件依赖，对OCP的可靠性提出了挑战，同时也引入了较高的部署成本。

二、OCP2.0的诞生

作为一个直接面向应用开发者的在线系统，OCP承担了对超大型oceanbase集群的监控和运营维护。对接企业级业务系统时，至少需要具备以下能力：

1、对在线系统而言，需提供持续稳定的高可用性服务。

2、对于成本敏感的企业用户，要求OCP提供高并发访问，同时占用少量机器资源。

3、运维人员投入尽可能少，要求系统能实现无人值守。

4、提供可定制、可扩展的产品能力，可在线升级。

总之，OCP2.0在架构设计上，进行了彻底的自我革命，完全抛弃了1.0时代对一些开源组件的依赖，坚持OCP层面的分散设计理念，将所有状态信息集中在oceanbase数据库上。

所以，最直接的好处就是大大缩短了服务链接，在架构层面保证了系统的运行质量，同时，消除了开源软件的部署成本。