第8章 系統架構

學習目標 提供在選擇系統架構時應考量的各項主要議題的查核清單 描述伺服器、以伺服器為基礎的處理、用戶端，及以用戶端為基礎的處理 解釋用戶端 / 伺服器架構，包含階層、成本效益問題，及效能考量 解釋網際網路在系統架構上的衝擊 3

學習目標 描述線上及批次處理的差異 定義網路拓樸結構，並提供階層式、星狀、匯流排，及環形等網路模式 解釋網路協定及授權 (licensing) 等問題 3

學習目標 解釋系統管理工具及技術，包含效能管理、系統安全、錯誤管理、備份，及災難回復 描述系統設計規格及解釋其每一節的內容

簡　介 有效的系統將這些元件結合在一個架構 (architecture) 或是設計中，使它具有彈性、具有成本效益、技術性健全、且可以支援企業經營的資訊需求 系統架構 (system architecture) 將資訊系統的邏輯設計轉變成包含硬體、軟體、資料，及處理方法的實體結構 4

系統架構查核清單 系統分析師也必須持有整體的查核清單以決定系統架構 分析師必須考量以下七項會影響系統架構選擇的具體事項︰ 企業資源規劃 (ERP) 初始成本與總取得成本 (TCO) 規模彈性 網頁整合 老舊系統之介面需求 系統安全 處理選擇

系統架構查核清單 企業資源規劃 (ERP, enterprise resource planning) 初始成本與總取得成本 (TCO) 描述一個特定的硬體與軟體環境 (environment) ，也稱為平台 (platform) 供應鏈管理 (supply chain management) 初始成本與總取得成本 (TCO) 在設計階段的最後，你所做的決策，將會對新系統的初始成本與 TCO 產生重要影響 在進一步到設計系統架構之前，你現在應該再分析系統需求及可能的方案

系統架構查核清單 初始成本與總取得成本 (TCO) 規模彈性 自問以下問題︰ 如果選擇在組織內自行開發為最佳初始解決方案，現在仍是最佳解決方案嗎？ 如果最初選擇某特定套裝軟體，它仍然是最佳選擇嗎？ 有沒有任何新形式的委外可取得？ 規模彈性 規模彈性 (scalability) 是指一個系統為滿足企業經營不斷變動的需求，而可以擴大、改變，或縮小之能力的量度 規模彈性的另一個術語是延伸性 (extensibility)

系統架構查核清單 網頁整合 一個資訊系統包括許多處理輸入、管理處理邏輯，及提供所需輸出的應用程式 (application program, or application) 以網頁為中心的 (Web-centric) 架構依據網際網路設計協定，並使得公司可以將新應用系統整合於其電子商務策略中 以網頁為基礎的應用系統可避免許多在牽涉到不同硬體環境下經常會發生的連線及相容問題

系統架構查核清單 老舊系統之介面需求 新系統可能必須與一個或多個老舊系統 (legacy systems) 互動 與老舊系統間的介面牽涉到資料格式及相容性的分析 為選擇最佳應用系統架構，分析師必須先知道新系統是否終將要取代老舊系統

系統架構查核清單 系統安全 以網頁為基礎的系統產生新的安全考量，重要資料必須在網際網路環境中加以保護 電子商務應用系統也引發一些安全考量，公司必須尋求方法以向消費者證明其個人資料的安全與完整

系統架構查核清單 處理選擇 在規劃系統架構時，設計師也必須考量系統將如何處理資料──線上或分批 每天 24 小時，每週 7 天 (通常稱為 24/7 ) 必須預先做好在系統失效時備份及快速回復的準備工作

架構的規劃 每一個資訊系統都牽涉到三個主要功能︰資料儲存與取用的方法、完成處理邏輯的應用程式，以及允許使用者與系統互動的介面 依架構而定，這三個功能可以是在伺服器、在用戶端，或是分別在伺服器與用戶端執行

架構的規劃 伺服器 伺服器 (server) 用戶端 (client) 雖然實際的伺服器不一定就是大型主機，但此處的術語，大型主機架構及集中式系統中，通常是指伺服器比用戶端具有絕對優越的處理能力之多使用者環境

架構的規劃 伺服器 背景 除了集中式資料處理之外，早期系統在通常稱為資料處理中心 (data processing center) 的中央位置執行所有的資料輸入與輸出 在此組織下的使用者，除了從 IT 部門所分發出來的列印報表外，是沒有輸入與輸出能力的

架構的規劃 伺服器 以伺服器為基礎的處理 在集中式設計中，遠端使用者在鍵盤上的動作被傳送到大型主機中，而它以傳送輸出畫面回到使用者的終端機螢幕上作為回應 而其主要缺點是，以伺服器為基礎的處理通常使用以字元為基礎的終端機，只能提供有限的介面給使用者 以 Intermet 為基礎的零售業務可以在客戶服務中心，使用集中式資料管理，以支援或管理其線上銷售活動 隨著伺服器技術的發展，終端機技術也發生劇烈的變化

架構的規劃 用戶端 自從 1980 年代中期 PC 科技開發以後，微電腦很快就成為公司的桌上型電腦 使用者發現他們可以執行自己的文字處理、試算表，及資料庫等，而不需要 IT 部門的協助 大部分公司又將這些獨立運算的電腦連結起來而形成網路

架構的規劃 用戶端 獨立運算 獨立運算(Stand-alone computing) 是相當低效率、昂貴 在個別工作站上維護資料產生許多關於資料安全性、整合性，及一致性的問題 沒有集中的儲存位置，就不可能對貴重的業務資料保護及備份，而公司因而暴露在極大的風險之下 這又引發了資料的不一致及不可靠

架構的規劃 用戶端 區域及廣域網路 大部分公司解決獨立運算問題的方法，是將這些用戶端連結起來而形成一個區域網路 (LAN, local area network) 廣域網路 (WAN, wide area network) 跨越較長的距離而可以連結在不同地區的使用者，如圖 8-10 所示 網路是通透的 (transparent) 與大型主機架構相較，分散式系統增加關於資料安全性及完整性的考量

架構的規劃 用戶端 以用戶端為基礎的處理 在一般的 LAN 中，用戶端分享儲存在本地伺服器的資料 在檔案伺服器 (file server) 設計中，每個個別 LAN 的用戶端都有一個應用系統程式，而資料則是存放在集中的伺服器 檔案伺服器設計需要大量的網路資源

架構的規劃

用戶端/伺服器架構 概 述 用戶端/伺服器架構 (client/server architecture，或稱主從架構) 概　述 用戶端/伺服器架構 (client/server architecture，或稱主從架構) 在用戶端/伺服器互動中，用戶端提出要從伺服器取得資訊的要求，伺服器完成此項操作並將之回復給用戶端 許多早期的用戶端/伺服器系統並不能產生預期節省效果 許多公司都有已經存在的大型主機資料，稱為老舊資料 (legacy data) ，這些資料的取用及傳送到用戶端/伺服器系統中都很難 

用戶端/伺服器架構 概　述

用戶端/伺服器架構 用戶端的種類︰胖與瘦 胖用戶端 (fat client, or thick client) 瘦用戶端 (thin client) 大部分的 IT 專家同意，瘦用戶端設計的表現較好，因為程式碼放在伺服器，比較靠近資料之所在 相反的，胖用戶端要負責大部分的處理，且必須常常存取及更改資料

用戶端/伺服器架構 用戶端的種類︰胖與瘦

用戶端/伺服器架構 用戶端/伺服器階層 二階式 (two-tier) 設計 三階式 (three-tier) 設計 你可以將此中間階層視為是一個應用系統伺服器 (application server) ，因為它提供系統所需要的應用系統邏輯 (application logic)或業務邏輯 (business logic) 三階式設計也稱為 n 階 (n-tier) 設計 中間階層在大規模的系統中，更有效率且更具成本效益

用戶端/伺服器架構 中間軟體 (middleware) 使各階層可以彼此溝通並交換資料 提供了一種讓系統設計師整合不同類軟體及硬體的透明介面 也可以整合老舊系統與以網頁為基礎的應用系統

用戶端/伺服器架構 成本效益議題 用戶端/伺服器系統可讓公司在此快速變化的環境中，調整系統的大小 用戶端/伺服器運算也讓公司將各種應用系統從昂貴的大型主機，轉換到便宜的用戶端平台上 用戶端/伺服器系統可降低網路負載且改善回應時間

用戶端/伺服器架構 用戶端/伺服器效能議題 用戶端/伺服器架構的確含有許多效能問題，而這些是與將以伺服器為基礎的資訊和必需取用資料的用戶端分離相關的 相對於集中式系統，一套用戶端/伺服器設計將應用系統與資料分開 用戶端/伺服器系統必須是設計到，用戶端只有在必要時才與伺服器聯繫，而且這種次數愈少愈好

用戶端/伺服器架構 用戶端/伺服器效能議題 Distributed database management system (DDBMS)分散式資料庫管理系統 (DDBMS, distributed database management system) 資料比較靠近使用者，可以降低網路交通量 系統具有擴充能力，所以可在不用更動系統設計下，增加新的資料存放點 而且當資料分別存放在不同位置時，比較不會發生毀滅性的系統故障

網際網路的衝擊 電子商務策略 組織內自行開發 如果你決定進行組織內自行開發的解決方案，你必須要有一個整體的計畫以幫助你達成目標 組織內自行開發的解決方案通常需要比較大的初始投資，但是可以提供較大的彈性，可以幫助公司很快地調適於這個動態性的電子商務環境中

網際網路的衝擊 電子商務策略 套裝解決方案與電子商務服務提供者 公司入口 許多廠商，包括Microsoft，提供啟鑰式系統 (turnkey systems) 給想要迅速建立與運作電子商務的公司 另外一種選擇是使用應用系統服務供應商 (ASP, application service provider) 公司必須考慮，較低初始成本的優點是否值得其後續彈性減少之缺點 公司入口 入口 (portal) 是多功能網站的進入點 公司入口 (corporate portal) 提供其資料之存取給客戶、員工、供應商，及公眾

網際網路的衝擊 產業經驗與趨勢 當系統分析師在建構網際網路或是企業內部網路的系統時，就會面臨一大堆令人眼花撩亂的產品及策略 一個好的出發點可能是考慮在相同產業中其他公司的經驗 此類研究可以提供關於廠商產品及服務的寶貴資訊

各種處理方法 線上處理 線上處理系統有四個一般性的特色︰ 當交易發生時，系統就在發生地完全處理 使用者直接與資訊系統互動  線上處理系統有四個一般性的特色︰ 當交易發生時，系統就在發生地完全處理 使用者直接與資訊系統互動 使用者可以隨機存取資料 資訊系統必須隨時在可用狀態，以備在需要時即可支援各種企業功

各種處理方法 批次處理 在批次處理 (batch processing) 系統中，資料是以群組或是批次的方式收集及處理的 IT 團隊可以在不牽涉到使用者的狀況下，依預定的進度執行批次程式，它可在一般工作時間、在晚上或是在週末執行；且批次程式比起線上系統，只需要非常小量的網路資源

各種處理方法 線上與批次處理的組合 銷售時點 (POS, point-of-sale) 線上處理有一個基本優點是因為資料在交易發生時即輸入且驗證，所以所儲存的資料是較快可取得且總是最新的 線上處理比較昂貴 線上處理的備份及回復比較困難 在很多狀況下，批次處理是具成本效益的、比較不會受到系統損壞而影響，而且比較不干擾正常操作

網路模型 網路可以允許硬體、軟體，及資料資源的分享，以達到減少開銷及提供更強的功能給使用者 OSI參考模型 在你研讀網路拓樸之前，你應該對於描述資料實際上如何從某部電腦上的應用程式移到網路相連的另一部電腦的應用程式中的開放系統互連模型 (OSI model, Open System Interconnection model) 有一些基本了解

網路模型 OSI參考模型 OSI 模型包含了七個層級 應用層 (application layer) ：提供本地工作站所請求的網路服務 展示層 (presentation layer) ：確保資料已依網路傳輸之需而按照一致標準排列並作格式化 會議層 (session layer) ：定義用來管理電腦間通訊連結的控制結構 傳輸層 (transport layer) ：提供可靠的資料流及錯誤回復

網路模型 OSI參考模型 OSI 模型包含了七個層級 網路層 (network layer) ：定義網路上的地址並決定資料如何在網路上轉送的路徑 資料連結層 (data link layer) ：定義在實體層上傳送資料的特定方法，例如定義出資料區塊的起始與結束 實體層 (physical layer) ：包括承載資料的實體元件，諸如各種配線及接頭

網路模型 網路模型工具 當你將 OSI 邏輯模型轉換為網路化系統的實體模型時，你可以使用如 Microsoft Visio 之類的多用途繪圖工具來表示實體架構及網路元件

網路模型 網路拓樸 一個網路配置的方式，稱為網路拓樸 (network topology) LAN 與 WAN的網路通常以四種方式配置︰階層式、匯流排、星狀，及環狀

網路模型 網路拓樸 階層式網路 階層式網路的一大缺點則是如果一家公司增加額外的處理工作階層，此網路的運作與維護會變得更加複雜與昂貴 優點是它反映出組織內實際運作流程

網路模型 網路拓樸 星狀網路 星狀網路 (star network) 中有一部中央電腦，而一部或是多部的工作站都連接此中央電腦形成一個星形 在星形的中央，被稱為軸心 (hub) ，中央電腦管控著此網路 當星狀網路提供效率及嚴密控制時，其主要的缺點是，整個網路都依賴中央電腦

網路模型 網路拓樸 匯流排網路 優點是設備可隨時連接到網路，或是從網路上移除，而不會影響到網路的其他部分 缺點之一就是當愈來愈多使用者或設備加入後，其效能會衰退，因為所有訊息的交通都必須在中央的匯流排上流通

網路模型 網路拓樸 環狀網路 通常是使用在，當大部分的處理都是在本地電腦上執行而不是在中央電腦上執行時 在環狀網路中資料只向單一方向流動 環狀網路的缺點之一是，如果某個網路設備 (諸如一部 PC 或一部印表機) 發生故障，則故障設備下游的所有設備就無法與網路作通訊了

網路模型 網路協定 網路都必須要使用協定 (protocol) 一套常用的網路協定是TCP/IP (Transmission Control Protocol/Internet Protocol) 一個大家熟悉的 TCP/IP 協定的實例就是檔案傳輸協定 (FTP, file transfer protocol)

網路模型 授權問題 軟體廠商提供各種不同類型的個人或是網站的使用授權 有些廠商限制使用者的人數或是可同時存取程式的電腦個數 你必須仔細評估網路軟體的容量，以確定它可以滿足預期的系統流量

系統管理及支援 效能管理 效能管理 (performance management) 工具是設計來收集有關於系統資源及活動水準的資訊 為幫助滿足此種需求，像 NetScout 這種公司，提供易了解的效能管理套裝軟體 NetScout 網頁有提及網路延遲比完全不動的網頁損失更多收益的研究，因為它們太常發生

系統管理及支援 系統安全 (system security) 首先，必須提供指定及監控使用者 ID、密碼，及存取權限的功能 第二，系統安全工具必須可以進行病毒保護及檢測非法存取，包含企圖進入系統的入侵者 目前，已有許多可用的安全管理軟體產品

系統管理及支援 錯誤管理、備份，及災難回復 最佳策略是在問題尚未影響到系統前，先行避免 然而，你還必須要再提供一些方法以處理系統錯誤及中斷問題 錯誤管理 錯誤管理 (fault management) 包含監控系統出問題的徵兆、記錄所有系統故障、診斷問題，及施行更正動作

系統管理及支援 錯誤管理、備份，及災難回復 備份及災難回復 備份 (backup) 回復 (recovery) 災難回復計畫 (disaster recovery plan) 備份及災難回復的規劃是依其所牽涉系統的類型而定 在線上系統中，你必須在與系統互動時做備份，或是在系統操作時，持續備份資料

系統管理及支援 錯誤管理、備份，及災難回復 備份及災難回復 另外一個常用的策略是使用RAID (redundant array of independent disks) 系統 RAID 系統也稱為容錯 (fault tolerant) 系統， 有經驗的 IT 專業人士經常注意到三項最重要的系統安全工具是備份、備份，更多的備份

系統管理及支援 錯誤管理、備份，及災難回復 備份及災難回復 誌錄檔案 (log file 或 journal file) 在最糟糕的狀況下，企業保險可以彌補一些由於系統故障及企業損失的花費 除了支持系統運作所必要的備份及回復程序之外，檔案保留 (file retention) 的法律與規定也施用於公司資料中。 如果政府法令規定公司的所有薪資紀錄必須保留三年，則你必須將資料保留至該期限

系統設計完成 系統設計規格 系統設計規格 (system design specification) 技術設計規格 (technical design specification) 細節設計規格 (detailed design specification) 系統設計規格是衡量開始運作後的系統的基準 系統設計規格的長度不盡相同

系統設計完成 系統設計規格 一般系統設計規格使用類似於以下所示的結構 管理概況 系統元件 系統環境 建置需求 時間及成本估計 附錄

系統設計完成 使用者批准 使用者必須審視及批准使用者介面、報表及選單設計、資料輸入畫面、原始文件，及在系統中會影響使用者的其他部分 其他 IT 部門成員也必須來審視此系統設計規格 當系統設計規格完成時，你將此文件分發給預定使用者群組、IT 部門人員，及公司管理階層

系統設計完成 簡 報 這些簡報讓你有機會來說明系統、回答問題、考量意見，及取得最終批准 簡　報 這些簡報讓你有機會來說明系統、回答問題、考量意見，及取得最終批准 第一次簡報是針對參與系統未來專案階段或操作性支援的系統分析師、程式設計師及技術支援幕僚 下一次的簡報是針對系統所影響到的各部門經理及各部門的使用者

系統設計完成 簡 報 最後一次簡報是針對公司的管理階層 這個簡報有一個重要的目標︰獲得管理階層的批准及支持下一個開發步驟 簡　報 最後一次簡報是針對公司的管理階層 這個簡報有一個重要的目標︰獲得管理階層的批准及支持下一個開發步驟 管理階層可以做出三種決策中的一種︰繼續進行系統開發、再多做一些系統設計階段中的工作、或是中止此專案

本章總結 資訊系統或是應用系統是結合硬體、軟體、資料、程序，及人員於一個應用系統架構中 在選擇應用系統架構之前，分析師必須要考慮企業資源規劃、初始成本及 TCO、規模彈性、網頁整合、老舊系統介面需求、安全及處理選擇等 系統安全在整個設計過程中，是一個重要考量 一個架構需要伺服器及用戶端 49

本章總結 網路可以允許硬體、軟體及資料資源的分享，以達到減少開銷及提供更大的能力給使用者 網路配置的方式稱為網路拓樸 系統設計規格顯示資訊系統的完整系統設計，而它是為完成整個系統設計階段而作簡報的基礎 49

Chapter 8 Complete