近期，炫一下（北京）科技有限公司（簡稱“一下科技”）短視頻產品“秒拍”完成了一個“大動作”——將原來部署在虛擬機上的主體業務遷移到華為云，同時將公司的技術體系承載在下一代虛擬技術容器（Docker）上。而這一系列動作是在業務不下線，用戶無感知的前提下完成的，秒拍是如何做到的？

秒拍是一個媒體屬性很強的業務，在用戶規模達到一定體量后，由明星熱點事件引發的流量突發狀況非常嚴重，而傳統虛機業務存在擴容響應速度慢，成本高等一系列問題，于是秒拍想到了容器。容器服務擁有啟動快速、占用資源少、運行效率高等技術特點，在處理海量數據方面擁有天然的優勢。但是如何保證業務能夠快速無縫地進行切換，讓最終用戶毫無感知的完成從虛機到容器的遷移，真正要做到這一點非常困難。

盡管困難重重，但秒拍在評估了未來業務需求和技術團隊規模之后，還是選擇將已部署在云上的主體業務遷移到華為云CCE上。而華為云強大的技術支持能力和服務團隊，為這次遷移解決了后顧之憂。

以下是秒拍架構師李東輝對本次業務遷移的記錄，如果你也希望從虛機向更靈活的容器升級，又不希望影響業務，不妨一看：

背景

我們現在主體業務已經是部署在某云上了，但整個技術體系，還是基于傳統的虛擬機去承載的，由于我們產品本身的媒體屬性，導致了不可避免的會經常遇到突發流量，相比于一直比較平穩的流量，這種對服務端的考驗更高，核心關注點還是在怎么保障在這種時刻用戶都能得到良好的體驗。

另一方面，由于云平臺本身的一些不可抗力因素，不能保證百分百的高可用，怎么降低單點依賴的風險，也是我們需要重點考慮的。

經過綜合性的權衡，我們決定把主體業務遷移到華為云，并且優化升級原來的架構，以便更好的支撐海量用戶訪問。前端機也從VM過渡到docker，遷移后的整體架構圖如下

各個資源的遷移過程

1. mc遷移

現在業務上使用mc只是做臨時緩存，cache miss會從存儲（DB、ES等）拉一份寫進去，并且業內也沒有比較成熟的mc存量與增量遷移方案，所以這部分數據可以忽略，等上線前，預熱一部分熱點數據進去。不過使用上有一些區別，原平臺使用的是服務端集群，現在是客戶端集群，需要建立MC連接的時候，添加所有的服務器列表以及權重。

2. mq遷移

mq主要用來解耦業務模塊，生產端生產一份數據，消費端可能有多個，遷移的話，需要先配置好資源的vhost，exechange還有queue，服務端先更新配置上線，數據寫入到新資源，消費端在舊資源消費完成后，切換到新資源的消費上。

3. redis遷移

redis的遷移需要區分兩個場景的數據，一個是緩存數據，可以按照mc的遷移策略忽略，另一部分是持久化數據，主要是業務上的各種計數，這部分數據要求盡量精確快速的遷移到新資源，當時考慮了兩種方案

· 一種呢，是基于快照文件遷移 存量數據可以通過RDB快照，只需要原平臺有備份RDB的權限，在新資源通過快照回放完成全量數據的遷移。 這種方案優點比較突出，操作簡單快速，但缺點是不支持增量同步。

· 另一種呢，基于業務遷移 首先，讀 優先從新資源讀，沒有命中的從老資源讀取一份，寫入到新資源并返回這個值。 其次，寫 （incr decr操作） 優先更新老資源，并且按照更新后的返回值寫入到新資源。

這種方案能兼顧存量與增量數據，但存在的問題是，讀寫新老資源的過程非原子性，理論上高并發情況下會存在一定誤差，并且業務上的這種改造增加了后期的維護成本，另外，從性能方面考慮，原來一次連接（短連接）、一次redis操作就能搞定的事，現在都需要兩到三次。

綜合現在的業務量考慮，我們采取了第一種方案，但是時間點選在凌晨四點低峰時段，將影響范圍盡可能降到最低，后續通過落到DB的數據做統計恢復。

4. db遷移

db遷移相對比較容易，全量數據預先復制一份過去，增量數據因為都是基于binlog訂閱，只需要獲取原平臺DB的權限，就可以通過binlog同步到新數據庫。

這里需要注意的是一個主從同步的問題，新資源主從是半同步復制，主庫只需要等待一個從庫節點收到并且 Flush Binlog 到 Relay Log 文件即可，同時，這里只是一個收到的反饋，而不是已經完全完成并且提交的反饋，這時候，主庫就會進行其他操作，相比與之前的全同步的事務復制，節省了很多時間，但是也造成了新的問題，即：主從有理論上1ms的延遲，實際測試延遲時間是0.5-0.8ms，這在“更新DB后又立馬讀取一次DB數據”的場景下會有問題，并且根據Cache Aside Pattern的緩存更新策略，DB更新成功會直接刪除緩存，由于主從延遲，這時候讀進程讀取到老數據并且寫入到緩存，從而導致了一段時間內的臟數據。

有一個比較快速的方式能夠解決這個問題，那就是在DB更新成功后直接更新緩存，但是這樣處理后會產生新的問題，并發的寫操作，又會導致同一資源key的臟數據，不過是概率大小的問題。這就涉及到了取舍，就像為了保證DB、cache的強一致性，采用2PC（prepare, commit/rollback），大大降低性能一樣，軟件設計從來都是取舍。

5. ES遷移

ES主要服務的是APP以及Admin后臺，用戶、媒資等數據的搜索，數據源在DB，所以存量數據直接從DB拉一份進去，增量數據通過監聽DB更新，同步到ES里。

6. 版本庫遷移

版本庫的遷移主要是方便接入鏡像構建與k8s部署，同時呢，項目使用到的資源鏈接地址、用戶名、密碼等也需要更新，這部分都是統一配置，直接修改就行。

7. 服務發現

原來業務上都是基于服務端發現的模式，一個微服務對應著一個LB，通過DNS解析到對應的LB IP，LB實現VM的負載均衡策略與保活機制。LB下層現在多了一層k8s的調度，k8s調度的單元也不再是VM，而是Pod(邏輯主機)，在這里VM的存在也僅僅是提供不同規格的物理資源。

其次使用DNS解析也可以方便不同VPC子網指向不同的資源IP，例如測試環境與生產環境，項目使用到的資源地址是相同的，只不過解析到了不同的資源。

8. Dokerfile

需要預先制作好基礎鏡像，包含基本的php、nginx環境跟用戶權限這些，Dokerfile主要實現將項目代碼復制到容器。

9. 切流量

后端資源遷移完成，準備就緒以后，就可以開始切公網流量了，非核心業務直接修改公網DNS，解析到新LB IP，核心業務LB上層還有一層高防，在高防不變的情況下，只需要修改高防源站IP到新LB就行。

流量遷移完畢后，全線驗證，觀察錯誤日志，當然這個過程并不是只有等流量切完才會開始，而是從資源遷移開始就一直持續進行的。

10. 部署上線

原來的部署是通過中控機，將代碼分發到各個線上服務器，現在呢，需要使用上一步創建的Dockerfile，構建鏡像，將構建好的鏡像通過k8s滾動升級（先kill老鏡像，再派生出新鏡像）。升級的步驟如下：

push后鏡像已經推送到私有倉庫，現在需要創建k8s的配置文件用于管理和升級容器。

創建pod kubectl create -f miaopai.yaml 后邊再升級容器，先把容器更新push到倉庫后，修改image地址，通過apply進行升級就可以。

架構優化

架構優化的目標是分析現在業務上存在的問題，并針對性的優化解決，結合壓測結果，主要確定了幾個優化點。

1. mc、redis的優化

mc使用上存在的問題是，只有在存儲查詢到的情況下才會緩存數據，這樣就會導致很多空查詢落到存儲，解決這個問題只需要將沒有查詢到數據的情況，也寫一份空數據到緩存就能解決。

除此之外，mc的批量查詢，存在太多的偽批量（redis也存在)，例如：foreach每次循環里都使用get查詢，需要將這樣的處理都改成multiget的形式，不過multiget在集群的情況下會存在hole現象，這個問題最早是由 facebook 的工作人員提出的

facebook 在 2010 年左右,memcached 節點就已經達3000 個.緩存數千 G 內容.他們發現了一個問題-memcached 連接頻率,效率下降了,于是加 memcached 節點, 添加了后, 發現因為連接頻率導致的問題, 仍然存在, 并沒有好轉,稱之為”multiget hole現象”。請求多臺服務器并不是問題的癥結，真正的原因在于客戶端在請求多臺服務器時是并行的還是串行的！問題是很多客戶端，包括Libmemcached在內，在處理Multiget多服務器請求時，使用的是串行的方式！也就是說，先請求一臺服務器，然后等待響應結果，接著請求另一臺，結果導致客戶端操作時間累加，請求堆積，性能下降。

有推薦根據key做hash的，這樣就可以使得相同key前綴的數據分布在一臺機器上，但是這樣又會導致新的問題，例如：增加業務復雜度，每個節點的數據分布不均等等，不過相信大部分公司業務的體量都沒辦法對標facebook的，如果真的到了需要考慮這個問題的時候，其實是推薦使用redis的pipeline并行機制來解決的。

2. 核心業務的降級策略

作為APP內首屏的幾個tab，數據都是從推薦系統中獲取，一旦推薦系統掛掉，基本沒有了用戶體驗，所以必要時還是需要采用熔斷降級策略，降級策略相對來說，只需要保證用戶能獲取到部分列表數據，即使所有用戶獲取到的數據都一樣。實現上呢，先把部分列表數據存儲到cache，一旦發生熔斷，那么數據從推薦系統讀取的渠道會直接切斷，轉而從cache里讀取返回給用戶。但是有一個問題，讀取的這個流程應該是由業務完成，還是由前端web服務器（nginx）直接完成呢。我們目前采用的后者，一方面使用ngx_lua能保證系統的吞吐，另一方面不僅僅是推薦系統，即使在服務端整體掛掉的情況下，也可以繼續提供服務。

觸發熔斷的條件可以有很多，例如：每20個請求中，50%失敗，當然了，失敗包括響應失敗跟超時，也可以根據當次請求結果來判斷。熔斷的條件其實并沒有什么標準，更多的是依照以往系統的經驗來一步步調整。在以前并沒有很多熔斷經驗的情況下，盡量擴大這個閾值，隨著經驗的一步步積累，再確定各個模塊比較合理的熔斷條件和降級策略。

3. 負載均衡策略

傳統負載均衡LB，實現的是請求到VM和端口的負載均衡，容器化之后，LB下層掛載了k8s集群，實際上這里的負載均衡除了LB的，還有k8s的，即請求到達節點（VM）后，再負載均衡到不同的容器。

上邊提到的負載均衡只是四層（IP加端口），如果要根據應用層的信息，比如：URI，cookie等等，做負載均衡，就需要使用七層LB，我們使用到的場景，主要是還沒有切割成微服務的大單體，根據URI，將不同模塊的請求打到不同的四層LB。

4. Mysql HA

Mysql作為我們底層的核心存儲，必須要保障它的高可用，現在架構是采用主從+主備的形式，不過這兩種方式都有個共性的問題，主機故障后，無法進行寫操作，如果主機一直無法恢復，需要人工指定新主機角色。優化的目標也顯而易見，就是設計雙機切換，在主機故障之后，能夠自動切換到其他主機。

PHP本身實現了mysql的負載均衡和failover策略，需要依賴插件mysqlnd_ms，詳見https://php.net/mysqlnd_ms，不過僅限于PHP5.x版本，倒是有支持PHP7.0以上的非官方版本，https://github.com/sergiotabanelli/mysqlnd_ms，但如果直接用在生產環境，并不十分明智，并且mysqlnd_ms需要特殊格式的資源配置，在一個項目里維護兩份資源配置，也會帶來新的復雜度問題。

要實現雙擊切換的核心點在于，對主機狀態的判斷，和狀態決策，可以通過引入一個中介角色，主機和備機把狀態傳遞給中介，由中介完成決策功能，但引入中介的角色并不是沒有代價的，那就是要考慮中介角色的高可用。這就陷入了一個遞歸的陷阱：為了實現高可用，我們引入中介，但中介本身又要求高可用，于是又要設計中介的高可用方案……如此遞歸下去就無窮無盡了。

MongoDB的Replica Set采取的就是這種方式，基本架構如下：

幸運的是，開源方案已經有比較成熟的中介式解決方案，例如：Zookeeper和Keepalived。ZP本身已經實現了高可用集群架構，因此已經解決了中介本身的可靠性問題，在實踐中也推薦這種架構。

5. 日志與監控

線上日志的定時收集反饋也是必不可少的，日志包括服務器的access_log，error_log，當然還有業務的自定義log。收集的目的主要是用來統計一段時間內的http code 分布、響應時間和錯誤信息。

通過在實例跟資源上部署agent，定時收集CPU和內存信息也是必要的。統計型的數據需要收集匯總成表格，方便觀察，各種指標的閾值也需要提前設置好，超過閾值后能夠及時報警，通知到責任人。當然了，監控不是最終目的，及時巡檢線上資源、接口，排除系統隱患，防范于未然才是終極之道。

不得不說，互聯網企業把大多數業務部署在云服務器上，現在已漸成趨勢，但由于歷史原因，技術往往是架設在傳統的虛擬機（VM）上。如果企業要過渡到下一代虛擬技術容器，會涉及到各類資源遷移和技術架構優化，整個過程是必須短暫而痛苦的。但如果沒有相應規模的技術團隊來操作，再加上云廠商沒有完善的技術支持團隊，這個過程會更加痛苦。如何減少企業業務升級的痛苦，這就非常考驗企業技術決策者的選擇智慧！華為云，目前已經展現出了在技術服務的獨特優勢，未來肯定是擺在企業面前最具競爭力的選項之一。