淺談關于云服務架構的演進過程
大小:0.3 MB 人氣: 2017-10-10 需要積分:1
標簽:云服務架構(1576)
摘要:MaxLeap從一個對內的私有云服務平臺,發展到對外服務的BaaS平臺,其功能覆蓋了移動領域開發、運營的完整服務鏈,近期還會推出PaaS服務。在這個過程中,支撐整個平臺的基礎架構也在不斷演進。本文結合了云平臺的業務發展,介紹基礎架構演進過程的主要思路、遇到的難題、用到的開源技術和未來的規劃。前言
MaxLeap早期是一家研發、運營移動應用和手機游戲公司,發展過程中積累了很多通用組件。這些組件很大程度幫公司在移動研發過程中節省了時間和成本,有沒有可能以云服務的方式開放出去,創造更大的價值?延續這個思路,公司成立了云服務部門,嘗試服務的商業化。
從對內提供接口服務到對外提供云服務,經歷了三個階段發展:1.0時代,定位對內服務,為公司研發的幾十款應用提供服務端功能,推送、統一用戶管理等API接口,可以說是非常普通的接口服務;2.0時代,定位對外服務,除了支撐公司的移動研發以外,同時對外開放服務,提供更多的功能接口,也參考了行業的通用做法,形成了針對移動研發加速和提高運營效率的BaaS云平臺;3.0時代,定位基礎研發平臺,工具鏈逐漸完整,從研發、上線、運維到運營,提供應用管理、支付、IM、推送等SaaS功能,也提供托管、發布、監控、日志等PaaS功能,逐步形成SaaS + PaaS的研發平臺。
云服務概念
常見的云服務有幾種方式:
1. IaaS(Infrastructure as a Service),基礎設施即服務。提供云端的基礎設施為主,比如提供主機、存儲、網絡、CDN、域名解析等功能,知名廠商有阿里云、AWS、Azure等;
2. PaaS(Platform),平臺即服務。提供云端的發布、數據庫服務、文件存儲、緩存服務、容器管理等基礎存儲和管理組件,自動化了程序的配置、發布、管理,有Heroku、Google App Engine、Force.com等;
3. SaaS(Software as a Service),軟件即服務。提供云端的應用服務,ERP、HR、CRM等在線系統,每個賬戶或者每家公司有獨立的數據存儲,通過賬戶進行權限和訪問隔離,知名廠商有Salesforce、Successfactor、Zendesk等;
4. 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 服務化架構
背景
隨著業務不斷發展以及新的產品定位,單應用架構的弊端不斷暴露出來,要求我們在新的規劃中,重新設計整個后端架構。
非常好我支持^.^
(0) 0%
不好我反對
(0) 0%