云服务架构的演进过程

从应用到平台 - 云服务架构的演进过程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还有单点问题，脱单是高可用系统中首要需要解决的问题。所有服务部署在一起，出问题时相互影响，项目耦合度高，扩展困难。开发效率低，发布新功能时相互依赖等，这些都是单用架构设计最明显的问题。