Begin

需求決定架構，需求更可以區分有功能性需求、非功能性需求以及『約束』

  • 系統 v.s 子系統
  • 模組 v.s 元件
  • 框架 v.s 架構：框架關注『規範』、架構關注『結構』

為什麼要架構設計

整個軟體技術發展的歷史就是一部與『複雜度』鬥爭的歷史

  • 架構設計的目的是為了解決複雜度帶來的問題
  • 複雜度來源
    • 高性能(速度)
    • 高可用(系統無中斷的執行功能)
    • 高擴展性：應對需求變化而提供的擴展能力
    • 成本
    • 安全
    • 規模

架構設計原則

和程式設計對比而言，架構設計並沒有像語言那樣的語法進行約束，更多的是面對多種可能性時進行選擇

  • 合適原則：合適優於業界優先
  • 簡單原則：簡單優於複雜
  • 演化原則：演化優於一步到位,「軟體架構需要根據業務發展不斷變化」

對於建築來說，永恆是主題、而對於軟體來說，變化才是主題

架構設計流程

  • 識別複雜度
  • 設計多個備選方案
    • 新技術都是在現有技術的基礎上發展起來，現有技術又來源於先前的技術。將技術進行功能性分組、可以大大簡化設計過程，這是技術『模組化』的首要原因。技術的『組合』和『遞迴』特徵，將徹底改變我們對技術本質的認識 — By 「技術的本質」
    • 常見錯誤：要設計最優秀的方案、只做一個方案、方案過於細節
  • 評估和選擇備選方案
  • 詳細方案設計

高性能：速度更快

存儲高性能

關聯式資料庫

  • 讀寫分離：考慮『複製延遲帶來的複雜性』
  • 分庫分表：
    • 按業務分庫: join操作問題、transaction 問題、成本問題
    • 分表：垂直分表v.s水平分表
  • 實現方式：程式碼、中介軟體封裝

NoSQL

  • Key-Value、document、列式、全文檢索搜尋引擎

Cache

  • 緩存穿透、緩存雪崩、緩存熱點

計算高性能

單伺服器高性能

  • PPC model
  • TPC model
  • Reactor model

集群高性能

  • DNS/硬體/軟體 負載平衡

高可用：東西不會壞

CAP 理論

對於一個分散式運算系統、不可能同時滿足一致性(Consistence)、可用性(Availability)、分區容錯性(Partition Tolerance)

  • 一致性與分區容錯性（CP）：當選擇一致性和分區容錯性時，系統將保證所有運作的節點在網絡分區期間顯示一致的數據。然而，這可能意味著在某些情況下無法處理來自用戶的請求（降低可用性）。
  • 可用性與分區容錯性（AP）：選擇可用性和分區容錯性意味著即使在網絡分區的情況下，系統仍然能夠處理請求，但這可能會導致數據在不同節點之間的不一致。
  • 一致性與可用性（CA）：如果一個系統在沒有網絡分區的理想狀況下運行，則可能同時實現一致性和可用性。但在真實世界的分布式系統中，網絡分區是無法避免的，因此這種組合在實踐中是不切實際的。

SAGA Pattern

在軟體架構中，SAGA Pattern 是一種用於處理分布式系統中事務的設計模式，特別是在微服務架構中。在傳統的單一資料庫系統中，事務管理通常通過使用ACID（原子性、一致性、隔離性、持久性）原則來實現。但在分布式系統中，尤其是微服務架構中，由於服務間的資料庫是獨立的，因此無法直接使用ACID事務。

SAGA Pattern 通常分為兩種類型：

串行 SAGA（Choreography-based SAGA）： 在這種模式下，每個服務在完成其操作後會產生事件，這些事件被其他服務監聽，從而觸發下一個服務的操作。這個過程是自我管理的，沒有中央協調器。 例如，訂單服務完成創建訂單後會發送一個事件，庫存服務聽到該事件後進行庫存減少操作，然後發送一個更新事件，這個更新事件可能會被支付服務聽到，從而觸發支付操作。 集中式 SAGA（Orchestration-based SAGA）： 這種模式使用一個中央協調器（或者叫 Saga Orchestrator）來管理和協調各個微服務間的交互。協調器負責決定何時以及如何觸發各個服務，並處理可能出現的錯誤。 協調器會向訂單服務發送命令執行訂單創建，然後等待確認後，指揮庫存服務進行庫存更新，最後指揮支付服務進行支付操作。 在SAGA模式中，如果在一系列操作中的任何點發生失敗，就會觸發一個補償交易（Compensating Transaction），這是一系列操作的逆操作，用於將系統恢復到一致的狀態。例如，如果支付服務在執行時失敗，則可能需要取消訂單並恢復庫存。

SAGA 模式通過保持服務的獨立性和減少相互依賴，有助於提高大型分布式系統的可擴展性和可靠性。

FMEA (萬一錯誤了怎麼處理錯誤)

Failure mode and effects analysis

  • 初始架構設計圖 > 假設某個部件發生故障 > 分析此故障對系統功能的影響 > 根據分析結果判斷架構是否要進行優化
  • FMEA 分析表格

儲存高可用

  • 主備複製
  • 主從複製
  • 主備倒換 v.s 主從倒換
  • 集群分區

計算高可用

  • 主備架構：適合內部管理系統、後台管理系統這類使用人數不多、使用頻率不高的業務。不適合線上業務
  • 主從架構
  • 對稱集群
  • 非對稱集群

業務高可用

前兩者計算與存儲高可用目標是：在部分伺服器故障的場景下、如何保證系統能夠繼續的提供服務

  • 異地負載
  • 介面級的故障應對：降級、熔斷、限流、排隊

可擴展：需求可以改

可擴展模式

所有的可擴展性架構設計，背後的基本思維都可以總結一個字：拆

  • 面向流程拆分
  • 面向服務拆分
  • 面向功能拆分

分層架構

分層架構本質在於：隔離專注點

  • 特性：層層傳遞、缺點：性能
    • C/S、B/S
    • MVC MVP
    • 邏輯分層

SOA 架構

提出背景是企業內部的IT系統重複建設且效率低下

  • 服務
  • ESB
  • 松偊合

微服務

  • small、automated、lightweight
  • 微服務 v.s SOA
    • 微服務是一種和SOA相似但本質不同的架構理念
  • 微服務基礎設施
  • 自動化：測試、部署、交付

微內核架構

  • For Example: WordPress
  • 外掛程式化(plug-in)
  • 通常基於產品的應用
  • 外掛程式管理、外掛程式連接、外掛程式通訊

架構演進

我們應該如何推動技術的發展呢？

  • 潮流派、保守派、跟風派(跟風競爭對手…)
  • 歸根到底就是業務的發展(市場、技術、管理)
  • 業務分成『產品類』和『服務類』
    • 產品來自於技術創新
    • 服務類來自於業務發展：越來越複雜、用戶量越來越大

架構重構

期望透過架構重構來解決所有問題是不切實際的

目標是識別出真正要透過架構重構來解決的問題、集中力量快速解決

開源專案

DRY: Don’t repeat yourself 不要重複造輪子

  • 如何選擇一個開源專案？
    • 聚焦是否滿足業務
    • 聚焦是否成熟：版本號、使用案例、社群活躍度
    • 聚焦運維能力
  • 如何使用開源專案？
    • 深入研究、仔細測試
    • 小心應用、灰度發布
    • 做好應急、以防萬一
  • 如何基於開源專案做二次開發
    • 保持純潔、加以包裝 ex. 不要改動原專案、而是開發輔助系統, 例如不要改動redis,而是增加redis proxy…
    • 發明你要得輪子

高流量

https://blog.scottchayaa.com/post/2019/01/09/how-to-handle-the-high-concurrency-on-laravel/