云上RDS架构

概述

越来越多的企业选择上云，最基础的云服务就是iaas(infrastructure as a service)服务，直观理解就是虚拟主机，用户不用再自建机房，自己购买服务器，而是直接向云厂商购买虚拟主机服务ecs(elastic compute service)，按时按量付费。对于数据库而言，将数据库能力集成进来，就是daas(database as a service)服务，我这里主要讨论rds(relational database service)。因为目前主流云厂商在数据库领域，除了基础的rds服务，还有新型分布式数据库服务，比如amazon的aurora，阿里云的polardb等。所以对于用户而言，他们选择在云上使用数据有两种方式，一种是自己买ecs，自己搭建数据库服务；另外一种方式是，直接购买rds服务。本文主要讨论rds的链路，rds链路中的核心组件slb转发模式，以及rds中proxy的作用，最后还会提到rds的高可用解决方案。

rds链路

1. app+ecs(db)自建

2. app+lvs+db

 

简单说明下，云上并不提供单独买一个rds的服务，因为这种场景无法提供高可用能力，所以一般购买数据库服务时，会同时带上slb作为一套整体解决方案。slb本质就是基于lvs的改进，lvs工作在ios七层网络模型的tcp/ip层，属于4层负载均衡。利用ip,port映射转发能力，提供高可用，负载均衡等能力，rds正是借助slb来实现rds的高可用和负载均衡等能力。lvs主要有几种工作模式，dr模式，nat模式，full-nat模式，ip-tun模式以及我们阿里云优化的enat模式。

2.1 dr模式(direct routing)

核心逻辑：本质是2层转发，slb-server与rds共享一个ip，经过slb-server时，slb-server将mac地址改为目标rds的mac地址，将请求包转给真实的rds；回包时不用经过slb-server，dr模式要求slb和rds需要配置相同的vip地址。

2.2 nat模式(network address translation)

核心逻辑：client端不感知rds真实地址；发包经过slb时，dip(dest_ip)会被替换成rds的ip，请求包返回经过slb时，再将回包源地址改为vip。对比dr模式，请求和回报都需要经过slb-server，rds的ip不再需要是公网地址；与dr模式相同的是，slb和rds需要在同一个局域网内。

2.3 full nat模式

 

核心逻辑：本质是4层转发，请求经过lvs时，lvs请求的(ip,port)替换成真实rds的(ip,port)，回包时，再经过lvs，将回包的源地址改为lvs的(ip,port)，lvs与rds不再要求在同一个局域网内。所有请求的来回都要经过lvs，效率比较低。

2.4 enat模式(enhance nat，三角模式)

核心逻辑：enat模式解决了来回包都要经过lvs问题，具体而言，lvs接收请求后，修改包地址时，会将用户的cip地址冗余在网络包中，回包时，将包改为(vip,cip)，这样就不用再经过lvs了。

3. app+lvs+proxy+db

通过引入slb，rds已经具备了高可用的能力，但由于slb是工作在4层负载均衡，对于应用层协议无法感知，所以当发生主备切换时，所有已经连接在old-master的连接都需要被断掉，对用户来说，就是连接发生了闪断，对于没有重连机制的业务简直就是灾难。引入proxy后，则能有效解决这种问题。切换过程中，对于old-master会等待事务完成，而新的请求则会路由到new-master。

核心逻辑：本质是7层转发，proxy模拟实现mysql协议，应用实际是连接proxy，proxy再连接rds，转发sql给rds，并将结果集转发回传给应用。

4.主要优缺点对比

rds链路类型	优势	缺陷
app+ecs(db)自建	成本低	用户个人负责数据库的容灾、备份、恢复、监控、迁移
app+lvs+db	无需经过proxy转发，rt短，具备高可用能力	无法解决闪断问题，也不容易实现读写分离等高级功能
app+lvs+proxy+db	功能丰富，包括防sql注入，读写分离，连接池等。	多一跳proxy，增加rt。

proxy中间件 vs tddl 中间件

proxy中间件引入使得rds除了具备必要的高可用能力，还能实现更多的高级功能，包括读写分离，连接池，防sql注入，防闪断等，这部分能力的获取是通过牺牲一定rt来获得的。实际上，中间件有两种模式，一种是client模式，一种是server模式，集团的tddl和云上的proxy就是两种典型代表。client模式要求与语言强绑定，比如tddl中间件以jar包的模式打进用户的应用，只支持java语言，这对于云上业务肯定是不可行的，毕竟现在用php，python写后端的应用也非常多。另外一点是，client模式会导致连接数随着client的个数同比例增加，这带来的影响是到后端db的连接数增加，client模式的好处是不用经过proxy这一跳，rt更好；而server模式则能有效控制到后端db的连接数，但是整个链路增加了一层，也就增加了一层风险，proxy自身的高可用也需要严格保证，确保整个链路的可用性。至于功能层面的，比如读写分离，连接池，防sql注入等功能，两种都是可以实现的。

rds高可用

云上售卖的数据库都是传统的数据库包括mysql，postgresql，sqlserver等都是单机数据库，所以数据库的高可用还需要依赖于外部的ha组件。

参考文档