云上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注入等功能，两种都是可以实现的。