我對Web開發的認識

前端

  • 使用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
    • 有必要的話用特定賬戶運行該應用
  • 應用日誌格式須由運維指定,既要人類可讀,又要方便代碼解析

    日誌記錄應該是非阻塞的

  • 監控應用進程佔用的系統資源
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章