静态网站建设的主要技术,wordpress youku videos,南通seo招聘,网站建设代理招标简介#xff1a; 世上没有免费的午餐#xff0c;微服务技术让 IT 系统变得更敏捷、更健壮、更高性能的同时#xff0c;也带来了架构复杂度的提升。对于开发者而言#xff0c;要想更好的驾驭微服务架构#xff0c;需要解决持续集成、服务发现、应用通信、配置管理、流量防护…简介 世上没有免费的午餐微服务技术让 IT 系统变得更敏捷、更健壮、更高性能的同时也带来了架构复杂度的提升。对于开发者而言要想更好的驾驭微服务架构需要解决持续集成、服务发现、应用通信、配置管理、流量防护等一系列难题。 前言
在大型分布式 IT 架构领域微服务是一项必不可少的技术。从本质上来讲微服务是一种架构风格将一个大型的系统拆分为多个拥有独立生命周期的应用应用之间采用轻量级的通信机制进行通信。这些应用都是围绕具体业务进行构建可以独立部署、独立迭代也可能根据业务负载独立进行水平扩展。
微服务思想以及相关的技术为 IT 架构的发展带来了一系列深刻的变革
易于开发和维护一个应用只会关注一组特定的业务功能通过服务拆分能减少应用之间的耦合度让开发和维护更加简单。
技术栈不受限制在微服务架构中可以结合项目业务及团队的特点合理的选择技术栈。
加快系统演进速度每一个应用都可以独立的进行版本更新通过灰度发布等技术手段能确保发布过程中整个系统稳定运行。
突破性能瓶颈每个应用都能独立的水平伸缩使系统性能可以根据计算资源的增加而得到线性的扩展。
微服务的挑战
世上没有免费的午餐微服务技术让 IT 系统变得更敏捷、更健壮、更高性能的同时也带来了架构复杂度的提升。对于开发者而言要想更好的驾驭微服务架构需要解决持续集成、服务发现、应用通信、配置管理、流量防护等一系列难题。幸运的是针对这些普遍存在的难题业界涌现了一系列优秀的开源技术组件和工具让开发者可以更轻松的构建微服务应用。像 Spring Cloud 和 Dubbo 这样的技术框架经过多年的发展已经演化为微服务领域的通用标准极大地降低了微服务的门槛但这些技术框架依然没有办法解决其中两个最大的挑战这两个挑战成为摆在开发者面前的两座大山。
挑战一亟需完善的生命周期管理与服务治理方案
在一个频繁迭代的系统中每个应用会经常性面临新版本发布需求需要对应用的上线、下线、更新、回滚等流程进行集中性的管理并配合精细粒度的灰度发布手段减少版本迭代对业务造成的影响。 在一个简单的微服务架构中如果某应用处于整个链路的入口位置它的前端一般会挂上负载均衡组件上图中的应用 A以承接来自于最终用户的业务请求。这类应用在进行生命周期管理的时候复杂度会更高为了确保应用在新版本发布过程中的平衡稳定会经过如下的步骤 在这个流程中还没有涉及到对于流量精细粒度控制的高级灰度方案但已经足够体现出其复杂性和操作难度了。如果仅仅依赖于简单的发布脚本进行管理不但效率很低还很容易导致顾此失彼对系统稳定性造成巨大的风险。
挑战二亟需完善的水平扩容与缩容方案
当某一个应用的性能出现瓶颈需要通过增加实例数量来提升性能的时候就需要引入新的计算资源。
新的计算资源从何而来呢
对于线下 IDC 而言计算资源是需要预先规划的扩容并不是一件简单的事情可能会因为各种条件的制约而导致扩容无法实现。当然这种困扰在云计算时代不复存在了为一个应用扩充计算资源是信手拈来的事情但光有计算资源是不够的还得在上面部署应用并将应用容纳到微服务体系中。 根据这个流程如果需要扩容一个应用实例保守估计也需要 20 分钟以上其中购买、系统初始化、应用部署都需要占用大量的时间。假设系统流量突增需要在 2 分钟之内紧急扩容这个方案就无用武之地了。
一剂良药容器化技术
为了解决这两个难题开发者们尝试了各种各样的方案新的理念以及技术框架在过去的这五年层出不穷。在一轮轮的优胜劣汰下以 Docker 为代表的容器技术在 Kubernetes 生态的支撑下在业界成为了主流是构建云原生Cloud Native应用的必备要素。容器化相关技术能够更大程序的挖掘云计算的价值在一定程度上帮助开发者解决这两个难题。
在应用生命周期管理以及服务治理方面 Kubernetes 提供了比较完善的实现机制通过构建 Deployment 资源配合 proStop 和 postStart 脚本能比较方便的实现滚动发布以及应用的优雅上下线。虽然在灰度发布的过程中依然没有办法直接对流量进行精细粒度控制引入 Service Mesh 技术能增强流量控制力不在本文讨论范围但相比简单的发布脚本已经有了飞跃性的提升。
在应用的水平扩容与缩容方面通过容器化技术可以极大程度的减少操作系统安装以及系统级初始化的时间但购买虚拟机的操作是无法避免的所以在系统遇到流量增突的时候依然没有办法实现快速水平扩容。我们可以预留一部分计算资源放在资源池中当应用有扩容需求的时候就向资源池申请资源当业务负载下降的时候再把多余的计算资源归还到资源池中。 这其实并不是一个好主意每一个计算资源都是需要成本的资源池虽然能够解决计算资源快速投入使用的问题却造成了巨大的浪费。另外到底规划多大的资源池也是一件很伤脑筋的事情池子越大造成的浪费就越大但池子太小又可能满足不了扩容的需求。
资源成本更深层次的分析
可能有的开发者会认为目前的业务运行非常的稳定在用户流量上并不存在明显的突增所以扩容和缩容是一个伪需求在将来也不会有这样的需求。这可能是对互联网业务的一种误解因为完全没有扩容需求的情况是不存在的。
首先只要一个系统是为人服务的就必然存在波峰和波谷。对于一个 7*24 小时运行的系统不可能永远保持同样的用户流量二八原则对于很多业务系统依然适用 80% 的用户流量集中在 20% 的时间段。即便是用户流量相对平衡的系统在凌晨也存在流量的低谷如果能更进一步的释放闲置计算资源提升资源利用率就能显著的降低资源使用成本。 另外相比生产环境开发和测试环境对于扩容和缩容的需求会更加迫切。一套微服务应用由不同的团队进行开发在理想的情况下多个团队会共享一套测试环境 然而每个团队对于应用的迭代都会有自己的节奏与此同时他们又想拥有独立的端到端测试环境从而实现环境之间的隔离以避免团队之间的相互影响。这样的话很有可能会形成多套测试环境 随着应用、团队、业务功能点数量的增加所需要的开发测试环境数量还会成倍的增长造成巨大的资源浪费。对于测试环境的计算资源而言资源利用率要远低于生产环境。有的时候仅仅是一个简单功能点的验证为了端对端的跑通业务功能又避免团队之间的相互影响就会开启一套包括全部微服务应用的新环境。这样的资源浪费对于很多企业都是一个多年都未曾得到解决的难题。
因此微服务架构在本质上就是对弹性伸缩有着强烈诉求的在弹性伸缩的过程中不管是单应用的水平弹性伸缩还是整套环境的启停资源利用率都对最终的资源成本起着决定性的作用。如果能想办法提升资源利用率就能为企业节省大量资源成本。值得我们重视的是绝大多数的微服务应用的资源利用率都是非常低的。
我们可以做一个简单的统计把所有服务器的 CPU 利用率每 5 分钟导出一次按照天的维度求平均值就能从整体上了解系统的资源利用率数据。如果把开发测试环境的服务器资源也纳入统计的范围资源利用率很有可能会更低。
Serverless 化探索
资源利用率低的根本原因在于以服务器为载体的应用架构中开发者需要将构建好的程序包部署到服务器上从而对多个用户事件进行响应。为了确保事件响应的及时性需要让程序长驻于服务器上而且尽可能保守的规划资源以避免出现负载过重而导致服务崩溃的情况。在这个过程中实际的负载在时间上分配并不均衡从而导致整体的资源利用率偏低。
Serverless 技术的出现为提升资源利用率提供了新的思路。Serverless 是一种构建和管理基于微服务架构的完整流程允许开发者脱离服务器资源而直接部署应用。它与传统架构的不同之处在于完全由第三方管理由事件触发存在于无状态Stateless的计算容器内。构建无服务器应用程序意味着开发者可以专注在产品代码上而无须管理和操作服务器资源真正做到了部署应用无需涉及基础设施的建设。 Serverless 技术存在多种形态最典型的一种是 FaaSFunction as a Service函数即服务比如阿里云的函数计算Function ComputeFC产品。在函数计算领域一切计算资源的申请和调度都由具体的业务事件触发当业务事件所对应的任务完成之后计算资源会被立即释放。这样的方式真做到了计算资源的按需分配能显著提升资源利用率是 Serverless 技术的终极形态。
另外一种是 Serverless 化的容器技术Serverless 化的容器实例运行在案例隔离的环境中每个计算节点通过轻量级虚拟化安全沙箱技术完全强隔离。对于使用者而言无需购买服务器资源即可直接部署容器应用也无需对集群进行节点维护和容量规划可以根据应用配置的 CPU 和内存资源量进行按需付费。当微服务应用需要扩容的时候就可以快速获得计算资源不需要再经过购买服务器这个步骤了可以帮助开发者降低计算成本减少闲置资源浪费平滑应对突发流量高峰。阿里云的 Serverless Kubernetes ASK就是 Serverless 化容器技术的代表产品。
更进一步发掘开发者的诉求
Serverless 技术无缝是云计算和云原生应用架构的发展方向但对于微服务应用的开发者而言不管是 FaaS 形态还是 Serverless Kubernetes 都存在一定的局限性。
不是每一种业务都适合通过 FaaS 的方式进行构建特别是对于链路长上下游依赖特别明显的应用根本没有办法进行 FaaS 化改造。即便某些业务系统的 FaaS 化改造被证明可行把现有的微服务架构改造成 FaaS 架构也需要一定的工作量并不能做到无缝移植。
Serverless Kubernetes 架构虽然能适配所有的业务场景但对于开发者而言构建一整套 Kubernetes 体系需要掌握一系列跟 Kubernetes 相关复杂的概念有着非常陡的学习曲线。而且 Kubernetes 生态中各种组件的搭建再加上网络层与存储层的适配都涉及非常复杂的工作。
造成这种局限性的原因很简单在以 Spring Cloud 为代表的微服务技术阵营中系统的构建都是围绕着应用也可以理解为单个的服务而展开不管是版本更新还是水平扩展都是针对应用本身。Serverless Kubernetes 架构的核心在于 Pod 比应用更偏向系统底层所以使用者需要投入更多的精力用于应用下层资源的管理。而 FaaS 架构的核心在于函数比应用更偏向系统上层因此灵活度会降低不能适配所有的业务场景。
对于使用主流 Spring Cloud 体系或 Dubbo 体系构建微服务应用的开发者而言如果需要引入一种方案降低资源成本他的最终诉求一定包含两个方面
1能否零改造成本或者接近零改造成本 2能否适配所有的业务场景。
应用层 Serverless 技术
是否有一种介于 FaaS 和 Serverless 化容器之间的技术可以实现上述重要诉求呢当然有这就是以阿里云 Serverless 应用引擎SAE为代表的应用层 Serverless 技术。 图不同层级的 Serverless 技术
SAE 实现了 Serverless 架构 微服务架构的完美融合对于 Spring Cloud 和 Dubbo 等主流的微服务架构可以实现无缝兼容基本上没有改造成本并真正按需使用、按量计费节省闲置计算资源同时免去 IaaS 层运维方面的工作有效提升开发运维效率。
以 Spring Cloud 应用为例如果需要部署一个新的应用只需要 2 个步骤
1告诉 SAE 这个应用需要多少个实例并指定每个实例需要的 CPU / 内存规格。 2上传应用的 JAR 包 / WAR 包并启动应用。
我们发现这两个步骤中并不涉及容量评估、服务器购买、操作系统安装、资源初始化等工作就能让包含多个对等实例的微服务应用运行起来。这是因为在 Serverless 的世界中不再具有服务器资源这样的概念应用的载体是 SAE 调度出来的沙箱容器每个实例只有在真正投入使用后才会按使用时长进行计费。
对于开发者而言他们不用关心应用到底部署在物理机里面还是虚拟机里面或是容器里面也不需要知道底层的操作系统是什么版本的只需要关注每个应用实例占据多少运算资源就可以了。如果应用需要从 4 个实例扩容到 6 个实例或者缩容到 2 个实例只需要一个指令就可以完成甚至与 SLB 的绑定关系都可以自动的建立或解除这是 Serverless 技术为开发者带来的巨大价值。
使用 SAE 部署微服务应用因为只是变更了应用运行的载体所以可以 100% 的兼容现有的技术架构和业务功能迁移成本可以忽略不计。
SAE 的极致弹性能力
除了手动的扩缩容指令SAE 还支持 2 种自动弹性机制可以对微服务应用进行灵活的水平扩展更进一步的发挥云计算的弹性能力。
定时弹性机制对于会预期发生的周期性行为可以设置定时弹性策略。举例如果每天的上午 9 点是业务高峰可以定时每天 8 点半增加实例数量并在 9 点半减少实例数量。
基于指标阈值的弹性机制对于超出预期的业务流量突增可以设置基于指标阈值的弹性策略根据 CPU 、内存等资源指标以有 QPS 等业务指标让应用实现自动的弹性缩。
通过多种弹性机制能够对系统容量进行精细粒度的管理使资源的使用量能随着业务流量的变化而调整从而极大程度的增加资源利用率大幅降低资源成本。 在计算资源的调度和启动上 SAE 做了多项优化对于扩容出来的新实例只需要几秒钟的时间就能拉起这项能力对于一些需要紧急快速扩容的突发场景是具有重大意义的。
对于开发测试环境而言SAE 的机制弹性能力能体现得更加淋漓尽致得益于 SAE 出色的资源调度能力可以一键启停一整套微服务应用。即便仅对一项简单的新功能进行冒烟测试也完全可以新启一套完整而隔离的测试环境来进行。新的环境可以在秒级搭建完成快速投入使用而测试完毕后又可以立即释放。从成本上来讲一套新环境实际投入使用的时间很短因此只会消耗极少的费用。这对于微服务应用开发过程中的多团队协作是一个巨大的变革。 成本分析
SAE 通过资源的实际使用量来付费费用由两部分组成每部分根据统计结果和计算方式进行费用结算按小时出账单扣款。每个应用使用的资源计量方式如下所示
应用 CPU 资源使用量∑实例 CPU 规格×本月运行时长以分钟计即应用中所有实例的 CPU 规格乘以本月运行时长的总和。
应用内存资源使用量∑实例内存规格×本月运行时长以分钟计即应用中所有实例的内存规格乘以本月运行时长的总和。
其中 CPU 部分的价格为 0.0021605 元/分钟/Core内存部分的价格为 0.0005401 元/分钟/GiB。SAE 还提供预付费资源包相当于批发的方式预购计算资源只要能要有效期内消耗完就能更进一步的节省使用成本当资源包扣完以后系统会自动变更为按量付费的模式。
让我们通过一个实际案例来进一步体会 SAE 如何帮助微服务应用降低资源成本。假设一个微服务系统包含 87 个应用实例每个时间每天的平均运行时长为 8 小时实例的配置为 2 Core 4 GiB 20 G 磁盘。
使用包年包月的 ECS 部署应用需要购买 87 台计算型 c5 单台的月成本为 186 元每月总成本 16146 元。使用按量付费的 ECS 部署应用单台价格为 0.63 元/小时每月累计使用 20880 小时总成本 13154 元。使用 SAE 部署应用购买 1 个 75000 元的包年资源包87 个实例每天运行 8 个小时刚好把资源包额度用完折合每月总成本 6250 元。
从这个对比我们可以得出只要能够合理的运行 SAE 的弹性能力就可以为微服务应用大幅度降低资源成本。
附加能力
SAE 除了可以简化运维工作量降低资源成本以外还为微服务应用提升了一系列附加的功能这是应用层 Serverless 技术为开发者带来的额外价值我们可以尽可能的利用这些开箱即用的功能让建设微服务应用变成更加简单。
完整的应用生命周期管理应用托管至 SAE 后可以对应用执行更新、扩缩容、启停、删除、监控启停等应用生命周期管理操作。
开箱即用的注册中心SAE 自带商业版 Nacos 注册中心可以免费使用不需要自行搭建。如果有特殊的需求比如让部署在 SAE 的应用和其他应用相互发现也可以使用微服务引擎MSE产品提供的注册中心或者自建的注册中心。
开箱即用的配置管理中心SAE 集成了 ACMApplication Configuration Management应用配置管理中的配置管理功能可以在 SAE 中使用 ACM 对应用配置进行集中管理。
应用级流量防护 SAE 集成 AHAS 实现应用级别的流控与降级能力全面保障应用的高可用性。
监控能力应用托管到 SAE 以后可以免费获得基础资源包括 CPU、内存、负载和网络以及应用层包括 JVM 分析、接口调用分析等方面的监控能力。如果需要更高级的 SQL 分析、异常分析、链路上下游和接口快照可以集成阿里云应用时间监控产品ARMS。
CI/CD 集成能力SAE 与云效、云效 2020、 Jenkins 等产品进行了深入集成可以方便开发者将构建好的应用快速部署。 多语言支持
对于非 Java 语言编写的应用或者没有使用 Spring Cloud 等微服务框架的 Java 应用 SAE 能不能完美支持并帮助企业降低资源成本呢
当然是可以的。SAE 提供容器镜像部署方式这就代表着不管采用哪种编程语言只要最终的应用能够发布成容器镜像就可以部署在 SAE 上。
对于 Java 系的微服务应用 Java 系统的普通应用以及非 Java 系应用而言SAE 的极致弹性能力并没有本质的区别都能通过 Serverless 技术提供系统的资源利用率。只不过 SAE 提供的一些附加价值比如免费的微服务注册中心就只能为 Spring Cloud 或 Dubbo 应用服务罢了。
总结
让我们用这张图回顾 Serverless 技术的巨大价值 常见问题
1.问应用实例没有固定的机器资源连固定的 IP 地址都没有如何 SSH 到一台服务器排查问题
答并不需要有固定的机器资源和固定的IP地址才能排查问题在云计算时代通过 SSH 登录到一台机器排查问题的方式并不是一个好的实践。相反 SAE 提供了完善的监控能力还可以方便的与云监控、 ARMS 等新一代监控诊断类产品进行了集成为排查故障提供了更大的便利。当然如果一定要登录到某一台机器SSH 依然是可以支持的也可以利用 SAE 提供的 Webshell 工具简化这个流程。
2.问磁盘不是计费的维度吗应用需要大容量磁盘怎么办应用重启后碰盘中的数据还保留吗
答在微服务领域应用一般是无状态Stateless的不需要保存大量的本地数据。如果在特殊的场景下离不开这个需求可以集成 NAS 使用集中式的存储实现。
3.问应用的日志怎么查看
答SAE 控制台界面提供了对于文件日志的实时查阅能力相当于免费提供了一个分布式日志采集平台。当然强烈建议接入阿里云日志服务SLS产品更进一步的发挥应用日志的价值。 原文链接 本文为阿里云原创内容未经允许不得转载。
