今年 5 月，SphereEx 正式对外提出了 Database Mesh 2.0 理念。关于 Database Mesh，其不是静态的定义，而是一个在不断进化的动态概念。Database Mesh 始终关注对数据库流量的治理，基于数据库协议感知能力，提供数据分片、负载均衡、可观测性、审计等能力，这些能力已经解决了数据库治理中属于流量治理的部分问题。此外 Database Mesh 也关注数据库可靠性工程的建设，面向不同角色提供更易用、更极致的数据库治理能力。
爱奇艺十分认同 Database Mesh 的理念以及愿景，即『在云端实现数据库的高性能扩展以及解决数据治理难题』。因此，爱奇艺基于自身需要对 ShardingSphere-JDBC 进行了扩展，并结合 Database Mesh 理念的具体实现--Pisanix 进行了一系列关键测试，逐步向 Database Mesh 架构演进。
随着业务扩张与用户数量激增，所接入的各类活动（例如秒杀）也在增长，瞬间巨大流量的涌入也为数据库带来了不小的压力，进而导致企业在应用数据库的过程中出现 slave 延迟、慢查询以及部分操作无法满足业务需要等问题。在微服务架构以及云原生的加速下，双方的结合为业务上线发布和治理带来了新的可能。不过随着业务场景越来越多元，数据应用的方案呈现烟囱状，对数据的管控有孤岛化的趋势，摆在技术人员面前的是“选型难、成本高、管控复杂”等问题。
尤其是在云原生日渐成熟的今天，业务应用和数据库等基础设施的关系正在潜移默化中改变，爱奇艺希望通过把握云原生架构的新趋势，采用统一化管理的方式，实现对数据库的扩展和升级，以支撑更多应用与业务上云。
为了满足业务团队在云上环境中对于数据库性能、可用性等方面的高要求，爱奇艺需要将 ShardingSphere 在本地的分布式能力迁移至云端，并寻找一款能够在云原生环境下统一云端数据库流量入口、对云上流量以及数据进行统一高效治理的工具。
爱奇艺在调研并配合测试反馈由 SphereEx 社区提供的 Database Mesh 解决方案--Pisanix 的同时，也基于 ShardingSphere 社区的 ShardingSphere-JDBC 进行二次开发，以满足目前业务接入数据库治理平台中对于数据分片、负载均衡、配置存储与安全等需求。
目前爱奇艺使用统一配置中心存储数据库连接配置，使用 KMS 相关技术加密数据库访问配置，使用 ShardingSphere-JDBC 满足数据分片和负载均衡相关的需求，整体架构如下图。
爱奇艺云原生数据库体系
当业务接入数据治理平台时，通过申请相关的连接配置，在经过转化和访问信息通过 KMS 加密后存储进统一配置存储中心；当应用启动时，通过改进过后的 ShardingSphere-JDBC 拉取配置并监听配置变更以支持配置热更新。
在改进之前，如果遇到修改配置、Sharding 集群扩容、集群版本升级、数据库迁移和上云等场景时，往往需要针对业务服务进行重新发版，并且业务方需针对相关场景设计如切换和回滚、选择时间点、流量灰度以及数据校对等复杂操作流程。
改进后，对于配置中新增或修改分表配置，定制化的 ShardingSphere-JDBC能够对 Sharding 集群的扩缩容或改绑起到很好的支持作用。通过在配置中心白屏操作修改配置或绑定集群，主动选择配置重新加载时机，当 SDK 端接收到最新配置，会使用异步任务进行老连接池的关闭并替换现有连接池，做到读写流量的平滑迁移， 大大降低了相关数据治理能力平滑迁移至云上环境的难度。
在爱奇艺的规划中，未来规划通过接入 Database Mesh 并引入 Pisanix-Proxy，进一步将数据治理能力从 SDK 下沉到 Sidecar 中。
在流量入口层，随着云原生应用微服务化、Serverless 化，用户需要面对复杂路由规则可配置、支持多种应用层协议、服务访问的安全性以及流量的可观测性等诉求。关于这部分，爱奇艺最早是通过中间件统一管理 Redis 和 MySQL。
除此以外，为了更好支持爱奇艺的混合云部署方案，SmartJedis 支持了统一配置中心，在统一的配置中心中动态支持不同环境下的配置，在非网格环境中使用直连的方式，在网格环境中使用 Envoy 中的 RedisProxy 管理 Redis 协议流量并支持连接配置的热更新，避免了 Redis 上云后需要业务重新发版的问题。
在 MySQL 部分，爱奇艺研发团队测试了 Database Mesh 的具体实践--Pisanix。Pisanix 由 Go 及 Rust 编写，适配 Kubernetes 环境，目前已支持 MySQL 协议。其主要包括 Pisa-Controller、Pisa-Proxy 和 Pisa-Daemon 三个组件，为用户应用提供『本地即数据库』的访问体验，实现支持多协议的可插拔架构、屏蔽真实数据源状态，为数据运维人员提供统一的数据库流量管控能力。
目前爱奇艺在系统仍然是基于 ShardingSphere-JDBC 来支持 Java 应用，未来 Pisanix 在爱奇艺的系统中得到进一步落地后，爱奇艺将通过 Pisanix 实现标准化的数据库自动维护体验，并通过支撑多语言应用来完成多种数据库治理行为的云原生编排。另外借助各种 Database Mesh 的标准 CustomResourceDefinition，比如统一的数据库接入声明配置、可编程的数据库访问资源限制等，爱奇艺也将能够快速实现云原生数据库的治理编排。
01 数据分片，在云端提供接近 ShardingSphere-JDBC 的性能
数据分片是应对海量数据存储与计算的有效手段，这也是爱奇艺在云原生非 Java 语言场景中倾向于 Pisanix 的动机之一。在数据分片的全部环节中，主要包含了 SQL 解析、SQL 改写、SQL 路由、结果归并这 4 个重要模块。
其中，为配合将 ShardingSphere 本地强大的分片能力迁移至云端，Pisanix 基于底层数据库在云端提供了数据分片的治理能力，用户可以通过 Pisanix 实现水平扩展计算。同时开放更多自定义指标，为 Pisa-Proxy 实现更智能、更稳定的高级自动扩容能力。
基于 Pisa-Controller 控制面，爱奇艺能够实现对数据面组件的管控，配合 Pisa-Proxy，以 Sidecar 方式与业务应用部署在同一个 Pod 中，用以监听 MySQL 协议获取应用访问数据库的流量。在此基础上，Pisanix 还为爱奇艺提供了多种治理能力：
SQL 流量治理：通过解析 SQL，实现多种负载均衡策略、限流等；
访问控制：根据用户和数据权限关系，实现细粒度的权限控制；
SQL 防火墙：阻止高危 SQL 语句执行；
可观测性：暴露各种数据库访问指标：如吞吐、延时等。
对于爱奇艺而言，基于 Pisanix 实现 Java 业务和非 Java 业务都能够在云环境下的高性能分片，将确保更多业务未来能够在 Pisanix 的支持下顺畅运转。
2、读写分离，有效提升数据库吞吐量
为了达到提升系统吞吐量以及可用性等需求，许多系统往往会采用主从数据库架构的配置模式，但是这种主从模式也为业务的使用带来了一定的复杂性。因此，在读请求明显高于写请求的情况下，需要在此基础上使用读写分离来突破数据库在实际应用场景中性能瓶颈问题。
作为业界在主从场景下提升数据库吞吐量最常用的技术方案之一，读写分离能够达到在实际场景中提高查询性能、降低服务器负载的目的。不过读写分离也带来了与数据分片同样的问题，它同样会使得应用开发以及运维人员对数据库的操作变得更加复杂。
目前爱奇艺通过一主多从的配置方式，将查询请求均匀分散到多个数据副本，进而提升系统的处理能力。这种方式不但能够提升系统的吞吐量，还能够有效提升系统可用性，进而达到在任何一个数据库宕机、甚至磁盘物理损坏的情况下仍然不影响系统的正常运行的目标。
在规划过程中，爱奇艺计划使用 Pisanix 的动态感知读写分离功能来管理多主多从的数据库集群。在接入 Pisanix 后，爱奇艺将可以利用读写分离功能管理主从数据库，实现透明化的读写分离功能，让用户像使用一个单体数据库一样使用主从架构的数据库。
目前，爱奇艺内部对 ShardingSphere-JDBC 的改造已经基本完成，未来也将计划应用 Pisanix 配合 ShardingSphere 的能力，在爱奇艺内部实现对 MySQL 的统一治理。在 ShardingSphere 社区和 Database Mesh 社区的大力推动下，Pisanix 也将结合用户使用场景不断打磨云上解决方案，为爱奇艺的业务部门提供可靠的技术支撑，加速云上业务拓展。
不过，毕竟 Pisanix 是一个非常年轻的项目，因此在实际应用中还是存在一些不足。在爱奇艺的测试应用过程中，目前 Pisanix 对于分库分表的表达式支持程度有限，对于 SQL 的特殊配置程度有待进一步提升。此外如 Pisanix 运行状况的可视化、metrics、熔断降级策略、trace 等与线上性能相关的能力将会是社区接下来的发展重点。SQL 审计、Pisa-Controller 与 Istio 合并等兼容性及性能问题，也已经被社区所注意到并提上了日程。
未来爱奇艺将基于 ShardingSphere-JDBC 以及 Database Mesh 理念正在迭代中的 Pisanix，搭建起基于 MySQL 的统一数据访问规范和解决方案。通过统一配置中心与定制化 sidecar，爱奇艺将逐步实现数据库访问细节对业务开发人员完全透明，降低使用复杂度的同时增强数据库访问的安全性，加速构建数据库统一配置中心，协助应用上云。