如何经过 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 是如何保证旧版本的微服务流量能够无损地下线掉？

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

B一、B2 把本身注册到注册中心，消费者从注册中心刷新服务列表，发现服务提供者 B一、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、应用托管领域，基于云原生技术持续打造新一代应用托管平台。

本文整理自【Serverless Live 系列直播】2 月 1 日场 直播回看连接：https://developer.aliyun.com/topic/serverless/practices

Serverless 电子书下载

本书亮点：

• 从架构演进开始，介绍 Serverless 架构及技术选型构建 Serverless 思惟；
• 了解业界流行的 Serverless 架构运行原理；
• 掌握 10 大 Serverless 真实落地案例，活学活用。

下载连接：https://developer.aliyun.com/topic/download?id=1128