Serverless 时代下微服务应用全托管解决方案

作者：陈昕

Serverless 时代下微服务发展与挑战

早期业务规模比较简单，大多团队开发采用单体应用，已经能够很好地满足团队的业务需求，并且能够快速迭代。但随着业务规模的不断增长，系统变得越来越复杂，单体应用逐渐无法满足线上生产的问题。比如电商业务中，如果将交易、支付，商品等所有功能都集中在单体应用中开发，有可能会出现发布简单商品功能影响到交易，从而对整个电商系统产生影响，给企业造成损失。

这个时候很多团队会把单体应用架构改为微服务的架构，解决单体应用的问题。但随着业务进一步发展，系统愈加复杂，加之新技术的到来，比如云原生时代下成了标准的 K8s 以及 容器镜像 Docker 等，研发运维投入会越来越大，需要保证几十甚至几百个服务正常运行与协作，这给运维带来了很大的挑战:

1、效率：随着应用规模的扩张，新的研发团队需要面临很多开发和测试中的复杂性问题。在团队协作上，不同应用团队之间如何更好地形成稳定的调用链路，在几十，几百甚至上千个应用的大规模场景里如何进行调用链路上应用的快速部署和灰度。此外，如此多应用的流量的处理、调用链路的跟踪和服务鉴权也非常影响效率。

2、稳定：微服务化之后，会出现调用链路上某核心应用出现问题，导致整体系统发生雪崩，而且有时缺少可视化、可观测性的系统来帮助快速定位分析问题，导致难以快速定位到出现问题的应用，造成长时间的损失；

3、成本：单体应用一般只需部署几台机器；到了微服务时代，随着应用数的剧增，出于可用性的考虑需要为每个应用保持一些冗余，比如一次大促中，一个调用链路会涉及到十几个应用，为了稳定性以及调用链路的安全，会进行整个链路应用的扩容，而实际上很多应用可能长时间没有流量，服务器空闲，导致巨大的成本浪费。 

面对微服务带来的这些问题和需求， Serverless 应用引擎在这方面都做了哪些工作? 带来哪些改变？

SAE 微服务应用全托管解决方案介绍

SAE 是面向微服务应用的 Serverless PaaS 平台。作为云平台，它能够为微服务应用进行全生命周期的托管。它能将 Serverless 和 K8s 本身的红利集中在一起，让微服务应用快速上线。以产品化的形式快速提供给用户，开箱即用，解决用户常见的微服务问题，提升研发效率。

SAE 提供了包含但不限于 CI/CD 流水线、微服务框架、 Spring Cloud、 Dubbo 、共享注册中心、K8s 容器以及诸多运维相关的功能，包含调用链、日志、告警、性能监控、流量的治理以及自动弹性等。它是 Serverless 框架与微服务进行深度结合的最佳实践的平台。

SAE 微服务功能和实践

底层能力：微服务功能增强

在 Serverless 时代下，微服务的趋势是客户端越来越薄，其中与服务治理、业务逻辑无关的部分被沉淀在 Java agent 等组件里，通过字节码的方式注入到业务中，对业务开发无侵入、无感知，并在过程中提供了丰富的微服务治理能力。比如流量管理相关的无损上下线、金丝雀发布、可视化数据上报等能力。

针对非 Java 场景，Java agent 也能够与不同的微服务框架进行通信。此外，与 Sidecar 之间的通信也正在不断完善建设中。

开发态实践：端云联调

Serverless 应用引擎（SAE）基于 Alibaba CloudToolkit 插件+ 跳板机可以实现：

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

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

发布态实践：无损下线

在版本更换的过程中，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 的实例上。 

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

运行态实践：可观测

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

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

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

客户案例

总结

本文介绍了 Serverless 时代下微服务的发展以及过程中遇到的相对较复杂的需求，面对这些，阿里云 Serverless 应用引擎 SAE 将“Serverless”的理念发扬到了极致，从最底层的 IaaS、到上层的 K8s、应用 PaaS、CICD、微服务套件集成、可观测增强等等都做了“Serverless”化的托管，实现了 SAE 针对微服务场景的完整的解决方案。 

未来，SAE 会在微服务场景下做持续的能力增强，做出端到端的解决方案，降低开发者在面对微服务技术的时候的门槛，比如故障注入、全链路压测，多语言微服务为等等；在 Serverless 场景下，其实是将复杂度由用户交给了平台，所以怎么运维好这么多应用也是我们的核心能力，我们会持续投入，不断完善。