分类目录归档:生活

【转载】微服务打造企业中台

随着技术的日趋成熟,云计算已经逐步替代传统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体系

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

背景介绍

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

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

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

自己建立的学习开发平台(http://cloud.linesno.com)

自己的经验和体会表达,原开始使用的是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架构设计

技术实施

整体平台技术选型

整体开发技术选型

整体服务划分

应用部署架构

建设目标

平台研发目标

平台业务目标

谢谢

【实践】使用在线研发中台进行HelloWorld项目开发

前言

使用研发中台,低代码开发好一个学生管理系统的CURD功能,整个过程预计【1个小时】左右 ,实现如下的效果:

学生管理系统效果(一下找不到合适的页面,暂时用这个替代,效果差不多)

研发中台是目前开始尝试做的第一个对外应用,期望就是在线配置非需求功能,调用现成的基础组件模块的服务,专注于需求和业务进行开发

研发中台提供了一些开发常用的能力,为开发提供相应的支持,减少研发成功:

1、开发支持:分布式配置中心、开发技术文档、开发规范、开发数据库、私服 等

2、基础组件:通知组件、日志组件、工作流组件、单点登陆、存储组件、打印组件、网关组件,为开发提供便利,前端控件代码

3、权限配置:菜单管理、角色管理、用户管理、部门管理、代码管理、参数管理、通知公告管理等。

这也是研发中台的第一个学习示例,其中开发使用的平台是alinesno研发中台:http://cloud.linesno.com

开发准备

开发准备,目标是生成代码,是包括【数据库建表 — 建立开发基线 — 生成代码】这几个操作过程。

数据库设计

数据的话,平台已经准备了一个在线版本的,为了图方便,使用的是公网的,在开发中使用还是可以用的。在平台找到开发的数据库入口,账号密码平台已经有注明,然后建立两张学生表,如下图:

数据库入口

建立了两张数据库表,如下图:

github注册

开发一般都有代码库进行版本管理,这里推荐使用github,因为是个人的,需要自己注册,假设你已经注册好,我们建立一个学生系统的基础,如下图:

建立学生库

生成代码

登陆平台门户,通过【创建项目】指引,填写相关配置(这里github基线要做成公开的,这个下一版本会调整问题,比如公司内部可能就不用考虑项目公开性的问题):

jenkins如果没有,则可以不用填写

点击【完成】,等待代码生成完成即可,这个时候,我们再查看一下git基线,已经看到我们生成的代码:

运行工程

运行工程主要流程按【工程导入 — 平台账号配置】过程,实现在线的配置。

导入工程

这里使用的开发工具是【idea】,导入基线即可,可以看到生成的代码结构,如下图:

过程要下载一些包,所以工程显示错误的,等包下载完成即可

然后运行springboot,访问地址:http://localhost:8080,应该出现如下界面:

会发现,需要一个登陆账号,这个账号,是通过研发中台配置的,看下一章节。

配置应用

登陆平台门户,研发中台是在线研发的,配置也是在线的,所谓的配置,就是一些常见的【菜单】、【角色】、【权限】、【用户】、【参数】、【通知公告】、【代码生成】等,如下图:

研发中台提供非需求性基础功能

在研发中台菜单项目先进行菜单配置,如下图:

菜单链接指向的是代码生成的list文件,即templates下的文件路径

再配置一个角色【学生管理员】,分配菜单权限给这个角色,如下图:

分配角色所拥有的资源

配置完角色之后,我们建立一个账号,同时分配【学生管理员】角色给他,这样他就跟菜单关联上,如下图:

添加账号和关联角色

有了账号之后,我们就可以登陆系统刚刚运行的系统,登陆之后,如下图:

显示菜单功能

发布k8s

整体按【Jenkins打包 — 发布k8s】这个过程,这里可以集成自己的Jenkins和k8s,平台目前的Jenkins和k8s不对外。

通过研发中台提供的【jenkins】进行发布,jenkins的配置和maven配置都已经整合,同时平台也集成好了k8s,为开发提供便利。

配置jenkins

此处由平台提供,但不对外,开发者可以使用自己的jenkins或者其它构建工具。

Jenkins配置是自动发布操作,同时为我们打成docker镜像,为发布k8s做准备。下面是jenkins的配置,Jenkinsfile已经在代码生成时自动生成:

通过平台jenkins入口进入,此处账号不对外(可自己安装jenkins配置)
配置的jenkins
构建过程和结果

访问应用

发布完成之后,访问地址,此处使用【NodePort】进行开发端口,只为演示方便。

开发支持

提供开发者过程中需要的一些技术资料和文档,可查可参考:

开发技术支持文档

最后

此处演示了整体研发中台的开发过程和企业集成流程,整体中台还在完成中,此处演示的只是一个示例和整体研发愿景,也希望有更多人参与我们中台的建设。

中台开源代码: http://gitee.com/landonniao

【实践】我参与的一个千万级软件项目平台架构设计与落地过程心得

基本背景

项目是在16年立项,前期主要进行需求调研,17年进入研究阶段,两广的城市信息化项目,整体项目的规模在3千万左右(不包含硬件,硬件是使用另一厂家云平台和阿里云),整体项目采用分布式,组件化开发,从设计到初步验收(只是初验)大概3年时间。整体项目包含有两个外包团队和两广团队,还有很多第三方的采购件,如工作流,APM等,相对来说,团队组织结构是比较复杂的,内部的组织结构还是部门型,即按开发组,测试组等,软件开发较为传统,还是老的单体结构,原项目架构非常老,还是Servlet、Strtus2、JDBC、EJB等,内部很多员工都有8年以上工龄,研发思维思维都以保守为主。

项目中我的角色是平台架构设计和平台组负责人,属于新血类型。整个记录过程,大多是以自己心得体会做过主线。整体过程按《前期 — 中上期 — 中下期 — 后期》几个过程进行描述,着重写这几个过程中出现的心得。

前期阶段

沟通是落实最实在也是最重要的一步

保守的研发观念,与新的平台架构观念融合过程

开始的时候,我这边是负责技术的吸取和学习,这个过程中,出现激烈讨论是相对比较多的,互相埋怨也是较多,互相沟通也是最多的。

打破传统,让团队接受并快速成长,接受平台的观念,是项目前期的比较重要的工作。 是于项目开始的时候,邀请了一个做过类似大型项目架构设计,有经验的架构师在公司搭建了一套平台,同时做了一段时间的内部培训,造成内部不少的讨论,平台可行性,是否可以这么做,事务怎么办,所谓的可靠消息,是否真的可靠等。引入分布式思维,统一研发平台思维。我这边的责任,便是与他学习,快速积累经验和了解平台结构。

很快,在为期1个月的熟悉之后,了解整体分布式结构(其实就是微服务架构),同时熟悉整体开发平台(其实就是PaaS平台),很快投入了前期试点项目,我这边协助开发平台的搭建和运维,保障前期项目的顺利进行。在这个过程中,也不断的邀请总公司的负责架构人员,或者技术负责人一起到广州进行讨论。方式也很简单粗暴,一帮人坐下来,针对设计的平台进行讨论,坐而论道。难免,一坐下来,就是意见不同,然后激烈的讨论(无可否认,讨论也是一项比较有技巧的技能)。

很快,试点项目就发现问题,工期有延期,无法达到平台预期的效果,整体开始针对试点项目进行讨论,两广一起讨论。平台组无法给开发组提升相应的开发支持(规范、规划、要求等),再加上前期对平台是否可落地的不明确,结论很显然,吵架又是再所难免,同时也预示着:平台落地出现了问题。整个会议几乎从开始到结束,都是针对平台的批评,技术的抨击,几乎让我无法抬头,甚至几乎无法面对开发,包括下一步的实施,甚至几乎到产生自我怀疑的态度。

平台初步落实的问题,这样的情况下,推广新平台,包括后期的内部实施,无非是又加一层难度 。几乎进行了为期一个多月的反思,找问题:为什么照着现成的平台,而且有成功实施经验的平台架构,在内部一实施就出现问题,问题点在哪里。之前平台架构整体规划及演示都很完善,为什么在内部实施一走就出问题。在不断的吸收前人平台设计经验的同时,也是不断的网上找各种资料(资料都说好,真的好么?),更是考虑内部实际的情况,光这几步,也差不多够折磨人,心态也开始有些浮躁,焦虑,不安等,更别说要休息,闭着眼就想着怎么落实的问题。

虽然过程中问题很多,待处理的问题也很多,但最终项目还是能落地下面,同时顺利上线。正是因为有了前面的各种讨论,意见的磨合,为下一步大项为了一个准备。

针对于跨团队,跨部门,跨地域,进行沟通过程

在后面的时候,由于各种各样的原因(可这么理解,家家有本经,即根据实际情况),内部做了一些组织调整,平台的设计和管理工作,转到我这里,从技术负责转变成平台管理,也就是平台组的负责人。

前面阶段的试点,讨论,还有各种或者说N多的技术问题积累之后,对平台做了重新规划,对之前的那套研发平台进行整体规划,然后服务器资源,还有管理方式都做了进一步调整,以符合实际场景。在进一步内部评审之后,新的平台架构通过大家的意见,这一步无非给自己增大了很大信心。并升级的平台架构,对前面试点过程中的问题处理,比如包括规范更好明显,沟通更加明确,还有组织结构也更加清晰等,在进行讨论确认新平台架构和方向之后,便是团队怎么消化和落实平台,怎么结合实际大项目,投入实施。

开始的项目组织结构就已经让我头疼不已,外包都有相对应的负责人,而且经验和资历都不浅,还有南宁这边的团队。内部除了开发以外,还有测试,运维这些部门,开始的第一步落实,怎么沟通,就让我已经倍有压力。

项目组按业务进行分组开发,平台为他们做好服务设计和组件设计 。不出所料,项目组一开始就有出现小组意见不合的情况,同时各个负责人都有自己的想法,各有各意见,负责人之前,很难说服对方。而平台组按目前的情况,还属于前期,是无法去统一的所有意见的,更别说去跟这些负责人碰,要么头破血流,要么自讨没趣。这样的情况,协调领导,把情况表明反馈领导,组织,开始进一步讨论, 又是一个个非常激烈的讨论,但最终的,还是统一意见下来。

在这样的情况下,平台组在各个负责人之间,作为基础服务,难免会有委屈,如受到一些非议,还有一些不认可。但总的来说,这个过程好,至少来说,都是往更好的方向发展。前期开始工程规划,到小组成员沟通,这几个过程还是比较顺利,沟通习惯和制度也慢慢的有形式。也正是因为前期,还没有过多的外部压力,同时也是内部的一种讨论,相对来说,还比较可接受。

平台与业务的碰撞,落实过程怎么走好第一步

怎么驱动开发接受新的技术,让他们成长,同时利于平台的进一步实施,这几乎是前期最难的。驱动一个人学习,让他学会思考,还在照着你的方向去思考,这几乎就是矛盾的开始点,但也是需要去做的点,而且是必须要做的点。

前期规划得最好的方式,也是要求的很严格的操作,就是文档。在每一个问题,还有每个操作过程都产生文档,让开发可查询,可操作。整体前期在研究过程中,便积累了大量的文档,这些开始培养,然后介绍,过程都很完善,并显示了怎么编写上传等,原以为准备那么充分,以为可以为开发提供更好的便利。

但是在真正落实的时候,才发现,文档与实际的项目过程问题有区别,而且很不完善(开始已经对文档了很严格的要求),文档可实施性真正结合到项目里的时候,各个N多的场景根本无法融合。更有一点致命的是,原习惯使用Office文档的,而规划的时候,操作使用线上文档,内部根本不习惯这样的操作。同时还有一个更好有意思的问题,文档太多,过程中不知道怎么查找符合自己的场景的,可能有很多关键字类似的,但是查询几次之后,发现与开发编码过程中实际想要不一样,等等这些问题。然后开发过程中发现,还不如百度出来的更快。

在文档规划及实施这块上,各种问题的出现,无非给平台组一个打击:给了一个好像很好,但是可用性不高的东西,多少有些鸡肋。还有类似的就是平台任务管理平台(类似于Jira),前期的时候,可能还能接受,但是后面实施也一样的鸡肋,根本不符合团队实际的习惯。开始尝试压着使用,但是这样的情况往往更槽糕,反弹的效果,很可能直接引起冲突,甚至相关负责人的否定,引起团队对平台的进一步怀疑。

不得不做内部反思,调整平台落地的方案,不得已,把平台规划再做一次调整,并做组内讨论(大的方向是正确的,只是调整部分),把一些“美好”的规划去掉,避免开发过程中的冲突,然后在遇到问题的时候,进行平台方向的引导,慢慢的过渡这个过程。要团队接受这个过程,非常长,近乎1年,很大一部分促进的功能,是开发过程及相关条件(比如压力,团队的文化的积累),而且有一些还是不能很好落地,比如原规划的自动化运维。

怎么让研发接受新的开发技术和管理过程

从开始到慢慢接受这个过程,几乎是一个一言难尽的过程。这几乎要改变的不是一个人的开发习惯,而是一群人的开发习惯,不仅仅如此,还要面对未知新技术带的各种未知问题,如接口开发前后的问题,开发版本管理的问题,还有各个各样环境(如网络)导致的各个异常引发等等。

当时有两个办公室,还有一个开发群,几乎有一段时间,都是两边都跑,然后一坐下来,可能群上或者就有各个QQ信息,包下载不了,怎么调用不了服务,这个异常那个异常等,还有包打错的,再加上maven一连串的依赖(这个证实前期设计的疏忽,是一个很小的细节引发),导致各种莫名其秒的问题,每天的工作就是沟通,处理,然后再沟通,再处理。当时很是担心,就怕这块异常引发开发的对平台组的信心减少,开发来上班,自己就比他们提前一点检查环境,开发加班,也跟着加班,如果开发走不下去,可能就是各种电话沟通,信息发过来是各个平台的问题,甚至的,有一段时间,通讯信息都不想打开,一听到电话,就猜到哪里哪里可能出问题了。这样的情况前期持续了差不多2个多月,几乎让我喘不过气。

后来才发现,前期这样的情况还好一些,中后期的时候,可能更为严重,异常处理都是半夜的,而且持续好长时间

经过这段时间的不断融合,可能产生各种问题,比如沟通,或者不理解,还有一些压力,甚至包括一些冲突等,但最终还是把这个过程落地下来。在持续了一段时间的 “问题” 热度之后,技术和整个新的研发流程,研发管理流程也已经慢慢理下来,后期遇到的,更多的就是业务性的问题,这个便是由业务组沟通处理,平台组做技术协助。

中上期阶段

做事过程,就必然有问题,不要指望完美

平台组成员压力太大,怎么克服

这个问题的出现,有必然,也有偶然。并不是说什么样的条件,也不是说什么样的环境,最终由实际的团队情况,环境,约束等方方面面来决定的。投入开发过程中,开发对平台组提了要求,需要完成的任务有没有达到的情况比较多,还有各个方面的经验还有实际情况,无法满足开发组,这个时候,便意味着,冲突的开始。

从上往下过程中就发现问题点,平台组并不是直接面向项目组,所以有一些隐藏性的问题,并不是一时的出现,这个过程可能会包含有遗忘、异常、侥幸、研发等,不过最终还是会暴露,这也不得不明确一点,遇到问题要及时提出,以避免进入深一层次的问题出现。而面对这样的情况,业务组在项目中期的时候,就全面暴发。异常多的问题冲向平台组,计划不断的被打断,一些原来基础简单的工作,几乎无法完成。常常一有问题就得马上响应和处理,而原计划的工作却又落下,不断重复和积累 ….

很快,以上的表现很快到人能力,小组能力的质疑,进行对平台能力的怀疑,是否能撑起业务组的开发过程。同时各种不满的意见,声音,反馈开始慢慢在项目组低下传播,业务组开始出现脱离平台组进而用自己解决技术处理问题的情况 …. 等等以上的异动开始出现。

明显,我在当局中,不得不思考和处理方案,这也是让我最头疼的方式。压力大与小的情况如何分配和调整,确实比较难办。在这样的情况和内部不满的情况下,还有对各种质疑不断,把一些业务针对比较锋利的压力转到我这里,然后小组进行工作考核和评估。原本考虑人心安定的问题,但是最后发现,不能满足的考核根本无法抵挡得住业务组的压力。沟通上的冲突与不理解很快就出现,这样更加激起业务组的情绪。

很显然,沟通能力和抗压能力的要求很快体现,而且体现得很明显

最后的表现是不管是上层和业务组,都慢慢有排斥平台的情绪,质疑和不合作,不接受的情况慢慢表现。这也是我最害怕的,最担心的,这样下去,可能的结果就是,平台组在项目组中的位置降低,同时更可怕的是,整个平台组可能为此而受莫大的打击,更别说其它的后期想落实什么什么方案或者意见。最无奈的办法,考虑左右,把研发出的组件效果体验最差的人员移出平台组,调入业务组,一方面是减压和挡住业务组的压力,另一方面是为平台组保留住核心人员,即表现能力比较好的,然后一步步的慢慢啃之前留下的各种技术债和业务债。但是之前的一些原本脱离平台管理,包括规范,要求等,只能在后期中慢慢的一点点的与业务组进行沟通和调整,只能在后期慢慢积累经验和找机会调整,有些可能无法调整的也只能默认(这步却为后期运维和后期各个工程上的不统一,研发意识和项目结束后的不统一埋下了隐患)

其中这个过程早就应该这么做,而且不应该犹豫,这是前期最优柔寡断的错误,同时也是自己实际管理能力不足的最直接体现

这样,在调整结构和人员的工作之后,平台组在协助业务组方面的效果有提升,认可度也很快有了改观,直到第一部分项目的上线。这个过程几乎经历了几乎慢慢转变了整体平台组的观念的改变和认可。

项目开始落地,内部抱团,相关工作安排沟通困难怎么办

第一个部分项目上线,落地部署的过程也是极困难的。平台基础环境搭建过程较为困难,迁移搭建的前一个星期,就几乎是每天到晚上2左右,然后早上8点半又得去验证。难并不是安装部署一些软件(如jenkins、redis之类)有多难,而是工程依赖,版本库,数据,第三方厂家的沟通等。工程就有近乎80个,而且开发过程中有可能发布新的代码,而之前工程发布有先后,还有一些工程(如基础组件)已经很长一段时间没有动,新的接口可能还没有做好验证(或者说没细考虑到)等等。

原自信满满的认为可能最多3天部署完成的,但是整整拖了近乎5天 ….. 这不得不让我心里崩溃,也明显体现出原平台架构的不合理,规划的失误。以前参考和培训的平台架构规模相对较小,整体完全不是一个级别的,这让我不得不为自己的背锅,所谓的坑,可能自己在挖着,而这些坑只能自己跳然后自己填。

项目上线,原考虑分人员运维已经上线的项目,做前期的过渡支持,然后我这边负责广州核心业务开发支持。这个安排,直接导致了平台组内部问题的出现,意见开始出现不统一,这也意味着,沟通上出现了问题。深入沟通过程发现,平台组原能力较好的人员保留,直接对接业务组(以前都是我直接对开发组,做第一步沟通),两边能力的差异,很快产生对业务组的不理解,比如注册中心,可能业务组开发人员也不怎么清楚原理(这其中也很正常,毕竟很多平台技术对业务组是透明的,他们可能都没有感觉到自己做的是分布式项目)

这样的问题出现,很快导致业务组的一些工作落实不顺利,不能满足要求,不久,很快就出现互相抱怨的情况,最常见的,你说他技术不行,他说你组件问题多。开始我并没有注意到这些,原认为是让接触一些也比较好,可以磨练,但是后来问题突出的时候,已经开始有些进入激化(比如互相抱怨)的程度,这个时候不得不介入首期项目的运维管理。

抱团就开始出现。开始自己也是比较难接受这个,毕竟小组内开始出现的,然后与其它业务组抱成内部小团体(确实开发太年轻,有可能出现稳定性不足的情况)。最开始的操作是内部办公室分隔,这步的效果不是特别好,可能是前期项目组工作压力,导致一些满情况有压抑,抱团成一个比较突出的反抗方式。考虑到矛盾的进一步激化风险,接下来就是沟通,即慢慢沟通,了解情况,然后就是安静,观察。公司明显也体会得出来这样的风险,进行了一些物质奖励,以安定人心。前期确实有一些效果,但是这样的抱团往往形成的隐患是有后遗的,一旦开始,各种消极的思维(比如逃避困难、互相指责)就可能变得固化,为后面的风暴期埋下了隐患。(比较建议的抱团应该是团队一起面对目前的困难,积极表达,针对问题进行沟通,解决困难,每个项目都有困难期,事事都顺利可能比较难)

组件近乎无法使用,开发崩溃怎么办

平台组经过了前面一段时间的躁动,这段时间大概为1个月左右,内部开始变得稳定一些。同时第一个项目运维支持的工作也差不多结束,在结束完第一阶段,很快就要面对第二阶段的挑战:有些基础组件在测试期间出了问题,而解决不顺利。

基础组件涉有几个是第三方的,在业务测试过程中,积累了几十个问题,一直在沟通调整中。有一些第三方公司本身就出现了问题,对接人员不断换,两年的时间里面,差不多换了4个开发。每调整一个版本大概是2~3周,还不包含测试。有些第三方组件,在实际的生产环境中(如接入银行,银行网络内部多了多层的NAT转换),一直出现异常,如客户端电脑不兼容,网络莫名的提示异常,还有各种硬件出现冲突等等。

以上的表现实际上在开发和内部测试阶段是比较不明显,但是实际到用户测试,安排的测试人员有近乎200人,用户在实际业务中,已经很娴熟,在测试过程一用就发现卡,要么就是这个接口不行,那个提示浏览器崩溃,这样对业务人员几乎无法忍受。开始业务人员第一施压对象便是业务组,业务组一汇总,压力进一步转移到平台组,然后平台组再转到第三方。第三方根据问题调整的周期长,每次验证都是正常的,平台组这边也验证,但是一上用户测试就是一大堆的问题,这样所有压力都开始针对于平台组,与第三方沟通也是存在各种不确定,可能人家忙,不接电话,问题延期,第三方发布的版本不稳定等等,这些沟通过程,都差不多消耗了2个月,效果还是不怎么理解。每次开会,都是提到这几个问题,平台的开发人员几乎很无语,也很无奈。过程大概都是,每个阶段都说自己的是正常的,第三方说调整版本没问题,是业务集成的问题,业务组说集成是平台组问题,平台组说第三方集成的问题,两头夹,或者谁都说谁有理等情况,接下来再走一次内部查找,排查,沟通等等。

这样不是办法,效率太慢,我也实在是无法忍受,一个问题可能拖很长时间。后面,调整策略,与商务和用户沟通,直接要求第三方人员现场驻场一到两周,集中把问题处理,由业务人员直接对接第三方,项目例会涉及到第三方,第三方各种问题先处理完,再回去。

这些组件的问题,从用户测试到有比较稳定的第一稿,差不多经过了半年的时间,用户才稍稍接受,这个过程也几乎把平台组折磨得差不多。

中下期阶段

不上不下的,要的不仅仅是会做事,也要学会做人

前期架构某点技术问题,实际线上场景无法使用,怎么面对客户和内部双重压力

开发和测试都经多很多次验证,在用户测试和试运行阶段还是出现了很多猜想不到的问题。

最明显的,网络层面的开通和阻力远远超过原预期的设计和考虑,原中间件的选型也是不能完全满足要求,还有分布式事务的设计与实际场景差异等等。那么多人前期在讨论着,看着方案,也有很多的验证过程,而且别人也是这么用的,为什么别人就可以正常,我们一用的时候,就出现异常。之前甚至找了原厂的人(比如Weblogic),也一样说是某些技术场景也没见过。这个几乎是一把虚汗,因为在开发,测试中都验证过的,可能来说,都已经正常的,到实际试运行就不行,这让内部测试、用户测试人员很难接受。

能用得起来的人都说正常,你能确定你用起来就一定正常的么?

首先发现的是网络,最典型的,也就是上面说的第三方组件也一样出现类似的问题。接入各个使用机构(如银行、管理部)的时候,他们自己本身内部就有一套网络结构,在使用过程就发现,有些第三方路径回调不回来,网络出去了,找不回原来的地址,系统一进入就是空白,这无话可说,加班调整和修改。

再有的就是事务这块,交易过程也一样发现各种各样的重复交易,记账数据不正确,或者说消息发送找不到记录等等。这也无话可说,直接加班调整。比较无奈的一点是,原找使用说是在生产做正常业务的人过来处理,他们也只是看了一下,大多也是回复“不清楚”,“没遇到过这样的情况”,那只能自己内部开会调整找方案。

这个过程加班,熬夜也是最深的,因为技术架构的问题,有可能直接导致整个业务和项目跑不起来,或者无法应用实际的生活环境场景。这个时候你没办法,只能临时调整,大调整也得调整,小调整也得调整,实际环境就是如此。有的时候,还需要跑去实际现场查看问题,最典型,就是银行小妹窗口那里查看,看着人家办业务,然后有问题,及时处理。或者在用户电脑上调整,跑去那个银行网点,这个银行网点,Debug调试,实际验证等等。因为一旦试运行上线,业务一般就不能停太久,这个不管是在各个方面来说都是一个挑战。

这个过程差不多有2个月的时间,前一个月调整,后一个月运行验证,整个也差不多到17年低,也差不多告一段落。这个阶段都是直接技术处理,但是更多的是平台的压力,几乎也差不多折腾人,所幸的是,只是技术上问题,沟通及矛盾上不会那么多。

用户测试出来的问题几千个Bug,平台组怎么更好支持业务组

项目往往是越到后期,压力就会越大,加班也是越多,接触过几个公司,项目开发貌似不管大小,都存在类似的现象。而面对大型项目,多项目组,多部门的情况,这个方面就更加突出。

项目至少我是这边接触的,从一开始就一直在大量的加班情况,也近乎两年,再加上各种压力,确实一开始适应起来并不是那么顺利。前面也提到,每个阶段都有问题,而且是异常多的问题。几乎每次开会,都是拿问题进行投影讨论,定位到人,平台组的问题,几乎就没有断过。

分布式项目,都存在关联,A组会提到是B组的原因导致,B组会提到C组的原因导致,最终又转到平台组,组件不完善,技术支持不到位,环境各种异常等等。这个过程是比较折腾人的,前面抱团的原因让我也是让我更担心人心的问题,有些工作安排已经开始不到位的情况。

用户测试阶段几乎是一个灾难(并不是说不好),测试规模也比较大,安排了两个大间,类似于两个教室一样,安排的测试人员大概也近乎200人。用户的这个安排,也着实让我们出了一把汗,结果是果不其然,这把汗真的是流了不少。

几个业务系统一投入用户测试,就积累了大量的问题,差不多有4千多个,而且每天还不断有新的问题产生。加班、熬夜、外卖几乎是常态了,周末的时候,也许再安排点水果。这个时候,体重也慢慢提升,头发也在掉,也是比较意外的(所以程序员需要注意好身体是关键)。

问题修改,不断往上,改了近乎2个多月,几乎把人搞得人困马乏,再加上各种情绪的产生,人很容易,也很快就产生了消极情况,这种情况在项目组内部开始产生苗头。工作的消极情况,意味着上层就很难再给开发组压力,几乎只能找组长沟通,交流,这个过程人心和业务已经慢慢变消极,离职,招聘也就这个时间段也在同时进行,这也是我压力,情绪比较消极的阶段,甚至有一些提项目无法上线的说法,整个项目组信心不是特别大,抱怨也成了常事,这个过程更多的是志气上的提升,需要更多的互相沟通,依赖等。很显然,这个过程我并没有做好,也是自己需要认知的地方,平台核心成员也开始提离职,那个时候我压力最大的时候,特别是团队成员的离开,虽然有预知,但是那个时候的离去,确实一开始有些难接受。不过这也意味着自己的成熟,平台的成熟。

业务组在前期测试,对平台组的压力,几乎把平台组主要的问题都已经消化得差不多,不能说很好,但是不影响业务的进行(这不得不说,前期的问题暴露和施压了正确的),所以业务组在消化系统Bug的同时,平台组当中担当的角色几乎都是技术支持,加速问题排查和调整。同时也慢慢的支持开发过程的问题,这个过程是很容易积累平台威信的,同时也很容易获取到业务组的信任。在前期的积累和各种经验上,其实很快解决技术问题,同时认可度也慢慢提高,这也意味着,平台组开始变得稳定,也开始变得成熟。

在处理研发问题的时候,就开始慢慢把前期的坑补上,比如一些规范,一些工具的使用,一些技术的统一等。这样的过程差不多变得统一,如在消息的使用上,在业务上的整合极度容易出现重复消费的情况,前期讨论的时候,平台的意见有被排斥情况,这样业务组自己整合的前期貌似情况比较理想,但是业务组用完即走即不管理后期的维护,维护方是平台,这也是前期说的遗留问题),也开始按平台的规范,要求来编写,这样的排查的时候,就更加容易,也提高了排查效率,认可度也慢慢提升。

这个过程也是持续了很久,直到上线试运行到较稳定,大概有1年多的时间,都还是持续,只是紧与慢的区别。但是坚持到这个过程,已经留下人员不多,原平台组一开始的核心人员已经都走完了,没有坚持到最后,也是在中下期的时候。

后期阶段

这只是一个过程

后续的问题怎么调整和总结

平台前期架构设计和管理,当与实际整合中出现的问题,怎么样可以更好的落地。这个过程不断的在总结,同时在架构上做了进一步的调整,技术调研,还有自我工作反思总结。及时进行一些工作内容的合理梳理安排,以达到跟实际场景,实际团队更好的切合。

平台经过了差不多3年时间的磨练,出来的东西并不是相当的完善,反而让我发现,需要调整和需要走的路还很远,并不是说技术,而是怎么样更好的为业务服务,更好的在多种场景下进行落地。技术只是说一种手段,但是这个手段又不能没有,但是使用过度使用,怎么样能适中,两者怎么权衡,这些都是平台需要考虑的。

在大项目场景下是这样,但是在迁移到小项目场景下,是否可以实行得通,可能完全不是一回事。在项目过程中可以使用,但是项目结束后是否也符合后期团队的实际情况,也不敢一定。这个时候,需要的不是断的升级,不断的听取业务组,项目组的意见,切合实际的去协助他们的工作,帮助他们的工作,这才使得平台的意义有提升,更好的在实际中落地。不断的进行某个节点的改造,更好的结合内部场景来实现这个过程。

最后

整个过程下来差不多3年,直到现在,自己也是撤场不久(原在客户现场开发),整个过程有些唏嘘。回头看,整个过程真的到处碰,说得头破血流,有点悲壮也不为过,路要自己走,要自己体会。这相对于团队来说,几乎相当于一次改革,从上到下的新的思维引进,有非常非常多的阻力,也有非常非常多的困难,也会有人离开,也会有人失望,但是整个下来发现,需要的更多是学会团队的合作,更多的是学会引导,宽容,同时也更多的学会成长,个人整体素质的提高,人格的提高等,同时也感谢自己前期的不放弃。

整体感悟。