问题-》方案之间的逻辑映射就是需求分析的关键。在需求分析中给出了平台复用的思想。这里面的差异是HR系统只管理正式组织和人员，而虚拟组织，外部人员等管理都放在4A系统里面进行。在DMZ区可以独立再部署一套ESB总线或者仅仅部署Nginx来实现代理转发。流程平台是一个多租户的PaaS平台，其租户就是各个业务系统。包括统一流程平台自身的状态监控及其中运行的流程的状态监控，主要包括状态监控、流程修复、流程干预、统计分
今天整理一个企业信息化建设初期经常会遇到的基础平台建设和应用集成案例。虽然我头条上大部分文章都在谈云原生，微服务，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平台建设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等的分享只在关注公众号后留言分享。
