系統質量治理

一、前言

架構分爲三種：

• 企業架構
• 業務架構
• 應用架構

每一層架構都在flow上一層架構，爲上一層架構提供支持，併爲下一層的架構提供指導。
舉個例子，應用架構的服務拆分，一定flow業務架構。由業務架構的職責領域，劃分子域（常說的二級域等），從而進行服務拆分。
另外，越接近底層，則越具有通用性，也越常見，掌握的難度也越低。畢竟通用，就意味着很容易進行知識傳播。
我們日常見到的技術公衆號，推送的內容大部分都是應用架構的東東。因爲這些東東纔是多數人需要掌握的，並且也是具有普適意義的。

而在應用架構中，質量治理還是非常重要的一塊兒。無論是日常工作，還是面試，亦或者是同行溝通，應用架構的質量治理都是常客。舉個例子，日常開發中，我們經常需要評估程序的性能，併爲性能優化做出努力。面試中，性能優化是常客，系統可用性也是常常被提及。同行溝通，往往都是在一起diss接手項目的性能多麼糟糕，擴展性是多麼差。囧

---

原本想好好打磨打磨，但是由於最近組織關係調整，暫時無心整理這個。所以，先放出來啦。對部分細節感興趣的小夥伴，可以私聊或者艾特我。

二、屬性

系統質量屬性，代表着架構的核心維度，各個維度的取捨體現了架構師的tradeoff能力。
系統質量屬性有很多，劃分&組織方式也有很多（如運行時&編譯時），這裏只是談一談日常較爲常見的內容。

1.性能

a.刻畫方式

• 交易業務：QPS、TPS、RT、出錯率
• 流業務：吞吐量、處理窗口、滯後時間
• 系統：CPU、內存、存儲、網絡

b.解決方案

• 思想：
  • 簡化：
    • 業務：精簡流程
    • 架構：減少不必要的服務調用與依賴、減少不必要的架構層次抽象
    • 編碼：減少代碼塊內容，如循環體、try塊等
    • 數據：減少不必要的數據處理、傳輸、存儲。如數據清洗
  • 時空轉換：緩存、索引、副本、bitMap等
  • Map_Reduce：dts的合理拆分（這涉及dts的整體設計優化，後詳）、本地fork-join框架
  • 並行：分佈式、多線程
  • 調優：Mysql調優、HashMap調優（初始容器大小）、Nginx調優等
• 架構級：
  • 緩存爲王（《緩存架構》。Mysql的cache&buffer等。可以借鑑緩存中間件-緩存架構的實現（上）與緩存中間件-緩存架構的實現（下））
  • 異步爲帥（如異步編程&MQ。削峯填谷，局部異步併發有效降低RT（校驗場景下，帶來少許額外請求量））
  • 分佈式爲將（X軸擴展：提升吞吐量&QPS等；Y軸擴展：出錯率降低；Z軸擴展：RT降低，TPS/QPS提升）
  • 妥協方案（出於成本考量，可以通過限流（排隊）、降級、熔斷，在性能不可提升下，保證系統可用）
• 編碼級：
  • 數據結構：如跳錶、COW
  • 算法：如折半查找
  • 池化：如線程池、連接池
  • 局部化：如多線程的一種優化（ThreadLocal）
  • 批量：如批量請求合併

c.流程

• 容量規劃（負載測試&壓力測試）-> 確定水位
• APM監控
• 彈性擴縮容

優化注意：首先得確定性能瓶頸在哪裏

但仍然需要思考，這些方法的定位。需要涵蓋服務端問題排查與系統優化涉及的性能優化手段

高性能編碼，可以借鑑：高性能編程論述

2.可用性

a.刻畫方式

• IBM：MTBF、MTTR、HA
• SAP：ATP
• 串聯架構&並聯架構的可用性評估

b.解決方案

• 本地高可用：服務器、磁盤、適配器卡、網絡等

• 業務邏輯保護：操作系統、數據庫、應用、服務、

• 容災多活：HA方案失效、主站點（基礎架構）失效、自然災害

• 本地高可用：

  • 集羣架構（CA）：應用集羣、中間件集羣、數據集羣（包括RAID）
  • 分佈式架構（AP）：分佈式應用、分佈式中間件、分佈式數據庫。引申出一致性（Base理論）、腦裂（Lease機制->合理的time設置）等問題

• 業務邏輯保護：

  • 預防：數據備份（熱冷備份、全增量備份）、嚴謹的應用與架構設計、N與N-1版本共存、變更審覈
  • 發現：監控工具、自動化腳本、應用與系統的正常行爲描述、應用與系統的異常行爲偵測（告警）
  • 修復：應用與系統回滾、一鍵恢復（回覆初始狀態）、自動恢復、快速數據恢復

• 異地容災：

  • 容災級別：應用、數據、SAN網絡、存儲
  • DRP規劃：流程、演練、BCP
  • 容災方案：成本隨數據中心的數量增加而降低。企業Set單元化

邏輯保護技術：備份、快照、CDP連續數據保護、事件溯源（架構）
架構設計方案：限流、降級、熔斷、超時&重試、限制（限流、超時等）&隔離（線程池隔離、信號量隔離）

c.流程

• SRE文化（谷歌）：SLI、SLO、SLA、錯誤預算
• 混沌工程：Chaos Monkey、故障注入測試、故障演練等

PS：
美團CAT應用監控：

3.可伸縮性

a.刻畫方式

可伸縮性的刻畫在與伸縮速率（多久達到目標伸縮數）、伸縮成本（ROI曲線）、伸縮限制（伸縮上限）三個方面。

b.解決方案

• 無狀態應用伸縮：無腦複製（注意路由，避免熱點（一致性哈希空間）等問題）
• 有狀態應用伸縮：
  • 共享磁盤模式：向無狀態應用轉移（將應用的狀態，剝離到對應數據存儲）
    • 結構化數據->共享數據庫
    • 非結構數據->共享緩存（Redis）、對象存儲（OSS）、搜索引擎（ES）等
    • 減少文件系統依賴（如CDN直接對接對象存儲）
  • Share Nothing模式：
    • CAP-優化可用性和分區性，弱化一致性：如Kafka的消費級別調整
    • 集羣管理-優化選舉、仲裁、階段提交、副本、分片管理：腦裂問題（Lease機制）
    • 資源預配置（預熱）：緩存預熱

PS：
由於存儲本身自帶狀態，所以伸縮性較弱。如分佈式數據庫，往往都需要有計劃的，進行擴縮容（擴縮容、切換計劃、精衛同步等）。
但由於Redis有一致性哈希空間的分片方案，所以Redis是具備伸縮性的。不過，需要進行合理的槽點分配（避免請求不均->熱點。注意，槽點變動帶來的事件風暴，控制風暴大小（保留安全量，確定IO閾值等））

PS：

• 伸縮前：容量計算&規劃、動態感知->擴縮容（參照K8s）
• 伸縮中：路由規則。合理&有效的路由規則
• 伸縮後：各個節點負載的檢測。尤其是熱點數據問題

PS：
擴展!=伸縮。伸縮是運行時質量屬性

c.流程（思路）

場景：秒殺&搶購->熱點業務、熱點數據
思路：微服務伸縮->網絡引流、系統資源、基礎設施

4.安全性

a.架構

• 物理安全：
  • 訪問控制
  • 入侵檢測
  • 人員安全
• 數據安全
  • 訪問權限：
    • 責任分層
    • 最小特權
  • 數據較密：
    • 對稱加密
    • 非對稱加密：無需反向解析（如密碼）（哈希->彩虹表->加鹽）
    • 數字簽名：通過哈希獲取
  • 數據保護：
    • 數據邏輯保護（Mysql部分有所涉及）
    • 數據高可用
• 通信安全
  • 網絡攻擊：
    • DDoS拒絕服務攻擊：驗證所佔用資源（SYN Flood -> SYN Cookie回發）、提前阻止（Nginx的OpenResty，進行解析，配合威脅庫，進行阻攔）、WAF
    • HTTP劫持：（運營商劫持。加料）（工信部投訴、轉HTTPS）
    • DNS劫持：
    • 重放攻擊：隨機數、時間戳、通信流水號、一次性口令機制（修改密碼）
    • ARP地址解析欺騙（類比DNS劫持）：
  • 網絡防禦：
    • WAF應用防火牆
    • IDS/IPS入侵檢測和防禦
    • VPN/IPSEC安全通道加密（集團）
    • PGP郵件加密
    • TLS HTTP隧道加密
• 身份安全
  • Authentication認證
    • 目錄管理
    • 用戶認證
  • Authorization授權
    • RBAC（基於角色的訪問控制。還有其他訪問控制方式，《系統架構設計師》有提及）
    • OAuth第三方認證
  • Audit審計
    • 審計管理控制
    • 審計技術控制
• 軟件安全
  • 操作系統安全：
    • 病毒
    • 蠕蟲
    • 特洛伊木馬
    • 零日攻擊（即黑客的0day攻擊）
    • 補丁（參考之前騰訊玄武工作室發現的fastJson漏、或者烏雲網的一些case）
  • 數據庫安全：
    • SQL注入
    • 推理攻擊（對在線教育網站用戶的手機號猜測，應該算是推理攻擊的一種）
  • Web應用安全：
    • XSS跨站點腳本攻擊：嚴格區分用書提交的數據&網頁代碼（編碼&過濾）
    • 重放攻擊：隨機數、時間戳、通信流水號、一次性口令機制（修改密碼）
      PS：有關安全這部分，可以參考《系統架構設計師》安全部分（有涉及多個安全協議）。還可以參考之前黑客相關的資料

b.解決方案：

• SQL注入預防：
• XSS跨站點攻擊防治：
• 加密：
• 簽名：
• WAF應用防火牆：
• RBAC訪問控制
• PKI基礎架構
• .etc

c.流程：

安全基本原則CIA：

• 機密性Confidentiality
• 完整性Integrity
• 可用性Availability

安全評估方法：

• 安全測試：
  • SAST靜態測試：靜態源碼掃描
  • IAST交互式測試：在業務流量中把參數替換成攻擊向量，然後發送給被測服務器，通過服務器的回報對測試結果進行判斷
  • 安全掃描：對系統/應用進行安全漏洞（已有）掃描
• 威脅模型：
  • 攻擊樹分析：用樹型結構來表示系統面臨的攻擊，其中根節點代表被攻擊的目標，葉節點表示達成攻擊目標的方法。
  • DREAD風險評估：漏洞等級評估，穩定性較差
• 滲透模型：
  • 紅藍對抗：
  • 白帽黑帽：

PS：
安全框架：

• ITIL：
• 自適應安全
• 網絡韌性：
• .etc

網絡韌性，在數學的簡單定義是，要使一個網絡分崩離析、喪失原有功能，需要被除掉的節點數佔節點總數的比例。

PS：
AiR-ViBeR: Exfiltrating Data from Air-Gapped Computers via Covert Surface ViBrAtIoNs
Mordechai Guri教授提出了許多諸如此類的物理安全漏洞問題。
ATT&CK向安全白銀時代進軍：統一語言，重裝上陣【open-ata】
自身對黑客行爲的瞭解：滲透-提權-後門...
ATT&CK

5.可擴展性

方法論：
架構擴展立方體：X軸：水平復制（無腦複製；可用性）；Y軸：功能拆分（分割責任、功能、數據；隔離；與領域劃分相關）；Z軸：特徵分割（對業務透明；提供諸如優先級、就近等服務）

• 應用：
  • X軸：水平復制（無狀態應用、狀態剝離（如Session）；涉及性能規劃、彈性擴縮容等）；
  • Y軸：服務拆分（參考微服務拆分。個人理解DDD+業務主鏈路；資源迭代分配；服務隔離）
  • Z軸：客戶分割（地域等；加速查詢等）
• 數據：
  • X軸：水平復制（SQL CDC：Change Data Capture，如canal、精衛等）；
  • Y軸：庫表拆分（這裏的表拆分，不是同一功能的邏輯表拆分爲多個物理表，具體拆分可以參考微服務拆分）；
  • Z軸：分庫分表（同一個邏輯庫表，拆分出多個物理庫表。往往路由規則採用某字段進行哈希）
    架構擴展立方體的不同維度，往往是共存的，即套娃

組織擴展性：溝通鏈路計算、六個披薩理論、
個人理解，組織擴展性提高了溝通效率，進而提高了內聚主題（團隊目標等）下，團隊思考的有效連接，從而迸發出許多創意。可能這也是spotify爲什麼會成功。

流程擴展性：CMMI軟件成熟度模型
個人理解，CMMI軟件成熟度模型，實質一種精細化的過程。這也是我們業務的發展過程。

1. 初始-拍腦袋
2. 管理-方法論
3. 定性-流程化、制度化
4. 定量-SMART原則
5. 自動-信息同步&自我優化

百度百科：
CMMI共有5個級別，代表軟件團隊能力成熟度的5個等級，數字越大，成熟度越高，高成熟度等級表示有比較強的軟件綜合開發能力。
CMMI一級，執行級。在執行級水平上，軟件組織對項目的目標與要做的努力很清晰，項目的目標可以實現。但是由於任務的完成帶有很大的偶然性，軟件組織無法保證在實施同類項目時仍然能夠完成任務。項目實施能否成功主要取決於實施人員。
CMMI二級，管理級。在管理級水平上，所有第一級的要求都已經達到，另外，軟件組織在項目實施上能夠遵守既定的計劃與流程，有資源準備，權責到人，對項目相關的實施人員進行了相應的培訓，對整個流程進行監測與控制，並聯合上級單位對項目與流程進行審查。二級水平的軟件組織對項目有一系列管理程序，避免了軟件組織完成任務的隨機性，保證了軟件組織實施項目的成功率。
CMMl三級，明確級。在明確級水平上，所有第二級的要求都已經達到，另外，軟件組織能夠根據自身的特殊情況及自己的標準流程，將這套管理體系與流程予以制度化。這樣，軟件組織不僅能夠在同類項目上成功，也可以在其他項目上成功。科學管理成爲軟件組織的一種文化，成爲軟件組織的財富。
CMMI四級，量化級。在量化管理級水平上，所有第三級的要求都已經達到，另外，軟件組織的項目管理實現了數字化。通過數字化技術來實現流程的穩定性，實現管理的精度，降低項目實施在質量上的波動。
CMMI五級，優化級。在優化級水平上，所有第四級的要求都已經達到，另外，軟件組織能夠充分利用信息資料，對軟件組織在項目實施的過程中可能出現的次品予以預防。能夠主動地改善流程，運用新技術，實現流程的優化。

解決方案：
架構擴展立方體：

• X軸（水平復制）：
  • 應用：無狀態、容器化、Serverless
  • 數據：多副本、讀寫分離、冷熱隔離。SQL CDC技術
• Y軸（功能拆分）：
  • 應用：
    • 設計：服務拆分、界限上下文交互（DDD、主鏈路設計）
    • 運行：服務發現、服務治理、負載均衡、服務追蹤（參考Spring Cloud服務治理等）
  • 數據：
• Z軸（特徵分割）：
  • 應用：負載均衡
    • 客戶端Ribbon
    • 服務端Nginx
    • K8s Service
    • ESB：企業服務總線
    • API Gateway
  • 數據：
    • 分佈式多片架構（CA）
    • 分庫分表：客戶端（sharding-jdbc）、中間Proxy（Mycat、TDDL）、數據庫（Spanner）

思考
Q：除了狀態剝離外，有狀態應用如何進行擴展
A：功能拆分，以及特徵分割（貌似Session的剝離也可以按照這個思路）
Q：除了狀態剝離外，有狀態應用如何進行水平復制？

三、流程

質量治理涉及的流程，可以參照集團的安全生產（如《安全生產指南》）。

質量流程
流程：
安全生產：

核心：可監控、可灰度、可回滾
容量預估、【核心】、覆盤、快速止血、

PS：不站在架構角度，而是站在編碼角度，可讀性是很重要的。