系統質量治理

一、前言

架構分為三種：

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

每一層架構都在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：不站在架構角度，而是站在編碼角度，可讀性是很重要的。