快狗打車CTO 沈劍
快狗打車原名58速運，是同城即時貨運平台。目前支援拉貨、搬家和運東西等一些業務。本文講述了快狗打車上雲的緣由，如何平滑地、客戶無感覺地上雲以及上雲給快狗打車帶來的價值。
我們先思考一些問題：為什麼要上雲？
第一，成本考慮：快狗打車作為初創公司，未必有資源組建大規模的運維團隊，dba團隊，sa團隊，是以成本這塊是我們考慮的。
第二，可用性考慮：我們可以自建機房，但目前我們沒有信心比阿裡雲做的更好。
第三，擴充性考慮：快狗打車作為快速發展的公司，按需使用，對于機房的擴充性，對于機器的擴充性是有非常強的要求的。如果像傳統的網際網路公司，如果要擴容，可能需要季度初做預算規劃，像一些大促活動，明天要做活動，今天就擴容。
最後，是服務能力考慮：不管是資料庫、緩存、搜尋、大資料、監控等等，如果我們從頭都自己來的話，可能會比較耗費時間，而且搭建的服務可能也沒有已有的雲能力那麼強。是以這裡我們的結論是讓專業的人做專業的事情，少造輪子，讓我們就專注在業務研發，雲的一些能力交給專業的雲去做。
上雲之前，看一下我們的架構，我們最早是在一個自建機房裡面的。我們是一個典型的大規模的網際網路應用，架構特點是并發量非常的高，流量非常的大，資料量非常的大。對于架構有可用性，擴充性的要求，而且我們實施的是微服務分層架構，整個在遷移之前，我們其實是一個單機房的架構，如果讓我用一個詞來形容的話，那就是全連。
大家可以看一下上面左邊的架構圖，我們原來在機房A。端上是我們的PC站、M站以及APP。然後我們的後端服務的這一塊，整個機房的這一塊分為了三層：
（1）站點層是我們所有的web應用；
（2）中間是服務層，我們有很多業務service，以及基礎service；
（3）最底層是資料層，我們有資料庫，資料庫我們主要是用MySQL；我們有緩存，我們主要用的是memcached和redis；然後還有一些圖檔的服務。
為什麼說它是一個全連的架構呢？你會看到我們的web層一個叢集有多個節點，服務層一個叢集有多個節點，你會發現它是一個節點會連接配接下層的所有節點，業務service調用基礎service，一個節點會連接配接下層的所有節點，基礎service調用資料層一個節點會連接配接下層一個叢集的所有節點，是以它是一個全連的架構。
我們機房遷移的目标是什麼呢？
上面右邊的這幅圖，左邊的一半是我們原來的機房架構，另外一半可能最終我們要将我們所有的系統架構遷移到雲上，遷移到雲上你會發現從反向代理，到web，到業務service，到基礎service，到db，全部要部署一套。最早的話是左邊的一半，然後最終要到右邊的一半。中間是專線和公網進行連接配接。在這個過程中，最難的，也是我們遷移的目标，是要平滑。因為牽扯幾乎所有的業務，所有的部門需要關聯，如何做到平滑、螞蟻搬家式的遷移，并且保證這個資料的一緻性，業務的一緻性，流量的平滑，是我們機房遷移的首要目标。
我們如何做到平滑呢？
很容易想到的方案是，我們把所有的業務系統從站點層，到業務服務層，到基礎服務層，到資料層，在阿裡雲全部部署一套，然後在某一個時間節點，舊機房終止流量，流量全部切到新機房。但是這種方案的風險極高，因為我們有非常多的業務，非常多的機器，可能站點都有幾千個，服務可能有幾百個，然後資料量也非常的大。如果一次性進行遷移出現任何問題的話，可能都會導緻服務不可用。是以這種方案明顯是不可行的。
我們所謂的平滑是什麼平滑呢？我們所謂的平滑有4個特點：
第一，可分批。可以一個業務一個業務地遷移，我們大大小小可能有幾十個業務，每個業務可能要有一些子系統，每個子系統是可以分批遷移的。
第二，可以分層遷移，就是對于同一個業務子系統，你可以先遷站點層，再遷業務service層，再遷資料service層，再遷資料層，可以分層的遷移。當然遷移的方向可能是自頂向下的，也可能是自底向上的，你可以先遷資料層，最後再遷應用層再切流量也是可以的。
第三，在任何一個步驟我們都要是可復原的，任何一層在遷移的過程中可以随時切回流量，并且保證業務不受影響。
第四，整個過程中我們要不停止服務，整個過程對于使用者是透明的，使用者是無感覺的，全部是保持HA的，這個是我們平滑遷移的目标。
要平滑的話，你會發現其實短暫的多機房架構是不可避免的，左邊是我們最初的機房，右邊可能我們要遷移阿裡雲，我們是螞蟻搬家分子產品分層地遷移，一定在中間有一個臨時節點，兩邊的機房都有流量。這個過渡的過程，你會發現它其實是一個多機房的架構。
多機房多活的架構的特點是什麼呢？用一個詞來概括，其實是同連，你所有層次的連接配接，要連同一機房，站點層連服務層隻能連同一機房，業務服務層連基礎服務層隻能連同一機房。但是這裡面有一個問題就是資料層，你為了防止資料不一緻，其實你隻有一個寫庫，是以不可避免的有少量的請求必須跨機房，你不能夠做到完全的同機房連接配接，但是我們能夠做到最少的跨機房連接配接請求，是以你會發現整個過程它不是一個純多機房多活的架構，是一個僞多機房多活的架構。純同連的是有一部分，這架構圖裡面就是基礎service調用資料庫主庫的時候，它是跨機房的，但是web層調用業務service，業務service調用基礎service，基礎service調用db，你會發現都是同機房連接配接的。這個多機房，或者叫僞多機房的多活的架構，它最大的關鍵詞是同連，單機房的話其實是全連。
自頂向下的平滑遷移方案
我們知道了在遷移的過程中不可避免的有多機房的多活的一個方案，然後我們在制定平滑遷移方案的時候又有兩套方案，一套是自頂向下的遷移方案，就是我們先遷站點層，再遷業務服務、基礎服務，最後遷資料庫。還有一種方案是自底向上的方案，可以先遷資料庫，再遷基礎service，再遷業務service，再遷web應用。兩種方案都是可以的。然後我們實際采用的是自頂向下的遷移方案。
我們來看一下我們的遷移步驟，所謂自頂向下，那肯定是先遷上層的站點層和服務層。
我們的第一個步驟，左邊是m6，是我們的舊機房，右邊是我們待遷移過去的阿裡雲的機房。我們第一步，搭建相關的站點和服務，比如說你有一個業務子產品想要遷移，你就在新機房搭建反向代理層、站點應用層，部署好後，搭建業務服務層、基礎服務層，然後把DNS也提前做好。資料層你會發現此時是不變的，資料層和緩存層還是通路舊機房的服務。
搭建好之後，第二步逐漸切流量。你把一個小的業務子產品的流量的5%，切到了阿裡雲，然後這5%的流量會走阿裡雲的nginx反向代理層，web應用層Tomcat，業務服務層和基礎服務層，但是你會發現它的緩存和資料庫仍然是通過專線通路原機房的，因為此時緩存層和資料庫層還沒有遷移，也不會引發資料不一緻。有一部分流量切到了阿裡雲的新機房，此時如果你發現異常，可以迅猛的将5%的流量切回來，這樣的話其實整個業務又恢複了，因為整個資料還是在原機房的，發現問題可以随時復原。如果沒有問題，就逐漸的放量，5%、10%、20%、50%、100%，把這個子產品的所有反向代理、web應用、業務service和基礎service就遷到了阿裡雲。這樣的話你的一個小業務的站點層和服務層就遷移完了。遷移完之後，舊機房也不用急着下線，因為還預留了一個復原的方案，你會發現這是一個螞蟻搬家式的，你可以一個業務遷過去，再一個業務遷過去，再一個業務遷過去都是沒有問題的。
先進行了站點層和服務層的遷移之後，接下來是緩存層的遷移。緩存層遷移之前，你會發現其實整個反向代理、站點應用、業務service和基礎service的流量都已經到了阿裡雲上，相當于入口的所有流量都已經進了阿裡雲了，隻是說你的緩存和db其實是通過專線通路的原來的機房。
緩存這裡也是螞蟻搬家分子產品遷移，第一步，你先搭建某一個子產品的緩存，在新的阿裡雲機房上搭建緩存，然後再切流量之前，你要把内網的緩存域名和IP進行修改。你的業務service和基礎service是通過域名去通路緩存的，最早這個域名是指向舊機房的緩存，你要把它修改為指向新機房的緩存，修改完之後流量是不是就過來了呢？
并不是的，是因為緩存的連接配接，很多時候是長連結，你必須經過步驟三：切斷原有的舊連接配接。相當于 service通過專線連接配接cache的連接配接你要切斷，切斷的話，其實緩存的用戶端它會有重連機制，它會重新連接配接緩存域名，但是此時你已經将緩存域名切換到新機房阿裡雲上了，是以它會自動的連接配接阿裡雲上的緩存，這樣的話緩存就切過來了。
你會發現這種方式它并沒有進行緩存裡的資料遷移，它隻适用于允許cache miss的緩存，但是99%的業務場景是允許cache miss的。如果你緩存裡這個為空，可以去資料庫裡去取相關的資料。這種方案還有一個好處，就除了它是按業務按流量逐漸遷移，螞蟻搬家式遷移之外，你會發現業務層是無需重新開機的，隻需要運維統一操作，統一的修改内網域名的指向，統一的切斷舊連接配接，重新指向新連接配接就可以了。就相當于業務的系統是不需要重新開機服務的，隻需要配合觀察業務的可用性和業務是否有異常就可以。
緩存層遷移完了之後，最後是資料層的遷移，資料層遷移你會發現遷移之前所有的站點服務和緩存都已經遷移完了，但是資料庫的流量還是通路舊的m6機房的。此時你先要進行資料庫的搭建和資料的同步，因為此時阿裡雲的rds上是沒有資料的。沒有資料，你就在阿裡雲上搭建rds建庫建表，然後通過 dts或者是你自己的工具，将資料從原機房同步到阿裡雲上，在同步完成之前，還是依然是舊的機房的資料庫提供服務的。
同步完成之後到某一個節點，你認為幾乎同步上了，這個時候我們進行步驟三，原機房進行一個 read only 操作，不能讓原機房的資料再進行修改了。Service修改配置重新開機指向阿裡雲的新機房，整個過程中可能有秒級的服務不可用，是以這個操作必須在流量低峰，淩晨的時候進行。秒級的 read only ，寫不可用，以及秒級的流量切換，然後他也是可以支援螞蟻搬家式，一個庫一個庫，一個子系統一個子系統地遷移的，是以風險也非常的小。
然後我們在遷移的過程中還發現了阿裡雲的工具的一些不足。這裡也給阿裡雲提幾個建議。DTS資料同步工具早期的話隻支援公網的資料同步，通過專線進行資料同步，其實可以極大的提升資料同步的速度。第二個建議是好像rds是不能夠支援定制化端口的，是以必須修改配置重新開機。像我們原來老機房資料庫的端口是58885，但是遷移到阿裡雲就必須使用3200，這樣的話你的業務服務必須修改配置，不能夠通過像緩存一樣統一的運維側的切斷重連。最後一個建議是如果DTS它支援資料庫的這種Master-Master架構的話，其實風險會更小一點，現在好像是不支援的，如果支援Master-Master架構，那麼其實原機房和阿裡雲機房做一個Master-Master架構，這樣的話其實可以來回切可復原，可能風險會更小。
我們通過這樣的步驟，從站點層、服務層，服務層可能又分為業務服務層和基礎服務層、緩存層以及資料庫層，一步一步的螞蟻搬家式的随時可復原的高可用的、平滑的對業務無影響的，把整個大幾百台服務上的所有站點、應用、服務、資料、緩存全部平滑的遷移到阿裡雲上，整個過程耗時了有一個多季度，四五個月，但是對業務對使用者是透明的，是無感覺的。
遷移完成之後，我們現在的話相當于整個業務是在雲上了，我們後續有什麼樣的一些規劃呢？方向上還是充分發揮雲的優勢。我們自身專注在業務研發上，讓一些基礎設施基礎體系基礎服務交給雲去做，後續至少我們有兩項計劃，第一項我們原來的大資料體系也是自研的，有專門的團隊，然後有專門的機器搭建了一些基礎設施，後續也是計劃全面的遷到阿裡雲上，用MaxCompute來替代，我們算了一下，應該成本能夠節省不少，而且擴充性也比較好。第二塊是原來我們在自己的機房上是有全套自研的監控體系的，包括調用鍊跟蹤、服務的監控、一些基礎資源的監控、機器運維層面的一些監控。我們現在也是準備切換阿裡雲的監控體系，當然現在還是在調研中，然後通過與阿裡雲的協作，給我們的業務也是帶來了不小的價值，成本上有所降低，可用性加強了，擴充性，毋庸置疑，随時可以加機器，随時可以擴縮容。服務的能力也是非常強的。
最後總結一句話，還是讓專業的人做專業的事情，少造輪子，讓我們自身專注在業務研發中。
謝謝大家！
更多大資料客戶實戰案例：
https://developer.aliyun.com/article/772449