【架构】需求决定架构 —— 萌Mark的架构升级之路

CarmineWood 8年前

来自: http://blog.csdn.net/diandianxiyu_geek/article/details/50491265


前言

2014年到2015年,是IP爆发的一年,在这一年中,出现很多因为IP火起来的产品。其中有一款产品,凭借着新奇的玩法和萌萌的IP形象,取得了不俗的成绩,也使我司得到数量客观的融资。
萌Mark,萌mark—呆萌漫画DIY、心情分享有图配。
萌Mark

架构升级之路

在这个项目中,我担任的为服务端主程好吧 ,服务端连部署也是我一个人做的 :),看着这个项目从0到1,再从1到N的发展历程,下面对整个服务端的架构实现以及发展进行技术分享,希望得到学习。

从无到有,基本实现

产品的第一阶段,为快速实现阶段。需要用最短的时间验证一个产品的想法是不是正确。
我们采用的是阿里云,进行线上的服务器部署。
项目初期,采用较低配置的ECS服务器以及RDS服务器,由于没有配备专业的运维人员,我们把主要的运维工作交给了阿里云。

简单实现

这样,我们就用很低的成本跑出了简单的第一个版本。

实际出发,需求为王

每个产品的特性不同,也就意味着架构演变的流程是不同的。

萌Mark是以图片为核心的产品,数据传输是以图片为核心,扩展出众多参数,所以,图片数据是整个研发过程中的重点。

我们采用阿里云的OSS文件存储,配合CDN加速,同时解决了图片访问速度问题,和图片占用服务器带宽的问题阿里云的带宽很贵的,你懂的~

这样,结合产品特性的初期架构基本搭建完成,正式版本的项目发布,开始跑数据了。

基本结构

纵向扩展,简单扩充

产品上线之后,用户数量出现了增长,同时数据访问增加。

低配置的服务器已经不能满足需求,我们开始了对服务器配置的简单升级。

同时对于专题模板之类的数据,数据上传之后几乎不会变化,所以,加入了缓存层,对数据库的需要访问的数据进行缓存,这里采用的是阿里云的OCS缓存层,用起来和Memecache一样,不是专业运维就不要抢专业运维的活儿,小心挖坑把自己埋了~

基本完整

横向延展,负载均衡

随着项目扩展,单机服务器升级的成本到达了投入成本的性能的临界点,过了这个点之后,升级配置的成本超过了获得性能的增量。

恩,是时候用负载均衡了…

通过增加同等配置的服务器,在加上阿里云的SLB负载均衡服务,不仅可以只管控制服务器的上线下线,还可以隐藏服务器对外ip,还可以达到不切断服务更新线上环境~

完善阶段

总结

  • 架构升级不能一步到位,没有需要的升级都是在浪费预算
  • 根据需求排序优先级解决问题,产品不同,升级路径不同
  • 尽可能降低潜在的坑,不会运维不要硬上

P.S.

对小团队的产品开发,实现优先于运行效率,快速实现就是最大的节约成本。