如何通过 Serverless 提高 Java 微服务治理效率?

简介: 在业务初期,因人手有限,想要快速开发并上线产品,很多团队使用单体的架构来开发。但是随着公司的发展,会不断往系统里面添加新的业务功能,系统越来越庞大,需求不断增加,越来越多的人也会加入到开发团队,代码库也会增速的膨胀,慢慢的单体应用变得越来越臃肿,可维护性和灵活性逐渐降低,维护成本越来越高。

 

微服务治理面临的挑战

在业务初期,因人手有限,想要快速开发并上线产品,很多团队使用单体的架构来开发。但是随着公司的发展,会不断往系统里面添加新的业务功能,系统越来越庞大,需求不断增加,越来越多的人也会加入到开发团队,代码库也会增速的膨胀,慢慢的单体应用变得越来越臃肿,可维护性和灵活性逐渐降低,维护成本越来越高。

 

这个时候很多团队会把单体应用架构改为微服务的架构,解决单体应用的问题。但随着微服务越来越多,运维投入会越来越大,需要保证几十甚至几百个服务正常运行与协作,这给运维带来了很大的挑战,下面从软件生命周期的角度来分析这些挑战:

  • 开发测试态如何实现开发、测试、线上环境隔离?如何快速调试本地变更?如何快速部署本地变更?
  • 发布态如何设计服务发布策略?如何无损下线旧版本服务?如何实现对新版本服务灰 度测试?
  • 运行态线上问题如何排查?有什么工具可以利用呢?对于服务质量差的节点如何处理?对于完全不工作的实例我们如何恢复?

面对以上问题,Serverless 应用引擎在这方面都做了哪些工作?

Serverless 应用引擎

 

如上图所示,Serverless 应用引擎(SAE)基于神龙 + ECI + VPC + SLB + NAS 等 IaaS 资源,构建了一个 Kubernetes 集群,在此之上提供了应用管理和微服务治理的一些能力。它可以针对不同应用类型进行托管,比如 Spring Cloud 应用、Dubbo 应用、HSF 应用、Web 应用和多语言应用。并且支持 Cloudtoolkit 插件、云效 RDC / Jenkins 等开发者工具。在 Serverless 应用引擎上,零代码改造就可以把 Java 微服务的应用迁移到 Serverless。

总的来说,Serverless 应用引擎能够提供成本更优、效率更高的一站式应用托管方案,零门槛、零改造、零容器基础,即可享受 Serverless + K8s + 微服务带来的技术红利。

微服务治理实践

1. 开发态实践

1)多环境管理

 

  • 多租户共有一个注册中心,通过不同的租户对流量进行隔离;更进一步可以通过网络 VPC 进行环境隔离;
  • 提供环境级别的运维操作,比如一键停止和拉起整个环境的功能;
  • 提供环境级别的配置管理;
  • 提供环境级别的网关路由流量管理。

2)云端联调

Serverless 应用引擎(SAE)基于 Alibaba CloudToolkit 插件+ 跳板机可以实现:

  • 本地服务订阅并注册到云端 SAE 内置的注册中心;
  • 本地服务可以和云端 SAE 服务互相调用。

 

如上图所示,在实现的时候用户需要有一个 ECS 代理服务器,实际注册的是 ECS 代理服务器到 SAE 的注册中心,IDEA 在安装 Cloudtoolkit 插件以后,在启动进程时,会在本地拉起一个通道服务,这个通道服务会连上 ECS 代理服务器,本地所有的请求都会转到 ECS 代理服务器上,云端对服务的调用也会通过 ECS 代理转到本地,这样就可以以最新的代码在本地断点调试,这就是云端联调的实现。

3)构建快速开发体系

 

代码在本地完成联调以后,要能快速地通过 Maven 插件和 IDEA-plugin,可以很快地一键部署到云端的开发环境。

2. 发布态实践

1)应用发布三板斧

 

 

  • 可灰度:应用在发布的过程中,运维平台一定要有发布策略,包括单批、分批、金丝雀等发布策略;同时还要支持流量的灰度;批次间也要允许自动/手动任选。
  • 可观测:发布过程可监控,白屏化实时查看发布的日志和结果,及时定位问题。
  • 可回滚:允许人工介入控制发布流程:异常中止、一键回滚。

通过这三点可以让应用发布做到可灰度、可观测、可回滚。

2)微服务无损下线

在版本更换的过程中,SAE 是如何保证旧版本的微服务流量可以无损地下线掉?

 

上图是微服务注册和发行的整个流程,图中有服务消费者和服务提供者,服务提供者分别有 B1、B2 两台实例,服务消费者分别有 A1、A2 两台实例。

B1、B2 把自己注册到注册中心,消费者从注册中心刷新服务列表,发现服务提供者 B1、B2,正常情况下,消费者开始调用 B1 或者 B2,服务提供者 B 需要发布新版本,先对其中一个节点进行操作,如 B1,首先停止 Java 进程,服务停止过程又分为主动销毁和被动销毁,主动销毁是准实时的,被动销毁的时间由不同的注册中心决定,最差的情况可能需要一分钟。

如果应用是正常停止,Spring Cloud 和 Dubbo 框架的 ShutdownHook 能正常被执行,这一步的耗时基本上是可以忽略不计的。如果应用是非正常停止,比如说直接 Kill-9 的一个停止,或者是 Docker 镜像构建的时候,Java 进程不是一号进程,且没有把 Kill 信号传递给应用的话,那么服务提供者不会主动去注销节点,它会等待注册中心去发现、被动地去感知服务下线的过程。

当微服务注册中心感知到服务下线以后,会通知服务消费者其中一个服务节点已下线,这里有两种方式:注册中心的推送和消费者的轮巡。注册中心刷新服务列表,感知到提供者已经下线一个节点,这一步对于 Dubbo 框架来说不存在,但对于 Spring Cloud 来说,它最差的刷新时间是 30 秒。等消费者的服务列表更新以后,就不再调用下线节点 B。从第 2 步到第 6 步的过程中,注册中心如果是 Eureka,最差的情况需要消耗两分钟;如果是 Nacos,最差的情况需要消耗 50 秒。

在这个时间内请求都有可能出现问题,所以发布的时候会出现各种报错。

 

经过上面的分析,在传统的发布流程中,客户端有一个服务端调用报错期,这是由于客户端没有及时感知到服务端下线的实例造成的,这种情况主要是因为服务提供者借助微服务,通知消费者来更新服务提供的列表造成的。

 

那能否绕过注册中心,服务提供者直接通知服务消费者?答案是肯定的。SAE 做了两件事情,第一,服务提供者在应用发布前,会主动向服务注册中心注销应用,并将应用标记为已下线状态,将原来停止进程阶段的注销变成了 preStop 阶段注销进程。

在接收到服务消费者的请求时,首先会正常处理本次请求,并且通知服务消费者此节点已经下线,在此之后消费者收到通知后,会立即刷新自己的服务列表,在此之后服务消费者就不会再把请求发到服务提供者 B1 的实例上。

通过上面这个方案,就使得下线感知时间大大缩短,从原来的分钟级别做到准实时的,确保你的应用在下线时能够做到业务无损。

3)基于标签的灰度发布

 

发布策略分为分批发布和灰度发布,如何实现流量的灰度?从上面的架构图中可以看到,在应用发布之前,要配置一个灰度规则,比如按 uid 的取模余值 =20 来作为灰度流量的规则,当应用发布的时候,会对已发布的节点标识为一个灰度的版本,在这样的情况下,当有流量进来时,微服务网关和消费者都会通过配置中心拿到在治理中心配置的灰度规则。

消费者的 Agent 也会从注册中心拉取它所依赖的服务的一些信息,当一个流量进到消费者时,会按照灰度规则来做匹配,如果是灰度的流量,它会转化到灰度的机器上;如果是正常流量,它会转到正常的机器上,这是基于标签实现的灰度发布的具体逻辑。

3. 运行态实践

1)强大的应用监控 & 诊断能力

 

运行态的实例,服务的运行过程中会出现这样或者那样的问题,怎么去排查和解决它?

排查和解决的前提是必须具有强大的应用监控能力和诊断能力,SAE 集成了云产品 ARMS,能够让跑在上面的 Java 微服务看到应用的调用关系拓扑图,可以定位到你的 MySQL 慢服务方法的调用堆栈,进而定位到代码级别的问题。

比如一个请求响应慢,业务出现问题,它可以定位到是哪个请求、哪个服务、服务的哪行代码出现了问题,这样就能为解决问题带来很多便利。总的来说,就是我们要先有监控报警的能力,才能帮助我们更好地诊断服务运营过程中的问题。

2)故障隔离和服务恢复

上面说到我们通过监控、报警来排查、解决遇到的问题,那我们的系统能否主动去做一些事情呢?SAE 作为一个 Serverless 平台,具备很多自运维的能力,下图中有两个场景:

 

  • 场景 1:某应用运营过程中,某几台机器由于磁盘满或者宿主机资源争抢,导致 load 很高或网络状态差,客户端出现调用超时或者报错。

面对这种情况,SAE 提供了服务治理能力,即离群摘除,它可以配置,当网络超时严重或者后端服务 5xx 报错达到一定比例时,可以选择把该节点从消费端服务列表中摘除,从而使得有问题的机器不再响应业务的请求,很好地保证业务的 SLA。

  • 场景 2:某应用运行过程中,因突发流量导致内存耗尽,触发 OOM。

这种情况下,通过 SAE 这种 Serverless 应用引擎,节点在配置健康检查以后,节点里的容器是可以重新拉起的,可以做到快速对进程进行恢复。

3)精准容量+限流降级+极致弹性

 

基于 Serverless Paas 平台 SAE 和其他产品的互动,来达到整个运维态的闭环。

用户在使用的时候,可以运用 PTS 压测工具构造场景,然后得出来一些阈值。比如可以对流量高峰所需要消耗的资源进行预估,这时就可以根据这些阈值设计弹性策略。当业务系统达到请求比例时,就可以按照所设置的弹性策略来扩缩容自己的机器。

扩缩容在时间上,有可能还跟不上处理大批量的请求,这时可以通过和 AHAS 的互动,配置限流降级的能力。当有突发大流量时,首先可以用 AHAS 的能力把一些流量挡在门外,然后同时触发 SAE 上应用的扩容策略去扩容实例,当这些实例扩容完成之后,整个机器的平均负载会下降,流量又重新放进来。从突发大流量到限流降级再到扩容,最后到流量达到正常状态,这就是“精准容量+限流降级+极致弹性”的最佳实践模型。

总结

本文首先按照提出问题、解决问题的思路,阐述微服务在开发、发布和运行态是如何解决问题的;再介绍如何通过 Serverless 产品和其他产品的互动,从而实现精准流量、限流降级和极致弹性。

  • 开发测试态通过注册中心多租户和网络环境的隔离,并提供环境级别的能力;通过云端联调技术来快速调式本地变更;如果 IDE 插件快速部署本地变更。
  • 发布态运维平台针对应用发布需要具备可灰度、可观测、 可回滚;通过 MSE agent 能力实现服务无损下线;通过标签路由提供了线上流量灰度测试的能力。
  • 运行态建立强大应用监控和诊断能力;对服务质量差的节点具备离群摘除能力;对已经不工作的实例通过配置健康检查能够做到实例重启恢复业务;提供了精准容量+限流降级+极致弹性模型。

作者简介

王科怀,花名:行松,阿里云 SAE 技术研发,负责 SAE 产品 Runtime 层技术架构设计,专注于微服务、Serverless、应用托管领域,基于云原生技术持续打造新一代应用托管平台。

原文链接

本文为阿里云原创内容,未经允许不得转载

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/514117.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

每次都需要解释大量指令?使用 PolarDB-X 向量化引擎

简介: 向量化引擎为PolarDB-X的表达式计算带来了显著的性能提升。 介绍 PolarDB-X是阿里巴巴自研的云原生分布式数据库,采用了计算-存储分离的架构,其中计算节点承担着大量的表达式计算任务。这些表达式计算涉及到SQL执行的各个环节&#xff…

稳定性保障6步走:高可用系统大促作战指南!

简介: 年年有大促,大家对于大促稳定性保障这个词都不陌生,业务场景尽管各不相同,“套路”往往殊路同归,全链路压测、容量评估、限流、紧急预案等,来来去去总少不了那么几板斧。跳出这些“套路”&#xff0c…

观测云品牌正式亮相,携手通信院共推国内可观测性概念与技术发展!

2021年9月17日,由中国信息通信研究院、中国通信标准化协会联合主办的“2021 OSCAR 开源产业大会”在北京中关村拉开序幕。会上正式发布了《开源治理标准与评估结果》《开源法则》等多项重要成果,而由通信院主导、驻云科技参与制定的《中国可观测性标准》…

闲鱼如何建设技术舆情治理体系 (多图多代码)

简介: 从日志、监控、性能检测几个方面建设了有日志可查、有数据可依的排查体系 现状和问题 闲鱼的舆情治理,依托阿里集团的设施建设,有以下能力: 崩溃异常、性能在线聚合查询;本地日志:TLog;在…

全球企业KVM开源贡献榜发布,腾讯云、华为、阿里巴巴等入围

9月16日晚,在全球虚拟化顶级技术峰会 KVM Forum 上,2021年度全球企业 KVM 开源贡献榜正式发布,华为、腾讯云、阿里巴巴等中国公司纷纷入围。其中,腾讯云更是连续第五年入围,成为唯一取得这一成就的中国企业。 据了解&a…

使用MQTT与函数计算做热力图的实践

简介: 在各类场景中,关于上报数据的处理无处不在,而以上提到的场景都可以通过本方案的MQTTFCAPI Gateway的方式参考优化来实现。 前言 最近几年,我们在一些商场、图书馆、机场或港口环境里,经常可以看到一些机器人在转…

Google 宣布推出隐私计算核心服务;Amazon Managed Grafana正式可用……

NEWS本周新闻回顾Google 宣布推出隐私计算核心服务今年 5 月 Google I/O 开发者大会发布 Android 12 的同时,宣布了隐私计算核心(Private Compute Core)。这是一项开源计划,提供了一个沙盒式的安全环境,将智能回复、实…

谈身份管理之基础篇 - 保障云上安全,从[规范账号使用]开始

简介: 身份和密钥的管理,是企业上云的重中之重;每年国内外都有因为身份和密钥的管理不善,或泄露,或误操作导致严重的生产事故或者数据泄露。本期小编将重点聊聊云上身份的那些值得关注的事儿。 引言 2021年初&#xf…

开课啦 dubbo-go 微服务升级实战

简介: 杭州开课啦教育科技有限公司是一家致力于为中小学生提供学习辅导的在线教育公司,目前公司后端服务基础设施主要依托于阿里云原生,其中包含计算、网络、存储以及 Kubernetes 服务。 技术选型背景 2020 年是开课啦公司发展壮大的一年&am…

gui界面设计心得体会 python_Python笔记-GUI界面设计(tkinter)

文章目录前言相关介绍一、函数方法介绍二、导入tkinter库三、窗口[1]. 创建[2]. 设置标题[3]. 设置大小[4]. 设置背景色[5]. 删除窗口四、按钮[1]. 创建[2]. 放置按钮(绝对位置)[3]. 放置按钮(相对位置)[4]. 代码五、单行文本[1]. 创建[2]. 代码前言此篇文章介绍的是有关图形用…

阿里云科技驱动“数字化转型”,助力中小企业发展“突围”

2020年至2021年的新冠疫情, 让全世界进入了困难模式,国家的经济运行不得不放缓脚步。这不仅给每个人造成了很多不便,更是给人们所依赖的企业组织,造成了巨大的影响。每一个微观个体所感受的只是自己身边肉眼可见的影响&#xff0c…

这些中秋礼盒绝了,悄悄惊艳互联网人

整理 | 王晓曼出品 | 程序人生 (ID:coder _life)来了来了它们来了,2021年腾讯、阿里、百度、字节等诸多互联网大厂带着他们的中秋礼盒来了!“八月十五月儿圆,中秋月饼香又甜”,没有月饼的中秋节…

想成为全栈工程师,要做到哪几点?

简介: 如何成为一名全栈工程师?需要具备哪些技术积累?成为全栈工程师有哪些好处?希望本文能为期望成为全栈工程师的同学提供一点帮助,和同学们一起分享交流。 作为开发者,我们不过度区分服务端 server 客户…

DDD as Code:如何用代码诠释领域驱动设计?

简介: 相较于常规的MVC架构,DDD更抽象、更难以理解,各个开发者对DDD的解释也不尽相同。那么哪种设计方式才更好?在学习时如何知道哪种DDD更正统,没有被别人带歪?本文尝试使用“DDD as Code”的概念&#xf…

谈身份管理之进阶篇 - 快速了解从管理到治理的最佳方案

简介: 云上身份安全是当今企业管理者和云上运维团队所面临的挑战之一,针对云上身份管理不全面所产生的风险究竟又哪些?又应当如何应对?本文将结合案例和最佳实践与您分享。 引言 云上身份安全是当今企业管理者和云上运维团队所面…

报名倒计时 | TeaTalk 深圳站邀您共话安全云世界

对越发复杂的网络环境,保障网络安全势不可挡,为此国家也对应颁布了系列规章政策。除相关政策外,网络安全及云安全也同时被列入国家规划重点发展方向,随着“十三五”规划逐渐落实,“十四五”规划制定实施,推…

KubeNode:阿里巴巴云原生 容器基础设施运维实践

简介: 目前 KubeNode 已经覆盖了阿里巴巴集团的所有的 ASI 集群,接下来,将随着阿里巴巴集团“统一资源池”的项目,推进 KubeNode 覆盖更大的范围、更多的场景,让云原生的容器基础设施运维架构发挥更大的价值。 阿里巴巴…

扫盲贴|如何评价一款App的稳定性和质量?

简介: 我们不应该为了掩盖代码质量问题,通过手动try catch去规避某些问题,这样有可能会打断用户的正常使用,并造成感知性的阻断反馈,应该从用户使用APP时的真实感知出发,当出现问题时及时捕获和处理问题。 …

聊聊 5G 云专线

作者|小枣君来源|鲜枣课堂通过本文,和大家分享探讨一下 5G 云专线。我们从今天文章的标题开始说起吧。5G、云、专线,分开的3个词,作为通信人,大家应该都懂(专线可能陌生一点)。但是,合起来之后&…

谈AK管理之基础篇 - 如何进行访问密钥的全生命周期管理?

简介: 我们也常有听说例如AK被外部攻击者恶意获取,或者员工无心从github泄露的案例,最终导致安全事故或生产事故的发生。AK的应用场景极为广泛,因此做好AK的管理和治理就尤为重要了。本文将通过两种AK使用不安全的典型案例&#x…