disstertation

??軟考高級-系統架構設計師-論文：論文范圍（十大知識領域）、歷年論題、預測論題及論述過程、論文要點、論文模板等。

---

—— 2025 年 4 月 4 日 甲辰年三月初七 清明

1、論文范圍（十大核心領域）

??系統架構設計師需要掌握的知識領域廣泛且深入，以下是十大核心知識領域的總結，結合了行業標準和實際架構設計需求。

??這些知識領域需結合具體行業（如金融、電商、IoT）特點靈活應用，架構師的核心價值在于平衡技術先進性與業務可行性，同時規避長期技術債務風險。

• 1.軟件架構理論與模式
  • 核心內容：分層架構、微服務、事件驅動架構（EDA）、CQRS、六邊形架構、Clean Architecture等。
    • 關鍵能力：根據業務需求選擇合適模式，權衡模塊化、解耦與性能。
    • 擴展：云原生架構（Serverless、Service Mesh）、領域驅動設計（DDD）。
• 2.系統設計方法與評估
  • 核心方法：ATAM（架構權衡分析法）、QFD（質量功能部署）、UML/SysML建模。
    • 工具：ArchiMate、C4模型、決策樹分析。
    • 輸出：架構決策記錄（ADR）、技術可行性報告。
• 3.分布式系統設計
  • 關鍵技術：CAP定理、一致性算法（Raft/Paxos）、分布式事務（Saga、TCC）、消息隊列（Kafka/RabbitMQ）。
    • 挑戰：網絡分區容錯、冪等性設計、數據一致性（最終一致性 vs 強一致性）。
• 4.性能與可擴展性
  • 優化方向：緩存策略（Redis、Memcached）、CDN、數據庫分庫分表、讀寫分離。
    • 指標：TPS、延遲、吞吐量、99分位響應時間。
    • 實踐：壓測工具（JMeter）、性能剖析（Flame Graph）。
• 5.安全架構設計
  • 核心領域：零信任架構、OWASP Top 10防護、數據加密（TLS、HSM）、RBAC/ABAC權限模型。
    • 合規性：GDPR、等保2.0、PCI-DSS。
    • 新興技術：同態加密、機密計算（Intel SGX）。
• 6.云與基礎設施架構
  • 多云/混合云：AWS/Azure/GCP服務選型、Kubernetes編排、IaC（Terraform）。
    • 關鍵服務：無服務器（Lambda）、托管數據庫（RDS）、邊緣計算（Cloudflare Workers）。
    • 成本優化：預留實例、Spot實例調度。
• 7.數據架構與治理
  • 數據分層：OLTP vs OLAP、數據湖倉一體化（Delta Lake）、實時數倉（Flink）。
    • 技術棧：SQL/NoSQL選型、ETL工具（Airflow）、數據血緣（Apache Atlas）。
    • 趨勢：Data Mesh、向量數據庫（AI場景）。
• 8.容災與高可用
  • 策略：多活架構（同城/異地）、藍綠部署、混沌工程（Chaos Monkey）。
    • 指標：RTO（恢復時間目標）、RPO（數據丟失容忍度）。
    • 案例：金融級容災（兩地三中心）。
• 9.DevOps與持續交付
  • 工具鏈：CI/CD（Jenkins/GitLab CI）、制品庫（Nexus）、監控（Prometheus+ELK）。
    • 實踐：GitOps（Argo CD）、不可變基礎設施、Canary發布。
    • 文化：SRE（服務等級目標SLO制定）。
• 10.業務與需求分析
  • 方法論：用戶故事地圖、影響地圖（Impact Mapping）、非功能性需求（NFR）量化。
    • 溝通：跨部門協作（產品/運營/安全）、技術商業化思維（ROI分析）。
    • 案例：架構反模式識別（過度設計 vs 欠設計）。
• 附加能力
  • 新興技術敏感度：AI架構（MLOps）、區塊鏈智能合約、量子計算潛在影響。
  • 軟技能：技術談判、文檔撰寫（RFC模式）、技術領導力（Mentoring）。

??論文高頻題：系統建模、軟件架構設計、基于架構的軟件開發方法、系統設計、系統的可靠性分析與設計、系統的安全性和保密性設計。

2、歷年論題

時間\題目	論題一	論題二	論題三	論題四
2009	領域專用架構（DSSA）	信息系統建模	REST 服務的 web 應用	可靠性設計
2010	軟件的靜態演化和動態演化	數據挖掘技術	分布式緩存	可靠性評估
2011	模型驅動架構（MDA）	需求獲取技術	企業架構管理	企業集成平臺
2012	基于架構的軟件設計方法（ABSD）	數據持久層設計（DPL）	決策支持系統（DSS）	信息化建設
2013	軟件架構建模技術	分層架構風格	分布式存儲	可靠性設計
2014	需求管理	非功能性需求	網絡安全設計	可靠性設計
2015	應用服務器基礎軟件	系統架構風格	面向服務架構（SOA）	企業集成平臺
2016	系統架構評估	數據訪問層設計	設計模式	微服務架構
2017	信息系統建模	軟件架構風格	無服務器架構	軟件質量保證
2018	軟件開發過程 RUP	軟件體系結構演化	面向服務架構（SOA）	NoSQL 數據庫
2019	系統架構評估	軟件設計方法	數據湖技術	負載均衡在 web 中
2020	數據分片技術	云原生架構	軟件測試缺陷管理	企業集成架構
2021	面向切面編程（AOP）	系統安全架構	微服務架構	企業集成平臺
2022	基于構件的軟件設計方法（ABSD）	軟件維護方法	區塊鏈技術	湖倉一體架構
2023	面向對象設計	多數據源集成	邊緣計算	可靠性模型
2024-05	模型驅動架構（MDA）	大數據 lamda	單元測試方法	云上自動化運維
2024-11	系統維護	多數據源集成	面向服務架構（SOA）	分布式事務

面向對象、面向切面、架構評估、架構設計、可靠性設計、安全性設計、高并發設計、高可用設計、微服務架構、分布式架構、分布式存儲、分布式數據庫、分布式緩存、分布式事務、基于架構的軟件設計方法（ABSD）、企業集成平臺、

3、預測考點

??面向對象、面向切面、架構評估、架構設計、可靠性設計、安全性設計、高并發設計、高可用設計、微服務架構、分布式架構、分布式數據庫、分布式緩存、分布式存儲、分布式事務。

3.1面向對象

3.2 面向切面

3.3 架構評估

• 架構評估核心目標

  • 確保架構滿足需求：
    • 功能性需求：業務邏輯。
    • 非功能性需求：性能、安全性、可用性、可靠性、可修改行、易用性、健壯性、互操作性等。
  • 識別潛在風險：技術債務、單點故障、擴展瓶頸等。
  • 優化架構決策：在成本、時間和技術可行性之間權衡。

• 常見架構評估方法

  • 基于問卷調查的評估方式：具有主觀性，不太適合本項目。
  • 基于度量的評估方式：雖然評價比較客觀，但需要評價者對系統架構有精確的了解，所以也不太適合本項目。
  • 基于場景的評估方式：評價較主觀，要求評估者對系統有中等程度的了解，故本項目采用基于場景的評估方式。
    • SAAM：架構分析法。
      • 主要輸入：問題描述、需求說明、架構描述文檔。
      • 分析過程：場景開發、架構描述、單個場景評估、場景交互、總體評估。
    • CBAM：成本效益法。
    • ATAM：架構權衡分析法。

• 架構評估過程：

  • 描述和介紹階段：描述架構評估方法、描述業務動機、描述架構。
  • 調查和分析階段：確定架構方法、生成質量屬性效用樹、分析架構方法。
  • 測試階段：討論場景和對場景分級、分析架構方法。
  • 最終/報告階段：描述評估結果、生成評估報告。

• 論述過程：按照架構評估過程進行論證。

  • 1、介紹架構評估目標（并解釋質量屬性）、介紹并確定架構評估方法、介紹所選架構。
  • 2、羅述質量場景、生成質量屬性效用樹、說明敏感點、權衡點、風險點和非風險點并指出對應質量場景。
  • 3、確定質量場景優先級并提供解決方案。
  • 4、生成評估報告。

3.4 架構設計

• 軟件體系結構設計定義：從宏觀層次對需要開發的目標系統進行描述，用不同的視圖從不同的視角對目標系統進行分析與設計的過程。具體過程可分為：體系結構需求、體系結構設計、體系結構文檔化、體系結構復審、體系結構實現、體系結構演化等。
• 架構設計過程
  • 體系結構需求：根據用戶需求和對目標系統的質量目標整理出功能性需求和非功能性需求，架構必須同時滿足二者，并羅列架構核心關注點（如功能性需求、非功能性需求（架構評估質量場景）等）。
  • 體系結構設計：考慮到架構核心關注點所描述的問題，故本項目采用微服務架構，簡述各組件關系、服務拆分、通信等。
  • 體系結構文檔化：采用 4 + 1 時圖模型，描述系統邏輯架構、實現架構、進程架構、部署架構、用例時圖，輸出架構文檔、設計文檔等等。
  • 體系結構復審：與架構團隊、客戶團隊等對架構設計進行評審。
  • 體系結構演化：上線后有什么問題，如何解決。

3.5 可靠性設計

心跳、Ping/Echo、主動冗余、被動冗余、選舉、集群等。（需通過量化數據來說明）。

• 可靠性定義：系統在發生錯誤或故障的情況下，能夠維持系統功能特性的能力。
• 系統可靠性：
  • 硬件可靠性：物理退化，故障率變高，通過主動冗余、監控檢錯配合報警（心跳、Ping/Echo等）來解決。
  • 軟件可靠性：業務邏輯復雜度、系統設計，通過防衛式程序設計、N 版本程序設計、降低復雜度設計等來解決。
• 論述過程：
  • 1、介紹什么是系統可靠性，硬件故障和軟件故障如何產生以及常用解決方案。
  • 2、針對本項目所選用可靠性方案進行論述。
  • 3、每個論點先說明不這樣設計的問題（例：系統集群部署：單個硬件設備或單個軟件服務進程或有什么問題），然后說明該如何設計（例：應該集群部署），這樣設計如何解決問題，會帶來什么問題。
  • 4、系統集群部署、數據庫主備部署（可引進緩存設計）、程序設計方面容錯（防衛式程序設計：參數校驗、sql 注入、異常處理等；降低復雜度：高內聚、低耦合、面向對象六大設計原則、設計模式等）。
  • 故障檢測與恢復、冗余設計、軟件容錯、降低復雜度、采用成熟構件。
  • 分層設計：
    • 基礎設施層：
      • 同城雙活（同城兩機房）、異地備災、兩地三中心。
      • 負載均衡：nginx、服務網關。
    • 數據層：
      • 分布式數據庫：tidb、最終一致性。
      • 分布式緩存：redis 高可用。
    • 應用層：
      • 限流、熔斷、降級。
      • 服務網關：路由與負載均衡、k8s 彈性擴容。
    • 監控與自愈：日志收集、可用性計算、告警。

3.6 安全性設計

• 安全性定義：指系統向合法用戶提供服務的同時能夠拒絕非法用戶使用系統的能力。
• 信息安全五要素：機密性、完整性、可用性、可控性、可審查性。
  • 機密性：確保數據不暴露給未授權的實體或進程。入侵檢測、用戶認證。
  • 完整性：只有被授權的實體才可修改數據，并能判定出數據是否已被篡改。用戶授權、數據加密（加密傳輸、加密存儲）。
  • 可用性：確保被授權的實體在需要時可訪問數據，即攻擊者不能使用所有資源阻礙被授權者的使用。
  • 可控性：可以控制授權范圍內的信息劉向和行文方式。
  • 可審查性：對出現的問題提供調查的依據和手段。追蹤審計。
• 論述過程：
  • 1、先說明什么是安全性、安全問題如何產生（惡意入侵、泄漏、爬取、盜刷流量等）。
  • 2、說明信息安全五要素定義。
  • 3、以此說明在項目中如何確保五要素。
  • 用戶認證、授權：單點登錄、基于RBAC的權限模型、token 驗證（第三方授權、刷新 token、token）。
  • 入侵檢測：ip 過濾、ip 黑名單、ip 白名單。
  • 數據加密：加密傳輸（非對稱加密（RSA）、數字簽名以及如何加密）、加密存儲（sql 函數和客戶端設置）數據脫敏。
  • 追蹤審計：日志收集、監控告警。

3.7 高并發設計

核心考點：

• 并發問題本質：資源競爭、數據一致性、系統擴展性。

• 分層優化策略：前端 -> 網關 -> 服務層 -> 數據層逐級削峰。

• 技術組合能力：緩存、隊列、并發、資源調度、分庫分表。

• 前段層優化：減少 http 請求，加速頁面渲染。

  • 靜態資源加速：cdn 分發 html/css/js，減少源站壓力。
  • 瀏覽錢緩存：強緩存（cache-control: max-age = 3600）。
  • 請求合并：將多個接口聚合為BFF（Backend For Fortend）。

• 接入層優化：防止惡意流量、負載均衡（發揮節點性能）。

  • nginx 負載均衡服務網關。
  • 服務網關：路由與負載均衡（負載均衡策略）、限流降級（sentinal）、熔斷、黑名單。

• 服務層優化：避免資源競爭、提高吞吐量。

  • 增加計算資源（集群部署）、減少計算開銷（優化業務邏輯、字段裁剪等）、引入優先級隊列（mq 削峰）、引入并發機制、采用資源調度（線程池）。

• 數據層優化：降低數據庫負載、突破單機性能瓶頸。

  • 緩存策略：

    • 緩存：分布式緩存 熱 key + 本地緩存。
    • 雪崩：緩存預熱、隨機過期時間。

  • 數據庫策略：讀寫分離、分庫分表、緩存 + 數據庫讀寫問題。

• 容災與降級：

  • 熔斷機制：qps >= 5000 式2熔斷。
  • 降級方案：返回緩存歷史數據、關閉非核心功能。

3.8 高可用設計

見 3.5 可靠性設計。

3.9 微服務架構

• 定義：定義、優點、缺點。
• 相關組件：注冊中心、配置中心、網關、調用、負載均衡、限流/降級/熔斷、分布式事務。
• 論述過程：分別說明各組件作用、特點、缺點及注意事項。
  • 注冊中心：sca nacos、與 eureka 區別、優點。
  • 配置中心：優點。
  • 網關：nginx 網關、服務網關、優點。
  • 調用：http 與 rpc 區別。
  • 負載均衡：nginx 負載均衡、服務網關負載均衡。負載均衡測略。輪詢、加權輪詢、最少連接、ip 哈希。
  • 限流降級熔斷：定義、實施、限流算法。
  • 分布式事務：
  • 最終一致性：

3.10 分布式架構

• 理論基石：
  • CAP：一致性（C）、可用性（A）、分區容錯性（P）。
    • 一致性：所有節點在同一時間看到的數據是一致的。即任何讀操作都能督導最新寫入的數據。若某個用戶更新了某個數據，則其它用戶在讀取時應該立即看到更新后的結果。
    • 可用性：系統在任何時候都能正常使用，不會因為部分節點故障而導致整個系統不可用。即使某些節點宕機，用戶仍可讀寫數據。
    • 分區容錯性：系統在遇到網絡分區（即節點間通信中斷，如網絡延遲、丟包、節點故障等）時，仍能夠繼續運行。即使部分節點間出現網絡故障，系統仍能夠提供服務。
  • BASE：基本可用性（Basically Available） + 最終一致性（Eventually Consistent）。
    • 基本可用性：系統在出現故障時（如節點故障或網絡分區），仍然能夠提供部分功能或服務（如核心功能），而不是完全不可用。但可能會降低服務質量（如降級或增加響應時間）。電商系統在大促銷期間可能會關閉非核心功能（如評價系統），但核心功能（如下單、支付）仍然可用。
    • 軟狀態（Soft State）：系統的狀態可能會隨著時間的推移而變化，即便沒有外部輸入，數據也可能不一致。換言之，系統的狀態不需要時刻保持一致，允許存在中間狀態，且狀態的變化通常通過異步更新或后臺任務完成。分布式緩存中的數據可能會在一段時間后過期或更新。
    • 最終一致性：系統在經過一段時間后，最終會達到一致狀態。即不要求數據的實時一致性，運允許短時間內不一致，通過異步復制或消息傳遞來達到最終一致。分布式數據庫（Cassandra）中，數據被更新后，可能會延遲同步到所有節點，但最終所有節點的數據將會保持一致。
  • 一致性協議（分布式一致性共識算法）：Raft（kafka、etcd、tidb）、Paxos（zookeeper）。
• 實踐：
  • 分布式數據庫：TiDB、Multi-Raft 協議，再說明其與 mysql 的區別。
  • 分布式緩存：redis、協議、分布方式、數據同步、持久化。
  • 分布式事務：分布式事務解決方案。
  • 分布式文件系統：
    • 數據可靠性：通過數據冗余存儲（默認3副本）和自動容錯機制（數據塊復制、心跳檢測和數據塊掃描）來保證數據的可靠性。
    • 可伸縮性：通過增加更多的節點來線性擴展存儲容量，能夠支持 PB 級數據的存儲。
    • 性能：通過數據本地化、優化讀寫路徑和利用硬件特性（如磁盤并行讀寫）來提高數據傳輸和處理效率。
  • 消息隊列：解耦、削峰填谷、異步、發布訂閱、可伸縮性、容錯性、持久化、低延遲、生態系統支持。
    • 優點：
      • 解耦：提高系統可擴展性和靈活性。
      • 削峰填谷：平衡系統負載。
      • 異步：異步處理，提高系統吞吐量。
      • 發布訂閱：實現消息的訂閱和選擇性傳遞。
      • 可伸縮性：通過增加更多節點來線性伸縮，以適應不斷增長的數據量。
      • 容錯性：通過數據復制和分區機制來提供強大的容錯能力。
      • 持久化：允許用戶根據需要調整數據的保留策略和副本因子，以適應不同的業務場景。
      • 生態系統支持：強大的生態系統和豐富的 api，可無縫集成到現有系統或框架中。
    • 缺點：
      • 消息隊列設計管理較復雜。
      • 可能出現消息丟失、重復或亂序問題。
      • 需要處理消息隊列延遲和吞吐量瓶頸。

3.11 分布式數據庫

• CAP 定理及一致性協議（分布式算法）：分布式理論與分布式算法

• 定義：忘了，等做到了再補上。

• 主要特點：

  • 數據分布性：數據在物理上分布于不同的節點。
  • 邏輯整體性：數據在邏輯上是相互關聯的統一整體。
  • 節點自治性：每個節點可以獨立處理本地數據。
  • 使用透明性：用戶無需知道數據存儲在哪個節點上。

• 分布式數據庫模式：

  • 全局概念模式：定義分布式數據庫中數據的整體邏輯結構，數據就如同根本沒有分布一樣，可使用傳統的集中式數據庫所采用的方法進行定義。
  • 全局外模式：是全局應用的用戶視圖，是全局概念模式的子集，該層直接與用戶交互。
  • 局部概念模式：是局部數據庫的概念模式。
  • 局部內模式：是局部數據庫的內模式。
  • 分片模式：講一個關系模式分解成多個數據片。
  • 分布模式：定義分片模式的處理結果的存放節點，即數據分布在不同的物理位置。

• 分布模式：

  • 共享磁盤（存儲）架構（Shared-Disk）：所有節點共享統一存儲設備，但計算資源獨立。其優點是數據一致性易維護，缺點是存在單點故障風險且擴展受限。適用于讀多寫少、小規模、低并發場景。
  • 無共享架構（Shared-Nothing）：每個節點獨立存儲和處理本地請求，節點間通過消息傳遞寫作。其優點是容錯性高易擴展、大數據量高并發，缺點是引入了數據一致性問題、數據分片問題和事務處理的復雜性。適用于分布式、大規模、高并發場景。
  • 多主復制（分片）架構（Sharding）：數據按特定規則劃分為多個分片，分布到不同節點，多節點共同提供讀寫服務。其優點是高可用、高負載，缺點是數據沖突和一致性問題，且實現復雜。別用。

• 分片模式：

  • 水平分片：
    • 哈希分片：對分片字段（如用戶 id）進行哈希，將數據均勻分配到多個節點上，適用于均勻分布的數據。
    • 范圍分片：按分片字段（一般為時間字段）將數據以時間范圍為條件分配到多個節點上。適用于時間性較強的數據。
  • 垂直分片：按特定列的字段值切分，通常用于邏輯上的分片。如根據地區或部分切分。
  • 混合分片：結合水平分片與垂直分片，應該對復雜業務需求。

• 數據復制：

  • 主從復制：一主多從，主節點負責處理寫請求，并將寫操作結果同步到從節點，多從節點負責處理讀請求。其優點是實現簡單、易于理解，讀寫分離、提高性能；缺點是單點故障需手動升級主節點，主從同步可能存在延遲，導致數據不一致。
    • 優點：
      • 避免單點故障：主節點實時、異步的復制數據到從節點，當主節點宕機或故障時，可選取一個從節點升級為主節點，從而防止單點故障。
      • 提高吞吐量：讀寫分離，主節點負責處理寫請求，從節點負責處理讀請求，以此來避免因讀寫鎖的競爭而帶來的時間損耗，降低了系統壓力，提高了吞吐量。
    • 全同步復制：主庫完成一個事務后，會等待所有從庫完成同步再返回。數據一致性高但性能較低。
    • 半同步復制：主庫完成一個事務后，會等待至少一個從庫完成同步再返回。犧牲了一定性能但提高了數據安全性。
    • 異步復制：主庫完成一個事務后立即返回，不會等待從庫完成同步。性能高但數據一致性差。
    • mysql 主從復制過程：
      • 當在從庫上啟動復制時，首先創建 I/O 線程連接主庫，
      • 主庫隨后創建 Binlog Dump 線程讀取數據庫事件并發送給 I/O 線程，
      • I/O 將接收到的數據庫事件更新到從庫的 Relay Log 中去，
      • 之后從庫上的 SQL 線程讀取中繼日志 Relay Log 中的數據庫事件并應用。
  • 多主復制：多個主節點同時處理寫請求，并將寫操作結果同步給各自從節點。其優點是無單點故障、寫入性能高；缺點是數據沖突與實現復雜。
  • 鏈式復制：節點以鏈式結構存在。寫請求先由頭節點處理，然后依次傳遞給后繼節點，讀請求由鏈中任意節點處理。其優點是數據一致性強、且避免了數據沖突，缺點寫操作延遲較高（尤其是鏈較長時）、鏈中單節點故障會導致鏈中斷。適用于讀多寫少且對數據一致性要求高的場景。

• 一致性模型：

  • 強一致性：
    • 線性一致性：寫入的值在調用和完成之間可以被其它節點讀取出來，即不會讀到數據轉換的過程和中間未完成的狀態。
    • 順序一致性：
  • 弱一致性：
    • 因果一致性：
    • 最終一致性：副本之間的數據復制完全是異步的，即寫操作執行完后，會以異步的方式在一段時間后同步到其余副本，這段時間可以是毫秒、數天、甚至永遠，總之最終它一定會同步的。
    • 客戶端一致性：

• 事務處理：

  • 見下文 分布式事務。

• 查詢優化：

  • 數據庫定位優化：分片裁剪（只訪問當前節點分片規則內的數據）、全局索引（維護分片鍵與物理位置的映射）、本地索引（各分片維護自己的索引）。
  • 連接操作優化：廣播連接（將小表復制到所有節點）、重分布連接（按連接鍵重新分布數據，即將連接鍵相關的一組數據分布到同一節點上）、本地化連接（同一分片上的表直接連接）。
  • 聚合操作優化：各節點執行局部聚合，合并節點執行全局聚合。
  • 并行執行優化：流水線并行（不同操作階段重疊執行）、分區并行（不同數據分區并行處理）、操作符并行（單個操作符內部分解為子任務）。
  • 網絡傳輸優化：列式傳輸（只傳輸查詢需要的列）、數據壓縮（減少網絡傳輸量）、批處理（合并多個小請求為批量請求）。

• 挑戰：

  • CAP 權衡：分布式系統中 p 不可避免，故只能在 cp 和 ap 二者之間抉擇，如金融系統選強一致性，社交網絡選高可用性。
  • 事務處理：跨多個節點事務處理。
  • 查詢優化：數據分片導致。
  • 運維管理：復雜度提高。

• 主流分布式數據庫對比：

  數據庫	類型	一致性模型	特點	適用場景
  Google Spanner	NewSQL	強一致性	全球時鐘同步	金融、跨洲際強一致性
  CockroachDB	NewSQL	強一致性（線性）	兼容 pgSQL、自動分片	全球化部署、HTAP
  TiDB	NewSQL	強一致性（線性）	兼容 MySQL、HTAP 架構	實時分析、高并發事務
  Cassandra	NoSQL	最終一致性	高寫入吞吐、多數據中心復制	社交網絡、時序數據
  MongoDB	NoSQL	可調一致性	靈活文檔模型、自動分片	內容管理、物聯網

3.12 分布式緩存

說 redis 就行，我說的。

3.13 分布式文件系統

說 HDFS 就行。

3.14 分布式事務

介紹事務特性（ACID）、常見協議或算法、實際使用組件（Seata）。

• 四種方案：
  • AT 模式：AT 模式是一種無侵入的分布式事務解決方案。用戶只需關注自己的業務 sql，AT 模式會自動生成事務的二階段提交和回滾操作。一階段，AT 模式 會攔截業務 sql，解析 sql 語義，找到要更新的業務數據，并保存快照數據和行鎖。二階段，如果是提交，則清理快照數據；如果是回滾，則根據快照數據恢復業務數據。
  • TCC 模式：侵入性強，但性能高。該模式需要用戶自己根據業務場景實現 try、confirm 和 cancel 操作。此三種操作分別對應事務的開啟、二階段事務提交和二階段事務回滾。該模式適用于對中間狀態有約束的業務，如訂單業務。
  • Saga 模式：該模式適用于長事務，由事件驅動，各個參與者之間異步執行。如果任何一個正向操作失敗，該模式會執行前面各個參與者的逆向回滾操作，回滾已提交的參與者。該模式的優點是并發度高，無長期資源鎖定。
  • XA 模式：XA 模式是利用事務資源對 XA 協議的支持，以 XA 協議的機制來管理分支事務。XA 模式是兩階段提交模式，通過資源管理器和事務協調者來保證事務的原子性。該模式的優點是數據的一致性較好，缺點是實現復雜度較高。
• 兩種實現：
  • 兩階段提交（2PC）：
  • 三階段提交（3PC）：

3.15 軟件架構維護

• 可理解性：一個可維護的軟件必然是可理解的。軟件的可理解性是指通過閱讀源代碼和相關文檔，了解軟件的功能和如何運行的容易程度。軟件的可理解性可以使用“90-10測試”的方法來衡量，即如果一個有經驗的程序員閱讀一份源代碼清單10分鐘，可以寫出該程序的90%，則認為這個程序具有可理解性。
• 可修改性：可維護性、可擴展性、可移植性、軟件重構
  • 一個可維護的軟件必然是可修改的。軟件的可修改性是指修改軟件的難易程度。軟件的可修改性可以通過進行幾個簡單的修改練習來評價。假設軟件的平均復雜性是C，要修改的模塊的復雜性是A，那么修改的難度可由下面公式計算：D=AC
• 可靠性：一個軟件的可靠性越高，需要維護的概率就會越低。軟件的可靠性是指軟件在滿足用戶需求的前提下，在給定的時間段內正確運行的概率。軟件可靠性的度量有以下兩種方法：根據軟件的錯誤統計進行可靠性預測。如度量軟件的平均失效間隔時間（MTTF）。根據軟件的復雜性進行可靠性預測。
• 可測試性：一個可維護的軟件必然是可測試的。軟件的可測試性是指驗證軟件程序正確的難易程度。可測試性好的軟件，通常意味著軟件設計簡單，復雜性低。因為軟件的復雜性越大，測試的難度也就越大。
• 易用性：軟件易于使用通常意味著軟件設計簡單，易于理解。軟件的可使用性是指用戶使用軟件的難易程度。軟件的可使用性可以通過測試用戶首次使用軟件掌握常用功能的時間來衡量。

4、論文要點

??論文包含三部分：摘要 + 正文 + 結尾。

• 1.摘要
  • 摘要組成部分：項目背景 + 論文主題（250 字 + 50 字 共 300 字）。
  • 項目背景組成部分：項目起止時間、項目投資（資源）、個人職責（建議以項目經理的角度進行寫作）、項目甲乙雙方（項目其他干系人——如有，如設計單位、質量監督機構等）、項目建設任務、項目建設目標/目的、其他補充。
  • 論文主題組成部分：論文主題設計某某知識領域、該領域具體管理過程、項目效果、業主評價。
• 2.正文
  • 正文組成部分：項目背景、管理過程/論文主體（500 字 + 2000 字 共2500 字）。
  • 項目背景組成部分：在 摘要-項目背景 基礎上進一步細化、詳細。
  • 管理過程/論文主體組成部分：論文主題設計某某知識領域、該領域具體管理過程。如，該知識領域共設計 5 個管理過程/步驟 — 2000 字。
    • 過程/步驟1：闡述該階段主要工作依據、方法技術、成果 — 400 字。
    • 過程/步驟2：同上 — 400 字。
    • 過程/步驟3：同上 — 400 字。
    • 過程/步驟4：同上 — 400 字。
    • 過程/步驟5：同上 — 400 字。
• 3.結尾
  • 結尾組成部分：項目主要成果、個人目標（200 字 + 50 字）。
  • 項目主要成果組成部分：項目起止時間、項目目前狀態、項目建設主要成效、其他補充。
  • 個人目標：自由發揮。

注：論文題目居中，黑體加粗，2 號字；摘要、正文和結尾首行縮進兩字符、宋體 5 號字，段落行距 1.5 倍。

5、論文模版

??摘要：

??本人于 2022 年 7 月參與 XXX 項目，該項目 XXX、XXX 和 XXX 等功能模塊。 在該項目組中我擔任系統架構師崗位，主要負責系統整體架構設計工作。本文以該項目為例，主要討論了 吧啦吧啦 在項目中的具體應用。（祭出排比句大招，簡述論點在項目中的實際應用。如：通過 xx 技術/機制/模式等實現了什么功能或解決了什么問題。）。項目最終順利上線，并持續穩定運行，為 XXX 提供了有力保障，且 XXX 取得了何種成績。

??正文：

??隨著國家經濟的飛躍發展，人民生活水平的快速提高，以及國際政治因素的影響，以 XXX（項目目的）已顯得尤為重要。故，2022 年我司 計劃自主研發/手某某某公司委托 建設 XXX 項目。該項目主要包括 XXX、XXX 和 XXX 等功能模塊（基于摘要 但比起更詳細）。吧啦吧啦組件/技術/機制/模式。本人在項目中擔任系統架構師職務，主要負責系統整體架構設計。

??我們在項目中采用 吧啦吧啦技術/架構/原則/模式（針對論點），論點是什么、有什么特點/原理過程是什么、能給系統帶來什么好處（優點）。下文著重討論 論點 在該項目中的具體應用和效果。

??一、過程/步驟1

??二、過程/步驟2

??（過程/步驟數 * 400 = 2000 字左右）

??該項目歷時 2 年時間完成測試并上線，通過上述 論點方案的實施，整個系統持續穩定的運行，未出現過 論點所針對 的問題。

??當然，在我們設計系統和后期運行維護過程中，也陸續發現了一些問題和不足，如 吧啦吧啦 問題（問題定義），描述問題現象或過程。后續改進方案。