浅谈关于云服务架构的演进过程
大小: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需要研发和运营,每个应用功能各异,种类包括浏览器、音视频工具、社交工具、清理大师、图片存储类和手游等,门类很多、很杂。如何提高研发效率,实现一套统一的研发、管理和运营体系,是当时的主要诉求。对主要功能进行梳理之后发现,各类应用共同需要依赖的组件包括,用户体系、云参数体系、推送服务、数据存储和广告服务。
![浅谈关于云服务架构的演进过程](/uploads/allimg/171010/2362486-1G010150941V1.png)
图1 1.0业务模型
需求基本明确后,目标是快速上线,然后小版本迭代。
设计
当时4个后端研发人员,Java出身,人少但是技术精干。结合团队情况和产品需求,决定采用如下架构,简单但给力。
![浅谈关于云服务架构的演进过程](/uploads/allimg/171010/2362486-1G010150954461.png)
图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%