『網際網路架構』軟體架構-軟體系統設計（一）

開發人員看文件的時候，首先就要看體系結構。它是軟體系統最本質的東西，主體的形態，人的骨架就是體系結構。如果你設計的體系結構是個大猩猩，後期不管如何進化，如何發展，它始終無法變成一個人，只能是個猩猩。比如蓋房子，可能蓋高層，可能蓋土房，可能蓋平房，或者是窯洞，一開始就想蓋高層，它需要的材料，地基深度什麼都是不一樣的。所以體系結構就需要了解軟體設計的本質。也可以說架構。

2. 應當設計的很穩定

蓋到一半，要換地基是不是很悲催。開發的設計的時候一定要三思而後行。

3. 設計的原則

3.1 適應性

滿足使用者需求，達成商業的目的。而不是開發人員自己歪歪，高水平的設計人員就是設計出來剛剛滿足使用者需要的軟體，而不是不惜一切程式碼設計出來一個最先進的軟體，沒有最好，只有最合適。打造閉環是最好的，對於很多網際網路專案，可能不是剛需需求，可能不是成熟的商業模式，如果非要進行閉環，試錯的機會都不給，開發的成本老闆接受不了，老闆無法快速推廣到市場裡面。開發的功能越多，功能越強大的話，一旦業務發生調整的話，軟體不好發生變動。所以要分為很多個階段。開發和產品經理很多容易犯這個毛病，剛開始就設計都喜歡大而全，精而細。 產品經理經常愛說：『別人的系統都有這個功能，你為什麼做不了！』，其實可以這麼懟過去，給他上一課：『這樣的產品設計根本就不能滿足現階段產品設計的適應性！』

3.2 結構穩定性

我們設計的要相對的穩定性，一定確定一定要相對的穩定性，如果經常變動，就相對於房子的地基，你看到那個房子蓋好後的地基經常發生變動。如果軟體經常發生，太悲劇了。體系結構設計的不穩定，範圍不清楚，如果一個系統剛開始是B2C，突然要變成B2B，表結構，系統模組，介面，全部都要發生比較大的改變。整個專案變的很輪亂，需求不停的變動導致系統很混亂。導致開發人員不敢動程式碼（牽一髮動全身），都是複製一份 程式碼。最後維護多份程式碼。對於高水平的設計師都是有一定經驗的，可以預先知道那些需求是基本不變的，那些需求是可變的。

必須匯出：可變需求和可變需求。

舉個例子：之前專案中針對訊息中心的設計，訊息中心：對於使用者來說會有很多種類的訊息。訊息除了pc端，移動端也有很多的訊息，物流訊息，營銷訊息，通知訊息。當時就有一個問題， 實際的訊息中心，就是接收到各種渠道的訊息，然後分發到各個平臺（郵件，簡訊，推送，系統訊息資訊）。之前沒有訊息中心，都是業務方自己各自來完成的。為了滿足原子性，原子是不可變的，訊息中心需要做的就是按照業務方的需求把訊息傳送出去，傳送到對應的渠道，簡訊。但是訊息中心是在業務平臺之後設計的，業務平臺不可能因為傳送訊息修改自身的業務程式碼。在訊息中心專門設計了一個監聽模組，監聽業務方的一個動作，這個模組跟業務平臺是緊耦合的，事件監聽模組隨著業務而變動，訊息中心的核心功能不會發生變動的，因為功能很純粹就是發訊息，收訊息，推送訊息。這就是當時如何保證穩定性的問題。在模組上進行劃分。如果之後在需要拆分的話，直接把模組進行拆分。監聽模組，按照業務的變更進行變更。

穩定性，就不會被業務需求方趕著走，專案是可控的。天天不用擔心老闆又有新需求。

3.3 擴充套件性

軟體在擴充套件新功能的難易程度。擴充套件性越好，適應變化的能力越強，尤其是敏捷開發，如果擴充套件能力不強的話，很容易進入一個死衚衕裡面去。區分可變動和不可變動。軟體體量約小，擴充套件能力越強，船小好調頭。為什麼專案分階段，就是為了可擴充套件。系統的體量肯定受限業務的，越大的專案擴充套件性越難，所以要進行分散式（應用層，中間業務層，原子服務層），分層（控制層，服務層，資料訪問層），越是往下穩定。

合理的業務模組劃分，擴充套件的時候根據模組進行拆分擴充套件。業務的邊界劃分。

3.4 是不是所有的系統在設計的時候都要考慮擴充套件性

一次性專案，只要完成現階段的功能就可以了，例如兩個單獨的公司的對接介面，其實很多時候因為可能是一次性的，沒必要考慮擴充套件性，如果考慮可能就變成了過度設計。如果做開放平臺的話，肯定要考慮擴充套件性。

3.5 可複用性

用一次還可以繼續在用，工具類，公共的元件。工具類一定設計的純粹（對使用環境沒有假設，少配置零配置，沒有依賴）