作者介绍：沈炼，蚂蚁数据部数据库内核负责人。2014年入职蚂蚁，承担蚂蚁集团的数据库架构职责，先后负责了核心链路上OceanBase、OceanBase高可用体系建设、NoSQL数据库产品建设。沈炼对互联网金融、数据库内核、数据库高可用体系等领域有着深厚的理解。沈炼秉承“止于至善”的理念，深耕互联网金融和数据库两个专业方向，保持着十年如一日的热情与专注。
背景
何为“数据库服务”，我的理解是一种交付形态。数据库产品是指用于存储和管理数据的计算机软件系统，软件是其交付形态，在线业务常用的数据库产品包括关系型数据库和NoSQL。而数据库服务指将数据库产品以访问接口的形态交付到用户(也就是在线业务)，并维持其稳定且安全的运行。相比于数据库产品，数据库服务具有更长的生命周期和更多的技术内涵，除了数据库产品本身的可靠性，还需要接入的简易性、运行的稳定性、数据的安全性和合规性、成本的可控性等。
因此，互联网“在线业务”对“数据库服务”有着独特的技术诉求，需要对业务工作负载和数据库产品特性有着深刻的理解。然而脱离于互联网平台之外，很少有这方面的专门阐述，本文正是试图弥补这一缺憾。我们将围绕蚂蚁业务场景阐述什么是对互联网“在线业务”友好的“数据库服务”，本文的技术主张也适用于其他的互联网平台业务。
水平伸缩
随着互联网的持续爆发和移动互联网的兴起，支付宝作为一款优秀的国民App，流量屡创新高，极大考验了整套后端系统的水平伸缩性。
蚂蚁的应用架构经历了数代发展，从第一代的集中式架构，到第二代的分布式架构，再到第三代的自研平台的架构、第四代的云平台架构、第五代的云原生架构，每代架构都有着不同的业务使命和技术使命，但“弹性”始终作为基本课题贯穿其中。蚂蚁也长出了SOFAStack这样的代表应用层的分布式产品，使得应用代表的无状态服务层具备了可伸缩、可扩展的能力。但数据库代表的有状态服务层的伸缩性具有着更高的难度和技术挑战，需要解决扩展性、一致性、高可用、高性能等难题。
关系数据库最显著的特征是ACID，给应用程序提供了数据一致性、数据完整性和数据持久性的语义。在海量流量的冲击下，单机数据库受限于单机资源很快出现性能瓶颈和容量瓶颈，分布式中间件和分布式数据库提供了不同层次的解决方案。
分布式中间件位于应用系统和数据库集群之间，遵循数据库通信协议和SQL标准。截获客户端发往数据库的SQL请求，并进行解析和转发，根据数据的分布规则发送到对应的数据库实例。接受数据库实例返回的执行结果，解析后转发至对应的客户端。分布式中间件通过这种解析并转发请求的方式，将应用流量分发到多个数据库实例上，减轻了每个数据库实例上的应用流量，从而突破了单数据库实例的性能瓶颈和容量瓶颈。业界的分布式中间件产品有Cobar、MyCAT、DRDS等，蚂蚁的中间件产品则是ZDAL、DDS。
在分布式数据库的具体实现中，关系型数据库和NoSQL有着不同的技术路径和不同的对应用层的语义呈现：
分布式数据库在解决了水平伸缩性的同时，还提供了更好的高可用能力。例如OceanBase，能够在少数派副本故障时提供RPO=0、RTO<30秒的高可用SLA，这是传统关系型数据库完全无法想象的。
对于蚂蚁的在线业务，端到端的水平伸缩性是一个必选项，蚂蚁的数代应用架构演进也体现了这点。对于数据库服务，必须从设计之初就把水平伸缩性纳入设计目标之中。不具备水平伸缩性的数据库服务一定不业务友好。
应用敏捷
蚂蚁包罗万象的业务场景产生了丰富多样的数据库服务诉求。金融业务产生的交易数据;搜广推业务产生的圈人数据;安全业务产生的用户行为数据;消费金融业务产生的风控数据;AI业务产生的训练数据;小程序云业务产生的社交数据和移动应用数据;短视频业务产生的多模态内容数据;监控业务产生的指标数据等。多样化数据产生的诉求是灵活的数据模型和数据操作，关系型数据库提供的关系模型面对这种场景时举步维艰。
我们不能也不应该淹没在各种业务数据的细节里，却忽视了对问题本质的思考和理解。多样化数据的存储诉求的底层逻辑是“数据不应该被存储形式束缚”，传统的关系型数据库定义了关系模型和SQL接口，这种范式并不能适用于所有的数据场景，新型数据模型、访问接口和数据架构呼之欲出。应用程序需要新的数据范式来解放自身，就像半个世纪前关系模型将应用程序从处理数据的物理存储结构的繁文缛节中解放出来一样，这就是应用敏捷性。
数据模型
数据模型是对数据库的存储结构和语义的描述，是对现实世界数据特征的抽象。数据模型在应用程序和数据库之间建立了一座桥梁，屏蔽了数据在数据库如何储存的细节，并向应用程序提供数据的抽象视图。恰当的数据模型能够极大简化应用程序的数据逻辑，避免应用开发者陷于处理业务数据与数据库数据模型之间不匹配的问题。传统关系型数据库提供了关系模型的数据语义，而现代NoSQL则提供了很多非关系模型的数据语义，包括KV模型、宽表模型、文档模型、图模型、时序模型等。数据库的数据语义突破数据模型的束缚以更匹配业务数据表示的形式呈现是一种应用敏捷性。
基础技术栈
数据模型是一种应用敏捷性，基础技术栈(包括应用开发栈和应用工具栈)是另一种应用敏捷性。基础技术栈提供了标准构建模块，使得应用开发可以直接在其上构建应用程序，免去了使用胶水组件将多种独立组件粘合在一起的额外投入，我们以MEANStack和TICKStack来举例。
我们上面介绍的基础技术栈都是以NoSQL作为核心的(MongoDB@MEAN、InfluxDB@TICK)，面向特定场景或特定行业的整套解决方案，具有全栈、易迁移、易扩展、社区生态丰富等优点，从而使得应用开发/应用搭建能够专注于业务逻辑，是一种应用敏捷性的体现。
数据分析
OLTP作为面向在线交易的场景，往往具有短事务和小数据量的特点，专注于事务处理的并发性和快速性。与OLTP对应的是OLAP，面向数据分析和决策支持的场景，往往涉及大量数据的分析，专注于查询的复杂性。然而，现代OLTP往往会有数据分析的需求，基于事务数据实时提供分析视图，因此数据分析能力也是一种应用敏捷性。典型的数据分析流派有Lambda、HTAP、HSAP，代表了若干着不同的设计理念。
灵活检索
在线业务往往有着数据检索的需求，一个成熟的解决方案是在主数据库之外联合查询引擎一起提供数据服务，两者之间的数据通过业务主键关联。主数据库用于存储原始数据，同时把待检索字段和业务主键写入查询引擎里面建立索引，查询时先基于检索字段去查询引擎获取业务主键，再基于业务主键去主数据库获取完整的原始数据。多存储架构会引入数据一致性的问题，例如应用在主数据库写入成功，但在查询引擎写入失败，此时会发送一个补偿消息到消息队列用于异步重试，从而达到数据的最终一致性。一个被广泛使用的产品组合为HBase+ElasticSearch+MQ，其架构图如下：
多产品组合引入了架构复杂度，增加了硬件成本，且应用程序需要处理多产品之间数据一致性的问题。对，数据一致性是分布式系统的设计关键，从水平扩展性到容灾设计，再到现在的多产品组合架构，我们始终绕不过数据一致性的话题。对于数据一致性有几种解决方案：2PC、Totalorderbroadcast、最终一致性，或者终极大招——容忍不一致。数据一致性的语义应该由数据库服务屏蔽掉，并通过灵活的接口语义呈现出来，这就是应用敏捷性。
因此对于在线业务的数据检索需求，一个业务友好的解决方案是数据库服务同时提供原始数据存储和数据检索的功能，且提供可配置的数据一致性语义。数据检索特性应该尽量多元化，包括地理位置检索、全文检索、向量检索等。
总结
我们说数据库服务应该给应用程序提供应用敏捷性，其本质是某种易用性，尽量使得应用程序减少实现数据逻辑的投入，更专注于业务逻辑自身。易用性有多种理念，例如我们本文介绍的数据模型、基础技术栈、数据分析、灵活检索等，数据库服务不需要也无法践行所有这些理念，需要的是把这些理念融入到日常的架构设计和服务交付中去，如果能够以合理的ROI践行一两个理念，那也就达到对业务友好的目的了。
安全合规
安全合规是在线业务一项非常基本的诉求，可以帮助企业更好的保护其数据资产，保障业务运行的连续性，降低法律风险。安全合规的方案设计需要从数据的生命周期入手，遍历所有流程，分析其风险敞口并针对性防护。数据库的入口主要有两个，分别是应用程序和运维人员/运维系统。应用程序通过数据库协议与数据库进行通信和数据交换，涉及到认证鉴权、数据传输、数据存储等流程。
蚂蚁业务具有金融属性，完备的安全合规能力是一个必选项。对于数据库服务，必须从设计之初就把安全合规纳入设计目标之中，并保持跟随业务安全合规诉求提高而演进的初心和能力。不具备安全合规能力，或者安全合规能力不能演进的数据库服务对于业务系统，是不可承受之重。
成本优化
现代数据具有4V特性，其中有个是规模性(Volume)，规模性表示数据量的爆炸性增长，对性能和存储容量提出了很高的诉求，最后都会直观反应到数据库成本上，高昂的成本最后会成为企业继续发展的拦路虎，尤其是当前的存量时代。因此随着数据库服务的发展，成本优化是必须纳入考虑的事情，否则会阻碍数据库服务的进一步发展。
业务数据库架构优化是成本收益最大的优化措施。我们前面介绍了各种多产品架构，包括PolyglotPersistence、CQRS、Lambda架构等，多产品架构会引入多份数据存储的开销、应用代码适配多产品引入的代码复杂度开销、多产品的运维开销、建站的交付开销等。我们作为数据库服务提供者，本着帮助业务收敛其数据库架构的目标，需要尽可能促进数据库产品丰富其特性。多种技术可以达到收敛数据库架构的目标：多模数据库，一份数据提供多种数据模型服务，避免可能的PolyglotPersistence和CQRS架构;HTAP&HSAP，一套系统同时提供数据写入和数据分析的职责，避免可能的Lambda架构;具有检索特性的持久化数据库，一套系统同时提供数据持久化和数据检索的职责，避免可能的PolyglotPersistence和CQRS架构。
总之，成本优化对企业有着非常积极的意义，但同时对业务自身也可能产生巨大的改造成本，需要数据库服务提供方跟业务方齐心协力，一起缔造优秀的ROI和TCO。成本优化对于数据库服务提供方可能是一个懈怠的事情，需要有企业成本控制小组从整体资源层面进行审计，以做到整体最优。
轻量交付
蚂蚁是一个多站点的业务环境，经常会有新建站点而交付数据库服务的需求。轻量交付能力能够显著缩短建站周期、提升建站体验、优化建站成本，具备轻量交付能力的数据库服务能够有效提升其业务友好性。
轻量交付首先离不开数据库产品的管控成熟度。数据库服务依赖的硬件设施需要能够适配企业当前普适的硬件形态，例如硬件设施经历了从物理机形态到虚拟机形态的演进，再到当前的容器形态，数据库产品需要积极去适配，积极适配当前企业普适的硬件形态能够有效降低交付前置事项对人肉的依赖;服务搭建流程需要能够接口化且具备原子动作的可重入能力和回滚能力，这对管控平台的成熟度提出了要求，从而能够被上层系统所集成，能够最大限度的规范化、自动化，并最终无人化;数据库服务需要具有完备的健康自检能力，完整覆盖服务自身的所有组件与接口，及依赖的第三方服务，从而保证交付质量。
轻量交付也离不开数据库产品的架构轻量化，架构轻量化表示对第三方组件的依赖尽可能少，从而能够有效降低站点的“重量”，避免引入一些又大又重的组件，这对于站点的成本控制有着非常积极的意义。
轻量交付也意味着面向更高一层的Programmingmodel交付，积极的主动或跟随推高应用程序的思考层次。例如云计算的发展使得计算资源被不断推高，从物理机到云服务器，再到容器，使得应用程序对计算资源的适配越来越轻量化。数据库服务也同样随着云计算的发展而发展，从On-Premises到云托管，再到Serverless，应用程序的Programmingmodel也在不断推高，其专注点越来越回归到业务逻辑自身。因此数据库服务的轻量交付必须积极拥抱应用程序的Programmingmodel。
总之，轻量交付是一个系统化工程，囊括了数据库产品的架构轻量化、管控成熟度、交付层次等方面，而管控成熟度又是以产品成熟度为前提的。能够轻量交付的数据库服务一定是一款比较成熟的数据库产品且拥有成熟的配套管控体系，从而是对业务友好的数据库服务。数据库产品往往受限于自身的生命周期，很难做到超出自身成熟度的轻量交付，但我们应该把轻量交付作为终态目标而不断逼近。
从业务视角需要的是数据库服务，而不仅仅是数据库产品，数据库服务提供者必须从业务视角审视自己如何提供更好的数据库服务。数据库服务相比于数据库产品有着更多的技术内涵，囊括了数据库内核产品、数据库管控产品、访问中间件、数据库部署架构、业务数据存储架构等整套技术栈，囊括了从服务交付、稳定运行、成本优化、合规整改等完整的数据生命周期，需要从业务编程模型、业务工作负载和数据库特性等多角度分析和优化，从而做到整体最优。对业务友好的数据库服务能够极大简化业务层在数据库逻辑上的投入，能够更专注于业务逻辑自身，对企业发展有着巨大的价值。
科技在进步，业务在演进，数据库服务也必须与时俱进，才能持续对业务友好。