王曉波 / 同程旅遊首席架構師

專注於高併發網際網路架構設計、分散式電子商務交易平臺設計、大資料分析平臺設計、高可用性系統設計，基礎雲相關技術研究，對 Docker 等容器有深入的實踐。

前言

隨著公司體系的不斷龐大，各種服務越來越多，程式設計師往往需要操心很多程式碼以外的事情如資源申請、環境配置、效能安全等，導致了開發效率低下。在ECUG 10週年的大會上，同程旅遊的首席架構師王曉波分享了同程旅遊從傳統架構轉變為微服務架構，再從微服務架構轉變為Serverless架構這個過程中的一些經驗，旨在讓程式設計師的開發能更加純粹快樂，專注於程式碼。

很多人說OTA這個行業不是網際網路，其實確實很難把旅遊這事完全的網際網路化。如果你去買一個充電寶和買一個帽子，不論是在淘寶還是京東，肯定是一套系統幫你服務的。但是如果在同程上面，你去買一個酒店或者買一張門票，可能有五六套系統在為你服務。這是因為資料、關注的點、使用者的行為，完全不一樣。導致公司裡幾千號程式設計師，每天好像都在乾重復的事情。怎麼改變這個事情呢？讓程式設計更快樂一些，更純粹一些。

同程實踐Serverless的背景

從一條SQL到一個服務的距離到底有多遠？

很多在做業務級開發的同學，往往每天應對的是從資料庫或其它資料儲存的地方，用一條SQL把資料搬出來，或者寫進去，並且把它作為一個服務提供出去。那這樣一件事情到底離一個服務有多遠？其實真的很遠。換句話說就是，當你想開發一個功能的時候，這個功能什麼時候能夠上線？當我們去做一條SQL時，首先要知道DB在哪，要知道它的效能怎麼樣，然後得去申請一個工程來放程式碼。申請了工程之後，得去構建開發環境；構建了開發環境後，得申請線上的資源；申請了資源之後，要去申請部署；部署完之後，要去申請運維。這一切都好了以後，還得想到哪一天要是壓力扛不住了，或者哪一天流量大了以後怎麼去擴容。當看到這一系列帶來的問題之後，一條SQL到一個服務的距離到底有多遠？非常遠。

在同程，很多的產品經理充滿想法。可能早上在公交車上被人撞了一下，就想到一個想法，然後到公司讓程式設計師把這個實現了，下午就要上線。程式設計師說這個下午上不了線，做各種的解釋，說需要申請伺服器，或者其它的各種資源。這一系列的事情，其實都來自這個問題：一條SQL到一個服務的距離到底有多遠。如果這個時間只需要1小時的話，一天8個小時允許產品經理想8個問題了。晚上下班以後加班4個小時，還能夠再想4個問題。產品經理開心了，這樣程式設計師的開發一定是更加快樂一點的。

哪些因素影響著程式設計師不快樂

首先是環境、框架、依賴，這些問題非常的難搞。

第一個是指環境，從開發到上線這個過程中，環境就已經非常難搞了。可能在開發同學的本地是好的，但到了測試手上或者線上的時候，就出現了問題。鬧了半天可能是怪我們的運維同學太弱了，配的環境跟本地開發環境不對，所以不行。其實這裡有很大的問題，這個運維同學是背鍋的。環境的一致性我覺得本身就是程式設計師應該做的一個事情。可是並不是所有的程式設計師都是好的程式設計師，並不都是全棧工程師。他可能會寫程式碼，但不懂運維，不懂得如何讓程式碼在環境中更好地跑起來。再反過來說中國有多少的全棧工程師？一個全棧工程師的培養又需要多久？這裡困難就來了。

還有一個困難就是依賴關係，這也是開發過程當中非常頭疼的問題。我自己是個Java程式設計師，有時候自己寫個一兩千行程式碼，只有一兩個檔案，打一個包，60幾兆出來了，一堆依賴關係。當然現在用Go好一些了，但這樣的問題能不能解決？比如說同程很多的同學，我們在蘇州，北京也有一些開發，在蘇州我們有近千名程式設計師。當有這麼多程式設計師的時候，如何讓這些程式設計師的效率更好地提升？當然你可以用管理，用開發模式去做。但是用技術去解決依賴關係，讓沒有依賴關係產生不是更好？即使有依賴，也是用介面的形式去調，這樣就舒服多了。

還有一塊就是部署、運維、擴容。剛才說過可能開發的同學不是太懂運維，運維的同學又不是太懂開發，所以導致了問題。同程之前也在推DevOps，現在我們每個開發同學也可以擁有自己的運維工作臺，去操作他部署的每一臺機器，這個是沒有問題的。但是這件事情真的好嗎？其實同程在做這個的時候發現，真正讓一幫開發的同學去做運維並做不好，天天線上故障，因為做運維和做開發是兩個思路。所以後來我們在做DevOps的時候，先把所有原始的運維同學進行轉崗，變成運維的產品經理和專案經理，讓一幫開發同學去做運維平臺，把運維平臺做出來之後再給開發同學去用，這樣DevOps才推起來了。聽起來這樣真的解決了這個問題嗎？其實還是沒有解決，因為對於開發的同學來說他們還是得知道運維的工作有哪些，但有些開發同學可能並不想知道。比如某天早上產品經理想出來個賣票時搭售個盒飯，這樣一個功能可能50行程式碼就寫完了，那麼這個開發同學為什麼要去懂運維呢，這樣的同學其實有很多。

當公司大了之後一定會受到成本結算。OTA的缺點是一個公司看似一個公司，但它其實是一個特種部隊，裡面集成了各種事業部，互相獨立，都很牛逼，但是收他們錢的時候就都沒錢。比如在春節這種流量高峰時部了很多伺服器，但是春節過後，這些伺服器就產生了資源浪費。所以就有了問題，如何讓我的程式碼做到沒有流量的時候不要算資源，當流量大的時候又可以自己擴容。這個要求很高，但是對於商業戰場來說為什麼不可以呢？

這塊可能是最大的痛苦。在同程我們有專門的效能測試團隊，也有效能測試的平臺，也會做全鏈路的效能測試。比如說每年國慶節和春節前期都是兩次旅遊的高峰點，所以我們都會做全鏈路的壓測。但這有個問題是你如何保障每一個程式設計師寫出的任何一條垃圾程式碼都可以高併發。

還有一個問題是什麼呢？假如之後產品經理又出了個難題，說搶購不好玩，搶了就沒有了，為什麼不能在搶購的時候實時顯示排在第幾位。這就得要儲存每個人的排名，還不能造假，那這個時候的效能如何去做。可能有人說找個高階的程式設計師做這個事情不就好了嗎，但是我們有這麼多的程式設計師，產品經理可能隨便拉了個剛畢業的新人來做。當一個一年左右的程式設計師寫了一個產品也是坑爹想法的系統的時候，最後上線真的造成了損失，那麼誰該負這個責任呢？一路追究上去，事業部技術不行，公司技術不行，公司架構師技術不行，那這個事情就很坑爹了，我作為架構師甚至都不知道這個系統。所以我們就想著能不能去做一個平臺，讓這個事情變得更加簡單。

Serverless與傳統架構比較

這是同程最老的一個架構，這個架構基本上是同程創業的時候那幾個老闆自己寫的。10年前看這個系統的時候感覺還可以，做這樣的架構沒有問題。但如果是17年的時候還用這樣的架構，大家會覺得OTA的技術果然比較弱，還在用這樣的系統。但其實今天在同程的系統裡確實還有這樣的架構出現，而且還有新做的系統也長這個樣。為什麼有這樣的問題呢？比如說我們某個業務同學發現在澳大利亞的某個沙漠深處很好玩，產品經理感覺也不錯，要成立個專案幹這個事。然後就給他三程式設計師，你讓他們寫個微服務的系統出來，不可能。能寫個上面這樣的架構就不錯了，說不定連服務都沒有，直接都堆到應用裡了。這樣的業務在整個旅遊場景裡面非常多，我們把它叫做打樣業務或者創新業務。一個事業部會孵化這樣的專案N多個，可能一個成了，就會慢慢發展成大專案的。

但這樣的架構容易碰到問題，流量上來就容易宕機，死個一天也是有可能的，所以需要改造。

同程在2年前開始做微服務，這一套微服務架構跟別人的不一樣，除了服務的基礎容器以外還多了一箇中間的Gateway，專門去遮蔽非微服務的服務。這是因為在同程中還有很多傳統架構的那些創新業務，這些創新業務不代表不會相互去呼叫，那麼這些非微服務的服務如何被微服務呼叫呢，我們當時特別想到了一個模式，叫GNE模式。大家可以思考一下微服務是不是一個偽命題？我們實踐下來覺得是偽命題，因為並沒有誰能夠非常明確地用數字告訴你微服務應該多微才稱之為一個微服務。而且服務長時間跑下來，一定會變大。舉個例子來說，你今天有一個下單介面做成一個微服務釋出上去，下單可以算是核心的一個服務了。假如你的產品是在不斷迭代的，那麼一個月或者兩個月之後一定會有第二個服務出現，叫“新下單服務”。三個月之後，一定還會有新的服務出現，叫”新新下單服務“。半年之後，最老的那個服務會被打上標註“不能再用的下單介面，但是不能下線”。所以會發現一個問題，在所有的公司裡面，系統上線是很容易的，但是如果想讓一個系統下線，需要聯絡各個部門，燒各種香，最終才能下線。

微服務產生的結果，就是這個服務不停長大。原來我們微服務的目的是業務單一化，做得更小更好更穩定，獨立地部署，可以去做編排。但當你三五個月或一年半以後再去看時，會發現這玩意就是個吃胖的楊貴妃，不再是那個窈窕淑女。編排也排不起來了，因為裡面包含了太多的東西。那這就是同程在做微服務時遇到的麻煩。我們的解決方案是再做個Gateway，把長胖的胖子關進去，對外還是用多個微服務基本介面，只是有不同的路由策略去選擇使用哪個版本的介面。這做完之後，其實帶來的是維護成本和維護代價非常大。

同程現在幾乎所有的應用都是部署在Docker裡面的，包括資料庫。但服務的數量越來越多後，其實對運維和每個服務的回收帶來很大的問題，服務不能這樣無限地增長下去。而且發現30%的服務隨著時間的流逝呼叫量幾乎變成沒有了，有時候一天調一次或者一個月調一次。這些就是已經可以下線但是又沒法完全下線的服務，還有微量的流量進來。這樣的服務越積越多，大量地消耗你伺服器的資源，浪費就極大了。

一個程式碼指令碼能不能就是一個微服務

我們來看一個對比。開發同學寫程式碼時，有的情況下是叫偽面向物件，寫出來的程式碼和過程程式碼沒什麼區別，而且往往非常累贅，程式碼一坨一坨的。所以開發同學經常會說要重構一下程式碼，因為他的程式碼是錯綜複雜的。反過來想，現在去看運維的同學，運維同學也寫程式碼，很多都是指令碼化的。對於運維同學來說，指令碼不存在重構一說，不要就扔了再寫一個，相對來說是快速的一次性的東西。

在前面的系統中我們說了很多快速變現的內容，那麼這些快速變現的內容可不可能去變成一個指令碼，這一個指令碼可不可能變成一個微服務？比如說今天要從資料庫一個表裡面查出來資料，對外提供服務，可能就一句SQL的事。如果不允許它變成一個指令碼，而是做一個微服務，微服務是有一整套自己的流程要走，怎麼辦？他肯定不會走這個流程，他可能就會找一個其他服務的例項，加一個這個介面，結果這個服務就被他汙染了。所以我們就想在已經做微服務的場景下，把那些變化快的輕的東西變成指令碼去走。

同程的Serverless實現了什麼

同程大概是2016年的4、5月份開始做Serverless。Serverless架構是什麼，估計今天也沒有人能說清楚。我這裡截了一句話：“如果你的PaaS可以將以前半秒啟動的應用在20ms內啟動，就叫它Serverless”。反正我們做這個的時候並沒有想到多少毫秒能把它啟動起來。我們本著的一個原則是，那些輕的服務能讓它一個指令碼的，就去變成一個微服務，並且它的呼叫部署能夠做成動態的擴容。當它沒有流量的時候最好不要再消耗大部分的資源，而且能夠輕易的上下線。我們做Serverless其實要解決的問題就是，。

這是我們做的一個架構圖，我們主要分為三個層次，排程層、計算層和基礎層。排程這一層看似沒有什麼問題，但其實我們做了很多的事情。可以想象一下如何快速地在1秒之內把下面擴容之後的服務掛載上來，並且擴容出去。所以動態的熱載入的負載均衡是非常重要的，而且是每個階段都會有，因為有可能釋出在這上面的是個網頁。如果是個對外的高併發的東西，比如產品經理說今天要做一個大流量的引流，需要做一個落地頁，假如程式設計師不小心做到這裡面，那併發就來了，很可能就掛了。而且不僅要考慮前端的外部流量進來，也要考慮內部流量。比如在內部是被多個系統依賴之後，如何在斷掉之後有個熔斷機制。因為如果用微服務架構去 做的話，都會做熔斷的機制，但如果是這樣的簡單指令碼，它很少會去考慮熔斷的時候怎麼辦。

第二層是計算層，主要是做我們的排程工作，如何快速地開出資源。在Serverless做的時候有兩種做法，比如我們直接用Docker容器放，每次擴容都是一個容器，靠一個個容器堆上去。但我覺得這種不夠美，而且直接去擴容器太粗暴，畢竟容器本身還在佔資源。而且還有個問題是，這裡面部署的東西，我們是定義為一個指令碼或者一兩個指令碼去做的事情，這個程式碼非常少，如果分配一個容器這麼重的東西，那麼資源還是挺浪費的。所以我們開始入手的時候比較簡單，用動態語言去做這件事。我們先去實現Lua，Node.js這類動態語言，它的好處是執行時像個虛擬機器，可以把它隔出來。隔掉之後，當每個指令碼在執行的時候，它就是一個獨立的可執行的容器，然後再把它放到一個Docker容器中。目前我們只支援動態語言，我們也在嘗試Go，但比較難還沒成功。上面這兩圖展開的是我們每個指令碼之間的互調關係。

這是我們Serverless架構的資源利用圖。基本是在物理機的基礎上去布Docker容器，Docker容器裡再去開我們一個個例項去部署出來，然後做個隔離。我們做了實驗，最小的部署量能在4臺物理機上部署10萬個應用。當然，這在生產環境是做不到的，10萬個指令碼服務在生產環境都有流量的話，光這些流量就把它打死了。使用這樣的Serverless之後，很多輕的應用是可以隨時下線的，就解決了那些流量很少但是必須活著的服務的問題。

但這裡又產生一個問題，就這樣的話程式設計師程式設計快樂了嗎？我想還是不快樂的。我比較討厭的是想寫行程式碼從資料庫裡面取一個數據，結果需要我找什麼驅動，問我DB地址、密碼，以及打各種各樣的類庫，煩都煩死了。所以我們也開始做了個SDK，讓程式碼能更好地去用它。如下圖所示的從資料庫拉資料的例子，當你程式設計時不需要關心伺服器在哪兒，專注於程式碼就可以了。這樣一個Server.DB的庫在整個平臺會有一個配置中心進行管理，所有DB可以人工地配進去，配進去之後它就生成了這個物件，對於開發同學來說他只需要敲就行了。

在這個平臺除了操作DB以外，還可以調其它的微服務。比如做了一個落地頁，想知道會員的等級，那肯定要調會員的服務。會員服務是個很重的服務，不會在這個平臺上，肯定會是一個微服務部署的獨立服務，那這個平臺一樣可以去靠到它，通過排程去直接呼叫它。

做了這麼多事情以後，其實我們發現還不夠Serverless。我剛才說了還有個很大的問題，本地是好的，但線上或測試環境不行，這個問題還是沒有解決。這就還是在關注環境，還是不能夠僅關注程式碼。所以我們做了一個Web IDE，開發同學不用再關心本地的開發環境，也不再需要配置本地開發環境的依賴關係。因為當微服務化以後，特別是大量大團隊去合作的時候，往往它的互相依賴關係在本地很難模擬出來。我們提供Web IDE，讓每個同學開啟一個Web網頁就能寫程式碼，這樣程式碼在寫的時候，一切就在我的控制之下。

這個Web IDE還蠻強大的，可以做一些版本合併。可以直接在上面新建工程，或者進入一個工程，工程中還帶了很多的腳手架，還會有很多的角色。同時還有商店的功能，程式設計師可以寫一些公用的東西給別人去用。比如剛才說的反爬，反爬的兄弟把反爬系統做好了，如果你寫了個指令碼是對外提供網頁服務的，需要反爬功能，那隻需要在配置這裡打個勾就可以支援反爬了。比如說要做個排隊搶購的，只需要在配置裡打個勾，寫上併發數量就可以了，因為有別的系統會為你做這事。

Serverless在同程的情況

開發、釋出和運維的效率

我們發現做了這樣的一個事情以後，對於我們開發的初期，任何一個專案，任何一個獨立部署的功能開始放置時，一定會要申請一系列的東西，在這些事情上我們省了90%的時間。再接下來是找資料，DB在哪看起來是小事，但其實在開發看來是很煩的，測試環境的DB在哪，開發環境的DB在哪，預發環境的DB在哪，搞錯一個就完了。所以做了Serverless之後，在這些事情上省了80%的時間。對於寫程式碼來說，其實節省的時間不多，畢竟很多程式碼還是要人寫的。在這個環節我們提供的很多SDK起了不少作用，節省了40%的時間。還有90%的時間是運維這邊省下來的，當應用作為一個小指令碼來部署的話，整個平臺化，連開發工具都沒有了，那麼這樣對於運維來說更簡單，一個監控系統就可以全自動化地做掉。

Web應用

現在同程所有的站點所有的網頁都是放在剛才的平臺裡面，因為有了這個平臺，同程內部在16年末興起了前端革命。以前前端工程師做完頁面需要找後端提供介面，現在做了這個平臺以後，由於是Node.js，前端工程師自己就擼完了，各種資料庫都可以直接找到。真的是早上提需求，晚上就能上線，所以所有的前端都喜歡用這個平臺。而且這個平臺不僅是個網頁平臺，還有很多的API提供，很多同學就開始自己造工具，比如拿Atom對接平臺的API，拿Atom也能寫這些程式碼。

輕型服務

還有就是一些簡單業務的快速服務，上圖就是一個實際的程式碼，真的就是一個指令碼就完成了。

配套功能整合

然後是價格計算的實時服務。很多人說OTA沒有什麼漂亮的技術，其實還挺多的。舉個例子，最傳統的業務，酒店。酒店這樣的業務，非常的傳統，但其實它非常難做，非常的複雜。可以想象一下在阿里或者京東上面買東西的時候，它的價格是什麼樣子的？死的，上午的價格至少到中午是不會變的。但是酒店的價格是不一樣的，為什麼？酒店連住三天，或者你住的日期裡面有周末，或者提前三天，或者提前一個星期，每種搜尋條件下出來的酒店價格是不一樣的。酒店住一個禮拜價格是低的，可能300塊錢的酒店變280，如果你提前兩週訂可能又更便宜。但如果你訂明天或今天晚上的，那就貴了，或者住到週末要漲價30%，所以這個價格是根據每次搜尋的條件去變的。目前在酒店搜尋的時候很多是死資料，可能5分鐘變一次，或者半小時變一次。這時候就要實時的計算，這個實時的計算其實就是擴容的問題，因為算的時間太長了。當然現在搜三亞很快就能夠搜尋到，因為它有個實時的擴容機制。像我們同程的酒店，日常是有480個節點去計算它，可以擴容到1000個節點，也可以縮回來。

下一步在Serverless上要做什麼

當然未來我們還有很多事情要做，Serverless只是才剛剛開始，做的對不對也不一定，總之這個Serverless是能夠幫助我們去做掉一些事情的。

Q&A

王曉波：其實國內開發都有這個問題，前兩天跟他們facebook的交流了下，我們中國要求當天程式碼當天交，根本沒有人看的，耽誤公司的話就掛了，哪怕你有原生代碼，我們這個可能還會更好一些。

王曉波：這個不會。我覺得你們那個方式比國內那個方式好的。

王曉波：稍微簡單一點，我們分很多種的閘道器，比如說前端過來的，我們把它也放在閘道器，你說的閘道器是微服務的，同程微服務的話我們做成負責服務的分發，對非微服務和微服務，我們只把這個叫閘道器，別的都沒有了，這個閘道器是要犧牲一些功能，我們做一些微服務，通過閘道器這些東西都沒有了，做的非常粗暴，我們也不融合的，給你返回到一個特定的地方，剩下就是自己服務了。