【系統分析師之路】第七章 系統設計記憶敲出

【系統分析師之路】第七章 系統設計記憶敲出

1. 人機界面設計

• 由於最近幾年手機APP開發趨勢日益劇增，人機界面設計也越來越受到了人們的重視，UI設計也因此被提高到了一個新的高度。

1. 置於用戶的控制之下：比如某些流氓軟件，你按了某個按鈕後，它就會讓你跳到流氓軟件指定的網頁，
   這樣的話用戶體驗肯定不好，所以我們在設計人機界面時，要求如果在載入進度中不能10秒以上沒有響應，
   還有在處理過程中，任務時可以取消的。
2. 減少用戶的記憶負擔：比如載入進度的時候顯示百分比，鼠標變成齒輪狀，這些都能減少用戶的記憶負擔。好的APP開發完成以後，大家都可以憑感覺就可以熟練地操作，因爲用戶不會一邊看你的軟件使用說明書，一邊學着操控軟件了。
3. 保持界面的一致性：可以讓用戶按自己習慣的方式操作就是保持界面的一致性，在軟件升級的時候，千萬不要把用戶喜歡的操作習慣給改變了。很早以前玩過軒轅劍3，軒轅劍3外傳天之痕就是繼承了軒3的操作和界面，讓人可以很快的上手，而軒4開始使用了3D的引擎進行遊戲的開發，界面以及操作習慣完全和之前的遊戲系列沒有了關係，讓口碑一下子下降了不少，還有重製版生化3也是基於了重製版生化2的操作，所以很多老玩家可以很快速的上手遊戲。這些都是保持界面一致性的很典型的例子。

2 Web開發演化–單機系統

• 最早的Web開發數據庫服務器，應用服務器都部署在一臺機器上，發現速度漸漸慢下來的時候優先對應的方法是升級硬件
• 當升級硬件以後，速度已經沒有很明顯的提升的時候，我們就要分析並思考能不能把數據庫服務器和應用服務器分開放到不同的PC上之下，然後通過中間件將數據庫服務器和應用服務器連接起來，看起來像運行在一臺服務器上，數據庫服務器和應用服務器都需要資源，而且也分開兩臺PC來處理，於是速度得到了提升

3. Web開發演化–集羣於負載均衡

• 但是這種提升往往還是不夠的，當應用服務器負荷量很大變爲瓶頸的時候怎麼辦？我們可以使用多臺PC跑應用服務器，這個就是集羣技術。這裏集羣和分佈式技術要區分開來。集羣就是多臺PC機運行同一個內容，而分佈式則正好相反，同一個內容拆分爲數份，每一小份分別運行在不同的PC上，這就是集羣技術和分佈式技術的差異點。
• 集羣技術是如何實現的呢？集羣技術的實現離不開負載均衡。負載均衡的方式有應用層負載均衡和運輸層負載均衡兩種類型。Http重定向和反向代理是應用層的負載均衡技術；DNS重定向和基於NAT的負載均衡是運輸層負載均衡技術。
  1. DNS是動態的域名解析協議，你輸入一個域名，傳輸到域名解析服務器進行域名的解析，在這裏爲了實現負載均衡，得到不同的IP地址，然後客戶端就訪問不同的IP地址實現DNS的分流。它是最早的最爲簡單有效的負載均衡技術。基於DNS協議的負載均衡技術可以有效的分發客戶請求，但是缺點就是無法獲得集羣中哪臺機器性能塊，哪臺機器目前不可用，所以在客戶端消息負載均衡時，還是有不足的地方的。
  2. 基於反向代理服務器的負載均衡技術。這裏使用了代理服務器，這裏的代理服務器就可以理解爲一箇中間件。在這個代理服務器中使用算法來實現分發，也就是把請求均勻轉發給多臺服務器，從而達到負載均衡的目的。
  3. 基於Http重定向的負載均衡技術。我們在做Web開發的業務邏輯時，當訪問某一個URL失敗的時候，使用重定向技術將URL重新定位到另一個地址，而這個Http重定向技術配合一定的算法以後，還可以用來實現多臺服務器之間的負載均衡。Http重定向的負載均衡方式實現最爲簡單，但是性能也是最差的。
  4. 基於NAT的負載均衡技術。將一個IP地址轉化爲另一個IP地址的技術，使用這種技術也可以指定不同的主機，實現多臺服務器之間的負載均衡。
  5. 混合型負載均衡在有些大型網絡，由於多個服務器羣內硬件設備、各自的規模、提供的服務等的差異，可以考慮給每個服務器羣採用最合適的負載均衡方式，然後又在這多個服務器羣間再一次負載均衡或羣集起來以一個整體向外界提供服務（即把這多個服務器羣當做一個新的服務器羣），從而達到最佳的性能。將這種方式稱之爲混合型負載均衡。

4. Web開發演化–負載均衡算法

• 爲了實現負載均衡，不光和使用到的技術策略，還和負載均衡算法有關。負載均衡算法的好壞直接影響者負載均衡的效果。負載均衡算法分爲動態算法和靜態算法兩種。

1. 靜態算法是以固定的概率去分配任務給集羣中不同的服務器，從而實現負載均衡。輪轉算法和加權輪轉算法就是靜態負載均衡算法的應用。
2. 動態算法於靜態最大的不同就是在分配任務的時候，會考慮集羣中服務器目前的負荷，根據符合情況再進行任務的分配。最小連接法、加權最小連接法都是動態的算法。

5. Web開發演化–Web頁面的狀態

• 訪問的頁面分爲有狀態和無狀態兩種類別。
  1. 無狀態的頁面比較好整，不管用什麼樣的負載均衡算法，問題都不大。而有狀態的頁面就不那麼容易處理了。因爲在考慮負載均衡分配處理服務器的時候，同時還要把Session裏面的內容一併告訴被分配到的集羣中的某臺服務器纔可以。所以有狀態的頁面在實施負載均衡的時候會相對比較麻煩。
  2. 爲了解決上面的問題，我們可以把這些所謂的狀態信息也就是Session裏面的信息放在一臺專門的Session服務器上，這樣對應了以後，比如手機淘寶和PC淘寶上購物車裏面的信息，就可以實現同步了。

6. Web開發演化–主從數據庫

• 當應用服務器這邊使用了集羣技術，並且上了負載均衡技術和相應的算法，爲應用服務器進行了減負，
  那麼接下來，系統的瓶頸就到了數據庫服務器這邊。數據庫服務器這邊速度越來越慢而不得不改善的時候，
  我們首先可以使用主從數據庫的技術，主庫負責對數據的讀寫操作，從庫負責對數據的查詢操作，分別部署在兩臺PC機上。
• 這樣兩臺PC機各司其職，也實現了負載均衡。除了負載均衡，主從數據庫還可以起到容災的作用。
  比如一臺數據庫服務器壞了或者無法使用的時候，我們無需做任何變更，因爲主從數據庫可以互爲BackUp。
• 主從數據庫在使用過程中還涉及到同步的問題，主從數據庫的同步，讓我想到了企業信息化集成技術中的數據集成。

7. Web開發演化–用緩存緩解讀寫庫的壓力

• 數據庫的使用和操作往往也是遵循28法則，20%的數據訪問表示往往佔用了80%的可能性，而80%的訪問每次都去查找數據庫取得並計算，有時候還會遇到重複的對數據庫的計算和查詢，這個時候效率又變得低下了。因爲每次查詢操作都需要訪問數據庫的數據，將其讀到內存中，然後再計算。這個時候我們使用了緩存，將經常操作或者查詢的結果保存在緩存中，這樣可以大大減少數據庫讀寫和計算的時間。這樣我們的信息系統又進行了有效地改善。
• 這裏的緩存數據，其實和計算機組成原理中的存儲結構非常的相似。應該也可以歸納到局部性原理上。

8. Web開發演化–CDN內容分發網絡

• CDN的全稱是Content Delivery Network，即內容分發網絡。如果一個大家都要訪問的內容放在一個網絡節點上，那麼大家都需要訪問的時候，都會去訪問這個節點，這樣這個節點的負載就會變大，如果這個時候將這個結點的內容拷貝以後放到各個網絡節點上，需要這個節點上數據的人只要就近訪問就可以了。 這樣就改善了數據傳輸速度和穩定性這些瓶頸，解決了網絡擁擠的問題，提高了網絡訪問的速度。CDN的基本原理爲反向代理（Reverse Proxy）。在我看來CDN更像是一種特殊的集羣技術。當然特殊集羣化之後，就變相冗餘了系統，也減少了被DDOS攻擊的可能性。
• 在國內訪問量較高的大型網站如新浪、網易等，均使用CDN網絡加速技術，雖然網站的訪問巨大，但無論在什麼地方訪問都會感覺速度很快。而一般的網站如果服務器在網通，電信用戶訪問很慢，如果服務器在電信，網通用戶訪問又很慢。

9. 面向對象的設計原則

• 單一職責原則：每一個類只負責一個職責，每個人幹什麼事情職責清晰可見
• 李式替換原則：子類可以替換父類。千萬不要覆蓋父類的東西，不然誰都不會想到，替父從軍之時千萬不要打破父親在軍隊中定下的規則。
• 依賴倒置原則：針對接口而不是針對實現來編程，名字和實際差別比較大的一個原則。針對接口有點類似多態，還有策略模式就是依賴倒置原則的典型應用。電視機和PC機就是一個很好的例子，電視機一般部件不會升級，所以電視機部件都焊接起來，不能輕易替換，而PC機可以升級，所以針對接口編程了，內容，網卡等都有自己通用接口，可以方便升級。
• 開放封閉原則：對修擴展開放，對修改關閉，因爲修改可能會引入新的bug。
• 迪米特原則：一個對象要對其他對象有儘可能少地瞭解。它也叫最少知識法則。
• 接口隔離原則：它是針對接口設計來說的，接口設計時不要使用多個參數的總接口，因爲這樣不好，還不如將這個總接口做拆分爲多個。
• 組合重用原則：儘量少用甚至不用繼承，因爲繼承是一種強耦合關係，取而代之使用組合關係去替換它。因爲使用繼承的話，父類一變子類不變都不行了啊。

10. 業務流程設計—標杆瞄準

• 這個還是比較容易理解的，類似於在項目管理中的標杆對照，在這裏它是參照行業內的標杆企業，看看他們的流程並以他們的流程作爲參照來定義自己的業務流程。

11. 業務流程設計—IDEF

• IDEF是一個比較完善的是業務流程定義的體系。
  IDEF0是對系統功能進行建模，類似於DFD。
  IDEF1是信息建模
  IDEF1X是數據建模，可以用到ER圖
  IDEF2是仿真建模設計
  IDEF4是面向對象的建模
  IDEF8是用戶界面建模
  IDEF12是組織結構建模

12. 業務流程重組與業務流程管理的區別與聯繫

• 任務流程重組事宜革命性的大改變。他的關鍵字是革命性的，再思考和徹底性的再設計。因爲他推翻了原來所有的業務流程，所以他的風險也是最高的。
• 而業務流程管理中最主要的是加入了戴明的PDCA的思想到了裏面，更加強調持續改進的思想。還有業務流程管理強調構造端到端的卓越業務流程。
• BPR強調對流程的再設計，BPM強調對流程進行規範化的改造，使之成爲卓越的業務流程。

13. 結構化設計

• 結構化設計分爲概要設計和詳細設計，結構化設計可以說算是比較古老的設計了，在結構化設計中也需要遵循一系列的原則，比如多扇入，少扇出，因爲扇入是調用別人的接口，扇出則是調用別人，調用得少說明依賴耦合度小，也就是可複用性要來得高；還有高內聚低耦合是用來說明和衡量模塊的可複用性好壞；還有需要有效地控制調用的層數，層數越多，出棧入棧也會變得頻繁，這樣效率就會受到影響；每個模塊大小適中，自頂向下逐步求精也是結構化設計的特徵。

14. 設計模式的概念

• 架構模式，設計模式，慣用法之間的關係：架構模式比設計模式大一號，慣用法比設計模式小一號，設計模式和架構模式不依賴於某種特定的語言，而慣用法一般是很具體的語言相關，比如C++中的引用就是一種慣用法。
• 工廠模式，模板方法，適配器模式，解釋器模式這四個是屬於類模式。其他的模式屬於對象模式
• 類模式就是不用實例化爲對象就能達到我們想要的結果。
• 對象模式：實例化之後對象去打交道的一種模式；
• 類的靜態方法是不需要實例化爲對象便可以使用的方法，它是實現類模式的一個重要手段

15. 設計模式之創建型模式

• 創建型模式一共有下面的五個，主要用來解決創建對象這樣一個目標。

1. 工廠模式：只是提供一個創建對象的方法，如何創建對象，創建什麼對象由子類決定。實現了動態化的對象生成。
2. 抽象工廠模式：工廠方法模式的升級版本，他用來創建一組相關或者相互依賴的對象。
3. 單例模式：可以讓特定的類只生成一個對象
4. 生成器模式：一般用來解決創建對象複雜的問題，它將複雜的創建過程進行了封裝
5. 原型模式：Clone對象的一種應用，一個對象生成以後，給了另外一種創建對象的方式

• 工廠模式與抽象工廠的區別
  抽象工廠可以用來創建一系列相互依賴的對象，而工廠模式只適合創建單一的產品對象。如果工廠的產品全部屬於同一個等級結構，則使用工廠方法模式；如果工廠的產品來自多個等級結構，則使用抽象工廠模式。

16. 設計模式之結構型模式

• 適配器模式：主要做的是接口的轉換，把我們不想要的接口轉化爲想要的接口。
• 橋接模式：首先讓我想到了組合重用原則。它主要是拿來解耦的，繼承是緊耦合，如果可以把繼承拆分爲組合，那麼就拆分到組合來使用。通過使用橋接模式，緊耦合的關係可以得到有效的解決。比如可以使用橋接模式，把手機軟件通訊錄和手機品牌進行解耦。這樣一來，類的複用性就可以得到提高。
• 組合模式：這個模式主要可以用來表示整體和部分的關係，比如文件夾結構就是組合模式的最好的一個應用，因爲在文件夾內部還有子文件夾，這就是整體和部分的關係。在編譯器對語法進行分析的時候，也用到了組合模式。
• 裝飾模式：它主要做的是動態的給一個類添加一些職責。首先讓我想到的是強襲敢達，可以根據不同的地形換裝。
• 外觀模式：在我看來就是定義一個抽象化統一接口的模式，使用外觀模式後，可以把網狀拓撲結構變爲星型結構。使用外觀模式可以簡化某些子系統的調用，用結構化設計的思想來看，可以簡化扇入。外觀模式說白了就是打包一系列得接口，所以感覺有點像界面集成。
• 享元模式：在需要生成很多對象，而且很多對象都一樣的時候，這個時候就可以使用享元模式來
• 代理模式：封裝對象的訪問控制的一個模式。我不喜歡做家務，於是找來了代理，讓代理去拖地，洗碗，這樣我就不用親自去做這些事情了。

17. 設計模式之行爲型模式

• 責任鏈模式：減少信息發送者和信息接收者的耦合。信息在一條對象鏈之間遊走，看由誰來處理這條信息更加得合適。
• 中介者模式：銀行直接轉賬複雜，這個時候就有了銀聯，所有銀行之間的轉賬都變爲銀行對銀聯進行轉賬，這個時候的銀聯就是中介者。在架構模式中的ESB就是應用到了中介者模式來進行的。再比如買賣房屋，賣家和買家都是通過中介實現交易。
• 命令模式：命令模式就是把對象之間得通信的命令進行抽象化設計的模式，它最大得特點就是命令是可以撤銷的。
• 解釋器模式：提到解釋器，不得不聯想到還有解釋器的架構風格。它們都是用在虛擬機的機制中。
• 觀察者模式：MVC模式中View就在觀察Model中數據的變化，一旦數據層發生了變化，就及時通知View層來更新，它強調的是對象之間的聯動。觀察者模式很像發佈訂閱的模式。
• 備忘錄模式：打遊戲的時候，卡在了某個關卡，死活過不去，載入進度了N次，爲什麼可以載入，因爲我們之前保存了遊戲的備忘錄。
• 狀態模式：它的UML圖和策略模式是完全一樣的，狀態模式最大的特點就是已經把狀態封裝成了一組狀態類。
• 策略模式：根據策略載入最爲合適的算法的時候，就用到策略模式。策略側重特定方法的選擇和切換。
• 模版方法：C++中的模版就是使用到了模版方法，在模版中定義方法，在子類中實現方法。
• 迭代器模式：C++的STL庫中就有迭代器，它就是一組對象的集合，一組數據集。
  向量集，鏈表集，Map集，HashMap集都是數據集，都可以用迭代器模式來訪問。
• 訪問者模式：用來橫向採集各個對象之間的數據的時候，使用訪問者模式，其實覺得訪問者模式可以和迭代器模式一起使用，因爲迭代器就是一組對象的數據集。在C++中對迭代對象進行遍歷運算的範型算法，更像是訪問者模式。