标签：cep 重启 线性 lib 判断 修复 ref 方案 传递
前言微服务发展至今，因其高内聚、低耦合等特性，以及诸多开源方案带来的开放性，已成为提升架构效率的最佳实践之一。当一项技术或一个框架成为事实标准之后，我们会把更多的注意力聚焦在运维效率和应用可用性的持续提升上。相信下面这些场景大家或多或少都遇到过。
场景一，当业务达到一定的规模之后，微服务的数量和单个微服务实例的数就会变的很多，从而导致微服务注册中心需要管理很多服务地址，同时还需要给所有的上下游提供服务注册和服务发现的能力。
场景二：发布是天大的事情，每一次的发布，都会出现执行到一半的请求中断掉，上游继续调用已经下线的节点导致报错的现象。发布时收到各种报错，同时还影响用户的体验，发布后又需要修复执行到一半的脏数据。
上述场景还是在新版本没有任何问题的情况下，如果新版本有问题，则会导致大量业务直接请求到有问题的新版本，轻则修复数据，重则严重影响用户体验，甚至产生资损。最后不得不每次发版都安排在凌晨两三点发布，心惊胆颤，睡眠不足，苦不可言。
场景三：大半夜某个服务节点出现异常，上游仍旧不断地调用，出现很多异常和各种报警短信。被报警吵醒后，想直接在线上修复，有点难，想保留现场又害怕拖垮整个应用，只好先重启为上。
但是这只是治标不治本的方式，因为很难复现从而无法有效定位，可能明天又被吵醒，继续重启。上述场景还是建立在报警系统比较完善的情况下，如果没有完善的报警系统，严重情况可能整个业务系统都被单机异常拖垮。
场景四：公司业务壮大了，部门组织变复杂后，微服务模块越来越多。我不清楚发布的服务到底被谁调用了，所以我不知道能否安全地下线一个服务。我这个应用的这个接口是个敏感接口，我只希望得到我授权的应用才能调用，而不是直接从服务注册中心得到我的地址就能直接调用，但是目前好像还做不到。
面对以上这些场景，可以通过投入更多的开发和运维资源来解决，但对于大部分希望专注于业务开发的企业来说，如果能有一款适合企业自身需求，支持组件化的商业化产品，将会是更好的选择。
接下来，我们就来详细剖析下阿里云微服务MSE是如何解决以上问题的。
一、注册和配置中心托管
相比基于Zookeeper/Nacos/Eureka来自建注册中心，MSE 提供了以下这些差异化竞争力。
二、如何降低应用发布出错率
什么是无损下线
传统的发布流程中，服务提供者停止再启动，服务消费者感知到服务提供者节点停止的流程如下：
<u>1、服务发布前，消费者根据负载均衡规则调用服务提供者，业务正常。
2、服务提供者 B 需要发布新版本，先对其中的一个节点进行操作，首先是停止 Java 进程。
3、服务停止过程，又分为主动注销和被动注销，主动注销是准实时的，被动注销的时间由不同的注册中心决定，最差的情况会需要 1 分钟。
</u>
如果应用是正常停止，Spring Cloud 和 Dubbo 框架的 Shutdown Hook 能正常被执行，这一步的耗时可以忽略不计。
如果应用是非正常停止，比如直接使用 kill -9 停止，或者 Docker 镜像构建的时候 Java 应用不是 1 号进程且没有把 kill 信号传递给应用。那么服务提供者不会主动去注销服务节点，而是在超过一段时间后由于心跳超时而被动地被注册中心摘除。
<u>4、服务注册中心通知消费者，其中的一个服务提供者节点已下线。包含推送和轮询两种方式，推送可以认为是准实时的，轮询的耗时由服务消费者轮询间隔决定，最差的情况下需要 1 分钟。
5、服务消费者刷新服务列表，感知到服务提供者已经下线了一个节点，这一步对于 Dubbo 框架来说不存在，但是 Spring Cloud 的负载均衡组件 Ribbon 默认的刷新时间是 30 秒 ，最差情况下需要耗时 30 秒。</u>
<u>6、服务消费者不再调用已经下线的节点。
</u>
从第 2 步到第 6 步的过程中，Eureka 在最差的情况下需要耗时 2 分钟，Nacos 在最差的情况下需要耗时 50 秒。在这段时间内，请求都有可能出现问题，所以发布时会出现各种报错，同时还影响用户的体验，发布后又需要修复执行到一半的脏数据。最后不得不每次发版都安排在凌晨两三点发布，心惊胆颤，睡眠不足，苦不可言。
MSE提供的无损下线功能会自动在发布新版本的时候做如下的增强，我们主要关注绿色部分的信息：
<u>1、应用在发布前主动向注册中心注销应用，并将应用标记为已下线的状态。
2、在接收到服务消费者请求时，首先会正常处理本次调用，并通知服务消费者此节点已下线，服务消费者会立即从调用列表删除此节点。
3、在这之后，服务消费者不再调用已经下线的节点。
</u>
MSE的无损下线功能，将原来的从原来的 停止进程阶段 注销服务变成了 prestop 阶段注销服务，将原来的依赖于 注册中心推送，做到了服务提供者直接通知消费者从调用列表中摘除自己。使得下线感知的时间大大减短，从原来的分钟级别做到准实时，确保您的应用在下线时能做到业务无损。
金丝雀发布再加一重保障
在普通的新版本发布场景中，默认情况下请求到各个节点的流量是均匀分布的。
假设服务提供者有 4 台，只要某个节点一发布新版本，就会有 25% 的流量打到新版本。如果新版本存在问题，就会影响线上 25% 的流量，轻则修复数据，重则严重影响用户体验，甚至产生资损。
MSE提供的金丝雀发布功能，支持用户在发布新版本之前就提前配置好金丝雀规则，使得只有符合流量特征的流量会调用到新版本，从而可以精准地控制调用到新版本的流量，进行新版本验证。
在发布一个新版本的应用的时候，通过一个新的 Deployment 来发布，并在 Deployment 中填写相应的版本号
新版本启动之后，默认没有流量，需要在 MSE 控制台配置流量规则才有流量进来，可以基于流量百分比进行配置，也可以按照流量特征进行配置。
配置完成后，Agent 会自动将路由规则推送到服务消费者端，服务消费者会去根据配置好的规则选择去调用新版本或者旧版本。
比如这里我们配置 user-id 对 100 取模为 20 的会去新版本，那么 user-id=120 的这个流量就会去新版本。
三、如何避免半夜醒来重启机器
开源框架有可能被单点异常拖垮整个应用系统
在微服务架构中，当服务提供者的应用实例出现异常时，服务消费者无法及时感知，会影响服务的正常调用，进而影响消费者的服务性能甚至可用性。
在上图的示例场景中，系统包含 4 个应用，A、B、C 和 D，其中应用 A 会分别调用应用 B、C 和 D。当应用 B、C 或 D 的某些实例异常时（如图中应用 B、C 和 D 标识的各有 1个和 2 个异常实例），如果应用 A 无法感知，会导致部分调用失败；如果业务代码写的不够优雅，有可能影响应用 A 的性能甚至整个系统的可用性。
离群实例摘除给业务系统的稳定性加把锁
为了保护应用的服务性能和可用性，MSE支持检测应用实例的可用性并进行动态调整，以保证服务成功调用，从而提升业务的稳定性和服务质量。
如下图所示，您可以在控制台上对应用 A 进行如下配置，从而保证 A 应用的稳定性。
1、 异常类型，网络异常指的是 IOException，业务异常在 Spring Cloud 框架中指的是返回值 http 状态码 为 500 ，Dubbo 框架中指的是返回值中包含 Exception。
2、 QPS 下限，为了避免调用次数太少，随机性较大从而影响判断的准确性，您可以设置 QPS 的下限，只有 QPS 达到一定值后才进行离群摘除判断。默认为 1 ，可以配置成 0。
3、 错误率下限，如果某台服务提供者返回值中，错误的比例超过了配置的这个值，会被判定成需要被摘除。
4、 摘除实例比例上限，为了避免摘除过多的机器节点，导致剩余的节点数流量过载，需要配置一个摘除比例的上限，建议不超过 50%。
5、 恢复检测单位时间，离群节点被摘除的动作是暂时性的，经过单位时间
后，消费者侧会对此节点进行检测。如果节点已经恢复，会将其放回到节点中。如果节点持续被摘除，那么它被摘除的时间会线性增加到最大值。
基于离群实例摘除功能，您不会因为单机异常在半夜醒来重启机器，先安心地睡一觉吧，反正业务也不会受影响。醒来之后机器现场也还在，是拿着保留的现场进行分析，还是直接重启，任君选择。
四、如何做到对自己的服务胸有成竹
服务查询一目了然
我们熟知的 zookeeper 组件并没有服务查询界面，Eureka 和 Nacos 这两个注册中心，虽然提供了网页版的控制台，但是在控制台上只能查询到服务的 IP 和 port 等基本的信息。
MSE用户在使用服务查询时，不仅能够查询到应用注册了哪些服务，对应的 IP 和 port 是什么，还能查询到服务包含的具体方法和参数类型，以及直观地看到服务被其他应用和节点的订阅情况。
即使部门组织再复杂、微服务模块再多，您也可以清晰地查询出服务的被调用情况，做到心中有数，在梳理服务依赖以及评估影响面的时候可以做到胸有成竹。
精准地控制服务调用的权限
业务发展后，服务还会遇到权限控制的需求。比如优惠券部门的某个应用，同时包含了优惠券查询接口 和优惠券发放接口。对于优惠券查询接口来说，默认公司内部的所有应用都有权限调用的；但优惠券发放接口只有客服和运营部门的某些应用才有权限调用。
如下图所示，MSE用户可以对自己的服务进行权限管理，这里以 Dubbo 为例，下图中配置表明，应用 cartservice 发布的 com.alibabacloud.hipstershop.CartService 服务的 addItemToCart 的方法，只允许 frontend 这个应用调用。
除了支持对指定的接口添加鉴权规则之外，服务鉴权也支持对整个应用添加鉴权规则，还支持根据调用方 IP 进行鉴权。
精准的权限管理，可以让你更好地管理微服务调用的权限，保证业务的合规性，保障数据的安全。
MSE 以组件化的方式来提供微服务能力，客户既能对应用实现自主可控，还能低门槛的接入注册中心和配置中心的托管，以及高阶的微服务治理能力。据悉，Spring Cloud 和Dubbo近5年的开源版本，均可0代码修改就能接入MSE。
从开源自治，到微服务云化，阿里云的这款产品给了一剂提升微服务幸福感的良药
标签：cep 重启 线性 lib 判断 修复 ref 方案 传递
原文地址：https://blog.51cto.com/14781300/2509422
