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

按照正常的網際網路玩法，産品經理原型畫好進行需求評審，評審完後，需要把需求丢給技術經理，或者技術負責人，進行一整套的概要設計，然後針對概要設計評審，概要評審後進行開發。這次咱們一起說說概要設計的體系結構。了解下套路。

軟體系統設計

軟體系統設計在很多人眼裡就是寫文檔，寫文檔是一種負擔，其實系統設計頭腦風暴，是一種非常開心的事情。是以必須掌握什麼是系統的設計。它裡面有哪些方法論，如何去做一些系統設計。

我們平常做開發設計嗎？

才畢業回鄭州那幾年，都是一句話就是需求，開發完了河南本地連個測試人員都沒有，開發人員說開發完了就開發完了，直接拿給使用者進行測試。有的使用者直接罵娘，有的使用者用的感覺很不爽哭的（工作沒做完），有的使用者直接摔東西的。聰明的一點的使用者都直接聯系開發人員幫他來操作。直接測試都沒有，使用者就是測試人員，說實話7，8年前的告訴使用者怎麼用，他怎麼用。他感覺很神秘，這幾年随着網際網路産品越來越多，智能手機的普及，大家對軟體的要求越來越嚴格了。很多之前的習慣的同僚，現在都沒轉變過來，真是土，土的掉渣。後來其實也沒太關注設計，可能就是之畫個圖。直到後來跟第三方系統進行互動資料，剛開始草草的設計下，導緻之後的2個月都沒好過。是以說系統設計是一項非常重要的工作。而不是老鐵們經常說的就是寫個文檔就行了。

1. 拿這鍵盤直接幹。
2. 深思熟慮，考慮到多方的問題，在開始我們的編碼。
3. 需求裡面是一句話，直接就是幹，别墨迹。
4. 做設計的時候，開發人員在考慮？還是技術經理在考慮？

用什麼方法做？

瀑布流程（網際網路直接忽略）

需求确定的基礎上，系統設計的方方面面設計的都很全面，把每個階段都有非常嚴格的驗證條件，在主流的大型軟體的開發方式。

基于原型，快速疊代（網際網路常用）

許多創業公司的老闆真心喜歡，感覺業務可以進行快速的開發，其實在裡面還是有很多的坑在裡面的。很少有人基于瀑布來開發。其實快速疊代也變成了很多老闆讓各位老鐵趕項目的理由了。我幾個億的單子，先讓使用者驗證，讓使用者體驗到，大家不能耽誤我們偉大的商業模式，就算是這種開發模式也是需要有文檔的，對設計不清楚的地方也會有很多，很多的坑在裡面，包括後期的性能和擴充也好，如果前期底子沒有搭建好的話，後期傷筋動骨。随随便便改一個小功能可能要對程式進行傷筋動骨。但是這個時候老闆是不會管你的，測試人員更不會管你，産品也不會管你，他們隻知道我們滿足業務和需求。

具體設計什麼

具體到底需要設計什麼？如果系統沒有做好一個設計，如果你還是基于所謂的原型，快速疊代靈活開發以這為借口的話，程式後期越來越大，越來越大的時候真心很傷，根本都不改你的系統，就比如說：銀行，社保裡面的代碼基本是10年前的代碼，裡面的問題一大堆，但是沒有人敢改，這也是設計部合理導緻的一個毛病。

• 體系結構設計

  1.指明了一個系統是什麼，它是整個軟體中最本質的表現

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

2.應當設計的很穩定

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

3.設計的原則

3.1 适應性

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

3.2 結構穩定性

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

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

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

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

3.3 擴充性

    軟體在擴充新功能的難易程度。擴充性越好，适應變化的能力越強，尤其是靈活開發，如果擴充能力不強的話，很容易進入一個死胡同裡面去。區分可變動和不可變動。軟體體量約小，擴充能力越強，船小好調頭。為什麼項目分階段，就是為了可擴充。系統的體量肯定受限業務的，越大的項目擴充性越難，是以要進行分布式（應用層，中間業務層，原子服務層），分層（控制層，服務層，資料通路層），越是往下穩定。

    合理的業務子產品劃分，擴充的時候根據子產品進行拆分擴充。業務的邊界劃分。

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

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

3.5 可複用性

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

• 表結構設計
  1. 方法論
  3. 性能擴充性考慮
• 系統的子產品設計
• 資料結構和算法