摘要： 在專案的初期往往存在很多變數，業務邏輯時刻在變，而且還要保證快速及時，所以，一個靈活多變、快速部署、持續整合並可以適應多種情況的架構便顯得尤為重要。本文主要介紹基於阿里雲搭建適合專案初期的後端架構

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

前言
在專案的初期往往存在很多變數，業務邏輯時刻在變，而且還要保證快速及時，所以，一個靈活多變、快速部署、持續整合並可以適應多種情況的架構便顯得尤為重要。本文主要介紹基於阿里雲搭建適合專案初期的後端架構，至於細節操作不作描述，比如nginx配置優化、linux核心優化、防火牆配置、ansible的使用等。

專案背景
專案的組成: 兩個IOS客戶端，一個微信端，一個管理系統，智慧硬體。

專案初期的運維架構
總體架構
專案後端架構使用阿里雲服務搭建，其中RDS為主從叢集，並配備災備例項。ECS可根據業務量動態彈性伸縮，其餘服務均採用單例項的方式遠端呼叫。

VPC
搭建VPC的原因有以下幾點:

可以將業務資料庫和業務伺服器放置在可以自己掌握的同一內網，可以提高一些安全性。
內網訪問，穩定而且速度快。
阿里雲服務之間通過內網訪問的流量是不收費的。所以在選購服務時，頻寬可以選擇流量版，這樣在保證頻寬速率的同時，還可以極大的減少運維費用。
舉個例子：同樣一臺ECS，在同為百兆頻寬的情況下，每月的費用如下圖：

當然，能這樣的做的原因也是因為在這個架構中，ECS僅處理業務邏輯，幾乎不儲存檔案資源。大部分靜態資源，如視訊圖片等，都是儲存在OSS上。如果存放靜態資源，比如下視訊或圖片什麼的，流量一多那就很虧了。

業務資料層
RDS
專案一開始，RDS選購的是共享型單例項的，隨著業務量的提升，可以多區域部署只讀例項。另外，保險起見，主例項可以配有一個災備例項，防止意外發生。

Redis
阿里雲的這個Redis，一開始我用的時候比較早，那個時候還不支援主從的，只能單例項，所以主要用它做資料快取，響應速度非常快。而且，因為是放置在內網的且只能內網訪問，所以安全性也很高。

目前阿里雲redis已經可以支援主從叢集，使用它實現一些業務場景也是個很不錯的選擇。比如有序集合可以用來做資料權重分析後的資料排序，雜湊表可以用來儲存具有簡單對映關係的字典表，還有訊息佇列，訊息訂閱等等其它場景都可以使用redis實現，並進行持久化儲存。

MongoDB
結構型資料，主要儲存檔案式的資料，比如每個使用者的操作行為，以檔案式記錄並進行統計分析，方便下一階段的專案做個性化服務。另外一些關聯複雜的資料，也可以用MongoDb儲存，可以提高訪問速度。還有，一些對軟體應用版本比較敏感的資料也可以存在MongoDB中，比如a版本拿到A資料，b版本拿到B資料，而這個AB資料都是由很多關聯關係複雜的資料所組成，如果把這些資料根據版本號儲存在不同的MongoDB檔案中，需要時，直接根據版本號拿就可以了，這樣就避免了很多的mysql查詢。

靜態資源
OSS + CDN
OSS儲存靜態資源，CDN(內容分發網路)可以加速靜態資源的下載速度。至於資源連結地址，客戶端可以通過介面訪問從後端業務資料庫中拿到。
伺服器安全
運維層面
選購了阿里雲的web防火牆和態勢感知的服務。這兩個服務可以實時監控伺服器狀態，識別並跟蹤***來源和型別，可以說，用這兩個工具也節省了很多人力成本。
配置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: https://github.com/AxiosCros/tpr-cms

專案主要集成了以下服務
workman ： 實現長連線場景
gearman ： 實現非同步處理，及CGI到CLI模式切換
rabbitMq ：實現訊息佇列場景，解耦生產者與消費者

還有其它服務的SDK重製版，如aliyun-sdk，Umeng、RongIM等
以及一些專案中常用的工具
如何根據業務量提高效能
http請求的併發效能可以通過增加ECS實現，針對部分耗時較長且無須即時回撥的請求，可以用gearman非同步處理。
資料庫的併發連線數可以通過增加配置來提高，也可以通過建立只讀例項進行讀寫分離，提高資料處理能力。再往後，可能需要搭建hadoop管理資料庫叢集，不過等用上hadoop的時候，應該已經不是專案初期了，至少資料量得是TB級的了。
其它還可以採用優化nginx配置，優化linux核心，採用高速固態硬碟等等的手段。
總結評價
這套架構基本上可以完全滿足專案初期的業務需要，而且所有的雲服務費用總和也非常少(相比於自建伺服器機房)。隨著業務量的提升，可以逐步升級配置或者平行擴充套件以應對需求，可以在短時間內臨時性的提高併發處理能力。總結起來就是省錢、省時、省力氣。