第5章 運作架構設計

整體感覺這章沒有講太多東西

運作架構關注的是系統如何運作，是同步還是異步，是并發還是串行，關注運作中的各個對象如何互動，狀态如何轉換，關注那些安全必性、可靠性、可伸縮性等品質要求，以及響應時間、吞吐量等性能要求。

運作架構關注的不再是全局，而是局部，是系統中那些關鍵點與難點。

1、如何開展對非功能需求的分析與設計？

答：采用“屬性à場景à決策”的過程，一步一步進行架構設計。

（1）屬性：就是整個系統應當遵循的品質屬性。譬如，整個系統應當達到的安全性、可靠性，應當達到多少秒内的響應時間，以及多大的高并發與吞吐量等。在制訂非功能性需求時，每一項必須有明确的可驗證的标準。

（2）場景：就是拿着非功能性需求中的每一個品質屬性，到整個項目中去掃描，哪些功能達到要求，哪些功能不能達到。進而把整個項目對品質屬性的要求變成某些關鍵場景對品質屬性的設計。架構師會依據品質屬性的要求，對這些場景進行技術選型，制訂各種文豪發，然後依據方案設計編碼，最後搭建實驗環境進行測試驗證，通過不斷地優化最終達到品質屬性的要求。

（3）決策：在這個階段，架構師要決策的，就是他在該應用場景中進行的設計是不是适用于其他的各個場景。

架構設計是在對系統的功能性需求進行全面梳理，總結歸納的基礎上制訂的，是對各個功能共性的設計。

運作架構的設計，不是對開發架構的否定與替換，而是進一步的調整與優化。

2、非功能性需求有哪些内容？

答：簡單可歸納為“URPS+”，即可用性（Usability）、可靠性（Reliability）、性能（Performance）、可支援性（Supportability）以及其他（+）。

（1）可用性

是一個非常寬泛的概念，泛指那些能讓使用者順利使用該系統的名額，包括易用性（易操作、易了解）、準确性、安全性（系統安全、資料安全、權限體系、通路限制等）、相容性（伺服器、用戶端的相容程度），等等。

（2）可靠性

就是系統可以可靠運作不當機，包括系統成熟度（資料吞吐量、并發使用者量、連續不停機性能等）、資料容錯度、系統易恢複性等。

（3）性能

是非功能性需求分析中非常重要的内容。功能性需求與部署方式是對性能影響最大的兩個方面，必須在該階段就想清楚，解決掉。

功能與性能往往是沖突的，保證了性能就必須要犧牲功能。

（4）可支援性

就是軟體的可維護性、易變更性。可支援性能于客戶是透明而不可見的，是以客戶通常不關心這個。

3、什麼是恰如其分的架構設計？

答：

（1）目前的架構設計必須滿足目前的所有需求

  利用“5視圖法”進行架構設計，先全面梳理目前的需求，即要覆寫功能性需求，也要覆寫非功能性需求，即包含軟體設計，也包含硬體部署，把來自方方面面的問題都囊括，不遺漏任何一個設計風險。在這樣的基礎上設計出來的架構就是高品質的。

（2）沒有過度設計

      所謂的“過度設計”，就是脫離了目前的需求，試圖去滿足未來的需求。

不過度設計，并不意味着架構師完全不考慮未來。那些近期可以預見的變化還是可以預先做一些設計的，但那些自己都不确定未來會不會發生的變化，不做也罷。

4、什麼是好的架構？

答：

（1）恰如其分的架構

  滿足目前的所有需求；沒有過度設計

（2）不停衍變的架構

好的架構其實隻能适應一段時間的變更，隻有不斷疊代、重構、衍變，适應業務的變化的架構才能稱之為好的架構

5、什麼是意圖架構？

答：不去規劃一成不變的未來，而是規劃可以預測的目前，并随時做好應對未來變化的準備。在這種思路指導下的架構就是“意圖架構（Intentional Architecture）”

意圖架構，就是根據近期需求變更的意圖，去規劃近期的技術架構，使其剛剛滿足近期的需求。未來當需求變化時，再根據未來需求變更的意圖，去規劃未來一段時間的技術架構，使期剛剛滿足未來這段時間的需求。也就是說，意圖架構永遠規劃的是近期的架構，能夠剛剛滿足近期的需求，并随時做好應對未來變化的準備。這也就是恰如其分的架構設計。

6、什麼是浮現式設計？

答：團隊全部圍繞着使用者需求，用很短的時間去做增量

7、什麼是使能故事？

答：“使能故事（Enabler Story）”是架構師實踐“意圖架構”的落地實踐。

“使能故事”是相對于“使用者故事（User Story）”提出的；所謂“使能”就是使自身的能力得到提高，包括：

（1）更深層次地了解使用者業務，探索使用者需求，給使用者更好體驗；

（2）優化即有的代碼，提高代碼品質，以降低日後變更的成本；

（3）調整即有的技術架構，以支援未來更多的功能，更快更好地完成開發；

（4）将現有功能算法下沉，建構更加強大的技術中台，以支援未來的發展。

雖然使能故事不能直接産生使用者價值，卻可以有效地提升無未來完成使用者故事的速度與能力，進而間接地提高生産力，産生更多使用者價值。

注意：長周期的大重構，不如短周期的小重構。

8、什麼是架構跑道？

答：即要滿足未來一段時間的需求，又不能規劃得太遠，進而産生浪費，這就是“架構跑道”的設計思路。（意圖架構、架構跑道感覺都是一回事）

9、針對老舊系統架構師是如何架構的？

答：

（1）縫縫補補又三年

（2）走一步推兩步，淺嘗辄止

（3）洗心革面，重頭再來

10、什麼是演化式技術改造？

答：演化式技術改造就是利用重構在原有的系統上逐漸改造。每一步重構都保持功能不變，隻調整程式的内部結構。通過内部程式結構的優化，業務代碼逐漸與各個層次、各種技術解耦。

演化式技術改造的目标是實作業務代碼與技術架構的解耦，使系統适于進行技術改造，而采用的方法就是重構。

11、軟體重構

答：軟體重構，就是在不改變原有系統外部行為的基礎上，調整它的内部結構，使其更加易于閱讀、維護和變更。

從軟體重構的定義中，我們可以總出以下幾個特點：

（1）不改變系統原有的功能

（2）調整程式内部結構

（3）易于閱讀、維護和變更

注：幾個簡易的重構方法

1）抽取方法  2）抽取類  3）抽取接口

12、演化式技術改造的執行過程是什麼？

答：

（1）通過抽取方法，将各業務子產品中對底層架構進行調用的代碼從其他業務代碼中剝離出來，放到單獨的方法中，但代碼還是在各業務子產品中

（2）通過抽取類，将以上這些方法從各業務類中抽取出來，形成接口層單獨的類，與業務代碼分離

（3）通過抽取接口，将各業務類對接口層類的調用，變成對接口層接口的調用，進而實作業務代碼與接口層的解耦

（4）通過對所有接口層的接口進行總結歸納，逐漸合并，抽取共性，保留個性，逐漸形成各業務子產品對一些公用接口的調用