從應用到平臺 - 雲服務架構的演進過程

時間 2019-12-04

原文原文鏈接

介紹

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

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

雲服務概念

常見的雲服務有幾種方式。web

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

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

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。緩存

1.0 單應用架構

背景

當時公司有幾十款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還有單點問題，脫單是高可用系統中首要須要解決的問題。全部服務部署在一塊兒，出問題時相互影響，項目耦合度高，擴展困難。開發效率低，發佈新功能時相互依賴等，這些都是單用架構設計最明顯的問題。

2.0 服務化架構

背景

隨着業務不斷髮展以及新的產品定位，單應用架構的弊端不斷暴露出來，要求咱們在新的規劃中，從新設計整個後端架構。

來看新的需求：

定位公有云，服務標準化
多租戶支持，用戶數據須要隔離，每一個公司都有本身的後臺管理和帳號管理，不一樣工做人員區分權限職責，容許同時有多款應用，應用在邏輯上相互獨立，每一個應用可使用全部服務
更靈活的存儲和查詢服務
提供基礎數據分析功能，提供代碼託管等更多雲服務

圖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等基礎服務也要標準化。

3.0 平臺化

背景

圖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系統，但願可以跟蹤整個請求的生命週期，爲尋找問題和定位性能瓶頸作參考。

總結

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

成熟簡單的技術就是最合適的，踩坑在所不免，可是如何把有限的資源用於作對的事情，不只對商業和產品適合，對研發也一樣適合。互聯網公司多數都有由小團隊、小想法、小產品，一步步發展起來的，在這個過程當中可以經過設計和決策，在正確的時間作正確的事情，讓產品可以快速迭代，快速上線，纔是架構人員最須要考慮的事情。

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

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

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

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

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

近期線下技術活動預告：

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