為什么要做用戶系統

幾乎每個應用都會用到用戶系統。如果能夠進行通用化，自然是一種很快意的事了。然而到目前為止我還沒有找到一個讓我滿意的類似的東西。不是說它們不夠好，而在于它們不能滿足管理和部署上的可伸縮性、靈活性及與現有應用的可集成性上，所以只好自己做了一個。

用戶系統的組成

用戶系統在設計上是有三部分組成的，用戶基礎信息管理、用戶庫管理、用戶組管理。大家可能會對“用戶庫”和“用戶組”感到疑惑，覺得不應該同時出現這兩個東西，或者只用一個就可以了。然而這是為了滿足“可伸縮、靈活”特征而特意設計的。下面分別就這三部分做一個說明。

用戶基礎信息，沒有特別的，為了實現單點登錄，以使各種不同的應用進行統一的用戶登錄驗證，我們只提供簡單的登錄名、密碼、昵稱等信息。這些信息存儲在中心庫上。我們可以指定管理員來對整個用戶數據進行管理，這對一般的應用來講就可以了，但當一個大型的企業，每個部門都可以對自己部門進行獨立的人員管理，這時就需要擴展我們的設計。

為此我提供了用戶庫，總部可以創建用戶庫，然后對用戶庫進行授權，讓各部門管理各自的用戶庫，這樣就實現了用戶管理的獨立性和伸縮性。用戶庫只能用于新建、編輯、刪除用戶，不能做其它的事情。用戶庫（實際上是一個表）的存儲也位于中心庫上。需要注意的一點是，用戶庫是屬于平臺管理的范疇，不屬于某一特定的應用。

用戶組只是多個不同用戶或用戶組的集合，用戶組中的用戶可以來源于任何一個用戶庫。它只能添加或移除用戶，而不能“新建”和“刪除”用戶。這一點非常重要，否則用戶系統的管理會非常的混亂。用戶組的一個重要應用是建立一個“穩定的授權模型”，以簡化管理員的工作。

用戶組的復雜性和伸縮性遠遠超出了用戶庫的設計。主要有兩點：

l用戶庫中的數據不需要分布式存儲，而用戶組卻需要。用戶組可以有平臺級的管理范疇，同時每個應用系統又都可以管理各自的用戶組數據。全部將這些數據進行集中存儲是不科學的，會給中心帶來不必要的數據庫維護任務，最好的做法就是各應用存儲在各應用自己的系統庫中，這就要求用戶組的存儲是分布式的。

l用戶庫之間是平等的，而用戶組之間的關系是交叉的。用戶庫沒有父級用戶庫的概念，大家都是平等的。而一個用戶組可能屬于多個用戶組。

設計要點

用戶系統的設計總體上貫徹平臺架構中講到的“應用與WS分離”及“WS與數據庫分離”兩條宗旨。用戶組的分布式存儲便是一個很好的應用，我們只有一個用戶組相關的WS便可以操作分布在不同位置上的數據庫。

其實用戶組WS和用戶庫WS是用的同一個WS，這就是我要給大家講的容器系統。“容器”系統是抽象后的概念，我定義它可以管理三種結構的數據形態。

一、一維結構。容器之間是平等的，沒有包含與被包含之分，如用戶庫系統。

二、樹結構。每個容器可以有一個或零個父容器，如各種分類信息。

三、多父結構。每個容器可以有多個或一個或零個父容器，但不能形成循環，如用戶組系統。

為了使用容器系統，我們必須要遵守一定的規范。

一、用容器系統提供的模板數據表進行應用數據表的創建，這里對用戶庫系統為每個創建的數據表名稱冠以“UserLib”前輟，為每個用戶組系統創建的數據表名稱冠以“UserGroup”。

二、使用平臺規范的自定義DBInfoSoapHeader，進行數據庫信息的傳遞，這個類中除了包含數據庫連接信息之外還提供了表名稱前輟字段。這樣才能在中心數據庫中即能訪問用戶庫數據又能訪問用戶組數據。當然對用戶組來講應用系統庫中也存在著用戶組數據。

用戶系統中另一個共用的設計是有效時間，它允許限制用戶及用戶組在某一時間段內的可用性。有效時間模塊用一個WS來表示，但他不直接被客戶端使用，而是作為父類被其它類繼承。這是因為有效時間在意義上不能是一個獨立系統，另外一個重要原因在于提高系統的性能，以減少不必要的WS服務之間的訪問開銷，及提供事務處理功能。

我們在進行用戶管理時，會經常用到“刪除用戶”的功能，但這個功能在用戶系統中會有些麻煩。用戶系統是服務于多個應用的，當刪除一個用戶時，與用戶關聯的應用數據會形成“孤兒”！如何防止此問題的發生呢？

數據依賴系統是解決此問題的專用模塊。用戶系統是不了解應用的業務邏輯的，這件事情只能由應用自己去處理關聯的數據。不同的應用將關聯關系注冊到數據依賴系統中，在進行用戶刪除時，用戶系統查詢數據依賴系統中與用戶關聯的注冊。如果存在注冊，則調用所注冊的處理單元，等到所有的處理單元都成功處理才能將此用戶進行刪除;如果沒有注冊,則直接進行用戶的刪除。不過因為時間關系,目前數據依賴系統并沒有實現！只能將不需要的用戶先暫時禁用了。

這里只是講了用戶系統的技術點，要讓用戶系統更方便的使用還要涉及到平臺中的其它內容，如數據庫冗余系統，WS地址服務系統等。

注意的問題

一、用戶信息的擴展。

在平臺用戶系統中，用戶信息是以保證用戶能夠實現統一用戶驗證而設計的，這同時也說明他不能全面的說明用戶的基本情況，尤其是一些專業領域的系統。如銀行及保險中的用戶家屬信息，社交網站中的興趣愛好等。對于這些信息需要由外部應用自身來擴展。為了有好的用戶體驗及提供很好的集成性，用戶系統提供一個“用戶詳細信息”的事件供應用來實現。

二、基于.NET的使用。如果應用使用.Net進行開發，那么用戶只需要使用CommonWare.Dll文件就可以了。這里面已經封裝了很好的客戶端相關的實現。它體現了“應用與WS分離”的設計理念。

三、基于跨平臺的使用。如果應用不是使用.Net進行開發，那么只好進行WS的直接調用了。

相關文章

平臺”我的編程人生à產品à“項目

平臺架構——體系結構

總結

以上是生活随笔為你收集整理的平台架构用户系统的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。