架構設計(1)-談談架構

一、什麼是架構和架構本質  前端

    無架構,不繫統,架構是大型系統的關鍵。從形上看,架構是系統的骨架,支撐和連接各個部分;從神上看,架構是系統的靈魂,深入體現業務本質。node

     這相似建築設計規劃,城市整體規劃等,其實就是架構,只是應用的場景不一樣。web

     架構的本質就是符合當前業務的發展並能夠快速擴展。sql

 

二、架構分類數據庫

 

     架構可細分爲業務架構、應用架構、技術架構。編程

      業務架構是戰略,應用架構是戰術,技術架構是裝備。其中應用架構承上啓下,一方面承接業務架構的落地,另外一方面影響技術選型。緩存

      熟悉業務,造成業務架構,根據業務架構,作出相應的應用架構,最後技術架構落地實施。安全

      如何針對當前需求,選擇合適的應用架構,如何面向將來,保證架構平滑過渡,這個是軟件開發者,特別是架構師,都須要深刻思考的問題。服務器

業務架構(俯視架構):

      包括業務規劃,業務模塊、業務流程,對整個系統的業務進行拆分,對領域模型進行設計,把現實的業務轉化成抽象對象架構

應用架構(剖面架構):

硬件到應用的抽象,包括抽象層和編程接口。應用架構和業務架構是相輔相成的關係。業務架構的沒一部分都有應用架構。

應用架構本質:

     應用做爲獨立可部署的單元,爲系統劃分了明確的邊界,深入影響系統功能組織、代碼開發、部署和運維等各方面,應用架構定義系統有哪些應用、以及應用之間如何分工和合做。

    分有兩種方式,一種是水平分,按照功能處理順序劃分應用,好比把系統分爲web前端/中間服務/後臺任務,這是面向業務深度的劃分。另外一種是垂直分,按照不一樣的業務類型劃分應用,好比進銷存系統能夠劃分爲三個獨立的應用,這是面向業務廣度的劃分。

     應用的合反映應用之間如何協做,共同完成複雜的業務case,主要體如今應用之間的通信機制和數據格式,通信機制能夠是同步調用/異步消息/共享DB訪問等,數據格式能夠是文本/XML/JSON/二進制等。

     應用的分偏向於業務,反映業務架構,應用的合偏向於技術,影響技術架構。分下降了業務複雜度,系統更有序,合增長了技術複雜度,系統更無序。

     應用架構的本質是經過系統拆分,平衡業務和技術複雜性,保證系統形散神不散。

     系統採用什麼樣的應用架構,受業務複雜性影響,包括企業發展階段和業務特色;同時受技術複雜性影響,包括IT技術發展階段和內部技術人員水平。業務複雜性(包括業務量大)必然帶來技術複雜性,應用架構目標是解決業務複雜性的同時,避免技術太複雜,確保業務架構落地。

 

技術架構:

    拓撲架構,包括架構部署了幾個節點,節點之間的關係,服務器的高可用,網路接口和協議等,決定了應用如何運行,運行的性能,可維護性,可擴展性,是全部架構的基礎。

    

 

 

三、應用架構演進

    架構演進路程:

   ->初始階段:LAMP,部署在一臺服務器

   ->應用服務器和數據服務器分離

   ->使用緩存改善性能

   ->使用集羣改善併發

   ->數據庫地讀寫分離

   ->使用反向代理和cdn加速

   ->使用分佈式文件和分佈式數據庫

   ->業務拆分

   ->分佈式服務

    

 

     業務架構是生產力,應用架構是生產關係,技術架構是生產工具。業務架構決定應用架構,應用架構須要適配業務架構,並隨着業務架構不斷進化,同時應用架構依託技術架構最終落地。

      企業一開始業務比較簡單,好比進銷存,此時面向內部用戶,提供簡單的信息管理系統(MIS),支持數據增刪改查便可,單體應用能夠知足要求。

      隨着業務深刻,進銷存每塊業務都變複雜,同時新增客戶關係管理,以更好支持營銷,業務的深度和廣度都增長,這時須要對系統按照業務拆分,變成一個分佈式系統。

     更進一步,企業轉向互聯網+戰略,拓展在線交易,線上系統和內部系統業務相似,不必重作一套,此時把內部系統的邏輯作服務化改造,同時供線上線下系統使用,變成一個簡單的SOA架構。

      緊接着業務模式愈來愈複雜,訂單、商品、庫存、價格每塊玩法都很深刻,好比價格區分會員等級,訪問渠道(無線仍是PC),銷售方式(團購仍是普通)等,還有大量的價格促銷,這些規則很複雜,容易相互衝突,須要把分散到各個業務的價格邏輯進行統一管理,以基礎價格服務的方式透明地提供給上層應用,變成一個微內核的SOA架構。

      同時不論是企業內部用戶,仍是外部顧客所須要的功能,都由不少細分的應用提供支持,須要提供portal,集成相關應用,爲不一樣用戶提供統一視圖,頂層變成一個AOA的架構(application orientated architecture)。

 

四、架構知識體系

 

 

  • 架構演進
    • 初始階段:LAMP,部署在一臺服務器
    • 應用服務器和數據服務器分離
    • 使用緩存改善性能
    • 使用集羣改善併發
    • 數據庫地讀寫分離
    • 使用反向代理和cdn加速
    • 使用分佈式文件和分佈式數據庫
    • 業務拆分
    • 分佈式服務
  • 架構模式
    • 分層:橫向分層:應用層,服務層,數據層
    • 分割:縱向分割:拆分功能和服務
    • 分佈式
      • 分佈式應用和服務
      • 分佈式靜態資源
      • 分佈式數據和存儲
      • 分佈式計算
    • 集羣:提升併發和可用性
    • 緩存:優化系統性能
      • cdn
      • 方向代理訪問資源
      • 本地緩存
      • 分佈式緩存
    • 異步:下降系統的耦合性 
      • 提供系統的可用性
      • 加快響應速度
    • 冗餘:冷備和熱備,保證系統的可用性
    • 自動化:發佈,測試,部署,監控,報警,失效轉移,故障恢復
    • 安全:
  • 架構核心要素
    • 高性能:網站的靈魂
      • 性能測試
      • 前端優化
      • 應用優化
      • 數據庫優化
    • 可用性:保證服務器不宕機,通常經過冗餘部署備份服務器來完成
      • 負載均衡
      • 數據備份
      • 自動發佈
      • 灰度發佈
      • 監控報警
    • 伸縮性:建集羣,是否快速應對大規模增加的流量,容易添加新的機器
      • 集羣
      • 負載均衡
      • 緩存負載均衡
    • 可擴展性:主要關注功能需求,應對業務的擴展,快速響應業務的變化。是否作法開閉原則,系統耦合依賴
      • 分佈式消息
      • 服務化
    • 安全性:網站的各類攻擊,各類漏洞是否堵住,架構是否能夠作到限流做用,防止ddos攻擊。
      • xss攻擊
      • sql注入
      • csr攻擊
      • web防火牆漏洞
      • 安全漏洞
      • ssl

 

總結參考:

《大型網站技術架構》

相關文章
相關標籤/搜索