【騰訊雲峯會 Cloud Native 專場】微票兒的 Cloud Native 實踐之路

導讀

在今年騰訊雲峯會上，開源技術一樣是一大亮點。做爲開源技術的集成平臺，Cloud Native 專場給各家提供了針對 OpenStack 應用以及背後填坑之路做深度探討的機會。
此文是微票時代技術副總裁楊森淼在現場有關《微票兒的 Cloud Native 實踐之路》分享的實錄。

楊森淼：《微票兒的 Cloud Native 實踐之路》

我跟你們分享的是咱們在實踐之路上踩過的坑，咱們作 Cloud Native 已經作了一段時間了，咱們主要以微服務+Docker，加其它的方式，從研發測試到部署總體的實現了咱們的業務流程化運行。咱們在一開始把這個事情想得很美好，咱們是一個電商票務平臺，咱們大致的分爲兩個方向，第一個方向是交易，另一個方向就是作用戶信息、電商推薦等等。另外咱們如今的語言也很是多了，咱們要實現持續交付和整個管理的流程化。咱們全部的服務都是在雲上。

想得挺好的，可是作起來仍是挺難的，咱們在作的過程當中會發現，雲服務確實是挺不錯，業務結構簡單，耦合度小，獨立部署，方便隔離，可使用不一樣的技術站，程序員想怎麼玩均可以，只要他在本身隔離的環境裏面，可是調用開銷增長、服務依賴性複雜、數據一致性難保證、運維的成本成倍的增長。

因此首先咱們遇到的問題，組織結構要不要一塊兒調，對數據進行改造，不一樣的實體業務要不要繼續拆分，聯合查詢變成了屢次的查詢，對不一樣的業務共享數據單機的事物不夠，而後是系統重構期間雜亂無章的依賴，形成數據的不一致，致使人工查詢的成本增長，還有就是是否在每個微服務裏面要增長 Request-Id，咱們增長完了之後發現，50 多個微服務，300 多個 API，這個微服務到底要怎麼作，這變成了咱們如今一個新的坑。

咱們作微服務的時候作了組織結構的變動，以前（2015年）研發管理就是前端、平臺、運維，以後（2016年）變成了這種打散的方式：每一個人在相應的微服務裏面，由於工做職責的增長，不少人還要跨微服務協做，而後他就開始糾結了。

這是咱們業務層面的微服務的拆分，咱們有 50 多個微服務的模塊，300 多個 API，因此咱們又拆分出了一組人專門作服務編排。這個服務編排的人天天作的一件事情就是相互的依賴和相互的關係要讓這個接口部門所有去調用，它所有去負責，它要最瞭解每一個服務之間的關係，可是它還要作整個服務的調用和協調者，這個又是很大的一筆開銷。
剛剛說了，微服務有了之後，對運維的成本成倍的增長，咱們就須要有敏捷的基礎設施，爲微服務提供彈性，按需計算、儲存和網絡資源能力，因此咱們又有了三個相應的微服務須要執行的點：

第一個是有支撐微服務的平臺，咱們選擇的是 OpenStack+Docker+Mesos
第二個是有符合微服務平臺的規範
第三是有微服務的核心技術點，須要配置、代碼分離、服務註冊和發現，路由和容錯，還有API的邊緣服務，這又增長了很大一部分的工做量。

這是咱們整個微服務的平臺，咱們將開發、發佈、運行這三個階段嚴格地作了一個拆分，在不一樣的環境使用不一樣的相應的服務。

爲了作一些資源上的複用，咱們首先把儲存和部分本地內存經過 Mesos 鋪用了之後，而後在不一樣的時間點來調用資源的服務，經過分析一些歷史的信息，好比說咱們白天的時候不少業務上的儲存運用都不多，費的主要是 I/O，咱們白天能夠把大數據的 I/O 和 CPU 都提供出來供業務使用；晚上的時候，當業務所有都停歇的時候，咱們會把全部的 I/O 和 CPU、儲存所有都給大數據使用，讓他們作離線計算，會在全部的內存下面去跑咱們的 Spark 集羣的服務。

微服務這邊所說的 12 因子的規範，我就舉例說明幾個。首先咱們對不一樣的環境參數的配置是經過環境變量進行注入的，代碼和配置分離，代碼中不容許出如今生產環境的配置信息中，部署相關的 playbook 的時候是公開的，配置中的隱私是不能公開的，部署的過程當中通過代碼和配置的合併。自己這樣又會形成 playbook 也變成了代碼，它也須要必定的測試和維護。

咱們的日誌做爲統一的事件流，統一處理服務和進行收集、聚合、蒐集、分析，每一個程序的開發都要看到數據，他們天天要看全部的數據是否打算，本身的請求耗時大概是多少，本身的請求返回時間是多少，它吃的帶寬是多少，均可以經過本身的數據和日誌查找到相應的本身服務的相關報表，整個後面還有一系列的報警。

微服務的技術特色 Devops，咱們是版本控制的分佈式配置中心，服務註冊和發現，儘早發現問題，儘早解決，成本越小。持續集成保證代碼始終處於可用的狀態。

當咱們多點的觸發 Image 的時候，咱們保證它和最後要是一致的，當咱們發現 Docker 有變動的時候，會自動觸發 Image 的重建過程，依賴這個 Image 物的 Dockerfile 也會重建。

爲了保證多點同時觸發 Image，咱們爲了保證每一個點都是可用的，因此咱們在動態更新的時候，會動態建立、重啓、中止的事件通知到服務發現模塊，前端的反向代理會自動更新來確保用戶訪問地址不變。DNS 的域名和模板，在不一樣的服務中會有不一樣的分支和規則。

咱們使用了微服務之後又用了 Docker 等等，對於咱們來說，真的可能提升了整個系統的可維護性和穩定性，同時又增長了兩個的成本，第一個最大的成本是有 50 個微服務，微服務連起來最大的成本就是測試，還有就是運維的成本會增長，這裏面有不少的測試環節，每一個服務還有本身的灰度發佈，每一個服務大概有三四個灰度發佈，天天不一樣的灰度有不一樣的人選進去，怎麼保證灰度和它的測試是一致的，怎麼保證咱們指定哪個用戶進入哪個灰度，來持續跟蹤用戶的行爲，都成爲一個大的話題，咱們專門又有一組人去作灰度，專門又有一組環境去作灰度發佈，它來保證灰度的數據的人指定，而後進入發佈的灰度，再在灰度出來之後分析灰度的數據，來保證你所須要的灰度的用戶就是你所須要的來查看你的問題。

服務還有很重要的就是監控，咱們有業務單元的監控，紅包是否存在異常，是否有黃牛天天不斷地在領紅包，訂單的狀態是否一致，是否微信支付會有延長，是否微信支付的回調會有異常。而後還有接口級別的監控，每一個接口的成功、錯誤率，調用的時間。還有咱們很依賴電影院自己的系統，電影院出票系統的錯誤分佈等等，這些接口的監控都經過統一的日誌規範來進行處理。還有就是基礎監控，服務器自己的 CPU、儲存和數據庫緩存隊列是否有效等等。咱們全部的基礎監控也是經過統一的日誌處理和分析。

之前的隔離、降級和斷路等等基本上已經很難作了，由於它是一條鏈，沒辦法隔離，用了 Docker 之後，咱們的斷路、降級、隔離就是自然的，咱們的運維團隊能夠在某一天隨機幹掉某幾個微服務，而後看這些微服務怎麼手忙腳亂，而後還不影響到其它服務，這個好的地方就是微服務也給咱們形成了這樣好的環境，能提升你的斷路和降級。

以上的實踐咱們都是用騰訊雲來實現的。有人會說，你自己的虛機再鋪一層會不會把資源浪費，可能會浪費，可是經過你總體的服務來說，咱們認爲資源是在降低的，服用是在降低的，並且這裏能夠看到咱們全部的資源開銷的佔比，看起來最貴的仍是帶寬，可是這一塊就是由於我要有不少的調度系統去實現個人微服務調度和使用資源的調度，都會使用帶寬，這一塊的成本會增長，可是儲存成本和主機成本都在降低。

以上是我給你們分享的咱們的微服務和 Docker 的一些經驗，謝謝你們。