中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

本系列拙作是個人在公司業務中臺建設中的思考，共分為3篇（按中臺劃分），本篇為第一篇。由于中臺尚處于建設中，最終走向還待實踐。公司的產品有2B和2C方向，因此在設計時需要同時考慮這兩方面。

ps：我所聲稱的用戶中臺，可以認為是一個基于微服務的類SAAS的綜合身份管理中心，主要給公司平臺內的業務系統使用。

問題域

用戶中臺需要面對哪些問題呢？

把時間線往前撥一下，先看看企業在信息化方面的遇到的問題，然后再看看用戶遇到的問題。

企業遇到的問題：

在多年以前，企業的業務系統是由各個部門負責建設，比如大家熟知的OA系統、財務系統、CRM和ERP等系統，這些系統是由某個部門提出然后并負責推向公司使用。

當業務系統慢慢變多的時候就會發現，雖然企業擁有了這么多系統，但是這些系統的數據是不通用的。每個系統都需要把員工和組織錄入一遍。

一旦員工變動（變更組織或者辭職、新員工入職），那么所有業務系統都需要全部更新一遍，這無疑增加員工的工作。而且，由于這些系統互不相同，導致職員在上班時需要逐個登錄到相關系統，浪費不少時間。

更致命的是，有的員工離職之后，某些系統的操作人員沒能及時注銷員工賬號導致公司數據泄露；某些員工在離職前拷貝公司客戶數據導致客戶被挖墻腳，這些事情也屢見不鮮。

那么企業遇到的主要問題有（4A）：

• 統一管理員工賬號，為新員工創建賬號，為離職員工注銷賬號；
• 統一管理員工權限，避免員工越權接觸數據或越權操作等；
• 統一認證，所有系統只需要登錄一次；
• 統一審計，記錄所有員工的 操作日志。

除了這些企業內部遇到的問題外，還有一些是對外暴露的一些問題：用戶在A產品上的賬號不能在B 產品上登錄，盡管A產品和B產品都屬于同一個公司。

那么回到一個用戶中臺（類似SAAS），不僅要面對上述問題，還需要處理以下問題——組織如何注冊。

• 組織如何實名
• 組織如何登錄（組織管理員如何登錄）
• 員工怎么登錄，手機密碼、手機短信驗證碼、第三方登錄（微信、QQ、微博等）、賬號名稱/ID
• 怎么創建、刪除、禁用員工賬號
• 管理員怎么邀請員工加入到這個虛擬“組織”
• 組織如何分配員工權限（控制訪問）

用戶遇到的問題：

用戶面對的問題與企業是有一些類似，明明用的都是某一個公司的產品，結果卻需要用戶再次注冊；更有甚者web端和移動端不統一，導致用戶在web端下的單但是在手機上卻看不著。

如果沒有統一的用戶管理，付出的代價也是非常昂貴的，用戶流失是一方面，用戶打通的成本是另一方面。比如最近2年阿里推出的88vip，其中一個目的就是為了打通阿里系相關產品的用戶體系。

對于用戶，重點是以下問題：

• 需要登錄么
• 怎么登錄，手機密碼、手機短信驗證碼、第三方登錄（微信、QQ、微博等）
• 怎么注冊，手機號注冊、郵箱注冊
• 怎么能夠注銷賬號
• 是否需要實名，如何實名

解決方法域

對于問題域中提及的問題，業內其實有很成熟的解決方案，比如4A管理和IAM。

4A管理：集中賬號管理（Account）、集中認證管理（Authentication）、集中授權管理（Authorization）和集中審計管理（Audit）

IAM：Identity and Access Management，即身份識別與訪問管理

當然類似的公開產品有（非公開的更多）：

• 東軟 SaCa IAM
• 國民認證的統一身份認證平臺（UAP）
• 其它的就不列舉了

無論哪種解決方案，重點要解決的問題是：

• 統一管理賬號，創建賬號、注銷賬號、修改密碼、找回密碼、修改信息等等
• 統一管理權限
• 統一登錄
• 統一注冊
• 統一認證鑒權

設計思路

在分享設計思路之前先定義一些概念

概念

下面是一些概念（來源于關于SaaS平臺中應對多租戶模式的設計—權限設計）：

（1）資源

被安全理的對象（Resources頁面、菜單、按鈕、訂單等）。

（2）權限

訪問和操作資源的許可（Permit刪除、編輯、審批等）。

（3）角色

用戶通過業務需求確定一個角色（Role），并按照實際的業務場景，賦予角色對應的權限的過程，角色也可以理解是權限的集合，是眾多權限顆粒組成。

（4）用戶

系統實際的操作員（User）

（5）操作權限

• 頁面權限：即用戶登錄系統可以看到的頁面，由菜單來控制，菜單包括一級菜單或多級菜單。當系統賦予用戶對應菜單的權限，那么用戶就可以訪問對應的菜單頁面。
• 操作權限：即頁面的功能按鈕，包括：查看、新增、修改、刪除、審核等。當用戶點擊按鈕時，系統將會校驗用戶的是否包含次操作權限，如果有，就可以進行下一步操作。
• 數據權限 ：數據權限就是用戶在同一頁面看到的數據是不同的。比如項目管理員，就能看到當前團隊正在進行中的項目，以及項目的進度情況。而團隊成員，就只能看到本人具體參與的項目以及項目信息。相對于復雜一項的權限也可以基于組織結構來拓展。

注意：在用戶中臺中，資源歸屬于各業務系統，但權限（權限控制）卻是屬于用戶中臺！

關于統一管理的說明：

這里面的統一管理是從開發角度或者系統治理角度出發，并非是從使用角度出發。

以權限管理為例，之前每個業務系統需要搭建自己的權限管理，10個系統就需要開發10次 。如果將這些分散在各系統中的權限管理合并到某個系統中，那么只需要開發一次即可。

而這個獨立的權限管理系統就可以稱之為統一權限管理系統。這個統一的管理系統可以由專人/部門維護，也可以由各個系統來維護。

從使用角度上來看，統一權限就是有專門的人負責給平臺所有用戶分配權限，比如新來一個研發小張，公司信息部給他創建賬號并給他分配各系統的權限。這個信息部就承擔了統一管理的角色。

以“用戶”為中心

用戶中臺是以“用戶”為中心的，那么可以基于用戶的活動來繪制一張“用戶地圖”，如下圖所示。

從圖中可以看到，用戶屬于用戶中臺，但是他在物業系統中的角色是管理員，在智慧園區系統中的角色是普通員工。這表明著用戶在不同的業務系統中承擔著不同的角色，換句話說，角色是與系統關聯，系統限定了用戶的角色。

上圖有一個明顯的問題，這個用戶沒有屬于任何組織或者只屬于一個組織（平臺方）。如果僅是一個自用的平臺、小團隊等等，沒有顯式的組織是有可能的。但是，有人的地方就會有團隊，有團隊的地方就會有組織（有人的地方就有江湖）。

而軟件系統是人類真實社會的一個寫照一個映射，組織自然就應該加上。用戶可以屬于1個組織也可以屬于多個組織，這些組織之間可以是相關聯（比如集團公司和子公司），也可以不關聯（比如特朗普不僅是總統，還是商人）。用戶與組織的關聯關系后面再詳細介紹。

由于我們的部分業務是對外提供服務（SAAS），用戶中臺還要考慮多租戶需求。各租戶的權限控制可能不一樣，組織架構也可能不一樣，因此需要進一步調整以應對這兩種挑戰。

這會遇到一個問題，若租戶使用多個系統，那么是每個系統都創建組織還是所有系統都使用一個組織？

個人比較大傾向于各個系統使用獨立的組織（指組織機構），這樣會更靈活一些（有的業務系統不需要組織架構，而有的業務系統需要組織架構來劃分各種權限尤其是數據類權限）

此處是分割線……

如果不存在多租戶概念，那就沒有租戶這一層。這種更接近于自用的內部平臺，此時用戶應當與組織關聯（下圖未畫用戶與組織的關聯）

如果沒有組織（組織架構）這一層，那么還可以簡化為：

賬號體系

從平臺角度上來看，平臺的賬號分為兩類，一類是個人賬號，一類是組織賬號（組織有政府機構、企業、社會團體等）。個人賬號非常常見，全部的C端應用和部分B端應用都是基于個人賬號體系的。

關于組織賬號其實在一些平臺中也是非常常見的，銀行有公司賬號和個人賬號，支付寶和微信也有類似的賬戶；蘋果的開發者賬戶有個人、企業之分。

在組織賬號的實現上其實有兩種方式：

• 一種是為組織創建獨立的賬號（曾經在政府OA系統中設計過）；
• 一種是將個人賬號綁定到組織進而通過個人賬號來登錄。后者在平臺中非常常見，比如各類SAAS平臺

ps：在授權方面，個人賬號和組織賬號并無區別。

權限管理

用戶中臺的權限體系是基于RBAC概念，這個RBAC是基于資源的RBAC而非基于角色的RBAC。

各業務系統的權限是相互獨立的，沒有依賴關系

業務系統的權限遵從于基于資源的RBAC

數據權限受限于數據規則

權限并集：與 RBAC2 的靜態職責分離-角色互斥原則相反，平臺采用多角色權限取并集的設計。即在某個業務系統中，用戶可以擁有多個角色。此時用戶在該業務系統的權限等于各角色權限的并集

為滿足以上幾點，權限體系中必須有系統標識；數據資源權限中不僅有組織標識，還必須要有部門標識和創建者標識，部門標識和創建者主要是便于區分消費者和生產者。

ps：目前暫未設計用戶組和角色組概念

賬號體系和權限管理小結

賬戶體系和權限管理遵循以下原則：

個人賬戶統一原則：個人賬戶一次注冊，全平臺通用，類似于全網通行證和 SSO。

業務權限獨立原則：每個子系統的權限體系是獨立的，但是由用戶中臺統一管理維護。『個人賬戶統一原則』明確了賬戶體系是統一的，但是對于每個子系統而言，每個賬戶所能使用的功能和服務，所能查看的數據權限是獨立維護的。

組織實體隔離原則：不同的組織實體之間，是相互隔離，獨立管理的。每個組織實體可以自行組織自己的組織體系、賬戶體系和權限體系。不同的組織實體資源權限也是隔離的。

從屬關系隔離原則：個體賬戶與組織實體的從屬關系是基于單獨的業務系統存在的，『個人賬戶統一原則』明確的僅是個人賬戶的全網統一，但組織實體、從屬關系并沒有統一，并且是隔離的。

比如在 CRM 系統中，張三（用戶）從屬于 XXXX 公司（組織），但在 OA 系統中，張三（用戶）默認是不從屬于任何組織的，從屬關系受到具體業務系統的影響。

事實上，這個原則是非強制的，具體取決于各自的業務邏輯和業務場景。

如果要簡化從屬關系的管理，那么可以不遵循此原則，即個體賬戶與組織實體的從屬關系是全平臺統一的，與業務系統無關，但這會為降低平臺的靈活性和擴展性。靈活性和復雜度之間通常要做一個取舍。

擴展：

在序言中提及到的《平臺級SAAS架構的基礎-統一身份管理系統》文章中，作者用的是OS-RBAC權限體系，其中O是Orgnization組織，S是Systerm系統。筆者解釋這個體系說明權限受組織和系統雙重約束。

這一點我是贊同的，權限是依賴于系統，數據依賴于組織。這個在多租戶體系中尤為明顯，A公司的管理員不能看到B公司的數據，因為A和B是兩個不同的組織；同樣，A公司的組織架構、權限體系可以和B公司的完全不一樣。

考慮公司平臺的業務主要集中在自用和第三方開發者接入使用，短期內（半年到一年內）有租戶入駐的概率較低。為了降低復雜度，我降低了組織對權限的影響（設計和開發實現上兼顧）。

即在某個業務系統中，所有管理員的功能權限是一樣的（數據權限除外，因其受到組織影響）。

用戶類型

下圖來源于《平臺級SAAS架構的基礎-統一身份管理系統》，這個里面概況的用戶類型非常詳細。我將組織用戶和行業用戶都放在了組織用戶概念中，與前文的組織賬戶對應。

組織類型

《GBT20091-2006組織機構類型》中定義了以下組織類型：

• 國家機關
• 企業
• 事業單位
• 社會團體（含行業協會）
• 其它類型

我們平臺對應的2B業務有智慧社區、智慧園區、智慧辦公、智慧校園等，2C業務有智能家居、電商等。綜合這些業務場景，平臺首要考慮：

• 國家機關，園區、社區類需要考慮，尤其是引入政府資金時，可能需要將數據提供給街道辦、公安或政法委（綜治辦2018年被撤銷，相關事宜轉交到政法委）
• 電商平臺，主要考慮到企業類型

服務分解

微服務架構下的服務分解有兩種方式：一種是基于業務能力的分解方式，一種是基于DDD領域驅動子域分解。由于我還在學習DDD領域驅動，故先基于業務能力來分解服務。

業務能力

用戶中臺需要滿足下列需求：

從功能角度來看，可以分為以下模塊，詳見腦圖：

• 賬戶
• 認證
• 組織管理
• 權限管理
• 授權管理
• 鑒權中心
• 系統管理

服務分解

以下是具體的服務

（1）賬號類服務

• 賬號管理服務
• 注冊服務
• 注銷服務

（2）權限類服務

• 角色服務
• 權限服務

（3）組織類服務

• 組織管理服務
• 組織機構管理服務

（4）授權類服務

授權服務：綁定/解綁角色權限，綁定/解綁用戶角色，綁定/解綁用戶和系統，綁定用戶和組織機構。

（5）鑒權類服務

• 登錄鑒權服務：登錄方式配置、登錄風控和登錄鑒權3個業務能力
• 其它訪問鑒權：負責外部應用訪問內部服務的鑒權

（6）認證類服務

認證服務：包含個人實名認證、組織實名認證和人證資質審核3個業務能力。

（7）系統類服務

系統管理服務：負責系統的增刪改查

參考鏈接

平臺級SAAS架構的基礎：統一身份管理系統

關于SaaS平臺中應對多租戶模式的設計—權限設計

本文@ wweiru 原創發布于人人都是產品經理，未經許可，不得轉載。

題圖來自Unsplash，基于CC0協議