資訊專欄INFORMATION COLUMN
摘要：導讀在今年騰訊云峰會上，開源技術同樣是一大亮點。此文是微票時代技術副總裁楊森淼在現場有關微票兒的實踐之路分享的實錄。
導讀
楊森淼：《微票兒的 Cloud Native 實踐之路》在今年騰訊云峰會上，開源技術同樣是一大亮點。作為開源技術的集成平臺，Cloud Native 專場給各家提供了針對 OpenStack 應用以及背后填坑之路作深度探討的機會。
此文是微票時代技術副總裁楊森淼在現場有關《微票兒的 Cloud Native 實踐之路》分享的實錄。
我跟大家分享的是我們在實踐之路上踩過的坑，我們做 Cloud Native 已經做了一段時間了，我們主要以微服務+Docker，加其它的方式，從研發(fā)測試到部署整體的實現了我們的業(yè)務流程化運行。我們在一開始把這個事情想得很美好，我們是一個電商票務平臺，我們大體的分為兩個方向，第一個方向是交易，另外一個方向就是做用戶信息、電商推薦等等。另外我們現在的語言也非常多了，我們要實現持續(xù)交付和整個管理的流程化。我們所有的服務都是在云上。
想得挺好的，但是做起來還是挺難的，我們在做的過程中會發(fā)現，云服務確實是挺不錯，業(yè)務結構簡單，耦合度小，獨立部署，方便隔離，可以使用不同的技術站，程序員想怎么玩都可以，只要他在自己隔離的環(huán)境里面，但是調用開銷增加、服務依賴性復雜、數據一致性難保證、運維的成本成倍的增加。
所以首先我們遇到的問題，組織結構要不要一起調，對數據進行改造，不同的實體業(yè)務要不要繼續(xù)拆分，聯合查詢變成了多次的查詢，對不同的業(yè)務共享數據單機的事物不夠，然后是系統重構期間雜亂無章的依賴，造成數據的不一致，導致人工查詢的成本增加，還有就是是否在每一個微服務里面要增加 Request-Id，我們增加完了以后發(fā)現，50 多個微服務，300 多個 API，這個微服務到底要怎么做，這變成了我們現在一個新的坑。
我們做微服務的時候做了組織結構的變更，之前（2015年）研發(fā)管理就是前端、平臺、運維，之后（2016年）變成了這種打散的方式：每個人在相應的微服務里面，因為工作職責的增加，很多人還要跨微服務協作，然后他就開始糾結了。
這是我們業(yè)務層面的微服務的拆分，我們有 50 多個微服務的模塊，300 多個 API，所以我們又拆分出了一組人專門做服務編排。這個服務編排的人每天做的一件事情就是相互的依賴和相互的關系要讓這個接口部門全部去調用，它全部去負責，它要最了解每個服務之間的關系，但是它還要做整個服務的調用和協調者，這個又是很大的一筆開銷。
剛剛說了，微服務有了以后，對運維的成本成倍的增加，我們就需要有敏捷的基礎設施，為微服務提供彈性，按需計算、儲存和網絡資源能力，所以我們又有了三個相應的微服務需要執(zhí)行的點：
第一個是有支撐微服務的平臺，我們選擇的是 OpenStack+Docker+Mesos
第二個是有符合微服務平臺的規(guī)范
第三是有微服務的核心技術點，需要配置、代碼分離、服務注冊和發(fā)現，路由和容錯，還有API的邊緣服務，這又增加了很大一部分的工作量。
這是我們整個微服務的平臺，我們將開發(fā)、發(fā)布、運行這三個階段嚴格地做了一個拆分，在不同的環(huán)境使用不同的相應的服務。
為了做一些資源上的復用，我們首先把儲存和部分本地內存通過 Mesos 鋪用了以后，然后在不同的時間點來調用資源的服務，通過分析一些歷史的信息，比如說我們白天的時候很多業(yè)務上的儲存運用都很少，費的主要是 I/O，我們白天可以把大數據的 I/O 和 CPU 都提供出來供業(yè)務使用；晚上的時候，當業(yè)務全部都停歇的時候，我們會把所有的 I/O 和 CPU、儲存全部都給大數據使用，讓他們做離線計算，會在所有的內存下面去跑我們的 Spark 集群的服務。
微服務這邊所說的 12 因子的規(guī)范，我就舉例說明幾個。首先我們對不同的環(huán)境參數的配置是通過環(huán)境變量進行注入的，代碼和配置分離，代碼中不允許出現在生產環(huán)境的配置信息中，部署相關的 playbook 的時候是公開的，配置中的隱私是不能公開的，部署的過程中經過代碼和配置的合并。本身這樣又會造成 playbook 也變成了代碼，它也需要一定的測試和維護。
我們的日志作為統一的事件流，統一處理服務和進行收集、聚合、搜集、分析，每個程序的開發(fā)都要看到數據，他們每天要看所有的數據是否打算，自己的請求耗時大概是多少，自己的請求返回時間是多少，它吃的帶寬是多少，都可以通過自己的數據和日志查找到相應的自己服務的相關報表，整個后面還有一系列的報警。
微服務的技術特點 Devops，我們是版本控制的分布式配置中心，服務注冊和發(fā)現，盡早發(fā)現問題，盡早解決，成本越小。持續(xù)集成保證代碼始終處于可用的狀態(tài)。
當我們多點的觸發(fā) Image 的時候，我們保證它和最后要是一致的，當我們發(fā)現 Docker 有變更的時候，會自動觸發(fā) Image 的重建過程，依賴這個 Image 物的 Dockerfile 也會重建。
為了保證多點同時觸發(fā) Image，我們?yōu)榱吮ＷC每個點都是可用的，所以我們在動態(tài)更新的時候，會動態(tài)創(chuàng)建、重啟、停止的事件通知到服務發(fā)現模塊，前端的反向代理會自動更新來確保用戶訪問地址不變。DNS 的域名和模板，在不同的服務中會有不同的分支和規(guī)則。
我們使用了微服務以后又用了 Docker 等等，對于我們來講，真的可能提高了整個系統的可維護性和穩(wěn)定性，同時又增加了兩個的成本，第一個最大的成本是有 50 個微服務，微服務連起來最大的成本就是測試，還有就是運維的成本會增加，這里面有很多的測試環(huán)節(jié)，每個服務還有自己的灰度發(fā)布，每個服務大概有三四個灰度發(fā)布，每天不同的灰度有不同的人選進去，怎么保證灰度和它的測試是一致的，怎么保證我們指定哪一個用戶進入哪一個灰度，來持續(xù)跟蹤用戶的行為，都成為一個大的話題，我們專門又有一組人去做灰度，專門又有一組環(huán)境去做灰度發(fā)布，它來保證灰度的數據的人指定，然后進入發(fā)布的灰度，再在灰度出來以后分析灰度的數據，來保證你所需要的灰度的用戶就是你所需要的來查看你的問題。
服務還有很重要的就是監(jiān)控，我們有業(yè)務單元的監(jiān)控，紅包是否存在異常，是否有黃牛每天不斷地在領紅包，訂單的狀態(tài)是否一致，是否微信支付會有延長，是否微信支付的回調會有異常。然后還有接口級別的監(jiān)控，每個接口的成功、錯誤率，調用的時間。還有我們很依賴電影院本身的系統，電影院出票系統的錯誤分布等等，這些接口的監(jiān)控都通過統一的日志規(guī)范來進行處理。還有就是基礎監(jiān)控，服務器本身的 CPU、儲存和數據庫緩存隊列是否有效等等。我們所有的基礎監(jiān)控也是通過統一的日志處理和分析。
以前的隔離、降級和斷路等等基本上已經很難做了，因為它是一條鏈，沒辦法隔離，用了 Docker 以后，我們的斷路、降級、隔離就是天然的，我們的運維團隊可以在某一天隨機干掉某幾個微服務，然后看這些微服務怎么手忙腳亂，然后還不影響到其它服務，這個好的地方就是微服務也給我們造成了這樣好的環(huán)境，能提高你的斷路和降級。
以上的實踐我們都是用騰訊云來實現的。有人會說，你本身的虛機再鋪一層會不會把資源浪費，可能會浪費，但是通過你整體的服務來講，我們認為資源是在下降的，服用是在下降的，而且這里可以看到我們所有的資源開銷的占比，看起來最貴的還是帶寬，但是這一塊就是因為我要有很多的調度系統去實現我的微服務調度和使用資源的調度，都會使用帶寬，這一塊的成本會增加，但是儲存成本和主機成本都在下降。
以上是我給大家分享的我們的微服務和 Docker 的一些經驗，謝謝大家。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規(guī)行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://systransis.cn/yun/26643.html
摘要：導讀在今年騰訊云峰會上，開源技術同樣是一大亮點。此文是微票時代技術副總裁楊森淼在現場有關微票兒的實踐之路分享的實錄。 導讀 在今年騰訊云峰會上，開源技術同樣是一大亮點。作為開源技術的集成平臺，Cloud Native 專場給各家提供了針對 OpenStack 應用以及背后填坑之路作深度探討的機會。此文是微票時代技術副總裁楊森淼在現場有關《微票兒的 Cloud Native 實踐之路》分...
摘要：年月日日，由高可用架構技術社區(qū)聯合麥思博有限公司共同主辦的全球互聯網架構大會在上海光大會展中心成功舉行。至此，全球互聯網架構大會完美落幕。 showImg(https://segmentfault.com/img/bV1mnC?w=800&h=533); 2017年12月22日-23日，由高可用架構技術社區(qū)聯合麥思博（msup）有限公司共同主辦的 GIAC全球互聯網架構大會在上海光大會...
摘要：年月日日，由高可用架構技術社區(qū)聯合麥思博有限公司共同主辦的全球互聯網架構大會在上海光大會展中心成功舉行。至此，全球互聯網架構大會完美落幕。 showImg(https://segmentfault.com/img/bV1mnC?w=800&h=533); 2017年12月22日-23日，由高可用架構技術社區(qū)聯合麥思博（msup）有限公司共同主辦的 GIAC全球互聯網架構大會在上海光大會...
摘要：可簡單地認為它是的擴展，負載均衡自然成為不可或缺的特性。是基于開發(fā)的服務代理組件，在使用場景中，它與和整合，打造具備服務動態(tài)更新和負載均衡能力的服務網關。類似的特性在項目也有體現，它是另一種高性能代理的方案，提供服務發(fā)現健康和負載均衡。 摘要： Cloud Native 應用架構隨著云技術的發(fā)展受到業(yè)界特別重視和關注，尤其是 CNCF（Cloud Native Computing Fo...
摘要：京東云集群最佳實踐容器是的基石，它們之間的關系不言而喻。因此我們今天的文章將會和大家分享關于京東云集群的部分最佳實踐。京東云集群采用管理節(jié)點全托管的方式，為用戶提供簡單易用高可靠功能強大的容器管理服務。 京東云Kubernetes集群最佳實踐 容器是Cloud Native的基石，它們之間的關系不言而喻。了解容器對于學習Cloud Native也是十分重要的。近期，京東云Cloud N...
閱讀 2420·2021-11-18 10:02
閱讀 1934·2021-10-13 09:40
閱讀 3012·2021-09-07 10:07
閱讀 2119·2021-09-04 16:48
閱讀 1017·2019-08-30 13:18
閱讀 2463·2019-08-29 14:03
閱讀 2931·2019-08-29 12:54
閱讀 3169·2019-08-26 11:41
