----基於阿里雲搭建的適合初創企業的輕量級架構
前言
在項目的初期往往存在很多變數，業務邏輯時刻在變，而且還要保證快速及時，所以，一個靈活多變、快速部署、持續集成並可以適應多種情況的架構便顯得尤爲重要。本文主要介紹基於阿里雲搭建適合項目初期的後端架構，至於細節操作不作描述，比如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 之類的工具雖然也嘗試過，但是感覺部署起來很不方便，不夠定製化，而且還消耗了一部分服務器資源。端邏輯層架構
項目起初的接口是基於phalapi框架開發，之後逐步過渡到基於laravel5.3開發，感覺還是不夠靈活，與項目屬性有些不符，後來又轉到thinkphp5框架，但在使用中發現了一些問題，雖然提交了pr，但是響應速度無法達到公司項目的迭代速度，於是就重寫的框架核心，並開發了一個支持多應用後端場景的後端開源項目。框架核心保留大部分thinkphp5優秀特性的同時，又加入一些thinkphp5本身沒有的元素，且修改了很多代碼問題。
項目主要集成了以下服務
workman ： 實現長連接場景
gearman ： 實現異步處理，及CGI到CLI模式切換
rabbitMq ：實現消息隊列場景，解耦生產者與消費者
還有其它服務的SDK重製版，如aliyun-sdk，Umeng、RongIM等
以及一些項目中常用的工具如何根據業務量提高性能
- http請求的併發性能可以通過增加ECS實現，針對部分耗時較長且無須即時回調的請求，可以用gearman異步處理。
- 數據庫的併發連接數可以通過增加配置來提高，也可以通過創建只讀實例進行讀寫分離，提高數據處理能力。再往後，可能需要搭建hadoop管理數據庫集羣，不過等用上hadoop的時候，應該已經不是項目初期了，至少數據量得是TB級的了。
- 其它還可以採用優化nginx配置，優化linux內核，採用高速固態硬盤等等的手段。
總結評價
這套架構基本上可以完全滿足項目初期的業務需要，而且所有的雲服務費用總和也非常少(相比於自建服務器機房)。隨着業務量的提升，可以逐步升級配置或者平行擴展以應對需求，可以在短時間內臨時性的提高併發處理能力。總結起來就是省錢、省時、省力氣。
原文鏈接
本文爲雲棲社區原創內容，未經允許不得轉載。