XXX管理平台系統——架構

XXX管理平台系統架構

前言

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

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

關于部分系統架構圖的内容參見：

<a href="http://space.itpub.net/6517/6517/viewspace-609654">http://space.itpub.net/6517/viewspace-609654</a>

系統硬體

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

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

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

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

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技術架構本來就是一個虛虛實實的架構， 呵呵。

系統同步和接口架構

盡管通過測試，進階複制和stream都可以實作實時資料同步，不過我知道在實際生産環境中是遠遠不會這麼簡單的；

首先源資料和目标源的結構并非完全一緻，允許目标源的結構大于原資料源的結構

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

最後Oracle的stream有許多的bug，需要進行不斷調試和patch更新。

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

關于MQ、Webservice、LDAP接口，目前的業務和技術雖然已經完全實作，但是還缺乏穩定性和一緻性。

總結

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

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

本文轉自baoqiangwang51CTO部落格，原文連結：http://blog.51cto.com/baoqiangwang/313494，如需轉載請自行聯系原作者