<b>摘要：</b>3月10日，2017阿裡雲網站行業熱點問題和解決方案線下研讨會在上海舉行。在本次研讨會上，阿裡雲資料庫團隊産品專家王義成（花名摯尤）針對于大型網站的資料庫架構設計以及阿裡雲apsaradb所提供的服務管理和解決方案進行了深入介紹。
<b>分享者簡介：</b>王義成（花名摯尤），阿裡雲資料庫團隊産品專家，負責阿裡雲nosql資料庫的産品規劃。加入阿裡巴巴近5年的時間，參與過多種雲資料庫的産品設計工作。目前主要負責阿裡雲的mongodb、redis以及memcache産品，旨在為廣大客戶提供安全可靠的資料庫解決方案。
<b>以下内容根據演講視訊以及ppt整理而成。</b>
最近一年整個資料庫行業可以說是風生水起，同時也發生了包括mongodb黑天事件以及最近的gitlab删庫誤操作事件在内的很多事件，這些事件導緻了各自的業務都遭受了巨大損失。而很有意思的一件事情就是在mongodb黑天事件發生之後，使用阿裡雲mongodb服務的執行個體數開始出現暴漲，這其實是因為大家都抱着亡羊補牢的心态，開始使用雲資料庫。
今天就為通過以下四個主題為大家簡單剖析為什麼做大型網站需要使用雲資料庫：
一、通用資料庫架構
二、apsaradb.概要介紹
三、apsaradb.服務管理
四、apsaradb.解決方案
本次分享中首先會介紹大多數網際網路行業的資料庫通用架構設計、自建資料庫的一些常見問題以及面對的困難，之後将介紹apsaradb基于什麼樣的考量為使用者設計出了什麼樣的産品以及apsaradb所提供的服務管理能力，最後還将介紹apsaradb為阿裡雲整體提供了什麼樣的資料庫解決方案。
<b>一、通用資料庫架構</b>
<b>1.電商高并發，高性能場景</b>
在第一部分将介紹網際網路企業中常用的五個場景。第一個場景就是電商高并發，高性能場景。在電商高并發的場景下，很多架構采用了mysql，也有一些架構采用了postgresql，并且目前大量的電商行業也開始使用mongodb資料庫。而且對于新興的電商企業而言，由于資料相對比較靈活，是以基本上都會選擇使用mongodb建構線上應用，還有一部分電商使用redis做持久化存儲，将使用者資訊類的資料直接使用redis存儲到資料庫中。
這類場景對于資料庫的要求關鍵字就是高性能和資料安全。那麼如何保證資料庫具有較高的性能并且保障資料安全，并且電商的核心交易往往存儲在mysql資料庫中，該如何從網絡層面來保護資料安全，又如何防止sql注入，這些問題都是應用dba或者開發同學需要考慮的事情。如果使用自建的資料庫時就需要考慮應該采用什麼樣的手段來保障資料庫的高性能和安全，應該采用一主多從政策還是采用水準分區政策，這些問題都需要進行考慮。
<b>2.金融：安全交易類場景</b>
第二個場景就是安全交易金融類的場景。在金融類場景下，資料庫往往需要支援海量的資料存儲，可以從上圖中看到，可以結合前面的分布式proxy和後面mysql以及mongodb資料庫實作分布式資料庫的架構。目前mysql和mongodb資料庫是可以實作分布式資料庫設計的，包括阿裡雲的drds以及開源的tadl等都可以用于建構自己的資料庫系統。而在自建資料庫時就需要去考量如何進行資料庫的橫向擴充以及如何保證分布式資料庫能夠平穩地運作，并且保證網絡安全和資料安全。除此之外，金融類場景中的一個核心要求就是保證業務高度可靠，當單節點無法滿足需求時需要使用雙機熱備，而當使用雙機熱備的時候如何保證在主機當機的情況下備機不會丢失資料、某一個機房挂掉之後業務能夠瞬間恢複、緩存資料宕掉之後能夠避免對于背景整體業務的沖擊過大以及在緩存宕掉之後能夠迅速地拉起等問題，都是在自建資料庫時需要仔細考慮的，而這些也正是進行中的難點。
<b>3.網站：高成本效益場景</b>
第三類場景針對的是比較通用的網站類，也就是要求高成本效益的場景。在這個場景下的資料存儲可能會使用到緩存層以及背景的資料庫層，資料庫可能會使用mysql、pg或者mongodb，在緩存部分可能會使用到redis或memcache。這個場景下對于緩存的要求就是成本足夠低并且性能足夠高，這些也是在自建資料庫時需要保證的，而對于背景存儲資料庫而言，則要求具有較高的成本效益。是以如果使用一主一備的政策可能無法滿足高成本效益的需求，是以需要使用讀寫分離以及一主多從的政策。雖然mysql、pg以及mongodb都提供了原生的一主多從的政策模式，但是如何處理這樣的模式以及讀寫分離政策，都是需要應用程式開發人員以及dba進行聯合考量的，是以在自建資料庫時就将會耗費大量的人力、物力和财力。
<b>4.遊戲：行業高可用場景</b>
第四類場景是遊戲類通用的資料庫場景，該場景的核心特點就是ecs和資料庫具有分服的概念，也就是在遊戲中會分出多個區。是以對于遊戲資料庫而言，需要保證其高穩定并且防止對于資料的誤操作。對于一些遊戲産品而言，往往發展非常迅速，可能一到兩周就會更新一個版本，如果開發和測試不完善就可能因為誤操作導緻資料錯誤。那麼dba如何保證在發生誤操作時，能夠瞬間恢複到誤操作發生之前的時間節點的資料狀态，這也是整體維護上的難點。而且在遊戲行業往往需要秒開資料庫，可能一天開多個區，會有大量使用者進來，那麼如何保證整體的前端服務、cdn以及底層的資料庫在一兩分鐘之内就能夠将業務全部開啟，這也是對于資料庫的一個考驗。
<b>5.通用：大資料分析</b>
第五個場景是大資料分析場景，在這個場景下的底層可能是一個hadoop叢集在晚上換算各種資料，白天就能夠将資料展示給老闆看。比如整個網站的交易量資料都需要經過一夜的運算存儲到前端的mysql或者redis資料庫中，快速友善地供業務内部人員稽核。在這個場景下，對于資料庫要求就是需要一個能夠将hadoop中的資料一鍵式地導入到mysql中的工具，還需要增加易用性，使得各個業務方都能夠友善地檢視資料，并且需要低成本地應用mysql和mongodb資料庫來滿足内部查詢需求。是以在大資料分析場景下資料庫的關鍵詞就是易用，需要資料庫服務能夠提供資料通道，保證在異構的資料引擎之間進行資料快速傳輸，并滿足資料庫層面的低成本訴求。
以上就是網際網路應用中的五種通用的資料庫架構，總結而言自建資料庫的難點就在于以下四個方面：
<b>1.穩定性，</b>首先就是當機怎麼辦？如果搭建了一主一備的資料庫政策，就需要保證主機當機之後服務能夠快速恢複起來，并且機房當機之後也要保證服務能夠快速起來。如果發生了地域的災難性事件之後需要能夠在一天或者幾個小時之内迅速恢複服務，而如果資料量非常大時就難以保證資料庫服務能夠在一天之内恢複，這些都是自建資料庫的難點。另外如果資料丢失了怎麼辦？可能業務是正常的，但是被黑客黑掉了，發生了像mongodb黑天這樣的事件或者被sql注入攻擊了，在這樣的情況下業務如何才能快速地恢複起來，還有白名單政策是否足夠好，以及在sql注入将資料删除之後是否能夠迅速恢複sql注入之前的資料庫狀态，并且判斷出是誰對發起的sql注入或者攻擊，這些都是在自建資料庫時需要考慮的難點。除此之外，還需要保證發生誤操作時資料庫的穩定性，雖然mysql有比較合理的權限管理機制，但是像新興的mongodb以及redis等資料庫對于權限管理的處理還是比較粗放的，而在權限管理不合理的情況下，如果觸發了誤操作将可能修改了整個資料庫，此時dba如何才能夠快速地将資料恢複以及恢複後會丢失多少資料都是需要考量的難點。
<b>2.擴充性，</b>當業務快速發展的時候，資料庫如何縱向地更新也需要在自建資料庫時考慮。大家在ecs上可以自由調配資源，如果沒有使用雲服務而是使用的自建機房，當進行活動宣傳時可能出現平時業務的十倍增長量，這使得資料庫的壓力也會急劇增加，縱向的資料庫如何排程也将會成為難點。對于自建機房而言，伺服器的采購周期也會很漫長，而搭建在ecs上就能夠解決這個問題。但還存在一個問題就是資料庫的縱向更新也是存在瓶頸的，即便是ecs也是有固定的配置，當單個ecs已經無法承擔業務壓力的時候，資料庫又應該如何橫向更新也需要在自建資料庫時考慮。舉個簡單的例子，大家都知道redis是單線程的，ecs配置再高也隻能增加記憶體的數量，qps的極限也就是十萬，當業務迅速上來，縱向更新已經達到極限的時候，如何将redis直接橫向擴充為叢集的執行個體，以及擴充成為叢集之後如何進行維護，這些也都是dba需要面對的巨大挑戰。除此之外如何實作異構資料庫之間的資料互通，如何将mysql中的資料定向地導入到mongodb或者hadoop中，或者将hadoop中的資料導入到mysql中，這些都是需要耗費很多開發力量并且需要很多dba的運維工作的。
<b>3.安全性，</b>如果能夠預防sql注入以及網絡攻擊，如何在遭受攻擊的時候終止攻擊，也就是在判斷出這是一個sql注入時，如何将其進行攔截也是在自建資料庫時需要考慮的。還有如何亡羊補牢，在遭受攻擊被脫庫或者删庫之後，在最短的時間内将資料找回并且将業務恢複起來，對于dba而言也是難點。另外就是在遭受攻擊之後，需要追查出攻擊者到底是内鬼還是外部黑客，如果在管理比較混亂時，查出資料庫是如何被删掉的以及到底是誰攻擊的，都是自建資料庫的難點所在。
<b>4.優化和人力，</b>sql慢了該如何進行優化，在前期資料庫管理時如果優化了資料庫的性能就能夠提升網站的整體性能。另外架構演練如何進行更新，比如從原本的隻有mysql的資料庫架構演化成為前端+緩存并且使用更加合理的資料庫的架構，這些都是優化中的難點。
其實除此之外，關系型資料庫的dba還是容易招募到的，但是招nosql領域的dba還是相對比較困難的。那麼在整體運維層面比較困難的情況下，如何最大地發揮資料庫的價值就是阿裡雲推出的資料庫服務的目标。圍繞着在自建資料庫中遇到的難點，就能夠襯托出阿裡雲資料庫産品的使命。
<b>二、apsaradb.概要介紹</b>
之前分享了在自建資料庫中遇到的難點和需要解決的問題，接下來介紹一下阿裡雲的apsaradb資料庫在做什麼以及能夠幫助使用者解決什麼樣的問題。
<b>飛天技術棧</b>
下圖是阿裡雲的飛天技術棧。最下層是阿裡雲的資料中心，其上層是阿裡雲的作業系統和檔案系統，再上一層就是服務部署和資源排程，再上面一層就是任務系統、安全管理以及叢集監控。在飛天技術棧最上面的這一層就是使用者可見的雲服務，這一層大緻分為了七大闆塊：計算、存儲、網絡、資料庫、内容分發、大資料以及中間件。目前阿裡雲資料庫團隊的産品有關系型資料庫rds、包括redis、mongodb、memcached在内的nosql類的資料庫以及金融類的資料庫oceanbase、針對大資料的emr和greenplum以及自研內建了oltp以及olap的資料庫petadata。
<b>阿裡雲資料庫-apsaradb産品家族</b>
下圖是阿裡雲資料庫團隊目前支援的幾款産品，開源類的産品包括mysql、postgresql、mongodb、redis、memcached、greenplum以及hadoop。而在商業化資料庫體系裡則支援sql server的2008和2012兩個版本，以及postgresql的進階版，可以相容95%的oracle協定的ppas，其可以作為oracle使用者上雲的臨時替代方案，另外對于oracle這部分，存在apsaradb的合作夥伴能夠幫助使用者去維護和建構雲上oracle，另外還有hava，也就是apsaradb的合作夥伴sap上線的hana1，在未來不久就可以在阿裡雲上售賣hana的版本。
<b></b>
<b>流量元件</b>
下圖是阿裡雲上的幾個大的流量元件。
<b>1.vpc+slb</b>，在安全性上，阿裡雲提供vpc + slb的模式，這其中的slb是購買rds服務或者redis、mongodb自帶，這個slb其實是内部直接包在rds中的，其主要幫助做四層的負載均衡。vpc的虛拟路由器和虛拟交換機保證在公有雲之上該網絡隻有自己的專有網絡内的使用者能夠連接配接，保障與其他網絡使用者的天然隔離，并且在整個資料庫層面之前會綁定一層針對ddos攻擊的防禦措施。
<b>2.proxy</b>，proxy也是阿裡雲資料庫團隊自研的元件，其主要作用是幫助使用者實作七層的負載均衡。像分布式事務和讀寫分離這些都是在應用場景中幫助使用者解決成本效益問題的，當一個請求過來之後，可以直接通過proxy判斷該請求是讀還是寫，并根據政策分發到讀或者寫節點，不需要應用程式再進行解析和判斷。sql解析一方面就是将請求分析出來并且配置設定到相應的讀或者寫節點，另外就是及時地終止攻擊，這個層面的sql解析還處于研發階段，未來希望通過sql解析來判斷請求中的語句是否存在sql注入的嫌疑，如果使用者選擇讓阿裡雲幫助進行判斷，如果發現的确是sql注入就會在應用程式上直接進行攔截，避免對于資料庫造成災難性的損失。還有一點就是連接配接保持，比如想要對于mysql進行核心修複時，更新版本對于前端而言是非常痛苦的，應用程式就需要全部重連。而在主備進行切換或者主資料庫進行核心更新的時候，如何保證業務不受影響，都需要依靠proxy幫助進行連接配接的保持，而這則會免去對于運維幹擾。
<b>3.db engine</b>，這裡有多種資料複制方式保證rpo和rto在相應的結合模式上進行處理，當對于資料可靠性要求比較高時，可能會選擇雙節點+半同步的模式；而當對rpo要求比較高時可能會選用異步複制的模式，這樣就可以通過db engine來适配多種資料複制模式來解決不同使用者的需求。另外db engine提供了插件式引擎，阿裡雲資料庫團隊提供了大的中台來支撐使用者的服務能力，目前也已經實作了插件式引擎方式，比如在建立資料庫時隻需要一兩個月的時間就可以實作産品的公測和商業化，能夠快速地滿足使用者對于資料庫的需求。除此之外還提供了源碼級定制，資料庫團隊在開源領域吸收了中國頂尖的核心級開發人員來維護源碼級的版本，目前使用的mysql版本也都是去年開源的alisql的版本，其相比于原生mysql核心性能提升了70%，而像mongodb和redis也都能夠從核心層面幫助使用者解決性能問題。
<b>4.ha</b>，使用者使用資料庫一個核心的需求就是穩定，而穩定性需要強大的ha系統來支撐。阿裡雲資料庫團隊的ha能夠幫助使用者進行健康檢查、流量切換以及sla計算。原生的流量切換隻會檢測程式的安全性，當記憶體hang住或者io出現問題時，原生無法切換過來，而阿裡雲的ha政策是嘗試真實地寫磁盤io，保證在受到影響之後ha都可以切換過來。
<b>流量路徑</b>
下圖是資料庫架構的流量路徑，這裡介紹了使用者購買阿裡雲資料庫服務之後的資料流向。下圖存在雙節點，其實雙節點的設計也會存在問題，比如某一機房斷電或者網絡出現故障，資料中心也就會癱瘓了，而阿裡雲的mysql和redis都提供了跨可用區的複制，也就是資料庫執行個體存在多個可用區，當一個可用區出現故障之後可以直接将流量切換到備用機房，保障業務不受影響。下圖展現的大緻流程就是流量到來之後，資料将通過proxy路由到db engine層，db engine層通過阿裡雲内網專線将資料複制到遠端的跨可用區的資料庫節點上，也就是如下圖所示的左邊是主節點，右邊是備用節點，隻不過備用節點平時不會承擔流量，資料正常進行複制。如果發現主節點當機之後就可以直接将流量全部一鍵切換到備用節點上，免除了使用者自己維護穩定性的困難，也同時保障了服務的高可用。
<b>連接配接優化</b>
下圖展現的則是proxy的連接配接保持優勢，其實在資料庫層面往往需要兩個節點，對于大型的雲服務而言，某一台主機壞掉是很正常的情況，那麼在當機或者在資料庫核心更新時如何才能不影響使用者業務，其實背後都是依靠proxy體系支撐的。内部的slb直接連到為使用者提供的proxy上，proxy連接配接db engine，當主機需要更新或者當機的時候，可以把主機的連結斷掉，直接将proxy連接配接到備用節點，而在恢複時連接配接其實并沒有斷掉，在切換時可能會有一兩秒的卡頓，但是對于卻免去了業務重連的處理。總之，整個雲服務就可以依靠proxy實作連接配接保持。
<b>複制方式</b>
目前阿裡雲資料庫服務一共提供了以下四種複制方式：
<b>rpo + rto模式</b>，該模式實作了瞬間恢複以及恢複後能夠找到時間點，在預設的雙節點情況下進行半同步複制，也就是資料必須要到達備端之後才能傳回，是以當主節點當機之後，備節點能夠快速地運作起來，但是這樣性能就會有相應的損耗，因為需要将資料傳輸到備端，如果選用了雙可用區本身還會有3到5毫秒的延遲。
<b>rto + performance模式</b>，這個模式下能夠保證在資料當機之後能夠快速起來，這對于rto不是很高的要求，可能起來之後資料會丢失一些，但是要求性能足夠高，這種模式使用雙節點 + 異步複制。
<b>rpo + performance模式</b>，這種模式下資料宕掉之後可能恢複時間會長一些，可能需要1到5分鐘，但其rpo是沒有問題的，其底層使用了共享存儲并且性能足夠高，并且使用的是單節點。
<b>rpo + rto + performance模式</b>，它使用了多節點、強同步複制以及最終一緻性，目前mongodb的三節點都是複用的這種模式。
<b>三、apsaradb.服務管理</b>
之前概要性地介紹了apsaradb，接下來從服務管理層面為大家介紹與自建資料庫相比，apsaradb的優勢所在。
首先，對于服務可用性而言，阿裡雲的資料庫提供主備架構、同城容災和異地容災模式，可以在半天之内将流量切換到備節點，并且不影響業務，還支援直接在控制台上點選主備切換來演習故障發生時的情況。如果自建資料庫，則需要在自己的ecs上去考慮如何處理服務可用性以及在當機時如何進行切流量的問題。
對于資料可靠性而言，阿裡雲提供的資料庫通過本地raid5實作了線上存儲備援，而ecs采用的是高效雲盤 + ssd雲盤，是以在本地存儲方面兩種方案是差不多的。在離線長效備份方面，阿裡雲apsaradb支援一鍵式将檔案存儲到oss上并且可以存儲延長至兩年，而ecs自建資料庫時則需要自己寫oss腳本來上傳資料。第三方面就是按時間點恢複，就是當出現開發的誤操作或者删除了一個表格之後，需要将資料恢複到誤操作前一秒的狀态，其實apsaradb支援将增量日志和aof日志等全部存儲到oss上。在控制台發起操作之後，背景就會将備份檔案以及增量日志在一個新的時序上恢複起來，資料就能夠直接復原回來。在資料複制方面，apsaradb支援異步 + 半複制的方式，則使用ecs自建資料庫則需要自己進行配置。
在資料安全性部分，目前apsaradb支援白名單分組，而ecs則是支援安全組，在未來四、五月份的時候資料庫團隊就會将白名單分組取消，并将其和ecs安全組融合起來，解決目前客戶在使用時的體驗較差的問題。在審計日志方面，apsaradb會依靠内部的系統将sql的審計日志收集起來并且存儲到遠端的存儲中，使用者可以定期地将sql審計日志拉到本地進行檢視，而且這個系統對于整體的性能損耗并不大，但是可以實作有蹤可查，當發生問題的時候，就可以知道到底是誰發動了攻擊，以及時間點、所使用的ip以及進行的操作。在網絡加密和存儲加密方面，阿裡雲資料庫也處于比較領先的位置，apsaradb經過資料庫的的等級認證，目前已經支援了ssl網絡加密以及tde存儲加密。如果選擇了tde存儲加密，即使資料被拖走對方在沒有密匙的情況下也無法解析自己的資料，這部分在金融行業裡也是要求非常嚴格的。
在監控與報警部分，阿裡雲資料庫支援資源類的監控，也就是對于執行個體的cpu、記憶體、磁盤等的資源進行監控，還有就是引擎層面的監控，對于mysql、redis以及mongodb等引擎層面的監控。在資料庫引擎層面存在很多可以監控的名額，這些都可以通過圖形化的方式展現給使用者。在秒級監控部分，apsaradb支援300s和60s的監控模式，後續還可能對于像緩存等業務實作更細的粒度。并且apsaradb支援雲監控的報警，對于資料庫的監控名額而言，當發現這些名額出現異常時可以通過雲監控直接向運維人員的手機或者郵箱發送報警資訊。
在參數管理部分，apsaradb可以在資料庫運維層面為使用者提供參數模闆和修改曆史以及開銷的分析。
在性能優化部分，阿裡雲資料庫會為使用者提供一套系統來幫助使用者審查所有的sql日志，并對于日志進行相應的去重分析來判斷對于sql應該加什麼樣的索引以及對于某張表應該如何處理給出相應的建議。
而一站式服務就是對于阿裡雲資料庫整體的生态提供的工具。阿裡雲資料庫提供了資料管理的工具，大家使用mysql可能知道有navicat等，在ecs上自建資料庫時可以裝上這樣的工具，但是對于像mongodb以及redis這樣的資料庫，可視化的資料庫管理工具卻是很少的，現在的dms可視化操作工具已經和阿裡雲資料庫完全結合，可以支援sqlserver、pg、mysql、memcache、redis以及mongodb等所有的引擎，購買了阿裡雲的這些資料庫之後就可以直接以圖形化的方式進行管理了。而對于資料同步方面，對于如何輕松地将hadoop中的資料同步到mongodb中，或者對于兩個同構的資料庫如何進行資料同步以及如何實作增量同步的同時不影響業務而言，阿裡雲的整個資料同步工具是非常健全的，首先對于雲上雲下的同構的資料庫同步來說，阿裡雲資料庫都是支援全量 + 增量的，比如使用者在ecs上有mysql和mongodb資料庫，就可以直接選擇dps實作全量和增量的資料同步，目前對于異構資料庫而言也是支援oracle到ppas的。資料同步這部分也是在迅速地發展，後續也會加更多的引擎進來，将會實作更多的資料庫的異構同步來打通資料庫的整體生态。
<b>資料安全</b>
下圖展現了阿裡雲資料庫可以從幾個次元幫助使用者建構事前、事中和事後的安全防範措施。在事前阿裡雲資料庫會使用vpc專有網絡形成隔離的網絡環境，另外還會要求使用者設定精細粒度的白名單，而且所有的資料庫都是要求強密碼認證的。在比如像mongodb的黑天事件中，其實根源在于使用者将自己的mongodb的ip位址暴露于公網之上，直接導緻黑客有了入侵的機會，是以阿裡雲對于nosql的資料庫都需要強制使用者設定強密碼，并且不會暴露公網ip供外網調用，保證資料庫處于一個相對比較安全的網絡環境内。在事中還會使用ssl的網絡加密以及tde的資料加密。在事後的防範中還使用了一整套詳細的審計日志，當真正發生了問題之後可以将審計日志調出來檢視誰在什麼時間點對于資料庫進行了什麼操作。除此之外，最後還有一套克隆執行個體保證資料庫能夠實作資料秒級恢複。
<b>監控報警</b>
下圖介紹的是阿裡雲資料庫的監控報警能力，目前阿裡雲rds正在打造一套整體中台，也就是内部的“天象”的指揮端的系統，這個系統能夠幫助使用者将流量從ecs上直接打通到rds上去的所有網絡延遲監控下來并展現給使用者，使得使用者能夠了解rds或者mongodb在一定時間内的壓力負載究竟在哪，知道qps反應比較慢的時候究竟卡在哪個鍊路上，到底是ecs出網口的問題、ecs到rds鍊路的問題還是rds引擎層面的問題，這些都會通過鍊路的監控圖展示給使用者。
<b>性能優化</b>
對于阿裡雲資料庫的性能優化部分，可以分為如下圖所示的資源分析、引擎分析、sql分析以及專家系統這四大部分。
<b>四、apsaradb.解決方案</b>
<b>異地容災解決方案</b>
第一個是在雲上實作異地容災的解決方案，比如在金融行業會需要考慮的一個可用區出現問題的場景下衍生出的服務就是異地容災，可能資料庫的主可用區在上海，而備可用區在深圳，當上海這個主可用區出現兩個機房都癱瘓或者城市發生了電力故障不能提供服務的時候，都可以通過一定容災模式保證服務的。而異地容災的架構是需要所有的阿裡雲産品進行配合的，但其中最難做并且最重要的還是資料庫。其實沒有資料的部分是很好做容災的，但是一旦涉及到資料就會很難實作。如上圖中的解決方案所示，其支援的是兩地四中心的概念，兩個節點在不同的可用區之内，兩個節點之間通過原生複制的方式實作資料同步，而自己搭建資料庫時異地複制就會出現困難，如何保證資料能夠追上并且rpo和pto處于合理範圍之内都是難點。
<b>混合雲解決方案</b>
對于混合雲的解決方案而言，其實實作混合雲架構的難點還是在資料庫，隻要在有資料的地方實作多中心的同步都會比較困難。如上圖的架構中左邊所示就是如何将雲下機房和雲上機房進行資料互通和同步，而右邊則是如何将阿裡雲上的資料同步到雲下，這個場景都是真實存在于很多的金融場景中的，金融行業可能以雲上作為備份、雲下為主，還有一些新興的金融行業因為其業務是依靠雲發展起來的，而又因為需要合規是以需要将資料備份到雲下，是以采用了雲上做主、雲下做備的方式。這套混合雲解決方案還是依賴于整體的同步機制，雲下到雲上的的同步可以直接拽一個backup上去存儲到對端之後，再通過增量資料将兩部分資料一直挂同步和同載實作雲上和雲下的同步。而雲上到雲下的同步就是會将mysql的binlog或者mongodb的oplog直接開放權限給dts服務，将資料通過通道傳輸到遠端的自建資料庫中，進而完成混合雲的架構。
<b>快速部署解決方案</b>
上圖展現的是一個快速部署的場景。快速恢複的功能支援整體的克隆執行個體，可以基于備份檔案将資料整體克隆出來，并進行快速部署。而flashback功能是阿裡雲資料庫團隊的彭立勳開發的，目前已經整合到mariadb版本中并成為了其中核心的功能，這個功能主要就是抓起binlog檔案。因為平時做資料恢複時需要保證一個全量的備份，而flashback的開發直接将binlog的資料收集到裡面，保證在很短的時間之内能夠将資料恢複出來。對于flashback功能感興趣的同學可以到網上進行詳細了解。
<b>實時計算解決方案</b>
最後的場景展現的實時計算的解決方案，目前很多業務都要求ltp和lap兩套機制。本身的一套資料庫系統可能是實作ltp的，也就是正常的增删改查，還有一套系統需要将資料拉回來做lap和分析，正常都是有一套lap的資料庫每天定時将ltp的資料直接同步到lap中，而這個同步也是非常痛苦的。實時計算的解決方案希望在一套架構中為使用者解決lap和ltp的問題。阿裡雲的petadata産品目前正處于邀測階段，預期會在三月底進行商業化，petadata能夠通過一套存儲機制幫助使用者解決lap和ltp的問題，大家有興趣可以關注一下。