前端
- 使用mvvm框架,每個視圖維護自己的數據模型,更專注於視圖模型及狀態,在框架的幫助下規範視圖與後端的交互及減輕工作量
我的選擇是avalon.js
- 解耦前後端開發
- 自有資源獨立管理,向後端開放資源使用的接口
- 拿到後端靜態資源標識後,按照約定獨立運算獲得資源URL,不需要後端參與
後端
業務入口
- 任意語言的web開發框架都可以
- 主要任務是把HTTPRequest轉換爲RequestContext
- 對RequestContext做基本的驗證,如有效性、入口權限等
- 按照HTTP接口約定,調用相應的服務並返回Response
服務
- 爬蟲服務使用Python,開發簡單、相關類庫豐富、可跨平臺部署
- 搜索服務使用Java,目前在這塊還沒有實踐經驗,看好ElasticSearch
- 圖片服務,任意帶豐富圖片處理類庫的語言都可以
- 接口約定應該允許客戶端用參數指定返回的圖片的長寬
- 接口需要直接對外公開
- 郵件服務
業務入口及服務都應該做到可容易水平擴展,甚至分佈式
數據庫
方案一
- 關係數據庫選擇postgresql
- 應對複雜查詢的能力比mysql強
- 對json數據有很好的支持,可以省掉用來保存無結構key-value數據的nosql數據庫
- 對地理數據有很好的支持
- 自帶優秀的讀scalability
- 寫scalability有postgresql-xl
- pg vs mysql
- redis做緩存
方案二
- 任意對事務支持良好、可多線程訪問的關係數據庫
- 需要考慮讀、寫scalability
- redis用作nosql,主要處理key-value數據
- redis用作緩存
高併發讀不是什麼大問題,緩存+數據庫集羣能很好的解決。難點在於用數據庫集羣應付高併發寫的同時需要保證ACID。
反向代理
毫無疑問是nginx
運維
運維也是重要的需求方
目標
- 掌握資源使用情況
- 限制應用可接觸的資源
- 資源總量能迅速擴張
- 任何操作都能回滾(time machine機制)
- 任何操作都有歷史記錄
- 任何數據和操作都可視化
策略
- 限制應用的訪問權限
- 自身所在目錄
- 以環境變量指定的目錄,如APP_LOG_HOME、APP_DATA_HOME、APP_UPLOAD_HOME
- 有必要的話用特定賬戶運行該應用
- 應用日誌格式須由運維指定,既要人類可讀,又要方便代碼解析
日誌記錄應該是非阻塞的
- 監控應用進程佔用的系統資源