Building Evolutionary Architectures : Support Constant Change 心得歸納2

CH.2 適應度函數

ZONGRU Li
Sep 19, 2022

架構師會定義一個適應度函數解釋"更好",是什麼意思,並評估何時達到目標

架構的適應度函數可以客觀地評估架構特性的完整性

適應度函數可以保護系統的各種架構特性

架構的適應度函數是"-ility"的保護機制

例如有的系統需要高度安全性(其中一個-ility)

或是大的傳輸量(-ility),或是低延遲(-ility)

亦可將系統範圍的適應度函數看成一組適應度函數

系統絕對不是它的零件的總和,而是各個零件相互作用之下的產物

沒有引導機制的演進式架構充其量只是一種簡單的反應式架構

什麼是適應度函數?

  • 演進式架構的適應度函數有可能無法在軟體中實現(如法規要求人工處理)
  • 如前一章所提,架構是由不同維度組成的,包含性能,可靠性,安全性,可運維性,程式編寫標準和整合等需求
  • 會需要適應度函數來代表每一種需求
  • 例如迴路(cyclomatic)複雜度是常見的程式碼指標,用以評估函數或方法的複雜度,架構師可以訂上限值,並在CI中執行UT確保
  • 考量一個請求事100ms內回應所有的服務呼叫,寫出一個測試(即"適應度函數"來衡量服務請求)

分類

  • 適應度函數可根據範圍、頻率、動態...等其他因素分門別類

原子vs. 整理

  • 原子適應度函數是對單一背景執行的適應度函數,例如單元測試(UT)
  • 但是僅限"有驗證架構特性的UT"才能當適應度函數
  • 整體適應度函數是對著共同的背景運行的例如安全性、可擴展性
  • 其中安全性適應度函數有一重要檢查項目是資料的過時性(staleness)
  • 可擴展性測試有一個重要項目是"一定的等待時間內"
  • 為了可擴展性,當開發人員透過開啟"快取"讓原子化的可擴展性適應度函數通過
  • 但有可能只有在未打開"快取"才能讓安全性適應度函數通過等相反的狀況
  • 對於架構原素組合,架構師可利用整體適應度函數選擇性或有優先順序地測試重要的互動

觸發式vs.持續型

  • 觸發式適應度函數是根據特定事件運行,例如UT、功能測試、行為驅動開發(BDD)等
  • 持續型適應度函數相關的測試不按時間表運行,而是對架構的各個層面(如交易速度)不斷執行驗證
  • 監視驅動開發(MDD)透過監視器來評估技術和商務的健康狀況即是種持續型適應度函數

靜態vs.動態

  • 靜態適應度函數有一固定結果,例如UT的通過/失敗
  • 甚至乃是基礎程式的方法平均迴路複雜度定義一個可接受範圍
  • 動態適應度函數則是移動式定義,例如大規模運行時,架構師可以接受較低的性能指標(我自己認為簡單例子就是online服務(要快)/批次服務(可以慢點))

自動化vs.人工

  • 在DevOps觀念文化盛行下,許多自動化在過去被認為不可能實現,現在都實現了
  • 但是仍有某些關鍵維度會阻礙自動化,如法律需求
  • 我自己的經驗上就是金管會/金檢單位/稽核單位/資安(或是說資安顧問建議下的資安系統卻不熟公司系統的工程師)/決策層等
  • 大量維持在人工程序上

時間性的

  • Ruby on Rails常有開發者搶先在下個版本前加入誘人的功能,進而導致專案升級時後端的接口與真正的版本不相容
  • 開發者可以用break upon upgrade(在中斷時升級)測試使用後端接口的功能包起來,以便強制重新評估

有意勝於應急

  • 有些適應度函數只在系統開發過程中出現,無法一開始就明確定義出來
  • 後面CH6會討論到未知之未知問題

領域專屬的

  • 有些架構有特定關注點,例如特殊的安全性或法規需求
  • 進而形成設計特定的、持續的、整理的適應度函數對安全性進行壓力測試
  • 也就是這些問題領域會形成驅動因素
  • 架構師要找出這些驅動因素讓它成為適應度函數,以確保重要特性部會隨時間劣化(後面CH3會有一些例子)

盡早找出適應度函數

  • 盡早確定系統的適應度函數才容易比較各種架構特性
  • 未確認適應度函數的團隊會有以下風險:
  • 1.做出錯誤的設計決策,最終導致軟體在環境中故障
  • 2.在設計時做出花費時間和金錢且非必要的選擇
  • 3.無法在未來的環境發生變化時輕鬆地演進系統
  • 另外適應度函數還可以分為以下三大類:
  • 1.關鍵的(例如銀行的應用程式而言,性能和彈性式關鍵維度)
  • 2.有關的(例如程式碼品質有關的指標很重要,但不是關鍵因素)
  • 3.無關的(例如從設計到實現的週期時間,這種在流程指標可能很重要,但是跟架構無關,它不需要適應度函數)
  • 以上透過將適應度函數分門別類有助於優化設計決策

複審適應度函數

  • 因應重大市場或客戶增長等,每年至少複審適應度函數一次,執行以下:
  • 1.審查既有的適應度函數
  • 2.檢查當前適應度函數的關聯性
  • 3.確定每個適應度函數的規模或大小的變化
  • 4.確定是否有更好的方法來測量或測試系統的適應度函數
  • 5.發現系統需要支援的新適應度函數

我們會希望架構能夠已被引導的方式演進,用以限制架構的各個層面

在以前經驗上應該要在討論做核心轉型前

把上面許多適應度函數及其分類先談出來才對

--

--

ZONGRU Li
ZONGRU Li

Written by ZONGRU Li

2022/11/17 開源部分個人筆記給LINE "Java程式語言討論區"社群,希望能對社群的技術學習做一點點貢獻.(掩面....記得退訂閱!

No responses yet