獨立出來的美團云業務部目前有十幾位工程師。雖然部門獨立，但工作中仍然跟系統運維組有緊密的配合。美團系統運維組原本就有三分之二的開發工程師，而運維工程師也全部具備編寫代碼的能力，因此開發與運維工程師能夠進行緊密的配合。

相關廠商內容

美團云的最初版本起步于2012年7月，一開始是作為私有云計算平臺來構建。第一版開發了大約2個月的時間，之后用了大概10個月的時間將美團的所有業務遷移到云平臺上。現在除了Hadoop、數據庫仍跑在物理機上之外，美團網的所有業務都已經運行在美團云上，內部的研發、測試平臺也運行在美團內部的辦公云平臺上。

2013年5月，美團云開始對外提供公有云服務，截止到目前僅對外提供云主機產品。對象存儲、Redis、MySQL、負載均衡、監控、VPC等服務也在研發，部分產品已經在內部以及部分測試客戶使用，未來會根據產品的成熟度和客戶的需求程度逐步對外開放。

穩定是公有云服務的核心價值。自從公有云服務開放以來，美團云主要的工作都放在提升云主機的穩定性，完善云主機模板、備份、監控、安全等工作上。預計在2014年9月，美團云將發布其第三個版本的更新，繼續打磨其產品細節。

技術架構

美團云最初選型的時候對OpenStack、CloudStack、Eucalyptus都做過調研，調研的結果是架構設計使用OpenStack的框架，網絡架構參考CloudStack，主要組件由自己開發，部分組件在OpenStack原生組件上進行了二次開發。

核心的云主機管理系統是自己研發，沒有使用Nova。采用Region-Zone-Cluster三層架構，支持跨地域、多數據中心的大規模集群部署。采用了基于KVM的主機虛擬化和基于OpenVSwitch+OpenFlow的網絡虛擬化技術。
鏡像管理用了Glance。有一定修改，例如，多數據中心分布式支持，以及鏡像替換。
身份管理用了Keystone。有一定修改，例如，高并發性能改進，與美團帳戶系統的集成。
對象存儲用了Swift，但Swift在寫延遲方面存在性能問題，同時在OAM方面的功能比較薄弱，所以也做了一些修改和研發。Swift現在已經在為美團網內部存儲量幾十TB量級的業務提供服務。
之所以沒有整個引入OpenStack，是因為當時調研時，感覺OpenStack的設計比較脫離美團的實際情況。例如，網絡架構需要有較大的調整，同時需要有共享存儲的支持。當時對美團來說，現有業務的基礎設施已經基本固化，為適應OpenStack而做這樣的調整基本不可接受。另外，OpenStack在很多細節方面達不到需要的級別。比如，OpenStack對跨機房多Zones的設計，它假設你機房之間的網絡是完備的，這也不太符合我們的網絡現狀。因此，我們基于美團現有的主機使用模式和網絡架構，重新設計了網絡、存儲和主機管理模型，自主研發了虛擬化管理平臺。同時，我們在從單機房做到多機房的時候，在Zones之間做了解耦，比如在每個機房里都放置Glance服務節點，減少對跨機房網絡的依賴。正是由于這些研發工作，使得我們經過不到一年時間的磨練，就實現了美團整個基礎設施完全運行在私有云上的目標。

當然，由于我們不使用Nova，就意味著OpenStack社區的很多依賴Nova的組件和功能我們基本無法直接使用。不過，相對于OpenStack大而全/兼容并包的架構，我們堅持在每一方面都集中精力用好一種技術，如主機虛擬化使用KVM，網絡虛擬化使用OpenVSwitch+OpenFlow，使得整個系統的開發和維護成本相對較低，同時能深挖這些技術方案的功能特性，最大限度地壓榨硬件性能。同時，由于我們掌握了基礎系統的代碼，使得我們可以較高的效率添加一些新的業務功能（例如，對虛擬IP，USB KEY的支持等），以及實現系統架構的升級改造（例如，對多機房架構支持等）。另外，我們對使用的OpenStack組件做的一些修改，比如對Swift的優化，目前技術委員會也在提議如何回饋給上游社區。當然了，這個還需要看社區對我們的patch接受與否，而我們也還是以滿足業務需求優先。

其他方面，塊存儲落在本地的SAS盤上并在本地做RAID。目前我們對美團網自己的業務做RAID5，對公有云用戶做RAID10。這是考慮到美團網自己的業務在應用層已經做了較完備的高可用設計的，即使掉了單個節點也不會影響到業務；但對于公有云用戶而言，他們用的那一臺云主機就是一個單點，所以要對他們的云主機做更好的保護。使用RAID10當然成本會比較高。我們也在考慮共享存儲，當然前提是先解決了上面的穩定性和性能問題。以后會使用SSD，使塊存儲的性能有更大的提升。

網絡方面做了分布式設計，主機上用了OpenFlow，通過OpenFlow修改二層協議，讓每個用戶擁有一個獨立的扁平網絡，跟其他用戶的網絡隔離。通過DNS虛擬化技術，使得不同的用戶可以在各自的私有網絡上使用相同的主機名字，并在每個宿主機上部署分布式DNS和DHCP以實現基礎網絡服務的去中心化。

運維

美團云的運維思路跟整個美團的運維思路是一致的。下面介紹的運維思路既適用于美團云，也適用于整個美團網。

運維框架可以概括為五橫三縱。從橫向來看，自底向上分為五個層次：

物理層，包括機房網絡、硬件設施。我們已在開展多機房和城域網建設，從最底層保證基礎設施的穩定性。為了應對大規模機房建設帶來的運維成本，我們實現了Baremetal自動安裝部署的Web化管理，從服務器上架之后，其他工作均由自動化完成，并可以和虛擬機一樣管理物理機。
系統層，包括操作系統、虛擬化。我們在虛擬化基礎之上采用了模板化（鏡像）的方式進行管理，也對Linux內核做了一部分定制開發，例如針對OVS的兼容性做了優化。
服務層，包括Webserver、緩存、數據庫等基礎服務。我們基于Puppet工具做了統一配置管理，有自己的軟件倉庫，并對一部分軟件包做了定制。統一配置管理的好處，一方面是避免不一致的修改，保證集群的穩定性，另一方面是提高運維效率。
邏輯層，包括業務邏輯、數據流。這一層的主要工作是發布和變更。在很多其他公司，業務的發布上線、數據庫的變更管理都是由運維來做，我們認為這樣對開發、運維的協作成本較高，所以一直往開發人員自助的方向做，通過代碼發布平臺、數據庫變更平臺實現開發和運維工作的輕耦合。在發布平臺中，每個應用對應獨立的集群，有一位開發作為應用owner有最高權限，有多位開發作為應用的成員可以自助發布代碼。數據庫變更平臺也有類似的權限控制機制，并在任務執行層面有特殊的穩定性考慮，例如將大的變更任務自動調度到夜間執行，對刪除數據表的任務在后臺先做備份。
應用層，包括用戶可見部分。除了跟邏輯層有類似的發布和變更之外，我們有統一前端平臺，實現訪問流量的進出分離、行為監測和訪問控制，這對于整體的安全性有很大的好處。
從縱向來看，有三部分工作，對上述五個層次是通用的：

監控。從物理層到服務層的監控和報警都是運維來跟進、響應的。對于邏輯層和應用層，也是開發人員自助的思路，運維提供監控API的規范，開發可以自己創建監控項、設定報警規則、進行增刪改查。監控報警之后的處理，現在有些做到了自動化，有些還沒有。尤其是有些基礎架構和業務之間的縱向鏈條還沒有打通，包括建立業務容量模型，某種特定的業務形態在多少用戶的情況下最高負載多少，不同負載等級下的SLA應該是多少，等等，這些模型都建立起來之后就能夠進行自動化的處理。
安全。我們很早就部署了統一的安全接入平臺，所有線上的人工操作都需要登陸relay跳板機，每個人有獨立的登陸帳號，所有線上操作都有審計日志。更多的安全工作由專門的信息安全組負責。
流程。早期基于Jira做了一些簡單的流程，但仍需要改進。現在正在針對比較集中的需求，開發相應的流程控制系統，方向也是自動化、自助化。從業務部門申請VM資源，到業務擴容的整個流程，我們正在進行上下游的打通，未來可以在Web界面上通過很簡單的操作實現，也提供服務化的API，方便其他業務平臺進行集成。虛擬化覆蓋全業務線之后，這些事情做起來都變得很方便。
總之，美團網整體的運維思路就是：保證業務穩定運行，同時推動全面自動化、自助化。涉及開發、運維溝通協作的部分，盡可能通過自動化平臺的方式，由開發人員自助完成。運維人員除了基礎環境、平臺建設之外，幫助業務進行高可用架構的梳理，提高代碼的可運維性，以及定位和解決業務中的各類問題。

改進與演變

美團云從對內服務開始到現在兩年以來，最大的一次改進就是從單機房到多機房的建設，這是跟美團網的城域網建設同步開展的。

單機房的時候，美團網業務早期曾遇到過運營商網絡中斷幾小時的情況，期間業務不可用，非常痛苦。多機房冗余做到最理想的情況下是，即使一個機房整個斷電了，業務也不受影響，當然這就意味著需要100%的冗余量，成本是比較高的。不過對于美團網來說，冗余的成本是很愿意承擔的，因為業務不可用造成的損失要大于做這些冗余的成本，所以我們現在物理資源都留有50%的冗余，帶寬一般會預留30%的冗余。

因為美團網的發展速度很快，去年我們一度遇到資源不夠用的情況，在這上面踩了很多坑之后，開始做一些長遠規劃。現在美團網業務的雙機房冗余已經實施了一部分，美團云也有兩個機房，如果公有云客戶的業務支持橫向擴展，那么也可以做跨機房部署。這種機房級高可用做好了，對穩定性又是一個很大的提升，大大減少網絡抖動對業務的影響，可用性SLA可以從現在的4個9做到更高。有些規模比較大的客戶對服務質量會有比較高的需求，所以美團的城域網、以及未來的廣域網，也會共享給我們的公有云客戶。

另外上面說到我們數據庫跑在物理機上，這一塊現在用的是SSD，讀寫性能頂得上早期的三臺15000轉SAS，瓶頸在千兆網卡上，所以我們現在也在做萬兆網絡的升級改造。數據庫服務以后也會開放給公有云用戶使用，基礎設施跟美團自身業務一致。

未來的計劃

由于使用本地存儲，所以現在虛擬機遷移需要在夜間進行，以減少對用戶服務的影響。為了提高服務的可用性，在確保穩定性和性能的前提下，共享存儲是一個不錯的選擇，所以我們正在測試萬兆網絡下的共享存儲方案。另外，我們底層虛擬化機制用的KVM，本身是沒有熱插拔的功能，這也是我們計劃要做的一件事。

現在很多客戶問我們，什么時候出Redis，什么時候出云數據庫，一些客戶對Redis和MongoDB會有需求，Web服務想要MySQL。我們的計劃是由DBA團隊提供一些模板，相當于是一些專門針對Redis/MySQL做好優化的系統鏡像，讓客戶可以直接拿來用。這可能會在下一個版本release的時候推出。

我們還會提供一些基礎架構的咨詢服務，這個咨詢服務一方面是工程師提供的人工服務，另一方面是以工具+文檔的形式，以互聯網的方式將我們的最佳實踐共享出去。美團網做到現在的幾百億規模，內部有很多經驗積累，如果能把這些積累傳遞給我們的客戶，能夠幫助客戶少走很多彎路。

美團云的架構

    美團云的前端后臺使用的框架是Django，主要處理Web業務相關的邏輯，Django的社區支持比較豐富，文檔健全，本身功能也比較強大。然而有些特性似乎比較多余，比如說Django的很多“黑魔法”是用數據庫外鍵實現的，但是美團內部有自己的一個DBA團隊，負責審核所有項目的數據庫設計，他們則要求不允許用外鍵，據說是因為最佳實踐得出的經驗。

    后端整個云平臺的框架也是用Python實現的，在底層包括虛擬化計算、網絡、存儲三大功能體系，上層則分為資源管理、任務調度、日志、監控、用戶管理、通知報警、API、用量計費等模塊，同時在垂直方向上，又包括關系型數據庫服務、緩存服務、對象存儲服務、負載均衡服務、模板和快照服務、虛擬專用網絡服務等。盡管后端的業務不盡相同，但架構師們抽象出了一套處理工作流的邏輯，并且用Python實現了一個框架。比如，在消息通信機制的選擇上，美團云沒有采用類似OpenStack的采用消息隊列Rabbitmq的方案，而是采用了Webserver，主要原因是考慮到Web server在更加久經考驗，業界對HTTP協議有著更加成熟的方案。

    美團云團隊深度定制了Tornado，將它由單線程、異步回調的機制修改為同時支持多線程和同步查詢的機制。這主要是考慮到在關系型數據庫的查詢上（比如MySQL），沒有較成熟的異步查詢方案，而單線程的阻塞查詢則會影響Tornado的主線程。通過精巧的代碼整合，將Tornado與SQLAlchemy這樣的數據庫ORM集成在一起，成功地解決了數據庫的問題。同時針對SQLAlchemy的特性進行了一些設置，比如關閉Auto-Commit，這樣能夠使得ORM不會在每次查詢的時候都會發出網絡連接，而是在一個線程的業務邏輯里將所有的修改操作hold住，只允許查，在線程結束的時候手動commit，關閉session，提交所有的修改。通過這種方式，實現了一個線程級別的數據庫事務鎖和對象鎖，使得程序員們能在一個線程的邏輯里面同時查詢和修改多個數據庫表，同時保證業務的原子性。陳博說“通過這些框架，程序員們在開發上層業務的時候也感覺到更加便捷了。”

    聽眾對演講反應熱烈，表示受益匪淺，也對美團產生的敬佩之情。美團能發展到今天這般規模，其技術能力不容小覷。”當然，這些只是美團云整個技術的冰山一角。美團是中國第一大的O2O電商，網絡流量500T/天 ，月活躍用戶數超過1.3億。支持這一龐大業務規模的正是美團云。今年3月，美團云獲得IDC牌照，8月對外開放首個高品質的自建機房。同時，美團云通過第四批可信云認證，并將“電商云”獎項收入囊中。2015年第四季度，美團云也將推出數據產品及行業解決方案。所有的這些都意味著，美團云致力于為千萬用戶提供穩定的公有云服務這一愿景，正在成為現實。