概述 越來越多的企業選擇上雲，最基礎的雲服務就是IaaS(Infrastructure as a Service)服務，直觀理解就是虛擬主機，用戶不用再自建機房，自己購買伺服器，而是直接向雲廠商購買虛擬主機服務ECS(Elastic Compute Service)，按時按量付費。對於資料庫而言，將 ...
概述
越來越多的企業選擇上雲，最基礎的雲服務就是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
