前言

2014年到2015年，是IP爆發(fā)的一年，在這一年中，出現(xiàn)很多因?yàn)镮P火起來的產(chǎn)品。其中有一款產(chǎn)品，憑借著新奇的玩法和萌萌的IP形象，取得了不俗的成績(jī),也使我司得到數(shù)量客觀的融資。
萌Mark，萌mark—呆萌漫畫DIY、心情分享有圖配。

架構(gòu)升級(jí)之路

在這個(gè)項(xiàng)目中，我擔(dān)任的為服務(wù)端主程好吧 ，服務(wù)端連部署也是我一個(gè)人做的 :），看著這個(gè)項(xiàng)目從0到1，再?gòu)?到N的發(fā)展歷程，下面對(duì)整個(gè)服務(wù)端的架構(gòu)實(shí)現(xiàn)以及發(fā)展進(jìn)行技術(shù)分享，希望得到學(xué)習(xí)。

從無到有，基本實(shí)現(xiàn)

產(chǎn)品的第一階段，為快速實(shí)現(xiàn)階段。需要用最短的時(shí)間驗(yàn)證一個(gè)產(chǎn)品的想法是不是正確。
我們采用的是阿里云，進(jìn)行線上的服務(wù)器部署。
項(xiàng)目初期，采用較低配置的ECS服務(wù)器以及RDS服務(wù)器，由于沒有配備專業(yè)的運(yùn)維人員，我們把主要的運(yùn)維工作交給了阿里云。

這樣，我們就用很低的成本跑出了簡(jiǎn)單的第一個(gè)版本。

實(shí)際出發(fā)，需求為王

每個(gè)產(chǎn)品的特性不同，也就意味著架構(gòu)演變的流程是不同的。

萌Mark是以圖片為核心的產(chǎn)品，數(shù)據(jù)傳輸是以圖片為核心，擴(kuò)展出眾多參數(shù)，所以，圖片數(shù)據(jù)是整個(gè)研發(fā)過程中的重點(diǎn)。

我們采用阿里云的OSS文件存儲(chǔ)，配合CDN加速，同時(shí)解決了圖片訪問速度問題，和圖片占用服務(wù)器帶寬的問題，阿里云的帶寬很貴的，你懂的~

這樣，結(jié)合產(chǎn)品特性的初期架構(gòu)基本搭建完成，正式版本的項(xiàng)目發(fā)布，開始跑數(shù)據(jù)了。

縱向擴(kuò)展，簡(jiǎn)單擴(kuò)充

產(chǎn)品上線之后，用戶數(shù)量出現(xiàn)了增長(zhǎng)，同時(shí)數(shù)據(jù)訪問增加。

低配置的服務(wù)器已經(jīng)不能滿足需求，我們開始了對(duì)服務(wù)器配置的簡(jiǎn)單升級(jí)。

同時(shí)對(duì)于專題模板之類的數(shù)據(jù)，數(shù)據(jù)上傳之后幾乎不會(huì)變化，所以，加入了緩存層，對(duì)數(shù)據(jù)庫(kù)的需要訪問的數(shù)據(jù)進(jìn)行緩存，這里采用的是阿里云的OCS緩存層，用起來和Memecache一樣，不是專業(yè)運(yùn)維就不要搶專業(yè)運(yùn)維的活兒，小心挖坑把自己埋了~

橫向延展，負(fù)載均衡

隨著項(xiàng)目擴(kuò)展，單機(jī)服務(wù)器升級(jí)的成本到達(dá)了投入成本的性能的臨界點(diǎn)，過了這個(gè)點(diǎn)之后，升級(jí)配置的成本超過了獲得性能的增量。

恩，是時(shí)候用負(fù)載均衡了…

通過增加同等配置的服務(wù)器，在加上阿里云的SLB負(fù)載均衡服務(wù)，不僅可以只管控制服務(wù)器的上線下線，還可以隱藏服務(wù)器對(duì)外ip，還可以達(dá)到不切斷服務(wù)更新線上環(huán)境~

總結(jié)

• 架構(gòu)升級(jí)不能一步到位，沒有需要的升級(jí)都是在浪費(fèi)預(yù)算
• 根據(jù)需求排序優(yōu)先級(jí)解決問題，產(chǎn)品不同，升級(jí)路徑不同
• 盡可能降低潛在的坑，不會(huì)運(yùn)維不要硬上

P.S.

對(duì)小團(tuán)隊(duì)的產(chǎn)品開發(fā)，實(shí)現(xiàn)優(yōu)先于運(yùn)行效率，快速實(shí)現(xiàn)就是最大的節(jié)約成本。

總結(jié)

以上是生活随笔為你收集整理的【架构】需求决定架构 —— 萌Mark的架构升级之路的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。