作爲一個移動端開發人員來講，是很難接觸到後端項目架構的，所幸，從2015年開始，負責部分管理工作，參與了項目架構相關的工作。項目從小到大，架構也越來越複雜，特別是最近做的一個跨國型項目，涉及到國內國外服務器的部署，尤爲複雜。本文結合這些項目實踐，介紹基於阿里雲的後端架構設計。（部分內容爲引用他人的文章，文中已有說明，咱是尊重版權的）
1.基礎架構：
2015年初，團隊做了一個美食項目，業務邏輯比較簡單，主要是實現用戶、餐館、美食三元素的增刪改查及三者之間的關聯查詢。後端程序採用的是php，前端面對的是iOS和Android兩款App。當時購買了一臺阿里雲ECS服務器，在該服務器上安裝了MySQL以用於數據存儲。應用程序、數據庫、文件等所有資源都在一臺服務器上，網站架構如下圖所示：
此架構簡單，適用於項目初期，訪問量比較小情況。這裏着重要說一下的是，此項目中涉及到資源文件的存儲但並沒有用到OSS服務器，我們的做法是在客戶端在上傳圖片文件的時候，接口程序會將圖片壓縮爲所需的多種尺寸，並保存在對應的文件夾下，前端再取圖片的時候在URL後拼接對於的尺寸即可訪問。如客戶端上傳了一張圖片，程序會壓縮爲3030，120120，240*240三種尺寸，客戶端根據界面需要採用xxxxx_30.png的方式訪問，這個功能在阿里雲的OSS服務器上有現成的服務，無需自己壓縮。
2.應用與數據分離架構：
2015年底，團隊開始做了一個圖片社交項目，其功能是全部模仿Instagram，但是內容主要針對的是服裝、奢侈品。用戶通過手機拍攝一些奢侈品、服裝相關的視頻、圖片，並添加對應的下載鏈接，發佈到平臺後，用戶可以看到其他所有人發佈的內容，並可以根據鏈接購買。
這個項目中涉及到大量視頻、圖片的處理，這裏我們實現了應用服務、數據服務、資源服務的分離。我們購買了四臺阿里雲服務器，分別是兩臺ECS、一臺OSS、一臺RDS，其結構如下圖：
3.集羣式部署初級架構
2016年我們開始做一個大型的在線教育平臺項目，經歷一年的磨合，項目趨於穩定，我們的服務器架構也日臻完善。本想總結一下服務器的架構，在下筆之前在網上看到了他人總結的一篇文章，項目架構設計總結，再此先向作者表示敬意，以下是引用的這篇文章的部分內容：
項目背景
項目的前端主要爲ios應用以及一些web管理系統，後端的職能主要爲前端提供數據接口。我個人在項目中主要負責整個後端的架構設計、服務器運維、php開發等一系列後端工作，因爲主要是我一個人負責，在一定程度上也減少了許多溝通成本。
總體架構
項目後端架構使用阿里雲服務搭建，其中RDS爲主從集羣，並配備災備實例。ECS可根據業務量動態彈性伸縮，其餘服務均採用單實例的方式遠程調用。
2104726472.png
VPC
搭建VPC的原因有以下幾點
1.可以將業務數據庫和業務服務器放置在可以自己掌握的同一內網，可以提高一些安全性。
2.阿里雲服務之間通過內網訪問的流量是不收費的。所以在選購服務時，帶寬可以選擇流量版，這樣在保證帶寬速率的同時，還可以極大的減少運維費用。
舉個例子：同樣一臺ECS，在同爲百兆帶寬的情況下，每月的費用如下圖：按固定帶寬
[圖片上傳中...(4282504957.png-8d5eea-1513671576852-0)]
按使用流量
4282504957.png
當然，能這樣的做的原因也是因爲在這個架構中，ECS僅處理業務邏輯，幾乎不存儲文件資源。大部分靜態資源，如視頻圖片等，都是存儲在OSS上。如果存放靜態資源，比如下視頻或圖片什麼的，流量一多那就很虧了。
3.內網訪問，穩定而且速度快。業務數據層
RDS
項目一開始，RDS選購的是共享型單實例的，隨着業務量的提升，可以多區域部署只讀實例。另外，保險起見，主實例可以配有一個災備實例，防止意外發生。
Redis
提到阿里雲的這個Redis，不得不吐槽一句，它竟然是不支持主從的，只能單實例，不過，用它做數據緩存，還真是蠻不錯的選擇，響應速度非常快。而且，因爲是放置在內網的且只能內網訪問，所以安全性也很高。
MongoDB
結構型數據，主要存儲檔案式的數據，比如每個用戶的操作行爲，以檔案式記錄並進行統計分析，方便下一階段的項目做個性化服務。另外一些關聯複雜的數據，也可以用MongoDb存儲，可以提高訪問速度。還有，一些對軟件應用版本比較敏感的數據也可以存在MongoDB中，比如a版本拿到A數據，b版本拿到B數據，而這個AB數據都是由很多關聯關係複雜的數據所組成，如果把這些數據根據版本號存儲在不同的MongoDB檔案中，需要時，直接根據版本號拿就可以了，這樣就避免了很多的mysql查詢。
靜態資源
OSS + CDN
OSS存儲靜態資源，CDN(內容分發網絡)可以加速靜態資源的下載速度。至於資源鏈接地址，客戶端可以通過接口訪問從後端業務數據庫中拿到。
服務器安全運維層面
1.選購了阿里雲的web防火牆和態勢感知的服務。這兩個服務可以實時監控服務器狀態，識別並跟蹤攻擊來源和類型，可以說，用這兩個工具也節省了很多人力成本。阿里雲還有其它安全類產品，可以根據項目選購，使用起來也都很方便。
2.配置firewalld。業務層面
針對接口訪問的安全性，主要做了以下工作
1.簽名驗證：防止僞造請求
2.訪問頻次限制：計數器是用phpredis製作的毫秒級計數器
3.https訪問
4.部分敏感數據，使用RSA非對稱加密服務器集羣
主ECS
通過這臺ECS，可以管理其它從屬的ECS，並查看狀態。安裝的主要工具爲ansible。
如果不需要用這臺ECS來做負載均衡的話，可以配置白名單連接，只允許管理員ip才能訪問。從屬ECS
這類ECS服務器只存放邏輯代碼，所以當需求量增加時，只需增加此類服務器的個數即可。而且，在增加個數時，可以使用之前製作好的鏡像，創建多臺相同環境的ECS服務器。每臺ECS的web環境爲nginx1.10和php7，微服務容器環境用的docker。
負載均衡
負載均衡可以採用兩種方式
1.購買阿里雲的負載均衡實例(注意要買帶公網ip的)。由該負載均衡實例接收請求後，會分發到內部服務器。
2.在某臺具有外網ip的ECS上使用nginx部署負載均衡服務。個人更傾向第一種，畢竟管理起來比較方便，節省人力。
使用到的第三方服務
Coding
後端的所有代碼都是放在Coding上的，喜歡Coding的原因有三個。
1.私有git倉庫沒有個數限制。
2.有ios客戶端且比較好用。
3.操作界面好看。後端代碼的自動部署是通過Coding的webhook實現的
具體操作可以去看這篇博客《利用Coding的webhook自動部署項目》。實現的場景：代碼的自動部署與持續集成。
當我提交代碼到開發分支上時，測試服務器上會自動更新開發分支上的代碼。
當我把開發代碼合併到主分支上時，正式服務器會自動拉取master分支上的代碼，可謂是方便快捷。
jenkins 之類的工具雖然也嘗試過，但是感覺部署起來很不方便，不夠定製化，而且還消耗了一部分服務器資源。後端邏輯層架構
接口
項目起初的接口是基於phalapi框架開發，現在逐步過渡到基於laravel5.3開發。
項目起初選擇phalapi的原因1.phalapi框架是輕量級的接口發框架，開發起來比較便捷、快速，尤其是那個依賴注入挺好用的。
2.phalapi框架有很多現成的擴展可以使用，不用去找，而且這些也能基本滿足業務的需要。我個人還基於這個框架開發了兩個擴展，一個是關於使用workman的，一個是關於使用gearman的。
其中gearman是用來異步處理請求的，詳細介紹可以看這篇博客《基於Phalapi框架的gearman擴展(異步併發)》
根據業務量提高性能http請求的併發性能可以通過增加ECS實現，針對部分耗時較長且無須即時回調的請求，可以用gearman異步處理。
數據庫的併發連接數可以通過增加配置來提高，也可以通過創建只讀實例進行讀寫分離，提高數據處理能力。再往後，可能需要搭建hadoop管理數據庫集羣，不過等用上hadoop的時候，應該已經不是項目初期了，至少數據量得是TB級的了。
其它還可以採用優化nginx配置，優化linux內核，採用高速固態硬盤等等的手段。總結評價
這套架構基本上可以完全滿足項目初期的業務需要，而且所有的雲服務費用總和也非常少(相比於自建服務器機房)。隨着業務量的提升，可以逐步升級配置以應對需求，還可以在短時間內臨時性的提高併發處理能力。總結起來就是省錢、省時、省力氣。
4.集羣式部署國際化架構
隨着業務的擴展，最近我們的項目需要發佈到海外市場，原有的服務器架構已經不能滿足市場的需求。由於之前並未接觸如此大的項目，對海外市場服務器的部署非常不瞭解，在跟阿里雲架構師溝通的基礎上，我們得出兩種解決方案：
方案一：
阿里雲有一款叫全球加速的產品，該產品不用購買和部署海外服務器，只需購買全球加速服務，阿里雲接入其自建的全球骨幹網絡，據說可實現海外訪問100ms的延時。不過此種方式，成本較高，我們選擇了放棄，其結構如下圖：
方案二：
第二種方案就是在海外部署服務器，其結構如下圖：
在上一種架構的基礎上，在所需要的點購買ECS服務器，海外節點通過香港入口訪問國內的RDS和Redis。同時在海外對應的節點部署CDN，用於訪問OSS服務器時的加速，海外用戶訪問對應節點的CDN，CDN通過香港入口訪問OSS服務器，並將所訪問的對象文件緩存到對應的節點，當用戶下次再次訪問該對象時，直接從對應的CDN節點緩存中獲取，以此方式提高訪問速度。