作為一個移動端開發(fā)人員來講，是很難接觸到后端項目架構的，所幸，從2015年開始，負責部分管理工作，參與了項目架構相關的工作。項目從小到大，架構也越來越復雜，特別是最近做的一個跨國型項目，涉及到國內(nèi)國外服務器的部署，尤為復雜。本文結合這些項目實踐，介紹基于阿里云的后端架構設計。（部分內(nèi)容為引用他人的文章，文中已有說明，咱是尊重版權的）

1.基礎架構：

2015年初，團隊做了一個美食項目，業(yè)務邏輯比較簡單，主要是實現(xiàn)用戶、餐館、美食三元素的增刪改查及三者之間的關聯(lián)查詢。后端程序采用的是php，前端面對的是iOS和Android兩款App。當時購買了一臺阿里云ECS服務器，在該服務器上安裝了MySQL以用于數(shù)據(jù)存儲。應用程序、數(shù)據(jù)庫、文件等所有資源都在一臺服務器上，網(wǎng)站架構如下圖所示：

基礎架構.jpg

此架構簡單，適用于項目初期，訪問量比較小情況。這里著重要說一下的是，此項目中涉及到資源文件的存儲但并沒有用到OSS服務器，我們的做法是在客戶端在上傳圖片文件的時候，接口程序會將圖片壓縮為所需的多種尺寸，并保存在對應的文件夾下，前端再取圖片的時候在URL后拼接對于的尺寸即可訪問。如客戶端上傳了一張圖片，程序會壓縮為3030，120120，240*240三種尺寸，客戶端根據(jù)界面需要采用xxxxx_30.png的方式訪問，這個功能在阿里云的OSS服務器上有現(xiàn)成的服務，無需自己壓縮。

2.應用與數(shù)據(jù)分離架構：

2015年底，團隊開始做了一個圖片社交項目，其功能是全部模仿Instagram，但是內(nèi)容主要針對的是服裝、奢侈品。用戶通過手機拍攝一些奢侈品、服裝相關的視頻、圖片，并添加對應的下載鏈接，發(fā)布到平臺后，用戶可以看到其他所有人發(fā)布的內(nèi)容，并可以根據(jù)鏈接購買。
這個項目中涉及到大量視頻、圖片的處理，這里我們實現(xiàn)了應用服務、數(shù)據(jù)服務、資源服務的分離。我們購買了四臺阿里云服務器，分別是兩臺ECS、一臺OSS、一臺RDS，其結構如下圖：

分離.png

3.集群式部署初級架構

2016年我們開始做一個大型的在線教育平臺項目，經(jīng)歷一年的磨合，項目趨于穩(wěn)定，我們的服務器架構也日臻完善。本想總結一下服務器的架構，在下筆之前在網(wǎng)上看到了他人總結的一篇文章，項目架構設計總結，再此先向作者表示敬意，以下是引用的這篇文章的部分內(nèi)容：

項目背景

項目的前端主要為ios應用以及一些web管理系統(tǒng)，后端的職能主要為前端提供數(shù)據(jù)接口。我個人在項目中主要負責整個后端的架構設計、服務器運維、php開發(fā)等一系列后端工作，因為主要是我一個人負責，在一定程度上也減少了許多溝通成本。

總體架構

項目后端架構使用阿里云服務搭建，其中RDS為主從集群，并配備災備實例。ECS可根據(jù)業(yè)務量動態(tài)彈性伸縮，其余服務均采用單實例的方式遠程調用。

2104726472.png

VPC

搭建VPC的原因有以下幾點
1.可以將業(yè)務數(shù)據(jù)庫和業(yè)務服務器放置在可以自己掌握的同一內(nèi)網(wǎng)，可以提高一些安全性。
2.阿里云服務之間通過內(nèi)網(wǎng)訪問的流量是不收費的。所以在選購服務時，帶寬可以選擇流量版，這樣在保證帶寬速率的同時，還可以極大的減少運維費用。
舉個例子：同樣一臺ECS，在同為百兆帶寬的情況下，每月的費用如下圖：

按固定帶寬

[圖片上傳中...(4282504957.png-8d5eea-1513671576852-0)]

按使用流量

4282504957.png

當然，能這樣的做的原因也是因為在這個架構中，ECS僅處理業(yè)務邏輯，幾乎不存儲文件資源。大部分靜態(tài)資源，如視頻圖片等，都是存儲在OSS上。如果存放靜態(tài)資源，比如下視頻或圖片什么的，流量一多那就很虧了。
3.內(nèi)網(wǎng)訪問，穩(wěn)定而且速度快。

業(yè)務數(shù)據(jù)層

RDS

項目一開始，RDS選購的是共享型單實例的，隨著業(yè)務量的提升，可以多區(qū)域部署只讀實例。另外，保險起見，主實例可以配有一個災備實例，防止意外發(fā)生。

Redis

提到阿里云的這個Redis，不得不吐槽一句，它竟然是不支持主從的，只能單實例，不過，用它做數(shù)據(jù)緩存，還真是蠻不錯的選擇，響應速度非?？?。而且，因為是放置在內(nèi)網(wǎng)的且只能內(nèi)網(wǎng)訪問，所以安全性也很高。

MongoDB

結構型數(shù)據(jù)，主要存儲檔案式的數(shù)據(jù)，比如每個用戶的操作行為，以檔案式記錄并進行統(tǒng)計分析，方便下一階段的項目做個性化服務。另外一些關聯(lián)復雜的數(shù)據(jù)，也可以用MongoDb存儲，可以提高訪問速度。還有，一些對軟件應用版本比較敏感的數(shù)據(jù)也可以存在MongoDB中，比如a版本拿到A數(shù)據(jù)，b版本拿到B數(shù)據(jù)，而這個AB數(shù)據(jù)都是由很多關聯(lián)關系復雜的數(shù)據(jù)所組成，如果把這些數(shù)據(jù)根據(jù)版本號存儲在不同的MongoDB檔案中，需要時，直接根據(jù)版本號拿就可以了，這樣就避免了很多的mysql查詢。

靜態(tài)資源

OSS + CDN
OSS存儲靜態(tài)資源，CDN(內(nèi)容分發(fā)網(wǎng)絡)可以加速靜態(tài)資源的下載速度。至于資源鏈接地址，客戶端可以通過接口訪問從后端業(yè)務數(shù)據(jù)庫中拿到。
服務器安全

運維層面
1.選購了阿里云的web防火墻和態(tài)勢感知的服務。這兩個服務可以實時監(jiān)控服務器狀態(tài)，識別并跟蹤攻擊來源和類型，可以說，用這兩個工具也節(jié)省了很多人力成本。阿里云還有其它安全類產(chǎn)品，可以根據(jù)項目選購，使用起來也都很方便。
2.配置firewalld。

業(yè)務層面
針對接口訪問的安全性，主要做了以下工作
1.簽名驗證：防止偽造請求
2.訪問頻次限制：計數(shù)器是用phpredis制作的毫秒級計數(shù)器
3.https訪問
4.部分敏感數(shù)據(jù)，使用RSA非對稱加密

服務器集群

主ECS

通過這臺ECS，可以管理其它從屬的ECS，并查看狀態(tài)。安裝的主要工具為ansible。
如果不需要用這臺ECS來做負載均衡的話，可以配置白名單連接，只允許管理員ip才能訪問。

從屬ECS

這類ECS服務器只存放邏輯代碼，所以當需求量增加時，只需增加此類服務器的個數(shù)即可。而且，在增加個數(shù)時，可以使用之前制作好的鏡像，創(chuàng)建多臺相同環(huán)境的ECS服務器。每臺ECS的web環(huán)境為nginx1.10和php7，微服務容器環(huán)境用的docker。

負載均衡

負載均衡可以采用兩種方式
1.購買阿里云的負載均衡實例(注意要買帶公網(wǎng)ip的)。由該負載均衡實例接收請求后，會分發(fā)到內(nèi)部服務器。
2.在某臺具有外網(wǎng)ip的ECS上使用nginx部署負載均衡服務。

個人更傾向第一種，畢竟管理起來比較方便，節(jié)省人力。

使用到的第三方服務

Coding

后端的所有代碼都是放在Coding上的，喜歡Coding的原因有三個。
1.私有git倉庫沒有個數(shù)限制。
2.有ios客戶端且比較好用。
3.操作界面好看。

后端代碼的自動部署是通過Coding的webhook實現(xiàn)的
具體操作可以去看這篇博客《利用Coding的webhook自動部署項目》。

實現(xiàn)的場景：代碼的自動部署與持續(xù)集成。
當我提交代碼到開發(fā)分支上時，測試服務器上會自動更新開發(fā)分支上的代碼。
當我把開發(fā)代碼合并到主分支上時，正式服務器會自動拉取master分支上的代碼，可謂是方便快捷。
jenkins 之類的工具雖然也嘗試過，但是感覺部署起來很不方便，不夠定制化，而且還消耗了一部分服務器資源。

后端邏輯層架構

接口

項目起初的接口是基于phalapi框架開發(fā)，現(xiàn)在逐步過渡到基于laravel5.3開發(fā)。
項目起初選擇phalapi的原因

1.phalapi框架是輕量級的接口發(fā)框架，開發(fā)起來比較便捷、快速，尤其是那個依賴注入挺好用的。

2.phalapi框架有很多現(xiàn)成的擴展可以使用，不用去找，而且這些也能基本滿足業(yè)務的需要。我個人還基于這個框架開發(fā)了兩個擴展，一個是關于使用workman的，一個是關于使用gearman的。

其中gearman是用來異步處理請求的，詳細介紹可以看這篇博客《基于Phalapi框架的gearman擴展(異步并發(fā))》
根據(jù)業(yè)務量提高性能

http請求的并發(fā)性能可以通過增加ECS實現(xiàn)，針對部分耗時較長且無須即時回調的請求，可以用gearman異步處理。
數(shù)據(jù)庫的并發(fā)連接數(shù)可以通過增加配置來提高，也可以通過創(chuàng)建只讀實例進行讀寫分離，提高數(shù)據(jù)處理能力。再往后，可能需要搭建hadoop管理數(shù)據(jù)庫集群，不過等用上hadoop的時候，應該已經(jīng)不是項目初期了，至少數(shù)據(jù)量得是TB級的了。
其它還可以采用優(yōu)化nginx配置，優(yōu)化linux內(nèi)核，采用高速固態(tài)硬盤等等的手段。

總結評價

這套架構基本上可以完全滿足項目初期的業(yè)務需要，而且所有的云服務費用總和也非常少(相比于自建服務器機房)。隨著業(yè)務量的提升，可以逐步升級配置以應對需求，還可以在短時間內(nèi)臨時性的提高并發(fā)處理能力?？偨Y起來就是省錢、省時、省力氣。

4.集群式部署國際化架構

隨著業(yè)務的擴展，最近我們的項目需要發(fā)布到海外市場，原有的服務器架構已經(jīng)不能滿足市場的需求。由于之前并未接觸如此大的項目，對海外市場服務器的部署非常不了解，在跟阿里云架構師溝通的基礎上，我們得出兩種解決方案：

方案一：
阿里云有一款叫全球加速的產(chǎn)品，該產(chǎn)品不用購買和部署海外服務器，只需購買全球加速服務，阿里云接入其自建的全球骨干網(wǎng)絡，據(jù)說可實現(xiàn)海外訪問100ms的延時。不過此種方式，成本較高，我們選擇了放棄，其結構如下圖：

全球加速.png

方案二：

第二種方案就是在海外部署服務器，其結構如下圖：

集群式服務器結構.png

在上一種架構的基礎上，在所需要的點購買ECS服務器，海外節(jié)點通過香港入口訪問國內(nèi)的RDS和Redis。同時在海外對應的節(jié)點部署CDN，用于訪問OSS服務器時的加速，海外用戶訪問對應節(jié)點的CDN，CDN通過香港入口訪問OSS服務器，并將所訪問的對象文件緩存到對應的節(jié)點，當用戶下次再次訪問該對象時，直接從對應的CDN節(jié)點緩存中獲取，以此方式提高訪問速度。