XXX管理平臺系統——架構（原創）

Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONEXXX管理平臺系統架構

前言

系統架構是專案中技術實現的最重要的環節。系統架構的良好與否關係到系統的效能指標、安全指標、穩定性指標、可擴充套件性、業務實現等等。

系統架構涉及到系統硬體的選型、網路拓撲、作業系統選型、資料庫選型、B/S與C/S的選型、B/S各框架的選擇、快取的實現、資料庫設計等諸多方面。

在大型IT企業中，專案經理和架構師是分離的；但對於國內IT公司尤其是小企業來說，就成了一種奢望。專案經理一肩挑的現狀至少短期之內還是無法改變的，這自然也增加了專案經理的痛苦指數和工作量。

關於系統架構是什麼？我最認同一句話：架構即關注點分離。

專案經理不是萬能的，系統架構需要更廣博的知識，當然某些方面專業的知識也是必須的，這取決於平時知識的積累和總結，也需要其他團隊成員共同的努力。

關於部分系統架構圖的內容參見：

http://space.itpub.net/6517/viewspace-609654

系統硬體

關於系統硬體的選型，首先是根據業務需求和效能指標確定硬體的需求數量和相應型號；舉例說：一個普通的B/S系統需要有web應用伺服器，資料庫伺服器，如果對於效能有較高的要求，則需要增添cache伺服器；如果對於穩定性和高可用性有特殊的要求，則需要對相應的伺服器進行叢集處理。

關於系統硬體的選型，一是關於廠商的選擇(有IBM和HP之爭)，一是關於機器架構的選擇(PC伺服器和小型機)，再則是某種機型的選擇（在本系統中主要為HP360和HP580）；再細的話就是更細型號的選擇了(HP360、HP580都至少有十幾種型號)，最後是機器選件，比如是否需要擴充硬碟、記憶體或者CPU。

其實最重要的一項就是預算，呵呵。本系統的硬體採購是由甲方採購的，但是架構是由自己做的，方案如果有之前的案例就會很輕鬆很多，很不幸，這個方案改了幾十版，跨度達到4個月。無他，對硬體，我不熟。

系統軟體

關於系統軟體的選擇主要上是作業系統、資料庫、開發工具

選擇什麼樣的作業系統與計算機硬體本身有很密切的聯絡，當然也與甲方的要求有關。Linux/Windows/專有UNIX都是可選項，windows囿於安全性原因，一般不為推崇；UNIX與硬體有很大關聯，一般也很少用；所以普遍選擇的是Linux；

關於作業系統版本的選擇，一般建議選擇目前市面比較穩定的版本，最新的版本往往意味著相容性問題，太老的版本一般有效能問題；

關於作業系統的32/64位的選擇，這個需要硬體的支援；在64位CPU上安裝32位的作業系統意味著資源的浪費；在這個專案上曾經考慮有所欠妥，結果造成了一定的問題。

關於資料庫的選擇，與作業系統有一定關係，也和對系統的安全性、穩定性、高併發性有一定關係；雖然一個好的DBA在任何一種資料庫上都可以構建出高可用性的資料庫，呵呵。

關於開發工具的選擇，與作業系統相關，也與甲方的要求有關，開發工具一向有java和微軟兩條線路之爭；在本系統中採用的當然是java了。

關於web中介軟體的選擇，與開發工具、作業系統都有關係，JBOSS，websphere，tomcat，resin，web logic都有一定的擁蹇和市場；取決與甲方的要求和本團隊對相應系統的熟悉程度。

B/S架構

關於系統軟體架構通常是指的是B/S部分實現的具體框架，此部分仍屬於技術架構部分。

眾所周知，B/S的框架有不下數十種，常用的有SSH（Structs + Spring + Hibernate）和SSI（Structs + Spring + iBatis），SSH和SSI從本質上沒有什麼不同，就是實現業務邏輯層、控制層、資料持久層和展現層的分離。

B/S快取的架構：OS Cache + Eh Cache

         說到軟體架構，我就不太在行了；我做過Powerbuilder，ASP，java(JSP,HTML,CSS,Javascript,structs,spring,xml,xsl,ajax,web service)不過都是入門級水平，實在連個稱職的程式設計師都算不上，唯一的好處就是對方方面面都略知一二，查資料方便一點而已，呵呵。我個人只是在資料倉儲和資料庫開發、設計方面還算有點研究。

幸虧下面有相應的專案經理，也是專案中的技術經理，他在這方面是權威，B/S技術架構本來就是一個虛虛實實的框架，呵呵。

系統同步和介面架構

關於資料同步，在本平臺中是最重要的環節，缺少資料的系統是無用的；為了實現系統資料同步架構，我曾先後在虛擬機器上進行過oracle高階複製、Oracle Stream的測試，也曾為了該同步和公司技術總監吵過N多次，他主張用程式來實現，不過在他那邊總是不了了之。

儘管透過測試，高階複製和stream都可以實現實時資料同步，不過我知道在實際生產環境中是遠遠不會這麼簡單的；

首先源資料和目標源的結構並非完全一致，允許目標源的結構大於原資料來源的結構

其次多環節資料實時同步，從中心資料庫到電信資料庫，再從電信資料庫同步到網通資料庫。

再次各資料庫均採用RAC方式，現實的例子中很少有類似應用。

最後Oracle的stream有許多的bug，需要進行不斷除錯和patch升級。

事實上，在同步方案的過程中，也遭遇到很大的困難，前後的測試和最終順利實施經歷了2個月之久，不過stream仍需要不斷的人工監控和干預。我相信到目前為止即使市面上也沒有任何一種完全穩定的同步方案。

關於MQ 、Webservice、LDAP介面，目前的業務和技術雖然已經完全實現，但是還缺乏穩定性和一致性。

總結

系統架構是專案最重要的技術部分，它是否應該是專案經理的職責，暫且不談；從現實的角度而言，技不壓身，技能服眾還是很有意義的；從專案經理角度來看，你能夠準確的對專案進度、難度、工作量進行評估，對團隊成員面臨的困難迅速給出解決方案，減少專案經理和團隊成員的溝壑；從團隊成員角度來看，信任自己的專案經理，也是專案成功的一個重要因素。

專案經理能夠透過對系統架構的設計,儘快評估出各部分的工作量,以安排相應的人力資源和工作計劃,做到有的放矢,實際上本專案雖然包含幾個業務系統,加上對本公司相關資源和技能的評估,但我個人認為系統整合和資料同步等在專案實施中佔據了50%的工作量.