用CI作網站架構的一點心得

項目簡述

日PV數萬，針對海外，跨五個大洲，南美，北美，歐洲，非洲，東南亞。

服務器環境

windows服務器數個分屬不一樣大洲

數據庫：mysql

開發框架：CodeIgnite 即CI框架

開發語言：PHP

架構前的幾點思考

1.擴展性

作架構必定要考慮擴展性。在項目開發中，項目需求變更是時有發生的事情，世界上沒有完美的框架，修修補補是很正常的事情，並且往後隨着業務的發展需求有所增長也是很正常的事情，因此一個好的架構必定要在最開始就考慮可擴展性。

2.安全性

作架構的時候必定要考慮安全性，由於別有用心的人老是大有人在，若是咱們不考慮安全性，往後咱們就有得忙了。

3.運行效率

程序運行效率也是十分重要的問題，試想咱們平時瀏覽網頁的習慣，若是一個頁面要加載好幾秒甚至十秒以上，咱們的心情如何？相反，若是瀏覽的每一個頁面都幾乎是秒開，咱們的心情也會變得舒暢不少。因此，運行效率是咱們作架構時必須考慮的一個重要問題。

4.開發效率

作項目固然是在保證質量的前提下，越快越好，那麼咱們如何提升團隊的開發效率呢？團隊使用一直的開發環境，有效的代碼管理工具如GIT等等基礎問題必定要事先肯定好。除了這些基礎任務外，我想一個清晰的目錄結構也十分重要，好的目錄結構不只查找資源迅速並且方便定位錯誤位置等等不少好處。

5.程序可靠性

以上是我在作架構過程當中想到的幾點，固然還有不少不足，在往後的工做學習中，還會不斷補充。

下面看看個人目錄結構

總目錄
common--------------CI公共擴展
public------------------外部訪問目錄
site---------------------應用程序目錄
system----------------CI核心類目錄

common目錄結構
core-------------------CI自定義公共核心類擴展目錄
helpers---------------CI自定義公共幫助類擴展目錄
libraries--------------CI自定義公共擴展類目錄

試想一下咱們一個域名下面掛在了好幾個差距較大的功能模塊，爲了方便擴展，咱們須要解耦，提升代碼複用性。
熟悉CI的朋友應該知道CI能夠在application中的core、helpers、libraries目錄裏面自定義擴展，CI的這個功能在必定程度上知足了咱們的需求。
可是咱們每個功能模塊就是一個application，如今有一個common_helper.php 裏面定義了一些公共函數，
若是咱們只沿用CI框架的自定義擴展，那麼我須要在每個模塊的application中添加一個
common_helper.php，這顯然大大增長了代碼的維護成本。
這時若是咱們將一些每一個模塊都能用的擴展提取出來放到一個公共目錄，是否是大大提升代碼的複用性呢？！

public目錄結構
asset------------------公共資源目錄
admin-----------------後臺入口文件目錄
index.php------------前臺入口文件

將入口文件從應用中提取出來能夠有效限制用戶對服務器文件的訪問，使之僅能訪問資源文件，
這樣能夠在必定程度上下降服務器文件被修改的風險。

site目錄結構
admin-----------------後臺應用目錄
front-------------------前臺應用目錄

將應用文件按模塊分開，這樣能夠有效解耦，不一樣模塊之間代碼互不影響。
好比後臺代碼出錯，前臺訪問不受影響。

system系統結構目錄與CI系統一致

說完目錄，簡單談談，我對前面提到的幾點思考所提出的解決方案。

對於安全性，除了控制訪問目錄以外，還要對用戶輸入數據作XSS過濾，對於API接口類要作祕鑰認證

對於運行效率，首先要考慮靜態資源加速，可用第三方工具。

其次，要考慮頁面及查詢接口緩存，咱們選用redis而且數據庫進行讀寫分離

還有對於耗時操做好比發郵件，最好使用api調用腳本異步發送。

對於可靠性，好比發郵件丟失，咱們可使用消息隊列機制，監控發送狀態，屢次發送等等。 session共享採用存儲數據庫方式。