雲上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組件。

參考文檔

https://my.oschina.net/yunqi/blog/3069510