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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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