1、平台时间格式和公共代码转换插件

2、平台组件集成Jenkins持续集成

愿景

在南宁地区打出我们团队自己的品牌产品

课程计划

1、内部群先做一次直播（初次体验）

2、南宁民大群做一次直播（获取问题）

3、南宁西大群做一次直播（获取问题）

４、南宁IT圈做一次直播（对外展示）

课程内容

课程主题：技术中台对外演示及公开课

计划时间：2020年5月30日晚上8点

对外方式：腾讯视频（具体会发出）

主讲人：罗小东（平台负责人）

课程体系：

1、技术中台当前集成介绍

2、技术中台演示（自动化代码生成+DevOps+K8S监控）

3、整体研发中台过程监控体系（机器人+平台监控+Prometheus监控）

4、DevOps自动化部署平台演示（自动化操作）

5、业务中台战略规划和设计（后期愿景–数据中台+AI产品赋能）

6、开源项目说明和部署操作

其它

稳步行进，在南宁打出自己的一定影响力，同时对外推广自己的产品。

随着技术的日趋成熟，云计算已经逐步替代传统IT技术成为未来移动互联网发展的基础和核心。对于运营商而言，云计算的应用对于系统的建设模式、运维管理等带来了新的机遇和挑战，成为运营商降低运维成本，数字化、智能化转型的重要手段。

面向未来，该运营商研究院将通过对网络技术、创新业务自主研发的推进、对运营核心流程的高端补充与支撑，提升整个集团的核心竞争力，实现企业价值最大化的研发使命，为企业提供全方位支撑。

大型连锁商超智能化转型所面临的问题：

数据服务中心：

1.目的：把其他150个系统分散在不同的业务体系的数据能够读取过来，同时保留及通知其他的系统。要求实时数据推送（如多渠道价格同步），多service交互。

2. 线下的中国门店有500多家，目前先把价格，商品详情，库存数量等变得的数字读取过来，再暴露给到其他的系统。

3. 后期会把其他的例如OA的数据，HR的数据也会纳入到系统里面去。

4. 要求数据能够实时更新，实时暴露。

5. 用微服务的形式去做,每个部分做成一个服务，他们目前有在尝试用spring cloud 在做

6. 数量非常大，尝试了用一个门店的数据就达到了1亿，了所以要求将来要具备处理1-20数据量的系统

7. 不能把数据和服务器放在外面，所以一定是要独立部署的，那么就要求我们解决没有阿里云的这些服务中间件我们如何保障系统的部署和运行通畅，以及安全问题。

8. 高性能,安全性,用户体验,运维服务.微服务平台可能与传统ESB （Enterprise Service Bus）有相似之处，解决方案可以参考ESB。另外，还需要实施方案，包括但不限敏捷实践、DevOps实践等。

面临的问题主要包含以下几点：

1、用户群体庞大，需要大量的基础设施，这些基础设施该如何有效管理；

2、IT系统整体架构庞杂，各子系统之间标准不一、各系统间数据不能互通和共享，网络环境、系统软件等比较复杂;

3、资源利用率低，大量服务器上的系统独立部署、运营，云化程度较低，不能实现资源的集中共享；

4、传统基于 IOE 架构的系统，新建扩容等周期长、硬件部署效率低、横向扩容困难，维护成本居高不下;

5、数据集中后运行规模庞大并呈爆发式增长，传统的计费系统以及数据仓储等系统架构无法满足现有业务的需求;

6、系统弹性扩展能力不足，基本没有微服务治理能力，目前开发的各个平台系统耦合程度高;

7、缺少智能化运维能力，在 AI 分析、应用安全等方面还面临一定的技术挑战。

微服务能力中台赋能企业AI敏捷落地

为解决以上问题，该运营商研究院牵手国内容器云计算领军企业Legendshop，根据企业在架构、技术、研发、运营、业务发展等方面的实际需求，打造了“容器”+“微服务”+“AI”的创新性解决方案，即人工智能应用研发平台。在这个过程中，Legendshop微服务能力中台为该运营商研究院数字化、智能化转型提供了强有力的技术支撑。

Legendshop微服务能力中台基于Legendshop领先的 Docker容器技术和微服务架构方案，以及 AI 引擎和大数据服务能力，为企业提供了大型应用微服务化运维和管理能力、容器集群管理、容器部署、服务运维、持续集成、持续部署、租户隔离、微服务治理、APM 性能管理、CSB 服务总线、大规模训练、数据分析、AI 模型服务等功能，赋能企业AI应用敏捷落地，助力企业数字化、智能化转型。

Legendshop微服务能力中台建设方案，具体包含以下几点：

1、使用Legendshop搭建的统一容器 PaaS 平台，将软件从底层硬件中解耦，提供更好的可移植性和速度，打造轻量、快速、高效、友好的服务运行及开发环境，极大的降低了运维成本；

2、将企业中原来的单体应用系统应用升级为微服务架构应用，实现多个微服务组件可以独立部署，通过统一通信协议互相连接，保证独立性和高可用性，同时简化了部署、监控、运维、治理与微服务应用生命周期的管理；

3、使用Legendshop先进成熟的 DevOps 产品，重新规划设计开发测试运维的工作流程，优化开发测试标准的同时将日常繁琐的重复性工作交由平台来自动化完成，包括源代码管理、自动化构建、自动化测试、持续集成、持续部署等，显著的提高了应用系统的开发迭代效率；

4、基于 Kubernetes 核心支撑能力，实现对于应用服务的灰度发布、滚动升级、弹性伸缩、故障自愈、配置管理、服务高可用等多种治理手段，提供了统一的企业IT管理平台，提高了企业IT管理效率；

5、基于容器和微服务平台提供大规模训练、一键部署、弹性 NoteBook、AI 模型服务、支持数据/模型集等能力。显著缩短训练、调整和部署机器学习模型所需的时间。不同租户间资源有良好的隔离性，可以快速处理 AI 需求，极大的增强了资源利用率；

6、具备高清晰度的权限管理，涵盖项目、用户、角色等多个维度，对用户操作提供完整的审计功能，保障系统数据安全。

运营商的核心系统是目前涉及用户数量最多、涵盖范围最广也是技术最复杂的IT系统之一，Legendshop微服务能力中台出色的产品交付能力，再一次证实了自身过硬的技术实力，与该运营商研究院的深度合作也是容器、微服务和 AI 结合的又一次创新和突破。

微服务电商平台Spring Cloud技术白皮书

广州朗尊软件科技有限公司

企业中台架构解决方案

一、 中台方案概述

中台架构的思想伴随着企业规模不断扩大、业务多元化而形成的，各个业务条线通用的组件进行沉淀下来，以服务的方式为各个业务系统提供核心的能力，真正发挥组件重用的价值。中台架构以K8S+Docker容器化技术为基础构建运行支撑平台，基于容器化技术的灵活伸缩能力数据集成、服务集成、数据利用、公共服务、DevOPS版块，形成企业级的数据中台、技术中台。

中台实例截图：

二、 中台总体框架

中台架构以容器化技术为基础，构建集成类、数据类、支撑类公共支撑版块，并配到DevOPS实现对全过程的敏捷支撑，总体框架如下图：

中台架构各个组件说明：

（一）PaaS运行平台：

（1）以Kubernetes为基础，进行深度融合，构建PaaS运行平台，能够实现对微服务、服务网关、节点、镜像、存储卷进行统一管理。

（2）建立起公共服务应用超市，能够提供各类型常用应用支持。

（二）服务集成版块：

（1）数据总线：通过各种数据适配技术，将各类型的数据接入并汇聚到数据凭条中，能够满足大批量数据交换的需求，支持灵活的容器伸缩机制，能够适应大规模数据的采集处理。

（2）数据目录：对数据中心、各个应用系统的所有数据资源建立数据资源目录，提供以目录的方式扁平化管理数据资源，并且提供对数据的全生命周期管理。

（3）数据标准：结合国家标准、行业标准、企业标准对所有数据资源进行标准规范化。

（4）数据质量：对数据集成过程、数据中心的数据资源，以数据标准为基础进行数据质量监测。

（三）服务集成版块

（1）DaaS数据服务：以“配置即服务”的思路，无需代码开发的方式直接将数据平台的数据发布成接口服务。

（2）服务总线：建立统一的服务总线，支持对企业内部服务、互联网服务、企业外部服务的统一管理。

（3）服务目录：以目录方式组织共享服务，实现从服务的开发、测试、编目、发布、申请、使用全过程的管理。

（四）数据利用版块：

（1）数据可视化探索：基于B/S方式对数据中心的数据进行可视化的数据展示，支持图表方式、表格方式、图文方式数据展示。

（2）智能全文检索：对数据中心的数据，包括结构化数据、非结构化数据（Word、PDF等），建立全文索引，实现数据的高效、快速检索。

（五）公共平台服务：

（1）用户认证服务：建设企业统一的用户认证服务，实现Web应用、APP应用的单点登录。

（2）应用认证服务：建设统一的应用认证服务，实现对各个应用系统的接入、服务访问进行安全认证

（3）统一权限服务：建立统一的权限服务，实现对各个系统权限信息的集中管理、分级授权

（六）DevOPS版块

基于PaaS平台实现从开发、到运维的全过程敏捷化，主要配套建设：配置管理平台、自动构建平台、自动化测试平台、统一日志平台、运维管理平台。

（四）中台运营体系

（1）中台管理平台：实现对平台建设的各个模块以及资源进行集中的配置、管理、使用等。

（2）管理规范体系

三、 PaaS运行平台

3.1 运行平台概述

以Kubernetes为基础，进行深度融合，构建中台运行平台，为应用提供灵活的、可伸缩的、高性能的运行环境，能够实现对微服务、服务网关、节点、镜像、存储卷进行统一管理。总体功能设计如下图：

PaaS运行平台截图：

3.1 公共服务网关

服务网关是所有应用系统对外访问的流量入口，能够实现各个应用的访问，以及应用之间的相互访问能力，并且整体提升访问的安全性。总体访问过程如下图：

路由网关策略管理界面截图：

（1）路由网关策略管理

（2）网关路由策略配置

（3）服务网关运行监控

3.3 应用运行管理

1.1.1 微服务管理

微服务管理是指对每个应用的微服务进行部署、配置、卸载、销毁等全过程的管理，完全实现基于可视化进行进行配置。

（1）微服务管理列表

（2）微服务创建

（3）微服健康检查

（4）微服务自动伸缩

1.1.2 配置项管理

对微服务配置文件的在线管理功能，能够对全局配置文件进行统一的管理，并且能够对修改后的配置信息动态的注入到运行的微服务容器中。

3.4 平台资源管理

1.1.3 资源申请审核

资源申请审核是指各个应用系统需要在PaaS平台部署的时候，需要提交资源申请，并由管理员审核后，才能进行部署，申请单设计如下：

1.1.4 域名资源管理

域名管理是指对需要挂接到服务网关中进行路由访问的域名进行统一登记管理。

1.1.5 存储资源管理

提供对应用所需要使用的磁盘的统一注册管理，提供对NFS、ClusterFS、CephFS的存储的支持，后期建设过程中，根据不同的需要可以考虑同时支持多种分布式存储系统。

1.1.6 平台节点管理

平台节点是指PaaS运行的服务器集群进行管理和监控，如下图所示：

（1）平台节点列表

（2）平台节点监控

3.5 镜像仓库管理

应用镜像仓库是指各个应用各自的镜像仓库，能够给各个应用提供镜像存储、使用能力

四、 数据集成版块

数据集成版块对数据的接入、数据的传输、数据的加载、数据加工处理、数据标准、数据目录、数据质量进行全方面的监管。

4.1 数据集成总线

数据中心数据来源于众多的渠道，主要包括企业内部数据、政府数据、社会公共事业运营商数据、互联网数据、物联网数据等，平台提供多种数据适配采集方式采集数据，将采集的数据进行预处理后，存储到数据中心，产品还提供统一的监控、管理、配置中心，实现对数据汇聚服务的可视化配置，集中式管理和全方位监控。

总体框图设计如下：

数据总线汇聚监控：

数据总线任务管理

1.1.7 数据采集适配

数据采集采用适配器模式进行设计，实现适配器的可拔插、可扩展性，目前提供了大量的适配器满足不同的数据源的需求。

1.1.7.1 数据库数据采集

关系数据库是目前使用最广泛的数据库系统，实现对数据库、数据仓库的全方位的适配是非常必要的。

n 支持国内外主流数据库：MySQL 、Oracle、DB2、Sybase、Sql Server、Informix、Derby、PostgreSQL、KingbaseES（金仓）、达梦等

n 数据库多种增量采集策略支持：时间戳方式、全表比对、增量字段标示、触发器方式、Oracle CDC、MySQL Binlog、SqlServer CDC、PostgreSQL Slony。

1.1.7.2 半结构化数据采集

数据汇聚过程中涉及大量的文件数据资源，主要包括文件格式数据和日志格式数据两种。

（1）文件格式数据

n 支持对多种格式的文件进行解释处理：文本文件、XML、CSV、JSON、Excel等

n 支持文件目录、FTP服务器、Samba服务器等中增量采集文件数据资源

（2）日志格式数据

n 支持文件目录、FTP服务器、Samba服务器等中采集日志文件数据，并增量的逐行解析日志数据内容

n 支持多种日志内容解析方式，如Log4J日志文件、系统日志、AWK、正则表达式等

Excel数据提取界面如下：

1.1.7.3 非结构化文件采集

数据汇聚整合系统支持文件目录、FTP服务器、Samba服务器采集各类型的非结构化文件数据（文档、图片、视频、音频、网页），并将文件存储到大数据平台中。并且支持2G以上大文件的采集、传输和存储，采用拆解包机制保障数据的可靠传输，同时还支持对文件进行压缩和加密处理。

1.1.7.4 接口数据采集

支持主动的采集业务系统提供的数据接口服务，并将采集的数据存储到大数据平台中。

1.1.7.5 消息数据接收

消息数据采集是指从消息队列中接收消息，并进行加工处理后，存储到指定的介质中。产品支持HornetQ、ActiveMQ、RabbitMQ、Kafka、ZeroM消息队列服务器的数据接收采集。

1.1.7.6 业务数据填报

数据报送是指将数据报送服务提供给业务系统、业务人员主动的将数据提交到数据报送系统，由数据报送系统将数据存储到大数据平台中。主要提供接口服务报送、文件数据报送和业务填报三种方式报送数据。

1.1.7.6.1 业务表单填报

业务表单填报是指采用类似Excel方式能够通过在线配置填报表单，并且分发给指定的人员进行填写相关数据的过程。

（1）填报表单设计：

（2）数据填报：

1.1.7.6.2 接口服务填报

“接口服务报送”是指通过定制数据接口服务给业务系统主动的上报数据。“接口服务报送”为方便业务系统使用，支持多种协议HTTP、SOAP、AMQP、JMS的数据上报方式，并且支持采用多种数据格式的进行上报，如XML、JSON、CSV、Excel等。

1.1.7.6 跨网数据采集

在涉及到安全要求比较高的部门的数据资源存储在内网，在数据采集过程中，对内网数据的采集、汇聚，支持以上各种采集方式，并且将采集的数据以文件形式通过安全边界。

产品提供跨网前置部署软件，能够进行数据的发送、接收以及人工数据交换，并且提供了数据的安全控制相关功能，界面如下图：

1.1.8 数据加工处理

1.1.8.1 数据清洗转换

大数据平台需要归集的数据分布在不同的单位，各自的标准规范不一致，在做数据汇聚整合时，需要对数据进行清洗转换。需要提供字段映射、数据翻译、字段拆分、字段合并、字段运算、数据范围过滤、字段过滤、数据条件过滤等数据清洗转换功能。

在数据清洗过程中，提供图形化、可视化的数据清洗配置，简化数据清洗过程和数据标准转换过程，数据转换过程效果示意图如下：

1.1.8.2 数据脱敏处理

大数据平台数据汇聚建设过程中，需要保障数据的安全，因为隐私或敏感数据的泄露，会对数据主体的财产、名誉、人身安全、以及合法利益造成严重损害。因此需要对某些敏感信息通过脱敏规则进行数据的变形，实现敏感隐私数据的可靠保护。

本系统支持多种的数据脱敏处理方法：替换、重排、加密、截断、掩码、日期偏移取整等

1.1.9 数据加载适配

采用数据适配技术接入各类型数据后，再对数据进行加工处理，处理后后需要将数据加载到指定的目标存储中，由于产品采用了数据抽象层技术，所以接收的任意数据都能够存储到多种目标结构中，包括：关系数据库、文件服务器、消息服务器、Hadoop等，如下图所示：

1.1.9.1 关系数据库加载

关系数据库是最常见的数据存储方式，并且支持多种入库方式：增量入库是按照产生增量顺序执行入库（入库表需要主键或指定主键字段）；追加入库是不断添加数据到入库表；刷新入库是删除入库表的数据后再执行入库操作；更新入库是按数据执行新增或更新操作（入库表需要主键或指定主键字段）

1.1.9.2 文件服务器存储

将采集到的数据转换成为XML、CSV、JSON、Excel等格式的文件存储到指定的文件服务器中（本地文件目录、FTP文件服务器、Samba文件共享目录）。

1.1.9.3 消息队列发送

消息发送是指将采集到的数据发送到指定的消息队列中，本产品支持HornetQ、ActiveMQ、RabbitMQ、Kafka、ZeroM消息队列服务器。

1.1.9.4 Hadoop数据加载

大数据存储负责将采集的数据经过清洗后存储到大数据平台中，大数据平台数据的存储主要采用HBase和HDFS进行存储。

（1）HBase数据存储

大数据存储子系统提供将结构化、半结构化数据存储HBase中，并且增量数据的存储。将已完成加工的数据，需要装载到大数据平台，可以通过以下方式装载数据

（2）HDFS数据存储

HDFS作为大数据平台的分布式文件系统，提供大文件的存储能力，大数据存储子系统能够实现将采集的数据存储为半结构化文件，如CSV、Text等。

（3）小文件数据存储

由于HDFS文件系统的数据块过大，不适合存储小文件（100M以内）的，但是在实际业务应用中，存在大量的小文件，需要用其他方式来解决，主要可以通过Hadoop Har小文件存储和HBase小文件存储两种方式。

1.1.1.2 全文索引库存储

本产品默认的全文库是采用ElasticSearch进行构建的，配置界面如下图：

1.1.10 可视化服务编排

由于数据采集的方式、标准众多，本系统提供了灵活的集成开发环境，支持数据汇聚过程的建模、开发、集成、部署、运行、监控、维护的完整生命周期过程管理。

n 基于B/S的可视化服务编排：提供众多数据整合、协议转换构件以及可视化的人机操作界面，只通过拖拽及配置即可实现用户信息交互的各种场景，最大限度的降低用户工作量。。

n 提供大量的服务模板：针对常见的业务应用场景，内置了大量的服务模板，采用向导式的参数配置即可完成服务定制。

n 支持远程部署、调试：支持对编排好的服务直接进行在线部署和调试。

n 提供统一的数据抽取、转换方案模板。各类业务数据的抽取和转换方案采用统一的设计思路实施，便于共享智慧，优化设计，方便维护。抽取方案采用结构化设计，将共性的功能规范为可复用模块。

数据采集服务编排子系统效果图：

1.1.11 数据汇聚监控

实现对数据采集过程、数据处理过程、大数据存储过程进行监控，统计分析数据采集量、入库量、异常数量等。

4.1 数据资源目录

以元数据为核心，以政务分类表和主题词表为控制词表，对信息资源进行网状组织，满足从分类、主题、应用等多个角度对信息资源进行管理、识别、定位、发现、评估与选择的工具。

信息资源目录体系也是管理信息资源，实现共享和服务的一种工具。通过规范的元数据与分类表和主题词表，可以方便地根据应用需要按行业、部门、地域、应用主题和其他使用目的变换出信息资源的各种目录。借助目录系统，可以对信息资源进行识别、导航和定位，以支持公众方便、快捷地检索、获取和使用信息资源。

产品提供了基于数据资源目录体系的从资源注册、审核、发布、申请、使用、授权的全过程管理。

（1）资源目录列表

（2）数据资源注册

4.3 数据标准管理

数据资源标准体系的建立是数据项目建设的基础。对所有数据标准进行统一规划、统一管理、综合利用，保障大数据平台与各业务系统数据之间的数据一致性、准确性、可靠性，打破系统之间的数据壁垒，整体提升数据质量，发挥数据价值。主要包括三种类型的数据标准：

n 业务术语标准：将业务中涉及的概念，以及概念关联的业务描述进行详细阐述

n 代码集标准：将可枚举的数据项进行完全的数据集定义，详细阐述数据的取值

n 数据规则标准：通过一定的业务规则进行定义的数据标准规则，可以通过表达式、脚本来进行技术描述

（1）数据标准管理功能

（2）代码集数据标准

（3）规则型数据标准

4.4 数据质量监测

通过“数据质量监测”实时对从采集到的数据进行数据质量检查，为大数据分析决策提供可信的数据支持，保证大数据平台能够提供准确、科学的数据。

数据质量问题来源于源数据系统、数据集成过程和大数据平台，任何一个环节出现数据质量问题都会造成数据分析结果不准确，实现对全过程的质量监测尤为重要。数据质量管理总体功能设计如下：

五、 服务集成版块

服务集成版对中台涉及的接口服务进行统一管理，主要包括：DaaS数据服务、ESB服务总线，并建立服务目录方式实现全过程管控。

5.1 DaaS数据服务

数据服务是将平台可连接的数据库资源以接口的形式对外提供服务，提供数据共享。产品提供了多种数据共享服务方式，界面如下：

1.1.12 SQL数据服务

按照指定的方式,执行SQL查询语句，并将查询结果返回给发布的接口。同时SQL语句支持模板写法实现动态的SQL语句。

1.1.13 组合SQL数据服务

组合SQL服务是按照指定的方式,执行主从SQL查询语句，并将查询结果按照主从关系返回给发布的接口。

1.1.14 数据表共享服务

数据表共享针对数据库单表结构或视图，根据配置自动构建语句查询，并将查询结果返回给发布的接口。

5.1 ESB服务总线

ESB企业服务总线主要实现对外部接口服务、互联网接口服务的路由代理，并且能够实现对服务的加工处理。

5.2 服务资源目录

以目录方式进行扁平化组织各类型的接口服务包括：企业内部服务、微服务接口、企业外部服务、互联网服务等，并且基于服务目录实现对接口服务的从编排到编目，再到发布、申请、授权的全过程管控。

服务目录展示效果如下图：

六、 数据利用版块

数据利用版块主要是对通过集成版块融合的各类型数据资源，进行数据的加工利用的过程。

6.1 可视化数据探索

数据可视化探索提供基于B/S的从数据定义、到可视化设计、再到可视化发布的一站式数据分析解决方案，开发过程完全可视化，无程序编码。

1.1.1 数据展示能力

（一）图表数据可视化

通过图表方式直接绑定数据，进行可视化展现，提供常用的各类型图表展示

（2）表格数据可视化

将可枚举的数据项进行完全的数据集定义，详细阐述数据的取值

（三）图文报告可视化

通过一定的业务规则进行定义的数据标准规则，可以通过表达式、脚本来进行技术描述

1.1.1 数据展示示例

（1）在线图表展示

（2）在线图表设计

6.1 智能数据全文检索

智能数据全文检索是以中文分词为基础，构建全文索引库，能够实现对结构化数据、非结构化数据的统一索引、统一检索。

七、 公共服务版块

7.1 统一应用认证

应用认证模块是对接入中台的各个应用系统进行身份认证，只有经过认证的应用才能进行接入访问。涉及的应用类型：

（1）APP应用：为每个项目的APP应用颁发证书，每个APP应用接入的平台都需要先进行应用认证，后续访问过程都需要携带应用认证后的Token，并且每隔30分钟需要进行更换Token，以进一步保障安全性。

（2）微服务应用：这类应用部署在中台中，微服务应用需要访问其他应用提供的服务

（3）业务应用系统：这类应用在接入也需要进行应用认证，采用证书+Token方式进行认证

7.2 统一用户认证

提供统一用户认证服务，能够为各个应用系统提供单点登录认证功能，支持Web端、后端应用、APP应用的单点登录认证能力。

7.3 统一权限管理

建立统一的权限服务，实现对各个系统权限信息的集中管理、分级授权，减少每个系统都需要重复建设权限、授权管理相关功能。

八、 DevOps版块

以中台架构为基础，构建DevOps体系，帮助开发人员、测试人员和运维人员在实现各自目标（Goal）的前提下，向自己的客户或用户交付最大化价值及最高质量成果的基本原则和实践。

DevOps需要建设相关配套工具设施进行最佳实践，主要包括：配置管理、自动构建、自动化测试、统一日志管理、运维管理等工具手段。

8.1 统一日志平台

实现对PaaS环境下的应用软件、硬件设备、主机、数据库、中间件等运行日志进行采集，实现日志数据采集、解析、加工、存储、分析、展现于一体的应用运行态势感知。产品支持集群化大规模的日志数据采集，并对日志进行预处理后，存储到大数据中心中，产品提供统一的监控、管理、配置、分析中心，实现对日志归集过程的可视化配置，集中式管理和全方位监控以及可视化的日志运行态势分析。

日志建设效果：

（1）日志总体展示

（2）业务健康评估

8.2 配置管理平台

基于目前主流的Git技术，构建配置管理平台，能够实现在线对配置库、开发库、发布库、文档库进行管理。

8.3自动构建平台

提供基于Gradle、Maven技术的源代码在线打包能力，与配置管理平台结合，从配置管理平台中来取源代码进行打包，并打包到Docker镜像中，为PaaS提供镜像。

8.4 自动化测试平台

提供基于Web端的在线可视化测试管理能力，提供多种测试引擎，包括：接口测试引擎、Web浏览器测试引擎、APP测试引擎，能够对多种应用类型提供在线的、可配置的开展集成测试、验收测试工作，自动化测试完全基于容器化技术构建，能够进行高效的全自动化测试。

8.5 运维管理平台

对应用系统、运行环境的运维提供基于ITIL全过程的运维保障支持。

九、 产品方案特性

（一）赋予业务应用快速创新能力

中台为业务应用的开发提供了简单、高效的应用运行环境，并且提供了大量的每个应用都涉及的公共组件的服务，减少了业务应用开发工作的复杂性，使得应用只需要关心差异化的服务，突出产品特性、提升细节体验，能够实现业务应用的快速迭代。

（二）形成丰富的公共服务能力超市

中台为公共服务组件提供公共服务超市，输出统一化的平台服务和能力，可以形成良性高效的生态，避免资源的浪费。能力的使用者利用“超市“可以知道方便的了解内部的所有能力，能力的开发者可以响应市场的需求，开发出真正需要的能力来填补空白。

（三）更好的规划、管控、协调能力

能够融合中台的运营管理体系，对各个应用从规划、建设、到部署实施、日常维护等全程进行有效的管控。

（四）创新应用系统开发模式

以“大中台，小前台”的应用建设模式，中台提供了主要的公共服务，应用系统只需要关注自身的定制化的业务需求。并且基于微服务架构进行开发，能够实现业务过程的高效迭代。

（五）有效的数据真实性和一致性保障

中台提供了功能强大的数据清洗工具，帮助用户从源头控制数据质量，同时提供数据共享对账和变动提醒功能，在中台无法与直接推送数据给共享系统的情况下，有效保障数据的一致性。

十、 项目案例介绍

10.1 广州地铁中台

广州地铁中台建设有服务总线、数据总线、资源目录、PaaS平台、公共服务（应用认证服务、用户认证服务、统一日志服务）等内容，建设成为了一个集应用、用户、服务、数据整合共享枢纽，并且将相关能力SaaS化，提供个各个应用开发商以及内部研发团队使用，为后续项目建设提供了有力支撑，进一步减少的项目建设成本。

该项目目前已经接入整合了大量的业务系统，包括：资金管理系统、维修信息系统、施工调度管理系统、人力资源管理系统、企业统计报表系统、办公自动化系统、物流管理系统、基建物流管理系统、工作证管理系统、票务管理系统、车站收益系统、工程设计管理系统、项目投资管理系统、数字认证平台系统、信息服务部文档平台、运营总部技术信息服务平台、运营应急物资管理系统等，共计87个应用系统。

项目建设逻辑架构图如下：

10.2 大数据归集平台

广州市政府大数据平台建设单位为广州市信息化服务中心，项目中实现实现对政府、物联网、社会及互联网等渠道的数据进行统一的归集，并交换到广州市政府大数据资源中心。大数据归集子系统需要提供统一的监控、管理、配置中心，实现对数据归集服务的可视化配置，集中式管理和全方位监控。

项目主要接入了广州市全市的企业库相关数据、互联网数据（招投标网站、广州市多个政府网站政策类数据）、系统日志数据等，总体架构如下图

文章带有强烈的个人观点和成长经历，针对的是政务项目，而非互联网，参考即可。

背景介绍

一直网上查找相关的学习资料用于实践并落地服务化，分布式，美好的资料与真正落地实践是两个一样的层次，真正能落地的资料较少，这过程中有很多的问题，能不能解决，团队、个人能不能支撑这个过程，都是一个问号。其中很多讨论的就是Dubbo和Cloud的选型的问题，这里表达一下自己的实践经验的感受与选型，我有我思。

微服务是一种架构设计，但是我这里说的更多的是服务化，主要针对的是传统项目转过来的过程，所以，以下文以服务化来代替微服务。此处针对的是政务型项目，而非互联网项目，自己在政务项目经验较多，而互联网项目项目经验、管理经验较为缺乏，比如团队管理政务项目更偏向于人才培养，技术积累，可以使用信息化项目管理体系管理项目，但是互联网项目可能有些并没有这个条件，比如一个项目周期2至4个星期，项目管理体系还没有起来就可能结束了。

为什么拥抱Dubbo而排斥Cloud体系，并不是因为技术不好，也不是因为技术过分崇拜，更不是因为国内外，或者阿里系，Spring系之类的，而是自己在建立个人学习开发平台的过程中，

自己的经验和体会表达，原开始使用的是Cloud技术，后来转变成Dubbo技术，这一过程中的体会，分以下几个点阐述：

团队和人才市场有一定的局限

从大一点的来说，Java的工程师培养一直以来都是SSH或者SSM体系入门，同时MVC层次更是深入Java开发人员思维，这些几乎是每个Java都是非常熟悉，接触的项目最多架构。大量的培训机构，都是这几套，几乎是这10多年Java软件培育的结果，这为在后期招聘，运维，团队组件上规避了极大的招聘风险，团队风险。

从小的来说，目前接触的团队，几乎都是单体项目转过来，开发过程，不管是异常处理，问题处理，都有极大的经验值，还有习惯，思维，这些都有极大的促进项目的开发效率，而这些都是建立在【习惯】的思维上，在服务化的路线上，如果选型得当，几乎可以省去很多的培养成本，适应成本。

这点不能站在开发者的角度，常常听开发者说这个技术没问题，但是团队来说，团队的角度考虑，服务化一个人开发跟一群人开发是天与地的区别

怎么使用旧的资源，更低成本的实现服务化，服务化之后是否能提高研发效率，解决业务问题，解决项目管理问题，解决团队开发效率问题，怎么引入新的技术，怎么引入DevOps，又要团队能接受，成本能接受，同时又要降低抵触情绪等，才是需要思考的，相对而言，技术点就比较容易考虑了。

回到我们的技术点上，我们来看一个技术例子，Dubbo技术几乎是无缝切入MVC工程，或者SSM工程，这几乎是归功于Dubbo的传输方式，相对而言，Cloud的HTTP+JSON传输，在这过程工程之间的交互几乎是灾难，复杂的数据不能传输，传输效率过低，接口管理困难，而在Dubbo这块，利用JavaAPI的特点，接口调整便直接提示异常，一目了然（也有弊端，这靠规范来管理），也规避了这部分风险，省去成本较高的接口管理（并不是不需要管理，更多的建议是规范）。

在之前实践的过程中，这步做得倒还是比较成功，技术上遮蔽了注册这块（即这些都已经配置好），前期融合的Java工程，Dubbo技术还是比较容易，有些项目组成员开发了近半年，依然感觉在做单体应用，甚至没有体会到这个是在分布式应用或者微服务。更有甚的，服务化项目已经准备上线了，有开发拿着一篇PPT说，”你看这样的技术架构，我们是不是也考虑一下“，而他说的那个PPT的架构，已经是两年前做的设计，并且实践成功落地。

业务场景限制和资源限制

业务场景是设计人员必须要做的考虑，团队不管是技术能力强还是资源充足也好，但是结果是否能实际的完成业务开发，服务于业务这才是价值体现。业务场景有哪些？

需要考虑怎么样的场景，这需要针对具体的业务实现，而往往针对于企业来说，至少软件公司来说，同步也要考虑实际团队的场景，能力，能产生的价值，而不是团队都是初级工程师，偏偏要规划出高级产品设计，更不要项目周期短，却规划出一个N多组件的微服务项目，服务组件全套用上。项目开发最终的目标不是为了微服务那套治理，更不是那整套的监控，也是不是那一个个组件，更多的为了业务服务，为了提供更高的生产力，本质是产生价值。

项目经费，周期，团队，硬件等资源限制，怎么能更好的在有限的场景里面服务好业务，又能落地好技术的规划，服务化组件的抽取，共用，同时还要能完成指定的指标，这是需要考虑的。

Cloud研发过程太多的组件和概念，相对来说，可能【完善】，但是反面来，却可能成了开发的壁垒，毕竟，不是每个项目都是一上来就有十几或者上百台服务器的资源，几千万的项目经费，更多的可能是几百万，几十万，只提供几台16G内存，硬盘暂时考虑都满足，一个Oracle或者MySQL数据资源。 整个服务化过程中，项目只需要一个稳定的，功能完善的RPC服务，来完成SOA，需要治理，也需要监控，但是这个并不是必须， 需要的是完成项目，快速研发并提供服务，消费服务。

而正是Dubbo精简化，针对性，有监控（Dubbo-Admin）等的情况下，服务化项目考虑，经过多年国内实践，有大量现成的文档和解决方案，满足实践项目开发的需求，反面变成轻量级的服务化工具，更加合适团队，一个问题，你确定你的项目真的一定需要分布式配置中心么？

技术过分冗余，软件价值考虑

所谓的冗余，有点类似于鸡肋的说法，丢了又觉得可惜，使用又觉得用不上，或者使用的场景很少之类的，刚刚上文也提到，分布式配置中心是否真的工程需要的（安装一个Apollo需要多少服务器资源？）；再比如是否真的需要链接跟踪，业务真的有那么大的访问量，再或者这访问过程是否是可能通过日志手段排查；再比如ELK，还有容器化，消息中间件之类的。以下的场景针对于一般性项目（几十万至几百万政务系统）来说，相信这类型项目在政务来说，比较常见，而这类型项目的服务器资源，项目资源（硬件，软件）往往很少 。

上面提到的，只是一部分，听起来好像有点不太可思议，甚至有点冲动，

“分布式项目怎么不需要配置中心，不是更简便的么？” “ 消息中间件是来处理日志或者可靠消息，必不可少的“”容器化容易发布“ 或者说 ”ELK可以有界面查询，及时收集多台服务器的日志” 等等

这些都没有错，但是也要考虑一点，但太多的技术债，维护成本有可能远高于应用系统的维护成本，原本应用软件就一个运维可以搞定的，加上这些不知名（相对于原运维来说），处理起来更加困难，而往往要求助于开发，这样，一个运维的成本，还有开发人员的支持，运维的成长周期可能就需要1至2年，而一个软件项目的生命周期也仅仅是5~10年（再往上的，稳定性也已经很强）。而实际上，这类型的项目实际在测试过之后，稳定性及可靠性已经很强，出现问题的往往并不是技术问题，而是业务问题。

即使出了线上问题，排查周期一年左右，基本上也趋于平稳，而使用大量的技术冗余，是否确定可以这一年里面运维可以正常学习到？或者再反问，确定运维会去学么？开发人员的支持一定到位么？中间沟通成本是否有考虑过？学习成本与问题消化成本是否等价？

技术精简化，遮蔽技术，大道至简等这些都是设计中需要考虑的，而Cloud大量的技术引入，是否真的合适这样的场景，是否让团队可以正常消化，并产生价值，这是我们需要考虑的。没错，传统软件开发确实很困难，有弊端，DevOps体系，服务化架构确实可以做到一定的提升，但是我们怎么最少成本切入，并提升我们自己的价值，这不是更重要？也许刚刚上面提到的，人员培养过程确实为后期提供了另一种可能，也是企业所需要考虑的，但是有一定是成本权衡。

相对而言，Dubbo这块的稳定性，效率，精简，与Spring的无缝融合，相对于Cloud的大量的技术债，确实有它一定的优越性，灵活性。

更灵活的技术迭代和选型

项目架构的设计，项目的版本提升，迭代，新技术怎么快速切入原项目架构而不影响，甚至是替代，都是需要考虑的。这不是必须，也可能不会发生，或者发生的机率比较小，但是它确确实实存在。

一般的项目上线，可能在这个周期内不会变动，但服务化的产生，使得大量的组件产生和成熟，在新的项目中产生迭代，升级，而这一些的操作过程，都是尽量原子化，比如替换掉UI，可能一次性替换，比如升级Dubbo，，升级Spring，怎么样快速做到灵活升级，而且对开发人员做到无感无知（理想状态），更或者产是不影响当前的版本，这是我们需要考虑的。

再回到Cloud，组件封装得甚至有些过渡，我们团队，也可以说你们团队确定是可以接受它技术的迭代么？1.5到2的升级，就有了很多变动，甚至要调整业务代码。为什么？Spring团队并不是针对于一个技术团队服务的，而是针对于所有的Spring开发者。如果我们自己不能把控，即使能把控，也有可能会产生大量的维护成本，人员成本。组件太多，甚至你也不知道他在哪里，而某个依赖的升级，是否会影响到其它版本的正常运维，这更难说。

怎么样有效管理工程迭代，升级，做到对开发的无缝感知，这是我们需要考虑的。

这里就不再细说，Dubbo就只是一个包，换掉即可，其实个人建议是不要换，因为这个包只是为我们提供了高质量的RPC服务，稳定即可，更多的，推荐升级周边服务，比如MyBaties，Spring等。一些场景下可能是一定要做升级的，比如兼容K8S，目前Dubbo转Apache维护，升级官方也出了文档，Cloud升级是否可能提供文档，也许可能，但是太多组件，风险也很大。针对于Dubbo工程，依赖包的问题会产生未知包引入，这个我们是在行政管理和代码评审上做的强制管理，这些由规范做约束。

推荐服务化技术实现方式

与其说推荐，更多说的是实践过程中积累的实际场景，学会取长补短，两者结合，也未偿不可。大概画了一个简单的架构设计图，对内使用Dubbo的优势，对外使用Cloud的概念。

服务化技术架构，Cloud有一定的优势，但是我们需要用到的是他的是HTTP+JSON，而这个，Boot已经实现了，与其说使用Cloud，还不如用Boot，可以适当引用一些Cloud组件，比如网关组件，消息组件，分布式链路跟踪组件，熔断器组件（不过听说不维护了），做为外部系统对接，如第三方系统，或者内部多系统对接。对内采用Dubbo提升开发效率和传输效率。

技术本身没有对比性，只能说场景符合，针对合适的场景，团队，项目，条件等使用合适的技术实现。

此次分享主要用于南宁IT圈技术分享

前言

此次分享的内容是针对于大型政务项目从零研究，设计，搭建，实践的过程分享，主要内容为研发平台架构的设计，在讲解过程中，同步说明落地经验分享，整个过程预计30~40分钟左右。

此次分享的目的是想让更多人了解我们开源团队，同时带动开源团队成长，提升团队成员的视野 ，见识 ，提升开放的心态，尽量减少团队成员成长过程中迷茫 ，焦虑。同时，需要不断的与外部学习，获取提升， 看到自己的不足，同时认可自己的优点 。

注：避免项目的涉密信息，此处以开源版的平台设计作为讲解设计过程 。（为了获取更多的信息，以原架构设计为原型，搭建了一套开源版的）

主讲人

罗安东，首都信息广分平台负责人，负责平台管理和两广技术支持。多个大中型项目架构经验和落地经验，对服务架构设计，平台架构，技术落地，团队建设等有一定的实战经验。

内容大纲

一、平台架构建设；

二、平台服务规划；

三、平台的部署架构；

四、平台建设的目标。

平台架构搭建

技术阶段

整体平台架构设计

整体业务架构设计

整体DevOps架构设计

技术实施

整体平台技术选型

整体开发技术选型

整体服务划分

应用部署架构

建设目标

平台研发目标

平台业务目标

谢谢