本文首发于2018年。
作者：笑言，蚂蚁金服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. 基础设施的变化。
阿里集团基础设施包括了若干自建独立机房，机房之间通过高带宽低延时高效骨干网络相连接，即使跨城的机房之间网络传输丢包率也很低。构建于高质量基础设施之上的开源组件，比如zookeeper，可靠性很高。然而，对于大多数企业级客户，有些是租用第三方机房，有些不具备三机房条件，基础网络的可靠性也不高，延时不稳定，开源产品运行故障率很高，OCP的SLA无法得到保证。
2. 业务的变化。
众所周知，阿里双十一所面临的高并发场景是极端的，需要投入大量的基础设施资源、人力资源来保障系统的稳定运行。而外部业务由于其差异性，往往对基础设施的投入成本比较敏感。OCP的近十个组件的部署成本很高。阿里集团由于其业务需要，比如HBase、JStorm等主流的开源产品都有专门的团队维护，专业的技术力量为OCP系统提供了强大的后背。然后，在外部输出的时候，OCP系统显得孤立无援。
综上，若干开源组件依赖，对OCP的可靠性带来了挑战，也引入了较高的部署成本。
OCP 2.0的诞生
OCP作为直接面向应用开发者的在线系统，同时承担了超大规模OceanBase集群的监控和运维工作。在对接企业级业务系统的场景下，至少需要具备以下能力：
- 对于在线系统，需要提供持续且稳定的高可用服务。
- 对成本敏感的企业用户，要求OCP在占用少量机器资源的同时，提供高并发访问。
- 尽可能少的运维人员投入，要求系统能够实现无人值守。
- 提供可定制、可扩展的产品能力，可在线升级。
OCP 2.0在架构设计上，进行了彻底的自我革命，完全抛弃了1.0时代对若干开源组件的依赖，OCP层面坚持去中心化的设计理念，将所有的状态信息集中到OceanBase数据库。因此，带来的最直接的收益就是极大的缩短了服务链路，在架构层面保证了系统的运行质量，同时，去掉了开源软件的部署成本。
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等计算平台，实时性相对变差了，但是仍然在可接受范围内，换来的是大幅降低了资源占用成本以及提升了系统可用性，总体来说，得远大于失。
