金融云经典应用服务简介以及运维实践(二)| 学习笔记

本文涉及的产品
对象存储 OSS,20GB 3个月
对象存储 OSS,恶意文件检测 1000次 1年
对象存储 OSS,内容安全 1000次 1年
简介: 快速学习金融云经典应用服务简介以及运维实践

开发者学堂课程【金融云经典应用服务简介以及运维实践:金融云经典应用服务简介以及运维实践(二)】学习笔记,与课程紧密联系,让用户快速学习知识。

课程地址:https://developer.aliyun.com/learning/course/1208/detail/18175


金融云经典应用服务简介以及运维实践


三、应用管理

1. 产品概述

应用管理:应用管理是金融科技的基础服务之一 ,为用户提供了应用基本信息的管理服务。

从以下四个方面进行管理:

(1)分组管理: 应用分组管理提供了垂直维度的应用区分功能,例如有业务关联的应用可以设置为同一分组。

(2)分级管理: 应用分级管理提供了水平维度的应用区分功能,例如从系统对业务的重要性来区分不同的应用。

(3)元数据:在创建或者编辑应用时,给应用添加自定义的元数据,便于应用分类管理。

(4)技术栈管理:技术栈定义了应用发布部署和运维时应用的依赖信息。例如,对典型的 Web 应用系统,常见的依赖信息包括服务器系统和版本、Web 服务器类型和版本、应用启动脚本等。

租户隔离和工作空间分享:

image.png

在环境里具有多个租户,有租户 A、租户 B 和租户 N,在租户 A 里可以有应用 A、应用 B 和应用 N,在租户 B 里可以有应用A、应用 B  和应用 N。这些应用是以租户的形式进行隔离的,但是租户内的应用不会隔离。

工作空间共享就是在租户里可能有不同的工作空间,工作空间 A、工作空间B和工作空间 C,在 A、B、C 三个工作空间里看到应用 A、B、C 均为一致,即为一个工作空间共享的功能。

以下是应用管理的控制台:

具有一个应用列表,列表里可以创建应用,创建应用之后还可以得到应用别名、分组等级、记录栈、负责人、创建人,状态是创建完成,还可以对应用进行编辑和删除,在工作空间共享这里可以切换工作空间,切换工作空间会有测试环境空间。  

技术栈管理包括操作系统有哪些,支持的地域,相应的记录栈。

 

四、发布部署(DEPS)

1.产品概述及架构

发布部署服务为用户提供以应用服务为核心视图,对版本、发布包、资源等进行可视化、自动化管理。提供功能丰富的发布策略,如分组灰度发布、蓝绿发布等能力,以满足金融场景下的严苛要求。

发布部署的产品为 Deps,相关介绍如下

image.png

2.功能组成

包括三方面:应用服务、发布部署、日常运维。

应用服务:服务实例管理指一个服务实例是一个应用版本,一个服务实例对应一个微服务软件;发布包可理解为安装包,安装包可以安装客户自己的应用。

发布部署:分为正向发布和逆向发布。正向发布包括普通发布、蓝绿发布;逆向发布包括发布取消、发布回滚。

日常运维:包括应用运维、服务器运维、指令模板。

(1)功能组成—普通发布

普通发布提供应用的发布、回滚,用户可以对需要发布的应用编辑依赖关系、调整服务器分组,并选择部署策略等。

image.png

在发布署上会有创建发布单的功能,创建一个发布单在类型里面就会创建一个普通发布的发布单,可以对是否使用发布流程模板选择分组策略,是否使用 bate 分组,是否使用灰度引流,是否使用SLB引流。

①分组策略

快速分组:服务器平均分组, 默认分两组,Beta 分组除外。

默认分两组指有四台服务器建立一个发布单的时候,即发布一个应用有四台服务器会默认分两组,两台服务器一组进行分组发布。先发布第一组,第一组有两台机器,对其进行发布;后面两台服务器等第一组两台服务器发布完成之后,再发布第二组的两台机器。

共分一组:服务器全部分在一个分组,Beta 分组除外。

指四台服务器均在一个分组里面,相当于同时发布,即四台服务器同时进行发布部署。

每台一组:一个服务器一组,Beta 分组除外。

指有例如有四台服务器,则一台服务器一组,先发布第一台服务器,第一台服务器发布成功之后再发布第二台服务器,再发布第三台服务

器,再发布第四台服务器。

按部署单元分组:一个部署单元一组,Beta 分组除外。

例如可能只有一个部署单元则每台一组,如果有两个部署单元,一个部署单元每台一组服务器,另一个部署单元每台一组服务器。

②Beta 分组是指以应用为维度,从各个数据中心获取一台机器作为 Beta 分组机器成员。在发布过程中,作为首个分组进行发布,完成后需手动确认方可执行后续发布。

即在发布的时候可以选择多个应用,一个发布单是可以选择多个应用的。一个应用可能有多台机器,比如应用A有两台服务器,则会从应用 A 的两台机器里随机挑选一台机器作为 Beta 分组机器成员。发布完成之后不会继续发布应用A的另一台机器,会存在一个确认的按钮。此时可以先发布到一台机器上去确认服务是否正常启动、安装部署是否成功,如果都成功则可以点击确认,确认之后会发布下一个分组。

③灰度引流指每个机器分组发布完成后不执行自动引流,通过

人工调整流量权重,进行调拨验证;每个机器分组都必须手动确认后才能执行下一组。

即如果服务器挂在 SLB 上则会存在流量权重,例如有两台服务器,一台服务器的引流权重是50,另一台是50。在发布之前会对流量权重打一个快照,如果不使用灰度引流的话,发布之前是50跟50,发布之后仍为50跟50;如果使用灰度引流,在发布完成之后不会按照之前的快照进行分配。此时存在人工调整流量权重,比如可以设置一个服务器为10跟10。此时可以观察引流10流量权重是否运行正常,是否出现问题;如果没有问题再引流20,慢慢的引流30、40,即为调拨验证的功能。

④设置 SLB 引流权重指完成发布后不再使用快照权重进行引流,而使用当前设置的权重。

同灰度引流一样,灰度引流是在发布完成之后对权重流量进行设置;使用 SLB 引流是在发布之前对流量权重进行修改。

发布的时候每台机器会具有执行日志,相应的操作均有任务执行日志。

对于执行日志相应的功能:

切除 SLB 流量:将要发布的 ecs 在挂载的 slb 下的权重调为零,在进行发布,切除的是外部web访问流量。

下载脚本:启动技术栈下载脚本,从金融云中枢的 oss上将技术栈软件与 sdk 下载到要发布的 ecs 服务器上并解压。

安装服务器脚本、配置服务器环境是对 ecs 进行适配,安装相应的 rpm 包,配置相应的环境参数;

下载应用包用户的代码包会上传到金融云中枢 oss,下载应用包则是从 oss 上将代码包下载下来;

部署服务是部署完成之后对服务进行一个健康检查,如果健康检查不通过,则会报错,这样可以判断应用是否出现问题;如果健康检查通过,则会恢复之前挂载的流量权重。

如果使用灰度引流在发布成功之后会有调整流量权重,点击调节流量权重,会弹出一个恢复SLB引流设置,则就可以设置相应的流量权重进行挑拨验证,再点击确定。确定之后会进行设置,可以先设置10,点击确定,再确定服务器运行状态。如果运行正常,再调整50来判断服务器运行状态,之后可以调整100,这就是灰度引流。

image.png

发布回滚是创建一个发布单并进行发布的时候,在发布过程中可能会出现报错即统计应用出现的问题或者现有的版本不太符合,则可以选择发布回滚。点击应用回滚会弹出一个回滚应用的界面,点击回滚版本可以选择相应的版本,回滚原因。

如果应用是第一次发布并且从来没有发布成功过则不能选择回滚,因此回滚的前提是必须发布成功过才能进行回滚,如果一次不能成功则不能进行回滚。

(2)功能组成—蓝绿发布

在发布部署控制台上,对于发布类型,在创建发布单的时候  蓝绿发布可以创建一个蓝绿发布单,蓝绿发布单服务列表里有一个待选应用服务列表和已选引流应用服务列表。

蓝绿发布支持以部署单元(Cel)为维度部署应用,能解决部署中的应用兼容性问题,实现双机房环境下的应用并行发布,提供更灵活的发布策略,对挂载SLB的应用进行引流验证。

可以理解为默认使用灰度引流的功能,在发布完成之后可以对流量权重进行相应的设置,此时会弹出相应的设置按钮。

蓝绿发布创建一个发布单时会存在一个已选发布应用服务列表:被选中的应用服务会参与发布及流量切换过程。已选引流应用服务列表是被选中的应用服务仅参与流量切换过程。

蓝绿发布单创建的前提:服务实例必须已经在两个机房部署,且每个机房都有发布完成状态的服务器。只有使用了SLB并且挂载了两个机房、状态为发布完成的服务器的应用才能被添加至引流应用中。

点击开始发布之后会存在组件迁移,即将消息中心、定时任务和分布式事务迁移到蓝机房。不是绿机房就不会有相应的流量,这时会进行相应的迁移,全部迁移到绿机房时应用提供相应的功能。

image.png

迁移完成之后会对绿机房进行发布,此时没有流量;发布成功之后进行引流,则会慢慢地把蓝机房的流量迁到绿机房。

image.png

组件切换迁移回滚:定时任务切换回绿机房,分布式事务和消息中心依然保留原机房进行消费。

全部引流到绿机房之后,将消息中心、定时任务和分布式事务迁移到绿机房。迁移到绿机房之后,蓝机房如果进行发布就会把蓝机房的流量切断,切断之后就开始发布蓝机房。

image.png

蓝机房发布成功之后则会慢慢回滚,最终回滚到蓝绿机房之前的状态,但是版本会是常见的版本。在发布的整个过程当中是可以进行回滚的。

(3)功能组成—应用运维

因为应用是部署在服务器上,如果想进行重启应用、上线应用、下线应用、初始化服务器,则可以在日常运维里的应用运维创建性赢得发布单进行相应的发布。

①应用重启

每个发布单均有一个发布流程图,应用重启首先切流,切流之后会执行记录栈脚本去重启相应的服务,重启之后检查服务是否正常运行,健康检查通过之后流量恢复

②应用上线

之前部署的应用想要重新统一,可以选择应用上线的发布单,跟普通发布的发布单是类似的。切除 SLB 流量,检查 staragent 是否正常。staragent 是运维管道的功能,在发布控制台上会有一个 staragent 进程,这个进程会接受从发布部署台上的请求,比如相应的重启、上线等,会执行机器上相应的脚本下发操作。再下载脚本、安装服务器软件、配置服务器环境等对应用进行部署上线。

③应用下线

通过 staragent 获取应用下的脚本,直接把 java 服务进程给 kill 掉;

④服务器初始化

存在一个应用A、应用B,但是应用A已经不再需要,这时要把部署在应用A上的依赖全部从服务器上移除,此时需要服务器初始化的功能。把应用A在这个服务器上的索引流量权重删除干净,然后再把服务器去部署应用B,这样可以避免一些不必要的冲突,可以对服务器进行一些初始化的操作。

⑤指令模板及服务器运维

在日常运维中创建一个指令模板,指令模板具有一个指令类型,一个是输入命令,一个是录入脚本。命令是执行相应的命令,脚本是服务上的脚本,点击确定即创建一个模板。创建一个指令模板之后,就可以创建一个服务器运维单;服务器运维单会有一个指令模板添加指令,这样就可以找到刚刚添加的指令模板。指令模板之下有个待选服务器列表,即选择相应的服务器。比如到A、B、C三个服务器执行一个SLC查看命令,此时可以把A、B、C三个服务器选中再创建一个指令模板,创建一个服务器运维单进行发布,发布成功之后就会到相应的机器上执行相应的命令,这样就可以适量的对服务器进行管理。

2.日常运维

常用日志内容包括日志路径和关键日志名。

日志路径包括应用日志和应用启动&健康检查日志,

应用日志: /home/admin/logs/appname/;

应用启动&健康检查日志: /home/admin/logs/sofa/。

关键日志名包括错误日志和健康检查日志,

错误日志: common-errorlog;

启动日志: sofa-starup.log;

健康检查日志: sofa-healthchecklog。

如果发布部署的过程中存在什么问题,可以去进行健康检查。

健康检查是在容器内执行 curl localhost:9500/checkServcie

返回结果第一行 passwd 为 true 代表服务正常。

Deps 的重启顺序如下:

Deps 的三个应用在启动时有依赖,如果出现异常需要重启,请按照以下顺序依次操作 :acopswareexecutor >acopswareorchestration >acopswareapiserver

3.常见问题

在发布部署的过程中可能会出现一些问题,现说明这些问题如何解决:

(1)发布单初始化失败:在创建发布单的时候会存在初始化的功能,初始化可以对机器进行筛选检查以此来检查及其是否是正常的、是否是同步的。某些情况下会存在初始化不能执行,存在报错的情况,原因可能是:

①技术栈版本和发布机器系统不一致导致初始化失败

image.png

例如技术栈的版本支持的操作系统是3-S7,但是实际上发布的操作系统是3-S6,会导致发布单发布失败。

②获取发布包失败

image.png

如果发布包是创建在 OSS 里,则可能是忘记上传或者是不小心在OSS里把发布包删除,就会导致发布包获取失败。

(2)切除/恢复 SLB 流量失

在应用发布详情里查看具体的报错信息,如果是 SLB 侧有问题,会

返回 request ID 以及对应的 code 和 message,根据错误在对应表进行排查: https://error-center,aliyun.com/status/product/Slb?spm=a2c4g.11186623.2.13.6f694fafJUfAU6

(3)下载脚本失败

①服务器的磁盘满导致下载失败,一般会提示No space left on device.

②服务实例使用的技术栈不存在,一般会报ERROR 404: Not Found exit 1。

③服务器上 Staragent 未运行,一般会报: Agent status not running。

这样就可以根据报错来判断相应的原因。

(4)检查服务失败

①服务启动失败或者启动时间太长,导致检查服务的脚本执行超时,一般会提示 python run time out,;

②应用本身存在问题会报错健康检查失败。

(5)Staragent 相关

PaaS 下发的所有执行命令,都是通过 Startagent 传到对应服务器上来执行,如果应用服务器上的 Startagent 未运行或者有异常会直接影响应用的发布和运维。一般遇到 Staragnet 问题,可以参考以下步骤进行排查和处理:

①检查应用服务器上 staragent的状态ps -ef | grep staragent

检查是否正常,如果不正常则一定是出现问题;

②检查应用服务器与 starserver 的长连接是否正常

netstat -anlp | grep 8000

③检查应用服务器上的 staragent 日志

tail -f /home/staragent/log/staragent core.log

④重启应用服务器上的 staragent 进程

/home/staragent/bin/agent.sh restart

相关实践学习
借助OSS搭建在线教育视频课程分享网站
本教程介绍如何基于云服务器ECS和对象存储OSS,搭建一个在线教育视频课程分享网站。
相关文章
|
3天前
|
消息中间件 运维 Kubernetes
构建高效自动化运维体系:Ansible与Kubernetes的融合实践
【5月更文挑战第9天】随着云计算和微服务架构的普及,自动化运维成为确保系统可靠性和效率的关键。本文将深入探讨如何通过Ansible和Kubernetes的集成,构建一个强大的自动化运维体系。我们将分析Ansible的配置管理功能以及Kubernetes容器编排的优势,并展示如何将二者结合,以实现持续部署、快速扩展和高效管理现代云原生应用。文章还将涵盖实际案例,帮助读者理解在真实环境下如何利用这些工具优化运维流程。
|
13天前
|
运维 监控 安全
构建高效自动化运维系统:策略与实践
【4月更文挑战第29天】 在信息技术日新月异的今天,高效的运维管理已成为企业保持竞争力的关键因素。本文将探讨如何构建一个能够适应快速变化需求的自动化运维系统。通过深入分析自动化工具的选择、配置管理的最佳实践以及持续集成和部署的策略,我们旨在为读者提供一个清晰的框架来优化他们的运维流程。文章的核心在于提出一种结合了最新技术和思维模式的综合解决方案,以实现运维工作的最优化。
|
4天前
|
运维 Kubernetes 监控
构建高效自动化运维体系:基于Ansible的策略与实践
【5月更文挑战第8天】 在当今IT基础设施管理领域,自动化不再是一个选择,而是必要的步骤。随着复杂性的增加和变更的频繁性,自动化工具如Ansible提供了一种高效、可靠的解决方案来简化配置管理和多节点部署。本文将探讨如何利用Ansible构建一个高效的自动化运维体系,涵盖其核心原理、策略设计以及在实际环境中的应用。我们将分析Ansible与其他自动化工具的不同之处,并提供一些最佳实践,以帮助运维专家提升他们的工作效率和系统稳定性。
|
6天前
|
运维 Kubernetes Devops
构建高效自动化运维体系:DevOps与容器化技术融合实践
【5月更文挑战第6天】随着企业IT架构的复杂化以及快速迭代的市场需求,传统的运维模式已难以满足高效率和高质量的交付标准。本文将探讨如何通过结合DevOps理念和容器化技术来构建一个高效的自动化运维体系,旨在实现持续集成、持续部署和自动化管理,提升系统的可靠性、可维护性和敏捷性。
|
6天前
|
存储 机器学习/深度学习 运维
提升数据中心能效:现代运维策略与实践
【5月更文挑战第6天】 在数字化时代,数据中心作为信息处理的核心设施,其能源消耗和环境影响成为业界关注的焦点。本文将探讨如何通过现代运维策略和技术手段提升数据中心的能效,同时保证系统的可靠性和服务的连续性。文章将详细分析数据中心能耗的主要来源,介绍先进的能效优化措施,并通过案例分析展示这些措施的实际效果,为数据中心管理者提供实用的能效改进建议。
|
12天前
|
敏捷开发 运维 测试技术
构建高效自动化运维体系:基于容器技术的持续集成与持续部署实践
【4月更文挑战第30天】在数字化转型的浪潮中,企业对软件交付速度和质量的要求日益提高。自动化运维作为提升效率、确保稳定性的关键手段,其重要性不言而喻。本文将探讨如何利用容器技术构建一个高效的自动化运维体系,实现从代码提交到产品上线的持续集成(CI)与持续部署(CD)。通过分析现代容器技术与传统虚拟化的差异,阐述容器化带来的轻量化、快速部署及易于管理的优势,并结合实例讲解如何在实际环境中搭建起一套完善的CI/CD流程。
|
12天前
|
运维 Kubernetes 持续交付
构建高效自动化运维系统:基于容器技术的持续集成与持续部署实践
【4月更文挑战第30天】 在快速发展的云计算时代,传统的运维模式已无法满足敏捷开发和快速迭代的需求。本文将介绍如何利用容器技术搭建一套高效自动化运维系统,实现软件的持续集成(CI)与持续部署(CD)。文章首先探讨了现代运维面临的挑战,接着详细阐述了容器技术的核心组件和工作原理,最后通过实际案例展示了如何整合这些组件来构建一个可靠、可扩展的自动化运维平台。
|
12天前
|
机器学习/深度学习 运维 监控
构建高效自动化运维体系:从理论到实践
【4月更文挑战第30天】 在信息技术日益发展的今天,自动化运维已经成为提高系统稳定性、优化资源配置和降低人力成本的关键。本文旨在探讨如何构建一个高效的自动化运维体系,涵盖从初步规划到具体实施的全过程。文章首先分析了自动化运维的必要性,接着提出一套完整的构建方案,并详细阐述了关键技术与工具的选择和应用。通过案例分析,验证了所提方案的有效性,并对自动化运维的未来趋势进行了展望。
|
12天前
|
运维 监控 安全
构建高效自动化运维系统:策略与实践
【4月更文挑战第30天】 在现代IT基础设施管理中,自动化运维不再是可选项而是必需品。随着复杂性的增加和变更的频繁性,自动化可以提高效率、减少错误并释放人员专注于更有价值的任务。本文将探讨构建一个高效的自动化运维系统的关键环节,包括工具选择、流程设计以及监控和优化策略。通过案例分析和最佳实践分享,读者可以获得实施自动化运维的实用指导和启发。
|
12天前
|
人工智能 运维 监控
构建高效自动化运维体系:DevOps与AI的融合实践
【4月更文挑战第30天】 在当今快速迭代的软件开发环境中,高效的自动化运维体系成为确保交付速度和服务质量的关键。本文探讨了如何通过整合DevOps理念和人工智能(AI)技术来构建一个更加智能、高效的运维体系。文章将详细阐述自动化运维的核心组件,以及如何利用AI技术优化这些组件的性能和决策过程。通过实际案例分析,本文展示了这种融合实践在提高运维效率、降低错误率以及提升系统稳定性方面的显著成效。