Building Evolutionary Architectures : Support Constant Change 心得歸納3
演進式架構可以解決"如何利用它們來設計可演進軟體"
演進式架構的定義裡面有"漸進變更"
例如書中範例widget銷售商PenultimateWidgets有一服務網頁實踐微服務
這些微服務建立一個無共享(share nothing)架構,以消除技術耦合,促進粒狀(granular)
但是所有為服務都佈署在單獨的容器中,以簡化運維
其中有一個共用的星級評分服務釋出新版本提供半星評分:
使用評分的服務部用立刻切換使用改良後的半星評分服務
而DevOps方法監視功能服務的路由發現特定時間內舊評分服務沒人用時
就會將該服務自動踢出生態系統
如上在生產環境透過託管不同版本服務,並用路由來控制訪問
並且不強迫呼叫方立刻升級到新服務
建構元素
- 架構師經常錯誤地將軟體架構視為必須解決的方程式
- 然而軟體的東西不是靜態的,而是持續改變的
- 當架構置入生產環境,並根據需求升級時,就進入到4D世界了
- 架構不是靜態等式,而是持續進行中的過程快照
架構是抽象的,直到它被運作化之後,才會變成活生生的東西
- 架構除非在設計、實作、升級、不可避免的變更取得成功,否則都不能認定架構具備長期生存能力,可能還要承受初期未知之未知事
可測試
- 可測試性是軟體架構經常被忽視的"-ility"之一,它的意思是,能否用自動化測試來驗證架構的準確性
- 使用部署管道,架構師可以定義執行哪個適應度函數,以及何時,多常執行
部署管道
- 持續交付介紹了部署管道機制,由部署管道來"監聽"變更
- 持續交付實踐法鼓勵我們將部署管道當成自動執行常見工作的機制,例如測試,機器供應,部署等
- 持續整合是敏捷專案中註明的工程實踐法,它鼓勵開發人員盡早,盡可能頻繁地進行整合
- 典型的部署管道會自動建立部署環境(Docker,Puppet,Chef等)
- 要在持續部署和階段性釋出之間取得平衡,常見的做法是使用功能開關
- 使用功能開關來建立新功能也可以讓你在生產環境中執行QA工作
結合適應度函數種類
- 各種適應度函數經常是彼此相關的
- 原子+觸發式:單元與功能測試
- 整體+觸發式:整體、觸發式式硬度函數會被當成整合測試的一部分
- 原子+持續型:持續型測試式做為架構的一部分運行的
- 整體+持續型:整體且持續型的適應度函數會一直測試系統的多個元件
互相衝突的目標
- 敏捷軟體開發程序告訴我們,開發人員發現問題的速度越快,修復問題所需要的工作就越少.考慮軟體架構所有維度可以讓你在早期發現跨維度且互相衝突的目標
- 例如開發者希望提供最積極的變更節奏,但是DBA比較關心穩定性
- i.e.技術架構和資料架構的演進目標是互相衝突的
案例研究:PenultimateWidgets的發票開立服務加入以下適應度函數
- 可擴展性
- 與其他服務整合
- 安全性
- 可稽核性
案例研究:PenultimateWidgets應用程式移植到web,哪些該移?
- 架構師問商業分析人員目前最流行的功能是什麼,他們不知道!
- 開發人員釋出就應用程式的新版本,並啟用log功能,以追蹤用戶實際使用的選單功能才確定
個人心得:
其實整段就是描述架構的調整與演進是可以動態平衡(化學的描述方式)
一杯水溶液內加入某項會融化的物質(架構調整或升級,甚至是如上的星級評分服務呼叫的版本變更)
該物質會慢慢地擴散至整杯水溶液,達到平衡
金融有些案例在搞核心系統轉換太過急促,導致系統轉換後問題頻頻
強硬的調整架構,成本往往也是巨大的
提供一個循序漸進的,有彈性的變更
甚至可以說是前面CH2提到的有意引導的架構變更會更好
引導機制的演進式架構充其量只是一種簡單的反應式架構
也許金融業在跟風採納新技術而沒有考慮現行狀況(需求,規劃,法規,人力市場等)
都漸漸造就了金融業常常在不同等待被淘汰的系統上遷移罷了!?
