【1.綜述工程開發】

時間  2019-11-05
標籤 1.綜述工程開發 简体版
原文   原文鏈接

更不知道起什麼名字。我想概括下一個通用系統（不考慮功能差別）的設計目標和對應實現方法，若是本人公司涉及到的會詳細講一下，也供架構設計搭建參考。本篇是個總體，其中涉及內容會分篇php

目標：
    ——高性能
    ——高可用
    ——可擴展
    ——成本=》效率（運維，研發效率，測試效率，物理成本與其餘分不開暫不考慮）
    ——安全

一個系統設計什麼樣子徹底由目標決定，能夠從原來的單機應用服務器擴展到分佈式服務（包含CDN服務器集羣，反向代理服務器集羣,分佈式微服務集羣，通用數據代理集羣，分佈式緩存集羣，分佈式文件服務器，分佈式數據庫服務器等）
舉個例子一個簡單的通用系統邏輯架構以下：
clipboard.pngreact

高性能

單機高性能

多進程，單進程多線程
每一個獨立線程處理請求模式：異步、同步(actor,reactor,preactor)
每一個獨立線程處理網絡IO模式：阻塞、非阻塞、非阻塞多路複用（select,poll,epoll）
底層IO:同步、異步（NIO）
數據共享：加鎖/通訊傳遞actor
見：https://segmentfault.com/a/11...nginx

集羣高性能：

1.緩存
本地數據緩存：在存儲中講，略
分佈式數據緩存：在存儲中講，略
CDN：見https://segmentfault.com/a/11...
2.擴展服務器，任務分配器（負載均衡）
須要關注分配器選型（硬件F5，軟件LVS，nginx）、分配器與服務器之間鏈接管理，創建，檢測，中斷後處理、分配算法
負載均衡總體上方案
1）可負載均衡位置和方案算法

2）負載均衡算法spring

  • HASH
    源地址hash
    目標地址hash
    session id hash,用戶id hash 適用於臨時保存的場景
  • 輪詢
    平分
    加權輪詢
    負載最低優先（好比CPU負載，鏈接數，IO使用，網卡等，LVS能夠以鏈接數來判斷，其餘由於收集負載耗資源，應用場景沒有輪詢多）
    性能最優類（響應時間，收集，採樣，統計週期）

3.任務拆分
簡單的系統更容易作到高性能，同時提升擴展性，在擴展性中說
3.通訊
公司入網部署 見：https://segmentfault.com/a/11...
長鏈接 見：https://segmentfault.com/a/11...
網絡協議 如下見：https://segmentfault.com/a/11...數據庫

  • 網絡基礎
  • tcp
  • http
  • thrift

高可用（穩定性建設）

多數穩定性建設是故障前建設。故障中減低影響，故障後補償segmentfault

最小系統/核心數據發現

服務冗餘/數據冗餘

1.部署，能夠1主多備或多主多備。
主備（單活）：冷備（主從），溫被（業務系統一直啓動，但不對外提供服務）
集羣（多活）：對稱集羣（負載均衡），非對稱集羣，任務分配器
2.任務分配器
分配算法更復雜，須要有角色狀態能力，若多主還須要考慮儘可能同一用戶落入單機房，固然也能夠簡單的人工切換。
高可用狀態決策緩存

1.一個決策者，多個上報者
2.2個機器協商，注意腦裂檢測
3.民主決策，=》腦裂 當集羣鏈接中斷，解決辦法投票節點數必須超過系統總節點一半，當可用少於一半時系統不可用

任務管理：某臺服務器失敗，是否要以及如何從新分配到新的服務器執行
3.異地多活（活不是備）安全

  • 異地
    同城異區，解決機房級別故障，能夠經過搭建高速網絡，和同一個機房同樣設計(0.5ms/0.07ms)
    跨城異地，網絡抖動時，延時會很高，數據不一致，支付寶等金融系統對餘額這類數據不會作跨城異地，應對極端災難場景
    跨國多活：不一樣地區不能相互訪問，或幾秒以上延時無感知的只讀服務
  • 原則
    保證核心業務的異地多活，保證核心業務數據最終一致性
    減小異地多活機房的距離，搭建高速網絡
    只保證絕大部分用戶的異地多活。掛公告，過後補償等
  • 挑選核心業務：訪問量大的，核心功能，產生大量收入業務
  • 數據
    帶存儲異地多活比較難，見：https://segmentfault.com/a/11...。全局惟一ID，該生成ID方案也要異地多活，idc生成個方案：https://segmentfault.com/a/11...
    分類：數據量，惟一性，實時性，可丟失性，可恢復性。根據不一樣數據設計不一樣同步方案，避免少許數據異常致使總體業務不可用
    採起多種手段同步數據，除了存儲系統等自帶的同步功能，消息隊列方式，二次讀取，回源讀取，從新生成數據等

鏈路

  • 多通道同步
    數據同步+接口訪問（用兩種不一樣的網絡鏈接，一個公網一個內網，優先同步+本地，不行就走接口，多機房須要路由規則記錄數據來源，訪問來源機器）

接口級故障，保證核心業務和絕大部分用戶（bug等內存耗盡等，第三方系統大量請求或響應慢，攻擊，促銷等）服務器

  • 降級，降級系統，降級點識別（批量操做等）
  • 熔斷：當a依賴B，B響應慢，A再也不請求B。調用層統一採樣+統計，設置閾值，見微服務
  • 限流，基於請求限流，基於資源限流，nginx講了限流的詳細作法
    固定數量1）1s內限制死數量24位時間戳+8位數量，取當前s若是同樣+後8位，若是不同初始時間戳+0
    2）流入速率和流出速率 當前剩餘令牌=上次剩餘令牌+1-rate*時差{本該消耗的令牌}>0/超出限制
    3）自適應的 固定數量=maxqps{最近採樣極大qps}（2minlat{0負載延時}-avglat{當前延時}）。（原本延時-超出部分）qps。0負載延時最近小值的平均，逐步減小maxqps獲取。
  • 排隊，kafka等消息隊列。排隊模塊，調度模塊，服務模塊

故障後

  • 日誌記錄（服務器上，本地獨立系統存儲，日誌異地保存）
  • 用戶補償

存儲高可用

存儲的東西涉及較多，獨立見https://segmentfault.com/a/11...

可擴展

常見拆分方案：
1.面向流程（UI,業務，數據，存儲）
分層架構 保證各層之間的差別足夠清晰，邊界明顯，本質就是隔離關注點，要保證層與層之間的依賴是穩定的，B/S,C/S MVC(邏輯都在M,C只是轉發)/MVP(邏輯在P，M是數據)，邏輯分層（自頂向下依賴好比端=》框架=》庫=》內核），建議層層不能被跨越，兩兩依賴，不然時間久會亂好比sdk和common。缺點是冗餘和每次都要通過全部層
2.面向服務

  • SOA 服務+系統總線（比較重，負責服務定義、服務路由、消息轉換、消息傳遞，）+服務鬆耦合
  • 微服務
    須要快速交付，輕量級，服務粒度細。small,lightweight,automated相好比SOA的系統總線，微服務推薦使用統一的協議和格式，例如，RESTful協議、RPC協議，服務作的比較多總線輕量。更小。
    服務劃分太細，服務間關係複雜；數量太多，團隊效率降低，平均3人一個；調用鏈路長，性能降低；調用鏈路長，問題定位論難；必定要有自動化的測試，部署，監控保障；服務路由，故障隔離，註冊和發現等服務治理。
    基於業務邏輯拆分。穩定和變化拆分，穩定服務力度能夠粗一些。核心和非核心拆分，只對核心業務作高可用等。基於性能拆分，瓶頸單獨部署。
    詳見：https://segmentfault.com/a/11...

3.面向功能：微內核（插件化架構）
clipboard.png
插件管理，註冊，加載時機。插件鏈接（OSGI，消息模式，依賴注入spring，分佈式協議rpc等）。插件通訊（核心模塊實現）
好比OSGI，Eclipse的Equinox。service層(bundle註冊)，lifecycle(管理bundle的安裝更新啓動中止卸載),bundle
規則引擎架構（開源drools），

效率

安全

todo

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程