從應用到平臺 - 云服務架構的演進過程2016-07-12 15:48
　　介紹
　　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。
　　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還有單點問題，脫單是高可用系統中首要需要解決的問題。所有服務部署在一起，出問題時相互影響，項目耦合度高，擴展困難。開發效率低，發布新功能時相互依賴等，這些都是單用架構設計最明顯的問題。