微服务应用平台的探索与实践
统来说，保持一致性非常 困难，意味着大家都要处 理最终一致性
增加运维复杂性：需
要一个成熟的运维团队 （机制）来管理大量需要 频繁部署的服务
目录
1. 为什么需要微服务 2. 华为云微服务全栈解决方案介绍 3. 华为云微服务应用平台设计要点详解 4. 开源社区生态 5. 案例
ServiceStage
微服务应用解决方案 公共组件 应用框架 运行环境 服务集成 基础设施
Web应用解决方案 公共组件 应用框架 运行环境 服务集成 基础设施
移动应用解决方案 公共组件 应用框架 运行环境 服务集成 基础设施
函数应用解决方案 公共组件 应用框架 运行环境 服务集成 基础设施
DevOps解决方案 Coding > 编译 > 构建 > 发布 > 部署 > 配置 > 压测 > 上线 > 运维
微服务应用平台的探索 与实践
目录
1. 为什么需要微服务 2. 华为云微服务全栈解决方案介绍 3. 华为云微服务应用平台设计要点详解 4. 开源社区生态 5. 案例
业务变革与创新
你有多久没去过银行？
你参加过多少次剁手节？
传统业务数字化、云化已成为不可逆转的趋势
流量不可预知性已成为互联网应用常态
应用架构的变迁
华为云ServiceStage是什么
以应用为中心，提供微服务、Web、移动和函数应用全栈解决方案，帮助企业加速业务创新。
DB PM
App Stack
App Logic
App Components
App Framework
App Runtime
Cache
MQ
OS
VM
…… Docker
DevOps Stack
水
线
构建
︵
扩展插件： 静态检查等
持
续
部署
集
扩展插件：
成
三方部署系统
︑持
测试 扩展插件：
续
客户测试系统
交
发布上线
付
扩展插件：
︶
客户自有仓库
监控运维
扩展插件： 客户自有监控
ServiceComb（Java)
微服务框架（CSE）
ServiceComb（Go） Spring Cloud（Java）
Istio（不限语言）
华为云ServiceStage一站式微服务解决方案
ServiceStage微服务解决方案
开发者生态
开源社区 开发者
API
案例
通用微服务工具市场
商业生态(aPaaS/SaaS)
行业：（政府、教育、医疗、零售、…） 行业：（政府、教育、医疗、零售、…）
行业微服务组件市场
工具（CPE）
设计和开发
流
扩展插件： Eclipse等
微服务生命周期管理
创建
删除
编码
发布 验收
微服务开发生命 周期管理
编译 构建
测试
部署
停止/卸 载
部署/启 动
日志/监 控
回滚 缩容
告警
微服务运维生命 周期管理
诊断
治理/配
扩容
置
微服务DevOps
基于Ser viceStage流水线实现应用全流程“自助式” 开发、集成、验证与上线
优势 • 一键生成持续交付环境
• Contract First
支持基于Swagger的API管理
• 多语言微服务
支持Java、Go、.Net、Node.js等
• 技术开放
支持ServiceComb、Spring Cloud、Service Mesh
来自于华为全面云化转型成功经验和前沿技术创新成果
微服务咨询
现状分析
培 训 适用性评估 ︵ 理 论
目标设定
︑ 案
例
试点实施
︑ 实
战
演
效果评估 练
︶
经验固化
生态
产品
开放： 支持主流开源框架和源码仓 库、开发体验不变，全流程 可扩展。
全栈： 咨询 + 框架 + 平台 + 工具 + 生态 成熟： 华为全面云化成功经验
第一代：单体架构
第二代：SOA架构
第三代：微服务架构
• 紧耦合，
• 系统复杂、错综交互，动一发而牵 全身
• 重复制造各种轮子：OS、DB、 Middleware
• 完全封闭的架构
• 松耦合 • 通常通过ESB进行系统集成 • 有状态 • 大团队：100~200人 • TTM: 1年、半年、月 • 集中式、计划内停机扩容
生命周期管理 部署/卸载 启动/停止 升级/回滚 灰度发布 弹性伸缩
应用管理平台（CAS）
微服务管理
微服务治理
微服务运维
契约管理
负载均衡
监控大屏
注册中心
限流/降级
智能分析
配置中心
熔断/容错
立体监控
治理中心
错误注入
日志分析
全局事务
黑白名单
全链路拓扑
环境管理 开发环境 测试环境 预验证环境 灰度环境 生产环境
微服务强调模块化结构 （REST接口调用），这对 大型团队非常重要
支持独立部署：
简单服务更易部署，由于 服务是自治的，出现问题 之后不会引起系统崩溃
允许技术多样性：有了
微服务，你可以混合使用 多种编程语言、开发框架 和数据存储技术
分布式编程难度大、 有风险：分布式系统编
程难度更大，远程调用更 慢且总存在失败风险
更快： 业务上线：年 > 月 > 周； 随时上线
更稳： 系统SLA：3个9 > 4个9 > 5 个9 > ；永不断服
更经济： 资源成本：容量预测、资源 按需弹性
全栈应用平台，覆盖应用全生命周期
研发态
应用开发
DevCloud
① 全流程 De vOps
② 全场景微服务能力
运行态
运维态
应用托管
Ser viceStage
• 解耦 • 小团队：2 Pizza Team • TTM: 按天、周进行升级发布 • DevOps: CI, CD, 全自动化 • 可扩展性：自动弹性伸缩 • 高可用：升级、扩容不中断业务
应用向CloudNative演进，微服务是CloudNative的事实标准
微服务带来的好处与挑战
服务模块的边界更清晰：
自动生成应用框架代码、构建、部署及测 试环境
• 多语言应用
Java、Go、Node.js、PHP、Python、 Ruby、.Net
• 多种源码仓库
CodeHub、GitHub、Gitee、GitLab、 Bitbucket
微服务框架
提供ServiceComb、Spring Cloud和Service Mesh多 种解决方案，降低企业迁移成本
应用运维运营
AOM
③ 业务上云平滑演进
集成态
Legacy系统
云原生应用A 云原生应用B 云原生应用C
应用集成
ROMA
第三方应用
边缘 工业设备
研发数据
业务数据
运维运营数据
④ 全生命周期数据分析、智能化辅助决策
融合集成数据
目录
1. 为什么需要微服务 2. 华为云微服务全栈解决方案介绍 3. 华为云微服务应用平台设计要点详解 4. 开源社区生态 5. 案例
基于微服务的性能测试实践
基于微服务的性能测试实践随着微服务架构在软件开发领域的普及，性能测试已成为保证微服务应用系统高效运行的重要环节。
本文将为您介绍基于微服务的性能测试实践，在保证系统性能的同时实现高质量的服务交付。
1. 概述在微服务架构中，系统由多个独立部署的微服务组成，每个微服务负责独立的功能模块，通过轻量级通信协议进行交互。
性能测试旨在验证系统在高负载条件下的稳定性、并发处理能力和响应时间。
对于基于微服务的应用系统而言，性能测试的关注点主要包括微服务之间的通信性能、系统整体的吞吐量和负载均衡能力等。
2. 测试策略为了有效评估基于微服务的应用系统的性能，我们需要制定一套全面的测试策略。
首先，需要定义性能测试的目标，例如系统的最大负载能力、响应时间的上限等。
此外，还需要选择适当的性能测试工具，如Apache JMeter、Gatling等，以模拟大量并发用户对系统进行压力测试。
在测试过程中，还应考虑分布式部署环境的搭建和配置，确保测试结果能够准确反映出真实生产环境的情况。
3. 场景设计性能测试的场景设计是评估系统性能的关键步骤。
在微服务架构中，一个典型的场景可能涉及到多个微服务之间的协同工作。
因此，我们应当结合实际应用场景，设计具有代表性的测试场景，并将其转化为相应的测试用例。
同时，还应考虑并发用户数、请求频率和数据负载等因素，以尽可能接近真实生产环境的负载条件。
通过设计多样化的场景，我们能够全面评估系统在各种情况下的性能表现。
4. 监控与分析在性能测试过程中，及时监控和分析测试指标是非常重要的。
通过监控系统资源利用率、服务响应时间、错误率等指标，可以及时发现系统瓶颈和性能问题，并针对性地进行优化调整。
为了有效分析测试结果，我们可以借助性能测试工具提供的报告和图表功能，对性能指标做出全面的评估和比较。
此外，还可以通过日志分析、堆栈跟踪等手段深入了解系统运行过程中潜在的性能隐患。
5. 结果验证与优化性能测试的最终目的是评估系统是否满足性能需求，并在发现问题后进行相应的优化。
211079460_招商银行企业级低代码平台探索与实践
视角Viewpoint招商银行企业级低代码平台探索与实践招商银行信息技术部首席IT 工程师 陈曦当前，招商银行在业界率先完成全面上云，从On Cloud 走进了In Cloud 的云后时代。
在此过程中，招商银行持续探索如何高效利用云计算相关技术并将其转化为真正的企业科技生产力，促进技术与业务的融合，从而构建科技高质量发展的新动力，打造全面数字化的“数字招行”。
低代码能够与云计算结合，将IT 资源和服务进行整合转化，发挥云计算能力，让技术与业务以融合的方式全面参与到数字经济浪潮中。
因此，低代码也被视为解决云计算“最后一公里”问题的重要方式之一。
招商银行通过不断探索与实践，推出了企业级低代码平台，有效提升了云时代的开发效能，促进了科技平民化，加速了数字化转型进程。
一、招商银行对低代码的认知和思考低代码最早于2014年6月由Forester 首先提出的LowCode 一词翻译而来，是指无需编码或通过少量代码即可快速完成应用程序的设计与开发。
低代码开发平台是通过图形化、可视化界面，以拖放组件和模型驱动等招商银行信息技术部首席IT 工程师 陈曦招商银行信息技术部 杨勉 黄燕VIEWPOINT方式，让更多业务人员和IT 开发人员快速实现Web、移动等多客户端企业级应用的开发平台。
从业界的发展趋势来看，低代码是继云计算之后最具实践价值和行业颠覆性的前沿技术生态之一。
国内外各大巨头纷纷采取自建或重金收购的方式布局低代码。
其中，微软推出Power 系列平台，阿里推出宜搭平台及钉钉搭生态体系，腾讯推出微搭，华为推出AppCube 等。
国际研究机构Gartner 在2020年发布的分析报告中提出，到2025年，预计将有5亿低代码新应用程序诞生，超过过去40年的总和。
因此，低代码领域值得探索与实践。
从企业数字化转型的过程来看，首先，有限的技术人力资源逐渐无法满足爆发式增长的软件开发需求，人力缺口问题、交付效率问题凸显。
微服务架构下DFX设计实践
7 DFC Design for Compatibility 兼容性设计
保证产品符合标准、与其他设备互连互通，以及自身版本升 级后的兼容性。
8 DFPr Design for Procurement
可采购性设计 在满足产品功能与性能前提下物料的采购便捷且低成本。
9 DFSC Design for Supply Chain
Design for Energy 5 DFEE Efficiency
and Environment
能效与环境设计
在设计中考虑能效与资源的有效利用并通过环保设计减少毒 害性和资源消耗，保护生态环境。
6 DFNS Design for Network Security 安全性设计
最大限度地减少资产和资源的脆弱性，包括机密性、完整性、 可用性、访问控制、认证、防抵赖和隐私保护等方面。
1. DFX概述
1.1 概念 DFX是Design for X的简称， 表示面向产品非功能性属性的设计。 其中“X”代表产品生命周期或其中 某一环节， DFX包括：可靠性、节能减排、归一化、可服务性、可安装性、可制造性、可维修性、可采购性、 可供应性、可测试性、可修改性／可扩展性、成本、性能、安全性。
3 DFT Design for Testability
可测试性设计 提高产品能观能控、故障检测与定位隔离的能力。
4 DFS Design for Serviceability
可服务性设计
提高系统安装调测与维护管理能力，提高服务效率。 隶属于DFS的二级DFX有：可维护性设计(Design for Maintainability)、易用性设计（Design for Usability）
DFS需求：Design for Serviceability，可服务性设计，提高系统安装调测与维护管理能力，提高服务效率。 鉴于以上种种问题，微服务的实施必然要具备需求管理、代码版本管理、质量管理、构建管理、测试管理、部 署管理、环境管理等工具链，除此之外，还需要开发部门与运维部门的协作，因此DevOps是微服务实施的充分必 要条件。
微服务架构在网级电能量数据平台中的应用研究
浙江工业大学学报JOURNAL OF ZHEJIANG UNIVERSITY OF TECHNOLOGY Vol.49No.3 Jun.2021第49卷第3期2021年6月微服务架构在网级电能量数据平台中的应用研究肖勇1，周密1，钱斌】，周积峰2,刘海峰2(1.南方电网科学研究院，广东广州5106632.烟台东方威思顿电气有限公司，山东烟台264001)摘要：使用微服务架构对网级电能量数据平台进行改造升级，提高平台的业务扩展能力。
智能电网建设的推进使得电网用户数和电力计量数据规模大幅增长，现有的单体式架构已经不足以支撑电能量数据平台的多业务扩展。
采用微服务架构技术对平台进行升级改造，架构内各个服务根据并发量和负载率独立制定部署方案，从而实现高可用和负载均衡，同时降低平台各功能的耦合性。
所提架构已在南方电网网级电能量数据平台中得到应用，长时间的稳定运行证明该架构可以提高平台运行稳定性及业务扩展能力。
关键词：高级量测体系；智能电网；微服务；计量自动化系统；电力计量中图分类号:TP302.1文献标志码:A文章编号：1006-4303(2021)03-0258-08Research on application of micro-service architecturein grid-level electrical energy data platformXIAO Yong,ZHOU Mi1,QIAN Bin1,ZHOU Jifeng2,LIU Haifeng2(1.SouthernPowerGridResearchInstitute Guangzhou510663China 2.YanTaiDongFang WisdomElectricsCo.Ltd.Yantai264001China)Abstract:This paper uses micro-service architecture to reform the grid-level electrical energy data plaIformIo improveIhe capabiliIy of daIa processing and business applicaIion exIension.The advanee of smart grid construction has greatly increased the scale of grid user number and electricity metering data size.The existing single-mode architecture is no longer su f icient to support the multi-business extension of electrical energy data platform.The micro-service architecturetechnologyis used to upgrade and transform the platform.Each servicein the architecture is deployed independently based its concurrent volume and load rate"thereby to achievehighavailabilityandloadbalance"meanwhiletoreducethecouplingofvariousfunctions ofthe platform.The architecture proposedin this paper has been appliedin the grid-level electricalenergy data platform of China Southern Power Grid.Thelong-term stablesystem runningprovesthatthisarchitecturecanimprovethestabilityofplatformandbusinessexpansion capabilities.Keywords:advanced metering infrastructure；smart grid；micro-serviee；metering automation system；electricity metering随着智能电表和低压集抄的覆盖面积越来越及数据密度随之增加(现有的电力计量系统已经不广，电网用户的规模和电力计量自动化系统数据项足以支撑未来的业务需求，需要对计量系统进行升收稿日期：2020-06-29基金项目：国家自然科学基金资助项目(1672451)南方电网公司科技项目(ZBKJXM20180157)作者简介：肖勇(1979—)，男，湖南岳阳人，教授级高级工程师，博士，研究方向为电能计量技术、智能电网，E-mail：xiaoyong@。
微服务平台建设方案
微服务平台建设方案微服务架构是一种将应用程序拆分成多个小型服务的设计，每个服务具有自己的数据库和功能。
微服务架构的主要目标是提高应用程序的可伸缩性、可维护性和可扩展性。
在建设微服务平台的方案中，需要考虑以下几个方面：1.技术选型：在选择技术时，需要考虑平台的可扩展性、可维护性、可伸缩性和稳定性。
常用的技术包括Spring Cloud、Docker、Kubernetes等。
可以采用Docker容器化技术来实现微服务的隔离和部署，使用Kubernetes来管理和调度容器。
2.服务治理：在微服务架构中，需要实现服务的注册与发现、负载均衡、熔断降级、流量控制等功能。
可以使用Spring Cloud中的Netflix Ribbon和Eureka来实现服务的负载均衡和注册与发现功能，使用Hystrix来实现熔断降级和流量控制。
3.数据管理：在微服务架构中，每个服务都有自己的数据库。
需要考虑如何管理和同步数据。
可以使用分布式事务来保证数据的一致性，使用数据同步工具来实现不同数据库间的数据同步。
4.安全问题：在微服务架构中，需要考虑如何保证数据的安全性。
可以使用OAuth2协议来实现用户认证和授权，使用SSL/TLS来保证数据的传输安全。
5.监控和日志：在微服务架构中，需要实时监控服务的运行状态，记录日志以便排查问题。
可以使用ELK（Elasticsearch、Logstash和Kibana）来实现日志的收集、存储和展示，可以使用Prometheus和Grafana来实现实时监控。
6.自动化部署：在微服务架构中，需要频繁地进行服务的部署和扩容。
可以使用Jenkins等工具来实现持续集成和持续部署，使用Kubernetes来实现自动化部署和扩容。
7.团队建设：在建设微服务平台时，需要考虑团队的技能和能力。
可能需要培训团队成员的技能，提高团队的协作能力和问题解决能力。
总结：微服务平台建设需要考虑技术选型、服务治理、数据管理、安全问题、监控和日志、自动化部署和团队建设等方面。
微服务平台云应用架构设计方案
微服务平台云应用架构设计方案现状分析01解决方案02核心技术03关于我们04目录CONTENTS云计算中心传输层工 商地 税卫 生教 育国 土民 政公 安计 生质 检工具与服务平台层数据共享交换平台基础数据库人脸数据统计平台学生人脸识别门禁管理人脸识别模块来访人员通行管理基础信息寝室分配未归/晚归提醒情绪管理系统基础信息辅导员信息情绪识别个人情绪波动学生信息学生信息毕业管理寝室实况未归/晚归统计访客统计报表生成个人出勤报表浏览器统计生成智慧应用情绪预判教学质量评估群体情绪感知层人脸高清抓拍相机壁挂式识别主机捕捉式高清相机人脸录入注册机闸机控制其它联动决策支撑系统身份认证访问控制人脸图库挖掘工作流管理预警管理黑名单管理终端家长教师职能人员管理者身份数据黑名单人脸属性访客数据SOA 架构ESB 服务总线A2服务B2服务C2服务A1服务B1服务C1服务管理控制工商公安人社微服务架构A1服务B1服务C1服务A1服务B1服务C1服务管理服务1管理服务2控制服务1控制服务2工商公安人社单体架构工商公安功能A功能B 控制管理功能A功能B 控制管理SOA 架构ESB 服务总线A2服务B2服务C2服务A1服务B1服务C1服务管理控制工商公安人社微服务架构A1服务B1服务C1服务A1服务B1服务C1服务管理服务1管理服务2控制服务1控制服务2工商公安人社单体架构工商公安功能A功能B 控制管理功能A功能B 控制管理» 单体架构缺点当系统的非常庞大的时候，如果只针对单个模块做水平扩展，这一点在单体系统是做不到的。
当大大小小的功能模块都集中在同一项目的时候，整个项目必然会变得臃肿，让开发者难以维护。
整个单体系统的各个功能模块都依赖于同样的数据库、内存等资源，一旦某个功能模块对资源使用不当，整个系统都会被拖垮。
项目过于臃肿1资源无法隔离2扩展性不够3单体架构工商公安人社功能A 功能B 控制管理功能A功能B控制管理功能A 功能B 控制管理无法满足高并发下的业务需求开发都在同一个项目改代码，相互等待，冲突不断代码功能耦合在一起，新人不知道从何下手构建时间长，任何小修改都要重构整个项目，耗时长一个微小的问题，都可能导致整个应用挂掉统一进程集中部署统一认证统一管理效率低1维护难2不灵活3稳定性差4扩展性不够5SOA 架构ESB 服务总线A2服务B2服务C2服务A1服务B1服务C1服务管理控制工商公安人社小最小颗粒化业务模块独 各业务模块独立进程、互不影响轻 轻量级通信方式（Restful Json ）松 服务之间完全松耦合快 快速开发，快速迭代微服务架构A1服务B1服务C1服务A1服务B1服务C1服务管理服务1管理服务2控制服务1控制服务2工商公安人社认证中心注册中心治理中心配置中心消息中心监控中心云应用服务市场1、在线开发平台2、数据服务平台3、工作流服务平台4、文件服务平台5、数据融合平台7、数据检测平台6、运维管理平台010203040506设计、开发、运维、管理一体化“1+6+7”架构体系» 一个云应用服务市场所有应用的功能统一发布到云应用服务市场，由该平台统一对外服务OA项目管理案件审批认证中心authen为各类服务与应用提供统一认证与授权，以用户为中心，以应用与服务为分类，实现用户关联的资源管理与授权，解决了用户与服务、服务与服务间的多种场景鉴权。
微服务架构在现代软件开发的应用与挑战
微服务架构在现代软件开发的应用与挑战浙江省宁波市 315000摘要：微服务架构在现代软件开发中扮演着关键角色，它促进了应用的模块化，提高了可伸缩性和响应速度。
然而，此架构也带来了技术挑战，包括服务发现、负载均衡、通信协议选择和复杂的数据管理问题。
此外，组织和文化上的挑战，如团队结构调整、项目管理复杂性和服务所有权问题，同样不容忽视。
在安全与合规性方面，微服务架构需要有效处理认证、授权和数据保护的问题。
结合新兴技术，如容器化和自动化，微服务架构正在推动软件开发的创新。
这些因素共同预示着微服务架构将对软件开发的未来趋势和长期发展产生深远影响。
关键词：微服务架构,技术挑战,组织与文化变革一、在现代软件开发中的应用微服务架构强调将大型应用程序分解为小型、独立的服务。
每个微服务都是一个独立的模块，负责特定的业务功能。
这种模块化的方法有助于简化开发和维护，因为每个微服务都可以由小团队独立开发、测试和部署。
模块化还促进了代码重用，因为服务可以在不同的应用程序中共享和组合，从而提高了开发效率。
微服务架构使得应用程序的各个组件能够独立扩展。
这意味着可以根据需要增加或减少每个微服务的实例数量，以应对不断变化的负载。
这种精细的可伸缩性控制有助于最大化资源的利用，降低成本，并确保系统在高负载下仍能保持高性能。
此外，微服务还允许使用不同的技术栈和语言来构建每个微服务，以最大程度地优化性能。
微服务架构通过减小服务的范围，使得每个服务可以更快地启动和响应请求。
这有助于提高应用程序的整体响应速度，因为每个微服务都可以独立进行水平扩展，以满足高流量的需求。
此外，微服务架构还支持快速部署和持续交付实践，使得新功能和修复可以更快地交付给用户。
二、技术挑战和组织文化挑战（一）技术挑战在微服务环境中，服务发现是确保服务间顺畅通信的关键。
随着服务数量的增加，动态地定位和连接到正确服务的复杂度也随之上升。
解决这一挑战通常需要使用服务注册和发现机制，例如使用Eureka或Consul等工具，以确保服务能够自动注册自己的位置并被其他服务发现。
微服务的4个设计原则和19个解决方案
微服务的4个设计原则和19个解决⽅案本⽂转⾃：微服务架构现在是谈到企业应⽤架构时必聊的话题，微服务之所以⽕热也是因为相对之前的应⽤开发⽅式有很多优点，如更灵活、更能适应现在需求快速变更的⼤环境。
本⽂将介绍微服务架构的演进、优缺点和微服务应⽤的设计原则，然后着重介绍作为⼀个“微服务应⽤平台”需要提供哪些能⼒、解决哪些问题才能更好的⽀撑企业应⽤架构。
微服务平台也是我⽬前正在参与的，还在研发过程中的平台产品，平台是以SpringCloud为基础，结合了普元多年来对企业应⽤的理解和产品的设计经验，逐步孵化的⼀个微服务应⽤平台。
⼀、微服务架构演进过程近年来我们⼤家都体会到了互联⽹、移动互联带来的好处，作为IT从业者，在⽣活中时刻感受互联⽹好处的同时，在⼯作中可能感受的却是来⾃⾃互联⽹的⼀些压⼒，那就是我们传统企业的IT建设也是迫切需要转型，需要⾯向外部客户，我们也需要应对外部环境的快速变化、需要快速创新，那么我们的IT架构也需要向互联⽹企业学习作出相应的改进，来⽀撑企业的数字化转型。
我们再看⼀下应⽤架构的演进过程，回忆⼀下微服务架构是如何⼀步⼀步进化产⽣的，最早是应⽤是单块架构，后来为了具备⼀定的扩展和可靠性，就有了垂直架构，也就是加了个负载均衡，接下来是前⼏年⽐较⽕的SOA，主要讲了应⽤系统之间如何集成和互通，⽽到现在的微服务架构则是进⼀步在探讨⼀个应⽤系统该如何设计才能够更好的开发、管理更加灵活⾼效。
微服务架构的基本思想就是“围绕业务领域组件来创建应⽤，让应⽤可以独⽴的开发、管理和加速”。
⼆、微服务架构的好处我们总结了四个⽅⾯的优点，分别如下：是每个微服务组件都是简单灵活的，能够独⽴部署。
不再像以前⼀样，应⽤需要⼀个庞⼤的应⽤服务器来⽀撑。
可以由⼀个⼩团队负责更专注专业，相应的也就更⾼效可靠。
微服务之间是松耦合的，微服务内部是⾼内聚的，每个微服务很容易按需扩展。
微服务架构与语⾔⼯具⽆关，⾃由选择合适的语⾔和⼯具，⾼效的完成业务⽬标即可。
软交换平台提供的应用——微服务
软 交换 为 电话 带 来 一 种 开 放 式 基 于标 准 的 分 布 式 网络 架 构 。与 ＰＳ ＴＮ相 比 ，在 基 于 软 交 换 的 网络 中 增 加 新 业 务 的 成 本 更 低 。 而 且 在 软 交 换 上 提 供 的 第 二 种业 务通 常 成 本 比 第 一 种 要 低 。软 交 换 为 传 统 有 线 和 无 线 电 话 网络 带 来 因 特 网 式 的 创 新 能 力 。
６ ０
维普资讯
微 服 务 主 要 是 通 过 确 定 更 小 、 更 窄 范围的人群一一 “ 有 共 同 利 益 的 群 具
两 个 关 键 因 素 。在 传 统 ＰＳＴＮ 网络 中 ，４ 类 和 ５类 交 换 机 负 责 多 种 功 能 ：呼 叫控 制 、呼 叫 处 理 、信 令 、应 用 和 业 务 。所 有 这 些 功 能 都锁 定在 单 个一 体 化 平 台 中 。 电路交 换环 境 中的业 务开 发和 创建 非常 耗 费 时 间 、 成 本 高 昂 并 风 险 很 大 。 交 且 软
微服 务的关键 平台
微 服 务 的一 个 主 要 优 点 是其 创建 的 方 便 。 电信 商 、第 三 方 开 发 商 或 电信 设 备 供
ห้องสมุดไป่ตู้
应 商 （ Ｃ ｍｍＷ ｏ ｋ ） 如 ｏ ｒｓ ，都 可开 发微 服 务 。
Ｃｏ ｍｍＷ ｏ ｋ ｒｓ公 司提 供 了 微 服 务 开 发所 需 要 的 架 构 、 术 、支持 和 合作 伙伴 关 系 。 技 实 现 微 服 务 的 平 台 包括 多 个组 成 部 分 ： Ｃｏ ｍｍＷ ｏｒｓ公 司 微 服 务 战 略 的 核 ｋ
待 服 务 看 起 来 差 不 多 ，花 费 也 差 不 多 ，而 且 与 无 线
面向高性能计算环境的微服务运维平台设计与实现
收稿日期：２０２０⁃０１⁃１０；修回日期：２０２０⁃０４⁃０２㊀㊀基金项目：国家重点研发计划资助项目（２０１８ＹＦＢ０２０４００１）；中科院信息化专项课题资助项目（ＸＸＨ１３５０３⁃０４）作者简介：张鼎超（１９９４⁃），男，山东济南人，硕士研究生，主要研究方向为高性能计算㊁可视化与网格技术（ｚｈａｎｇｄｉｎｇｃｈａｏ＠ｃｎｉｃ．ｃｎ）；王小宁（１９８１⁃），女，四川资阳人，副研究员，博士，主要研究方向为网格技术㊁云服务与分布式系统㊁高性能计算环境软件与技术；肖海力（１９７８⁃），男，湖北天门人，研究员，硕士，主要研究方向为网格技术㊁分布式系统；卢莎莎（１９８５⁃），女，河北饶阳人，工程师，硕士，主要研究方向为网格计算㊁持续交付；和荣（１９８８⁃），女，山东新泰人，工程师，硕士，主要研究方向为网格计算；迟学斌（１９６３⁃），男，吉林梅河口人，研究员，博士，主要研究方向为高性能计算㊁并行计算．面向高性能计算环境的微服务运维平台设计与实现∗张鼎超１，２，王小宁１，肖海力１，卢莎莎１，和㊀荣１，迟学斌１，２（１．中国科学院计算机网络信息中心，北京１００１９０；２．中国科学院大学，北京１０００４９）摘㊀要：国家高性能计算环境为提高应用服务的持续交付能力逐步引进微服务架构㊂针对国家高性能计算环境由传统单体架构向微服务架构转变引入的新的运维问题，设计并实现了面向高性能计算环境的微服务运维平台，拟面向开发运维人员，降低开发难度，提升运维效率㊂重点研究并实现了微服务运维平台中的服务部署及管理㊁服务运行监控和服务弹性伸缩特色功能，通过应用化封装技术对服务部署及管理过程进行封装，同时设计用户权限管理机制，利用ＥＦＫ和Ｐｒｏｍｅｔｈｅｕｓ分别完善高性能计算环境的日志收集功能和监控告警功能，通过ＨｏｒｉｚｏｎｔａｌＰｏｄＡｕｔｏｓｃａｌｅｒ资源对象实现基于ＣＰＵ㊁内存等核心指标以及ＱＰＳ等自定义指标的服务规模弹性伸缩技术㊂测试结果表明，微服务运维平台可以实现高性能计算环境中以项目为划分依据的一键式服务部署㊁更新㊁删除等操作，提供交互性更好的可视化运行监控方案，应对流量高峰场景，增强应用服务可靠性㊂关键词：高性能计算环境；微服务；运维平台；容器编排；弹性伸缩０㊀引言国家高性能计算环境，即中国国家网格（ＣｈｉｎａＮａｔｉｏｎａｌＧｒｉｄ，ＣＮＧｒｉｄ），起源于国家 ８６３ 计划，在国家科技计划持续支持下其资源聚合能力得到了快速发展㊂目前，国家高性能计算环境的聚合计算资源超过２６０ＰＦＬＯＰＳ，总存储资源超过２００ＰＢ㊂国家高性能计算环境基于科学计算中间件（ｓｃｉｅｎｔｉｆｉｃｃｏｍｐｕｔｉｎｇｅｎｖｉｒｏｎｍｅｎｔ，ＳＣＥ）提供计算服务，主要包括作业服务㊁资源服务以及数据服务，有效地支撑了生物医药应用社区㊁工业产品创新设计社区㊁新药创制社区㊁教育平台的建设，实现服务多样化和专业化，降低高性能计算应用成本，提升高性能计算应用的服务水平，方便用户进行科学计算与研究㊂随着计算资源的持续接入聚合㊁用户数量的不断上升㊁作业量的不断加大，应用服务的持续交付需求也逐渐增强，高性能计算环境的各类服务以及多种应用社区都开始从传统应用架构向结构更加灵活的微服务架构转变㊂微服务是一些小而自治服务的统称㊂相较于传统的单体架构和面向服务架构，应用微服务化具有技术异构性㊁易于扩展㊁简化部署㊁与组织结构相匹配以及对可替代性优化等明显的优势［１］㊂微服务架构的蓬勃发展离不开底层容器技术的支持，容器是一种轻量级㊁自包含的软件打包技术，利用容器技术可以实现应用程序的简化部署㊂微服务和容器技术的盛行推动着高性能计算环境中的系统服务和社区服务从单体架构向微服务架构形式转变㊂单体应用按业务领域被拆分为众多细粒度的服务，应用程序的部署迁移变得更加便捷，与此同时也因为容器数量的骤增，服务的管理控制㊁运行维护也越来越困难㊂Ｋｕｂｅｒｎｅｔｅｓ［２，３］作为Ｇｏｏｇｌｅ公司开源的一款容器编排引擎，是一个完备的分布式系统支撑平台，其针对容器服务提供了自动化的部署回滚机制，具有透明的服务注册和服务发现能力㊁灵活的服务扩缩容特性㊁可配置的负载均衡机制以及强大的故障诊断和修复机制㊂Ｋｕｂｅｒｎｅｔｅｓ和微服务架构相辅相成，促进了高性能计算环境的微服务架构实践落地㊂Ｋｕｂｅｒｎｅｔｅｓ主要通过命令行客户端或者开源社区提供的Ｋｕ⁃ｂｅｒｎｅｔｅｓｄａｓｈｂｏａｒｄ提供容器编排管理的服务，使用者需要熟悉容器领域的相关专业知识㊁Ｋｕｂｅｒｎｅｔｅｓ的应用架构，以及该生态环境中庞大复杂的各类工具与插件，不仅需要很高的学习成本㊁复杂的操作技巧，而且难以满足用户对于微服务架构高效便捷的期望㊂为解决上述问题，本文构建了一个面向高性能计算环境的微服务运维平台㊂该微服务运维平台在业务层面上对服务部署和服务管理进行了进一步封装，屏蔽了Ｋｕｂｅｒｎｅｔｅｓ和容器领域的相关概念，促使开发运维人员更专注于微服务应用自身，通过可视化的交互界面可以实现面向项目的应用服务一键部署和管理，同时集成了日志检索和监控告警技术，并为微服务配置了全面的自动扩缩容功能，使得微服务可以根据ＣＰＵ㊁内存以及用户自定义指标进行自动规模调整㊂该微服务运维平台可以同时运维管控高性能计算环境的系统服务和社区服务，达到降低技术门槛㊁提高运维效率㊁增强用户体验㊁提升应用服务可靠性的目的㊂１㊀相关工作目前学术界和工业界都在微服务架构的实践落地方面作出了重要的探索和贡献，尤其是众多企业各自给出了功能完善的微服务架构的落地方案㊂微服务是一种从面向服务的体系结构中脱颖而出的体系结构方法，其提倡自我管理和轻量级用于提高软件的敏捷性㊁可伸缩性和自治性㊂Ｊａｍｓｈｉｄｉ等人［４］从技术和体系结构的角度研究了微服务的发展历程，并总结了微服务架构未来在服务模块化和重构㊁服务粒度㊁前端整合㊁资源监控管理以及服务故障恢复等方面将要遭遇的挑战㊂ＤｅｖＯｐｓ是一种旨在减少系统更改和将更改转移到生产环境过程中时间的实践㊂任何实现这些目标的技术都被视为ＤｅｖＯｐｓ实践㊂持续交付（ｃｏｎｔｉｎｕｏｕｓｄｅｌｉｖｅｒｙ，ＣＤ）是ＤｅｖＯｐｓ的一种做法，通过自动化机制将软件按需部署到任何环境㊂随着可部署服务数量的增加，ＣＤ成为微服务架构的重要组成部分㊂Ｂａｌａｌａｉｅ等人［５］通过商业移动后端的体系结构重构和服务迁移解释了ＤｅｖＯｐｓ在消除开发团队与运营团队之间协调关系障碍㊁平稳进行微服务架构迁移过程中的重要作用㊂Ｍａｒｉｅ⁃Ｍａｇｄｅｌａｉｎｅ等人［６］提出了一个可视化微服务编排框架，该框架提供了一种了解微服务在不同层㊁生命周期和抽象级别的内部行为的方法㊂Ｍａｙｅｒ等人［７］提供了一个用于微服务监控和管理的仪表盘，支持集成服务的运行时信息和其他信息源，以提供有关微服务和微服务开发的静态信息㊂企业级分布式应用服务（ｅｎｔｅｒｐｒｉｓｅｄｉｓｔｒｉｂｕｔｅｄａｐｐｌｉｃａｔｉｏｎｓｅｒ⁃ｖｉｃｅ，ＥＤＡＳ）［８］是阿里云开发的一款应用托管㊁容器托管和微服务管理的ＰａａＳ平台，其提供了应用程序开发㊁部署㊁监控㊁运维一系列全栈式解决方案，简化了微服务向云上迁移的过程㊂ＥＤＡＳ是一个多样的应用托管平台，用户可以根据具体的需求选择使用ＥＣＳ集群㊁基于容器服务的Ｋｕｂｅｒｎｅｔｅｓ集群或者是ＥＤＡＳＳｅｒｖｅｒｌｅｓｓ来对应用进行部署管控，不必去关心底层的基础设施㊂同时ＥＤＡＳ支持丰富的微服务框架，开发人员可以针对原生的Ｄｕｂｂｏ㊁ＨＳＦ或是ＳｐｒｉｎｇＣｌｏｕｄ框架对应用进行开发运维，并交于ＥＤＡＳ管理㊂微服务引擎（ｃｌｏｕｄｓｅｒｖｉｃｅｄｎｇｉｎｅ，ＣＳＥ）［９］是华为云开发的一款用于企业应用微服务化的解决方案，提供高性能微服务框架和一站式服务注册㊁服务治理㊁动态配置和分布式事务管理控制台，帮助用户实现微服务应用的快速开发和高可用运维㊂ＣＳＥ提供了Ｊａｖａ㊁Ｇｏ㊁．ＮＥＴ㊁Ｎｏｄｅ．ｊｓ㊁ＰＨＰ等多语言微服务解决方案，支持开源核心框架ＳｅｒｖｉｃｅＣｏｍｂ，同时基于开源框架ＳｐｒｉｎｇＣｌｏｕｄ和ＳｅｒｖｉｃｅＭｅｓｈ开发的应用可以零业务代码修改，直接对接ＣＳＥ运行环境㊂作为华为核心业务ＣｌｏｕｄＮａｔｉｖｅ转型基础底座，ＣＳＥ经过了华为终端业务亿级用户考验，因此十分稳定可靠㊂京东云微服务平台（ＪＤＣｌｏｕｄｄｉｓｔｒｉｂｕｔｅｄｓｅｒｖｉｃｅｆｒａｍｅｗｏｒｋ，ＪＤＳＦ）［１０］是一种托管应用的服务治理框架，其围绕微服务实践落地流程提供了服务部署㊁注册㊁调用㊁日志和监控等生命周期管理功能，同时支持丰富的调用堆栈分析，在宏观上可以为用户提供全㊃０９１㊃计算机应用研究２０２０年㊀面的服务关系图谱，微观上给出了微服务间的调用链关系㊂ＪＤＳＦ目前支持ＳｐｒｉｎｇＣｌｏｕｄ㊁Ｄｕｂｂｏ等应用类型，同时兼容Ｇｏ㊁ＤｏｔＮｅｔ㊁Ｐｙｔｈｏｎ等语言的各种开发框架㊂２㊀面向高性能计算环境的微服务运维平台架构本文提出的微服务运维平台主要面向高性能计算环境中的运维开发人员，由以下三部分技术构成：ａ）服务部署及管理技术，用于微服务部署㊁检索和治理等操作，简化运维人员操作复杂度㊂ｂ）服务运行监控技术，用于服务的日志检索和监控告警功能，便于用户追溯定位异常告警㊂ｃ）服务弹性伸缩技术，用于微服务根据其核心指标或者自定义指标自动扩缩容，提高微服务应用的可靠性，增强资源利用率㊂技术之间交互过程如下：开发人员访问可视化ｄａｓｈｂｏａｒｄ，通过服务部署及管理模块将服务以项目为单位部署于微服务运维平台，服务弹性伸缩模块由部署及管理模块获取服务静态信息，同时借助服务运行监控模块采集服务相关指标动态控制服务规模㊂整个运维平台以ｄｏｃｋｅｒ容器的形式运行在Ｋｕｂｅｒｎｅｔｅｓ集群中提供服务，由Ｋｕｂｅｒｎｅｔｅｓ负责运维平台的服务发现㊁滚动升级和故障恢复等管理控制㊂微服务运维平台的详细架构如图１所示㊂２．１㊀服务部署及管理技术服务部署及管理技术主要提供以下功能：服务部署㊁服务检索㊁配置更新㊁应用更新和服务删除㊂原生Ｋｕｂｅｒｎｅｔｅｓ作为一个功能完备的容器编排引擎，可以支持丰富的应用类型及灵活的功能配置，被广泛应用于各种应用的架构转型实践中，与此同时，数量庞大的专业概念㊁复杂多变的配置设置也大大增加了用户的使用难度㊂面向高性能计算环境的微服务运维平台旨在降低技术门槛和学习成本，简化开发人员的设计流程，提高运维人员的运维效率㊂针对高性能计算环境中系统㊁社区等应用服务的特点，服务部署及管理技术在保持应用功能完备的基础上定制化封装了ＫｕｂｅｒｎｅｔｅｓＡＰＩ，屏蔽了ｓｅｒｖｉｃｅ㊁ｄｅｐｌｏｙｍｅｎｔ㊁ｃｏｎｆｉｇＭａｐ和ｈｏｒｉｚｏｎｔａｌｐｏｄａｕｔｏｓｃａｌｅｒ（ＨＰＡ）等专业术语，取而代之的则是项目服务㊁配置文件和服务数目贴近应用服务的概念，很大程度上降低了开发运维人员的学习成本㊂服务概念对应关系如图２所示㊂图３展示了服务部署的流程，通过定制封装原生ＫｕｂｅｒｎｅｔｅｓＡＰＩ，用户只需关注应用程序㊁参数以及配置文件即可实现高性能计算环境中微服务的一键部署及管理㊂主要定制化实现如下：ａ）身份认证和参数检查㊂目前高性能计算环境中的应用主要为系统服务和社区服务，对于不同的服务项目有相应的开发运维团队进行运行维护，该技术基于Ｋｕｂｅｒｎｅｔｅｓ的ｎａｍｅｓｐａｃｅ构建了身份认证功能，设置用户对于不同项目的管理使用权限，增加不同项目应用之间的隔离性；补充了参数检查环节，对用户输入的应用参数进行合法性检查，提高微服务部署成功率㊂ｂ）ｄｏｃｋｅｒｉｍａｇｅ定制优化㊂针对高性能计算环境中应用持续交付和配置更新的需求特点，本文搭建了具有漏洞安全扫描功能的本地镜像仓库，极大地提高了容器镜像的安全性以及镜像的传输速度；在构建应用容器镜像过程中，配置应用热更新设置，达到配置文件同步更新的目的；同时以动态可扩展形式构建镜像封装方案，在目前支持Ｔｏｍｃａｔ㊁ＭｙＳＱＬ和ＳｐｒｉｎｇＢｏｏｔ应用的基础上，用户可以灵活集成其他应用类型㊂ｃ）ｃｏｎｆｉｇＭａｐ定制优化㊂原生Ｋｕｂｅｒｎｅｔｅｓ提供了ｃｏｎｆｉｇＭａｐ资源对象管理配置数据，既可以用来保存单个属性，也可以用来保存配置文件，用户通过环境变量或者挂载卷的形式使用，简化了配置文件的更新操作；ｃｏｎｆｉｇＭａｐ同时存在一些固化的弊端，其以挂载卷的形式管理配置文件时，配置文件在容器内是以只读文件系统的形式存在，对于高性能计算环境中的应用服务，并没有加载配置文件的对应权限，导致应用部署失败㊂该技术针对于此弊端对ｃｏｎｆｉｇ⁃Ｍａｐ挂载机制进行优化，通过设置软链接避免文件权限的问题，完善配置文件的热更新㊂ｄ）通过官方提供的客户端库，封装定制原生Ｋｕｂｅｒｎｅｔｅｓ检索功能，丰富微服务检索信息；通过上传配置文件，自动更新ｃｏｎｆｉｇ⁃Ｍａｐ，同步更新微服务中配置文件；通过上传应用程序包，自动更新容器镜像，同步更新微服务应用；一键式删除微服务应用对应的ｄｅｐｌｏｙｍｅｎｔ㊁ｓｅｒｖｉｃｅ以及配置文件管理工具ｃｏｎｆｉｇＭａｐ，避免复杂重复操作㊂２．２㊀服务运行监控技术服务运行监控技术主要提供以下功能：ａ）灵活的日志收集检索功能㊂微服务运维平台采用开源日志收集解决方案Ｅｌａｓｔｉｃｓｅａｒｃｈ㊁Ｆｌｕｅｎｔｄ和Ｋｉｂａｎａ（ＥＦＫ）对高性能计算环境中服务日志进行收集㊁检索和展示㊂Ｅｌａｓｔｉｃｓｅａｒｃｈ是一个实时的㊁分布式的可扩展搜索和分析引擎，在ＡｐａｃｈｅＬｕｃｅｎｅ基础上构建而成，因此在全文搜索方面表现十分出色，同时数据分布在不同的分片中，允许复制进行冗余备份；Ｆｌｕｅｎｔｄ是一款用于统一日志层的开源数据采集器，允许用户在将日志数据索引到Ｅｌａｓｔｉｃｓｅａｒｃｈ之前，对日志数据进行过滤和转换，添加服务元信息等标签，提高数据检索的便捷性；Ｋｉｂａｎａ是一款功能强大的数据可视化和管理工具，允许用户通过Ｗｅｂ界面检索浏览Ｅｌａｓｔｉｃｓｅａｒｃｈ日志数据，同时可以提供实时的直方图㊁折线图和饼状图㊂本文提供的基于ＥＦＫ的日志收集架构如图４所示㊂具体技术实现如下：在Ｋｕｂｅｒｎｅｔｅｓ集群中通过ＤａｅｍｏｎＳｅｔ资源对象部署Ｆｌｕｅｎｔｄ应用，收集每个服务器节点内部存储的容器日志，对日志数据添加项目名称㊁服务名称等标签，通过制定传输规则将日志存储在全文搜索引擎Ｅｌａｓｔｉｃｓｅａｒｃｈ中，并配有分布式持久化存储冗余备份，同时将可视化工具Ｋｉｂａｎａ集成于微服务运维平台可视化界面中用于日志检索㊂ｂ）完善的运行监控告警功能㊂该运维平台集成了开源监控系统Ｐｒｏｍｅｔｈｅｕｓ，其最初是在ＳｏｕｎｄＣｌｏｕｄ上构建的开源系统监控和告警工具包，于２０１６年加入ＣｌｏｕｄＮａｔｉｖｅＣｏｍｐｕｔｉｎｇＦｏｕｎｄａｔｉｏｎ成为继Ｋｕｂｅｒｎｅｔｅｓ之后的第二个托管项目㊂Ｐｒｏｍｅｔｈｅｕｓ监控方案适用于监控收集时间序列数据，通过ｅｘｐｏｒｔｅｒ插件和Ｋｕｂｅ⁃ｓｔａｔｅ⁃ｍｅｔｒｉｃｓ工具采集资源对象的状态指标，在对多维数据收集和查询的方面具有独特的优势㊂基于Ｐｒｏｍｅｔｈｅｕｓ的监控告警架构如图５所示㊂具体技术实现如下：利用Ｐｒｏｍｅｔｈｅｕｓ监控Ｋｕｂｅｒｎｅｔｅｓ集群节点以及部署服务的ＣＰＵ㊁内存㊁网络等核心指标，针对高性能计算环境㊃１９１㊃㊀第３７卷增刊张鼎超，等：面向高性能计算环境的微服务运维平台设计与实现㊀㊀㊀中微服务特点，设计监控指标和规则采集用户自定义指标；在Ｐｒｏｍｅ⁃ｔｈｅｕｓｓｅｒｖｅｒ中制定报警规则，并借助ａｌｅｒｔＭａｎａｇｅｒ管理告警信息，灵活地选择诸如电子邮件㊁钉钉等工具进行消息提示；将可视化工具Ｇｒａｆａｎａ集成到微服务运维平台中用于提升用户的交互体验㊂２．３㊀服务弹性伸缩技术高性能计算环境中服务以系统服务和社区服务为主，形式主要为网站和ＡＰＩ服务等在线任务类型，其对ＣＰＵ㊁内存㊁网络Ｉ／Ｏ等常规资源消耗较大㊂服务弹性伸缩技术主要针对上述情况用于高性能计算环境中微服务的自动规模控制㊂微服务可以依据自身的ＣＰＵ㊁内存等核心指标或者ＱＰＳ等自定义指标进行规模的弹性伸缩，可以有效缓解流量突发带来的访问压力，应对业务高峰场景㊂该技术基于Ｋｕｂｅｒｎｅｔｅｓ的ＨＰＡ资源对象实现，ＨＰＡ通过周期性的查询机制监控其指定的服务核心资源指标和用户自定义指标负载，根据当前指标和期望指标采用式（１）计算微服务的缩放比例㊂ｄＲ＝ｃｅｉｌ［ｃＲˑ（（ｃＭＶ／ｄＭＶ））］（１）其中：ｄＲ㊁ｃＲ㊁ｃＭＶ㊁ｄＭＲ分别表示期望服务数㊁当前服务数㊁当前指标和期望指标；ｃｅｉｌ表示向上取整函数㊂ＨＰＡ的工作模式如图６所示㊂服务弹性伸缩技术的实现流程如下：ＨＰＡ通过部署的ｍｅｔｒｉｃｓｓｅｒｖｅｒ监控微服务的ＣＰＵ㊁内存等核心指标，同时针对高性能计算环境中微服务多为在线任务的特点构建Ｐｒｏｍｅｔｈｅｕｓ⁃ａｄａｐｔｅｒ并制定指标转换和计算规则，将Ｐｒｏｍｅｔｈｅｕｓ采集的用户自定义指标转换为其可以识别的指标，通过多指标监控可以实现灵活的微服务弹性伸缩效果㊂３㊀性能测试３．１㊀测试环境为了验证面向高性能计算环境的微服务运维平台在封装服务部署和管理流程，屏蔽容器和Ｋｕｂｅｒｎｅｔｅｓ相关领域专业概念带来的简便性和易用性效果，同时对构建的微服务运维平台进行弹性伸缩测试，本文搭建了一个单ｍａｓｔｅｒ节点的Ｋｕｂｅｒｎｅｔｅｓ集群，将微服务运维平台以ｄｏｃｋｅｒ容器的形式部署到Ｋｕｂｅｒｎｅｔｅｓ集群中，用户可以通过可视化的前端界面与微服务运维平台交互㊂集群配置如表１所示㊂表１㊀Ｋｕｂｅｒｎｅｔｅｓ集群服务器配置节点类型ＣＰＵ数内核数内存／ＧＢｍａｓｔｅｒ２４８ｎｏｄｅ１１２４ｎｏｄｅ２１２４ｎｏｄｅ３１２４㊀㊀本文采用开发人员实现的国家高性能计算环境中ｐｏｒｔａｌ接口服务对微服务运维平台中有关服务部署及管理㊁服务运行监控以及服务弹性伸缩技术相关功能进行性能测试，同时利用Ｋｕｂｅｒｎｅｔｅｓ原生命令行客户端ｋｕｂｅｌｅｔ进行对应功能实现以对比效果㊂访问微服务运维平台可视化界面，通过客户端上传ｐｏｒｔａｌ应用ｗａｒ包和配置文件，同时指定部署服务的项目名称㊁服务名称㊁部署数目等基本信息，一键生成可动态更新配置文件的微服务应用，测试得从上传文件到服务部署完成过程中消耗时间平均为６７ｓ，其中主要为上传文件包消耗的时间，大大降低了高性能计算环境中服务部署的时间成本㊂服务部署及管理技术可视化效果如图７所示㊂访问微服务运维平台可视化界面，通过服务运行监控技术可以利用服务名称㊁项目名称㊁时间等关键字检索高性能计算环境中微服务的日志信息，同时查看部署微服务的ＣＰＵ㊁内存㊁网络等监控信息㊂本文使用Ａｐａｃｈｅ组织开发的压力测试工具ＡｐａｃｈｅＢｅｎｃｈｍａｒｋ对部署的ｐｏｒｔａｌ接口服务进行压力测试，验证微服务运维平台中服务弹性伸缩技术功能性能㊂测试过程采用并发数为１００，压力测试总次数为１０００００次的访问请求，接口服务伸缩指标设置为ＣＰＵ，限额为资源请求的８０％，通过微服务运维平台的服务运行监控技术采集服务的负载信息和伸缩信息，测试结果如图８所示㊂从图中可以看出，微服务可以根据弹性伸缩算法应对压力测试，合理调整微服务规模㊂４㊀结束语本文针对高性能计算环境中应用服务的架构转型，为了满足提高开发运维效率㊁增强持续交付能力㊁增加应用服务稳定性以及降低学习成本的需求，基于Ｋｕｂｅｒｎｅｔｅｓ构建了面向高性能计算环境的微服务运维平台，根据系统服务和社区服务类型特点定制了服务部署及管理技术㊁服务运行监控技术和服务弹性伸缩技术㊂经测试，该微服务运维平台功能与高性能计算环境应用服务需求相契合，降低了操作复杂度，同时保证了应用服务的持续稳定性㊂但弹性伸缩技术是在保证集群节点资源充足的情况下实现服务的横向扩展，在后续过程中将针对集群资源的纵向扩展加以设计实现，以更加契合高性能计算环境的服务需求㊂参考文献：［１］ＮｅｗｍａｎＳ．微服务设计［Ｍ］．崔力强，张骏，译．北京：人民邮电出版社，２０１６：３⁃７．［２］ＢｕｒｎｓＢ，ＧｒａｎｔＢ，ＯｐｐｅｎｈｅｉｍｅｒＤ，ｅｔａｌ．Ｂｏｒｇ，Ｏｍｅｇａ，ａｎｄＫｕｂｅｒ⁃ｎｅｔｅｓ［Ｊ］．Ｑｕｅｕｅ，２０１６，１４（１）：７０⁃９３．［３］ＢｅｒｎｓｔｅｉｎＤ．Ｃｏｎｔａｉｎｅｒｓａｎｄｃｌｏｕｄ：ｆｒｏｍＬＸＣｔｏＤｏｃｋｅｒｔｏＫｕｂｅｒｎｅｔｅｓ［Ｊ］．ＩＥＥＥＣｌｏｕｄＣｏｍｐｕｔｉｎｇ，２０１４，１（３）：８１⁃８４．［４］ＪａｍｓｈｉｄｉＰ，ＰａｈｌＣ，ＭｅｎｄｏｎｃａＮＣ，ｅｔａｌ．Ｍｉｃｒｏｓｅｒｖｉｃｅｓ：ｔｈｅｊｏｕｒｎｅｙｓｏｆａｒａｎｄｃｈａｌｌｅｎｇｅｓａｈｅａｄ［Ｊ］．ＩＥＥＥＳｏｆｔｗａｒｅ，２０１８，３５（３）：２４⁃３５．［５］ＢａｌａｌａｉｅＡ，ＨｅｙｄａｒｎｏｏｒｉＡ，ＪａｍｓｈｉｄｉＰ．Ｍｉｃｒｏｓｅｒｖｉｃｅｓａｒｃｈｉｔｅｃｔｕｒｅｅｎ⁃ａｂｌｅｓＤｅｖＯｐｓ：ｍｉｇｒａｔｉｏｎｔｏａｃｌｏｕｄ⁃ｎａｔｉｖｅａｒｃｈｉｔｅｃｔｕｒｅ［Ｊ］．ＩＥＥＥＳｏｆｔ⁃ｗａｒｅ，２０１６，３３（３）：４２⁃５２．［６］Ｍａｒｉｅ⁃ＭａｇｄｅｌａｉｎｅＮ，ＡｈｍｅｄＴ，Ａｓｔｒｕｃ⁃ＡｍａｔｏＧ．Ｄｅｍｏｎｓｔｒａｔｉｏｎｏｆａｎｏｂｓｅｒｖａｂｉｌｉｔｙｆｒａｍｅｗｏｒｋｆｏｒｃｌｏｕｄｎａｔｉｖｅｍｉｃｒｏｓｅｒｖｉｃｅｓ［Ｃ］／／ＰｒｏｃｏｆＩＦＩＰ／ＩＥＥＥＳｙｍｐｏｓｉｕｍｏｎＩｎｔｅｇｒａｔｅｄＮｅｔｗｏｒｋａｎｄＳｅｒｖｉｃｅＭａｎａｇｅ⁃ｍｅｎｔ．Ｐｉｓｃａｔａｗａｙ，ＮＪ：ＩＥＥＥＰｒｅｓｓ，２０１９：７２２⁃７２４．［７］ＭａｙｅｒＢ，ＷｅｉｎｒｅｉｃｈＲ．Ａｄａｓｈｂｏａｒｄｆｏｒｍｉｃｒｏｓｅｒｖｉｃｅｍｏｎｉｔｏｒｉｎｇａｎｄｍａｎａｇｅｍｅｎｔ［Ｃ］／／ＰｒｏｃｏｆＩＥＥＥＩｎｔｅｒｎａｔｉｏｎａｌＣｏｎｆｅｒｅｎｃｅｏｎＳｏｆｔｗａｒｅＡｒｃｈｉｔｅｃｔｕｒｅＷｏｒｋｓｈｏｐｓ．Ｐｉｓｃａｔａｗａｙ，ＮＪ：ＩＥＥＥＰｒｅｓｓ，２０１７：６６⁃６９．［８］ＡｌｉｂａｂａＣｌｏｕｄ．ＥＤＡＳ［ＥＢ／ＯＬ］．［２０１９⁃１１⁃１２］．ｈｔｔｐｓ：／／ｗｗｗ．ａｌｉｙｕｎ．ｃｏｍ／ｐｒｏｄｕｃｔ／ｅｄａｓ？ｓｐｍ＝５１７６．２２４２００．１００．１９１．７ｄ７３６ｅｄ６ｓＲｓＱＵｍ．［９］ＨｕａｗｅｉＣｌｏｕｄ．ＣＳＥ［ＥＢ／ＯＬ］．［２０１９⁃１１⁃１２］．ｈｔｔｐｓ：／／ｗｗｗ．ｈｕａｗｅｉ⁃ｃｌｏｕｄ．ｃｏｍ／ｐｒｏｄｕｃｔ／ｃｓｅ．ｈｔｍｌ．［１０］ＪｉｎｇｄｏｎｇＣｌｏｕｄ．ＪＤＳＦ［ＥＢ／ＯＬ］．［２０１９⁃１１⁃１２］．ｈｔｔｐｓ：／／ｗｗｗ．ｊｄ⁃ｃｌｏｕｄ．ｃｏｍ／ｃｎ／ｐｒｏｄｕｃｔｓ／ｊｄ⁃ｄｉｓｔｒｉｂｕｔｅｄ⁃ｓｅｒｖｉｃｅ⁃ｆｒａｍｅｗｏｒｋ．㊃２９１㊃计算机应用研究２０２０年㊀。