共计 4535 个字符，预计需要花费 12 分钟才能阅读完成。
在 All in Cloud 的云计算时代，业务和应用正在不断“云化”，在此过程中云原生（Cloud Native）理念应运而生。作为云化改造的重要部分，云数据库因其天生的弹性扩展能力以及灵活、易用等特点，让其在面对爆炸性增长的数据量和愈加繁复的数据类型时表现的更加游刃有余。
面对业务及应用的“云原生化”，数据库技术究竟面临了怎样的挑战及发展趋势？为此巨杉科技特别举办了“云时代的数据库架构设计与演进”深圳站活动，邀请多位数据库领域专家带来精彩纷呈的技术干货、分享实实在在的应用实践经验，让现场数百位开发者收获满满。
云架构下分布式数据库设计实践
作为第一位分享嘉宾，巨杉数据库研发副总裁许建辉在主题为“云架构下分布式数据库设计实践”的分享中表示，云架构对数据库的要求最先产生于应用程序的变革。“很早之前，过去的应用开发并没有如此多的快速服务帮助，当时的数据开发模式如何？所有的企业应该都有平台部，负责开发一套与所有数据库打交道的中间件，负责与所有的数据库读取、存储、前端应用等做业务方面的链接。我们发现，在这种模式下数据库是一个集中存储的状态，比较耦合。”
随着互联网业务的快速兴起以及云架构逐渐普及，进而产生了微服务应用体系。在微服务架构下，我们看到了对数据库访问模式发生的变迁。据了解，目前业界有三种情况，首先基于微服务并不需要做太多调整，采用集中数据库存储，这样每个微服务的数据接口访问并不需要做很多变化，可以达成快速适配。
但相对之下也有很多不足，比方说数据集中存储在后端数据库中，数据的解耦合对每个微服务都有影响，分别是数据读取本身以及资源，毕竟数据访问的模式有差别，需求不同。此外在集中存储后，数据的弹性扩张出现问题。毕竟微服务的模式对数据扩张并不排斥，但存储不行，不弹性没商量；如果涉及到更换数据库也必然会对所有微服务架构产生干扰。
“应对这种情况，现在主流的玩法是每个微服务都有一个独立存储，这样开发起来比较简单，但同样会带来几方面的问题，例如每个微服务都具备独立数据库存储之后，每个企业都会有成千上百的微服务，如何做到统一治理、统一的数据视图很重要，当然管理成本是个需要前期考量的大问题，避免数据产生严重的碎片化很重要。”他总结道。
这种情况需要什么好办法来解决？通常采用分布式数据库平台。对于上层，对所有微服务体系可以抽象出许多数据库实例，主要用来做接口兼容与转换。在分享中，许建辉提到，如果需要 PostgreSQL，就可以创建 PostgreSQL 数据库实例，S3 也是如此。对每个实例来说，底层在一个分布式数据库上所承载的物理机数量，上层并不“关心”；从数据弹性扩张上来说也完全没有限制。还有一点，在微服务的发展过程中，在数据访问方面，同一份数据的不同业务模型其访问能力是有差异的。
目前巨杉数据库主要面对三大业务场景，第一是联机交易，替换传统数据库，例如 MySQL、PostgreSQL、DB2 等，可以进行交易场景的处理，让接口完全兼容等；第二就是数据中台，将每一部分业务分享出的数据进行统一管理，主要以大并发的读写为主；此外局势内容管理了，比方说数据分片能力、水平扩张以及弹性伸缩等分区操作。
谈及 MySQL 接口的兼容，巨杉数据库可以百分百兼容 MySQL 数据库和 PostgreSQL 数据库。从兼容层面来讲，首先涉及到语法的兼容，其中包括语法库的兼容；其次是通讯协议，不仅可以做到应用接口的兼容，还要保证体系工具方向，例如第三方 MySQL 有很多监控、管理和解析分析能力，必然要保证整个体系可以使用；再次就是访问计划，要对访问计划进行兼容，其中包括统计信息的收集、访问结构等。
分布式数据库智能运营平台—TDSQL 扁鹊的架构实现与实践
会上，腾讯 TDSQL 智能运营平台负责人赵东志也应邀来到现场，从云数据库以及分布式数据库更细化的运维场景出发并积极探索。在“分布式数据库智能运营平台—TDSQL 扁鹊的架构实现与实践”中，我们初步了解到，TDSQL 是腾讯金融云针对金融场景推出的高一致性分布式数据库，基于 MySQL 基础上进行的二次开发；目前在腾讯内部涉及 到 90% 的金融和交易，一般情况下交易类型不允许丢数据，所以腾讯海量数据体制要求其具备足够的扩展能力等。
“我们针对数据库云化的痛点构建了扁鹊平台，目的很明确，就是希望这个平台在数据库出现故障时可以告诉我们该怎么解决；如果没有出现故障，是否可以通过一些有效的巡检方式来评估 出现在数据库中的潜在风险等。总之，有了这样一个平台可以让我们将多年的运维经验沉淀到体系中，一定程度上减缓重复劳动的消耗。”赵东志总结道。
如今数据库确实面临很多问题，可以大致区分为可用性问题、性能问题以及可靠性问题等。TDSQL 作为金融级数据库，有高可用的配置，例如在每个实例上都会模拟 Agent，定期向 DB 实例中插入数据；此外切换本身对数据是无损的，但在金融场景中并不希望有过多的切换，主要是因为时间上的影响。更加常见的、用户自身对数据库的用法不太合理所导致的问题，一方面是 InnoDB 并发线程的问题，另外一方面是 Binlog 的问题。
对此他认为：“如果用户有大量慢查询，他们就会长期循环占用工作线程，结果会导致阻塞到 InnoDB。如果用户有大量，例如并发执行 100 个会话，也会有问题出现；众所周知，MySQL 金融场景要求 Binlog，数据写入之前，Binlog 做主备同步，相当于 Binlog 和 InnoDB 要一致，Binlog 负责主备同步关系。我一直觉得任何一个数据库无法完美应用各种场景，都有最大的适用范围。如果想更高效发挥数据库的能力，就要遵守数据库的规则。”
分布式搜索和分析引擎—阿里云 Elasticsearch 架构设计与演进
“谈到 Elasticsearch，大家会想到 ELK，这是比较流行的组合。Elasticsearch 是基于 Lucene 的开源分布式搜索和分析引擎，可以根据 Logstash 做数据过滤、修改和收集，其中 Kibana 主要用于数据展示和报表。此外做日志分析的企业用 Elasticsearch 也比较多，还 有些客户可能会去做指标数据的分析或者安全类应用的分析。”阿里巴巴搜索技术专家欧阳楚才在“分布式搜索和分析引擎—阿里云 Elasticsearch 架构设计与演进”的主题中说。
据了解，Elasticsearch 用 Java 语言开发，而使用 Java 语言都会遇到内存垃圾回收的问题。这样就导致如果应用并发量特别高，每一个请求都会占用一定的内存，如果 Java 虚拟机处理不及时，很有可能会导致 JVM 虚拟机的宕机。
2019 年 4 月，Elasticsearch 发布 7.0 版本加并入了 Top K 排序，7.0 版本后，Elasticsearch 本身会监测实际请求的使用量并配置熔断，例如查询请求对 JVM 使用内存超过 40% 则直接停止请求等。经常在关系型数据库中做查询或比较耗时的请求，可能会把数据库“拖慢”。如果可以提前识别出这样的请求，提前中断，就可以高效保证其他请求正常运行。伴随技术迭代与升级，在 7.1 版本里，Elasticsearch 公司把商业版特性、安全特性开始免费，而这个特性特别有用，因为原来开源版本没有账号密码和认证，这个版本后把账号密码安全认证功能免费使用起来。
欧阳楚才还补充道，Elasticsearch 本身可从一个节点扩展到上百个节点，最开始开发自测阶段可以在本机搭建单节点集群并完成数据的写入和查询，且推送到生产环境，通常会按角色拆分不同角色的节点，分别负责不同的功能模块。更重要的是，Elasticsearch 有 Master 节点，负责集群元数据信息的管理、索引的分片管理；DataNode 节点主要负责数据存储和查询；还有一个节点类型叫做客户端节点或者协调服务器节点，负责接收用户的查询请求，把查询和写入请求分发给数据节点。
阿里云从 2017 年开始与 Elasticsearch 合作，把 Elasticsearch 搬到阿里云上提供托管式服务，针对写入、查询做了性能上的调优。如今，阿里云 Elasticsearch 规模有超过 3000 个集群，节点数超过 1 万 +，存储数量超过 5PB，其最重要的工作是保证数据安全。“对此我们在外面加了一层 X -pack 安全认证，必须创建用户名密码，通过用户名密码实现访问，另外还可以配置 IP 段来访问 Elasticsearch 服务，避免黑客攻击。”
有时候，很多用户自己搭建 Elasticsearch 时会遇到一些问题，尤其是新手部署集群时没有专门配置专有主节点，导致集群里的节点通讯出现问题等。他提出，在阿里云上，一般推荐专门配置三个专有主节点来负责数据管理和分片管理。当然不排除有一些金融行业客户对数据的安全要求特别高，要求多个机房上任意一个机房掉电或者光纤被挖断的情况下，服务都可以做到高可用。在易用性方面，阿里云支持 X -pack、监控告警、机器学习等功能。“管理 Elasticsearch 集群实例比较方便，可以自定义安装自研或者开源的插件，也可以用自研的分词。阿里云的安全团队在 Kibana 上做了很多定制化开发，方便用户使用。”
“在 Elasticsearch 内核方面我们做了很多工作，支持分布式存储读写。在软件层面，我们团队有工程师专门研究 Elasticsearch 索引分片机制，让所有分片可以弹性扩建或者缩容。基于 Elasticsearch 做的应用案例，众安保险在今年四月份 Elasticsearch 发布会上介绍过他们在阿里云上使用 Elasticsearch 的经验等。”
SequoiaDB 分布式集群生态工具及容器化部署实战
技术分享逐渐接近尾声，巨杉技术社区杜蓉带来“SequoiaDB 分布式集群生态工具及容器化部署实战”的演讲。她提出，巨杉数据库生态工具中，一种是管理工具，另一种是数据备份、迁移、导入工具。支持 MySQL Workbench，以及很多 MySQL 周边的工具。像 Workbench 一样，可以查到它对应的表；可以通过图形化进行监控，也可以通过工具对集群的系统信息进行批量修改。
此外关于备份，分别涉及到数据库集的备份、集群级备份和文件系统级备份三种。所谓集群级备份，设有集群备份的指令，根据指令选择全量备份还是增量备份；此外集群级备份的数据量比较大。复制方面，异步复制比较简单，支持的实例比较多，可以用 MySQL、DB2、Informix、Oracle 等，用自身导入到处工具；准同步复制，MySQL 用自己的工具把日志实施写入管道中，通过 ApacheStorm 做标准化的修改，修改成 DML 或者 DDL 命令。
另外，杜蓉还在现场为开发者们列举了三种安装数据库的方式：首先就是安装包，直接安装在机器上；其次就是通过 VMWare 导入虚拟机镜像；另外就是 Docker 镜像等。
一键直达：巨杉 Tech | SequoiaDB Docker 镜像使用教程
尽管针对云时代的数据库架构设计与演进精彩技术分享已暂时告一段落，但关于面对业务及应用的“云原生化”，数据库技术究竟面临了怎样的挑战及发展趋势的系列问题探讨依旧在火热进行中，敬请继续关注巨杉 TechDay 技术沙龙的后续活动。
PS：关注公众号，发送“0721”，或按图示操作，即可获取 PPT~
