OceanBase云平台1.0由zookeeper、kafka、Jstorm、Hbase、OTS、OBAgent、obztools等十多个组件组成。所有组件相互配合，在阿里巴巴集团内部，它控制着超过5000个OceanBase服务节点，每秒处理监测指标超过100万次。
然而，具有如此复杂功能和架构的系统在过渡到云的过程中遇到了两个难题——高部署成本和复杂的运维。这两个问题对OceanBase的快速产出造成了很大的阻碍。在复制集团内部技术架构的过程中，系统的性能甚至不如一些开源系统。
问题总是可以在历史中得到解答的。成立之初，英特尔的主营业务是半导体存储芯片。多年来，英特尔一直是“内存芯片”的代名词。然而，几年后，英特尔在自己的内存领域被来自日本的五家电子公司甩在了后面。
图为英特尔三巨头，从左至右分别是安迪·格鲁夫、鲍勃·诺伊斯和戈登·摩尔。
英特尔的两位创始人Gruff问摩尔：“如果我们下台，公司任命新的CEO，你认为他会怎么做？”摩尔不假思索地回答：“他会放弃内存业务。”“那我们为什么不做呢？”。于是，世界上最大的处理器巨头诞生了。
那么，对于OceanBase云平台团队来说，如果重新架构OCP 2.0，我们应该怎么做？
一、场景的变化
1、基础设施的变化
阿里的基础设施包括多个自建的独立机房，通过高带宽、低时延、高效的骨干网连接。甚至跨城市机房之间的网络传输丢包率都很低。
构建在高质量基础设施上的开源组件，比如zookeeper，是高度可靠的。但对于大多数企业客户来说，有的租用第三方机房，有的没有三个机房，基础网络可靠性不高，延迟不稳定，开源产品故障率高，无法保证OceanBase云平台的SLA。
2、业务的变化
众所周知，阿里双十一面临的高并发场景是极端的，需要投入大量的基础设施资源和人力资源来保证系统的稳定运行。由于其差异，外部企业通常对基础设施的投入成本非常敏感。OceanBase云平台近十个组件的部署成本非常高。
由于业务需要，阿里巴巴的主流开源产品如HBase、JStorm都有专门的团队维护，专业的技术力量为OceanBase云平台系统提供了强大的后盾。于是，当对外输出时，OCP系统显得束手无策。
综上所述，几个开源组件相互依赖，对OceanBase云平台的可靠性提出了挑战，引入了很高的部署成本。
二、OceanBase云平台 2.0的诞生
OCP作为直接面向应用开发者的在线系统，还承担着超大规模OceanBase集群的监控和运维工作。在对接企业级业务系统的场景中，至少需要具备以下能力：
对于在线系统，需要提供连续稳定的高可用性服务。
对成本敏感的企业用户需要OceanBase云平台在占用少量机器资源的同时提供高并发访问。
操作和维护人员的投资越少越好，系统需要无人值守。
提供可定制、可扩展的产品功能，可以在线升级。
综上所述，OceanBase云平台2.0彻底革新了其架构设计，彻底抛弃了1.0时代对一些开源组件的依赖。OCP坚持分散化的设计理念，将所有状态信息集中在OceanBase数据库中。
所以最直接的好处就是大大缩短了服务环节，在架构层面保证了系统的运行质量，同时免去了开源软件的部署成本。
三、OceanBase云平台2.0解决方案
OCP 2.0由运维链路、监控链路、诊断链路、数据链路、高可用链路、基础设施等几个子系统组成。每个子系统又分为几十个甚至上百个小服务，每个服务实现一个独立的业务逻辑。服务之间的弱依赖带来了开发语言和系统框架选择的灵活性。
1、基础设施
考虑到外部场景基础硬件的多样性，OceanBase云平台2.0提供了统一的资源调度层，集成了物理机、Docker、ECS等。纳入资源池的统一管理，提供标准化接口以屏蔽底层差异，并通过扩展降低总体成本。同时，规范IT资源有利于应用服务的快速扩展。
OceanBase云平台2.0统一计算平台提供标准化的计算能力和任务调度能力，可根据简单定制完成实时、半实时、周期性、定时等计算需求。它支持各种计算任务，包括shell、python、java、http等。，可以满足常见的计算需求。还支持将应用定义的java、python等代码交付给计算平台，以便根据业务需求对系统进行扩展。
2、高可用性链接
OceanBase云平台2.0非常重视安全问题，引入流量控制保证系统运行时的安全性，引入租户隔离保证业务间的数据安全。同时引入全链路跟踪机制，监控完整的业务流程路径，尽可能缩短异常诊断路径，减少运维人工干预。
3、操作和维护链接
OceanBase云平台2.0承担OceanBase集群、实例、租户、主机等维度的白屏运维。与DBA团队承担所有数据库运维的小组不同，外部数据库实例往往按照组织架构或业务部门进行划分，各司其职。因此，OCP 2.0分为三个角色：系统管理员、应用管理员和应用开发者。每个角色都有自己的用户视角，每个角色承担一些运维功能，既符合用户行为，又增强了数据库安全性。
依托统一计算平台，可对运维任务进行全流程监控。只要是运行在计算平台上的计算任务，计算平台都会指派一个独立的进程负责任务执行。同时，运行时IO流和错误流会实时推送到浏览器，让你在计算过程中所见即所得。
4、监控链接
OceanBase的监控对象包括集群、租户、服务节点、SQL等多个维度，包括上千个监控项目。每个监控项目会记录几个甚至上百个监控日志。OceanBase云平台2.0将监控信息存储在OceanBase数据库中，可以使用日志拷贝来尽可能降低存储成本。
OceanBase云平台2.0提供了自定义监控指标的灵活能力。在以往的存储模型选择中，经常会遇到宽窄表的选择。如果使用宽表作为监控存储模型，一旦监控索引发生变化，该表将被锁定。如果采用窄米，可以更好的应对指标变化，但是会造成存储空间的浪费，不够经济。而且监控指标变化会引起计算逻辑的变化，系统维护成本高。OCP 2.0利用OceanBase增量数据写入内存并定期转储的特点，采用宽表作为监控索引存储模型，而DDL不锁表。
5、诊断链接
OceanBase云平台2.0整合了集团内部由来已久的智能数据库诊断优化产品和集团DBA的数据库优化经验，以统一的视角呈现。提供数据库资源诊断和建议、SQL诊断和优化、慢SQL诊断等常用功能。
6、数据传输器
OceanBase云平台2.0提供常用数据备份、恢复、历史数据库等功能。与ODC、OMS等系统集成，提供数据导入导出、DDL导入导出、数据整体和增量迁移等功能。它可以在不停机的情况下将mysql、oracle等主流关系数据库数据导入OceanBase。
OCP 2.0的架构思想是尽可能地去依赖、去状态和缩短服务请求的执行路径。在高并发、高性能、高可用的基础上，快速输出；并且开放了Open-SDK，让应用能够参与OceanBase云平台 plug-in的开发，快速适应业务变化。
建筑是一门平衡的艺术，一旦最好的建筑脱离了它所适应的场景，一切都是空谈。OceanBase云平台2.0去掉了kafka、jstorm等计算平台，实时性能相对较差，但仍在可接受范围内。作为交换，资源占用成本大大降低，系统可用性提高。总的来说，得远大于失。
