摘要：導(dǎo)讀在今年騰訊云峰會上，開源技術(shù)同樣是一大亮點(diǎn)。此文是微票時代技術(shù)副總裁楊森淼在現(xiàn)場有關(guān)微票兒的實(shí)踐之路分享的實(shí)錄。

在今年騰訊云峰會上，開源技術(shù)同樣是一大亮點(diǎn)。作為開源技術(shù)的集成平臺，Cloud Native 專場給各家提供了針對 OpenStack 應(yīng)用以及背后填坑之路作深度探討的機(jī)會。
此文是微票時代技術(shù)副總裁楊森淼在現(xiàn)場有關(guān)《微票兒的 Cloud Native 實(shí)踐之路》分享的實(shí)錄。

我跟大家分享的是我們在實(shí)踐之路上踩過的坑，我們做 Cloud Native 已經(jīng)做了一段時間了，我們主要以微服務(wù)+Docker，加其它的方式，從研發(fā)測試到部署整體的實(shí)現(xiàn)了我們的業(yè)務(wù)流程化運(yùn)行。我們在一開始把這個事情想得很美好，我們是一個電商票務(wù)平臺，我們大體的分為兩個方向，第一個方向是交易，另外一個方向就是做用戶信息、電商推薦等等。另外我們現(xiàn)在的語言也非常多了，我們要實(shí)現(xiàn)持續(xù)交付和整個管理的流程化。我們所有的服務(wù)都是在云上。

想得挺好的，但是做起來還是挺難的，我們在做的過程中會發(fā)現(xiàn)，云服務(wù)確實(shí)是挺不錯，業(yè)務(wù)結(jié)構(gòu)簡單，耦合度小，獨(dú)立部署，方便隔離，可以使用不同的技術(shù)站，程序員想怎么玩都可以，只要他在自己隔離的環(huán)境里面，但是調(diào)用開銷增加、服務(wù)依賴性復(fù)雜、數(shù)據(jù)一致性難保證、運(yùn)維的成本成倍的增加。

所以首先我們遇到的問題，組織結(jié)構(gòu)要不要一起調(diào)，對數(shù)據(jù)進(jìn)行改造，不同的實(shí)體業(yè)務(wù)要不要繼續(xù)拆分，聯(lián)合查詢變成了多次的查詢，對不同的業(yè)務(wù)共享數(shù)據(jù)單機(jī)的事物不夠，然后是系統(tǒng)重構(gòu)期間雜亂無章的依賴，造成數(shù)據(jù)的不一致，導(dǎo)致人工查詢的成本增加，還有就是是否在每一個微服務(wù)里面要增加 Request-Id，我們增加完了以后發(fā)現(xiàn)，50 多個微服務(wù)，300 多個 API，這個微服務(wù)到底要怎么做，這變成了我們現(xiàn)在一個新的坑。

我們做微服務(wù)的時候做了組織結(jié)構(gòu)的變更，之前（2015年）研發(fā)管理就是前端、平臺、運(yùn)維，之后（2016年）變成了這種打散的方式：每個人在相應(yīng)的微服務(wù)里面，因?yàn)楣ぷ髀氊?zé)的增加，很多人還要跨微服務(wù)協(xié)作，然后他就開始糾結(jié)了。

這是我們業(yè)務(wù)層面的微服務(wù)的拆分，我們有 50 多個微服務(wù)的模塊，300 多個 API，所以我們又拆分出了一組人專門做服務(wù)編排。這個服務(wù)編排的人每天做的一件事情就是相互的依賴和相互的關(guān)系要讓這個接口部門全部去調(diào)用，它全部去負(fù)責(zé)，它要最了解每個服務(wù)之間的關(guān)系，但是它還要做整個服務(wù)的調(diào)用和協(xié)調(diào)者，這個又是很大的一筆開銷。
剛剛說了，微服務(wù)有了以后，對運(yùn)維的成本成倍的增加，我們就需要有敏捷的基礎(chǔ)設(shè)施，為微服務(wù)提供彈性，按需計(jì)算、儲存和網(wǎng)絡(luò)資源能力，所以我們又有了三個相應(yīng)的微服務(wù)需要執(zhí)行的點(diǎn)：

第一個是有支撐微服務(wù)的平臺，我們選擇的是 OpenStack+Docker+Mesos
第二個是有符合微服務(wù)平臺的規(guī)范
第三是有微服務(wù)的核心技術(shù)點(diǎn)，需要配置、代碼分離、服務(wù)注冊和發(fā)現(xiàn)，路由和容錯，還有API的邊緣服務(wù)，這又增加了很大一部分的工作量。

這是我們整個微服務(wù)的平臺，我們將開發(fā)、發(fā)布、運(yùn)行這三個階段嚴(yán)格地做了一個拆分，在不同的環(huán)境使用不同的相應(yīng)的服務(wù)。

為了做一些資源上的復(fù)用，我們首先把儲存和部分本地內(nèi)存通過 Mesos 鋪用了以后，然后在不同的時間點(diǎn)來調(diào)用資源的服務(wù)，通過分析一些歷史的信息，比如說我們白天的時候很多業(yè)務(wù)上的儲存運(yùn)用都很少，費(fèi)的主要是 I/O，我們白天可以把大數(shù)據(jù)的 I/O 和 CPU 都提供出來供業(yè)務(wù)使用；晚上的時候，當(dāng)業(yè)務(wù)全部都停歇的時候，我們會把所有的 I/O 和 CPU、儲存全部都給大數(shù)據(jù)使用，讓他們做離線計(jì)算，會在所有的內(nèi)存下面去跑我們的 Spark 集群的服務(wù)。

微服務(wù)這邊所說的 12 因子的規(guī)范，我就舉例說明幾個。首先我們對不同的環(huán)境參數(shù)的配置是通過環(huán)境變量進(jìn)行注入的，代碼和配置分離，代碼中不允許出現(xiàn)在生產(chǎn)環(huán)境的配置信息中，部署相關(guān)的 playbook 的時候是公開的，配置中的隱私是不能公開的，部署的過程中經(jīng)過代碼和配置的合并。本身這樣又會造成 playbook 也變成了代碼，它也需要一定的測試和維護(hù)。

我們的日志作為統(tǒng)一的事件流，統(tǒng)一處理服務(wù)和進(jìn)行收集、聚合、搜集、分析，每個程序的開發(fā)都要看到數(shù)據(jù)，他們每天要看所有的數(shù)據(jù)是否打算，自己的請求耗時大概是多少，自己的請求返回時間是多少，它吃的帶寬是多少，都可以通過自己的數(shù)據(jù)和日志查找到相應(yīng)的自己服務(wù)的相關(guān)報表，整個后面還有一系列的報警。

微服務(wù)的技術(shù)特點(diǎn) Devops，我們是版本控制的分布式配置中心，服務(wù)注冊和發(fā)現(xiàn)，盡早發(fā)現(xiàn)問題，盡早解決，成本越小。持續(xù)集成保證代碼始終處于可用的狀態(tài)。

當(dāng)我們多點(diǎn)的觸發(fā) Image 的時候，我們保證它和最后要是一致的，當(dāng)我們發(fā)現(xiàn) Docker 有變更的時候，會自動觸發(fā) Image 的重建過程，依賴這個 Image 物的 Dockerfile 也會重建。

為了保證多點(diǎn)同時觸發(fā) Image，我們?yōu)榱吮ＷC每個點(diǎn)都是可用的，所以我們在動態(tài)更新的時候，會動態(tài)創(chuàng)建、重啟、停止的事件通知到服務(wù)發(fā)現(xiàn)模塊，前端的反向代理會自動更新來確保用戶訪問地址不變。DNS 的域名和模板，在不同的服務(wù)中會有不同的分支和規(guī)則。

我們使用了微服務(wù)以后又用了 Docker 等等，對于我們來講，真的可能提高了整個系統(tǒng)的可維護(hù)性和穩(wěn)定性，同時又增加了兩個的成本，第一個最大的成本是有 50 個微服務(wù)，微服務(wù)連起來最大的成本就是測試，還有就是運(yùn)維的成本會增加，這里面有很多的測試環(huán)節(jié)，每個服務(wù)還有自己的灰度發(fā)布，每個服務(wù)大概有三四個灰度發(fā)布，每天不同的灰度有不同的人選進(jìn)去，怎么保證灰度和它的測試是一致的，怎么保證我們指定哪一個用戶進(jìn)入哪一個灰度，來持續(xù)跟蹤用戶的行為，都成為一個大的話題，我們專門又有一組人去做灰度，專門又有一組環(huán)境去做灰度發(fā)布，它來保證灰度的數(shù)據(jù)的人指定，然后進(jìn)入發(fā)布的灰度，再在灰度出來以后分析灰度的數(shù)據(jù)，來保證你所需要的灰度的用戶就是你所需要的來查看你的問題。

服務(wù)還有很重要的就是監(jiān)控，我們有業(yè)務(wù)單元的監(jiān)控，紅包是否存在異常，是否有黃牛每天不斷地在領(lǐng)紅包，訂單的狀態(tài)是否一致，是否微信支付會有延長，是否微信支付的回調(diào)會有異常。然后還有接口級別的監(jiān)控，每個接口的成功、錯誤率，調(diào)用的時間。還有我們很依賴電影院本身的系統(tǒng)，電影院出票系統(tǒng)的錯誤分布等等，這些接口的監(jiān)控都通過統(tǒng)一的日志規(guī)范來進(jìn)行處理。還有就是基礎(chǔ)監(jiān)控，服務(wù)器本身的 CPU、儲存和數(shù)據(jù)庫緩存隊(duì)列是否有效等等。我們所有的基礎(chǔ)監(jiān)控也是通過統(tǒng)一的日志處理和分析。

以前的隔離、降級和斷路等等基本上已經(jīng)很難做了，因?yàn)樗且粭l鏈，沒辦法隔離，用了 Docker 以后，我們的斷路、降級、隔離就是天然的，我們的運(yùn)維團(tuán)隊(duì)可以在某一天隨機(jī)干掉某幾個微服務(wù)，然后看這些微服務(wù)怎么手忙腳亂，然后還不影響到其它服務(wù)，這個好的地方就是微服務(wù)也給我們造成了這樣好的環(huán)境，能提高你的斷路和降級。

以上的實(shí)踐我們都是用騰訊云來實(shí)現(xiàn)的。有人會說，你本身的虛機(jī)再鋪一層會不會把資源浪費(fèi)，可能會浪費(fèi)，但是通過你整體的服務(wù)來講，我們認(rèn)為資源是在下降的，服用是在下降的，而且這里可以看到我們所有的資源開銷的占比，看起來最貴的還是帶寬，但是這一塊就是因?yàn)槲乙泻芏嗟恼{(diào)度系統(tǒng)去實(shí)現(xiàn)我的微服務(wù)調(diào)度和使用資源的調(diào)度，都會使用帶寬，這一塊的成本會增加，但是儲存成本和主機(jī)成本都在下降。

以上是我給大家分享的我們的微服務(wù)和 Docker 的一些經(jīng)驗(yàn)，謝謝大家。