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

前言

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

架构升级之路

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

从无到有，基本实现

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

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

实际出发，需求为王

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

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

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

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

纵向扩展，简单扩充

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

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

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

横向延展，负载均衡

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

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

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

总结

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

P.S.

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