软件设计的第一性原理：结构化抽象
軟件設計的第一性原理，是結構化抽象。術生于道，技術生于原理。
引語
所謂的第一性原理，就是無論使用什么方法論，都無法繞過的那最最基礎的部分。無論是 DDD 設計，還是面向模式的架構設計，或 微服務架構，均建基于結構化抽象。
何為結構化抽象 ？先回答 “何為抽象” 與 “何為結構化” 兩個問題。
何為抽象 ？?“編程漫談（三）：抽象”?一文闡述了什么是抽象及在編程與計算中的意義；?“代碼抽象與分層”?則列舉了從代碼中提煉出來的六類抽象，涵蓋了編程開發中常見的實體及處理。
何為結構化 ？結構，是事物的組成元素及關聯和作用。?“編程漫談（十一）：編程概要”?一文闡述了編程中的各種數據結構及控制結構，“軟件的組合結構：從指令到軟件”?則闡述了組合元素的方法與結構。結構化，分為數據結構化和控制結構化。數據結構化指海量數據的組織和存儲及需要滿足的約束（比如一致性、完整性等）；控制結構化，是指，操作的組織和執行以及需要滿足的約束。
軟件，本質上是一種可動態而彈性變化的邏輯裝置。結構化，即是將邏輯進行抽象、提煉、分離、聚合，構建成更加縝密、動態、彈性的結構流。
邏輯，是思維意識的一種形式。軟件設計與開發，是與自己的思維意識進行抗爭與和解。
理念
設計與開發
軟件設計與開發工作滲透著結構化抽象的思想。譬如：
軟件建模。是對大量原始數據進行結構化組織，使之更加有序、有意義、可交互。
數據存取。在建立對數據的組織抽象之后，就要進行數據的存取操作。數據是規則的還是不規則的 ？數據量有多少及增長速度如何 ？是否要進行緩存 ？選取合適的數據存儲組件。數據存儲組件是對海量數據存儲和訪問的結構化抽象。
流程構造。在確定數據存取方案后，需要構建完整的流程。流程可以使用時序圖來表示。流程包含前置、操作與契約。前置，是進行操作需要滿足的條件；操作則是獲取數據或請求某種執行；契約，是在完成操作之后，必須滿足的一系列斷言。完整流程通常是：“前置-操作-契約”的子流程的有序組合。
編程實現。需要評估潛在變化的部分，將通用的部分與易變化的部分相分離。
設計模式
設計模式是對象職責及交互的結構化抽象，是體現結構化抽象思想的基本單元。可參閱：“軟件設計要素初探：基礎設計模式概覽”?。
架構模式是基于設計模式的更高層次的結構化抽象。可參閱：“軟件設計要素初探：架構模式”?。
設計模式和架構模式主要應對軟件的業務可擴展性難題。
技術機制
在軟件設計中，技術是繞不開的一道檻。技術的作用在于，在指定的場景下，所執行的操作效果必須滿足某種約束。技術機制，是將多個相關聯的結構化抽象進行聚合后的成品。
異步
比如先快速響應客戶端，再進行請求處理。其結構化抽象是，操作相對于主進程的執行耗時與實際執行耗時無關。
冪等
比如處理資金問題，必須考慮冪等問題，即同一個請求，執行多次的效果必須與執行一次的效果等同。冪等的結構化抽象是，操作的主效果與操作次數無關。
事務
比如多個關聯數據的插入、更新和刪除，必須保證原子性。要么全部執行，要么一個都不執行。需要使用事務來保證。事務的特性是ACID，結構化抽象是關聯數據集合在操作前后必須滿足某種一致性約束。確定“關聯數據集的一致性約束”是關鍵，其實現是還原點、快照與回滾日志。
并發
大量請求或數據集的處理，使用串行的方式效率難以滿足性能或吞吐量要求，需使用并發的方式，充分利用多核CPU資源。結構化抽象是，多個相互獨立的執行單元。這些執行單元擁有獨立的CPU和緩存，所使用的內存可以為共享內存型和獨立內存型。
同步
在并發場景下，要保證多個執行單元（比如線程、進程等）能夠看到共享內存的最新更新值。同步的本質是確保指定順序執行，避免不確定的執行順序帶來不確定性的結果。其結構化抽象是臨界區。臨界區是約束執行順序的一種結構。
框架
應用的組件、配置與啟動，可以做成通用的框架和腳手架反復使用，快速啟動和部署一項工程，減少不必要的重復工作量。框架的結構化抽象是，將工程中的配置、部署與啟動、運行結構、通用任務進行提煉并形成固定的模式，應用只需要關注可變的業務部分。
限流
突發的峰值流量，為了避免瞬間占滿和擊垮服務器的資源和服務能力，需要進行限流。其結構化抽象是，在指定時間間隔內的通過許可數必須滿足指定規格。
緩存
對于熱點數據，為了避免反復從源存儲獲取，增大對存儲的訪問壓力，可以使用緩存來存儲熱點數據，增大命中率，提升性能，減少對存儲的不必要的訪問壓力。緩存的結構化抽象是，使用少而精的空間優先于大而全的空間的搜索。“少而精”是指聚焦應用的經常被訪問的熱點數據。緩存的衡量指標是命中率和過期時間，操作是緩存與源存儲的讀寫同步。
降級
當非核心的依賴不可用時，可以及時切斷依賴，舍小取大，保證整體服務正常運行，不受局部影響。降級的結構化抽象是，是主備策略的設計與切換機制。
重試
當處理數據發生錯誤時，可以進行重試來進行補償和恢復。重試的結構化抽象是，至少（且通常只需）保證一次操作成功。
切面
比如耗時統計。耗時統計與操作的執行內容無關，僅關注操作的耗時。切面的結構化抽象是，操作的非功能屬性與功能本身的解耦。
代理
比如請求的負載均衡。不是直接執行目標操作，而是創建一個代理，由這個代理轉發請求和執行目標操作。代理的結構化抽象是，隱藏目標操作。
版本號
版本號通常用于實現非阻塞式并發，即樂觀鎖。其結構化抽象是，一個嚴格保證特征數值單調遞增的機制。
實踐
示例分析
要對問題進行結構化抽象，需要先提取問題的結構特征。可以分別從數據結構化和操作結構化兩個角度來思考。
分頁
比如分頁功能是大多數信息系統管理的必備功能之一。怎么實現一個通用的分頁功能呢 ？
從數據結構化來思考，其結構要素為：偏移量、頁大小、起始和結束位置。分頁本身和獲取何種對象無關。
從操作結構化來思考，其結構要素為：1. select columns from table where condition limit offset, size ; 2. count distinct(id) from table where condition limit offset, size .
columns , table, condition 都是可以根據具體業務來動態生成的，而整個 SQL 的骨架是固定的。table 不一定指 DB , select , count 也不一定是 DB 的 sql ，它只是表示在指定搜索條件下進行對象選擇與統計的操作語義。columns , table, cond 的動態生成，可以使用泛型和回調函數來傳入和處理。
限購
限購，是指定時間內，指定 key 的實體允許通過的許可數量。與限流是同一類結構化抽象。許可數量，是一個全局性約束。
假設去掉“指定時間”的約束，只限制許可數量， 其結構化抽象是，dec if total - count(key) > 0. 并發的場景下，total - count(key) > 0 的值需要進行全局同步。
如果加上“指定時間”的約束，還需要考慮高并發場景下 dec if total - count(key) > 0 的操作耗時。如果指定時間內不允許超過限購數量（強約束），則必須對 dec if total - count(key) > 0 進行加鎖，吞吐量取決于操作耗時而不是指定的限購數；如果指定時間內可允許暫時地超過限購數量（弱約束），則可參考限流算法。
數據同步
數據同步的結構化抽象是，將源存儲 S1, S2, ..., Sn 的數據復制到目標存儲 D 。
數據同步分為兩種不同的場景，有實時同步和離線同步。實時同步對數據延遲性容忍非常低，離線同步則要求更快的吞吐量。
實時同步通常采用流式同步，通過接收消息流來處理。操作的結構化是，Receiver (msg) -> Format(msg) -> Save for each msg . msg 是源存儲中的一條數據或一個單位數據集。
離線同步通常采用批量處理，實現方式是批量獲取數據并批量格式化后存儲。操作的結構化是，Divide(S) into N part(S) ; Select part(S) Then Format part(S) and Save for each part(S) 。可以根據業務唯一 ID 實現一個通用的 Divide 算法。
離線同步要注意 format 的超時和健壯性處理，記錄下異常以便重試，同時不因單個數據處理失敗而中斷整體流程；流式同步則要注意控制好并發情形下的準確性。由于對吞吐量要求比較高，往往采用樂觀鎖的方式，找到某種能夠控制全局版本號單調遞增的機制，或者盡量避免“多表同步到單表”的場景【并發場景下會帶來更多復雜性】。
積累抽象
在實際工作中，可以反思和提煉設計中所用到的結構化抽象。如果現有的結構化抽象及組合難以解決問題，是否需要新的結構化抽象 ？創建新的結構化抽象，并使之與已有的進行組合和集成。
規模化挑戰
如果程序媛猿面對的是幾萬的數據量，那是可以夜夜笙歌的。然而，現實情況是，面對的是億級以上規模的數據量，且數據量仍然在指數級增長。為了人類社會的無理性發展，程序媛猿們真是費盡了心思花白了頭。
為了應對億級規模的數據量，并發、分布式等方案層出不窮，結合變化的業務場景，又衍生出更多的撓人燒腦的復雜問題。如何應對呢？
規模化挑戰的結構化抽象是，在指定時間內，每秒處理的請求/單位數據集的吞吐量，處理一個請求或單位數據集的平均響應時間，以及在流量劇烈變化時的彈性擴展能力。
并發
并發和并行機制取代了串行機制。單CPU和單機的性能基本抵達瓶頸，只能從多核CPU和多機上想辦法。將要處理的數據量分解為多個相互獨立的子數據集，并在不同的執行實體里相互獨立地執行。比如線程池，Fork/Join ， Map-Reduce 執行模型。并發和并行雖然解決了單機性能不足的問題，卻引發了更多的問題。
同步
有了并發執行之后，由于有些資源是共享的，而一些熱點數據往往被多個執行實體同時讀取和修改，又產生了競爭問題。為了解決競爭，引入了同步機制。大量對同一資源、數據的操作進行同步，引起性能問題。
緩存
對于熱點數據的讀取和操作，通過“空間換時間”的策略，使用緩存來提升性能，降低對源存儲的訪問壓力。
限流
由于允許并發請求進入，則必須應對瞬間的峰值流量（可見世態）。限流必須有度，不能因噎廢食。需要對系統承載的負荷及極限負荷進行測量，根據測量值來確定一個可動態調整的限流值。極限負荷測量即是壓測。
降級
由于業務特性的不同，環境的不穩定波動，以及采用方案的局限性，依賴服務有可能出現部分失敗，對于調用極其頻繁的服務來說，依賴服務的少許失敗可能導致上層的雪崩效應。因此在依賴服務出現問題時，必須進行適當的降級熔斷。
測量
為了避免大流量或大數據結構導致軟件運行出現問題，降低維護成本，不能僅僅停留在定性分析上，還要進行量化。需要對系統進行仔細的測量。服務接口的 RT 和 吞吐量 如何 ？存取操作耗時如何 ？消息處理耗時和吞吐量如何 ？內存占用如何 ？大數據對象占用內存多大 ？能夠承載的極限流量有多大 ？能夠承載的極限對象大小是多大 ？指定時間段的失敗數和失敗率有多大 ？
集群
若以單機視角去考慮問題，就會殫精竭慮地在“并發、同步、緩存、限流、降級”等上做到極致，就像在單核時代將CPU主頻做到極致一樣。然而，即使做到極致，為了峰值流量所構建的機器資源，在平均流量場景下會造成很大的浪費；并且，很難預估峰值流量會在什么時候來到。如果有一個超級大的聚合的池化資源，總可以提供足夠強大而彈性的CPU計算能力、內存能力、磁盤空間，那么以上規模化引起的問題也將迎刃而解。這個超級大的聚合的池化資源，就來自于構成集群的分布式系統的資源虛擬化后的能力，即云計算能力。
可視化
為了從數據集中發現整體性的規律和趨勢，通過將大量數據集進行可視化，擁有一個簡明的全局視角。
AI
以數據為基礎，以規則集為準繩，訓練機器通過基本的規則集與數據的計算而獲得某種“學習”能力，從而能夠分析更多的數據集，調整現實活動和方式，獲得人力所無法得到的見解和經濟效益。
經驗與洞見
招聘或找工作的人，常常說要“工作經驗多少年才行”，然而，在軟件設計中，卻容易“有經驗而無洞見”。
經驗是什么？經驗是工作中遇到的問題及解決方案。有些問題，只有在規模達到足夠大的時候才會出現；而大多數問題，只要根據原理就能推導出來。在軟件世界里，并沒有一成不變的最佳經驗。
洞見是什么？洞見來自于究根追源，從最基本的公理進行推導得出定理和定律，從而能夠預知問題。邏輯，本質上是一種數學結構，而數學正是能夠進行推導的嚴密思維體系。
軟件設計的洞見來自哪里 ？究根追源，軟件邏輯建始于兩條公理：
1 + 1 = 2
機器的字長有限，內存有限；執行指令需要 CPU 時鐘周期
幾乎所有軟件問題都是這兩個基本要素的組合和疊加而產生的。軟件設計崇尚“自頂向下”的方式，然而，要獲得洞見，卻需要“自底向上”的思考和推導，通過多個層次的結構化抽象來建立。萬變不離其宗。
注意到，第二條公理描述了現實系統的局限性。局限性，正是經驗的用武之地。
在初期，可以 80% 依據經驗，20% 依據原理；而在后期，則應該 80% 依靠原理，20% 依靠經驗。那么，不依靠經驗應該怎么做呢 ？舉一個 API 調用的例子。可以測量這個 API 的平均耗時，耗時分布，大體了解這個 API 的對外輸出指標。API 超時是因為什么呢 ？可能是網絡環境波動導致。很難通過設計和開發優化環境的波動。如果不是，從 API 的實現層面來說，很可能是因為并發的大流量導致了競爭加劇，線程死鎖或者大量線程阻塞。API 超時又會導致多個子系統間數據不一致。可見，并發與大流量，是系統必須要面對的“對手”。并發與大流量一定需要通過工作經驗來獲得嗎？非也。并發與大流量的場景是可以模擬的。
可以通過原理推導，結合實驗，來模擬各種現實場景，測量數據， 并制訂應對方案。?這是細功夫，也是洞見的產生之源。
小結
本文闡述了軟件設計中的結構化抽象的理念及實踐方法，涉及設計與開發、設計模式、技術機制、示例分析、規模化挑戰，及設計中的經驗與洞見。結構化，即是將邏輯進行抽象、提煉、分離、聚合，構建成更加縝密、動態、彈性的結構流。
做軟件設計，要同時看到骷髏與美人。論理，要看到骷髏；論情，要看到美人。理，即是結構化抽象。
原文鏈接：https://www.cnblogs.com/lovesqcc/p/11220727.html
.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總?http://www.csharpkit.com?
總結
以上是生活随笔為你收集整理的软件设计的第一性原理：结构化抽象的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 依赖注入在 dotnet core 中实
- 下一篇： 【学习笔记】Docker - 01. D