緣起

早在2015年的時(shí)候，隨著阿里云業(yè)務(wù)突飛猛進(jìn)的發(fā)展，SQLServer業(yè)務(wù)也積累了大批忠實(shí)客戶，其中一些體量較大的客戶在類似大促的業(yè)務(wù)高峰時(shí)RDS的單機(jī)規(guī)格（規(guī)格是按照 內(nèi)存CPUIOPS 一定比例分配，根據(jù)底層資源不同都會(huì)有各自上限）已經(jīng)不能滿足用戶的業(yè)務(wù)需求，在我們看來(lái)也需要做Scale Out了，但SQLServer并沒(méi)有完備的中間件產(chǎn)品，所以無(wú)論是邏輯Sharding還是只讀分離，都需要用戶配合做應(yīng)用改造，而從用戶角度看Sharding改動(dòng)量很大不是一時(shí)間能完成的，那么更多寄希望我們提供讀寫分離的方案來(lái)滿足業(yè)務(wù)需求。

那么讀寫分離我們第一個(gè)想到的即是AlwaysOn技術(shù)，但由于當(dāng)時(shí)AlwaysOn對(duì)域控和Windows群集都是強(qiáng)依賴，而這兩者又對(duì)我們所依賴的基礎(chǔ)設(shè)施有很大挑戰(zhàn)，需要做很多的突破產(chǎn)品限制的非標(biāo)準(zhǔn)化操作才有可能實(shí)現(xiàn)并且還有安全風(fēng)險(xiǎn)，所以最后我們只能放棄AlwaysOn技術(shù)方案，重新設(shè)計(jì)方案幫助用戶度過(guò)難關(guān)。

最后，面對(duì)這類客戶需求我們的方案如何產(chǎn)品化是值得我們思考的。

產(chǎn)品快速發(fā)展

除了讀寫分離，產(chǎn)品上還有很多更重要的問(wèn)題急需我們?nèi)ソ鉀Q，所以從2015年到2017年我們經(jīng)歷了一個(gè)飛速發(fā)展階段，圍繞產(chǎn)品穩(wěn)定性、多樣性以及用戶體驗(yàn)做了非常多的事情，舉幾個(gè)點(diǎn)：

• 為了提高穩(wěn)定性和用戶體驗(yàn)我們最先替換了底層架構(gòu)，這也為后續(xù)產(chǎn)品多樣化發(fā)展打下基礎(chǔ)

• 為了滿足不同用戶需求，推出了SQLServer 2008R2/2012/2014/2016 Web/Standard/Enterprise 不同Version、Edition的組合版本

• 為解決上云難問(wèn)題推出了上云評(píng)估工具，以及針對(duì)不同版本、不同場(chǎng)景的上云方案全量備份數(shù)據(jù)上云SQL Server 2008 R2版、全量備份數(shù)據(jù)上云SQL Server 2012及以上版本、增量備份數(shù)據(jù)上云SQL Server 2012及以上版本、SQL Server實(shí)例級(jí)別數(shù)據(jù)庫(kù)上云

• 為了提升用戶體驗(yàn)支持更多特性，我們?cè)赟QL層提供了很多封裝的存儲(chǔ)過(guò)程，這里有些看似簡(jiǎn)單的功能在面對(duì)外部的安全、內(nèi)部的SQL鏡像等因素的共同作用下，實(shí)現(xiàn)的挑戰(zhàn)還是很大的

• 為了讓專家服務(wù)更智能、更能貼近每個(gè)用戶，我們研發(fā)了SQLServer CloudDBA集合了云上大量性能、空間問(wèn)題的解決方案

在這當(dāng)中依舊不斷有讀寫分離的用戶需求，每次遇到我們都先引導(dǎo)到了IaaS層用ECS自建實(shí)現(xiàn)，因?yàn)镻aaS化的時(shí)機(jī)并不成熟，具體原因跟SQLServer當(dāng)前的技術(shù)棧和云產(chǎn)品的結(jié)合有著密切的關(guān)系，這里也可以把我們背后的一些思考分享出來(lái)。

讀寫分離

首先明確我們討論的讀寫分離是什么，MySQL的讀寫分離大部分是利用中間層做路由解析，基本上可以實(shí)現(xiàn)對(duì)應(yīng)用端透明只有少部分場(chǎng)景需要用戶做適配。

SQLServer并沒(méi)有成熟的中間件產(chǎn)品，本質(zhì)上講是TDS（Tabular Data Stream）不完全開放的原因，如果要做也是有辦法的，只是投入的成本遠(yuǎn)大于收益；基于此，SQLServer無(wú)論利用當(dāng)前何種技術(shù)實(shí)現(xiàn)讀寫分離，對(duì)應(yīng)用來(lái)講都需要做一些適配，即使是使用AlwaysOn技術(shù)在鏈接驅(qū)動(dòng)的參數(shù)配置上也會(huì)不同，所以我們后面討論的讀寫分離都是基于這個(gè)前提。

技術(shù)選型

我們對(duì)比了SQLServer所有相關(guān)的技術(shù)棧

其中數(shù)據(jù)安全、HA（High Availability 高可用）、DR（Disaster Recovery 災(zāi)難恢復(fù)）以及備庫(kù)是否可讀是我們最關(guān)注的；這里的HA是指原生技術(shù)本身是否支持自動(dòng)HA，當(dāng)結(jié)合了部分云產(chǎn)品后我們也有能力把不支持變?yōu)橹С?，?shù)據(jù)安全和災(zāi)難恢復(fù)的時(shí)間基本是原生技術(shù)決定的，備庫(kù)是否可讀是對(duì)單一技術(shù)的說(shuō)明但做一些技術(shù)組合是可以把不可讀變?yōu)榭勺x的（比如Database Mirroring+Database Snapshots），最終綜合來(lái)看Transactional Replication和AlwaysOn是我們覺(jué)得有機(jī)會(huì)做讀寫分離產(chǎn)品化的技術(shù)。

接著我們單獨(dú)來(lái)看這兩種技術(shù)對(duì)比

原理上講Replication是邏輯復(fù)制，對(duì)比AlwaysOn的物理復(fù)制在性能、延遲、可靠性上都會(huì)有一定的差距；并且在產(chǎn)品復(fù)雜度讀、可控性上和易用性上，由于Replication過(guò)于靈活細(xì)到表、列級(jí)別很難控制，無(wú)論用戶使用還是我們做產(chǎn)品化整個(gè)復(fù)雜度非常高；所以最終我們選用AlwaysOn。

AlwaysOn技術(shù)

AlwaysOn是原生支持High Availability和Disaster Recovery的技術(shù)，本身又分為Failover Cluster Instances(后續(xù)簡(jiǎn)稱FCI)和Availability Groups(后續(xù)簡(jiǎn)稱AG)，下面的圖是FCI和AG的基礎(chǔ)架構(gòu)

其中FCI和常規(guī)版本的AG都依賴Windows Server Failover Clustering（后續(xù)簡(jiǎn)稱WSFC），不同點(diǎn)是FCI是Share Storage而AG是Share Nothing，F(xiàn)CI是實(shí)例級(jí)別同步而AG是DB級(jí)別，那么很容易想到Share Nothing會(huì)有同步和異步的區(qū)別（和鏡像技術(shù)類似），其中兩者的區(qū)別點(diǎn)需要我們知道AlwaysOn的基本同步過(guò)程

首先在Primary節(jié)點(diǎn)的日志（Commit/Log Block Write）會(huì)從Log Cache刷到磁盤，同時(shí)Primary節(jié)點(diǎn)的Log Capture也會(huì)把日志發(fā)送到其它所有Replica節(jié)點(diǎn)，對(duì)應(yīng)節(jié)點(diǎn)的Log Receive線程把收到的日志同樣從Log Cache刷到磁盤，最后會(huì)由Redo Thread應(yīng)用這些日志刷到數(shù)據(jù)文件里。

這其中還有一步，就是在Secondary端刷日志的時(shí)候，如果Primary節(jié)點(diǎn)等待這次返回的Acknowlege Commit，那么就是同步模式，反之如果Primary端不等Secondary的返回那么就是異步模式，兩者的區(qū)別由此展開。

這是基本的同步過(guò)程，但無(wú)論是AlwaysOn還是Database Mirroring都存在一種情況，即同步模式下如果Secondary端異常，Primary端沒(méi)有收到他的心跳也沒(méi)有收到這次的Acknowlege Commit，那么也并不會(huì)算作寫入失敗，因?yàn)樗坏┱J(rèn)定Secondary異常就不會(huì)等這次ACK，而是退化為類似異步的模式，但會(huì)把Secondary端的異常狀態(tài)記錄在基表里，通過(guò)相關(guān)視圖（sys.dm_hadr_database_replica_states、sys.database_mirroring）暴露出來(lái)，就是我們常見的NOT SYNCHRONIZING/Disconnect狀態(tài)，這時(shí)候自動(dòng)化運(yùn)維系統(tǒng)或者DBA就需要做判斷處理，等到Secondary修復(fù)重新聯(lián)機(jī)后會(huì)向Primary報(bào)告End of Log (EOL) LSN，Primary端再向它發(fā)送EOL LSN 之后hardened的所有日志，一旦Secondary端開始接收到這些日志并逐步刷到日志文件中，那么整個(gè)AG或者M(jìn)irroring相關(guān)的視圖又會(huì)標(biāo)記其狀態(tài)為Synchronizing，表明正在追趕直到Last Hardened (LH) LSN達(dá)到主備一致狀態(tài)，這時(shí)重新回到同步模式。

以前的情況一直是這樣，直到SQLServer 2017 CU 1引入了REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT這個(gè)參數(shù)，參數(shù)名字很長(zhǎng)但也基本包含了他的作用，應(yīng)對(duì)剛才的場(chǎng)景是可以讓Primary端一直等到Secondary節(jié)點(diǎn)重新聯(lián)機(jī)并同步后在提供服務(wù)。

了解了AG同步、異步以及FCI，在總結(jié)下我們關(guān)心的點(diǎn)

在實(shí)際方案中這些也可以結(jié)合起來(lái)，最終再和阿里云產(chǎn)品整合做一個(gè)整體方案，之前也講到阿里云從15年就開始做類似方案來(lái)解決用戶問(wèn)題，一直到最終PaaS化也過(guò)度了三個(gè)版本。

云上演進(jìn)

第一版本我們使用了ECS、SSD云盤、OSS、VPC、SLB作為基礎(chǔ)；在SQL技術(shù)上，我們使用SQL+WSFC+AD的方式，目前看這種方式支持的版本也非常多，從12到17都可以；驗(yàn)證方式既可以用域控也可以用證書。

但他有2個(gè)缺點(diǎn)：第一是成本高，除了Primary和兩個(gè)Secondary節(jié)點(diǎn)還要有兩個(gè)AD節(jié)點(diǎn)，畢竟我們每個(gè)環(huán)節(jié)都要保證高可用；
第二點(diǎn)是穩(wěn)定性不夠，網(wǎng)絡(luò)抖動(dòng)的情況非常容易讓W(xué)SFC判斷異常，SQL端DB同時(shí)出現(xiàn)不可用；

這是第二版的架構(gòu)，跟第一版相比我們用到了HAVIP來(lái)解決監(jiān)聽器問(wèn)題，去掉了AD只能用證書做驗(yàn)證，但也因此最小資源開銷降低到3；這個(gè)方案也是之前在阿里云上用的比較多的，但同第一個(gè)方案一樣，在網(wǎng)絡(luò)穩(wěn)定性上會(huì)有很多挑戰(zhàn)，因?yàn)槲覀兾磥?lái)面對(duì)的場(chǎng)景不只是同城跨可用區(qū)還會(huì)有更多跨Region以及打通海外的場(chǎng)景，所以這個(gè)方案也只能Cover一部分用戶的需求，但對(duì)我們不是一個(gè)最終方案。

最終我們找到了方案三，去除了WSFC和AD，只關(guān)注基礎(chǔ)云產(chǎn)品和SQL本身；最終要的是跟方案二相比，對(duì)網(wǎng)絡(luò)的抖動(dòng)敏感度會(huì)更低也更可控，最多是在Primary端出現(xiàn)Send Queue的堆積，這個(gè)我們完全可以通過(guò)SQLServer相關(guān)的Performance Counter監(jiān)控并做一些修復(fù)調(diào)整。

但沒(méi)有方案是完美的，可控性強(qiáng)的代價(jià)是這種無(wú)群集無(wú)域控架構(gòu)原生是不具備HADR能力的，這點(diǎn)熟悉WSFC的同學(xué)可以知道之前架構(gòu)的HA都是依賴WSFC，他包括健康檢查、資源管理、分布式元數(shù)據(jù)通知維護(hù)以及故障轉(zhuǎn)移，所以這時(shí)候就必須我們自己去解決這個(gè)問(wèn)題；為此我們也做了很多努力，最終實(shí)現(xiàn)了支持AlwaysOn無(wú)域控?zé)o群集的HA系統(tǒng)，不依賴Cluster完全自主可控的HA。

產(chǎn)品化

最終的產(chǎn)品架構(gòu)如下，首先會(huì)保證有2個(gè)同步節(jié)點(diǎn)做主備，并且盡量分配在不同的可用區(qū)，其它只讀節(jié)點(diǎn)默認(rèn)是異步，最多可以有7個(gè)只讀節(jié)點(diǎn)；用戶的訪問(wèn)鏈路可以有三種：

• 第一種是讀寫鏈路，會(huì)指向兩個(gè)同步節(jié)點(diǎn)，由我們的HA來(lái)保證高可用

• 第二種是統(tǒng)一只讀鏈路，根據(jù)用戶需求設(shè)定，把指定的Replica節(jié)點(diǎn)綁定到一起按照一定的權(quán)重比例分配鏈接

• 第三種是單一只讀鏈路，即每個(gè)只讀節(jié)點(diǎn)會(huì)提供一個(gè)單獨(dú)的鏈接，讓用戶也可以自己靈活配置，比如用戶的APP Server就是在可用區(qū)A那么就可以直接訪問(wèn)可用區(qū)A的只讀地址，避免再通過(guò)統(tǒng)一只讀被路由到其它區(qū)域

至此SQLServer AlwaysOn已經(jīng)在阿里云PaaS化，當(dāng)然目前只是支持最主要功能，后續(xù)還有很多可以完善豐富的地方，希望有更多用戶了解和使用這個(gè)產(chǎn)品并幫他們解決實(shí)際問(wèn)題。