章丘公司做网站,iis 7.0 搭建网站,企业网站找谁做,wordpress影视主题公园作者#xff1a;袭周、十眠 让我们从一个十分常见的业务场景说起。 移动互联网时代#xff0c;许许多多的业务都有着流量的周期性变化#xff0c;无论是直播、游戏、点单系统、电商平台等等#xff0c;都会存在着流量的高峰与波谷。如果采用固定的计算资源部署服务#…作者袭周、十眠 让我们从一个十分常见的业务场景说起。 移动互联网时代许许多多的业务都有着流量的周期性变化无论是直播、游戏、点单系统、电商平台等等都会存在着流量的高峰与波谷。如果采用固定的计算资源部署服务使用的多了大量资源在流量波谷闲置浪费使用的少了服务难以抗住高峰期的大规模流量易带来业务损耗。 尤其在大促或节日期间难以预估具体需要的计算资源数量同时不论水平还是垂直扩容人工操作成本都十分高昂。容器技术在某种程度上解决了这类问题K8s 原生的 HPA 可以根据应用的 CPU、Mem 等指标进行灵活弹性无需手动扩容但是使用 K8s 容器化需要付出大量的学习和维护成本这会极大地侵占运维团队的精力。 许多企业都面临着这样的问题。Serverless 产品因此而走进大众的视野。提到简单低负担大家都会想到 Serverless它的本质就是希望开发者不再需要去处理 Server 运维的复杂性。 它能够让用户无需使用和运维 K8s 等容器技术同时又能享受到容器技术带来的技术红利解放人力。 非弹性场景 下图是我使用镜像部署的 demo web 应用想动手实践体验下的同学可以参考本文后边附加的实践教程。这里我使用阿里云的压测工具 PTS 模拟流量波峰的场景在不使用弹性能力的场景下可以看到随着流量的递增服务器难以顶住流量的压力调用的成功率大幅降低RT 在 5000mstimeout 阈值左右徘徊线上业务产生了很大的损失。 加一点弹性 在 SAE 控制台可以一键开启弹性能力无需任何修改和 K8s 运维同时除了 K8s 原生支持的 CPU、Mem 指标外SAE 支持还多种指标弹性包括 QPS、RT、TCP 连接数等还支持定时弹性策略和混合弹性策略下图是开启指标弹性策略后的压测结果可以看到在同样的短暂的延迟之后请求的成功率接近百分百延迟也降至几十毫秒业务几乎没有收到影响相比于未开启弹性能力时有极大的改善。 对于非 Java 应用而言这里已经足够应对绝大多数的场景了然而针对 Java 应用又有特殊的地方。众所周知Java 应用启动相对较慢从开始创建容器到服务完全 ready这需要消耗大量的时间在流量短时间内大幅度上升的情况下这段真空时间可能也会导致线上业务的损失那么如何解决这个问题呢 流量防护解决突发流量风险 每个系统和服务都有其能够容纳的上限但是流量的变化是不确定的。有时候前一秒还很平稳但后一秒可能会出现大量的流量就像双十一零点的场景一样。如果突然来的流量超过了系统的承受能力即使我们配置了弹性能力由于 Java 应用冷启动过程时间过长的问题即使我们立即扩容请求仍然处理不过来。因为扩容来不及新的 Pod 无法启动并分配新的流量而堆积的请求会持续增加且处理速度缓慢老的 Pod 由于请求过多导致 CPU/Load 飙升最终导致整个系统崩溃。因此在这个过程中我们需要针对这种突发的流量来进行限制在尽可能处理请求的同时来保障服务不被打垮这就是流量防护。 为了应对多余的请求我们需要使用流量防护能力来限制这些请求以避免系统被压垮。经过我们的调研我们发现 MSE 流量防护可以满足我们的需求。MSE 流量防护基于毫秒级滑动窗口精确统计以及令牌桶、漏桶等流量控制算法可以提供多种维度的流量控制场景包括秒级精准流控和匀速排队等。这样我们就可以通过 MSE 流量防护来限制多余的请求确保系统的正常运行。 我们集成了 MSE 的流量防护能力对于 SAE 的用户来说通常在 Web 入口或服务提供方Service Provider的场景下我们需要根据服务提供方的服务能力进行流量控制。我们可以结合前期压测评估核心接口的承受能力配置流控规则当每秒的请求量超过设定的阈值时会自动拒绝多余的请求。从而保护服务提供方自身不被突然出现的过多的流量给打垮。 无损上线确保应用完全预热 在压力测试过程中我们还发现了 Java 应用普遍存在的一个问题即冷启动过程中容量过小的问题。 当微服务应用刚启动后由于 JIT 预热和框架资源的懒加载等情况应用的容量会比正常情况下小得多。特别是对于 Java 应用来说这个问题会更加明显。如果我们在这个时候不进行任何预处理应用直接接收线上均分下来的大量流量很容易导致大量请求响应缓慢、资源阻塞甚至应用实例宕机的问题。 在大流量下服务竟然扩容不出来新启动的 Pod 很快就被大流量打垮导致 Liveness 检查失败引起 Pod 重启。在这个阶段我们需要一种手段保证新启动的 Pod 可以平稳地度过冷启动阶段。 此时预热一词蹦入我们脑海在这阶段我们需要通过小流量预热的方式让系统充分进行预热合理分配少量的流量启到充分预热我们系统的作用确保新的 Pod 完全启动后再接受生产中均分下来的大流量。 SAE 默认集成了 MSE 无损上下线 我们需要在无损上线页面开启无损上线开关并配置预热时长然后我们重启应用后我们就可以看到上线 Pod 的流量曲线如上图所示缓慢增长符合小流量预热曲线。 Java 应用难道启动就要很长时间 我们通过实验发现Java 应用在扩容的过程中需要预热、启动过慢因此很大程度上限制了 Serverless 的能力难道 Java 应用启动就应该很慢吗最近在社区中出现了另外的一些声音。 图片来自 https://shipilev.net/talks/j1-Oct2011-21682-benchmarking.pdf 一个 Java 程序的执行生命周期如下图所示分为 JVM 初始化、应用程序初始化、应用预热、应用稳定执行和关闭 5 个部分在这个过程中我们可以看到 Java 应用的局限性Java 在运行基于 JVM 之上因此Java程序启动过程中需要进行 JVM 的初始化与启动。 Java 静态编译在这个过程中相比于传统基于 JVM 的 Java 应用程序运行方式采用静态编译技术能给 Java 应用程序带来如下优势 消除冷启动 没有了程序解释执行、虚拟机初始化等步骤冷启动问题得到大幅度改善。内存占用率大幅降低 静态编译做了大量优化并且没有了虚拟机运行时内存占用内存占用得到大幅降低。 右图来自 https://learn.lianglianglee.com/ GraalVM 为 Java 应用提供 AOT 编译和二进制打包能力基于 GraalVM 打出的二进制包可以实现快速启动、具有超高性能、无需预热时间、同时需要非常少的资源消耗。可以很好地解决 Java 应用启动慢的问题。 Spring Cloud Alibaba 社区基于 GraalVM 技术的最新版本 Spring Cloud Alibaba 应用使用 Nacos 进行服务注册与消费/配置订阅的启动速度提升了近 10 倍、内存占用率降低为原来 1/3。 同时我们也在 SAE 上验证基于 GraalVM 技术对 Java 应用启动的效果Java 应用启动时长从 3s 优化至 300ms极大满足了 Serverless 极致弹性的诉求。可以说 GraalVM 技术为 Java 在 Serverless 场景下带来了新的变革与机遇。 无损下线确保流量低峰缩容过程平滑 当流量高峰过去后我们弹性扩容出来的服务也会随着流量的下降而缩容从而确保最高的资源利用率这也是Serverless 弹性所带来的红利。但是我们在实践的过程中发现开源微服务在缩容的过程中流量并不能做到平滑在Pod销毁的过程中依旧有流量在持续访问下线中的服务从而引起业务问题。 如上图左侧所示只有到客户端感知到服务端下线并且使用最新的地址列表进行路由与负载均衡时请求才不会被负载均衡至下线的节点上。那么在节点开始下线的开始到请求不再被打到下线的节点上的这段时间内业务请求都有可能出现问题这段时间我们可以称之为服务调用报错期。 想象一下在大流量的场景下如果服务调用报错期持续数秒至数十秒我们的业务会有多少请求出现错误也正因为这个原因我们碰到许多客户扩容出来后就不敢缩容。MSE 无损下线可以有效解决微服务下线过程中的流量损失问题 MSE 通过提前注销、主动通知等策略保证每一次微服务下线过程中尽可能缩短服务调用报错期同时确保待下线节点处理完任何发往该节点的请求之后再下线。对于 SAE 的应用来说我们只需要开启微服务治理的无损下线能力无需额外操作即可实现平滑缩容的效果。 进击的 Serverless 提到简单低负担相信大家都会想到 Serverless它的本质就是希望开发者不再需要去处理 Server 运维的复杂性当然 Server 并没有消失而是交给了云平台这也就是 Less 的部分。 经过这么多年的发展Serverless 也在不断地演进Less的范围在不断扩大不仅仅包含 Server 部分还有 0 改造、可观测、弹性、应用托管、微服务、CI/CD 等等各个方面。结合我们前面的微服务架构下复杂性讨论Serverless 其实是微服务架构下降低复杂度减少维护成本的最好的一个解决方案之一。 完整的 Serverless 微服务解决方案SAE 在阿里云最新的 Serverless 体系中已经不局限仅仅关注“Server”部分而是围绕应用整体需要开发或者融合各种 PaaS 能力真正对开发者做到“将复杂留给平台简单留给客户”。以下为阿里云 SAE 产品作为例 首先是第一部分SAE 给用户提供了一个白屏化的界面极大的降低用户的使用门槛甚至可以说 0 门槛它的交互符合大多数开发者心中 PaaS 的心智同时它提供了大量的开发者工具和 SaaS 服务的集成如 Cloudtoolkit 插件、云效流水线、镜像仓库、jar/war 代码包部署、OpenAPI 等等。同时也有很多企业级特性比如命名空间隔离细粒度的权限控制、事件告警中心等等这些能帮助企业解决许多需要面对的实实在在的问题实现微服务无缝迁移0 代码改造开箱即用。 第二部分 在微服务能力上SAE 通过集成 MSE在平台侧注入 MSE 探针整体上实现了一个无侵入业务无感的解决方案提供了丰富的微服务治理能力包括无损上下线灰度发布、流量防护等等。 第三部分 在微服务架构下应用数量较多定位问题困难可观测就需要具备非常高的要求SAE 结合阿里云的 ARMS、云监控、SLS、Prometheus 等产品在 Metrices、Tracing、Logging 等方面都提供了相对完整的解决方案切实解决开发者在可观测方面的痛点包括基础监控、调用链、实时日志、事件等等 第四部分 SAE 让开发者不仅不需要运维 IaaS也不需要运维 K8s免去了 K8s 高昂的学习、试错、运维成本同时又可以利用 K8s 的各种能力包括健康检查、弹性。在此基础上SAE 又实现了比原生 K8s 更强劲的能力。以弹性为例除了 K8s 原生支持的 CPU、Mem 指标外SAE 支持还多种指标弹性如 QPS、RT、TCP 连接数等还支持定时弹性策略和混合弹性策略满足应用在不同环境下按需启停实现 15s 的端到端快速扩容应对突发流量。 提到云原生大家都会想到容器、微服务、不可变基础设施等等技术但是我们回到为什么会出现云原生本质也是希望能借助云原生相关的技术构建出“容错性好、易于管理和便于观察的松耦合系统”所以它也是为了降低复杂性和门槛。相信微服务和 Serverless PaaS 结合的解决方案是实现这个目标的最佳手段之一。 Serverless 的概念已经出现很久并且持续走热在 Serverless 场景下我们的 Java 应用如何更优雅地处理突增的流量呢通过本文的实践我们可以看到 Java 应用在流量洪峰到来之前如何安全平滑地进行防护、扩容和预热以及在流量峰值过去后如何无损地缩容。这样我们可以充分享受 Serverless 架构带来的成本、稳定等方面的红利Serverless 让业务更关注于业务本身。 如何一键使用无损上下线/流量防护能力 前文已经介绍了无损上下线与流量治理相信许多技术从业者已经迫不及待想体验对应的能力了。那么是否有方法可以为应用一键开启这两种微服务治理能力实际上之前 SAE 通过集成 MSE已经提供了公测版本的无损上下线功能。最近随着 SAE 2.0 商业化版本的发布SAE 更为深入地集成了 MSE提供了更完整的治理能力更简洁的配置方式和更清晰的交互逻辑下面来为大家介绍一下如何在 SAE 控制台为部署好的应用开启无损上下线和微服务治理。 前提条件已创建微服务应用可参考链接文档 [ 1] 创建完成后在应用详情页可以统一在微服务治理菜单下管理相关功能开启无损上下线需要用户开通 MSE 专业版或企业版开启限流降级需要开通 MSE 企业版。点击开通链接完成开通操作后可以点击开启按钮期间会自动触发一次应用重启完成后可跳转至对应功能页微服务治理能力即接入应用中。 针对无损上线功能有两个重要参数需要进行配置一个是预热时长用来设置应用实例下一次启动的预热时间。避免前文提到的在较大流量下刚启动的冷系统因应用内部资源初始化不彻底在直接处理大量请求时出现请求阻塞、报错等问题。取值范围为[0,86400]即最大取值为 24 小时默认为 120 秒。 另一个是延迟注册时间用来设置服务注册的延迟时间从而避免应用还未完全初始化就已经被注册到注册中心供外部消费者调用导致请求报错。取值范围为[0,3600]即最大取值为 1 小时默认为 0 秒。 在高级设置中可以设置在就绪检查前完成服务注册或服务预热系统会默认为应用业务就绪检查Readiness 配置路径为 /health端口为 54199原有就绪检查可能会被覆盖。详细功能介绍可以参考无损上下线文档 [ 2] 。针对无损下线点击开启主动通知功能后应用在收到下线请求时会主动通知消费方避免下线过程中消费方继续访问即将下线的应用实例。 相关链接 [1] 链接文档 https://help.aliyun.com/zh/sae/user-guide/application-management?spma2c4g.11186623.0.i6#82bbc67015v82 [2] 无损上下线文档 https://help.aliyun.com/zh/sae/user-guide/configure-graceful-start-and-shutdown?spma2c4g.11186623.0.i2