本文转载自微信公众号《Serverless》，作者王克怀（邢松）。转载本文请联系Serverless公众号。微服务治理面临的挑战在业务初期，由于人力有限，又想快速开发和上线产品，很多团队采用单一架构进行开发。但是随着公司的发展，系统会不断增加新的业务功能，系统会越来越大，需求也会不断增加。越来越多的人会加入开发团队，代码库也会以更快的速度膨胀。慢慢地，单体应用越来越臃肿，可维护性和灵活性逐渐降低，维护成本越来越高。这时候很多团队会把单体应用架构改成微服务架构来解决单体应用的问题。但是随着微服务越来越多，运维的投入也会越来越大。需要保证几十个甚至上百个服务的正常运行和协作，这给运维带来了很大的挑战。下面从软件生命周期的角度，从开发和测试的角度来分析这些挑战：如何在开发和测试状态下隔离开发、测试和在线环境？如何快速调试本地变化？如何快速部署本地变更？如何设计发布状态下的服务发布策略？实现新版本服务的灰度测试？如何排查运行状态在线问题？可以使用什么工具？如何处理服务质量差的节点？引擎在这方面做了什么？Serverless应用引擎如上图所示。Serverless应用引擎（SAE）基于神龙+ECI+VPC+SLB+NAS等IaaS资源构建Kubernetes集群，提供应用管理和微服务治理的一些能力。可针对不同的应用类型进行托管，如SpringCloud应用、Dubbo应用、HSF应用、Web应用、多语言应用等。还支持Cloudtoolkit插件、云效RDC/Jenkins等开发者工具。在serverless应用引擎上，Java微服务应用零代码修改即可迁移到serverless。总的来说，Serverless应用引擎可以提供成本更低、效率更高的一站式应用托管解决方案。零门槛、零修改、零容器基础，即可享受Serverless+K8s+微服务带来的技术红利。微服务治理实践1.开发状态实践1）多环境管理，多租户共享一个注册中心，通过不同租户隔离流量；进一步，可以通过网络VPC进行环境隔离；提供环境级别的运维操作，比如一键停止和拉起整个环境的功能；提供环境级配置管理；提供环境级网关路由流量管理。2）基于AlibabaCloudToolkit插件+跳板机的云联调Serverless应用引擎（SAE）可以实现：本地服务订阅注册到云SAE内置的注册中心；本地服务和云端SAE服务可以互相调用。如上图所示，用户在实现时需要有一个ECS代理服务器。实际注册是从ECS代理服务器到SAE注册中心。安装Cloudtoolkit插件后，IDEA在启动进程的时候会在本地拉起一个通道服务，这个通道服务会连接到ECS代理服务器，所有本地请求都会转发到ECS代理服务器，云端的调用到服务也会通过ECS代理转发到本地，这样就可以在本地用最新的代码调试，这就是云端联调的实现。3）搭建快速开发系统代码在本地联合调试后，必须能够通过Maven插件和IDEA-plugin一键快速部署到云端开发环境。2、发布状态实践1）应用发布可以通过三种方式进行：在应用发布过程中，运维平台必须有发布策略，包括单批、逐批、金丝雀发布策略；同时，必须支持流量灰度；批次之间也允许自动/手动选择。Observable：发布过程可监控，白屏实时查看发布的日志和结果，及时定位问题。回滚：允许人工干预控制发布过程：异常终止，一键回滚。通过这三点，可以实现应用发布变灰、可观察、回滚。2）微服务下线无损在版本更替的过程中，SAE如何保证老版本微服务的流量可以无损下线？上图展示了微服务注册和发布的全过程，服务消费者和服务提供者分别有B1和B2两个实例，服务消费者分别有A1和A2两个实例。B1和B2在注册中心注册，消费者从注册中心刷新服务列表，找到服务提供者B1和B2，正常情况下，消费者开始调用B1或B2，服务提供者B需要发布新版本，首先要操作的节点之一，比如B1，首先停止Java进程，服务停止过程分为主动销毁和被动销毁。主动销毁是准实时的，被动销毁的时间由不同的注册中心决定。在最坏的情况下，可能需要一分钟。如果应用正常停止，SpringCloud和Dubbo框架的ShutdownHook都能正常执行，这一步的耗时基本可以忽略不计。如果应用异常停止，比如直接Kill-9停止，或者构建Docker镜像时，Java进程不是第一个进程，没有给应用传递Kill信号，那么服务提供者不会主动注销Node，等待注册中心发现，被动感知服务下线的过程。当微服务注册中心感知到服务下线时，会通知服务消费者其中一个服务节点下线。有两种方式：注册中心推送和消费者巡更。注册中心刷新服务列表，感知到提供商下线。这个步骤对于Dubbo框架是不存在的，但是对于SpringCloud来说，它最差的刷新时间是30秒。消费者的服务列表更新后，将不再调用离线节点B。在第2步到第6步的过程中，如果注册中心是Eureka，最坏情况下需要两分钟；如果是Nacos，最坏情况下需要50秒。这段时间请求可能会出现问题，所以发布的时候会出现各种错误。经过以上分析，在传统的发布流程中，客户端调用服务端存在报错周期，这是由于客户端没有及时获知服务端实例下线造成的。这主要是因为服务提供者依赖于通知消费者更新提供的服务列表的微服务。能否绕过注册中心，由服务提供者直接通知服务消费者？答案是肯定的。SAE做了两件事。首先，服务提供者会在应用发布前主动将应用从服务注册中心注销，并将应用标记为离线，将注销从原来的stop流程阶段改为preStop阶段的注销流程。当收到服务消费者的请求时，首先会正常处理请求，并通知服务消费者节点已经下线。之后，消费者收到通知后会立即刷新其服务列表。服务消费者将不再向服务提供者B1的实例发送请求。通过以上解决方案，大大缩短了离线感知时间，从原来的分钟级到准实时，保证您的应用下线也能实现业务无损。3）基于标签的灰度发布发布策略分为批量发布和灰度发布。如何实现灰度流量？从上面的架构图可以看出，在应用发布之前，必须配置一个灰度规则，比如根据uid=20的模残差值作为灰度流量规则，应用发布时，发布的节点将被标记为灰度版本。这样的话，当有流量进来的时候，微服务网关和消费者都会通过配置中心获取治理中心配置的灰度规则。消费者的Agent也会从注册中心拉取一些它所依赖的服务的信息。当一个流量进入消费者时，会根据灰度规则进行匹配。如果是灰度流量，就转化为灰度流量，如果是普通流量，就去普通机器，这就是基于标签的灰度发布的具体逻辑。3.运行态实践1)强大的应用监控诊断能力在运行态的情况下，服务运行过程中会出现这样或那样的问题。如何排查和解决？排错解决的前提是要有强大的应用监控和诊断能力，SAE集成了云产品ARMS，可以让运行在上面的Java微服务看到应用调用关系拓扑图，可以定位到你MySQL慢的调用栈服务方法，然后定位到代码层。问题。比如某个请求响应慢，出现业务问题，它可以定位到哪个请求，哪个服务，服务的哪一行代码有问题，可以给解决问题带来很多方便。总的来说，我们首先要有监控告警的能力，才能帮助我们更好的诊断服务运行过程中的问题。2）故障隔离和业务恢复上面提到了我们通过监控和告警来排查和解决遇到的问题。我们的系统能不能主动做点什么？SAE作为一个serverless平台，有很多自主运维的能力，下图中有两种场景：场景一：应用运行过程中，由于磁盘满满导致某些机器负载很高或者网络状态不佳或宿主机资源竞争，客户端调用超时或报错。面对这种情况，SAE提供了一种服务治理能力，即异常值去除，可以配置。当网络超时严重或者后端服务5xx错误达到一定比例时，可以选择将该节点从消费者服务列表中移除。这样一来，问题机器不再响应业务请求，业务的SLA得到了很好的保障。场景二：应用运行过程中，突发流量耗尽内存，导致OOM。在这种情况下，通过SAE等Serverless应用引擎，在节点配置健康检查后，可以重启节点中的容器，快速恢复进程。3）精准容量+限流降级+极致弹性基于ServerlessPaaS平台SAE与其他产品的交互，实现了整个运维状态的闭环。用户在使用的时候，可以通过PTS压测工具来构建场景，然后得到一些阈值。例如，可以预估流量高峰消耗的资源，然后根据这些阈值设计弹性策略。当业务系统达到请求比例时，可以根据设置的弹性策略对自己的机器进行扩容和缩容。在时间上，扩缩容可能跟不上大量请求的处理。此时可以通过与AHAS的交互来配置限流降级的容量。当突发大流量时，可以先使用AHAS能力将部分流量挡在门口，然后触发SAE上应用的扩容策略，对实例进行扩容。这些实例扩容完成后，整机的平均负载会下降。流量再次放回。这是从突发大流量到限流降级再到扩容，再到正常流量的“精准容量+限流降级+极致弹性”的最佳实践模型。总结本文首先按照提出问题和解决问题的思路，讲解微服务是如何解决开发、发布、运行状态的问题；弹性。开发测试态通过注册中心隔离多租户和网络环境，提供环境级能力；通过云端联调技术快速调试本地变更；如果IDE插件快速部署本地更改。发布模式运维平台应用发布需要灰度化、可观察、可回滚；通过MSEagent能力，实现业务不丢包下线；通过标签路由，提供在线流量灰度测试能力。在运行状态下建立强大的应用监控和诊断能力；有能力去除服务质量差的节点的异常值；为不再工作的实例配置健康检查以重启和恢复服务；提供精准容量+限流退化+极限弹性模型。作者简介：王克怀，化名：兴松，阿里云SAE技术研发，负责SAE产品Runtime层的技术架构设计，专注于微服务、Serverless、应用托管领域，持续打造新一代基于云原生技术的应用程序托管平台。
