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

本文涉及的产品
对象存储 OSS,20GB 3个月
应用型负载均衡 ALB,每月750个小时 15LCU
对象存储 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,搭建一个在线教育视频课程分享网站。
相关文章
|
12天前
|
运维 监控
构建高效运维体系:从理论到实践
在当今快速发展的信息化时代,高效的运维体系是保障企业信息系统稳定运行的关键。本文旨在探讨如何构建一个高效、可靠的运维体系,通过分析当前运维面临的挑战,提出相应的解决策略,并结合实际案例,展示这些策略的实施效果。文章首先介绍了高效运维的重要性,接着分析了运维过程中常见的问题,然后详细阐述了构建高效运维体系的策略和步骤,最后通过一个实际案例来验证这些策略的有效性。
|
12天前
|
机器学习/深度学习 数据采集 人工智能
智能运维:从自动化到AIOps的演进与实践####
本文探讨了智能运维(AIOps)的兴起背景、核心组件及其在现代IT运维中的应用。通过对比传统运维模式,阐述了AIOps如何利用机器学习、大数据分析等技术,实现故障预测、根因分析、自动化修复等功能,从而提升系统稳定性和运维效率。文章还深入分析了实施AIOps面临的挑战与解决方案,并展望了其未来发展趋势。 ####
|
20天前
|
人工智能 运维 监控
构建高效运维体系:理论与实践的深度融合####
本文旨在探讨高效IT运维体系的构建策略,通过理论框架与实际案例并重的方式,深入剖析了现代企业面临的运维挑战。文章开篇概述了当前运维领域的新趋势,包括自动化、智能化及DevOps文化的兴起,随后详细阐述了如何将这些先进理念融入日常运维管理中,形成一套既灵活又稳定的运维机制。特别地,文中强调了数据驱动决策的重要性,以及在快速迭代的技术环境中保持持续学习与适应的必要性。最终,通过对比分析几个典型企业的运维转型实例,提炼出可复制的成功模式,为读者提供具有实操性的指导建议。 ####
|
22天前
|
机器学习/深度学习 人工智能 运维
智能运维:AIOps在大型系统运维中的实践与挑战
【10月更文挑战第28天】随着云计算、大数据和人工智能的发展,AIOps(人工智能运维)应运而生,旨在通过算法和机器学习提高运维效率和质量。本文探讨了AIOps在大型系统运维中的实践与挑战,包括数据质量、模型选择和团队协作等方面,并通过一个异常检测案例展示了其应用。尽管面临挑战,AIOps仍有望成为未来运维的重要方向。
52 5
|
19天前
|
运维 负载均衡 Ubuntu
自动化运维的利器:Ansible入门与实践
【10月更文挑战第31天】在当今快速发展的信息技术时代,高效的运维管理成为企业稳定运行的关键。本文将引导读者了解自动化运维工具Ansible的基础概念、安装步骤、基本使用,以及如何通过实际案例掌握其核心功能,从而提升工作效率和系统稳定性。
|
20天前
|
运维 资源调度 监控
提升运维效率的关键技术与实践
在当今快速发展的信息技术时代,运维工作面临着前所未有的挑战和机遇。本文旨在探讨如何通过采用先进的技术和实施最佳实践来提高IT运维的效率和效果。我们将深入分析自动化工具、监控策略、灾难恢复计划以及持续集成/持续部署(CI/CD)等关键领域,展示它们如何协同工作以优化运维流程。此外,文章还将提供一些实际案例研究,帮助读者更好地理解这些概念的应用。无论是对于初创公司还是大型企业,掌握这些技术都将是提升竞争力的关键。
|
29天前
|
运维 应用服务中间件 持续交付
自动化运维的利器:Ansible入门与实践
【10月更文挑战第21天】在现代IT基础设施的管理中,自动化运维已成为提升效率、降低错误率的关键。Ansible,作为一种简单而强大的自动化工具,正被广泛应用于配置管理、应用部署和任务自动化等领域。本文将引导你了解Ansible的基本概念,通过实际案例展示如何利用Ansible简化日常运维工作,并探讨其在现代IT运维中的应用价值。无论你是新手还是有经验的系统管理员,这篇文章都将为你开启Ansible的高效之旅提供指导。
|
1月前
|
运维 自然语言处理 开发者
作为一名运维人员,使用通义灵码个人版处理日常工作中的代码相关任务,极大地提升了我的工作效率。以下是我使用通义灵码的具体实践场景、效果和心得,以及相应的截图。
作为一名运维人员,我使用通义灵码处理日常工作中的代码任务,效率提升了30%。通义灵码帮助我快速理解复杂代码、生成准确的代码注释,并能从自然语言生成代码示例,大幅减少了代码编写和理解的时间。
57 3
|
1月前
|
运维 Prometheus 监控
运维之眼:监控的艺术与实践
在信息技术飞速发展的今天,运维监控已成为保障系统稳定运行的关键。本文将探讨运维监控的重要性,介绍常用的监控工具和方法,并通过实际案例分析,展示如何有效地实施监控策略,以确保系统的高可用性和性能。
|
1月前
|
运维 监控 jenkins
运维自动化实践:利用Jenkins实现高效CI/CD流程
【10月更文挑战第18天】运维自动化实践:利用Jenkins实现高效CI/CD流程
下一篇
无影云桌面