[架構之路-52]：架構師 - 嵌入式軟體常見難查問題與解決辦法大總結-1-架構設計不合理問題

目錄

​​第1章 問題描述​​

​​第2章 問題分析：好的軟體架構的特點​​

​​2.1 性能：承載力​​

​​2.2 可用性、易用性​​

​​2.3 擴充性​​

​​2.4 伸縮性​​

​​2.5 可靠性、容錯性​​

​​2.6 安全性、魯棒性​​

​​第3章 問題分析：影響軟體系統複雜性的因素​​

​​第4章 如何設計好的軟體架構​​

​​4.1 架構師必須熟悉業務​​

​​4.2 借鑒業内成熟的架構​​

​​4.3 采用設計子產品來設計軟體架構，包括系統架構和子產品内部的架構​​

​​4.4 用UML統一模組化語言為系統建立模型​​

​​4.5 合理的橫向和縱向切分​​

​​4.6 按照樹形結構組織、逐漸細化​​

​​4.7 降低子產品之間的耦合度​​

​​4.8 降低子產品與子產品之間通信​​

​​4.9 不定期根據業務的需求重構和演進架構​​

第1章 問題描述

在工程實際中，有時候為了趕項目進度、趕市場進度，開發目标軟體的首要目标就是以最快的時間，建構一個符合客戶需求的軟硬體系統，“快”為第一要素，是短期名額，然後像“适應性”、“彈性”、“可複用性”等長期名額比忽略，導緻後期，無論是産品的維護、bug的修複、新功能的增加都非常困難，後期，一個小小的業務需求，都會牽一發而動全身，需要大量的時間與精力，甚至一個小小的故障修複，引入更多的問題。整個目标系統變得越來越僵化，包袱越來越沉重。最簡單的變更或“很小的”缺陷修複需要花費大量的時間。管理軟體的開發周期越來越難難，越來越不可控，管理層對開發團隊不能滿足業務目标感到越來越沮喪。

第2章 問題分析：好的軟體架構的特點

2.1 性能：承載力

比如一棟房子，能承載多少人，能做多少個房間，是客戶比較關注的問題。

從軟體架構方面來說，一個軟體架構能承載多少個業務系統或功能系統，能承載多少代碼行數，在達到規定的代碼量時，是否還能有效正常的運作，是程式員和客戶都關注的問題。當然，這需要架構師一開始架構系統的時候，就需要有一定的預見性。

對于伺服器來說，伺服器的架構能承載多少人同時通路，能承載的日均通路量是多少，這就是它承載力的展現。

對于用戶端來說，它能顯示多少個UI功能，可以同時渲染多少個模型，分辨率可以達到多少，則是它的承載力展現。

2.2 可用性、易用性

易用性其實很簡單，就是你這個産品設計的好不好用，是不是友善使用，這個可能是很多架構師會忽略的一點，因為大部分架構師隻是一個程式員。程式員很少會從客戶的角度去想問題，是以就會導緻設計出來的東西不符合客戶的使用習慣。易用性也決定了軟體的整體開發效率，因為一個好的架構，會讓團隊成員容易上手，子系統容易對接，開發效率高，各子產品和各系統的編寫隻需要關注系統的設計和編碼工作，其他子產品通信方面的事情，架構可以提供很好的相容。一味地追求最新的、最多功能的軟體特性的架構是危險的！！！除了技術炫技之外，對整個團隊沒有太多的好處，對産品的演進也沒有太多的好處。它會讓産品陷入不穩定、不确定、讓團隊不斷适應無用的新變動。

2.3 擴充性

 如果一棟房子隻能住人，不能放其他的東西，那麼這個房子的設計用途就太單一了，大的家具不能放、長的家電不能放、特殊的水電不能裝，那這個房子肯定沒人買。架構就是要适應不同類型的需求，可添加不同類型的系統、不同功能的子系統，是非常有必要的。

軟體架構也是這樣，要具備更多的功能就要具備更高的擴充性。可擴充性的關鍵就在于，在添加新系統新功能的時候，會不會影響其他系統，添加這個新系統的代價大不大，會不會導緻系統整體性能問題。如果添加一個新系統，導緻其他系統使用有問題，那麼這個架構的可擴充性就很差。

2.4 伸縮性

什麼是伸縮性？其實就是你設計的這個方案或系統是否可以根據需求适配不同數量的功能或子系統，比如一棟房子由于住的人比較多，它的架構是否可以分割成多個房間，當人數變少的時候，能不能根據根據需求把多個房間合并成一個大單間? 這就是可伸縮性

在我們設計的軟體系統中，架構的可伸縮性決定了架構的可适配性，比如，當這個系統使用人數較少的時候，是否支援減少一些伺服器來支撐服務端的運作，當系統使用的人數較多時，通路量較大時是否支援添加伺服器來增強系統的支援。

2.5 可靠性、容錯性

房子也會有損壞的時候，同樣也會出現某個地方做工不好，導緻使用的時候出現各種破損，我們保證不了完全沒有問題，但是需要保證它不會因為一點小問題，出現倒塌的情況。

軟體架構也是這樣，如果軟體中某個系統出現了一點小BUG導緻整個系統使用不了，那這個架構容錯性就很差，軟體中的一些BUG很常見，我們無法避免，但是我們應盡量保證這個BUG的影響範圍最小。同時，若出現系統無法使用的情況，應該有備份方案，比如自動啟動或者自動儲存資料等功能，也應該能夠讓開發人員及時知道問題的發生，以及問題所在的位置并記錄錯誤資訊。

2.6 安全性、魯棒性

魯棒性是Robust的音譯，也就是健壯和強壯的意思。它也是在異常和危險情況下系統生存的能力。比如說，計算機​​軟體​​​在輸入錯誤、磁盤故障、網絡過載或有意攻擊情況下，能否不當機、不崩潰，就是該軟體的魯棒性。所謂“魯棒性”，也是指控制系統在一定（結構，大小）的參數​​攝動​​下，維持其它某些性能的特性。根據對性能的不同定義，可分為穩定魯棒性和性能魯棒性。

第3章 問題分析：影響軟體系統複雜性的因素

 系統的架構是從多個次元展現的，影響系統架構複雜性的因素包含：

• 軟體的靜态分層的數量 （靜态）
• 協定包封裝的靜态資料結構的複雜程度 （靜态）
• 軟體的功能子產品的數量 （靜态）
• 軟體的程序的數量 （靜态）
• 軟體的線程的數量 （靜态）
• 算法的複雜程度 （過程）
• 源代碼的行數（靜态）
• 狀态機的數量 （動态）
• 狀态機中狀态的數量 （動态）
• 線程/程序之間的互動路徑
• 業務場景的數量 （動态）
• 軟體時序的數量 （動态）
• 時序圖中消息的數量 （動态）

第4章 如何設計好的軟體架構

4.1 架構師必須熟悉業務

軟體系統是為業務服務的，業務才是“目的”， 軟體系統本身并不是目的，軟體系統是為了達成業務系統目标的手段和方法。有很多架構師為了軟體架構而軟體架構，甚至不考慮自身業務的需求，直接照搬所謂的“最新的“、“成功的”、“業界最優的”軟體架構。

• 适應目前的業務需求是基礎，不需要過多的考慮未來五年、十年的業務需求。适合的才是最好的。
• 充分考慮和預測未來的業務的擴充：要根據業務的擴充性，來設計軟體的擴充性。如果可預見性，未來沒有沒有擴充重大的新業務的需求，那麼相應的軟體架構就沒有必要采用高擴充的軟體架構。比如嵌入式的傳感器，就沒有必要把“雲”計算、“雲”原生的軟體架構放到嵌入式裝置中。當然，這是一個極端的例子，但可以充分的說明，軟體架構必須為業務服務的核心思想。是以，軟體架構師，必須熟悉業務，不熟悉目前軟體業務和未來業務的擴充的架構師是很難設計出好的軟體架構的。

4.2 借鑒業内成熟的架構

不照搬，并不意味着不要借鑒。借鑒業内成熟的軟、硬體架構是相對穩妥、高效、安全的做法。

無論是軟體、還是硬體都可以業内的架構為基礎、為藍本、為基線。然後根據自身業務的特點，進行适配、裁剪和增加新的功能。

熟悉業内正常的、成熟的、最新的軟體架構是架構師的一項基本功。

熟悉這些架構，并不是意味着，必須立即在目标系統中實施這些軟體架構。

備注：

在移動通信領域，3GPP已經定義整個網絡的網絡架構的标準，網絡裝置商以3GPP定義的網絡架構來實施。架構師一個重要的職責是了解業務需求，并把業務需求映射到産品的軟體架構中。另一方面，3GPP雖然定義裝置之間的接口，但并沒有定義裝置内部子產品之間的接口，軟體架構師還需要定義裝置内部軟體的子產品以及子產品之間的消息接口、消息互動流程等。

4.3 采用設計子產品來設計軟體架構，包括系統架構和子產品内部的架構

設計模式（Design pattern）代表了最佳的實踐，設計模式是軟體開發人員在軟體開發過程中面臨的一般問題的解決方案。這些解決方案是衆多軟體開發人員經過相當長的一段時間的試驗和錯誤總結出來的。

設計模式是一套被反複使用的、多數人知曉的、經過分類編目的、代碼設計經驗的總結。使用設計模式是為了重用代碼、讓代碼更容易被他人了解、保證代碼可靠性。 毫無疑問，設計模式于己于他人于系統都是多赢的，設計模式使代碼編制真正工程化，設計模式是軟體工程的基石，如同大廈的一塊塊磚石一樣。項目中合理地運用設計模式可以完美地解決很多問題，每種模式在現實中都有相應的原理來與之對應，每種模式都描述了一個在我們周圍不斷重複發生的問題，以及該問題的核心解決方案，這也是設計模式能被廣泛應用的原因。

用設計模式建構一個新系統、建構一個新的軟體子產品的時候，短期會讓人感覺有多此一舉的味道，有脫褲子放屁的感覺，當中長期來看，設計模式能夠克服“壞”架構的特征。

設計模式已經經曆了很長一段時間的發展，它們提供了軟體開發過程中面臨的一般問題的最佳解決方案。學習這些模式有助于經驗不足的開發人員通過一種簡單快捷的方式來學習軟體設計。

設計子產品通常被有經驗的面向對象的軟體開發人員所采用。

4.4 用UML統一模組化語言為系統建立模型

在正式編碼前，為系統建立業務模型、軟體層次模型、軟體狀态機模型、軟體時序模型，而不是一上來就陷入細節，進行軟體的編碼與實作。

UML模組化語言提供了建構一個軟體系統，通用的思想、方法、工具、模型。

UML能夠幫助架構師、軟體設計師快速建構一個正常的軟體系統。

UML2.0一共有13種圖形（UML1.5定義了9種，2.0增加了4種）

• 用例圖：從使用者角度描述系統功能。
• 類圖：描述系統中類的靜态結構。
• 對象圖：系統中的多個對象在某一時刻的狀态。
• 狀态圖：是描述狀态到狀态控制流，常用于動态特性模組化
• 活動圖：描述了業務實作用例的工作流程
• 順序圖：對象之間的動态合作關系，強調對象發送消息的順序，同時顯示對象之間的互動
• 協作圖：描述對象之間的協助關系
• 構件圖：一種特殊的UML圖來描述系統的靜态實作視圖
• 部署圖：定義系統中軟硬體的實體體系結構
• 包圖：對構成系統的模型元素進行分組整理的圖
• 組合結構圖：表示類或者建構内部結構的圖
• 互動概覽圖：用活動圖來表示多個互動之間的控制關系的圖

4.5 合理的橫向和縱向切分

橫向切分：軟體分層、資料包的封裝、層次關系。

• 如，移動通信：RF/L1/L2/L3
• 如,  資料通信：PHY/MAC/IP/TCP/應用層

縱向切分：

• 根據業務處理流程的環節縱向切分，不同的環節為不同的子產品。
• 根據業務的場景縱向切分，不同的業務場景類型，為不同的子產品，如，4G/5G L3的功能：移動性管理、無線資源管理、小區建立等，都是按照業務場景進行功能切分。

備注：

軟體的功能切分，以适用業務特征為基本原則。

4.6 按照樹形結構組織、逐漸細化

按照樹形的方式組織軟體系統，是目前最符合大自然的組織方式。

Linux系統的裝置、檔案也都是按照樹型方式進行組織。

國家、社會的組織架構也都采用樹形的方式組織。

​​[項目管理-25]：高效溝通的利器，結構思考力與樹形結構化表達_文火冰糖的矽基工坊的部落格-CSDN部落格​​

4.7 降低子產品之間的耦合度

耦合性（英語：Coupling，dependency，或稱耦合力或耦合度）是一種​​軟體度量​​​，是指一程式中，​​子產品​​及子產品之間資訊或參數依賴的程度。

​​内聚性​​是一個和耦合性相對的概念，一般而言低耦合性代表高内聚性，反之亦然。

4.8 降低子產品與子產品之間通信

一個軟體系統，子產品與子產品之間的通信，構成了一個内部的通信網。

4.9 不定期根據業務的需求重構和演進架構

• 架構不能一成不變，架構要随着業務需求的演進而演進，一層不變的架構是危險的，總有一天，架構稱為整個産品業務演進的最嚴重的制約因素。
• 除非是新産品，新軟體系統，否則不能采用颠覆性演變，每個軟體釋出版本，都要根據未來規劃的産品特征，進行預先的架構演進，為後續産品的新特征提前打下架構性基礎。