統一業務後台架構如何設計？

01-09

公司的各條業務線每上線一個產品都單獨開發一個後台管理系統，以便於跟蹤線上的業務使用情況和解決線上問題，這樣的話重複工作很多。如果做成集中式的，由於各個業務線的數據源是獨立的，使用許可權要做隔離，代碼層面也不容易做許可權隔離。如果做成分散式的，需要將公共的部分做成一個服務，其他每個獨立上線的業務接入這個服務，但這個接入用什麼方式去做，以及這個公共頁面的訪問許可權和業務數據的操作細粒度控制如何去做還沒有想清楚？有沒有好的設計思路，或者你們是怎麼做的？

很好的問題，稍微上點規模、分業務線/產品線/事業部管理的公司都會面臨此問題，尤其是業務快速擴張期。自己所經歷的公司也面臨過類似的嚴重問題。

業務後台是集中式還是分散式都有其道理，一方面從公司管理層面、運營層面、研發層面必須考慮各種成本，另外一方面又要滿足互聯網公司各業務線創新、試錯、快速上線的不同需要。務實及折中的做法是：集中式為主+分散式為輔結合的形式。

大的設計指導原則及建議：

1、避免重複造輪子

2、在公司層面與客戶關係管理相關的核心資源必須統一集中管理，包括商戶/用戶/合作夥伴等等的資料信息。

3、與公司核心業務運營流程相關的系統必須集中統一管理。一個典型的例子是第三方支付公司的用戶管理、商戶入網、商戶對賬、商戶清結算等。

4、與公司經營分析等相關的業務系統數據需要及早考慮集成及集中管理。

5、必須減少業務人員、運營人員多系統切換的成本，例如：要記錄不同系統管理後台地址、用戶/密碼。要適應不同系統的界面風格、操作邏輯。

6、在產品/項目立項評審流程中加入對業務後台是基於統一運營平台還是單獨開發的評審點，以兼顧公司層面統一管理需要和各業務線個性化需求、工期、創新的需要。

基本上所有的業務線都會希望自己能夠對業務有絕對的主控權，也會低估自己開發的難度，因此都會選擇自己做。

技術架構的一些建議：

1、在公司層面基礎技術框架統一併復用

管理後台的操作風格風格統一。

管理後台所採用的技術框架盡量統一。

管理後台的基礎框架及基礎功能盡量統一。

其中基礎功能包括：組織架構、人員許可權（功能許可權、數據許可權）、菜單管理、菜單許可權、單點登錄、工作流、操作日誌等與業務無關的功能。

具體到那些業務功能需要作為基礎功能提供，根據業務實際情況確定。

以上基礎功能，盡量能夠作為公司級blank項目的基礎功能，以便於其他業務線需要單獨的運營後台時在其基礎上快速創建。

2、業務後台Portal

業務portal提供對各個業務後台集中統一入口，包括：

a、整合公司組織架構、員工信息，為各業務系統提供統一的視圖。

b、提供員工與各個業務後台的用戶、角色的映射，不用到系統許可權級別，只需要到是否有許可權訪問對應的業務後台。例如員工登陸後，有哪些業務系統的入口。

c、提供各個業務後台的單點登錄功能

d、提供與公司其他核心公共服務的統一介面。例如與客服系統、財務系統、簡訊網關等。

這裡指的portal不是指商業軟體的portal解決方案，商業軟體portal設計思路有值得借鑒的地方，但作為業務後台portal，核心還是業務本身，沒必要搞得太複雜。

業務後台portal的價值一方面為各個業務後台提供統一的入口，避免運營人員記錄一堆密碼的問題，更重要的是降低各個系統用戶管理的隱形成本。

例如系統用戶對應的員工離職後，其賬戶的刪除、停用。單一系統相對好說，如果公司有多個系統，再加上與人力資源的離職流程銜接存在問題，則怎樣及時清除過期的賬戶、停用非活躍的賬戶則存在較大的挑戰，也是諸多風險的溫床。

3、公用業務服務SOA化
可以考慮採用dubbo+zookeeper等SOA框架來實現服務集中統一管理。

我個人的感受

如果是信息化或IT應用剛剛開始迅猛發展的話，務必要有前瞻意識，多了解一些企業架構的理論（Togaf cobit)，可以心裡有大概的方向跟目標。如果是應用都七七八八搞完了，也跑得比較成熟了穩定了。那這個過程是痛苦的而且很折磨人的。
我覺得大家的思路或方嚮應該都是差不多的 SOA架構數據流+BPM構建業務流+Portal構建呈現面
只是不同的企業和應用現狀不一樣，所以有個性化的地方。 @梁川說得很清楚，大部分的工作在於標準化，統一化。只是這個過程也是很折磨人的。
做這事最大的前提是要有高層領導支持，看得見未來的效益。要不，很難推行下去。技術和工具反到是其次了。因為成熟的SOA相關的中件間 portal BPM應用已經是越來越成熟
這是一條長征之路。