純技術貼:討論一個現實中的需求的架構
大家好,這個帖子我打算根據專案的進展不斷新增專案過程中碰到的問題,而在這裡,就先拋開商業的一些需求,純從技術上討論架構及實現,以及可能的風險。下面是對專案的描述。
首先,這是一個管理軟體,用於軟體公司的。就是說,是為某軟體公司開發的軟體。
第二點:這是一個需要外掛體系的B/S軟體,需要透過一些簡單配置去實現新功能(包括工作流,但不僅是工作流)
第三點:為了追求易用性,因此需要在B/S中實現單機程式的風格頁面,因此可能會包含大量元件,大量複雜頁面展示邏輯。
第四點:需要分散式部署
第五點:在特殊需求下,需要在網頁內呼叫一個富客戶端完成工作,而客戶可以接受的唯一安裝的東西是JVM,因此這個軟體不需要其他的客戶端
第六點:客戶的辦公室分佈在多個城市,需要高速響應使用者的需求,拋開網路問題,需要在客戶每個城市放上一臺或多臺伺服器。
第七點:線上人數會非常大,因此需要可以橫向擴伺服器。同時需要較快的訪問速度。
第八點:系統大部分地方對資料的查詢與寫入是二比一的比例,或者說:有很頻繁的更新操作
第九點:系統對事務要求較高,因為有財務,還有成本估算等模組,因此不允許垃圾資料的存在,並且事務要求是全域性的。
這是簡單的幾條,下面分別描述幾個典型的模組:
1.訊息系統。
需要一個完善的訊息系統,支援從Email到RSS,站內訊息的模組,同時也需要支援手機簡訊,以及未來可能需要的一些通知方式。
2.工作流系統
需要自定義的工作流,並且工作流需要實現的流程是跨地區的,比如有的流程在一個城市,另一個流程在另一個城市,流程之間可以輪轉。
3.線上的繪圖、會議
這種地方需要實現在頁面內繪圖,如果需要,允許使用客戶端(但不需要安裝,現在考慮的是JavaWebStart)
4.IM,(要求也是線上的)
可以整合MSN和YAHOO,同時自己還需要維護內部的賬戶(就是自己開發IM,使用者如果需要,可以同時聊MSN,就像Gaim那樣)
5.WebService支援
需要公開一部分WebService供客戶的客戶去呼叫,這裡有大量只讀的,部分需要進行資料資訊交流的
6.SSO
把過去的一些系統也整合起來,一起登入(現在還不清楚是誰整合誰)
7.分散式部署(這是我們經驗最不足的地方)
為了訪問速度可以快一些,雖然有核心的伺服器,但希望客戶的不同辦公區域都各放上一臺伺服器對某個地區提供服務。而客戶的不同辦公區域在不同的城市。而各地方的業務邏輯基本上是相同的,因此,這個部分的架構可以多討論一下。
在這方面,還有一些細節需求:中心伺服器是PostgreSQL或者Oracle,而為了速度,也許可以在客戶端的伺服器上跑一個簡單的MySQL對某些資料進行快取。
8.關於業務複雜度
在這裡我沒法把複雜度描述出來,不過的確是相當複雜,涉及財務、時間管理、專案管理、成本、風險等各種東西,因此業務相當複雜。
上面是一些典型的模型,大家對於這種專案,有什麼好的技術建議?隨著專案的進行,我也把一些問題擺上來,與大家的方案進行對比。這個專案現在還在考察階段,估計過了年才能夠開始。
專案會跑在Solaris上,不排斥Java EE 5的技術,可以使用新的應用中介軟體。
歡迎大家討論。
首先,這是一個管理軟體,用於軟體公司的。就是說,是為某軟體公司開發的軟體。
第二點:這是一個需要外掛體系的B/S軟體,需要透過一些簡單配置去實現新功能(包括工作流,但不僅是工作流)
第三點:為了追求易用性,因此需要在B/S中實現單機程式的風格頁面,因此可能會包含大量元件,大量複雜頁面展示邏輯。
第四點:需要分散式部署
第五點:在特殊需求下,需要在網頁內呼叫一個富客戶端完成工作,而客戶可以接受的唯一安裝的東西是JVM,因此這個軟體不需要其他的客戶端
第六點:客戶的辦公室分佈在多個城市,需要高速響應使用者的需求,拋開網路問題,需要在客戶每個城市放上一臺或多臺伺服器。
第七點:線上人數會非常大,因此需要可以橫向擴伺服器。同時需要較快的訪問速度。
第八點:系統大部分地方對資料的查詢與寫入是二比一的比例,或者說:有很頻繁的更新操作
第九點:系統對事務要求較高,因為有財務,還有成本估算等模組,因此不允許垃圾資料的存在,並且事務要求是全域性的。
這是簡單的幾條,下面分別描述幾個典型的模組:
1.訊息系統。
需要一個完善的訊息系統,支援從Email到RSS,站內訊息的模組,同時也需要支援手機簡訊,以及未來可能需要的一些通知方式。
2.工作流系統
需要自定義的工作流,並且工作流需要實現的流程是跨地區的,比如有的流程在一個城市,另一個流程在另一個城市,流程之間可以輪轉。
3.線上的繪圖、會議
這種地方需要實現在頁面內繪圖,如果需要,允許使用客戶端(但不需要安裝,現在考慮的是JavaWebStart)
4.IM,(要求也是線上的)
可以整合MSN和YAHOO,同時自己還需要維護內部的賬戶(就是自己開發IM,使用者如果需要,可以同時聊MSN,就像Gaim那樣)
5.WebService支援
需要公開一部分WebService供客戶的客戶去呼叫,這裡有大量只讀的,部分需要進行資料資訊交流的
6.SSO
把過去的一些系統也整合起來,一起登入(現在還不清楚是誰整合誰)
7.分散式部署(這是我們經驗最不足的地方)
為了訪問速度可以快一些,雖然有核心的伺服器,但希望客戶的不同辦公區域都各放上一臺伺服器對某個地區提供服務。而客戶的不同辦公區域在不同的城市。而各地方的業務邏輯基本上是相同的,因此,這個部分的架構可以多討論一下。
在這方面,還有一些細節需求:中心伺服器是PostgreSQL或者Oracle,而為了速度,也許可以在客戶端的伺服器上跑一個簡單的MySQL對某些資料進行快取。
8.關於業務複雜度
在這裡我沒法把複雜度描述出來,不過的確是相當複雜,涉及財務、時間管理、專案管理、成本、風險等各種東西,因此業務相當複雜。
上面是一些典型的模型,大家對於這種專案,有什麼好的技術建議?隨著專案的進行,我也把一些問題擺上來,與大家的方案進行對比。這個專案現在還在考察階段,估計過了年才能夠開始。
專案會跑在Solaris上,不排斥Java EE 5的技術,可以使用新的應用中介軟體。
歡迎大家討論。
相關文章
- 有沒有一些大廠的高階架構技術討論討論架構
- 在實際的專案需求中瞭解技術架構的演進架構
- 走在技術前沿的 iOS 架構實現 ?iOS架構
- [技術討論]資料許可權中的理論和實際
- 和開發人員討論一個業務需求和簡單實現
- 和開發同學討論的一個技術問題
- [技術討論]需求應該找誰來獲取
- 和開發討論的一個資料變更需求
- [技術討論]關於低耦合開發的討論
- [技術討論]Uml工具哪個更好
- 怎樣學習一個新的架構技術架構
- 就是單純的討論一下程式碼
- [技術討論]務實與務虛
- 現代資料架構的7個關鍵技術架構
- [技術討論]多人併發開發中的問題
- 創業之初的技術題:如何構建一個較為通用的業務技術架構創業架構
- 技術討論 | 陳珙:微服務,它還那麼純粹嗎?微服務
- 專案需求討論 — 用Transition做一個漂亮的登入介面
- 此貼討論一下 AI 在 UI 自動化中的應用,以及個人的一個想法AIUI
- HTTP服務七層架構技術探討HTTP架構
- 多層架構的討論,歡迎拍磚架構
- 關於業務元件相關架構的討論元件架構
- 資訊化技術討論組
- 愛奇藝RND框架技術探索——架構與實現框架架構
- [技術討論]軟體的產品、技術、標準對話
- [技術討論]做事一定要有方法
- 一個關於組織學員學習技術的筆試題--求討論筆試
- [技術討論]多使用者(多公司)的資料庫設計討論資料庫
- 專案需求討論-仿ios底部彈框實現及分析iOS
- 我的“技術架構”之旅架構
- Android技術棧(三)依賴注入技術的探討與實現Android依賴注入
- [技術討論]軟體工程之全程建模實現適合做教材麼?軟體工程
- 網上投票作弊的技術實現(純技術交流,勿用作他途!!) (轉)
- [技術討論]科學基礎的分析和探討對話
- 關於國內技術類書籍的一次討論
- Redux技術架構簡介(二)– 非同步實現Redux架構非同步
- Redux技術架構簡介(二)-- 非同步實現Redux架構非同步
- 資料庫系統架構討論資料庫架構