如何基於阿里雲搭建適合初創企業的輕量級架構？

前言

在項目的初期每每存在不少變數，業務邏輯時刻在變，並且還要保證快速及時，因此，一個靈活多變、快速部署、持續集成並能夠適應多種狀況的架構便顯得尤其重要。本文主要介紹基於阿里雲搭建適合項目初期的後端架構，至於細節操做不做描述，好比nginx配置優化、linux內核優化、防火牆配置、ansible的使用等。

項目背景

項目的組成: 兩個IOS客戶端，一個微信端，一個管理系統，智能硬件。

項目初期的運維架構

整體架構

項目後端架構使用阿里雲服務搭建，其中RDS爲主從集羣，並配備災備實例。ECS可根據業務量動態彈性伸縮，其他服務均採用單實例的方式遠程調用。

VPC

搭建VPC的緣由有如下幾點:

1. 能夠將業務數據庫和業務服務器放置在能夠本身掌握的同一內網，能夠提升一些安全性。
2. 內網訪問，穩定並且速度快。
3. 阿里雲服務之間經過內網訪問的流量是不收費的。因此在選購服務時，帶寬能夠選擇流量版，這樣在保證帶寬速率的同時，還能夠極大的減小運維費用。
   舉個例子：一樣一臺ECS，在同爲百兆帶寬的狀況下，每個月的費用以下圖：

固然，能這樣的作的緣由也是由於在這個架構中，ECS僅處理業務邏輯，幾乎不存儲文件資源。大部分靜態資源，如視頻圖片等，都是存儲在OSS上。若是存放靜態資源，好比下視頻或圖片什麼的，流量一多那就很虧了。

業務數據層

• RDS

項目一開始，RDS選購的是共享型單實例的，隨着業務量的提高，能夠多區域部署只讀實例。另外，保險起見，主實例能夠配有一個災備實例，防止意外發生。

• Redis

阿里雲的這個Redis，一開始我用的時候比較早，那個時候還不支持主從的，只能單實例，因此主要用它作數據緩存，響應速度很是快。並且，由於是放置在內網的且只能內網訪問，因此安全性也很高。

目前阿里雲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自動部署項目》。使用其它代碼託管平臺也有基於git的webhook功能，操做方式大體相同。

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

• 容聯·雲通信
  主要用來實現短信通知、驗證碼等功能
• 融雲IM
  主要用來實現ios客戶端之間的即時通信以及客戶端的應用消息推送。

後端邏輯層架構

項目起初的接口是基於phalapi框架開發，以後逐步過渡到基於laravel5.3開發，感受仍是不夠靈活，與項目屬性有些不符，後來又轉到thinkphp5框架，但在使用中發現了一些問題，雖然提交了pr，可是響應速度沒法達到公司項目的迭代速度，因而就重寫的框架核心，並開發了一個支持多應用後端場景的後端開源項目。框架核心保留大部分thinkphp5優秀特性的同時，又加入一些thinkphp5自己沒有的元素，且修改了不少代碼問題。

github: github.com/AxiosCros/t…

項目主要集成了如下服務
 workman ： 實現長鏈接場景
 gearman ： 實現異步處理，及CGI到CLI模式切換
 rabbitMq ：實現消息隊列場景，解耦生產者與消費者

 還有其它服務的SDK重製版，如aliyun-sdk，Umeng、RongIM等
 以及一些項目中經常使用的工具複製代碼

如何根據業務量提升性能

• http請求的併發性能能夠經過增長ECS實現，針對部分耗時較長且無須即時回調的請求，能夠用gearman異步處理。
• 數據庫的併發鏈接數能夠經過增長配置來提升，也能夠經過建立只讀實例進行讀寫分離，提升數據處理能力。再日後，可能須要搭建hadoop管理數據庫集羣，不過等用上hadoop的時候，應該已經不是項目初期了，至少數據量得是TB級的了。
• 其它還能夠採用優化nginx配置，優化linux內核，採用高速固態硬盤等等的手段。

總結評價

這套架構基本上能夠徹底知足項目初期的業務須要，並且全部的雲服務費用總和也很是少(相比於自建服務器機房)。隨着業務量的提高，能夠逐步升級配置或者平行擴展以應對需求，能夠在短期內臨時性的提升併發處理能力。總結起來就是省錢、省時、省力氣。