ESB作用 

       中国企业信息化经历了从无到有、从有到多、从多到散的过程，如今的后信息化时代面临着系统整合、优化IT架构、提升IT价值的新问题。随着现代企业经营理念的转变，在竞争加剧和IT发展的驱使下，企业开始朝着实时型的管理模式发展。原有的分割、零散系统将阻碍企业成为实时企业，因此想要具备实时反应能力的企业对信息系统的整合提出了前所未有的高要求。

       AEAI ESB是数通畅联自主研发的核心产品，ESB 应用集成平台能够消除信息系统之间的“信息孤岛”情况，集中进行应用管理维护，打破系统壁垒，实现各系统间数据、功能的互通，提高系统使用的便捷性。从v3.5版本开始主推K8S云平台分布式Cloud云ESB服务/数据总线平台，为企业制定各项集成规范，实现各监管、认证等系统，以标准化的方式进行集成，为后续IT建设奠定基础架构。

整体介绍

       ESB企业服务总线作为集成龙骨满足应用、数据和业务等集成需要，应用集成如统一认证、单点登录等主要实现业务系统间的对接；数据集成如主数据治理和数据分析等，通过ESB实现数据的聚合以及分发；业务集成如业财一体化等，实现企业业务之间的互联互通。在集成的过程中，ESB的作用至关重要，它连接着上下游业务系统，构建了数据集成传输的通道，是企业信息化建设由无序到有序、由散乱到规范、由点对点到总线式的有效工具与手段。

产品设计理念

       AEAI ESB服务总线最大的技术特点在于它是一个完全面向企业级的中间件解决方案，可以构建在企业现有的网络框架、软硬件系统之上，基于适配器组件技术，把数据、接口、协议、消息、文件都进行统一封装，采用引擎把它们图形化串联起来，构建数据集成、应用集成的可视化流程，实现数据传输交换、异构系统对接。

产品整体定位

       ESB企业服务总线核心功能是消除信息系统之间的“信息孤岛”情况，集中进行应用管理维护，打破系统壁垒，实现各系统间数据、功能的互通，提高系统使用的便捷性。传统模式的ESB是传统中间件技术与XML、Web服务等技术结合的产物，提供了网络中最基本的连接中枢，是构筑企业神经系统的必要元素。

产品功能介绍

       ESB企业服务总线在实际项目中主要用于各业务系统之间的集成，集成包括数据集成、应用集成以及业务单据集成等等，ESB企业服务总线主要包含三部分：ESB设计器、SMC管理控制台以及Server运行环境，ESB设计器用于服务以及集成流程的开发，可以直接将服务或者流程部署在Server当中，并通过前端管理控制台SMC来对服务以及流程进行管理，并进行监控统计分析。 

       K8S云平台是目前公司核心产品的主推部署方式，通过云平台实现ESB部署，可以提升部署效率，特别是针对集群式、高可用部署，云平台具有天然的优势。云平台部署模式在满足常规部署的同时，也提供了对于服务器资源的监控、运维的辅助，能协助运维人员快速进行服务器升级、扩容、启停等操作，降低运维难度。

解决问题

       目前大多数企业的信息化现状尤其是集团企业面临困境——信息竖井，企业信息化的过程中，形成了很多的信息孤岛，信息孤岛割裂了信息系统间的互联互通。如何让企业的系统间互联互通、打破信息孤岛、制定集成规范，让各IT系统相互组合、形成合力、提升信息化的价值，一直是困扰企业领导者的头疼问题。

消除应用孤岛

       信息孤岛割裂了信息系统之间的互联互通，被割裂的信息系统无法有效对公司经营、管理、决策形成统一的视图，对公司长期、高速发展的战略形成了一定的阻碍。统筹规划全局的信息基础与应用平台，在统一化、集成化的基础架构与平台之上，整合遗留的应用系统，推进及保障企业的业务战略落地。

提升生产效率

       实现无边界的业务、信息流体系的打通。通过监管系统搭建、数据采集交换等手段，为集团人、财、物等资产综合管理提供有效的支撑，同时通过系统建设倒逼组织布局、业务流程、管理制度的问题，规范业务操作流程，实现统一的系统监控和安全管理，达到企业业务全局的一体化管控，提高生产效率。

降低出错机率

       大量且重复性高的工作，会占据企业和员工的时间，不仅给员工带来不必要负担，还会导致效率低下。对于信息化的企业来说，将原来复杂和重复劳动的工作交给信息化系统批量处理，减少人工方式的介入，能够降低出错机率，提高工作效率。同时，将人力资源释放出来，去做更有价值、更具有创造性的工作，从而推动企业高质量发展。

涉及方案

        在数通畅联ESB总线平台是核心产品，可以跟其他产品套件组合使用，形成不同针对方向的方案，可以满足绝大多数的应用场景。在实际项目中，可根据企业项目的不同需求/性质，将产品进行相应的组合搭配，最终形成满足企业自身需求，独具特色的解决方案，能够快速解决企业问题，辅助企业决策。

统一集成平台

      在统一集成平台中，ESB应用集成平台自带集成样例可以快速上手，丰富的数据适配、协议适配、协议接入、消息转换、消息路由等组件；MDM基础数据管理平台可以进行数据的清洗，管理和丰富。对企业组织、人员、客户、供应商等高度共享的数据进行统一管理，对需要的业务系统进行同步分发，使数据易采集、易理解、易分析，提高部门与部门之间的沟通效率。

       二者相结合形成主数据治理方案，可以满足企业各个应用系统间数据共享与功能集成的需求，帮助企业解决数据整合的问题，推进企业信息化建设。

统一身份管控

       随着信息化的迅猛发展，各个企业也加快了信息化建设并引入大量的业务系统用于企业的业务管控。而随着业务系统的逐步增多，各个业务系统之间的组织、岗位、用户也变得愈加难以统一，企业中缺少统一的人员信息管理。由此我们公司的统一身份管理平台+应用集成平台结合的统一身份管控方案应运而生。

        IDM作为统一身份管理平台，实现了5A管控，即应用管控、统一用户、统一认证、统一权限和统一审计用于解决企业的多应用无统一管控的局面。而ESB应用集成平台，是一款强大的应用集成产品，配合IDM与其他业务系统进行数据对接，使得统一身份管控方案的灵活性更高。

基础数据治理

      随着企业业务迅速发展，需要支撑业务运转的信息系统越来越多，各系统之间的数据分散、重复，未完全形成业务闭环，数据孤立不能互通，数据统计不一致，企业主数据（组织、人员、岗位客户、供应商、产品、项目等）不能共享，数据不完整，缺少关键基础数据。

       作为数据交换平台，支持应用间批量数据交换和数据库间的数据交互，包括数据的抽取、转换和导入操作。不需要向不同的业务系统请求主数据的获取、同步，只需要通过ESB进行数据分发、下发等操作即可获取这些数据，帮助企业数据整合或数据中心建设。

集成底座方案

        集成底座是基于IDM、MDM、ESB三个核心产品组合打造的一套解决方案，主要解决企业信息化建设过程中业务系统打通以及基础业务集成整合的问题，通过构建企业集成底座，实现各业务系统间的统一认证，保证业务系统访问的一致性；实现各系统基础数据的同源，保证数据一致性的同时为后续复杂的业务集成、财务集成等提供基础数据支撑。

       其中IDM平台基于5A管控体系实现统一用户、统一认证、统一授权、统一审计、统一应用管控等安全管控；MDM通过支持组织、岗位、人员等主数据的同步分发，实现主数据的标准化，实现全生命周期的主数据管理；ESB作为集成通道，通过API管理将业务系统接口注册、代理到ESB平台，并通过平台实现集中监控、认证、限流、报警等功能，在满足IDM、MDM以及上下游系统的集成管理的同时实现服务接口的集中化管理。

数据中台方案 

       数据中台是基于公司的三款核心产品DAP、MDM和ESB组成的解决方案，主要实现基于数据治理分析的中台建设，通过MDM将企业内部的基础数据标准化、规范化、整合化后，由DAP进行数仓建设以及最终数据分析的可视化展现，ESB通过数据集成完成整个数据中台的主数据分发和数仓的数据汇聚。

       数据中台主要是针对企业的数据进行管理，其中包括了基础数据和业务数据，在管理过程中会为不同职级的用户赋予角色权限，在数据管理的过程中不同角色需要各司其职，共同实现数据中台的数据管理办法，保障数据的科学性和规范性。

产品优势

        数通畅联的产品并不是从一开始创造出来时，就十分的完美无缺，而是通过不断的升级优化，通过完成一个个项目深度挖掘问题加以解决得来的，不断与时俱进跟K8S无缝结合、主推K8S云平台模式提供分布云ESB模式。AEAI ESB功能非常强大、扩展性的灵活和多功能性，既可以通过图形化的拖拽方式设计流程，还可以通过地址对流程进行访问及测试，可以快速实现设计的功能。

敏捷应用集成

       支持服务注册、应用集成，支持集成场景的配置化，通过SMC配置集成场景，满足推、拉、定时等集成方式，可以更加快速、更加方便地实现业务系统间的集成，并支持邮件、微信、短信等多种预警机制。

        AEAI  ESB应用集成平台负责实现异构、分布式系统之间互联互通，实现服务API治理以及数据传输交换。通过ESB预置的各种适配器组件，连接现有各孤立应用系统，以图形化、拖拽方式构建集成流程和服务，提高应用系统集成工作效率，降低异构系统集成风险。针对未来可能出现的业务需求变更，在应用集成平台上进行动态调整，实现各应用系统之间的集成策略平滑升级。

性能易用强大

       ESB应用集成平台具有易用性、开放性、标准化、安全性、扩展性、实用性和高可用等特性。云ESB提供了丰富强大的组件堆，如：Http Rest、Soap、Web Service、Rest Service、FTP、数据库操作、消息队列、主题收发，可以满足客户绝大多数的业务场景。通过AEAI 设计器，开发人员使用优雅的方式和极少的代码即可完成整套流程的设计。

具有可开放性

       开发的流程可对外发布，也支持外部服务调用，提供服务源码，所有底层源码封装在jar包中，提供完整的技术框架，可深度学习。数通畅联软件本着开放的理念，产品源码直接打入Jar包，自带集成样例，支持远程调试；支持各种各样的服务质量等级和通信模式：同步(例如SOAP)和异步(例如MQ) 两种通信模式，请求/响应、队列、点到点以及发布/订阅模式，各种交付保证，集群支持。

性能稳定安全

        服务、流程支持用户名/密码、认证流程、IP白名单等机制，可以按应用进行安全策略配置，支持通过服务代理扩展安全认证。底层预置缓存处理机制，优化流程稳定性，满足多服务、多流程同时运行的需要，服务流程支持大数据量、高并发的使用场景。

       支持Web服务和HTTP/Rest服务用户名/口令的身份认证机制，且支持原服务和代理服务之间身份信息的自动二次封装；支持Web服务、Rest服务通讯安全保障，包括白名单、黑名单、IP地址、用户名&密码等多种身份验证机制、传输消息安全性及完整性等，支持HTTPS；服务管理通过权限分离实现管理控制台的权限控制，支持基于角色的功能权限、数据权限进行资源隔离。

价值分析

产品的IT价值往往不是可以量化的或是直观展现出来的，更多的是偏向于技术层面的价值，看不见、摸不着，却是真实存在着的。从IT层面来说，AEAI ESB可以在企业信息化建设过程中搭建一套稳定的、标准的、可持续的集成框架，满足企业业务集成的需要，同时为后续信息化的稳定发展提供强力保障。

1优化体系架构

确保企业核心系统（财务、生产、OA、HR等）实现信息系统互联，满足集团信息共享需求，避免信息孤岛形成。统一系统架构及协同标准，单一系统变化对其它系统影响极小，符合未来业务发展需求，支持插拔式信息应用扩展/替换，为后续信息化建设提供支撑。

2提高集成质量

AEAI ESB组件的丰富性可以满足客户的绝大部分业务需求，可以帮助开发人员简化基础代码开发的工作量，降低开发难度，也减少了代码出错的几率。另一方面，基于AEAI ESB规范化的特点，开发人员在开发过程中可以参照标准，优化程序的设计结构，提高项目的交付质量。

3加快交付速度

向导化开发、基于流程设计的方式、动态热部署技术、组件的复用，可以为开发人员屏蔽很大部分的基础代码编写，让开发人员更多的关注业务需求，从而大幅度加快开发效率。从用户的实际利益出发，通过复用内置的组件可以大幅度减少开发工作量，间接地减少企业人工成本，使企业更好地实现资源分配。

4强化数据治理

随着信息技术的飞速发展，企业对互联网环境下数据的呈现提出了更高的要求。AEAI ESB企业服务总线与AEAI DAP数据治理分析平台结合，实现数据抽取、加工、转换，构建企业数据中心，在分析数据可视化的基础上，实现了资产可视化。以图形化的方式呈现资产数据，为用户提供更加直观的数据呈现形式，更好地展现资产数据之间的相互关系，挖掘出数据背后隐含的信息，有效地提高资产管理效率。

ESB应用集成平台作为系统中间件可以实现集成业务处理，监控系统间消息流动，管理系统间交互的业务服务。国外的知名ESB公司有Oracle、IBM等，这些公司在集成领域相较于国内的ESB厂商起步较早，但是这些公司的ESB产品不能满足国内公司的需求。而作为本土诞生的数通畅联产品家族的ESB应用集成平台，会更加适合国内的集团型公司。

随着计算机技术、网络技术和通信技术的发展和应用，企业信息化已成为品牌实现可持续化发展和提高市场竞争力的重要保障。而ESB应用集成平台可以打破企业的信息孤岛，和MDM基础数据平台进行结合形成统一集成平台，清洗、治理企业的主数据，使企业的主数据具有唯一性、准确性、一致性、及时性，促进企业的信息化建设。

ESB与业务逻辑的关系

ESB是"中介逻辑，而不是应用逻辑"，应用逻辑应当放在应用程序服务器中，这样扩展性会更好

开源ESB介绍

1.Apache ServiceMix

         Apache ServiceMix 是一个灵活的开源集成容器，它将 Apache ActiveMQ、Camel、CXF 和 Karaf 的特性和功能统一到一个强大的运行时平台上，你可以用来构建自己的集成解决方案。它提供了一个完整的、企业就绪的 ESB，完全由 OSGi 驱动。

2.OpenESB

      OpenESB (NetBeans ESB) 项目实现了一个运行期企业服务总线 (Enterprise Service Bus:ESB) 使用 JBI (Java 业务集成) 作为核心基础。OpenESB 可以让你集成企业应用与 Web Service 松散地连 接成复合的应用程序。这使得你可以无缝地组合与拆解该复合应用程序，并认识到一个真正面向服务架构 (SOA) 的优点。

3.MuleESB

      Mule ESB是世界上使用最广泛的开源企业服务总线（ESB）产品，已拥有超过数百万的下载量，以及来自世界各地数十万个开发人员，很多世界五百强企业选择Mule ESB作为企业集成平台。通过Mule，企业可以在短时间内轻松地创建并集成应用服务，Mule ESB消除了系统集成的复杂度，使开发人员能够在异构系统和服务之间，轻松地构建出高性能的集成应用。

开源方案对比

API,ESB,ETL对比

      API 集成成本相对较低，只要具备一定的代码能力，无需第三方工具，即可由研发团队按照数据共享需求对系统进行 API 封装，为下游新业务供数。但直接在源库上构建 API 对性能的影响也比较大，且 API 通常会有 Rate Limit，难以支撑海量数据读写。此外，API 基本上只能对单库发布数据，难以跨库操作（本身脆弱，调用频率高了500，数据量大了崩溃）。

      ETL 也是过去很长一段时间里的主推方案，这种方式的优势在于，不需要写太多 Java 代码或服务代码，而是通过工具或脚本的方式，来实现数据向下游系统的抽取复制。ETL 的局限性主要体现在不易管理上，因为太过简单且无法复用，导致每个新起业务都需要不少数量的 ETL 链路，最终散落在企业各处。

      缺乏统一管理的的下场，就是痛苦的意大利面式结构状态。面对这一痛点，二十年前就出现了不错的架构解决方案——用 ESB/MQ 将数据都推到中央化的企业消息队列、服务总线上，然后将企业各个需要共享数据的系统，通过 API 和 Service 的方式连接起来，省去了多个系统之间两两交互的重复工作，降低了系统之间的对接成本。但整体成本仍较高，所以多用于商业化方案。而且开发复杂、系统耦合较高，性能又较低，很快就退热成了“明日黄花”，被类似于 Kafka 这样的分布式开源产品所取代。

       大约十年前，Kafka 迅速流行起来，大量企业开始基于 Kafka 实现数据集成。但由于 Kafka 并非为此而生，最初只是一个分布式的日志存储，所以其架构设计特性更倾向于高并发、高性能、分布式。相较于数据集成要求的链路短、耗时短、延迟短，基于 Kafka 的 ETL 架构因节点较多，反而显露出长链路、数据容易中断、排查难等特性。如果想要实现，还需要做很多 Java 代码开发，使用复杂度很高。

      最近十年，各种中央化数据平台打得火热，特别是以 Hadoop 为主的大数据平台，以及传统数仓、新一代数仓等代表，这一类方案的表现是将企业内散落在各个数据孤岛的数据集中化到一个平台里，从而实现通过中央平台统一获取需要的数据。但由于其技术架构多基于 Hadoop，本质上还是一个以离线分析为核心场景的技术栈，多用于对历史数据进行洞察、分析，数据不够实时，无法支撑对实时数据要求较高的一些 TP 型业务场景。看下linkis

完全使用    开源软件搭建企业信息系统已经不再是不可能的事情，下图从企业信息应用的各个层面，直观的描述了如何使用开源软件来按步骤搭建企业信 息系统，满足各应用层面的信息化需求。下图中的每一个应用单元内的软件均为开放源代码软件，他们遵循着不同的使用许可规则，企业用户在使用时，只要遵循各 软件的许可规则，即可放心使用。

各软件使用许可规则说明：

原文《集团企业数字化转型信息化技术架构规划与实施方案》WORD格式，主要从技术架构设计原则、信息化技术架构蓝图、信息系统应用技术架构（SOA和微服务架构、微服务架构实现路径）、私有云平台架构规划（规划总体原则、基础网络管理、服务器和数据库管理、存储管理、终端管理、私有云平台架构）、灾备体系、信息安全建设。适用于售前项目汇报、项目规划、领导汇报、招投标技术文件使用。

来源网络，旨在交流学习，如有侵权，联系速删，更多参考公众号：优享智库

目标与理解

技术架构是支持数据架构和应用架构落地的基础，根据股份公司对信息系统技术的架构的整体要求，集团公司在此基础上进行补充说明，以保证技术架构可以支撑将来业务发展的需要。

技术架构规划总体目标：在股份公司总体技术架构的框架内，为电气化集团建立一个具备高可用、高安全、高性能、易管理的信息化技术支撑环境，承接并确保上层应用架构规划成果的落地实现，助力集团公司信息化水平的跃升，推进业务应用深度集成，打造坚实可靠的信息化基础支撑环境，同时保障业务操作处理的连续性和时效性。

信息化技术架构为集团公司的应用系统架构提供必要、有力的技术支持，为已经在运行以及未来上线的应用系统提供统一、共享的服务，总体架构设计策略如下：

• 立足当前系统建设现状，适应集团公司中长期业务发展趋势的，同时要对已有硬件设施充分利用，并制定切实可行的总体设计方案和实施步骤。

• 考虑技术满足网络安全、数据完整、有效性等数据安全要求。

• 统一规划建设，统筹分配系统资源，建立运行环境安全可靠的系统基础平台。

• 充分考虑软硬件发展趋势，具有一定的新技术吸纳能力和扩展能力，使系统资源能够随业务扩张而逐步增加。

技术架构设计原则

• 安全性

技术架构必须是能够提供访问控制能力的环境，以确保业务关键信息的完整性与保密性；设计中应尽最大可能减少因基础设施故障而造成正常业务无法正常进行的现象的发生，同时设计中还应该注重信息安全体系的建设，提高信息基础设施的整体安全性。

• 可扩展性

可扩展性是指当未来应用系统的业务量增加时，技术架构能够扩展以适应更多用户、交易与更多数据处理的能力。可扩展性应该通过尽可能扩展己有的系统来实现，而不是必须替换己有系统。可扩展性通过硬件、软件与应用等方面提供；

• 灵活性

技术架构必须能够满足新的服务需求，而不需要对架构进行完全重新设计或进行超出正常维护时间之外的重大修改。获得灵活性的方法是依靠组件化的设计架构；

• 可靠性

技术架构中应采用高可靠的产品和技术，充分考虑系统的应变能力、错能力和纠错能力，确保整个技术系统运行稳定、可靠；

• 可用性

系统的可用性指业务应用系统每天能有多少小时，每周有多少天，每年有多少周可以为用户提供服务，以及这些应用在发生故障时可以多快恢复工作的时间。整理制作郎丰利1519

信息化技术架构蓝图

从应用系统的技术架构、应用系统的管理架构、数据中心、机房环境管理、灾备和信息安全角度进行集团公司技术架构的设计。下图是集团公司技术架构的整体蓝图。

图6.3-1：集团公司技术架构蓝图

信息系统应用技术架构

SOA和微服务架构

（一）SOA架构

SOA 将应用程序的模块化组件通过定义明确的接口和契约联系起来，接口是采用中立的方式进行定义的，独立于某种语言、硬件和操作系统，通常通过网络通信来完成，但是并不局限于某种网络协议，可以是底层的TCP/IP，可以是应用层的HTTP ，也可以是消息队列协议，甚至可以是约定的某种数据库存储形式。这使得各种各样的系统中的模块化组件可以一种统一和通用的方式进行交互。

图6.4-1 SOA架构逻辑

（1）服务层是SOA的基础，可以直接被不同的应用所调用，从而有效控制系统的人为依赖性。

（2）在设计过程中，各种组件的开发、部署形式都可以引用SOA的思想，以原子服务、组合服务的方式构建业务模型，在业务流程编排、符合应用阶段，原子服务（模型）被不同的流程和模块所调用，服务之间通过简单、精确定义接口进行通讯，而不涉及底层编程接口和通讯模型。

（二）微服务架构

微服务架构倡导将软件应用设计成多个可独立开发、可配置、可运行和可维护的子服务，子服务之间通过良好的接口定义通信机制， HTTP协议有跨语言、跨异构系统的优点，当然，也可以通过底层的二进制协议、消息队列协议等进行交互。这些服务不需要中心化的统一管理，每个服务的功能可自治，并且可以由不同的语言、系统和平台实现。

图6.4-2 微服务架构

总之，SOA架构模式是为了保证现有信息系统的正常使用，在信息系统正常使用的情况下，继续沿用原来的架构进行升级，并且采用SOA数据总线的模式进行数据接口的开发和维护。微服务架构是一种继承性、可维护性更高的架构方式，对于全新开发的信息系统，建议采用微服务架构的方式，以保证系统具有更高的灵活性和适应性。考虑到股份公司技术架构要求，因此建议集团公司采用“SOA和微服务”相结合的技术架构方式，如下图所示：

图6.4-3 分布式技术架构

微服务架构实现途径

（一）微服务架构的使用场景

对于工程行业，微服务架构由于其部署的灵活性，可以应用在很多的业务场景，大大简化业务人员的工作量。

场景1：工程施工现场信息采集和沟通：工程施工现场的图片、视频可以通过移动终端的微应用APP，直接上传到总部；施工现场的纸质文件资料也可以随时通过移动终端转化成图片文件上传到总部；

场景2：集团实时经营数据：可以通过微服务APP移动终端直接传到总部，各种文件的审批、请示和汇报也可以通过微服务APP移动终端实现上传；同时，也可以通过移动终端实现对工程现场施工人员的定位，以及安全管理等；

场景3：…..

（二）微服务架构的实现途径

企业基于微服务架构搭建IT 系统，可以主要分为系统设计和微服务平台搭建两个部分，其中微服务平台搭建工作相对标准化，而系统设计部分则需要根据企业自身业务流程进行个性化实施。

图6.4-4 微服务架构实现途径

1）原有系统有效拆分

微服务架构具备“独立”特性，这种独立性是其性能优势的基础。在进行系统设计时，首先需要对公司的业务流程和后续规划进行统一，随后据此进行领域驱动设计。

此外，在应用架构变革的同时，团队架构亦需同步调整。传统架构下，企业IT 团队基本以职能划分，开发项目时需要不同团队之间的协作；而在微服务架构下，则需要围绕每一个独立的服务能力组建团队，从开发到运维形成完整闭环，从而保证开发效率。

2）组件集群高效管理（容器云平台）

微服务架构下，企业应用系统微服务组件数量可多达数百个，如何将这些微服务进行统一管理编排，以满足各种业务需求，是微服务平台架构的核心能力。

容器技术的发展使得对微服务的管理成为可能。近年来微服务的兴起，很大程度上得益于容器技术的发展。事实上，容器并非微服务部署的唯一选择，但容器由于其自身特质，非常适合作为微服务的载体，进行迁移、编排和后续治理、运维。

图6.4-5 容器技术架构逻辑

多云平台为微服务提供了资源能力（计算、存储和网络等），承载企业微服务的容器作为最小工作单元被管理平台调度和编排，实现有效的服务治理，最后通过API Gateway 对外提供微服务的业务接口。

私有云平台架构规划

私有云平台是用于支撑业务应用运行的基础环境和载体，包括机房、服务器、网络、存储等物理设备和配套的管理平台。技术稳定、可靠运行的能力，直接影响业务应用的高效顺畅运行。一般性的信息化技术的存放环境是在传统机房或者数据中心。

根据私有云平台需要提供的业务支撑能力，需要按照一定的等级要求规划私有云平台架构。按照私有云平台技术标准要求，推荐集团公司的私有云平台级别为T3（可并行维护级），要求可以在不关闭计算机硬件设备的情况下进行计划性维护，允许支撑系统设备任何计划性的动作而不会导致机房设备的任何服务中断。

规划总体原则

• 安全可靠性原则

基础设施的规划必须遵循可靠性的原则，规划中应尽最大可能减少因基础设施故障而造成正常业务无法正常进行的现象的发生。（如：因服务器或网络故障造成用户无法访问系统，进而无法进行正常业务的现象等）。同时，设计中还应注重信息安全体系的建设，提高信息基础设施的整体安全性，进一步保证数据安全。

• 先进成熟性原则

基础设施的规划应具有产品和技术先进性，先进的产品和技术是未来系统性能的保证。在信息技术飞速发展的今天，选择的产品和技术应具有一定的前瞻性，能够适应未来一段时间（3~5 年）业务需求及技术发展变化的需要。同时，尽可能兼顾产品和技术的成熟性，增强IT基础设施的整体稳定性。

• 开放与可扩展性原则

基础设施的规划应选择开放式的技术，满足系统间灵活的信息交互的需要。同时，充分考虑可扩展性，满足不断发展变化的业务和技术需求。

• 统一标准化原则

基础设施的规划应该坚持标准化的原则，采用业界公认的行业或技术标准，降低管理复杂度。同时，坚持统一化的原则，整个系统内的所有同类的IT基础设施应尽可能采用统一的标准。

• 经济性原则

基础设施的规划必须实用、经济，应该尽量利用现有资源，坚持在先进、高性能前提下合理投资，以期在成本最佳的前提下获得最大的经济效益和社会效益。

基础网络管理

• IPSec VPN网络架构必要性保证总部和分公司数据传输安全。总部和分公司之间传输的数据安全性要求较高，不适合在Internet上传输，通过VPN就可以解决数据传输安全的问题。解决专线数据传输成本较高的问题。VPN是在inernet上临时建立的安全专用虚拟网络，用户节省了租用专线的费用，同时除了购买VPN设备和VPN软件外，企业所支付的仅仅是向企业所在地的ISP支付一定的上网费用，同时也可以节省长途电话费用。VPN网络可以支持不用类型网络用户的接入方式，包括移动用户接入。分子公司、移动用户、商业伙伴都可以方便的接入公司的内网，方便业务使用。

• IPSec VPN的网络基础架构为了让网络基础设施更好适应集团公司的发展与数据传输需求，集团和分子公司之间通过VPN技术进行组网互联，利用组织已有的互联网出口，虚拟出一条“专线”，将组织的分支机构和总部连接起来，组成一个大的局域网。IPSec VPN最大特点是安全性高，主要体现在两方面：一是IPSec VPN隧道是要经过一整套安全参数（SA）协商，并得到隧道两端共同认可后才能建立的，即VPN隧道本身也是受保护的；二是在IPSec VPN中传输的数据不仅要经过加密处理，还支持数据完整性验证和数据源身份认证功能（支持像预共享密钥、数字证书和数字信封等多种认证方式），进一步确保隧道端点所接收的数据是没有被非法篡改，而且来源是合法的。IPSec VPN用户可以任意方式（如专线接入方式、PPPo E拨号接入方式，甚至传统的Modem、ISDN拨号方式）接入Internet，且不受地理因素的限制。所以，IPSec VPN不仅适用于移动办公员工、商业伙伴接入，也适用于企业分支机构之间站点到站点（Site-to-Site）的互连互通。

服务器和数据库管理

• 服务器和数据库管理目标自动收集服务器和数据库的性能参数，分析问题原因并在其影响其它资源之前做自我修复。

• 服务器和数据库管理范围 数据库管理：通过单个具有一致架构的平台，管理不同平台上的多个数据库，控制捕获的关键指标以确保其数据库正常运行，自动处理日常任务，提高生产率。 虚拟服务器管理：集中监视服务器虚拟和整合资源的性能和可用性，以实现高效和经济有效的 IT 操作。预配置的、可自定义的报告和警告。管理自动化：利用应用程序级自动化降低操作的复杂性，减少人工干预和依赖性的需求，提高 IT 基础设施的效率、可靠性和可服务性。 系统性能：自动收集系统的CPU、内存吞吐率、带宽利用率等信息，自定义的警告、报告和异常分析，跟踪异常事件，简化管理。访问管理：保护应用程序和数据库，跟踪登录进程，并应用防止未授权访问的策略，提供有关用户活动的安全相关信息，跟踪敏感访问尝试。

存储管理

• 存储管理目标 高效、自动、可扩展、跨平台存储系统管理，确保存储信息的可访问性、可用性和存储性能。 郎丰利整理制作。

• 存储管理范围 存储虚拟化：通过存储虚拟化技术，建立数据的跨平台、跨系统的高速共享系统，为分散的系统提供统一的数据平台。 分级存储管理：根据预先设定的策略，存储管理系统能够自动和透明将文件从在线存储移动到近线存储，从近线存储备份到磁盘系统。存储资源管理：存储资源管理能够列出各服务器的存储使用情况，可以确定存储优先级，并可以对数据的移动、归档、删除做事先评估。 SAN管理：集中对SAN资源进行管理，响应存储请求和分配读写权限等。利用SAN的高速通道，实现数据高速共享，符合数据恢复、管理等要求。 数据保护：能够对网络中所有的客户机（无论是笔记本、PC还是服务器）进行数据归档、备份、加密和恢复等操作。

终端管理

• 目标实现软硬件资产自动收集和追踪、系统补丁和软件自动分发，远程用户支持，确保终端的最佳配置。郎丰利整理制作。

• 范围软件分发管理：支持PC、笔记本、服务器以及PDA软件的分发和补丁的部署，确保软件部署和管理的一致性和可靠性。操作系统安装：能够快速的在“裸机”上安装、配置一个操作系统，并能自动安装预定义的应用软件集合，降低管理员工作量。远程用户支持：管理员可以通过安全的连接方式，远程查看、控制终端，并可以定制被管理的终端的数量。 资产管理：自动发现，硬件和软件资产清单、配置管理、软件使用监控、软件许可管理、资产跟踪以及提供各类报告。

私有云平台架构

• 集团公司云管理平台建设规划

建设私有云是集团化企业IT发展的趋势，多数企业从旧系统架构向云服务转变过程中代价较高过程较长， 集团公司应利用信息化重新规划建设的契机，以云为标准，建立云计算和云服务的领先优势。

图6.5-1 基于云的网络拓扑结构

1）云计算模式选择：由于集团目前应用系统部署在租赁的私有云架构上面，建议选择基于IaaS、PaaS的云服务交付模型作为架构规划的模式：

图6.5-2 云服务交付模型

2）云架构概念模型：集团公司云服务管理中心对覆盖容灾中心和各下属子公司前置环境云服务进行全面管理。

3）集团公司云中心架构：建立基于虚拟平台的云服务环境，同时部署服务门户、服务总线统一管理云服务资源。

• 计算中心作为云服务的核心资源中心、运营监控中心和服务管理中心；

• 计算中心云环境主要支持行业共享系统的运行，兼顾为行业用户提供基础设施服务；

• 资源总线应支持对云环境和传统环境的综合管理。

图6.5-3 云服务中心架构

4）集团私有云搭建步骤：建设企业的私有云，就要求企业把自己的数据共享中心构建成一个高可扩展性、超大规模、高可用性、成本低廉的数据共享中心。通话虚拟化、网格计算、自动化管理等云计算技术，逐步把企业内部的数据共享中心建设成面向企业内部系统的具有公共云平台特性的云计算平台。

第一步：根据业务目标设置云计算目标

同业务人员、开发人员沟通对云计算业务目标的讨论，制定清晰的业务目标，比如需要支持哪些业务、业务流转效率提升目标、业务提供方式如何进行改变等；

第二步：定位私有云环境的工作负载

评估当前的工作负载，以确定哪些适用于私有云的此快照将用于设置针对私有云的总工作负载百分比的长期目标。在短期内，它还将用于识别初始云部署的工作负载。

第三步：采用企业基础设施的投资组合，计算资源虚拟化

绝大多数私有云都基于虚拟机(VM)的部署，利用虚拟软件对服务器虚拟化，作为私有云的基础；

私有云并不简单等同于虚拟化加上易用的虚拟机部署平台。它还在包含网络在内的各层面实现了灵活性，需要利用软件定义网络(SDN)对网络进行虚拟化；

存储是另一项需要高度可扩展性的层级。对存储虚拟化，需要在软件中监控各项操作，便能顺利使用额外的存储。

第四步：选择合适的私有云云端管理软件

单纯汇总集成上述组件并不能构成私有云，你还需要有云端的管理产品。今天主流的软件供应商都有其云端方案，但是并不是所有产品都可以让你运行在内部的私有云上。例如，Microsoft Azure仅可用作公有云。而OpenStack、Oracle Cloud和VMware Integrated OpenStack等则允许你在个人站点上运行私有云上的产品。

第五步：实施管理

在内部部署私有云解决方案，并对部署后的方案进行验证。同时，需要培养内部的私有云IT管理人员，需要具备有关存储和网络，以及云平台本身的专业知识。

5）集团公司采用私有云计算平台实际建设意义

• 整合资源提高利用率：云计算通过虚拟化技术将分散的资源聚集起来，集中统一加以利用。有效解决传统基础资源利用低的缺点。降低对数据中心机房的电力、制冷、空间消耗，进一步实现绿色节能。

• 提高IT资源部署效率：云计算的引入能够显著缩短硬件资源、平台环境、应用系统的部署周期，实现以“随需即取”的方式获取系统部署所需的基础资源和运维服务资源。

• 促进IT服务标准化：通过定制基础资源、平台环境的标准模板，结合运维管理服务模板，依靠自动化技术及云管理平台来交付规范的、有质量的服务。促进公司技术、运维的标准化运作。

• 提供更便捷的IT资源和服务：通过云管理平台可由集团公司通过出租服务的方式为下属单位信息化建设提供便利。甚至可以提供IT基础和运维的“全托管服务”，帮助新成立单位快速建设信息化应用。

• 促进IT建设的发展变革：使传统意义上的数据中心从原来的成本中心转变成服务中心。

灾备体系

根据《中华人民共和国网络安全法》中规定需要对重要系统和数据库进行容灾备份。另外国家《信息系统安全等级保护基本要求》（GB/T 22239-2008）三级要求中有关灾备的要求：

• 应提供异地数据备份功能，利用通信网络将关键数据定时批量传送至备用场地；

• 应根据数据备份的需要对某些介质实行异地存储，存储地的环境要求和管理方法应与本地相同；

灾备体系建设现状

• 集团公司尚未系统开展业务中断影响分析；

• 灾备技术体系有待完善；

• 灾备相关人员组织及岗位职责有待完善；

• 风险上报、预警、危机响应等相关流程有待完善；

• 灾备日常管理规范及机制有待完善。

总之，集团公司灾备体系建设尚处于起步阶段——即T4.5级别，但是不完善。

级别

名称

定义

Tier 0

无异地备份

在数据中心本地存放备份介质，成本低、管理方便，但存在数据丢失问题，恢复时间很长，一旦数据库发生灾难后介质安全无法得到保障，会造成所有数据均无法恢复

Tier 1

PTAM（Pickup Truck

Access Method）冷备份

将备份数据通过交通工具运到异地容灾中心进行周期性备份

Tier 2

PTAM结合热备份中心

建立备份中心，数据中心的数据备份每天通过交通工具运输到异地备份中心存放

Tier 3

网络备份

包含了第二级的所有功能，同时一些数据子集通过通讯线路传送到备份中心存放，可避免交通运输对数据备份所带来的危险和不便，同时对备份的对象、时间、数据量的大小也具有一定的灵活性

Tier 4

批量在线数据库镜像

与日志在第三级的基础上，增加数据库的镜像与日志备份

Tier 5

两中心，两阶段确认

在有主机运行的远程备份中心，通过远程磁带库备份和远程电子日志备份，一旦数据中心出现灾难，可以通过一套专用的系统进行数据恢复，利用备份中心的主机替代业务处理，大大减少了灾难恢复的时间。但是这个级别的备份技术复杂，成本较高，同时数据仍有部分丢失

Tier 6

远程磁盘镜像与自动切换

包含了第五级的功能，数据中心和灾难备份中心通过高速通讯链路进行磁盘镜像，一旦灾难发生，数据丢失量极少或没有。此方案要求灾难备份中心配备数据中心部分或全部的专用设备，较第五级而言，通讯成本高，灾难恢复时间进一步缩短

灾备规划及策略

图6.6-1 电气化局集团异地灾备方案

针对不同的单点故障或灾难，建议集团公司采用不同的应对措施：

• 服务器电源采用UPS和冗余电源多路供电的方式；

• 对于单机硬件故障，需通过采用冗余硬件设备来防止单点错误，包括CPU、网络设备、磁盘等；

• 对于整机、系统软件及应用软件的保护可以通过构筑群集系统来保证；

• 对人为因素所造成的故障要通过加强对人员的培训和标准化操作与管理来减少和避免；

• 对于灾难性事故，根据不同业务的关键程度设计不同的灾难恢复机制；对于连续性要求高的关键核心业务系统，未来可以考虑建立灾备中心，将数据实时复制到备份中心；对于连续性要求较低的系统，可以考虑磁带备份的方式，将数据异地备份，并可以通过异地恢复的手段，在一定时间内恢复数据

ODOO是一款开源企业信息化平台。

包含CRM、电商、财务、仓储、零售、项目管理、HRM、MRP等。

Odoo采用模块化设计，因此集成了众多实用模块，并且提供应用商城。

基于Odoo定制开发模块是一件很快乐的事情。当然，前提是你足够了解她。

我们从OpenERP7开始，8,9,10,11,12,13,14,15, 我们将持续与Odoo相伴。

 进入ODOO实践专题

ThingsBoard是一款开源物联网平台。

包含设备管理、数据采集、处理和可视化等。

工业标准IoT协议：MQTT、CoAP、HTTP。

微服务架构，支持垂直扩展。

IoT网关、规则引擎。

 进入ThingsBoard实践专题

Node-RED是基于事件应用的低代码编程工具。

NR可以将硬件设备、API和在线服务以一种全新有趣的方式集成起来。

NR提供了一款基于浏览器的编辑器，通过拖拽区块的方式编写流程，也可以使用富文本编辑器编写JS函数。 基于Node.js开发的轻量级运行时充分发挥了事件驱动、非阻塞模型的优势。

 进入Node-RED实践专题

Go-View是一个Vue3搭建的低代码数据可视化开发平台。

该平台将图表或页面元素封装为基础组件，无需编写代码即可完成业务需求。

平台技术栈为：Vue3 + TypeScript4 + Vite2 + NaiveUI + ECharts + Axios + Pinia2 + PlopJS

 进入Go-View实践专题

FUXA是一款开源HMI-SCADA-Dashboard web平台。

FUXA不需要web编程知识即可轻松的创建工业web人机交互界面、SCADA、web应用和Dashboard。

支持OPC UA、Modbus、BACnet、Enternet/IP、SiemensS7、WebAPI、MQTT。 通过拖拽预定义的控件创建自己的可视化方案。只要有浏览器的地方都可以运行你的人机交互页面。

 进入FUXA实践专题

Metabase是一款开源数据分析可视化平台。

基于Java开发，部署简单，支持20+数据源，Github星超34k。。

可视化查询编辑器，只需要掌握很少的知识，任何人都可以通过界面自由查询数据。轻松创建和分享可交互的仪表板，支持15+可视化类型。支持创建模型，提升效率。

 进入Metabase实践专题

NextCloud是一款开源文件管理平台。

包含文件管理、外部存储、多平台支持等。

应用商城有众多应用。

可对接OnlyOffice，在线协作。

我们公司所有文档靠NextCloud管理。