摘要：在互联网的浪潮冲击下，很多传统企业都选择上云。阿里云在做基于互联网的分布式应用，因此在传统企业上云的过程中，阿里云也同样面临一些数据库相关的各种冲击和需求。在武汉云栖大会上，阿里云高级产品专家王伟做了名为“传统企业数据库上云案例分享”的精彩演讲。
传统企业应用缺点
传统企业面临很多架构变迁，正是由于这些变迁，阿里云在应用架构上做了分布式改造，阿一直在思考如何帮助传统企业上云。很多金融、保险、制造业为了适应互联网的高并发、大流量冲击，都选择上云并且都在做适用性的改造。这个时候大家都在想数据库怎么办，很多企业都在考虑数据库是不是也要做分布式的改造。那究竟什么样的业务场景才需要做数据库分布式架构呢？
首先我们要明白传统企业应用架构和互联网的分布式应用架构到底有什么不同。其实从资源层面、数据层面、中间件层面、应用的开发层面等，每一个层面都面临着一些改变。
1.资源层面。传统的应用架构在使用微型机、存储设备等等一些物理硬件。而目前在互联网分布式应用下，阿里云在使用公有云、私有云、混合云等等一些混合式的架构。
2.数据层面。传统的应用在使用集中化的数据库，比如Oracle、SQLserver等数据库，为什么叫集中化的数据库？因为传统应用为了实现多个节点之间共享和最大限度的保证数据的一致性，习惯把数据文件存放在一台集中化的存储设备里面。而在互联网分布式应用下，阿里云一直倡导去集中化的数据库的理念，所以目前阿里云在使用MySQL、HBase、Redis等等一些分布式的架构。
3.中间件层面。传统应用在使用WebLogic/WAS/MQ等等，目前为了做一些微服务的改造，阿里云在使用Swarm/K8S/Mesos等等一些架构来基于微服务做一些调度。
4.从应用架构、应用框架来说，传统的应用在使用Spring/Struts/SOA，现在阿里云在使用一些微服务架构，例如像Docker。
5.传统企业的开发运维采用可控发布，保守运维，经常一个新功能的发布动辄几周甚至几个月的时间才能上线。而现在阿里云在使用DevOps，应用可以随时上线。在做这些改造之前，应用响应慢并且经常在应用层无法横向扩展，现在做了微服务改造，每一个微服务都可以适应灵活的弹性和压力去做一些扩展。
因此在目前分布式的改造之下，阿里云认为对数据库有更高的要求，总结就是需要敏捷、分布式、低成本等特点。每一个微服务都对应一个小的数据库，所以说需要大量的数据去支持一个业务，需要灵活性的调度，所以对敏捷性是有要求的。同时因为量级比较大，也希望实现分布式机构。并且由于使用的数据库多了，使用商业数据库成本太大，因此需要降低成本。
丰富的云上数据库
阿里云认为传统的行业做互联网的创新，需要的数据库主要有以下特点：
1.自主可控:基于开放架构，基于开源的优化。
2.高可用:跨机房容灾，满足金融级业务系统全天候对外提供稳定可靠的客户服务。
3.高性能:互联网+金融的创新业务所需的流量弹性。
4.支持云:私有云和公有云互通一致的体感，降低使用和运维难度。
5.易运维:大体量自动化、运维体系合规化要求(基线、环境适配、管理体系等)。
6.数据安全: 审计&数据强一致性&多中心容灾部署。
7.成本优化:IT总体拥有成本必须下降。
基于以上特点，阿里云提供了丰富的云上数据库。例如关系型数据库有MySQL、SQL Server PostgreSQL PPAS(⾼高度兼容Oracle) POLARDB。NoSQL数据库有Redis MongoDB HBase Memcache。混合分析数据库有HybridDB for MySQL HybridDB for PostgreSQL。搜索与时序数据库有OpenSearch Elasticsearch HiTSDB。另外还提供像DTS、DMS、HDM等数据库服务与工具。
对于这么多数据库类型和不同数据库引擎而言，阿里云还有很多不同的版本。以MySQL为例，有基础版、高可用版、金融版。基础版就是在ECS的基础上，加云盘上部署的MySQL数据库，它提供非常高的性价比，价格基本上跟你买一个ECS加一个云盘是一样的，但是阿里云在此之上已经集成好了数据库产品。高可用版实际上就是做了主从数据的复制，可以保证数据库的数据可用性。当主节点宕机以后，阿里云可以快速的把业务切换到从节点去，从而保证数据库的可用性，同时还有很多企业级的功能，包括读写分离，读写分离是做数据库横向扩展最便捷的一种方式，应用不用做任何更改，把写入在主节点执行，把查询在只读节点执行，无形之中增强了主库的能力。金融版是跨三机房、三节点的三副本的版本，默认实现了同城三机房的容灾。金融版直接部署在三个机房，它可以保证数据在三个机房做复制，并且当一个机房不管是因为电源的故障还是因为光纤的故障而失效，整个数据库也不会受到影响，数据库主节点会自动迁移到另外两个机房之一，继续提供服务，同时金融版集成了SQL审计、高频监控等。
阿里云数据库稳点、高效的秘诀
阿里云能做到数据的高可用、一致性主要从以下方面来考虑：
1.数据复制技术的演进
做数据库的高可用是一定要做数据复制的。MySQL原生提供两种方式的复制，一种是异步复制，比如是一主一从，中间做异步复制。但是从节点势必会引起延迟，当主节点发生故障的时候，这个时候不知道从节点的数据是不是最新的，因此如果切换从节点，很有可能会造成数据的丢失。为了解决这个问题，MySQL官方提供了另一种方式，半同步复制。半同步复制也是一主一从，主节点在写入数据的同时，会产生日志，然后发送日志给从节点。因此当主节点宕机，至少可以保证从节点是有数据的。但是同时也会产生另一个问题，当主节点在等从节点响应的时候，如果发生网络的故障，最终还是降级成异步。因此阿里云在AliSQL上做了增强，叫做双通道复制，也就是说同时有一条半同步复制通道和异步复制通道，通过这两个通道可以确定性的得知当前主数据库和从数据库的数据是否一致。
2.拜占庭将军问题与分布式一致性算法
拜占庭将军问题在分布式领域是一个比较传统的问题，为了解决拜占庭将军问题，十几年前有一个Paxos算法，但是Paxos算法过于复杂，在很长一段时间都没有计算机语言可以实现，后来Paxos算法做了简化，即Raft算法。通过Raft算法可以解决分布式一致性问题，因此阿里云把Raft算法放到了MySQL内核里面。底层维护了三个数据库节点，一主两备的复制拓扑结构意味着每个节点都是全量的数据，数据库事务日志(Log)从主库同步复制到所有的备库，当集群中超过半数的节点都写入成功后，事务才能完成提交。虽然是同步复制，但由于是三个点，因此单个节点的故障不会影响到实例整体的可用性。这种设计的好处显而易见，即在不损失可用性的情况下，通过较高的数据冗余度来换取更好的可靠性，同时支持跨机房的部署方式，具备机房容灾能力。
3.对于数据安全的重视
安全是根植于阿里云内核的原生功能。从安全的角度，阿里云做了事前、事中、事后三个方面的安全审计，事前阿里云可以做VPC专有网络、IP白名单、防暴力破解、灵活账号权限管理等，事中做了 SSL加密、TDE加密、拦截SQL注入攻击，事后可以做 SQL审计、克隆实例等。
结语
阿里云认为传统企业要做互联网分布式的改造，并不是一步就可以完成，因为企业的业务量可能还没有这么大，所以如果企业现在的业务系统跑在单个MySQL数据库上面，那么接下来可以做一些读写分离。如果读写分离承载不了企业的业务系统，接下来可以做一些垂直的拆分，可以通过微服务去架构，不要用一个数据库承载业务架构，而是用多个数据库承载业务。如果垂直拆分还不够，可以使用阿里云的POLARDB数据库，如果POLARDB数据库还达不到企业的需求，你就应该考虑互联网分布式的改造了。