今天整理一個企業信息化建設初期經常會遇到的基礎平台建設和應用集成案例。雖然我頭條上大部分文章都在談雲原生，微服務，DevOps等内容，但是對于很多信息化建設剛起步的企業，更多的還是解決傳統業務系統整合，基礎平台整合方面的問題。這些問題往往都是實際的業務場景和問題驅動的。

比如一個企業已經發現了人員組織用戶這些基礎數據各個業務系統都在使用，需要統一，這個時候不是去馬上建設MDM系統，而是應該優先考慮4A和門戶集成。

企業在信息化建設一般都會上一套OA系統，在OA系統實施完成後陸續上類似供應鍊，CRM，财務等業務系統。那麼這個時候要解決的關鍵問題就是業務系統之間的整合，基礎數據的統一，一些技術能力類似流程引擎如何避免重複建設的問題。

我在前面談私有雲PaaS平台的文章中也多次談到，當構建平台 應用的整體建設模式時，最基礎的就是4A 流程引擎的平台能力，其次就是通過單點和門戶實現的統一入口。這些簡單的平台建設和能力整合，往往會給企業IT帶來更快速的效果和收益。

我們這次分析的企業實際具備一定的代表性，都屬于信息化建設的初期階段。随着企業業務快速發展，信息化建設和投入也逐步加大，而在公司内部信息化建設過程中出現兩個迫切需求需要解決。

其一是各業務系統信息流，業務流需要一個統一平台進行整合，以提升IT投入資源複用和發揮信息價值。其二是應用系統不斷增加，系統間交互頻繁，需要有一個統一的服務集成和管控平台，解決常說的信息孤島問題。

項目建設目标和範圍

本次項目的建設目标為基于SOA參考架構和業績平台 應用的信息化建設思想，在建設OA系統的同時，為企業搭建統一的流程管理平台，SSO中間件和ESB平台。同時實現業務系統和平台層能力的集成和整合，并适應後續公司業務系統的快速發展和建設。

具體來講實際包括了四個方面的子目标：

1.建設OA系統建設，實現高效協作和溝通，同時建設OA系統各功能模塊 2.通過ESB中間件與業務系統進行融合，打造系統集成平台 3.通過SSO中間件實現單點登錄和4A管理 4.通過整合報表工具，構建數據決策平台

為了實現上述目标，整個項目又分為了兩期進行建設，具體的建設範圍和内容可以分為如下幾個方面。

項目需求分析和理解

在談項目整體建設方案前，需求分析和理解實際是一個重要内容。即你對項目的目标和範圍如何理解的，這些項目建設範圍如何通過需求分析映射到你最終的建設方案和建設内容上面去。問題-》方案之間的邏輯映射就是需求分析的關鍵。

因此當時在整理整個方案建設的時候，我專門增加了一頁分析内容。

經過前面的需求分析頁說明，再過渡到項目建設方案，整個邏輯關系就更加清楚了。在最終給出解決方案的時候，客戶也更加容易映射到具體的需求和目标上面。

在需求分析中給出了平台 複用的思想。這個思想即SOA 雲計算的思想，通過雲計算來實現共性技術能力的下沉和平台化，通過SOA思想來實現應用系統的集成和整合。

上面這個圖實際我用過很多次，可以看到解決傳統的煙囪式系統建設問題不是簡單的SOA集成，而是應該是SOA和雲計算思想的融合。

雲計算的思想不是等你建設完成後再來考慮集成，而是一開始就集中化建設共性技術能力，建設完成後再進行能力開放給上層應用使用。當共性的技術平台能力從單個業務系統中抽取出來後，你會看到業務系統會變得更薄。

業務系統變薄後更加容易進行單體到微服務的拆分，這也是我在談雲原生和微服務的時候經常談到的，你要做微服務，首先要做技術平台能力下沉，先将技術能力和平台從原有的業務系統中剝離出來，這是微服務化的前提。

整體架構規劃

基于項目目标範圍和前面的需求分析梳理，給出整個項目建設的架構規劃，這個規劃仍然是體現了平台 應用建設思想，最終通過門戶進行上層的統一整合。

這個本身也是當前大部分信息化建設初期建設思路。差别的地方的是有些是隻建設4A和門戶，有些是建設MDM主數據，有些是4A MDM主數據 SOA共同建設。

集成架構規劃

上面這個集成架構相當重要，基本說明清楚了HR系統，LDAP，4A，流程引擎和業務系統之間的基礎數據集成關系。

在這裡我再強調下裡面的一些重點。

在HR裡面是人員組織的概念，而在4A裡面已經是用戶和賬号的概念。對于一般企業來說往往在4A或門戶裡面也有管理組織和人員。這裡面的差異是HR系統隻管理正式組織和人員，而虛拟組織，外部人員等管理都放在4A系統裡面進行。

流程平台的基礎用戶信息，崗位角色信息應該來源于4A系統。但是流程平台為了自己流程設計的需要往往還會自己建立角色，一般會稱為流程角色，僅僅用在流程平台中。

對于4A系統也管理賬号授權，但是注意這個授權僅僅是管理到一個用戶賬号能否使用或訪問某個業務系統，比如張三能否訪問CRM系統。如果授權能夠訪問，才把張三的用戶信息分發到CRM業務系統中。

當CRM系統獲取到張三用戶信息的時候，還需要在CRM系統中僅詳細的菜單級别的功能權限和數據權限配置工作。

注：對于某些4A系統往往可以做到将業務系統中的權限管理也全部集中化，即對于業務系統中的細粒度權限也在4A系統中完成。但是這個實踐效果不太好。一個重要原因還是業務系統的權限模型比較複雜，特别是涉及到細粒度的數據權限控制時候，很難做到标準化抽象。

部署架構規劃

部署架構簡單來說還是要保證高可靠性，無任何的單點故障。

數據庫一般涉及到集中化存儲，如果沒有集中化存儲，那麼可以考慮材料類似Mysql的Dual Master架構方案，這個方案直接采用服務器的本地磁盤。

對于負載均衡和集群，既可以采用類似F5等硬件負載均衡設備，也可以采用HAProxy軟件來實現負載均衡。如果整個應用涉及到對外暴露接口或移動手機APP的訪問，那麼一般都需要設置獨立的DMZ區。在DMZ區可以獨立再部署一套ESB總線或者僅僅部署Nginx來實現代理轉發。

統一流程平台建設來說就是企業内部私有雲PaaS平台的一部分。

流程平台是将各個業務系統中原有的流程引擎全部剝離出來統一規劃建設，形成統一的流程建模設計，流程運行，流程監控，流程績效評估的一個管理平台。

流程平台是一個多租戶的PaaS平台，其租戶就是各個業務系統。

流程平台的集中化建設不僅僅是降低了業務應用的構建成本，更加重要的是實現了業務組件采用統一标準的流程設計建模标準和方法，流程執行和管控機制。這将為後續基于工作流引擎平台實現端到端的流程整合和監控，流程績效分析打下堅實的基礎。

流程平台整體架構和集成設計

流程平台一般需要和HR系統，4A系統進行對接，提供提供統一流程平台所需要的一些系統管理功能。主要是給統一流程平台管理員使用，包括基礎數據管理、登錄管理、權限管理、日志管理等功能。在前面也談到了在集成後，往往在流程平台還需要維護自己的流程角色，以滿足流程設計和建模的需要。

流程設計是統一流程平台的核心功能模塊，主要包括流程模闆管理及可視化設計器、流程編譯工具、流程部署工具。

流程運行主要包括流程的運行内核、流程觸發器、待辦待閱處理器、工作委派處理器、任務指派處理器、業務單據狀态更新處理器等。此模塊在設計時要充分考慮并發能力、異步處理能力、穩定性、大數據處理能力。

流程監控用于管理統一流程平台運行及對各流程運行情況進行統計分析。包括統一流程平台自身的狀态監控及其中運行的流程的狀态監控，主要包括狀态監控、流程修複、流程幹預、統計分析等功能點。

流程引擎設計的重點

在分布式的架構中，流程引擎和權限引擎也不适合分離構建，兩者之間的耦合度相當高。一個好的流程引擎首先要依賴于一個完善的權限模型和架構，其中包括了細粒度的數據權限控制等。

流程引擎中會産生動态權限控制。動态權限和靜态權限的區别是靜态權限是固定的，而動态權限是跟随流程節點的執行動态變化的。如當你處理到某個流程節點的時候，你對某個工單有查看權限，但是一旦審核或處理完成後，該權限将被自動回收。這是對靜态權限的一個重要擴展。

流程引擎的活動節點需要參與人。參與人可以是具體的人，可以是崗位，可以是角色，也可以是直接上級的某個角色。參與人往往是一個抽象的概念，在最終流程執行的過程中會最終定位到一個或多個人。在處理靜态功能和操作級權限的時候，往往定義到具體的角色和角色組就足夠用了。但是在考慮和流程引擎結合的時候，需要進一步定義用戶組。用戶組是多維度累加後的一個概念，舉個例子來說項目管理員是角色的概念，而某個組織某類産品的項目管理員即定位到具體的用戶組，如市場部消費類産品項目管理員。

在流程執行過程中映射到具體的參與人一般有兩種做法：一種是活動節點隻配置到角色，即隻配置到當前節點由項目管理員處理。在實際的工單中有具體的組織信息，有具體的産品線信息，因此根據映射可以明确的映射到某個工單是需要定位到哪個組織哪個産品的項目管理員，即用戶組。在這個用戶組裡面往往可以定位到具體的一個人。如果還定位到多個人則可以處理為流程搶先處理機制。如果某個流程隻涉及到根據組織進行劃分，則有第二種不需要用戶組的做法，即所有的人全部放到角色裡面，流程在執行過程中首先映射出具體的人員，然後根據組織ID或上級組織ID對人員進一步進行篩選即可，這種方法的可行之處主要在于本身人員信息屬性中就帶有所屬組織信息。

工單和流程模塊是一種完全的松耦合關系。一個工單根據類型的不同挂多個不同的流程模版，而多個工單也可以同時挂接同一個流程模版。因此工單和流程模版之間需要有一種支撐這種松耦合的關系表。即實現工單和流程之間的一種映射。對于流程模型而言，關鍵的内容是流程模版，活動節點，連接弧和路由信息，活動節點對應的參與人信息，路由事件（前 後）相關信息等。這些信息在流程啟動後又涉及到具體的實例信息，如流程實例信息，活動節點産生的任務實例信息等。

對于不屬于一套完整的快速開發平台産品的流程引擎，最好的方式就是隻管流程，而不管任何和表單相關的數據。包括在流程處理環節中可能涉及到的需要新補充填寫的擴展字段等，這些内容最好的方式就是都放給應用側來處理。流程引擎可以提供調用接口，但是不要去建模、存儲和處理這些數據。

對于企業私有雲PaaS平台中的流程引擎，實質是BPaaS的一部分内容，體現了流程即服務的思想。流程和應用完全松耦合開。在這裡流程引擎必須要支撐内部的多租戶，而租戶就是外部的多個業務系統或應用模塊。在多個業務系統之間需要考慮流程引擎本身的數據，權限等各方面内容的隔離性。

流程引擎需要有完善的條件節點和表達式節點的定義，在這裡涉及到工單中的任何屬性都可以作為表達式節點的計算條件參與到具體的計算和路由分支的選擇。同時對于複雜的場景，在路由發生前和發生後還需要支持對外部服務接口的調用，外部接口服務是一個完整的業務邏輯觸發，在這種情況下一個工作流引擎已經實現了部分BPM服務編排的内容。

再次強調下BPM是在工作流引擎之上，更加強調的是端到端流程整合，業務流處理和服務自動編排，對于頂層的BPM流程下鑽後才是具體的審批流處理。

4A是指：認證Authentication、授權Authorization、賬号Account、審計Audit，中文名稱為統一安全管理平台解決方案。即将身份認證、授權、記賬和審計定義為網絡安全的四大組成部分，從而确立了身份認證在整個網絡安全系統中的地位與作用。

4A平台功能架構

在我們自己的産品規劃裡面實際4A平台和流程平台是融合在一起的，在前面也解釋過兩者的關系相當緊密。一般的4A平台主要還是實現統一的用戶，賬号管理，統一認證和單點登錄，統一的門戶建設等。

門戶建設和集成

對于統一門戶建設來說本身又包括多個方面的内容，最基本的是需要實現統一認證和單點登錄，其次是門戶需要能夠做到Portlet的靈活定義和配置。

各個面闆能夠靈活定義配置，能夠直接配置面闆對應的底層數據源或接口。

對應門戶首頁或工作台可以靈活定義，不同的用戶或角色登錄系統後都可以看到不同的工作台界面布局和内容。這些也是我們常說的門戶基本能力。

單點登錄和集成

單點登錄的一個重點還是動态Token機制，從門戶登錄鍊接到其它業務系統的時候，需要傳遞Token，業務系統再拿到Token後調用4A服務進行驗證，驗證通過後自動化初始化Session信息。

實際可以看到在當前微服務架構下，由于各個微服務本身可以獨立部署，那麼從應用集成角度仍然存在類似單點基礎這種思路的應用，以進行獨立部署微服務的Session信息初始化。

多級權限管理和控制

對于常規的4A平台，一般控制到一個用戶是否能夠訪問某個系統這個粒度，對于用戶能夠訪問系統裡面的哪些菜單一般是在業務系統的權限管理模塊進行配置。

對于我們自己的4A平台，在前面已經提到實際思路是将業務系統内部的系統管理和權限管理功能全部移出，形成一個統一的内部PaaS技術平台。這個時候就必須實現多級權限管理能力。這個能力包括了如下幾個點。

其一是業務系統本身的菜單，操作，各類資源的定義全部在4A裡面進行。其次是對于用戶能夠操作業務系統裡面哪些菜單，哪些資源也都在4A系統定義。同時4A系統還能夠定義細粒度的數據級權限。

當業務系統裡面的系統管理和流程引擎全部剝離後，業務系統就隻剩餘各個獨立的業務功能模塊開發，在這個時候将單體拆分為獨立的微服務就更加容易。

雲服務總線是我們自研的輕量ESB總線産品，既實現傳統的WebService接口服務的集成，各種協議轉換和适配，同時又支撐大數據集成，大文件傳輸集成。

具體的功能架構如下：

在上圖中可以看到，整個SOA服務總線架構包括了服務總線（ESB業務服務總線、數據服務總線、技術服務總線）、BPM、規則引擎、元數據、服務目錄庫、基礎管理、服務管控幾個方面的核心内容。具體描述如下：

業務服務總線：由傳統的ESB承擔業務服務的注冊和接入、服務能力的共享。其中包括了服務鑒權、服務路由、服務代理、消息事件管理、消息數據映射等基本功能。為了方便遺留業務系統的接入，增加了對各種消息轉換，協議适配等功能。

數據服務總線：實現數據服務能力開發和數據集成，對于數據服務總線的實現需要借助傳統的ETL數據交換與集成能力，以及ESB業務服務代理能力共同來實現。數據服務既包括了結構化的數據庫數據交換和集成，也包括了跨業務系統的大文件傳輸和集成。

技術服務總線：實現PaaS平台的各種技術服務能力的注冊和接入。由于技術服務本身的大數據量，高并發特性，在整個大的總線功能架構中需要采用一種輕量的服務總線模式來實現和管控。

SOA服務目錄庫：雖然在整個SOA總線功能架構中涉及到數據總線，業務總線和技術服務總線等多方面的總線能力，但是最終都需要通過SOA服務目錄庫進行統一的服務發布。

管控治理體系

整個SOA管控治理體系覆蓋服務識别，定義，設計，開發，測試，部署上線，運維的服務全生命周期管理。同時在橫向又分為了過程支撐，服務域，業務域三個維度。

在平台 應用的服務化構建模式下，需要根據SOA治理的思想建立服務全生命周期管理體系、規範和流程。真正讓應用開發商，平台能力提供商能夠圍繞SOA服務化思想進行服務接入和注冊、服務申請、服務開通、服務消費、服務運行監控的全生命周期管控體系。

歡迎關注@人月聊IT， 也歡迎關注同名公衆号，後續更多技術資料，原版ppt等的分享隻在關注公衆号後留言分享。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!