摘要：應用的研發上線運維運營形成閉環，順利完成從對內服務到公共平臺的升級。從功能角度，只能支持靜態方式設置反向代理，然后，而平臺有服務對應的后端服務和端口是有動態調整需求。架構上是基礎組件需要進行升級，數據訪問層日志監控系統等。

? ? ? ?MaxLeap早期是一家研發、運營移動應用和手機游戲公司，發展過程中積累了很多通用組件。這些組件很大程度幫公司在移動研發過程中節省了時間和成本，有沒有可能以云服務的方式開放出去，創造更大的價值？延續這個思路，公司成立了云服務部門，嘗試服務的商業化。

? ? ? ?從對內提供接口服務到對外提供云服務，經歷了三個階段發展：1.0時代，定位對內服務，為公司研發的幾十款應用提供服務端功能，推送、統一用戶管理等API接口，可以說是非常普通的接口服務；2.0時代，定位對外服務，除了支撐公司的移動研發以外，同時對外開放服務，提供更多的功能接口，也參考了行業的通用做法，形成了針對移動研發加速和提高運營效率的BaaS云平臺；3.0時代，定位基礎研發平臺，工具鏈逐漸完整，從研發、上線、運維到運營，提供應用管理、支付、IM、推送等SaaS功能，也提供托管、發布、監控、日志等PaaS功能，逐步形成SaaS + PaaS的研發平臺。

? ? ? ?常見的云服務有幾種方式。

? ? ? ?IaaS（Infrastructure as a Service），基礎設施即服務。提供云端的基礎設施為主，比如提供主機、存儲、網絡、CDN、域名解析等功能，知名廠商有阿里云、AWS、Azure等。

? ? ? ?PaaS（Platform），平臺即服務。提供云端的發布、數據庫服務、文件存儲、緩存服務、容器管理等基礎存儲和管理組件，自動化了程序的配置、發布、管理–Heroku、Google App Engine、Force.com等。

? ? ? ?SaaS（Software as a Service），軟件即服務。提供云端的應用服務，ERP、HR、CRM等在線系統，每個賬戶或者每家公司有獨立的數據存儲，通過賬戶進行權限和訪問隔離，知名廠商有Salesforce、Successfactor、Zendesk等。

? ? ? ?BaaS（Backen as a Service），后端即服務，起初專指針對移動端的研發提供的云服務，降低移動研發的復雜度，讓開發者關注與移動端開發即可。流行的服務有幾大類：綜合類，Parse、Kinvey；分析類，友盟、TalkingData、神策數據；支付類，Beecloud、Ping++；IM類，環信、網易；消息類，極光、個推等。

? ? ? ?我們在2.0時代把自己定位于BaaS，隨著功能的不斷演進3.0著眼于PaaS和SaaS。

? ? ? ?當時公司有幾十款App需要研發和運營，每個應用功能各異，種類包括瀏覽器、音視頻工具、社交工具、清理大師、圖片存儲類和手游等，門類很多、很雜。如何提高研發效率，實現一套統一的研發、管理和運營體系，是當時的主要訴求。對主要功能進行梳理之后發現，各類應用共同需要依賴的組件包括，用戶體系、云參數體系、推送服務、數據存儲和廣告服務。

圖1 1.0業務模型

? ? ? ?需求基本明確了，目標是快速上線，然后小版本迭代。

? ? ? ?當時4個后端研發人員，Java出身，人少但是技術精干。結合團隊情況和產品需求，決定采用如下架構，簡單但給力。

圖2 1.0架構

? ? ? ?典型的web應用架構方式，使用Nginx做反向代理和負載均衡，后面跟了多個JVM實例。每個JVM實例由Jetty作為應用服務器，提供REST接口，服務層實現具體的邏輯。DAL層對DB和緩存進行封裝，提供統一的數據訪問接口。Redis作為緩存方案，支持多個shard水平擴容，TPS高、性能好。Cassandra作為數據存儲引擎，無中心、可水平擴展、易維護，沒有專門的運維人員，對研發人員非常友好，由于沒有事務場景，NoSQL完全滿足當時的需求。RabbitMQ作為消息中間件方案，不同進程間通信，支持HA，支持持久化。Zookeeper用于存儲基礎配置信息。

? ? ? ?這種簡單的設計，有效支持了公司幾十款應用的運行，日訪問量達數十億級別。統一后臺基礎服務和移動端SDK后，提高了移動應用的研發和上線速度，研發了用戶管理、推送這些基礎功能，在移動端幾行代碼搞定。通過控制臺，能有效管理應用和配置信息。其實對于多數十多個研發人員的公司來講，這樣的單應用架構性價比最高，解決商業上的問題才是關鍵。

? ? ? ?也有不少需要改進的地方，Cassandra作為業務數據的存儲，查詢非常不靈活，依賴設計時對row key和composit key的精確把握，擴展非常困難，再加上對翻頁、排序等支持有限，在數據層做了很多特殊處理。整個系統沒有脫單，Redis、Nginx還有單點問題，脫單是高可用系統中首要需要解決的問題。所有服務部署在一起，出問題時相互影響，項目耦合度高，擴展困難。開發效率低，發布新功能時相互依賴等，這些都是單用架構設計最明顯的問題。

? ? ? ?隨著業務不斷發展以及新的產品定位，單應用架構的弊端不斷暴露出來，要求我們在新的規劃中，重新設計整個后端架構。

? ? ? ?來看新的需求：

定位公有云，服務標準化

多租戶支持，用戶數據需要隔離，每個公司都有自己的后臺管理和賬號管理，不同工作人員區分權限職責，允許同時有多款應用，應用在邏輯上相互獨立，每個應用可以使用所有服務

更靈活的存儲和查詢服務

提供基礎數據分析功能，提供代碼托管等更多云服務

圖3 2.0業務模型

? ? ? ?服務規模擴大后，大家解決單應用弊端的方法也都類似，以獨立運行的業務為單位，對服務縱向拆分，提高單個服務的聚合程度，降低服務間的相互依賴，從而解決降低研發、測試、上線過程中各個服務相互依賴、相互影響的問題。

? ? ? ?除此以外，我們對數據存儲和網絡層也進行了改進。平臺所支持的兩類服務，分別是云服務和云計算。在新的設計中，云服務部分的重點是重構、支持在新架構上快速研發新服務，云計算部分的重點是，構建起來一個穩定、可靠、高效的基礎架構。

圖4 2.0云服務架構

? ? ? ?網絡，最外層增加了ELB，IP地址直接暴露在公網是非常危險的方式，通過DNS配置CNAME指向域名，降低了被DDOS的風險，提高了Nginx的可用性。ELB本身會在訪問增加時，自動伸縮，配合IaaS廠商提供的AutoScalling服務，可以抵御多數DDOS攻擊。通過Nginx作為反向代理和負載均衡，不同服務指向不同的upstram地址和端口。服務間禁止相互依賴。

? ? ? ?容器，每個服務都運行在Docker中，服務之間環境和資源隔離，能夠快速遷移和部署，統一了交付和發布流程。每個容器無狀態，服務遷移、擴容、宕機等問題迎刃而解，在服務化過程中起到很關鍵的作用。

? ? ? ?數據，NoSQL部分主要依賴MongoDB，Wired Tiger + SSD，由于MongoDB的Schema-less特性，開發者可以根據自己的需求隨時調整實體的定義。天生為分布式設計，支持復制集高可用方案，支持多Shard水平擴展。關系型數據庫采用MySQL，用于實現支付、訂單、配置信息等需要事務支持的業務，我們基于MHA實現MySQL的高可用和讀寫分離。不同服務所依賴的庫必須分離，從數據著手保障用戶資源的隔離。

? ? ? ?存儲/緩存，塊數據依賴AWS的S3，權限控制、分桶策略比較實用，可用性有保障；緩存依然使用Redis，為了解決單點問題，對原有版本進行了升級，采用官方的3.0集群方案，支持分片和高可用，當然也有其它方案可選，比如codis等代理的方案。

圖5 2.0云分析架構

? ? ? ?數據收集部分采用REST + Kafka方式，其中很重要的一部分是DataTransform，用于數據標準化、過濾、流控等用途，基于vert.x實現。

? ? ? ?計算部分參考Lambda架構實現，分為Speed Layer、Batch Layer、Serving Layer三層。

? ? ? ?Speed Layer，基于Storm實現，引擎監聽Kafka中收集到的新數據，把一些對實時性要求高的指標計算完成，寫入展示層。Batch Layer，基于Hadoop生態實現，通過開源項目Camus，把Kafka中監聽到的數據存儲在HDFS中，然后通過HIVE或者M/R的Job，計算各種指標，工作流通過oozie來調度，最終結果也寫入展示層，并且覆蓋掉實時計算的結果。結果數據根據不同指標，按天、周、月分別存儲在Cassandra中，有很高的寫速度，無限水平擴展。展示層，數據同時用antlr4j實現了SQL解析，訪問Cassandra中的計算結果。

? ? ? ?相比較1.0時期，架構上更合理，擴展性、維護性、魯棒性都有很明顯提升。功能上，完成移動應用研發大部分組件（統計分析、支付、IM、社交、在線參數、推送、營銷、云數據、云存儲、云代碼)。應用的研發、上線、運維、運營形成閉環，順利完成從對內服務到公共BaaS平臺的升級。團隊上，1-3人一個服務的研發，測試、上線的節奏可以自己把控。

? ? ? ?當然，業務在演進，也有新的問題需要去解決。從功能角度，Nginx只能支持靜態方式設置反向代理，然后reload，而平臺有服務對應的后端服務和端口是有動態調整需求。從架構角度，在相對成熟的系統中，日志、監控這些基礎組件需要統一收集、管理、處理。數據訪問層、RPC等基礎服務也要標準化。

圖6 3.0業務模型

? ? ? ?對于創業公司而言，業務隨時會有調整，作為技術人員，需要能夠應對這種變化，架構上為這些變化做準備。產品向3.0演進由新的業務需求和架構自身的調整需求共同推動。新的業務需要支撐一個全網營銷的SaaS產品線，產品支持配置操作生成App + 微信商城 + 手機網站，以及營銷，就是需要本來專注于移動端研發定位的BaaS，向PaaS化和SaaS前進。架構上是基礎組件需要進行升級，數據訪問層、RPC、日志、監控系統等。于是我們提出一個目標，就是平臺化，數據訪問的組件以PaaS形式提供給開發者和內部團隊，標準化API網關、日志、監控系統。

? ? ? ?設計上依然延續穩定、成熟、解決問題的思路。網關服務作為所有請求的入口，穩定、性能、水平擴展是考慮的要素。數據訪問層，就像一個項目的大動脈，所有的訪問壓力、瓶頸、安全問題會在這里匯合，如何構建一條數據訪問的高速公路是我們的目標。日志和監控，雖然沒有業務系統那么核心，但是關鍵時刻出現問題需要排查時他們很大程度會影響解決問題的效率，好的監控系統能第一時間把正確的信號通知到正確的人，而爛的監控只會為運維帶來困擾。

? ? ? ?我們設計網關的初衷是替代掉Nginx，在自研的網關上控制規則轉發、主機注冊、容器狀態檢查、負載均衡、服務拒絕、限速等功能。Nginx是非常優秀的一個軟件，也滿足一部分網關的功能，但是無法滿足我們不斷進化的需求。

? ? ? ?整個網關系統由規則控制組件和容器管理組件兩部分組成。后的服務在啟動后，向Hydra-容器管理組件，注冊自己的服務、IP地址和端口信息，Hydra隨后接管容器的生命周期管理，進行健康檢查，Failover處理，并把相關的信息保存在Zookeeper和MySQL中。規則控制組件在請求到達后，進行規制匹配、路由轉發、限制、限速等處理。

? ? ? ?目前網關用在了大多數服務中，下步計劃是所有服務統一由網關進行管理，下圖是網關系統的最終形態。

圖7 3.0網關架構

? ? ? ?結構化的業務數據主要存儲在MySQL和MongoDB中，設計上我們增加了數據代理層，代理層完全兼容MySQL和MongoDB的數據訪問協議，讓開發人員對代理完全無感，表面上是在訪問特定的數據庫，實際上連接上數據代理后，由代理對數據操作做解析和路由。

? ? ? ?當然，如果是僅僅實現代理的功能，有很多開源項目可以使用比如MyCat、MySQL Proxy等，我們對代理有這些需求，數據訪問路由和配置變更，數據訪問鑒權和處理，日志采集發送，流控和服務拒絕。

圖8 3.0公共組件架構

? ? ? ?設計之初也有考慮自己研發，通過調研后發現ElasticSearch + Logstash + Kibana完全滿足我們的需求，并且ES的生態和社區非常活躍。通過早期幾個服務的試水，最終決定整個平臺基于ELK構建日志系統。

? ? ? ?我們是這樣做的，在每臺主機上部署Logstash Angent采集格式化的日志數據，向Logstash Server發送日志。為了降低運維成本，我們把Logstash Forward做成Docker鏡像，通過Salt來管理所有的Agent。Logstash Server在拿到日志信息后，不做任何規則上的處理，將數據保存在ES中。其實Logstash Server自身有日志解析和格式化的功能，但這樣做會嚴重影響它的吞吐量，于是我們的方案是把日志標準的流程控制在源頭。接下來，在Kibana中建立各種服務的面板和視圖，便可以進行瀏覽和檢索了，還可以周期對日志進行rotate、分析。

圖9 3.0日志系統

? ? ? ?基于日志系統的基礎架構，不同服務將Metrics輸出到文件系統，通過LogStash和ES收集。在Kibana中定義視圖，Kibana使用ES作為自己的存儲引擎。比如新增一個視圖后，Kibana會在ES的.kibana這個索引中創建一份視圖的定義。

? ? ? ?有了Metrics數據和視圖的展示，下一步是報警。利用Nagios的報警機制，基于JNRPE實現報警的邏輯。報警邏輯通過讀取ES中.kibana某一個視圖的定義，和對應的閾值設置，通過比較當前值和閾值，返回某一個服務對應特定指標的監控狀態。Nagios拿到狀態后，決定是否報警。

圖10 3.0監控系統

? ? ? ?相比較2.0時期，統一了主要的基礎組件，降低了不同服務之間重復勞動部分。通過日志系統也提升了定位問題的效率，接下來還會考慮實現一套自己的請求trace系統，希望能夠跟蹤整個請求的生命周期，為尋找問題和定位性能瓶頸做參考。

? ? ? ?從應用到平臺，公司業務和產品定位在不斷的演進，架構也隨之發生了天翻地覆的變化。有一點是我們研發人員時刻要提醒自己的，不能脫離業務去談技術，滿足業務是原動力，一切拋開業務去空談架構的做法都是耍流氓。

? ? ? ?成熟簡單的技術就是最合適的，踩坑在所難免，但是如何把有限的資源用于做對的事情，不僅對商業和產品適合，對研發也同樣適合?；ヂ摼W公司多數都有由小團隊、小想法、小產品，一步步發展起來的，在這個過程中能夠通過設計和決策，在正確的時間做正確的事情，讓產品能夠快速迭代，快速上線，才是架構人員最需要考慮的事情。

相關閱讀：
移動云平臺的基礎架構之旅-云應用篇
移動開發篇_暢談移動云平臺之云代碼的基礎架構設計
微服務系統中的服務發現機制

作者系力譜宿云 LeapCloud 團隊_云服務負責人：秦鵬【原創】
首發地址：https://blog.maxleap.cn/archives/940

2014.02 加入上海力譜宿云團隊，啟動云平臺的研發
負責公司 MaxLeap，MaxWon 后端研發和維護工作
現任架構和服務部負責人
關注分布式存儲、緩存、中間件、容器技術、微服務、公有云等領域

作者譯作：
微服務實戰：從架構到發布（一）
微服務實戰：從架構到發布（二）

歡迎關注微信訂閱號：從移動到云端（主推技術活動信息+技術文）
歡迎加入我們的力譜宿云 LeapCloud 活動QQ群：555973817，我們將不定期做技術分享活動。

若有轉載需要，請轉發時注意自帶作者信息一欄并本自媒體公號：力譜宿云 LeapCloud，尊重原創作者的勞動成果~ 謝謝配合~

近期線下技術活動預告：

活動主題：【技術分享】Vert.x中國用戶組（上海地區）第一次技術沙龍
分享內容：

分享主題1：JVM上的高性能Reative工具Vert.x3介紹

分享主題1：Vert.x在maxleap的最佳實踐

分享主題1：Vert－web注解封裝

活動時間：2016/07/24(周日) 14:00 至 2016/07/24 17:00 ?
活動場地：上海浦東新區金科路2889弄（近祖沖之路）長泰廣場C座12層
報名鏈接：http://www.hdb.com/party/ydtru-comm.html