中间件小哥
TA的个人档案
个人介绍
阿里中间件（Aliware）官方账号
擅长的技术
- Java
- Python
- 前端开发
- Linux
- 数据库
- 高分内容
- 最新动态
- 文章
- 问答
-
发表了文章 2020-10-15
企业级分布式应用服务 EDAS 3.0 多语言功能重磅发布--附 EDAS 3.0 Demo 解析
免费报名：https://yqh.aliyun.com/live/detail/20660 【直播主题】企业级分布式应用服务 EDAS 3.0 多语言功能重磅发布--附 EDAS 3.0 Demo 解析 【直播时间】10月16日 15:00 【直播嘉宾】古琦、陆昆 【直播简介】EDAS 3.0 零代码侵入就能完成 Dubbo 和 Spring Cloud 应用上云，支持ECS和K8s集群，可代购 ECS/SLB，支持混合云及自建 IDC 等非阿里云资源接入。新增多语言功能，即使用自定义镜像部署多语言应用至K8s集群，提供非Java语言如PHP、Go、Python等在EDAS的部署、监管控能力。本次直播将对云栖大会期间发布的EDAS3.0Demo进行深度解析，130S 让您读懂EDAS3.0！
-
发表了文章 2020-10-14
通过Serverless技术降低微服务应用资源成本
本文作者：山猎，阿里云智能技术专家，13年IT领域行业经验，对互联网云原生架构以及大规模分布式技术有着深入理解，实战经验丰富，多次帮助阿里云的行业客户对系统架构完成全面的云原生改造。 前言 在大型分布式IT架构领域，微服务是一项必不可少的技术。从本质上来讲，微服务是一种架构风格，将一个大型的系统拆分为多个拥有独立生命周期的应用，应用之间采用轻量级的通信机制进行通信。这些应用都是围绕具体业务进行构建，可以独立部署、独立迭代，也可能根据业务负载独立的水平扩展。微服务思想以及相关的技术为IT架构的发展带来了一系列深刻的变革：1、 易于开发和维护：一个应用只会关注一组特定的业务功能，通过服务拆分，能减少应用之间的耦合度，让开发和维护更加简单。2、 技术栈不受限制：在微服务架构中，可以结合项目业务及团队的特点，合理的选择技术栈。3、 加快系统演进速度：每一个应用都可以独立的进行版本更新，通过灰度发布等技术手段能确保发布过程中整个系统稳定运行。4、 突破性能瓶颈：每个应用都能独立的水平伸缩，使系统性能可以根据计算资源的增加而得到线性的扩展。 微服务的挑战 世上没有免费的午餐，微服务技术让IT系统变得更敏捷、更健壮、更高性能的同时，也带来了架构复杂度的提升。对于开发者而言，要想更好的驾驭微服务架构，需要解决持续集成、服务发现、应用通信、配置管理、流量防护等一系列难题。幸运的是，针对这些普遍存在的难题，业界涌现了一系列优秀的开源技术组件和工具，让开发者可以更轻松的构建微服务应用。像Spring Cloud和Dubbo这样的技术框架，经过多年的发展，已经演化为微服务领域的通用标准，极大地降低了微服务的门槛，但这些技术框架依然没有办法解决其中两个最大的挑战，这两个挑战成为摆在开发者面前的两座大山。 挑战一 亟需完善的生命周期管理与服务治理方案：在一个频繁迭代的系统中，每个应用会经常性面临新版本发布需求，需要对应用的上线、下线、更新、回滚等流程进行集中性的管理，并配合精细粒度的灰度发布手段，减少版本迭代对业务造成的影响。在一个简单的微服务架构中，如果某应用处于整个链路的入口位置，它的前端一般会挂上负载均衡组件（上图中的应用A），以承接来自于最终用户的业务请求。这类应用在进行生命周期管理的时候，复杂度会更高，为了确保应用在新版本发布过程中的平衡稳定，会经过如下的步骤：在这个流程中，还没有涉及到对于流量精细粒度控制的高级灰度方案，但已经足够体现出其复杂性和操作难度了。如果仅仅依赖于简单的发布脚本进行管理，不但效率很低，还很容易导致顾此失彼，对系统稳定性造成巨大的风险。 挑战二 亟需完善的水平扩容与缩容方案：当某一个应用的性能出现瓶颈，需要通过增加实例数量来进行性能提升的时候，就需要引入新的计算资源。新的计算资源从何而来呢？ 对于线下IDC而言，计算资源是需要预先规划的，扩容并不是一件简单的事情，可能会因为各种条件的制约而导致扩容无法实现。当然这种困扰在云计算时代不复存在了，为一个应用扩充计算资源是信手拈来的事情，但光有计算资源是不够的，还得在上面部署应用，并将应用容纳到微服务体系中。根据这个流程，如果需要扩容一个应用实例，保守估计也需要20分钟以上，其中购买、系统初始化、应用部署都需要占用大量的时间。假设系统流量突增，需要在2分钟之内紧急扩容，这个方案就无用武之地了。 一剂良药：容器化技术 为了解决这两个难题，开发者们尝试了各种各样的方案，新的理念以及技术框架在过去的这五年层出不穷。在一轮轮的优胜劣汰下，以Docker为代表的容器技术，在Kubernetes生态的支撑下，在业界成为了主流，是构建云原生（Cloud Native）应用的必备要素。容器化相关技术能够更大程序的挖掘云计算的价值，在一定程度上帮助开发者解决这两个难题。 在应用生命周期管理以及服务治理方面，Kubernetes提供了比较完善的实现机制，通过构建Deployment资源，配合proStop和postStart脚本，能比较方便的实现滚动发布以及应用的优雅上下线。虽然在灰度发布的过程中，依然没有办法直接对流量进行精细粒度控制（引入ServiceMesh技术能增强流量控制力，不在本文讨论范围），但相比简单的发布脚本，已经有了飞跃性的提升。 在应用的水平扩容与缩容方面，通过容器化技术可以极大程度的减少操作系统安装以及系统级初始化的时间，但购买虚拟机的操作是无法避免的，所以在系统遇到流量增突的时候，依然没有办法实现快速水平扩容。 我们可以预留一部分计算资源，放在资源池中，当应用有扩容需求的时候，就向资源池申请资源，当业务负载下降的时候，再把多余的计算资源归还到资源池中。 这其实并不是一个好主意，每一个计算资源都是需要成本的，资源池虽然能够解决计算资源快速投入使用的问题，却造成了巨大的浪费。另外，到底规划多大的资源池，也是一件很伤脑筋的事情，池子越大，造成的浪费就越大，但池子太小，又可能满足不了扩容的需求。 资源成本更深层次的分析 可能有的开发者会认为，目前的业务运行非常的稳定，在用户流量上并不存在明显的突增，所以扩容和缩容是一个伪需求，在将来也不会有这样的需求。这可能是对互联网业务的一种误解，因为完全没有扩容需求的情况是不存在的。 首先，只要一个系统是为人服务的，就必然存在波峰和波谷。对于一个7*24小时运行的系统，不可能永远保持同样的用户流量，二八原则对于很多业务系统依然适用（80%的用户流量集中在20%的时间段。即便是用户流量相对平衡的系统，在凌晨也存在流量的低谷，如果能更进一步的释放闲置计算资源，提升资源利用率，就能显著的降低资源使用成本。另外，相比生产环境，开发和测试环境对于扩容和缩容的需求会更加迫切。一套微服务应用由不同的团队进行开发，在理想的情况下，多个团队会共享一套测试环境：然而，每个团队对于应用的迭代都会有自己的节奏，与此同时，他们又想拥有独立的端到端测试环境，从而实现环境之间的隔离，以避免团队之间的相互影响。这样的话，很有可能会形成多套测试环境： 随着应用、团队、业务功能点数量的增加，所需要的开发测试环境数量还会成倍的增长，造成巨大的资源浪费。对于测试环境的计算资源而言，资源利用率要远低于生产环境。有的时候仅仅是一个简单功能点的验证，为了端对端的跑通业务功能，又避免团队之间的相互影响，就会开启一套包括全部微服务应用的新环境。这样的资源浪费，对于很多企业，都是一个多年都未曾得到解决的难题。 因此，微服务架构在本质上就是对弹性伸缩有着强烈诉求的，在弹性伸缩的过程中，不管是单应用的水平弹性伸缩，还是整套环境的启停，资源利用率都对最终的资源成本起着决定性的作用。如果能想办法提升资源利用率，就能为企业节省大量资源成本。值得我们重视的是，绝大多数的微服务应用的资源利用率都是非常低的。我们可以做一个简单的统计：把所有服务器的CPU利用率每5分钟导出一次，按照天的维度求平均值，就能从整体上了解系统的资源利用率数据。如果把开发测试环境的服务器资源也纳入统计的范围，资源利用率很有可能会更低。 Serverless化探索 资源利用率低的根本原因，在于以服务器为载体的应用架构中，开发者需要将构建好的程序包部署到服务器上，从而对多个用户事件进行响应。为了确保事件响应的及时性，需要让程序长驻于服务器上，而且尽可能保守的规划资源，以避免出现负载过重而导致服务崩溃的情况。在这个过程中，实际的负载在时间上分配并不均衡，从而导致整体的资源利用率偏低。 Serverless技术的出现，为提升资源利用率提供了新的思路。Serverless是一种构建和管理基于微服务架构的完整流程，允许开发者脱离服务器资源而直接部署应用。它与传统架构的不同之处在于，完全由第三方管理，由事件触发，存在于无状态（Stateless）的计算容器内。构建无服务器应用程序意味着开发者可以专注在产品代码上，而无须管理和操作服务器资源，真正做到了部署应用无需涉及基础设施的建设。 Serverless技术存在多种形态，最典型的一种是FaaS（Function as a Service，函数即服务），比如阿里云的函数计算（Function Compute，FC）产品。在函数计算领域，一切计算资源的申请和调度都由具体的业务事件触发，当业务事件所对应的任务完成之后，计算资源会被立即释放。这样的方式真做到了计算资源的按需分配，能显著提升资源利用率，是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、 能否0改造成本，或者接近0改造成本。2、 能否适配所有的业务场景。 应用层Serverless技术 是否有一种介于FaaS和Serverless化容器之间的技术，可以实现上述重要诉求呢？当然有，这就是以阿里云Serverless应用引擎（SAE）为代表的应用层Serverless技术。 图：不同层级的Serverless技术 SAE实现了Serverless 架构 + 微服务架构的完美融合，对于Spring Cloud和Dubbo等主流的微服务架构，可以实现无缝兼容，基本上没有改造成本，并真正按需使用、按量计费，节省闲置计算资源，同时免去 IaaS层运维方面的工作，有效提升开发运维效率。 以Spring Cloud应用为例，如果需要部署一个新的应用，只需要2个步骤：1、 告诉SAE这个应用需要多少个实例，并指定每个实例需要的CPU/内存规格。2、 上传应用的JAR包/WAR包，并启动应用。 我们发现，这2个步骤中并不涉及容量评估、服务器购买、操作系统安装、资源初始化等工作，就能让包含多个对等实例的微服务应用运行起来。这是因为在Serverless的世界中，不再具有服务器资源这样的概念，应用的载体是SAE调度出来的沙箱容器，每个实例只有在真正投入使用后，才会按使用时长进行计费。 对于开发者而言，他们不用关心应用到底部署在物理机里面，还是虚拟机里面，或是容器里面，也不需要知道底层的操作系统是什么版本的，只需要关注每个应用实例占据多少运算资源就可以了。如果应用需要从4个实例扩容到6个实例，或者缩容到2个实例，只需要一个指令就可以完成，甚至与SLB的绑定关系，都可以自动的建立或解除，这是Serverless技术为开发者带来的巨大价值。 使用SAE部署微服务应用，因为只是变更了应用运行的载体，所以可以100%的兼容现有的技术架构和业务功能，迁移成本可以忽略不计。 SAE的极致弹性能力 除了手动的扩缩容指令，SAE还支持2种自动弹性机制，可以对微服务应用进行灵活的水平扩展，更进一步的发挥云计算的弹性能力。 1、 定时弹性机制：对于会预期发生的周期性行为，可以设置定时弹性策略。举例：如果每天的上午9点是业务高峰，可以定时每天8点半增加实例数量，并在9点半减少实例数量。2、 基于指标阈值的弹性机制：对于超出预期的业务流量突增，可以设置基于指标阈值的弹性策略，根据CPU、内存等资源指标，以有QPS等业务指标让应用实现自动的弹性缩。 通过多种弹性机制，能够对系统容量进行精细粒度的管理，使资源的使用量能随着业务流量的变化而调整，从而极大程度的增加资源利用率，大幅降低资源成本。 在计算资源的调度和启动上，SAE做了多项优化，对于扩容出来的新实例，只需要几秒钟的时间就能拉起，这项能力对于一些需要紧急快速扩容的突发场景，是具有重大意义的。 对于开发测试环境而言，SAE的机制弹性能力能体现得更加淋漓尽致，得益于SAE出色的资源调度能力，可以一键启停一整套微服务应用。即便仅对一项简单的新功能进行冒烟测试，也完全可以新启一套完整而隔离的测试环境来进行。新的环境可以在秒级搭建完成，快速投入使用，而测试完毕后，又可以立即释放。从成本上来讲，一套新环境实际投入使用的时间很短，因此只会消耗极少的费用。这对于微服务应用开发过程中的多团队协作，是一个巨大的变革。 成本分析 SAE通过资源的实际使用量来付费，费用由两部分组成，每部分根据统计结果和计算方式进行费用结算，按小时出账单扣款。每个应用使用的资源计量方式如下所示： 1、 应用CPU资源使用量=∑实例CPU规格×本月运行时长（以分钟计），即应用中所有实例的CPU规格乘以本月运行时长的总和。2、 应用内存资源使用量=∑实例内存规格×本月运行时长（以分钟计），即应用中所有实例的内存规格乘以本月运行时长的总和。 其中CPU部分的价格为0.0021605元/分钟/Core，内存部分的价格为0.0005401元/分钟/GiB。SAE还提供预付费资源包，相当于批发的方式预购计算资源，只要能要有效期内消耗完，就能更进一步的节省使用成本，当资源包扣完以后，系统会自动变更为按量付费的模式。 让我们通过一个实际案例来进一步体会SAE如何帮助微服务应用降低资源成本。假设一个微服务系统包含87个应用实例，每个时间每天的平均运行时长为8小时，实例的配置为2 Core + 4 GiB + 20 G磁盘。1、 使用包年包月的ECS部署应用：需要购买87台计算型c5，单台的月成本为186元，每月总成本16146元。2、 使用按量付费的ECS部署应用：单台价格为0.63元/小时，每月累计使用20880小时，总成本13154元。3、 使用SAE部署应用：购买1个75000元的包年资源包，87个实例每天运行8个小时，刚好把资源包额度用完，折合每月总成本6250元。 从这个对比我们可以得出，只要能够合理的运行SAE的弹性能力，就可以为微服务应用大幅度降低资源成本。 附加能力 SAE除了可以简化运维工作量，降低资源成本以外，还为微服务应用提升了一系列附加的功能，这是应用层Serverless技术为开发者带来的额外价值，我们可以尽可能的利用这些开箱即用的功能，让建设微服务应用变成更加简单。 1、 完整的应用生命周期管理：应用托管至SAE后，可以对应用执行更新、扩缩容、启停、删除、监控启停等应用生命周期管理操作。2、 开箱即用的注册中心：SAE自带商业版Nacos注册中心，可以免费使用，不需要自行搭建。如果有特殊的需求，比如让部署在SAE的应用和其他应用相互发现，也可以使用微服务引擎（MSE）产品提供的注册中心，或者自建的注册中心。3、 开箱即用的配置管理中心：SAE集成了ACM（Application Configuration Management，应用配置管理）中的配置管理功能，可以在SAE中使用ACM对应用配置进行集中管理。4、 应用级流量防护：SAE集成AHAS实现应用级别的流控与降级能力，全面保障应用的高可用性。5、 监控能力：应用托管到SAE以后，可以免费获得基础资源（包括CPU、内存、负载和网络）以及应用层（包括JVM分析、接口调用分析等方面）的监控能力。如果需要更高级的SQL分析、异常分析、链路上下游和接口快照，可以集成阿里云应用时间监控产品（ARMS）。6、 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）产品，更进一步的发挥应用日志的价值。 阿里云专门成立了“互联网架构升级实战课”钉钉群，每周都有阿里云专家在群内进行行业最佳实践直播，每天分享前沿干货，欢迎扫码或钉钉搜索群号加入：35712134。
-
发表了文章 2020-10-12
130 秒揭秘 EDAS 3.0 如何平滑应对突发流量高峰，为您的业务保驾护航
"在 PaaS 层面，我们始终拥抱开源技术，并保持和社区版本兼容的时效性；在企业特性上，例如服务治理、应用监控等方面，我们提供一个稳定成熟的产品，来降低企业构建互联网化应用的门槛，例如企业级应用服务 EDAS3.0 就是这样一个典型的产品"——阿里巴巴合伙人、阿里云智能基础产品事业部 高级研究员蒋江伟 EDAS3.0作为应用托管和微服务管理的PaaS平台，支持SpringCloud、ApacheDubbo、ServiceMesh等服务运行环境，提供应用开发、部署、监控、运维等全栈式解决方案，同时平台通过AIOps(智能运维)为托管应用提供性能和稳定性保障。 通常，企业在云上构建互联网应用，都会遇到以下这些问题： 如何来确定一个分布式系统的容量？ 如何实现更加智能的弹性的伸缩，用最低的成本，实现最高的容量？ 当系统出现问题时，如何进行快速定位和诊断？ 带着这三个问题，我们来看看 EDAS3.0 的云原生架构是如何满足真实场景下的流控难题和单点故障引起的交易成功率下降的问题的，详情如视频所示： 戳这里、戳这里、戳这里看视频，这里是视频哦~ 演示系统 视频中演示应用是模拟了一个电商购物交易系统主要包括：系统网关、交易中心、商品中心和购物车四个模块，各个模块之间选择了dubbo和springcloud作为微服务框架进行系统间交互。整个应用选择了阿里云ACK容器服务集群作为部署底座，同时将该集群一键托管到EDAS3.0平台进行微服务治理、应用监控、以及应用部署运维操作。 整个演示流程，我们按照电商大促活动前系统压测演练为背景，使用PTS(Performance Testing Service性能测试)来模拟用户请求流量，EDAS3.0通过限流降级、智能弹性、故障诊断以及异常实例摘除等功能为整个压测演练保驾护航。接下来，我们按照演示流程对每个环节中涉及到的技术进行一一解读分析。 容量探测 对于大促系统压测演练，首先我们需要知道压测目标值(这个需要产品和运营根据历史活动和用户量进行评估)，视频中的目标值为8000TPS(Transaction Per Second, 每秒事务数)。明确目标值以后，我们需要进行压测获取单机水位，这里我们利用了最佳压力值结合接口RT(Response Time,接口返回时间)进行单机容量评估。 如上图所示，最佳压力值指的是系统在最佳性能运行，连续成功率低于98%的点的前一个量级，同时结合我们对接口的SLA的RT上限800ms可以得出单机TPS(Transaction Per Second, 每秒事务数)在850左右(视频中选择了4台机器压测)。可以看出单机容量评估流程需要一定人工经验以及反复测试才可以完成，目前EDAS3.0已经在和PTS合作针对压测场景进行自动化容量评估以及性能诊断。完成上述单机水位评估后，我们即可根据目标值对系统容量进行手动扩容，在EDAS3.0系统中可以完成上述操作。完成扩容以后，通过PTS模拟需要压测的目标值8000TPS，观察扩容后的系统指标RT和交易成功率是否符合预期要求。 性能优化 像大多数首次上线的应用一样，这个电商交易模拟系统作为一个全新demo系统也是经历了多轮压测以及性能调优才达到最后视频中展示的效果。作为一个典型的dubbo微服务系统，这里分享一下整个调优过程中两个比较典型问题的调试过程。整个调试过程我们主要借助EDAS3.0的应用监控中心、日志中心以及Arthas工具进行排查和诊断。首先来看第一个问题，完成第一步容量探测此时PTS的压力值为3400RPS，紧接着直接进行扩容来进行下一步目标值压测，在完成扩容后可以看到RT监控指标反而有上升波动同时会出现一段时间请求错误，这个和预期不符的。我们利用EDAS3.0监控的接口快照链路定位到下游checkout服务问题，同时利用实例监控定位具体是扩容前某个pod问题。接下来在日志中心检查该pod相应日志发现了dubbo线程池满的错误日志，同时发现dubbo多次重试的错误日志。综合分析可以得出根因是，节点调用下游超时重试导致线程池沾满，针对这种情况我们将超时时间、重试次数以及dubbo线程池进行了调整，经过多轮压测后得到合适参数。 完成上述优化以后，由于后续限流降级的需求我们代码引入了AHAS的SDK，同样在容量探测完成以后直接进行手动扩容来进行下一步目标值压测的时候，再次出现短暂的失败率反而上升的问题。有了上一轮调优经验，这一轮我们也是轻车熟路配合Arthas的使用以及AHAS引入时间点，定位到这次问题主要是AHAS的SDK初始化会导致RPC首次调用耗时增加，同时扩容后新节点自身需要预热问题，大流量直接打在新节点上会导致超时失败。针对这两点问题，我们通过启动主动调用AHAS的SDK初始化方法以及修改dubbo的延时注册和预热配置进行解决。 作为一个交易核心链路新系统上线进行压测是必不可少的环节，这也体现了云上PTS的压测系统对于用户重要性，在压测过程中遇到问题我们需要进行一轮轮调优，调优过程中EDAS3.0的监控中心和日志中心起到了重要作用，将整个条有过程变得有章可循同时节省了排查时间。最后，我们可以看到微服务线程池配置、超时配置以及重试配置等是比较常见的微服务问题，未来我们EDAS3.0智能运维(AIOps)可以将这些问题排查变得更加自动化帮助客户节省更多时间。 限流降级 在当今日益复杂的应用环境下，应用设计应该遵循“面向失败”的设计原则，对上下游的依赖零信任。借助流量控制、熔断降级模块，应用就有能力对流量采取限流控制，并对下游依赖进行降级处理。面对视频中超过系统预估容量的突增流量，服务限流降级功能显得尤为重要了，我们知道一旦突发高流量将系统打垮，后续恢复将十分艰难，重启应用的预热，流量迁移等等给用户带来不好体验。EDAS3.0提供的一键接入服务限流降级功能，只需要您在部署阶段勾选接入限流降级服务，您的应用即可享受流量防护模块给您的应用全方位保护。目前该防护模块支持主流的Java框架，包括HTTP和Dubbo，同时可以实时监控框架的QPS（Queries per Second，每秒查询数）、线程数、响应时间、异常数等指标。 完成上述接入以后，在EDAS3.0监控详情页的服务/接口监控的限流降级菜单可以对接口进行规则配置以及实时指标监控，有了限流降级模块的保护，应用就可以从容面对线上突增流量的出现。 智能弹性 在分布式应用管理中，弹性伸缩是很重要的一个运维能力。弹性伸缩能够感知应用内各个实例的状态，并根据状态动态实现应用扩容、缩容，在保证服务质量的同时，提升应用的可用率。在弹性伸缩方面，EDAS3.0提供了更加智能丰富的弹性扩缩策略，包括监控指标策略和自定义弹性策略。同时，针对业务周期性我们还提供了定时弹性来支持该特定业务场景。 视频演示流程中突发流量在限流降级模块的保护下，应用抵挡住了超过系统容量上限的流量。该应用同时配置了单机QPS自定义指标的弹性扩缩策略，智能弹性模块会根据当前外部最新请求量进行智能弹性扩容，从而将超过预估的流量一并吃掉，保证系统稳定性的同时也提升了用户使用产品体验。 离群摘除 在微服务架构中，当服务提供者的应用实例出现异常，而服务消费者无法感知时会影响服务的正常调用，并影响消费者的服务性能甚至可用性。离群实例摘除功能会检测应用实例的可用性并进行动态调整，以保证服务成功调用，从而提升业务的稳定性和服务质量。目前，EDAS3.0微服务治理中的离群摘除功能会在客户端统计服务的指标数据，比如调用次数和错误次数，根据用户的规则配置进行流量摘除。 智能运维 互联网时代，应用并发量激增，业务流程更加复杂，如何保证系统稳定性越发困难，系统可观测性越来越重要。EDAS3.0系统在满足应用运行态和发布态可观测性的基础上，又进一步做到了智能运维(AIOps)。目前，智能运维已成为了应对IT系统与日俱增的复杂性的很好的解决方案， 它基于大数据、数据分析和算法来提供洞察力，并为现代基础设施和软件所需的管理任务提供更高水平的自动化。全球最具权威的IT研究与顾问咨询公司Gatner公司最新AIOps报告预测到2023年，全球40%的DevOps团队会使用AIOps工具。EDAS3.0作为监管控一体化PaaS平台，已经在AIOps领域深耕多年，并将其落地在应用运行态和发布态等多个场景。 如上图所示Gartner总结当下AIOps中涉及的三个主要流程Observer、Engage和Act，EDAS3.0的智能运维(AIOps)也是依照上述流程进行整体诊断分析。 整体来看，EDAS3.0智能运维流程主要包含以下三个部分：异常检测、根因分析和诊断处理。其中，异常检测阶段选择了应用黄金指标中的RT(接口响应时间)和错误率作为检测目标，利用算法和应用历史指标数据进行异常检测分析。在根因分析阶段，系统会根据单机、服务以及关联事件三个维度对异常进行解释和分析。通过三个维度指标检测最终会给出故障可能的原因，在复杂的微服务系统中可以很好的辅助运维人员对故障进行排查和复盘。 在完成根因分析以后，EDAS3.0智能运维系统会根据分析结果进行相应的修复建议、运维自动化处理，同时会给出一份诊断报告对本次故障进行问题定位分析帮助开发同学进行问题排查。诊断报告包含了故障定界、根因分析结果以及相应的建议或者推荐。 演示视频中，通过制造下游节点fullgc故障，从而引发上游接口RT(响应时间)的上升。EDAS3.0智能运维系统自动会检测到此次RT(响应时间)上升的异常，并会针对RT突增异常进行分析检测，最终根据检测结果进行相应的修复手段，如视频中所见在检测出是下游的单机fullgc问题后，智能运维系统通过EDAS3.0微服务治理提供的离群摘除能力将故障机器进行隔离，隔离后故障恢复。最后综述，EDAS3.0作为分布式架构、数字化转型上云的首选在线业务应用托管平台，在微服务治理、应用发布变更以及智能运维等多个维度为用户应用提供智能化、自动化的解决方案，欢迎大家使用。
-
发表了文章 2020-10-12
微服务治理实践：服务契约
本文是《微服务治理实践》系列篇的第四篇文章，主要分享Spring Cloud微服务框架下的服务契约。第一篇：《微服务治理解密》第二篇：《微服务治理实践：服务查询》第三篇：《微服务治理实践：金丝雀发布》在详细讲述服务契约之前，先给大家讲一个场景。 前言 随着微服务架构越来越流行，越来越多的公司使用微服务框架进行开发。甚至不止是公司，连笔者的研究生导师都要对实验室的Spring Boot工程项目转型使用微服务框架了。随着时间的推移，服务量逐渐上升，小学妹吃不消跑来问我问题： 一姐，我来交接你之前写的项目啦，你什么时间方便我想问你一些问题。这么多微服务接口，感觉不知道从哪里去看会比较好呢。 我想了想自己刚入门时候写的垃圾代码，还没有注释，无语凝噎。 好。我平时工作日在实习，周末给你讲哈。 于是到周末，花了整整一个晚上的时间，终于给零基础学妹从众多接口的含义，到参数列表的解析，最后到讲解百度应该搜什么关键词（我好南），全方位视频指导。学妹十分感动： 一姐你太贴心了555，跟别人协作项目的时候，经常能讲上几句就不错了，然后我还是什么都不明白，改完接口也不及时告诉我。还是你最好了，后面还有什么不懂的我再来问你哦。 从以上场景，我们可以总结出使用微服务框架后，会带来的几点进度协同问题：1、不及时提供接口API：尤其体现在项目交接上，该问题对人员变动比较频繁的组织，如高校项目的准毕业生和新生交接、企业项目的外包人员交接，问题会显得更加突出。开发人员经常过于关注微服务的内部实现，相对较少设计API接口。 程序员最讨厌的两件事：1. 写注释 2. 别人不写注释 是不是经常想着写完代码再写注释，但真正把代码写完以后，注释/接口描述一拖再拖最后就没有了？别告诉我你没有过。 2、不及时变更接口：即使有了API文档，但由于文档的离线管理，微服务接口变更以后，文档却没有及时变更，影响协作人员的开发进度。 综上我们看到，我们不但希望所有的微服务接口都可以很方便的添加规范的接口描述，而且也能随着接口的变更及时更新文档。因此，我们需要服务契约来帮助我们解决这些问题。 为什么我们需要服务契约 首先我们来看服务契约的定义： 服务契约指基于OpenAPI规范的微服务接口描述，是微服务系统运行和治理的基础。 有人可能会问了，既然想要规范的描述接口，我有很多其他的方式啊，为什么我要用服务契约？ 1、 我用Javadoc来描述接口然后生成文档不可以吗？可以，但刚刚我们也提到了“程序员最讨厌的两件事”，要求所有的开发人员都去主动的按照规范写注释，把所有的接口、参数列表的类型、描述等信息全都写清楚，是一件比较费时费力的事情。我们希望有一个能够减少开发人员负担的方法。 2、 现在不是有很多专业的API管理工具吗，我直接用专业的API管理工具去维护也是可以的吧。API管理工具我们也是有考虑的，但是有如下的问题：• 很多工具依然缺少自动化的API生成；• 不是专注于解决微服务领域的问题，随着服务量迅速上升，管理起来依旧比较困难。 3、 那微服务框架本身也会有提供相关的接口管理功能吧，Dubbo可以用Dubbo Admin，Spring Cloud可以用Spring Boot Admin，它们不香吗？ 这里篇幅有限，我们不再去详细讲述开源工具我们怎么去一步步使用，就用一张表格说话： 从表格可以看到，EDAS微服务治理的服务契约，支持版本更广泛了，配置难度更低了，代码侵入性没有了，直接用EDAS的Agent方案，它不是更香了？ EDAS 服务契约实践 下面我们来体验一下，EDAS上如何查看Spring Cloud的微服务契约。 创建应用 根据你的需要，选择集群类型和应用运行环境，创建Provider和Consumer应用。 服务查询控制台 1、 登录EDAS控制台，在页面左上角选择地域；2、 左侧导航栏选择：微服务治理 -> Spring Cloud / Dubbo / HSF -> 服务查询；3、 服务查询页面单击某个服务的详情； 查看服务契约 服务详情页面包括基本信息、服务调用关系、接口元数据、元数据等信息。在“接口元数据”一栏，便可查看服务的API信息。当用户使用Swagger注解时，会在“描述”列显示相应信息。 服务契约实现细节 在设计服务契约功能的时候，我们不但解决了开源框架中配置难度大，且部分方案具有代码侵入性的问题，而且针对如下阶段的难点都做了相应的方案，相信这些地方也是微服务框架的使用者会关心的： 1、数据获取 • 获取的同时是否还需要其他配置？• 如何获取所需的方法名及描述、参数列表及描述、返回类型等信息？• 会不会影响服务的性能？• 信息能不能全面的拿到？• 能不能同步接口的变更？ 2、数据解析 • 能不能看到参数类型/返回值类型的详细结构？• 解析参数结构的时候会不会影响启动时间？• 泛型、枚举是否支持？• 循环引用如何解决？下面我们来详细介绍一下这几点都是如何解决的。 数据获取 为了减少用户的配置和使用难度，我们采用了Agent方案，用户无需任何额外的代码和配置，就可以使用我们的微服务治理功能。 Java Agent是一种字节码增强技术，运行时插入我们的代码，便可稳定的享受到所有的增强功能。 而且通过测试可得，只要在SpringMVC的映射处理阶段，选取合适的拦截点，就可以获取到所有的方法映射信息，包括方法名、参数列表、返回值类型、注解信息。由于该点在应用启动过程中只发生一次，因此不会有性能的影响。 我们获取的注解主要是针对Swagger注解。作为OpenAPI规范的主要指定者，Swagger虽并非是唯一支持OpenAPI的工具，但也基本属于一种事实标准。注解解析的内容在表格的描述部分进行展示：• Swagger2的注解解析（如@ApiOperation，@ApiParam，@ApiImplicitParam），解析value值在“描述”列显示；• OpenAPI3的注解解析（如@Operation，@Parameter），解析description值在“描述”列显示。 当接口发生变更时，只要将新版本的应用部署上去，显示的服务契约信息就会是最新的，无需担心接口描述信息不能同步的问题。 数据解析 如果参数列表/返回值的类型是一个复杂类型，一般情况我们只看到一个类型名。那么有没有办法可以看到这个复杂类型的具体构成呢？ 聪明的你可能就会想到，通过反射来递归遍历该类所有的Field，不就都解决了？思路确实如此，但实际要考虑的情况会更复杂一些。 以该复杂类型CartItem为例，它可能不但会包含基本类型，还可能会涉及到泛型、枚举，以及存在循环引用的情况。 因此在解析该类型之前，我们需要先判断一下该类型是否存在泛型、枚举的情况，如果是，需要额外解析并存储泛型列表及枚举列表。 而循环引用问题，我们只需借助一个typeCache即可解决。如下图，A和B构成了一个循环引用。如果我们不采取任何措施，递归遍历将永远没有出口。但是，如果我们在遍历A的所有类型之前，先判断一下typeCache里是否存在TypeA。对TypeB也以此类推：那么当遍历ObjB中所包含类型时，如果遇到了TypeA，同样也会先判断typeCache中是否存在。如存在，就无需再递归遍历ObjA中所有的类型了，而是直接记录一个A的引用。因此，循环引用问题也就得以解决。 最终的解析信息，可以在服务测试功能中得以体现。未来我们可能会支持直接在服务查询中的服务契约页，通过一个入口显示复杂类型的具体解析结构。 由此我们看到，在服务契约的获取及解析阶段，涉及到的可能影响用户体验的问题都得到了一定的解决。 不止是服务契约 本文介绍了几种接口描述方法，并且和开源框架的微服务接口管理功能进行对比，引出了EDAS服务契约。虽然服务契约看起来只是在控制台上的一个接口信息展示功能，但在未来的发展中不可或缺，其上报的关键信息可以很大程度的优化服务测试、服务鉴权、标签路由的体验，是微服务治理体系中的基础功能。 EDAS微服务治理在未来甚至还可以在服务契约的基础上增加更多的增强功能，欢迎体验。 除了 EDAS 和 MSE（微服务引擎）这些微服务产品之外，我们还有 ARMS (应用实时监控服务)、ACM（应用配置管理）、SAE（Serverless 应用引擎）等云产品。欢迎加入我们一起，用心服务客户，共同打造产品，让业务永远在线。
-
发表了文章 2020-09-30
典型业务场景下，如何更好地使用RocketMQ | 在线直播
直播议题名称： 典型业务场景下，如何更好地使用RocketMQ 讲师简介： 折松，阿里云中间件解决方案架构师。主导过大型系统由传统的架构模式演进到大型分布式系统的整个生命周期工作，并在云原生中间件领域有多年从业经验。对系统架构选型、性能调优、问题定位分析有着丰富的实战经验。现致力于通过云原生架构转型来帮助阿里云各行业客户实现业务价值。 直播时间： 2020年10月14日（周三）15：00 议题简介： 当前越来越多企业都在使用消息进行解藕与异步化，以优化业务系统架构，获得更好的系统灵活性、吞吐能力、交互体验。本次直播阿里云专家将结合实战经验，深入剖析RocketMQ重点实现原理，以及在线教育行业的典型使用场景。 议题大纲： 1.消息在系统架构中的意义2.RocketMQ重点实现原理3.在线教育方面的MQ典型使用场景 观看方式： 1.【点击链接报名观看】：https://yqh.aliyun.com/live/detail/205652.【加入钉钉群观看】阿里云专门成立了“互联网架构升级实战课”钉钉群，每周邀请一位阿里云专家在群内进行行业最佳实践直播，每天分享行业前沿干货，欢迎扫码或钉钉搜索群号加入：35712134。
滑动查看更多
2020年10月
-
10.21 16:35:59
发表了文章
2020-10-21 16:35:59
众安保险云原生之旅：贯通行业数字化转型“快车道”
众安保险云原生之旅：贯通行业数字化转型“快车道”
-
10.21 16:31:58发表了文章
2020-10-21 16:31:58
MQTT在游戏运营发行中的实践
MQTT在游戏运营发行中的实践
-
10.21 15:45:06发表了文章
2020-10-21 15:45:06
Spring boot 2.3优雅下线，距离生产还有多远？
Spring boot 2.3优雅下线，距离生产还有多远？
-
10.21 14:55:21发表了文章
2020-10-21 14:55:21
SAE助力南瓜电影7天内全面Severless
SAE助力南瓜电影7天内全面Severless
-
10.20 11:04:38发表了文章
2020-10-20 11:04:38
90秒走进阿里云函数计算
90秒走进阿里云函数计算
-
10.20 10:48:51发表了文章
2020-10-20 10:48:51
Serverless X OpenKruise 部署效率优化之道
Serverless X OpenKruise 部署效率优化之道
-
10.20 10:45:57发表了文章
2020-10-20 10:45:57
考拉海购全面云原生迁移之路
考拉海购全面云原生迁移之路
-
10.19 16:08:29发表了文章
2020-10-19 16:08:29
全面上云这条路，洋葱学院已经走了近7年
全面上云这条路，洋葱学院已经走了近7年
-
10.15 11:29:42发表了文章
2020-10-15 11:29:42
企业级分布式应用服务 EDAS 3.0 多语言功能重磅发布--附 EDAS 3.0 Demo 解析
企业级分布式应用服务 EDAS 3.0 多语言功能重磅发布--附 EDAS 3.0 Demo 解析
-
10.14 10:41:20发表了文章
2020-10-14 10:41:20
通过Serverless技术降低微服务应用资源成本
通过Serverless技术降低微服务应用资源成本
-
10.12 18:42:42发表了文章
2020-10-12 18:42:42
130 秒揭秘 EDAS 3.0 如何平滑应对突发流量高峰，为您的业务保驾护航
130 秒揭秘 EDAS 3.0 如何平滑应对突发流量高峰，为您的业务保驾护航
-
10.12 17:23:25发表了文章
2020-10-12 17:23:25
微服务治理实践：服务契约
微服务治理实践：服务契约
-
10.12 17:18:12发表了文章
2020-10-12 17:18:12
平台式可复用的应用集成能力，助您敏捷、高效的完成企业数字化转型
平台式可复用的应用集成能力，助您敏捷、高效的完成企业数字化转型
-
10.12 15:02:58发表了文章
2020-10-12 15:02:58
阿里云CSB应用集成免费公测
阿里云CSB应用集成免费公测
2020年09月
-
09.30 15:29:43发表了文章
2020-09-30 15:29:43
典型业务场景下，如何更好地使用RocketMQ | 在线直播
典型业务场景下，如何更好地使用RocketMQ | 在线直播
-
09.27 14:18:01发表了文章
2020-09-27 14:18:01
EDAS助力「人人视频」新业务快速稳健上云
EDAS助力「人人视频」新业务快速稳健上云
-
09.27 09:47:26发表了文章
2020-09-27 09:47:26
Serverless 实践：「禾连健康」低门槛微服务化，弹性降本20%以上
Serverless 实践：「禾连健康」低门槛微服务化，弹性降本20%以上
-
09.25 14:54:29发表了文章
2020-09-25 14:54:29
SpringCloud 应用在 Kubernetes 上的最佳实践 — 高可用（容量评估）
SpringCloud 应用在 Kubernetes 上的最佳实践 — 高可用（容量评估）
-
09.25 11:32:08发表了文章
2020-09-25 11:32:08
服务网格 ASM +容器服务 ACK 助力画雕科技构建 IoT 服务管理能力
服务网格 ASM +容器服务 ACK 助力画雕科技构建 IoT 服务管理能力
滑动查看更多
-
发表了文章
2020-10-21
众安保险云原生之旅：贯通行业数字化转型“快车道”
-
发表了文章
2020-10-21
MQTT在游戏运营发行中的实践
-
发表了文章
2020-10-21
Spring boot 2.3优雅下线，距离生产还有多远？
-
发表了文章
2020-10-21
SAE助力南瓜电影7天内全面Severless
-
发表了文章
2020-10-20
90秒走进阿里云函数计算
-
发表了文章
2020-10-20
Serverless X OpenKruise 部署效率优化之道
-
发表了文章
2020-10-20
考拉海购全面云原生迁移之路
-
发表了文章
2020-10-19
全面上云这条路，洋葱学院已经走了近7年
-
发表了文章
2020-10-15
企业级分布式应用服务 EDAS 3.0 多语言功能重磅发布--附 EDAS 3.0 Demo 解析
-
发表了文章
2020-10-14
通过Serverless技术降低微服务应用资源成本
-
发表了文章
2020-10-12
130 秒揭秘 EDAS 3.0 如何平滑应对突发流量高峰，为您的业务保驾护航
-
发表了文章
2020-10-12
微服务治理实践：服务契约
-
发表了文章
2020-10-12
平台式可复用的应用集成能力，助您敏捷、高效的完成企业数字化转型
-
发表了文章
2020-10-12
阿里云CSB应用集成免费公测
-
发表了文章
2020-09-30
典型业务场景下，如何更好地使用RocketMQ | 在线直播
-
发表了文章
2020-09-27
EDAS助力「人人视频」新业务快速稳健上云
-
发表了文章
2020-09-27
Serverless 实践：「禾连健康」低门槛微服务化，弹性降本20%以上
-
发表了文章
2020-09-25
SpringCloud 应用在 Kubernetes 上的最佳实践 — 高可用（容量评估）
-
发表了文章
2020-09-25
服务网格 ASM +容器服务 ACK 助力画雕科技构建 IoT 服务管理能力
-
发表了文章
2020-09-25
华青融天加入阿里云原生合作伙伴计划并发布业务监控和安全运营联合解决方案
滑动查看更多
-
回答了问题
2019-12-20
40. 我们现在的CI/CD 都是用 Jenkins 做的，如何能跟SAE 结合起来？
如果仅需要打通 Jenkins，持续集成到部署应用到SAE，可以尝试调用SAE的部署应用OpenAPI。具体操作如下：使用 Jenkins，通过配置将 Jar 包或者镜像直接发布到 SAE 里面，将API打一个可执行的Jar包，并在CI流程里面上传Jar包到OSS，然后把URL作为参数，调用SAE的部署接口。OpenAPI 列表可在文档- API参考-API概览中查到。地址：https://help.aliyun.com/document_detail/125720.html
任何有关产品的使用疑问，欢迎加入我们的客户交流钉钉群：23198618。（1群100人已满，这是2群群号）
关于 Serverless 应用引擎（SAE）： Serverless 应用引擎（Serverless App Engine，简称 SAE）是面向应用的 Serverless PaaS 平台，帮助 PaaS 层用户免运维 IaaS，按需使用，按量计费，实现低门槛微服务应用上云，有效解决成本及效率问题。支持 Spring Cloud、Dubbo 和 HSF 等流行的开发框架，真正实现了 Serverless 架构和微服务架构的完美融合。除了微服务应用外，您还能通过 Docker 镜像部署任何语言的应用。
产品官网：https://www.aliyun.com/product/sae
赞0 踩0 评论0 -
提交了问题
2019-12-20
40. 我们现在的CI/CD 都是用 Jenkins 做的，如何能跟SAE 结合起来？
-
回答了问题
2019-12-20
39. Serverless应用引擎（SAE）可以用于本地开发环境，开发微服务吗 ？
可以的，通过Cloud Toolkit插件，能打通本地和SAE，进行部署。部署方式可在文档--应用部署-插件部署中找到，现已支持Maven/ Idea/Eclipse 三类插件。
Cloud Toolkit下载地址：https://www.aliyun.com/product/cloudtoolkit
任何有关产品的使用疑问，欢迎加入我们的客户交流钉钉群：23198618。（1群100人已满，这是2群群号）
关于 Serverless 应用引擎（SAE）： Serverless 应用引擎（Serverless App Engine，简称 SAE）是面向应用的 Serverless PaaS 平台，帮助 PaaS 层用户免运维 IaaS，按需使用，按量计费，实现低门槛微服务应用上云，有效解决成本及效率问题。支持 Spring Cloud、Dubbo 和 HSF 等流行的开发框架，真正实现了 Serverless 架构和微服务架构的完美融合。除了微服务应用外，您还能通过 Docker 镜像部署任何语言的应用。 产品官网：https://www.aliyun.com/product/sae
赞0 踩0 评论0 -
提交了问题
2019-12-20
39. Serverless应用引擎（SAE）可以用于本地开发环境，开发微服务吗 ？
-
回答了问题
2019-12-20
38. Serverless应用引擎（SAE）支持云效部署么？
支持。
通过云效可一键部署到SAE，欢迎加入Serverless 应用引擎客户交流钉群（群号：23198618），群内有云效大牛坐镇，提供在线支持。
任何有关产品的使用疑问，欢迎加入我们的客户交流钉钉群：23198618。（1群100人已满，这是2群群号）
关于 Serverless 应用引擎（SAE）： Serverless 应用引擎（Serverless App Engine，简称 SAE）是面向应用的 Serverless PaaS 平台，帮助 PaaS 层用户免运维 IaaS，按需使用，按量计费，实现低门槛微服务应用上云，有效解决成本及效率问题。支持 Spring Cloud、Dubbo 和 HSF 等流行的开发框架，真正实现了 Serverless 架构和微服务架构的完美融合。除了微服务应用外，您还能通过 Docker 镜像部署任何语言的应用。 产品官网：https://www.aliyun.com/product/sae
赞0 踩0 评论0 -
提交了问题
2019-12-20
38. Serverless应用引擎（SAE）支持云效部署么？
-
回答了问题
2019-12-20
37. 除 Java 外，Serverless应用引擎（SAE）是否支持多语言应用呢？
支持。
通过制作 Docker镜像，进行部署，您可以把任何语言的应用部署到SAE上。制作Docker镜像的方式可在文档-应用部署-高级设置-制作应用容器Docker镜像中找到，并提供了相关示例。详情：https://help.aliyun.com/document_detail/98492.html
任何有关产品的使用疑问，欢迎加入我们的客户交流钉钉群：23198618。（1群100人已满，这是2群群号）
关于 Serverless 应用引擎（SAE）： Serverless 应用引擎（Serverless App Engine，简称 SAE）是面向应用的 Serverless PaaS 平台，帮助 PaaS 层用户免运维 IaaS，按需使用，按量计费，实现低门槛微服务应用上云，有效解决成本及效率问题。支持 Spring Cloud、Dubbo 和 HSF 等流行的开发框架，真正实现了 Serverless 架构和微服务架构的完美融合。除了微服务应用外，您还能通过 Docker 镜像部署任何语言的应用。 产品官网：https://www.aliyun.com/product/sae
赞0 踩0 评论0 -
提交了问题
2019-12-20
37. 除 Java 外，Serverless应用引擎（SAE）是否支持多语言应用呢？
-
回答了问题
2019-12-20
29. Serverless应用引擎是否会考虑出一些小的规格给小站长这类的用户使用？
在2019-11-26发布的新版本中，SAE已经支持 0.5Core 1GiB 的小规格实例了，发布详情：https://help.aliyun.com/document_detail/120167.html
赞0 踩0 评论0 -
回答了问题
2019-12-20
36. Serverless应用引擎（SAE）什么时候支持预付费资源包？
Serverless应用引擎（SAE）自商业化9月25日提供商业化服务以来，推出了按量付费6折的活动，并将持续至2020年3月31日。
我们将会在此期间，尽快推出预付费资源包，进一步降低您的使用成本，降本增效是SAE的产品主张。
任何有关产品的使用疑问，欢迎加入我们的客户交流钉钉群：23198618。（1群100人已满，这是2群群号）
关于 Serverless 应用引擎（SAE）： Serverless 应用引擎（Serverless App Engine，简称 SAE）是面向应用的 Serverless PaaS 平台，帮助 PaaS 层用户免运维 IaaS，按需使用，按量计费，实现低门槛微服务应用上云，有效解决成本及效率问题。支持 Spring Cloud、Dubbo 和 HSF 等流行的开发框架，真正实现了 Serverless 架构和微服务架构的完美融合。除了微服务应用外，您还能通过 Docker 镜像部署任何语言的应用。 产品官网：https://www.aliyun.com/product/sae
赞0 踩0 评论0 -
提交了问题
2019-12-20
36. Serverless应用引擎（SAE）什么时候支持预付费资源包？
-
回答了问题
2019-11-04
1. Serverless应用引擎（SAE）怎么设置ARMS监控？
Serverless应用引擎（SAE）自带ARMS的基础应用监控功能，不需要单独设置，可以监控如 QPS、RT、接口调用量、错误数等指标，详情可在Serverless应用引擎（SAE）控制台查看。
赞0 踩0 评论0 -
回答了问题
2019-11-04
2. 新建Serverless应用引擎（SAE）的应用会默认新建 ARMS 监控吗？
新建的Serverless应用会自带ARMS的基础应用监控指标能力（免费使用），如QPS、RT、接口调用量、错误数等，帮助快速定位出错接口和慢接口、发现系统瓶颈。 如果需要其他更高阶的监控指标，需要前往ARMS控制台单独开通ARMS的按量付费或应用/前端监控资源包。
赞0 踩0 评论0 -
回答了问题
2019-11-04
9. 目前，Serverless应用引擎（SAE）支持华南Region吗？
更新：Serverless应用引擎（SAE）已经上线华南Region，截止目前，已经支持华北1（北京）、华东（杭州，上海）、华南1（深圳）4个Region。
赞0 踩0 评论0 -
回答了问题
2019-07-17
35. 请问 Serverless应用引擎 什么时候支持香港地区？
答：暂时还不支持，如果您有在香港region部署的需求，请加入我们的用户钉钉群：23156632，并@SAE客服01，我们会进行登记。
赞0 踩0 评论0 -
提交了问题
2019-06-04
35. 请问 Serverless应用引擎 什么时候支持香港地区？
-
提交了问题
2019-06-04
33.可以对子账号设置只查看EDAS应用日志的权限么?
-
提交了问题
2019-06-04
34. Serverless应用引擎中，重启的服务里能临时写入文件吗？
-
提交了问题
2019-06-04
31.Serverless应用引擎中，可以不用NAT网管访问OSS吗？
-
提交了问题
2019-06-04
30.Serverless应用引擎如何使用SLB/域名证书/二级路由之类的那些监听转发的东西？
滑动查看更多