阿里云

作者：阿里云开发者社区 从 2012 年提出 Serverless 到往年 2022 年刚好十年。 过来十年，上云是确定性趋势，在这个阶段企业一开始的关注点在于如何实现平滑上云。随着越来越多的企业上云，甚至很多企业零碎第一天就是在云上构建，企业的外围关注点转变为如何更好地利用云的能力。 在新的阶段中，云服务的角色也从单纯的提供资源，变成了企业构建利用的新平台，帮忙企业尽可能减小机器运维等低价值反复工作，聚焦于业务的翻新。云厂商的外围能力转变为企业提供 Serverless 云服务，打消用云复杂度，用更简略的形式进步资源利用率，帮忙企业降低成本。 这几年，不只是云厂商，大量的开源商业产品也采纳了 Serverless 模式，包含Confluent Cloud、MongoDB Atlas、Snowflake、Databricks 等。 随着云厂商在存储、计算、中间件、大数据等畛域推出越来越多的 Serverless 服务，云产品体系逐步 Serverless 化，也推动着 Serverless 架构从概念进入到大规模生产落地阶段。2021 年 DataDog 公布 Serverless 钻研报告，数据表明，从云原生初创公司到大型企业都在关注 Serverless，Serverless 生态曾经超过了 FaaS，蕴含数十种服务，能够帮忙开发人员构建更快、更动静的应用程序。 Serverless 奇点己来，所谓奇点，是由安稳倒退转向高速倒退的转折点，这也意味着 Serverless 在全行业的落地将全面暴发。 但与此同时，咱们也看到，一方面是企业关注度一直回升、行业开始落地，另一方面，企业和开发者也对 Serverless 存在一些困惑和顾虑。 阿里云联结 InfoQ 收集了一些企业和开发者对现阶段 Serverless 的反馈，并于 12 月 16 日举办了云原生 Serverless 开发者评测局线下沙龙，邀请了阿里巴巴研究员、阿里云智能云原生利用平台负责人丁宇、阿里云 Serverless 研发团队、上海慧游文化、德基网络科技有限公司、南瓜电影、宝马等企业技术负责人，一起探讨 All on Serverless 过程中的挑战和教训，以期给更多落地 Serverless 的企业提供参考和借鉴。本文截取沙龙上的精彩发言，完整版视频见「阿里云云原生」视频号。 Serverless 到底是什么在议论 Serverless 之前，咱们先理解下，Serverless 是什么？ 2012 年，Serverless 概念正式登上舞台。2016 年，首届 Serverless ConF 将这项技术的探讨推向顶峰。2017 年，阿里云推出国内首个重磅 Serverless 产品服务--函数计算 FC（Function Compute），让开发者只须要专一于业务逻辑开发，而不是把大量精力花在服务器等基础设施的治理上，从而疾速兑现业务价值。 ...

作者：十眠 流量路由，顾名思义就是将具备某些属性特色的流量，路由到指定的指标。流量路由是流量治理中重要的一环，本节内容将会介绍流量路由常见的场景、流量路由技术的原理以及实现。 流量路由的业务场景咱们能够基于流量路由规范来实现各种业务场景，如标签路由、金丝雀公布、同机房优先路由等。 标签路由标签路由是依照标签为维度对指标负载进行划分，符合条件的流量匹配至对应的指标，从而实现标签路由的能力。当然基于标签路由的能力，赋予标签各种含意咱们就能够实现各种流量路由的场景化能力。 金丝雀公布金丝雀公布是一种升高在生产中引入新软件版本的危险的技术，办法是在将更改推广到整个基础架构并使其可供所有人应用之前，迟缓地将更改推广到一小部分用户。金丝雀公布是一种在黑与白之间，可能平滑过渡的一种公布形式。让一部分用户持续用旧版本，一部分用户开始用新版本，如果用户对新版本没有什么拥护意见，那么逐渐扩大范围，把所有用户都迁徙到新版本下面来。始终都有据说，平安生产三板斧的概念：可灰度、可观测、可回滚。那么灰度公布能力就是帮忙企业软件做到疾速迭代验证的必备能力。在K8s中金丝雀公布的最佳实际如下：第一步：新建灰度 Deployment，部署新版本的镜像，打上新版本的标签。第二步：配置针对新版本的标签路由规定。第三步：验证胜利，扩充灰度比例。第四步：若验证胜利，将稳固版本的利用更新成最新镜像；若验证失败，把灰度的 Deployment 正本数调整到 0 或删除该 Deployment。 全链路灰度当企业的倒退，微服务的数量会逐步增多。在有肯定规模的肯定数量的微服务状况下，一次发版可能波及到的服务数量会比拟多，微服务链路也相当较长。全链路灰度能够保障特定的灰度流量能够路由到所有波及到的灰度版本中。 同可用区优先路由当企业的对稳定性的要求变高时，企业的利用会抉择部署在多个可用区中进步利用的可用性，防止某个可用区呈现问题后导致影响利用的可用性。当利用在不同的可用区部署时，利用间跨可用区调用可能会被因为远距离调用造成的网络提早影响，同可用区优先路由会让咱们的Consumer利用优先调用以后可用区内的Provider利用，能够很好地缩小这种远距离调用造成的影响，同时当某个可用区呈现问题后，咱们只需在流量入口处将以后可用区的流量隔离掉，其余可用区的流量不会拜访至以后可用区的节点，能够很好地管制某个可用区呈现问题后的影响面。 流量路由能力实现的场景泛滥，下面只是列举了一些典型的场景，上面咱们将从流量路由原理动手，分析流量路由的实现与技术细节。 流量路由原理须要实现上述所提的流量路由的场景，那么对于Consumer利用来说，同一个 Provider 利用的不同节点之间是有一些非凡的标识。金丝雀公布场景来说，新版本代码所部署的节点须要被标上成新版本的标识；同机房优先路由来说，Provider节点要被标识上机房的信息；全链路灰度场景来说，灰度环境的节点须要被带上灰度标。因而，咱们须要在Provider服务注册的过程中，就在注册到注册核心的地址信息中带上治理场景所需的标识。 节点打标首先介绍一下节点打标的能力，咱们先看看 Apache Dubbo 的设计，其中 Dubbo 服务节点的地址信息应用 URL 模型来承载。 class URL implements Serializable { protected String protocol; // by default, host to registry protected String host; // by default, port to registry protected int port; protected String path; private final Map<String, String> parameters;}举个简略的例子，如果 Consumer 收到这样一条 dubbo://10.29.0.102:20880/GreetingService?tag=gray&az=az_1 地址信息，示意 GreetingService 服务应用的是 dubbo 协定，服务绑定的 ip 与 port 别离为  10.29.0.102 跟 20880，该地址携带上了 tag=gray、az=az_1 这样两条元数据信息，别离示意以后节点的标签为灰度，以后节点所处的可用区（az：Availability Zone 为云上的机房的可用区概念）为 az_1 。那么节点打标的能力其实就比拟明确了，咱们在服务提供者向注册核心注册服务地址之前，咱们在以后服务提供者的地址信息上减少须要减少的元数据信息比方 verion = gray，比方在 Apache Dubbo 的 URL 中减少 paramters 信息，一般来说元数据信息都是 k-v 的 map 构造，这样框架向注册核心注册该节点时会为其增加须要的标签信息verison=gray。 ...

作者：云原生 序近期，阿里云性能测试 PTS 接口测试已上线公布一段时间，本着以和大家交换如何实现高效的接口测试为出发点，本文蕴含了我在接口测试畛域的一些办法和心得，心愿大家一起探讨和分享，内容包含但不仅限于： 服务端接口测试介绍接口测试自动化介绍接口测试自动化实际对于接口测试自动化的思考和总结服务端接口测试介绍什么是服务端？个别所说的服务端是指为用户在 APP 或 PC 应用的互联网性能提供数据服务的背地的所有。以天猫精灵智能音箱系列的产品链路为例，服务端便是网关（包含网关在内）之后的链路。 什么是接口？官网点说，是计算机系统中两个独立的部件进行信息替换的共享边界。艰深点说，就是服务端对外提供数据服务最罕用的信息替换形式。提供数据服务的服务端是个可大可小的机构，做的事大多不止一件，它做了这么多事，最终的指标是给 APP 或其它调用方应用，于是服务端就派出了几个代表，比方 API1 负责提供用户信息，API2 负责提供设施信息，API3 负责提供播放的音频信息等等。共事，服务端规定好跟 API1 通信的接头暗号是param1，param2…，跟 API2 通信的接头暗号是 param3，param4…，而 params 就是接口参数，就是用来通知服务端你要什么服务，具体的要求是什么。接口个别由三个局部组成：协定、地址及参数。 什么是接口测试？个别讲的接口测试指的是对某个给定接口进行功能测试，输出不同的参数时，接口返回值是否正确。下图是经典的测试金字塔模型。 在这个模型中，越往下比例会占的越高，也就是说在一个产品测试中，单元测试比例是最高的，顺次是接口测试和 UI 自动化测试，最顶端是人工测试局部。服务端接口测试在中部，承前启后，由此可见其重要性。 为什么要做接口测试？个别做接口测试有如下起因： 接口是服务端对外提供数据服务最罕用的信息替换形式，接口大部分内容都是数据，通过数据比照咱们能够揣测到零碎的逻辑，测接口其实也就是测逻辑。接口测试绝对容易实现自动化，也容易实现继续集成，且绝对 UI 自动化也比较稳定，能够缩小人工回归测试人力老本与工夫，缩短测试周期，反对后端疾速发版需要。如何做接口测试？后面提到，接口是由这几个组成部分：接口地址、申请协定、申请参数和预期后果。测试接口的步骤个别步骤是：发送申请->解析后果->验证后果。 简略来说，接口测试就是参照接口文档，调用接口，看后果的返回是否跟文档阐明统一；另外，再测试一下接口对异样逻辑的解决比方非法参数或边界值。 深刻来说，接口测试的关注重点在于： 一、接口的数据逻辑是否正确。 咱们须要充沛了解接口的性能，外部是什么样的数据逻辑，它与上下游替换了那些信息或资源，不单纯地停留在参数调用和程序返回的表象数据。艰深地说，就是要晓得这个接口是干什么用的，用到哪里，每次调用会产生什么，而后去测验改产生的有没有产生。 二、接口对于异样参数的解决机制与上下游服务的容错。 如下图所示，被测接口 A 依赖上游服务 A，那么服务A异样的时候被测接口是否很好的容错就很重要，否则服务挂起或宕掉都是有可能的。另外，作为服务提供方接口 B，该当要充沛兼容不同的应用场景、或不同版本的调用方的应用，不能为了服务 E 做的需要，除了E其它的服务使用者都用不了了。总的来说，准则就是 “上游不牢靠，上游要兼容” 。 接口测试自动化介绍为什么是接口测试自动化？接口测试自动化，简略来讲就是性能测试用例脚本化，而后执行脚本，产生一份可视化测试报告。 为什么要做接口测试自动化？不论什么样的测试形式，都是为了验证性能与发现 bug。那为什么要做接口测试自动化呢？一句话概括就是是为了节俭人力老本。具体来说，包含以下几点： 加重本人工作量，把测试从干燥的重复劳动的人工测试中解放出来；帮助手工测试实现很难模仿或无奈模仿的的工作；进步工作效率，比方测试环境的自动化编译、打包、部署、继续集成甚至继续交付等。帮助定位问题，比方接口层发现问题了，能够通过增加的 traceID 定位到日志谬误或错误代码行，尽早发现 bug，主动告诉测试人员。一旦发现问题，立刻告诉测试人员，疾速高效。接口测试自动化的标准这里联合我平时在做接口测试时的一些教训，总结了一些接口测试自动化的标准，抛砖引玉，欢送大家补充。 文档筹备磨刀不误砍柴工，筹备好分具体的接口相干文档可能帮忙后续接口自动化测试工作的高效开展。相干文档包含但不限于一下内容： 1. 《需要文档》 ，明确定义了：接口背地的业务场景，即该接口是干什么用的，用到哪里，每次调用会产生什么等； 2. 《接口文档》 ，明确定义了：接口名，各个入参值，各个返回值，和其余相干信息； 3. 《UI 交互图》 ，明确定义了：各单页面需展现的数据；页面之间的交互等； 4. 《数据表设计文档》 ，明确定义了：表字段规定、表 N 多 N 关系（一对一、一对多、多对多）等； ...

作者：Seata 社区 *用户注销 欢送已应用用户在此链接注销，便于咱们更好的针对业务场景优化： https://github.com/seata/seat... 公布概览 次要新增个性：反对 oracle 和 pgsql 多主键；反对 seata-server 服务注册多注册核心；反对 dubbo3；反对 jdk17；扩大 update join 语法反对；扩大多种 oracle timestamp 类型；反对 ARM64 镜像。大幅度晋升基于 DB 的存储性能。 此次 release 批改文件数：398，累计合并 PR 87 个，共 34 人参加代码 commit 人数。 1.6.0 milestone： https://github.com/seata/seat... seata-server： https://github.com/seata/seat... docker： https://hub.docker.com/reposi... 部署指南： https://seata.io/zh-cn/docs/o... 降级指南： https://seata.io/zh-cn/docs/o... 版本的次要更新如下feature： [#4863] 反对 oracle 和 postgresql 多主键[#4649] seata-server 反对多注册核心[#4779] 反对 Apache Dubbo3[#4479] TCC 注解反对增加在接口和实现类上[#4877] 反对 jdk17[#4914] 反对 mysql 的update join联表更新语法[#4542] 反对 oracle timestamp 类型[#5111] 反对 Nacos contextPath 配置[#4802] dockerfile 反对 arm64bugfix： ...

作者：宸罡 产品介绍—什么是音讯收发弹性大家好，我是来自阿里云云原生音讯团队的赖福智，花名宸罡，明天来给大家分享下阿里云 RocketMQ5.0 实例的音讯弹性收发性能，并且通过该性能生产集群是如果解决大促场景音讯收发的弹性以及降本诉求的。 阿里云弹性策略 本次将会从产品介绍，产品应用及限度，应用形式及演示三个方面来介绍。在介绍 Rocketmq5.0 实例的音讯首发弹性之前，先从整体上看下阿里云的弹性策略。咱们通常认为业务方往往存在预期外的突发业务热点和毛刺流量，惯例扩容无奈及时应答，这样一来服务会有不确定性的危险。因而为了应答突发流量，咱们设计了一套解决机制，最根本的是要满足规格内的预期流量，而后是应答弹性区间内的突发流量能够随时开启的弹性能力，最初是要有对齐全超过弹性下限流量的限流限流能力。针对弹性区间的突发流量，传统自建集群通过惯例扩容形式应答，须要分钟级的解决工夫，在这段时间内业务会受损，并且为了这部分偶然的突发流量扩容到一个较大的规格并不划算。云上5.0实例的音讯收发弹性能力对弹性区间内的突发流量能够做到秒级响应，针对大促这种预期内的短期突发流量能够按量免费更加实惠，仅当用户真正用到这部分弹性能力才免费。 音讯收发弹性简介 接下来咱们就看具体看下 5.0 实例的音讯收发弹性，音讯收发弹性最直观的感触就是在 5.0 实例的详情页面的自适应弹性 TPS 这部分，能够看到在失常音讯收发 TPS 的旁边额定有一个自适应弹性 TPS。通过这部分弹性 TPS 的设置，用户能够疾速、低成本的应答大促这种短时间突发流量的场景。 这时可能有小伙伴会问为什么我不间接降级规格进步规范收发 TPS，而是应用弹性 TPS 呢？让咱们假如一个典型的大促场景，比方在今晚 0 点有大促流动，应用音讯弹性性能的用户齐全能够提前几天就把弹性性能关上，大促完结等流量复原后再把弹性性能敞开，实际上不敞开也不会有什么问题，不应用则不免费。 如果通过降级规格来晋升规范 TPS 应答大促流量，用户同样是提前几天就把规格升高了，那么在大促前这几天依照高规格免费但理论又跑不到高规格的 TPS，实际上花了更多的钱然而确造成了资源的节约。如果用户为了防止资源节约在大促当天 0 点前降级规格，一个是须要用户付出额定的精力来关注 RocketMQ 按时升配，再就是实例的升配是一个重资源操作，扩容耗时长，无奈做到即开即用秒级失效，很有可能曾经到 0 点了然而升配还没有实现。 应用音讯弹性性能的话能够做到秒级失效开箱即用，并且如果没有应用到这部分额定的弹性 TPS 是不会免费的。然而弹性 TPS 也不是个解决问题的万能银弹，也是有下限的，基本上能够在规格规范 TPS 的根底上额定有一半的弹性 TPS，如果规范 TPS+ 弹性 TPS 依然无奈满足用户业务需要，此时意味着仅扩容弹性节点曾经无奈满足需要，同时须要扩容存储节点，所以须要升配规格，这部分的原理前面会具体解释。 也有用户会问，如果我的日常 TPS 在 2500 左右，可不可以购买一个 2000 规范 TPS 的实例并且始终开着 1000 的弹性 TPS 满足需要呢？这种状况咱们倡议间接应用规范 TPS 大于 2500 的实例，因为弹性 TPS 这部分的应用会额定计费，如果一天 24 小时都在大量应用弹性 TPS，从计费上来说间接应用更高规格的实例更实惠。 ...

作者：卜比 本文是《容器中的 Java》系列文章之 2/n，欢送关注后续连载 :) 。从 Java Agent 报错开始，到 JVM 原理，到 glibc 线程平安，再到 pthread tls，逐渐探索 Java Agent 诡异报错。 背景因为阿里云多个产品都提供了Java Agent 给用户应用，在多个 Java Agent 一起应用的场景下，造成了总体 Java Agent 耗时减少，各个 Agent 各自存储，导致内存占用、资源耗费减少。 所以咱们发动了 one-java-agent 我的项目，可能协同各个 Java Agent；同时也反对更加高效、不便的字节码注入。 其中，各个 Java Agent 作为 one-java-agent 的 plugin，在 premain 阶段是通过多线程启动的形式来加载，从而将启动速度由 O(n) 升高到 O(1)，升高了整体 Java Agent 整体的加载工夫。 问题但最近在新版 Agent 验证过程中，one-java-agent 的 premain 阶段，发现有如下报错： 2022-06-16 09:51:09 [oneagent plugin a-java-agent start] ERROR c.a.o.plugin.PluginManagerImpl -start plugin error, name: a-java-agentcom.alibaba.oneagent.plugin.PluginException: start error, agent jar::/path/to/one-java-agent/plugins/a-java-agent/a-java-agent-1.7.0-SNAPSHOT.jar at com.alibaba.oneagent.plugin.TraditionalPlugin.start(TraditionalPlugin.java:113) at com.alibaba.oneagent.plugin.PluginManagerImpl.startOnePlugin(PluginManagerImpl.java:294) at com.alibaba.oneagent.plugin.PluginManagerImpl.access$200(PluginManagerImpl.java:22) at com.alibaba.oneagent.plugin.PluginManagerImpl$2.run(PluginManagerImpl.java:325) at java.lang.Thread.run(Thread.java:750)Caused by: java.lang.InternalError: null at sun.instrument.InstrumentationImpl.appendToClassLoaderSearch0(Native Method) at sun.instrument.InstrumentationImpl.appendToSystemClassLoaderSearch(InstrumentationImpl.java:200) at com.alibaba.oneagent.plugin.TraditionalPlugin.start(TraditionalPlugin.java:100) ... 4 common frames omitted2022-06-16 09:51:09 [oneagent plugin b-java-agent start] ERROR c.a.o.plugin.PluginManagerImpl -start plugin error, name: b-java-agentcom.alibaba.oneagent.plugin.PluginException: start error, agent jar::/path/to/one-java-agent/plugins/b-java-agent/b-java-agent.jar at com.alibaba.oneagent.plugin.TraditionalPlugin.start(TraditionalPlugin.java:113) at com.alibaba.oneagent.plugin.PluginManagerImpl.startOnePlugin(PluginManagerImpl.java:294) at com.alibaba.oneagent.plugin.PluginManagerImpl.access$200(PluginManagerImpl.java:22) at com.alibaba.oneagent.plugin.PluginManagerImpl$2.run(PluginManagerImpl.java:325) at java.lang.Thread.run(Thread.java:855)Caused by: java.lang.IllegalArgumentException: null at sun.instrument.InstrumentationImpl.appendToClassLoaderSearch0(Native Method) at sun.instrument.InstrumentationImpl.appendToSystemClassLoaderSearch(InstrumentationImpl.java:200) at com.alibaba.oneagent.plugin.TraditionalPlugin.start(TraditionalPlugin.java:100) ... 4 common frames omitted相熟 Java Agent 的同学可能能留神到，这是调用 Instrumentation.appendToSystemClassLoaderSearch 报错了。 ...

作者：寒斜 前言对于企业方而言，最关怀的外围诉求就是如何能获取更多的营收，更高的利润，艰深点说就是如何赚更多的钱；企业赚钱的形式次要是通过发售企业服务，当用户购买更多的企业服务，企业赚的钱就越多；而发售企业服务所付出的老本越低，企业获取的利润收益就会减少。进一步总结下来就是，企业最心愿的事件是他们的企业服务在效率，老本，体验上能够一直地晋升，因为企业服务体验做的好，购买他的客户天然便会减少；企业服务效率高的公司，在等同单位工夫内提供的企业服务就会更多；而企业服务的老本升高，单个企业服务的利润营收就会变高。 明确企业服务价值后，咱们理解到老本，效率，体验是营收利润增长的要害。 何谓 Serverless 架构咱们能够简略地了解为，构建利用中须要的计算，存储，网络，数据库，中间件服务等都实现了 Serverless 化，各个系统实现了最精细化的用云，并且该架构体系在平安，高可用方面以及解决高并发的能力，可扩展性都达到了价值的最大化。上面我举一个理论的例子：Serverless 架构实现的 Websocket 集群场景-弹幕利用 来为大家更具体地解释一下。 该我的项目综合使用了计算，存储，网络，数据库，中间件全副件，用企业的规范构建，同时具备平安，高性能，稳定性，可扩大等能力，且实现了云，边，端的现代化拜访架构思路。 其中 websocket.serverless-developer.com 主域名通过寰球减速 DCDN 治理，主域的申请会被转发给边缘节点中的 ER 程序，ER 程序进行缓存解决和动动态分流，动静的资源转发到阿里云函数计算网关。函数计算网关弹性启动实例，解决业务逻辑以及拜访 MNS 消息中间件和 tablestore 数据库存储，动态资源则尽最大限度进行缓存，必要时从 OSS 对象存储进行回源。其中 DCDN 能够进行边缘防护，避免 DDOS 攻打，并且减少了 Https 平安证书进行网站的加密传输，边缘节点的 ER 程序是 Serverless 化的启停，能够达到毫秒级响应工夫。同时函数计算会对更简单的业务算力进行弹性，访问量大的时候多弹实例，无拜访数据则开释至 0。 barrage.websocket.serverless-developer.com 则独自提供 websocket 服务，由 DCDN 主动回源到函数计算，因为自身 websocket 协定无奈被边缘应用程序转发。 值得一提的是，笔者作为一名前端程序员，简直没有高可用，高并发，平安等业余方面的常识，然而这并不障碍我把这些能力构建到本人的利用上，Serverless is More ，这句话越品尝越有感觉。 企业数字化转型中 Serverless 架构的劣势当初咱们可能达到的一个根本共识就是：冀望通过企业的数字化转型来优化企业服务的老本，效率，用户体验。然而咱们暂且先不去探讨企业方因而须要在组织文化方面做的扭转，单纯去看数字化管理工具，具体而言就是业务软件局部。构建软件的根本架构在缓缓的发生变化，从 IDC 到容器集群，明天 K8s 曾经帮忙企业在根底软件架构层面进行了运维体验，效率，老本的晋升。下一个阶段的进化是 Serverless。 这里须要明确一点是，当初寻求的是 效率，老本，体验三者整体的最佳平衡点，并不是单一项的绝对值晋升，因为这三者中存在互斥的景象，比方你晋升体验的前提可能是把老本和效率减少了，而降低成本或者晋升效率自身也可能会影响体验。咱们期待 Serverless 架构可能在适宜畛域中相较于容器集群治理，去实现三者更优的均衡。 老本从计算资源老本方面： Serverless 具备比容器化更细粒度的计算形象。能够做到按量付费，从而极大的节俭计算资源的节约。 开发成本： Serverless 架构利用随着分布式的拓扑节点增多，开发运维老本会晋升下来，另外市场上因为新的利用架构相干的人才不足，从而也会影响 Serverless 架构的利用落地。不过值得注意的是，Serverless 开发者工具正日渐欠缺，Serverless 利用的开发范式也会更加明确，市面上 Serverless 利用架构的实际案例将会越来越多，置信开发成本会很快被补救上来。 ...

作者：陈景明 背景在一些业务场景，往往须要自定义异样来满足特定的业务，支流用法是在catch里抛出异样，例如： public void deal() { try{ //doSomething ... } catch(IGreeterException e) { ... throw e; } }或者通过 ExceptionBuilder，把相干的异样对象返回给 consumer： provider.send(new ExceptionBuilders.IGreeterExceptionBuilder() .setDescription('异样形容信息');在抛出异样后，通过捕捉和 instanceof 来判断特定的异样，而后做相应的业务解决，例如： try { greeterProxy.echo(REQUEST_MSG);} catch (IGreeterException e) { //做相应的解决 ...}在 dubbo2.x 版本，能够通过上述办法来捕捉 Provider 端的异样。而随着云原生时代的到来，Dubbo 也开启了 3.0 的里程碑。Dubbo 3.0 的一个很重要的指标就是全面拥抱云原生，在 3.0 的许多个性中，很重要的一个改变就是反对新的一代 Rpc 协定 Triple。Triple 协定基于 HTTP 2.0 进行构建，对网关的穿透性强，兼容 gRPC，提供 Request Response、Request Streaming、Response Streaming、Bi-directional Streaming 等通信模型；从 Triple 协定开始，Dubbo 还反对基于 IDL 的服务定义。 采纳 triple 协定的用户能够在 provider 端生成用户定义的异样信息，记录异样产生的堆栈，triple 协定可保障将用户在客户端获取到异样的 message 。Triple 的回传异样会在 AbstractInvoker 的 waitForResultIfSync 中把异样信息堆栈对立封装成 RpcException，所有来自 Provider 端的异样都会被封装成 RpcException 类型并抛出，这会导致用户无奈依据特定的异样类型捕捉来自 Provider 的异样，只能通过捕捉 RpcException 异样来返回信息，且 Provider 携带的异样 message 也无奈回传，只能获取打印的堆栈信息： ...

作者：宁佑章（硅基仿生科技）、元毅（阿里云容器服务） “应用阿里云容器服务 Knative，解决了开发迭代慢的问题，减速了深度学习模型的性能晋升；同时提供了弹性可伸缩的资源配置，满足网络服务需要，升高了服务部署老本。” -- 宁佑章 (硅基仿生科技数据中心算法研发部 NLP 我的项目负责人) 背景深圳硅基仿生科技股份有限公司成立于 2015 年，致力于慢病治理畛域的翻新医疗器械研发与产业化，公司规模超 500 人。外围团队由清华、北大、加州理工、普林斯顿、华盛顿大学等名校理工科科学家率领，次要我的项目包含间断血糖监测（CGM）、AI 眼底筛查、人工视网膜、胶囊胃镜机器人等，在多个细分畛域突破国外技术垄断，引领基础学科与行业技术倒退，先后承当和参加国家科技部重点研发我的项目 3 项，成为国内翻新医疗器械畛域准独角兽企业。 遇到的问题2021 年中国糖尿病患者超过 1.4 亿，居世界第一，糖尿病相干医疗收入超万亿；而糖尿病医治的重中之重就是糖尿病教育，能够大幅升高糖尿病医疗收入，同时改善患者预后情况，防止截肢、大脑进化等重大并发症。硅基仿生科技股份有限公司在”珍视生命，贡献，求实，翻新，协同，育人”的价值观下，踊跃投入糖尿病教育的产品研发和技术升级。 原有的技术架构遇到最大的问题是研发效率低，资源老本居高不下。 以智能问答模型为例，因为智能问答模型须要重复测试训练迭代，原有的技术架构须要运维人员一直检测部署，十分浪费时间；另外用户申请常常有峰值，应用固定资源的服务器，顶峰时会导致资源缓和，重大时甚至宕机，非顶峰时又会造成资源节约。 新的技术架构冀望做到按需应用资源，节俭资源应用老本，尽可能少的运维 K8s 集群，同时能基于 K8s 云原生规范 API 应用 Serverless，简化利用运维部署，资源免运维。 解决方案通过充沛沟通，深刻斟酌业务利用场景和需要后，硅基仿生选用了阿里云 Serverless 容器 —— Knative + ASK 产品解决方案： 通过 Knative 可能十分好的满足业务需要： 疾速迭代比方智能问答平台，须要屡次测试和训练，如果用以往的部署计划，会节约大量工夫在运维和部署上，升高产品的开发效率。当初应用了 Knative 疾速部署服务到 K8s 测试上线，大大提高了产品的开发效率，实现了数据驱动开发的良性循环。 极致弹性以往的部署计划，在面对脉冲式拜访流量时，容易造成顶峰时网络申请太多而导致服务器宕机，在低谷时节约网络资源的状况。而在 Knative 的部署计划中，通过极致的弹性能力和灵便的弹性策略，能轻松构建高效、稳固的、能应答脉冲式拜访流量的架构，满足部署需要的同时节省开支。 业务稳定性Knative 内置 queue-proxy 容器与业务容器联合能够实时察看申请流量，并可能做到流量告警。联合基于申请的灰度公布、多版本治理，能够做到全天候随时公布，大大提高了运维和版本的迭代速度。 此外为了更好地帮忙硅基仿生实现技术架构的迁徙，对客户应用过程中呈现的问题，积极响应，疾速排查起因，及时解决问题，保障服务的失常运行。 精益上云，降本增效以后通过 Knative 齐全撑持了硅基仿生的业务零碎，实现了硅基仿生业务全副上云。 包含糖尿病智能问答零碎，在内分泌专家和内测糖友的反对下收集了 14 万+的问答库，基本上涵盖了糖友甚至健康人的各种糖尿病问题；糖尿病科普文章举荐零碎，依据用户的点赞、珍藏、浏览时长等行为，给用户在 7 个频道举荐科普文章，给糖友及其家属举荐个性化的科普文章；血糖剖析助手和 AGP 剖析助手，通过多轮对话的形式，帮忙患者找到低血糖和高血糖的起因并给出倡议，助力患者达到更好的控糖程度；糖尿病事件常识图谱标注平台，包含标注计划的创立，不便地抽取和标注医学文献中的实体和关系，将用于糖尿病相干的诊断、医治以及科研。 凭借 Knative 的弹性速度、弹性策略、免运维、健康检查、实时监控，对服务全生命周期进行治理，硅基仿生极大进步了产品的开发效率和迭代速度，为糖尿病人群的血糖治理发明了极大价值，为进步糖尿病人群以及大衰弱人群的糖尿病认知和衰弱程度做出了巨大贡献。 ...

作者： 魁予 现今有越来越多的企业开始驳回云原生理念进行利用架构转型。而 K8s 和微服务是云原生的两大支柱，随着云原生浪潮而被广泛应用。 对少数利用而言，提供对外服务的使命并不会扭转，相比于原来的单体利用，微服务架构下的利用的服务进口更多，治理更繁琐，微服务网关也应运而生；而 K8s 也提供了多种形式来裸露利用的服务，各种 Ingress 实现百花齐放。面对泛滥技术计划，咱们如何做出正当的抉择，躲避潜在危险，本文将给出一些选型倡议，供大家参考。 云原生网关根本概述K8s 中服务对外拜访的形式对于部署在云服务器上的利用，通常应用负载平衡软件或服务（如 SLB）来提供高可用的服务。K8s 提供了基于 Service 的服务发现机制，用户通过将一批雷同个性的 Pod 绑定到一个 Service，能够提供稳固的 VIP（虚构IP）或域名供集群内拜访，并由 kube-proxy 组件基于 ipvs 或 iptables 实现 Pod 拜访的负载平衡。当须要提供服务对外拜访时，须要应用 NodePort 或 LoadBalancer 类型的 Service。 默认状况下，NodePort 会为服务在每个 K8s 集群的节点上调配一个节点端口，应用节点的 IP 地址和指定的节点端口能够从集群内部拜访到服务后端的 Pod。用 NodePort 的形式裸露服务时，因为客户端配置的是节点的 IP 地址和端口，即便 Service 提供了负载平衡的能力，其稳定性也会受对应节点的影响。在客户端拜访服务时，设置多个 K8s 集群节点的 IP 和服务 nodePort 端口，并配置适合的负载平衡和重试策略，才可能防止单点故障。 K8s 同时提供了 LoadBalancer 的 Service，客户端应用 LoadBalancer 的服务端点，能够无效躲避掉节点单点故障危险。LoadBalancer 类型 Service 基于 NodePort 实现，云厂商 CCM 组件将依据 Service 创立负载平衡监听端口，并将 K8s 集群中各节点和 nodePort 端口增加到负载均衡器后端，由云上负载均衡器实现服务负载平衡能力。 ...

以“深刻数字经济·洞见技术价值”为主题的【InfoQ 2022 中国技术力量年初榜单】正式颁布获奖名单。其中，Apache RocketMQ以其卓越的易用性、社区活跃性、成熟度、产品优越性、代码衰弱度等荣获【2022 年度十大开源新锐我的项目】。 作为支流的分布式消息中间件，RocketMQ于 2012 年开源，并在 2017 年正式成为 Apache 顶级我的项目，继续迸发出旺盛的生命力。 随同着云原生时代的到来以及实时计算的衰亡， 生于云、长于云的 RocketMQ 5.0 应运而生，全新降级为云原生音讯、事件、流交融解决平台，帮忙用户更容易地构建下一代事件驱动和流解决利用。RocketMQ 5.0 专一于音讯基础架构的云原生化演进，聚焦在音讯畛域的后处理场景，反对音讯的流式解决和轻计算，帮忙用户实现音讯的就近计算和剖析，并全面拥抱 Serverless 和 EDA。 在技术迎来重要变革的同时，回顾 Apache RocketMQ 社区这些年的成长历程。目前，寰球 Apache RocketMQ Contributors  700+，促成整个社区长期和衰弱倒退。同时，为了帮忙社区开发者更好地找到感兴趣的技术方向，疾速参加到社区并推动相干个性优化的疾速演进，RocketMQ 还成立内核、批处理、Connect、Streaming、多语言客户端、RocketMQ-Flink、Operator、Exporter 等不同兴趣小组。 为更好汇集本地开发者，咱们在北京、深圳、苏州等城市相继成立当地社区，定期举办线下流动，独特探讨 RocketMQ 相干的落地实际与新个性需要，大量翻新从社区的各类流动中产生并且落地。除此之外，RocketMQ 还非常重视社区间的单干，先后与 Apache DolphinScheduler，Apache Hudi 等社区组织了屡次联结 Meetup，在打造 RocketMQ 上下游生态的同时，也为不同社区开发者近距离探讨提供了平台。 在社区成员以及泛滥的开发者独特推动下，寰球超过数万家企业在应用 Apache RocketMQ，这其中不仅有字节跳动、快手、小米、滴滴、同城艺龙等互联网头部企业，还有泛滥银行、券商、保险，基金公司等金融公司。通过多年倒退，RocketMQ 已成为微服务畛域业务音讯首选。 本次获奖离不开整体社区成员的共同努力，是整体社区成员的独特荣誉！社区将再接再厉，不忘初心，继续促成  Apache RocketMQ 我的项目和社区的继续倒退。 退出Apache RocketMQ 社区十年铸剑，Apache RocketMQ 的成长离不开寰球 700+ 位开发者的积极参与奉献，置信在下个版本你就是 Apache RocketMQ 的贡献者，在社区不仅能够结识社区大牛，晋升技术水平，也能够晋升集体影响力，促成本身成长。 社区 5.0 版本正在进行着热火朝天的开发，以及 30 +个 SIG（兴趣小组）等你退出，欢送立志打造世界级分布式系统的同学通过以下形式退出社区： 微信搜寻：「rocketmq666」，增加开发者微信，即可退出微信群；钉钉搜寻：「21982288」，即可退出钉群。 微信扫码增加小火箭进群 ...

2022年12月28日，以“原生万物 云上翻新”为主题的第三届云原生实战峰会在线上举办。 会上，阿里云提出激活企业应用构建三大范式，并公布云原生可观测套件、企业级分布式应用服务EDAS 等产品焕新降级 ，以云原生技术继续推动企业数字翻新。 阿里云云原生利用平台总经理丁宇示意，从最开始布局容器，到外围零碎云原生化，再到往年提出外围云产品全面 Serverless 化，阿里云始终以先行者的视角布局技术，并一直带给业界新的设想空间。同时在开源生态上，2022年阿里云在开发者合作影响力上排名寰球第二。在搭档生态上，通过与搭档能力互补，让云原生产品和服务以最优的形式服务20多万企业，构建凋谢交融的生态体系。

作者：服务网格ASM 背景介绍 站酷（ZCOOL）2006 年 8 月创建于北京，深耕设计畛域多年，汇集了 1500 万设计师、摄影师、插画师、艺术家、创意人，在设计创意群体中具备肯定的影响力与号召力。站酷在创建之初，就以“让设计更有价值”为本身使命，多年来，始终致力于打造以原创设计为外围的“站酷原创版权生态体系”。 目前站酷旗下除领有主站设计师互动平台「站酷网」之外，还重点打磨了一站式正版视觉内容交易平台——「站酷海洛」、一站式创意营销解决方案共创平台——「站酷共创」。值得一提的是，站酷近期公布了 AIGC 产品—— 「AI 创作实验室」。通过文字输出，能够在 1 分钟内生成高质量图像， 自公测以来，曾经生成图片数十万张。将来也会造成一个 AIGC 学习分享的专属社区。 站酷会在人工智能畛域持续深耕，帮忙设计师晋升效率，更好专一在艺术作品创作的创意上，激发创作灵感。站酷的这一系列生态布局，为设计创意从业者在学习、展现、交换、待业、交易、守业各个环节提供了优质的业余服务，为设计师和企业的成长之路提供了高效的版权解决方案和平面的视觉服务。 技术挑战在站酷的业务架构上，只管应用 Kubernetes 平台解决了业务容器生产调度的问题，但在服务的治理、观测、平安等方面仍面临着诸多挑战。 1、多语言、多集群服务对立纳管站酷面向互联网用户，提供站酷网、站酷海洛、站酷学习等各项服务，这些业务应用了 node.js、Java、php 等多种技术栈进行开发，并部署在多个 Kubernetes 集群中，如何通过对立的业务中台对立纳管这些业务是一个很大的技术挑战。 2、服务指标观测体系的构建对于上述的业务架构而言，很难对于不同的应用服务实现对立的可观测体系、进行服务指标的对立实时监控。 3、服务治理的自动化集成因为站酷建设了对立的业务中台，对于服务的部署、保护、治理等有着较强的自动化配置需要。对于多集群服务治理的场景须要肯定的自动化集成能力。 基于服务网格 ASM 的生产实践服务网格作为一种用来治理应用服务通信的根底核心技术,  为应用服务间的调用带来了平安、牢靠、疾速、利用无感知的服务治理、平安、可观测能力。为多语言应用服务的治理、观测等挑战提供了无侵入式的高效解决方案。 而阿里云服务网格产品  ASM 作为业内首个全托管 Istio 兼容的服务网格，一开始从架构上就放弃了与社区、业界趋势的一致性，管制立体的组件托管在阿里云侧，与数据面侧的用户集群独立。ASM 产品是基于社区开源的 Istio 定制实现的，在托管的管制面侧提供了用于撑持精细化的流量治理和平安治理的组件能力。通过托管模式，解耦了 Istio 组件与所治理的 K8s 集群的生命周期治理，使得架构更加灵便，晋升了零碎的可伸缩性。  相比社区服务网格 Istio，服务网格 ASM 提供了更为弱小实用的多项能力，包含多集群对立纳管、即插即用的插件核心、与阿里云云产品深度集成的可观测核心等，可能更好地帮忙站酷解决业务建构中的各种技术挑战，显著升高运维老本。 目前，站酷所有的互联网用户业务都曾经接入 ASM，包含站酷主站、站酷海洛等。 站酷的业务架构图如下： 1、多集群、多语言下的应用服务治理在站酷的生产实践中，多集群、多语言的业务架构对对立治理带来了不小的挑战。对于服务网格来说，因为 Sidecar 模式的无侵入式个性，能够以对立的形式治理以不同技术栈开发的多语言利用，实现显著的运维老本升高。但对于社区服务网格 Istio 而言，多集群下的服务治理、以及对不同的 Kuberenets 集群状态的兼容依然是一个极大的挑战。 通过应用服务网格 ASM，对多集群、多状态、多语言服务的对立纳管成为了非常简单的工作。托管式服务网格 ASM 在成为多种异构类型计算服务对立治理的基础设施中, 提供了对立的流量治理能力、对立的服务平安能力、对立的服务可观测性能力、以及实现对立的代理可扩大能力, 以此构筑企业级能力。 服务网格 ASM 的托管式架构 ...

作者：董艺荃｜携程服务框架负责人 携程微服务产品的倒退历程 携程微服务产品起步于 2013 年。最后，公司基于开源我的项目 ServiceStack 进行二次开发，推出 .Net 平台下的微服务框架 CServiceStack。 2014 年，公司推出 Java 平台下同 CServiceStack 齐全互通的自研微服务框架 Baiji 和第一代服务注册核心。该服务注册核心后续经验屡次重构，目前应用的已是第四代产品。 2017 年，公司正式引进开源产品 Dubbo，推出整合携程治理能力的 CDubbo 框架。该框架最后基于 Dubbo 2.5.4 版本进行二次开发，经验屡次版本升级后，目前应用 Dubbo 2.7.7 版本。 2020 年，公司正式开始摸索落地 Service Mesh 我的项目。目前，相干产品曾经在生产环节正式落地，正在进行接入推广工作。 携程微服务产品状况简单，次要在于以下四点。 第一，线上同时运行着三种微服务框架产品。 第二，同时采纳 HTTP 和 Dubbo 两种通信协议。 第三，采纳齐全自研的基础设施，包含注册核心和配置核心。 第四，现存 8000 多个线上服务，实例数超过 10 万个。 随着研发的深刻，咱们团队次要遇到了以下三点问题。 第一，保护多个性能相似的中间件产品工作量较大，保障产品之间性能对齐须要破费大量的精力。 第二，因为产品以 SDK 公共依赖包的模式集成在业务利用内，进行版本升级须要业务方配合，推动降级比拟艰难，版本长尾问题重大。 第三，因为团队工作精力和技术栈的限度，只有少数几个语言平台上存在 SDK 反对，不利于小众语言用户应用微服务产品。 携程的云原生微服务架构设计 因为线上集群已初具规模，如何平滑适度和迁徙框架成为关键问题。彻底摈弃现有基础设施，一步到位实现全面云原生，不仅施行难度较大，我的项目周期也比拟长。 因而，我的项目决定采纳“小步快走”的形式。首先保障代码齐全向后兼容，其次保障整体架构反对业务利用迁徙，晋升接入容错率。 我的项目进行架构设计时，遇到了三个要害的问题。 数据权威问题：常见的 Service Mesh 实际以 K8S 为准则，将所有的数据保留在 K8S 内，但平台现有数据大部分保留在自研的注册核心和配置核心内。 ...

作者：子葵 背景在 ZooKeeper 的日常应用过程中，一个令人头疼的问题就是节点的磁盘容量问题，如果因为过大的 TPS 或者不适当的清理策略会导致集群中数据文件，日志文件的沉积，最终导致磁盘爆满，Server 宕机。近期就在线上发现某用户的一个集群在一个时间段内的 TPS 暴增。 导致磁盘中 snapshot 和 transaction log 文件十分多。 最终导致磁盘被写满，节点服务不可用。 本篇通过深刻解读 ZooKeeper 数据文件生成机制，以及 ZooKeeper 中和数据文件生成相干的参数，探索一下 解决 ZooKeeper 磁盘问题的最佳实际。 剖析ZooKeeper 中生成的数据文件有哪些？首先咱们须要探索一下  ZooKeeper 对数据进行长久化的基本原理，ZooKeeper 为了保障所有的数据变更不失落，采纳状态机来进行数据的记录和复原，简略来讲，ZooKeeper 中有一个大 Map 存储所有 Znode，key 就是 Znode 的 Path，value 就是 Znode 中的数据，acl，状态等信息，ZooKeeper 通过在某一时间点对内存中的大 Map 进行序列化失去这一时间点内存中数据的一份快照，同时通过另一个文件，存储在此工夫节点之后对这份快照中数据状态的批改操作。 当 ZooKeeper 节点重启的时候，会通过现有的 snapshot 和 transaction log 进行数据恢复。 采纳这种做法可能很好的保障内存中已变更的数据不会失落，同时写性能不会有太多损失，在遇到节点宕机之后，可能残缺的复原数据。 从此看来，ZooKeeper 产生的数据文件次要有两类：内存中数据的快照文件，以及存储变更的事务日志文件，这两类文件别离通过配置文件中的 dataDir 和 dataLogDir 进行指定，这也是 ZooKeeper 中占用磁盘空间比拟大的两类文件。 当 zk 中数据存储过多或者数据变更十分频繁的状况下，将内存中的存储的 snapshot 序列化到文件中，以及数据变更产生的事务日志文件就会很多很大，如果没有配置适合数据清理策略和参数，磁盘问题将会导致集群节点宕机，甚至服务不可用。 ...

作者：Koordinator 社区 背景Koordinator 旨在为用户提供残缺的混部工作负载编排、混部资源调度、混部资源隔离及性能调优解决方案，帮忙用户进步提早敏感服务的运行性能，开掘闲暇节点资源并调配给真正有须要的计算工作，从而进步全局的资源利用效率。 从 2022 年 4 月公布以来，Koordinator 迄今一共迭代公布了 9 个版本。我的项目经验的大半年倒退过程中，社区吸纳了包含阿里巴巴、小米、小红书、爱奇艺、360、有赞等在内的大量优良工程师，奉献了泛滥的想法、代码和场景，一起推动 Koordinator 我的项目的成熟。 明天，很快乐地发表 Koordinator v1.1 正式公布，它蕴含了负载感知调度/重调度、cgroup v2 反对、烦扰检测指标采集，以及其余一系列优化点。接下来咱们就针对这些新增个性做深刻解读与阐明。 版本个性深刻解读负载感知调度反对按工作负载类型统计和平衡负载水位Koordinator v1.0 及之前的版本，提供了负载感知调度提供根本的利用率阈值过滤爱护高负载水位的节点持续好转影响工作负载的运行时品质，以及通过预估机制解决解决冷节点过载的状况。已有的负载感知调度能解决很多常见场景的问题。但负载感知调度作为一种优化伎俩，还有比拟多的场景是须要欠缺的。 目前的负载感知调度次要解决了集群内整机维度的负载平衡成果，但有可能呈现一些非凡的状况：节点部署了不少离线 Pod 运行，拉高了整机的利用率，但在线利用工作负载的整体利用率偏低。这个时候如果有新的在线 Pod，且整个集群内的资源比拟缓和时，会有如下的问题： 有可能因为整机利用率超过整机平安阈值导致无奈调度到这个节点上的；还可能呈现一个节点的利用率尽管绝对比拟低，但下面跑的全是在线应用率，从在线利用角度看，利用率曾经偏高了，但依照以后的调度策略，还会持续调度这个Pod上来，导致该节点沉积了大量的在线利用，整体的运行成果并不好。在 Koordinator v1.1 中，koord-scheduler 反对感知工作负载类型，辨别不同的水位和策略进行调度。 在 Filter 阶段： 新增 threshold 配置 prodUsageThresholds，示意在线利用的平安阈值，默认为空。如果以后调度的 Pod 是 Prod 类型，koord-scheduler 会从以后节点的 NodeMetric 中统计所有在线利用的利用率之和，如果超过了 prodUsageThresholds 就过滤掉该节点；如果是离线 Pod，或者没有配置 prodUsageThresholds，放弃原有的逻辑，按整机利用率解决。 在 Score 阶段： 新增开关 scoreAccordingProdUsage 示意是否按 Prod 类型的利用率打分平衡。默认不启用。当开启后，且以后 Pod 是 Prod 类型的话，koord-scheduler 在预估算法中只解决 Prod 类型的 Pod，并对 NodeMetrics 中记录的其余的未应用预估机制解决的在线利用的 Pod 的以后利用率值进行求和，求和后的值参加最终的打分。如果没有开启 scoreAccordingProdUsage ，或者是离线 Pod，放弃原有逻辑，按整机利用率解决。 ...

作者：卜比 本文是《容器中的 Java》系列文章之 1/n，欢送关注后续连载 :) 。最近共事说到Java的 ParallelGCThreads [ 1]  参数，我翻了下 jdk8 的代码，发现 ParallelGCThreads 的参数默认值如下： 如果 CPU 外围数目少于等于 8，则 GC 线程数量和CPU数统一如果 CPU 外围数大于 8，则前 8 个核，每个外围对应一个 GC 线；其余核，每 8 个核对应 5 个 GC 线程然而被揭示，发现即便在调配 4 核的容器上，GC 线程数也为 38。而后就想到应该和容器的资源限度无关——jvm 可能无奈觉察到以后容器的资源限度。 翻了下代码，发现最新版本的 Java 是能感知容器的资源限度的，就依照 jdk 版本再翻了下代码： 线上的 jdk（jdk8u144）写一个 sleep 1000s 的程序，用于查看 JVM 的线程数量： ./jdk1.8.0_144/bin/java -XX:+UseG1GC -XX:+ParallelRefProcEnabled Main而后查看 GC 线程数目： $ jstack $pid | grep 'Parallel GC Threads' | wc -l38一算就晓得物理机器有 56 个外围（8+(56-8)*5/8=38） 而后应用 +PrintFlagsFinal 看下参数： ...

作者：史明伟（世如） 间隔阿里云事件总线（EventBridge）和 Serverless 函数计算（Function Compute，FC）发表全面深度集成曾经过来一年，站在零碎元数据互通，产品深度集成的肩膀上，这一年咱们又走过了哪些历程？从事件总线到事件流，从基于 CloudEvents 的事件总线触发到更具个性化的事件流触发，函数计算已成为事件总线生态不可或缺的重要组成部分，承载了 EventBridge 零碎架构中越来越多的角色，事件流基础架构的函数 Transform，基于函数计算的多种上游 Sink Connector 投递指标反对，函数作为 EventBridge 端点 API Destination；基于事件总线对立，规范的事件通道能力，和基于函数计算麻利、轻量、弹性的计算能力，咱们将又一次起航摸索云上事件驱动架构的最佳实际。明天的主题围绕事件总线+函数计算，构建云上最佳事件驱动架构利用。心愿通过明天的分享，可能帮忙大家深刻了解 Serverless 函数计算、EventBridge 事件总线对于构建云上事件驱动架构利用的价值和背地的逻辑、 为什么函数计算是云上事件驱动服务最佳实际？为什么咱们如此须要事件总线服务？随同着这些谜题的解开，最初，让咱们一起理解利用于理论生产的一些 Serverless 事件驱动客户案例。 事件驱动架构的实质Back to the Nature of Event-Driven大家可能会纳闷，事件驱动妇孺皆知，为什么咱们又要从新探讨事件驱动呢？我想这也正是咱们须要探讨它的起因，回归实质，从新起航；事件驱动可能是一个比拟宽泛的概念，而本文聚焦事件驱动架构的探讨，事件驱动架构作为一种软件设计模式，确实不是一个新的概念，随同着计算机软件架构的演进，它曾经存在了一段很久的工夫，大家对它的探讨也从未进行过，当咱们须要从新探讨一个曾经存在的概念的时候，我想咱们有必要从新回到它最开始的定义，一起摸索那些实质的货色，重新认识它。 下面的这些内容是我从相干的一些材料上摘录的对于事件驱动的一些形容，“abstract”，“simple”，“asynchronous”，“message-driven”这些具备代表性的词汇很好的给予事件驱动一个宏观的形容；从事件驱动的抽象概念，到它简洁的架构，以及事件驱动架构要达成的目标，和它在理论的零碎架构中所展示的状态。 事件驱动架构基本概念及状态在理解了对于事件驱动架构的一些根本形容之后，咱们须要进一步明确事件驱动架构所波及的一些基本概念和架构状态。依据维基百科形容，事件驱动架构波及的外围概念如下所示： 围绕事件的流转，依据事件驱动架构的概念和根本状态，次要波及以下四个外围局部： Event Producer：负责产生事件，并将产生的事件投递到事件通道；Event Channel：负责接管事件，并将接管的事件长久化存储，投递给订阅该事件的后端解决引擎；Event Processing Engine：负责对于订阅的事件做出响应和解决，依据事件更新零碎状态；Downstream event-driven activity：事件处理实现之后，对于事件处理响应的一种展现；事件驱动架构要达成的目标理解了事件驱动架构的根本状态，架构中事件通道的引入，解耦了事件生产和事件处理这两个最根本的零碎角色，那么这样的架构模型所要达成的最终目标到底是什么？ 零碎架构松耦合事件生产者与事件订阅者在逻辑上是离开的。事件的生成与应用的拆散意味着服务具备互操作性，但能够独立扩缩、更新和部署。 只面向事件的涣散耦合能够缩小零碎依赖项，并容许您以不同的语言和框架实现服务。您无需更改任何一个服务的逻辑，即可增加或移除事件生成方和接管方。您无需编写自定义代码来轮询、过滤和路由事件。 零碎的可伸缩性基于事件驱动架构的松耦合个性，意味着能够独立对事件生产者，事件通道服务，以及事件处理引擎进行独立的扩缩容；尤其对于后端事件处理引擎，能够依据音讯解决响应 SLA 和后端资源供应进行弹性扩缩容；同时能够基于事件粒度构建不同规格的后端解决服务，实现更细粒度的零碎弹性伸缩。 零碎的可扩展性零碎的可扩展性，次要体现在当零碎须要减少新的性能，如何疾速的基于现有零碎架构疾速构建反对新的业务逻辑，在事件驱动架构利用中，围绕事件粒度的解决模式，可能人造疾速反对减少新的基于事件的数据流形象；当零碎中减少新的事件类型的时候，无需调整变更公布整个零碎，只须要关注须要订阅的事件进行事件处理逻辑的开发和部署即可，也能够基于原来的零碎做很少的代码变更即可实现，也能够在业务初期通过独立的服务定于指定事件实现特定的业务逻辑反对。 为什么函数计算是云上事件驱动服务最佳实际？在探讨完事件驱动架构根本模型之后，我想对于事件驱动的概念，状态咱们有了对立的意识和了解，接下来咱们进入议题的第二个局部，为什么函数计算是云上事件驱动服务最佳实际？ 函数计算简介函数计算是一款基于事件驱动的全托管计算服务，相干的产品细节能够见官网介绍。作为一款通用的事件驱动型计算服务，接下来我会从三个方面进行具体的介绍。 编程范式应用函数计算，用户无需洽购与治理服务器等基础设施，只需编写并上传代码。函数计算为你筹备好计算资源，弹性地、牢靠地运行工作，并提供日志查问、性能监控和报警等开箱即用性能，编程范式带来开发的敏捷性。依照函数粒度进行独立的性能单元开发，疾速调试，疾速的部署上线，省去了大量资源购买，环境搭建的运维工作；同时函数计算是一个事件驱动的模型，事件驱动，意味着用户不须要关注服务产品数据传递的问题，省去了在编写代码中波及的大量服务拜访连贯的逻辑；“事件驱动” + “函数粒度开发” + “免服务器运维”等几个维度特色帮忙函数计算撑持“聚焦业务逻辑麻利开发”的底层逻辑。 计算模型除了开发模式带来的研发效力晋升之外，函数计算提供十分细粒度的计算资源和毫秒级计费模型，撑持按需计算，按量免费；可能反对按用户的申请，依据用户流量的模型为计算付费；当然按用户申请付费存在技术上微小的挑战，要求函数计算实例的启动小于用户的 RT 要求，冷启动性能尤为重要，这时候极致弹性成为了 Serverless 按需付费，业务降本的底层技术撑持。函数计算通过“极致弹性” + “按需付费”的模型帮忙 Serverless 函数计算实现真正的按需计算逻辑。 ...

12 月 3 日，首次 “微服务x容器开源开发者 Meetup” 在上海胜利举办。本次流动围绕云原生畛域当下 11 个热门开源我的项目的技术分享和企业实际开展。来自航空、金融、汽车、医疗、批发等行业的开发者来到现场与 Spring Cloud Alibaba、Dubbo、OpenYurt、KubeVela、OpenSergo、Koordinator  等云原生畛域传统&新锐开源我的项目的外围维护者进行了深度交换，11 个开源我的项目展现了最新进展、能力劣势及成功实践等精彩内容。流动现场因为名额限度，很多开发者搭档反馈心愿可能线上观看。这不~咱们立马给大家安顿！！ 12月14日（周三）10:00-16:00 ，咱们将在阿里云云原生视频号及开源中国视频号对本场流动进行联播，欢送扫描下方海报二维码进行预约。 精彩回顾分享主题：Spring Cloud Alibaba 全新异地多活解决方案超远距离带来的网络提早是异地多活最大的技术难点。本场流动，Spring Cloud Alibaba 开源我的项目负责人 ， 饶子昊（铖朴）为大家带来了利用于阿里巴巴外部多年的异地多活解决方案。从异地多活的背景、Spring Cloud Alibaba 异地多活的解决方案、性能演示以及社区的将来布局四个方面进行了具体的解读，为宽广社区内外部用户构建高可用零碎提供了思路。 分享主题：OpenSergo 微服务治理重磅反对 Go 生态在古代微服务架构中，针对简单微服务架构的稳定性治理是宽广开发者关注的重点，如何把微服务用好、用稳成为了关键问题。OpenSergo & Sentinel 开源负责人  ，赵奕豪（宿何）为大家整体介绍了OpenSergo 微服务治理场景、规范与生态，并重磅公布 OpenSergo Go 生态反对。 分享主题：Higress: 云原生趋势下 Ingress Controller 新抉择云原生时代，微服务在性能、高可用性和安全性方面面临着新的诉求和技术挑战。作为业内首个标准化、高集成、易扩大、热更新的云原生网关，Ingress Controller 开源新星 Higress 是如何解决这些问题的？阿里云高级开发工程师，Higress Maintainer ，凌轶群（井轶）为咱们带来了具体的解答，同时分享了 Higress 在集群入口流量治理上的最佳实际。 分享主题：云原生利用脚手架正式开源本次分享，云原生利用脚手架我的项目负责人， 陈曦（良名）发表了阿里巴巴云原生利用脚手架我的项目正式开源，并对脚手架的性能、定位以及近期的产品布局进行了介绍。 分享主题：Dubbo 开源现状的思考与将来布局自 Dubbo 开源以来，Dubbo 成为了国内微服务畛域最受欢迎的框架之一。Apache Dubbo PMC  ，江河清（远云）为大家介绍了 Dubbo 外围保护团队对于目前 Dubbo 开源的现状剖析、对策以及将来的整体规划。 ...

作者：董天欣（雾雾） Serverless 利用引擎（SAE）是一款底层基于 Kubernetes，实现了 Serverless 架构与微服务架构联合的云产品。作为一款一直迭代的云产品，在疾速倒退的过程中也遇到了许多挑战。如何在蓬勃发展的云原生时代中解决这些挑战，并进行牢靠疾速的云架构降级？SAE 团队和 KubeVela 社区针对这些挑战发展了严密单干，并给出了云原生下的开源可复制解决方案——KubeVela Workflow。 本文将具体介绍 SAE 应用 KubeVela Workflow 进行架构降级的解决方案，并对多个实际场景进行一一解读。 Serverless 时代下的挑战Serverless 利用引擎（SAE）是面向业务利用架构、微服务架构的一站式利用托管平台，是一款底层基于 Kubernetes，实现了 Serverless 架构与微服务架构联合的云产品。 如上架构图，SAE 的用户能够将多种不同类型的业务利用托管在 SAE 之上。而在 SAE 底层，则会通过 JAVA 业务层解决相干的业务逻辑，以及与 Kubernetes 资源进行交互。在最底层，则依附高可用，免运维，按需付费的弹性资源池。 在这个架构下，SAE 次要依靠其 JAVA 业务层为用户提供性能。这样的架构在帮忙用户一键式部署利用的同时，也带来了不少挑战。 在 Serverless 继续倒退的当下，SAE 次要遇到了三大挑战： SAE 外部的工程师在开发运维的过程中，存在着一些简单且非标准化的运维流程。如何自动化这些简单的操作，从而升高人力的耗费？随着业务倒退，SAE 的利用公布性能受到了大量用户的青眼。用户增长的同时也带来了效率的挑战，在面对大量用户高并发的场景下，如何优化已有的公布性能并晋升效率？在 Serverless 继续落地于企业的当下，各大厂商都在一直将产品体系 Serverless 化。在这样的浪潮下，SAE 应该如何在疾速对接外部 Serverless 能力，在上线新性能的同时，升高开发成本？纵观上述三个挑战，不难看出，SAE 须要某种编排引擎来降级公布性能，对接外部能力以及自动化运维操作。 而这个编排引擎须要满足以下条件来解决这些挑战： 高可扩大。对于这个编排引擎来说，流程中的节点须要具备高可扩展性，只有这样，能力将本来非标准化且简单的操作节点化，从而和编排引擎的流程控制能力联合在一起，施展出 1+1 > 2 的成果，从而升高人力的耗费。轻量高效。这种编排引擎必须高效，且生产可用。这样能力满足 SAE 在大规模用户场景下的高并发需要。强对接和流程控制能力。这个编排引擎须要可能疾速业务的原子性能，把本来串联上下游能力的胶水代码转换成编排引擎中的流程，从而升高开发成本。基于下面这些挑战和思考，SAE 和 KubeVela 社区进行了深度单干，并推出了 KubeVela Workflow 这个我的项目作为编排引擎。 为什么要用Kubevela Workflow？得益于云原生蓬勃的生态倒退，社区中曾经有许多成熟的工作流我的项目，如 Tekton，Argo 等。在阿里云外部，也有一些编排引擎的积淀。那么为什么要“新造一个轮子”，而不应用已有的技术呢？ ...

作者：赵海 引言事件总线 EventBridge 是阿里云提供的一款无服务器事件总线服务，反对阿里云服务、自定义利用、SaaS 利用以标准化、中心化的形式接入，并可能以标准化的 CloudEvents 1.0 协定在这些利用之间路由事件，帮忙您轻松构建松耦合、分布式的事件驱动架构。事件驱动架构是一种松耦合、分布式的驱动架构，收集到某利用产生的事件后实时对事件采取必要的解决后路由至上游零碎，无需期待零碎响应。应用事件总线 EventBridge 能够构建各种简略或简单的事件驱动架构，以标准化的 CloudEvents 1.0 协定连贯云产品和利用、利用和利用等。 目前 HTTP 的有余有以下几点： HTTP 的能力较弱，比方：受权形式繁多、只反对 Body 传参、网络互通能力未对齐。只能满足客户最简略的场景。用户无奈基于 API 来对立治理（批改/下线）Target，用户体验交叉口；对于基于 HTTP 实现的 SaaS API，无奈简略快捷的引入到 EB 中，作为 Target 给用户应用。本次新增集成核心（Integration Center）是负责 EventBridge 与外界零碎对接的模块，通过形象与配置疾速获取第三方事件并将事件集成到第三方零碎。并且优化现有 HTTP Sink 集成计划，为用户上游集成发明更多适配场景。 集成核心重点服务对象包含但不限于 SaaS 零碎，对标 IPaaS 平台的能力提供残缺的全面的通用系统集成计划。 集成源（Integration Source）：指集成到 EventBridge 的第三方源；API 端点（API Destination ）：指被集成到 EventBridge 的第三方 API 端点；<!----> 连贯配置（Connection）：是 API 端点模块的子集，与API 端点的平级资源，次要负责记录连贯及配置信息，连贯配置可被任意 API 端点复用。针对市场上其余云厂商服务，EventBridge 公布了 API 端点 Sink 能力，次要作用在于承接 EventBridge 上游端数据，帮忙用户疾速实现上游数据集成。提供简略且易于集成的三方事件推送 ，帮忙客户更加高效、便捷地实现业务上云。 API 端点 Sink 概述接入 EventBridge 利用有多种状况：用户自定义利用、阿里云服务、其余云厂商服务或者其余 DB 产品。 ...

作者：宇汇、壮怀 ACK One 概述ACK One 是阿里云面向混合云、多集群、分布式计算等场景推出的分布式云容器平台，可能对立治理阿里云上、边缘、部署在客户数据中心以及其余云上的 Kubernetes 集群，并简化集群治理界面。 通过 ACK One 多集群治理，能够关联并治理各种状态的 Kubernetes 集群，提供对立的集群管制面，实现多集群对立的利用散发，流量治理，运维治理，平安治理。 两大重磅个性，笼罩利用散发和运维治理，继续晋升多集群治理能力ACK One 利用散发 GitOpsGitOps概述 利用散发 GitOps 的外围是应用 Git 仓库来治理利用的部署模版，将利用继续部署到指定 Kubernetes 集群中，并以 Git 仓库作为利用部署的惟一起源，一直调整 Kubernetes 集群上利用状态，最终与 Git 仓库中的期待状态统一。 GitOps 的劣势： Git 易于被承受开发者承受，易于集成，无额定学习老本。Git 仓库作为利用部署的惟一起源，提供版本控制，疾速回滚和审计能力。安全性高，开发者应用 GitOps 不须要任何 Kubernetes 集群权限，只须要 Git 仓库权限。利用继续部署，Kubernetes 集群和 Git 仓库中的利用状态主动同步，保持一致。ArgoCD [ 1] 是 CNCF 开源我的项目，遵循申明式 GitOps 理念的继续交付工具，对接 Git 仓库和 Helm 仓库，提供功能强大的可视化页面。ArgoCD 作为控制器运行在 Kubernetes 集群中，继续监控利用的理论状态，并与 Git 仓库中申明的冀望状态放弃同步。 ACK One GitOps -- 多集群利用散发ACK One 多集群治理主控实例托管了开源 ArgoCD 实现利用的 GitOps 继续交付，同时集成 ACK One 多集群能力实现多集群的 GitOps 继续交付，满足利用的高可用部署，零碎组件多集群散发等需要。 ...

作者：赵慰 在 2022 云栖大会龙蜥峰会云原生专场上，来自爱奇艺的基础架构研究员赵慰分享了《基于龙蜥与 Koordinator 的在离线混部实际》技术演讲，以下为本次演讲内容： 爱奇艺离线业务混部背景 与泛滥互联网公司一样，爱奇艺常见的负载类型包含业务利用、数据库&中间件以及离线工作。其中业务利用包含有状态利用和无状态利用，无状态利用能够借助运维平台在业务团队和运维团队之间做比拟清晰的职责划分，适宜混部；而有状态利用较为简单，混部时的运行品质难以保障。数据库和缓存目前并没有运行在混部集群中。离线工作中的非实时性工作，比方夜间转码、数据处理等只关注吞吐量而不关注时效的工作也是混部的对象。 爱奇艺在混部上经验了长时间的摸索。 2013 年，爱奇艺首次进行了计算存储混部。进入容器时代后，爱奇艺在 Mesos 上破费了大量精力，最早把在线工作内容生产、 Spark、Storm 等所有工作负载混部在一个集群里，没有进行任何非凡的隔离性解决。在 Docker 上经验了窘境后，爱奇艺将业务按节点、集群进行了拆分；这又导致离线工作集群资源长年不够用，在线业务集群利用率非常低，尤其是夜间利用率甚至只有个位数。因而，爱奇艺思考将夜间线工作的资源提供给离线工作。 2016 年，通过 Mesos Oversubscription 性能引入依据实在资源做额定计数器的机制，将工作分为了提早敏感和尽力而为两类进行混部。但因为细粒度的隔离性问题，这条路线也无疾而终。 到了 K8s 阶段，因为在线业务的伸缩能力的加强和遍及，第二套计数器不再是强需要，爱奇艺间接在 K8s 上进行了混部，通过引入 Kata 保障服务质量。 2022 年，龙蜥 + Koordinator 一并被引入，用于构建下一步的混部架构。 从多年的混部教训里，爱奇艺总结出了影响混部的关键因素： 服务质量，尤其是在线业务的品质，脱离了服务质量则混部无意义。获取额定资源。工作适配。 获取额定资源存在有两个思路： 其一为应用一套计数器，按固定比例超卖资源，间接混用，或者按教训比例调配给各个类型的负载。 其二为多套资源计数器，一种形式是利用教训数据判断集群的闲暇工夫和闲暇资源，另一种形式是通过相似 Mesos Oversubscription 的形式做闲暇资源的实时探测。  服务质量的策略分为动态和动静。 动静指在离线业务或具体的过程之间动静进行调整，动态则是一旦下发即固定，即使有影响也不变动。 龙蜥和 Koordinator 在离线业务混部摸索 Koordinator 没有对散布架构做实质上的变动，而是在云原生的规范性方面，比方业务类型的形象上做了更多工作，使 K8s 和 Koordinator 有了做通用分布式架构的可能性，而不像之前只能针对特定的业务做定制。 Koordinator 能够简略了解为给 K8s 减少插件或做了加强，首先会减少一个调度器，引入一套资源技术，在节点上有一个 Koordlet，别离负责收集资源和保障工作的隔离性。 其工作机制为利用计数器在实在利用率根底上进行二次调配。整机的实在应用使用率取决于离线工作的使用率，保障在线业务的品质的前提下，水位线能够依据实际随时调整。 Koordinator 在任务分配方面分为五种类型（图中只列举了罕用的四种），通过不同层级的分类，对在线业务和离线业务进行了不同层级的保障。 为进一步保障服务质量，爱奇艺引入了龙蜥操作系统（Anolis OS）。Group Identity 性能和 CPU Burst 性能对以后的混部成果起到了很大的晋升作用。 ...

头：潘俊峰 前言微服务架构的呈现，拆分了宏大的单体利用，让业务之间的开发与合作变得更加灵便。当面临业务流量减少的场景时，往往须要对一些利用组件进行扩容。K8s 在利用层面提供了 HPA，围绕 HPA 开源社区延长出了 KEDA 这样的弹性组件，为微服务利用以业务指标执行弹性策略提供了实现的可能性。但 HPA 失常工作的一个大前提是须要保障集群资源短缺，为此用户必须提前对集群扩容或时常放弃集群资源冗余。 对于集群资源弹性这一命题，K8s 社区给出了Cluster Autoscaler（CA）和Virtual Kubelet（VK）两种解决方案。本文围绕着微服务利用的状态与特点，分析了 CA 与 VK 各自实用的场景，并总结了微服务架构下利用该如何抉择集群资源弹性。 微服务利用状态与特点在微服务利用架构，微服务架构将一个宏大的利用零碎拆分成了一个个离散的利用组件，这些组件通过 RPC 串在一起，对外提供残缺的服务。每个组件是离散的，大部分组件能够通过程度扩缩从而调整服务容量。非核心链路上的组件，是容许提早扩容或者不扩容，甚至是缩容让出资源。 微服务架构下在弹性场景存在五大特色点： 程度伸缩能够调整零碎容量： 在内部资源短缺的状况下，微服务利用组件程度扩容能够晋升业务零碎的容量。利用间存在依赖关系： 单个微服务利用并不能提供残缺的服务，扩容单个微服务组件，对系统容量的晋升十分无限，往往须要和依赖的服务一起扩容能力无效晋升零碎容量。利用自身是无状态的： 若微服务利用自身有状态，对于程度扩容是不利的，例如对磁盘有强依赖，在扩容场景下须要留神调度亲和性以打散 Pod，防止同类型利用在同一节点对磁盘 IO 抢占，同时缩容时还须要思考对于状态数据的解决。因而须要尽量革新成无状态利用。启动速度快且服务高低线流量无损： 服务高低线流量无损对于主动扩缩容场景至关重要，尤其是在大流量高并发场景下扩容，冷启动的新 Pod 很容易被大流量击溃，并且在衰弱探针的作用下，扩容出的新 Pod 一直被 K8s 重启，最终实现的是有效扩容。流量具备周期性： 绝大多数微服务架构利用面向的是在线服务，因而能够用二八定律来形容它，即 20% 的工夫解决了 80% 的流量。对于业务流量而言，最显著的特色是存在周期性的变动，且往往这个变动是疾速的，所以微服务利用容量扩缩的响应速度对于业务零碎的稳固起重要作用。在微服务利用架构中配置利用弹性时，咱们所须要思考的是抉择适合的指标来掂量零碎容量。在配置集群资源弹性时，咱们所须要思考的是扩容出的计算资源是否可能满足利用所需。 K8s 集群资源弹性技术计划如前言中所提及，K8s 社区给出了两份“标准答案”的框架，具体的资源弹性实现还依赖云厂商的技术状态与产品能力。 虚构节点：VKVirtual Kubelet 是依据 Kubelet 定义提出的一个“虚构节点”的概念，容许云厂商将云服务包装成一个“虚构节点”，退出到 Kubernetes 集群中。虚构节点的背地往往是云厂商的大资源池，因而实践上咱们能够认为虚构节点的资源是有限的，当然理论状况还要以云厂商的规模和产品能力来做判断。 节点伸缩：CACluster Autoscaler 是 K8s 社区给出的集群节点伸缩计划。CA 监听集群中所有 Pod 事件，当有 Pod 因为资源有余而无奈调度时，CA 会依据伸缩组信息进行模仿扩容并调度计算，最初依照预设的节点扩张策略进行实在节点扩容。同时 CA 监听集群整体资源利用率，当利用率低于预设的缩容阈值时，CA 进行模仿缩容调度计算，排除各种影响因素后，CA 对可缩容节点执行打污点、排水、删除这一系列操作。 各计划特点比对以 CA 技术状态为主的实在节点伸缩与以 VK 技术状态为主的虚构节点，这两种支流技术手段有着各自特点，其中最次要的区别如下： ...

作者：木环 来自世界六大洲的八强，正为大力神杯做最初的角逐。在精彩的较量之外，这届世界杯还留下了很多破圈元素：卡塔尔的两千亿、逗笑的饺子皮表情包、推延到夏季举办的赛事、围困啤酒赞助商的禁酒令。 以及，一个标杆我的项目，世界杯首个可拆卸足球场—— “974 足球场”。 起这样将来感十足的名字，是因为球场由 974 个可循环应用的航运集装箱组成，而 974 也正好是卡塔尔的国内电话区号。 整个球场由主体钢结构和模块化装卸的集装箱奇妙配合而成：球场为主体钢结构，观众席、卫生间和商店等都被安顿在一个个集装箱内，远远望去好似一座巨型积木。 图表 1：974 球场坐拥波斯湾 除了建造用料的不同凡响，974 的选址也很讲究。此届世界杯虽推延到夏季，可寒带沙漠气象的卡塔尔气温仍然达 30°C，因而卡塔尔为露天足球场都标配了室外空调；不过，绿色环保的 974 球场是个例外，它毗连哈马德机场的同时还坐拥波斯湾，独特“镂空式”构造令看台自然通风，实现了吹着海风看球。 有钱如卡塔尔，为何建造低成本的 974 球场？首先是天文条件无限，卡塔尔只有 1.15 万平方米，相当于天津市大小，而大部分土地又被沙漠笼罩。海运集装箱、并顺便近水楼台地建造在波斯湾，还可免去空调零碎，974 球场的选址堪称一举两得。 其次是人口少、享受不了这么多的足球场。首都多哈有着全国一半的人口、不到 100 万。国际足联要求承办国领有至多 8 座足球场、每座球场包容 4-8 万观众，即提供 32 万-64 万个观众席位。 此外，974 球场秉承低碳可回收利用的理念，球场的集装箱会在赛后装配并运往其余中央重装再应用。卡塔尔的天文和人口条件，并不“得天独厚”，甚至堪称“先天不足”。国内有观点谴责，卡塔尔并不该如此大费周折举办世界杯，然而卡塔尔情意已决，宣称会比所有往届更加环境友好，并承诺实现碳中和，尽量应用可回收、节能耐用的建筑材料以升高排放量。 图表 2：974 球场的钢结构和集装箱模块化装置 卡塔尔心愿模拟迪拜模式，解脱对化石能源的经济依赖，通过举办体育赛事等打造其国内知名度，并成为现代化的时尚旅游胜地。卡塔尔曾经踊跃操办几十次国内体育赛事，如 2006 年多哈亚运会和行将到来的 2023 年亚洲杯。在 2010 年博得世界杯承办资格后，卡塔尔称次日就发展各种筹备工作。 集装箱建造球场，还有省时省钱的益处，不过与上述劣势相比则显得沧海一粟。 每个 IT 公司都该思考建造集装箱“球场"举办这样一场熙熙攘攘的寰球盛事，对于如此袖珍国家，堪称是高并发需要了。世界杯完结、人流顶峰一过，将 974 集装箱足球场过剩的支撑力撤下来，还原成一片海边绿地。 这种业务场景就是 IT 软件架构中的弹性需要场景，能够采纳与航运集装箱同名容器技术（Container），其劣势也能够通过 974 球场一探到底。 麻利： 974 的集装箱外面安置好了座椅、厕所、商店等等， 而容器中则能够间接蕴含软件应用程序运行时和对应所需依赖，实现模块化加工和组装。 弹性： 同时，依据流量大小，即便调整容器数量多少，以缩小经营老本。一旦某个容器呈现问题，能够间接替换新的容器。 可移植： 如果须要，容器就像集装箱一样，可挪到其余的云资源服务器中疾速启用。974 球场的集装箱，也打算后续在其余中央再用，如 2030 年的南美乌拉圭世界杯。 ...

作者：柳下 背景介绍音讯队列服务（下文均以 Message Service 命名）作为云计算 PaaS 畛域的基础设施之一，其高并发、削峰填谷的个性愈发受到开发者关注。Message Service 对上承接音讯生产者服务的申请，对下连贯消费者服务。提到生产：那就不得不引入两个问题？ 如何以低成本、高吞吐、低延时的形式将音讯数据从 Message Service 输送给上游生产服务？如何疾速构建免运维、按需弹性伸缩算力的音讯生产服务？明天就来聊聊如何在阿里云上基于 Serverless 计算服务 + Message Service 构建这样一套零碎。 名词解释函数计算（Function Compute） 阿里云函数计算是事件驱动的全托管 Serverless 计算服务。通过函数计算，您无需治理服务器等基础设施，只需编写代码并上传。函数计算会为您筹备好计算资源，以弹性、牢靠的形式运行您的代码，更多产品细节可浏览官网文档 [ 1] 。 官网文档： https://help.aliyun.com/produ... 连接器（Connector） Connector 实现了大量数据的导入和导出。例如将 KAFKA topic 中数据导出到 stdout，或将本地文件中数据导入到 RocketMQ。Connector 简化了数据在不同零碎间复制和传输的复杂度，本文探讨的音讯服务和计算服务的连贯同样依赖 Connector 实现。 事件总线（EventBridge） 事件总线是 Connector 的产品化服务，反对阿里云服务、自定义利用、SaaS 利用等以标准化、中心化的形式接入，并可能以标准化协定在这些利用之间路由事件，帮忙您轻松构建松耦合、分布式的事件驱动架构，更多产品细节可浏览官网文档 [2 ] 。 官网文档： https://help.aliyun.com/produ... 架构演进传统的数据生产架构如下图左： 数据源将产生的数据写入到音讯零碎；开发者借助 Message Service 提供的 OpenAPI/SDK 或 Proxy 服务客户端从 Message Service 读取数据；依据音讯数据处理业务逻辑，也就是咱们所谓的生产音讯，将音讯生产的业务结写入到指标服务；如此架构开发者会面临以下几个问题： 如何并发平安的从 Message Service 读取数据？数据生产能力小于生产能力时，如何疾速晋升生产吞吐？指标服务资源成为瓶颈时，如何疾速扩容？当流量波峰过后，面对闲暇的机器老本，您又如何解决？如何保障生产实时性、程序性？如何实现容错、缓存、降级、限流等高可用爱护伎俩？如何监控链路状态或异样？...... 面对下面多个琐碎又简单的问题，置信总有几个会击中您的痛点。为了同时解决提到的所有问题，阿里云开发 Connector Service（如上图右）买通 Message Service 和 Serverless 计算服务的数据链路，您只需申明上游的音讯服务实例和上游的生产算子，便可一键部署上线，连接器同时提供了丰盛的流计算框架具备的数据处理能力和监控能力，总结如下： ...

作者：邓正威 背景概述什么是 PolarisPolaris 是腾讯开源的服务治理平台，致力于解决分布式和微服务架构中的服务治理、流量治理、配置管理、故障容错和可观测性问题，针对不同的技术栈和环境提供服务治理的规范计划和最佳实际。 什么是 dubbogodubbogo 是一款高性能 Go 语言微服务 RPC 框架，在 Dubbo 多语言生态中表演重要角色，是编写 Go 语言微服务的最佳抉择之一。开发者能够应用 dubbogo 框架高效地编写 RPC 服务，并反对与dubbogo  、gRPC 服务跨语言互通；并且 dubbogo 自身提供的丰盛服务治理个性，能够实现诸如服务发现、负载平衡、流量调度等服务治理诉求。 为什么要对接分布式和微服务架构中的服务治理、流量治理、配置管理、故障容错和可观测性问题，如何去解决、选用什么组件来解决、组件之间是否会存在抵触等等，置信曾经让不少开发者难以招架。在 dubbogo 用户中，须要解决这些微服务架构中的问题，通常都会部署以下组件 Nacos（Zookeeper）：解决服务治理、配置管理以及元数据管理Sentinel：解决流量治理、故障容错Prometheus、Skywalking：解决可观测性能够发现，要解决这些问题不得不部署多个组件，并且每个组件都有各自的管控平台，数据联动性差，难以有一个全局的视角让用户能够很好的治理微服务。 Polaris 是一反对多语言多框架的云原生服务治理平台，具备服务治理、流量治理、故障容错、配置管理和可观测性五大性能，用户不须要在为抉择什么组件而操心，间接在 Polaris 享受一站式服务治理平台所带来的便当。为此， Polaris 社区和 dubbogo 社区单干，将 Polaris 服务治理能力，与 dubbogo 框架相结合，便于 Go 利用开发者疾速低门槛的进行微服务开发。 如何对接 PolarisPolaris 有对立管制面和规范，数据面提供多语言sdk的实现给框架做集成。服务治理、流量治理、故障容错、配置管理和可观测性五大性能可间接通过 Polaris 的数据面间接接入，各个语言框架无需反复实现，对立了各个语言以及框架的服务治理能力。 因而，要实现 dubbo 与Polaris的集成，只须要应用 Polaris 提供的数据面 Polaris-Go SDK，通过 dubbogo 的 Extension 机制进行注入，无需额定进行服务治理逻辑的开发。 技术架构Polaris 通过实现 dubbogo 相干 Extension 插件，实现了性能的注入，用户只须要在配置中进行性能开启即可应用，无需进行代码革新。 从用户数据流的维度，当用户在 dubbogo 中启用 Polaris 的服务治理能力后，业务流量理论解决流程如下： ...

作者：李鹏（元毅） “应用阿里云弹性预测 AHPA，升高了 K8s 容器老本，同时加重了运维工作量，减速了业务容器化的过程。”—— 朱晏(厨芯科技VP) 背景厨芯科技，是寰球当先的餐饮设施和服务提供商。从一台智能洗碗机开始，致力于扭转餐厅后厨基础设施，驱动餐饮行业的智能化和自动化。 遇到的问题厨芯科技一年前将业务零碎从 ECS VM 迁徙至 K8s 集群，尽管进步了微服务运维效率，但因为 ECI 容器单位成本高于 ECS，如何充分发挥 K8s 的资源弹性，就成为降低成本的次要问题。 次要有两个业务场景存在优化空间： 场景一： Web 服务每天有早、晚顶峰和夜间低谷。最后应用 CronHPA 设置各个时间段的容器数，再用 HPA 应答业务顶峰的部分扩容，有肯定的优化成果。然而，CronHPA 设置的时间段越多，运维老本越高，并且不够灵便；指标容器数的配置也比拟艰难，太少则无奈保障应答业务顶峰，太多又起不到优化老本的成果，须要重复尝试进行调整。而 HPA 扩容总是滞后于负载变动，会引入一些不必要的容器创立删除，导致资源节约。 场景二： 定时工作有绝对固定的周期性。对于15-30分钟的周期，CronHPA 的配置显然太过简单，HPA 也因为滞后性无奈发挥作用。 解决方案通过充沛沟通，在对厨芯科技业务的利用场景和需要有了深刻了解后，举荐了阿里云容器服务弹性预测 AHPA 解决方案。 阿里云容器服务 AHPA（Advanced Horizontal Pod Autoscaler）能够依据业务历史指标，自动识别弹性周期并对容量进行预测，解决弹性滞后的问题。通过被动预测和被动预测相结合，实时调整资源实例数。被动预测基于利用实时指标计算 Pod 数量，能够很好的应答突发流量; 被动预测基于历史指标通过达摩院机器学习算法提前预测出将来 24 小时利用的实例数量。此外，AHPA 还减少了兜底爱护策略，能够设置工夫区间的实例数上下界值实现弹性兜底。 极致弹性 降本增效厨芯科技已在几个次要服务 ACK 集群上启用了AHPA。通过验证，相比于 CronHPA+HPA 的优化计划，AHPA 的被动预测模式额定升高了10%的 ECI 容器老本。同时，AHPA 主动计算负载曲线、设定指标容器数等特点，代替了人工运维的工作量，减速了业务容器化的过程。 对于 AHPAAHPA（Advanced Horizontal Pod Autoscaler） 是阿里云容器服务 ACK 与达摩院单干推出的容器智能弹性预测产品，能够依据业务历史指标，自动识别弹性周期并对容量进行预测，帮您提前进行弹性布局，解决弹性滞后的问题。 具体介绍请见:  ...

作者：KubeVele 社区 为了营造良好的开源气氛，为我国开源产业倒退注入更多生机，中国开源云联盟(China Open Source Cloud League，简称“COSCL”) 组织发展了 2022 年度评选活动。并在明天的 2022 木兰峰会中颁布了评比后果。 2022 木兰峰会：https://ke.segmentfault.com/c...中国开源云联盟（COSCL）成立于 2012 年 8 月，在工业和信息化部信息化和软件服务业司领导下，挂靠在中国电子技术标准化研究院，现有我国 180 余家开源生态圈产、学、研、用成员单位。中国开源云联盟（COSCL）作为国家重点研发打算《云计算和大数据开源社区生态系统》我的项目的指定开源组织，致力于联合国内开源产业界相干方，在中国独特推动开源生态系统搭建、技术社区建设、开源我的项目培养、开源个人规范研制、开源技术推广应用、以及开源人才培养等工作，是国内支流沉闷的开源技术组织之一。 KubeVela 作为现代化的软件交付平台，云原生时代的“Spring 框架”，在本次评选活动中，荣获“优良开源我的项目” ，成为评比出的十三个年度优良我的项目之一。 感激中国开源云联盟作为主办方，举办了年度评选活动，联结产业各方独特探讨开源产业倒退方向和将来时机，推动我国开源产业的高质量倒退。 KubeVela 我的项目于 2020 年 11 月在社区发动，通过灵便的可扩展性将云原生技术组件和企业级利用连贯在一起，提供跨集群的对立编排、基础设施无关、灵便的利用交付工作流等外围个性，受到社区用户宽泛的青睐。2021 年 6 月捐献给 CNCF 后始终位列 CNCF 寰球 TOP 级沉闷我的项目。目前在 GitHub 上领有 4500+ 的 Star，正在筹备进入 CNCF Incubation。至今已被阿里巴巴、招商银行、字节跳动、现实汽车、Napptive、Shein 在内的 300 多家海内外企业采纳。 KubeVela 现在的倒退和成就离不开社区来自十多个国家 300 多名贡献者的提交，以及合作伙伴的一直输出。感激社区中的所有贡献者，以及来自阿里巴巴、招商银行、Napptive、Guidewire Software、京东云、挪动云、亚信科技、谐云等公司的外围维护者继续投入！ 结语您能够通过如下资料理解更多对于 KubeVela 以及 OAM 我的项目的细节： 我的项目代码库： github.com/oam-dev/kubevela 欢送 Star/Watch/Fork！我的项目官方主页与文档：kubevela.io 从 1.1 版本开始，已提供中文、英文文档，更多语言文档欢送开发者进行翻译。我的项目钉钉群：23310022；Slack：CNCF #kubevela Channel退出微信群：请先增加以下 maintainer 微信号，表明进入KubeVela用户群： ...

作者： 屿山 微服务作为云原生时代下一种开发软件的架构和组织办法，通过将明确定义的性能分成更小的服务，并让每个服务独立迭代，减少了应用程序的灵活性，容许开发者依据须要更轻松地更改局部应用程序。同时每个微服务能够由独自的团队进行治理，应用适当的语言编写，并依据须要进行独立扩缩容。但微服务同样也并非“银弹”，在带来如此多的劣势的同时，逐步收缩的微服务数量也为零碎带来了空前的复杂度，服务之间盘根错节的调用、协作关系如同一层迷雾笼罩在零碎之上，借助 Trace、Log、Metric 三驾马车咱们的零碎具备了肯定的可观测性，但所能失去信息是标准化且固定的，往往不可能满足简单场景下的观测需要，比方微服务引擎 MSE（Microservices Engine）中的微服务治理功能模块为用户用好微服务提供了诸多帮忙，但其中的很多性能，比方全链路灰度、无损高低线等会波及多个利用，且所波及的信息又不被规范的可观测零碎笼罩。而微服务洞察通过动静的信息采集可能填补这其中的一部分空缺，更好地满足这些微服务场景的观测需要，同时也将他们纳入到规范的观测体系中来。 微服务洞察构想这样一个问题现场，线上零碎呈现了一个奇怪的问题，某一个接口偶现谬误，频率不高，呈现工夫毫无法则，然而没有发现任何无效的谬误日志。这时，在通常的实际中，除非具备脑内 debug 的神力，不然咱们往往须要在代码中减少日志逻辑，而后重启利用，静静期待问题复现后查问日志，如果定位了问题范畴须要更多的信息，就须要咱们一直循环 编写日志逻辑->重启利用->静静期待 的步骤直到解决 bug。但这还不是最令人头疼的，如果给这个问题加上问题触发随同利用重启、pod 内日志失落、重启后问题无奈复现等 debuff，排查的难度将会进一步回升。 而因为微服务洞察具备任意地位类粒度的动静信息采集的外围能力，可能帮忙咱们解决上述场景中的一些痛点。首先在第一次发现这个问题后，咱们能够间接在线上环境中通过配置一条微服务洞察的规定，来收集一些初步信息来帮忙咱们判断可能的问题起因。因为收集的信息会以调用链的模式组织，咱们能够从中获取问题呈现的频率、工夫、参数散布、上下游调用信息等。同时因为信息会间接上报并集中存储到远端零碎，因而不受利用重启的影响，咱们也不须要一台一台实例去查问日志。 在对问题有了初步的判断之后，咱们往往可能将问题定位到一个范畴之内，这时咱们能够进一步锁定某些办法，通过配置规定，打印它们的入参、返回值、调用堆栈等信息来判断其执行是否合乎预期。 通过上述的举例能够发现，借助微服务洞察的能力，咱们可能轻松地探知规范的可观测零碎难以触达的角落，从而满足咱们对一些微服务场景的观测需要。 洞察微服务场景无损下线无损下线是微服务治理中的一个性能，次要是为了解决在公布过程中的微服务在下线的过程中可能存在的流量损失。其大抵流程如下图所示。 通过一系列的策略和措施，可能做到服务的齐全无损下线。但这样就导致无损下线的流程比较复杂，同时还波及到多个节点之间的告诉机制，特地是在大规模之下，下线流程的完整性以及可靠性的确认变得非常复杂与繁琐。这就是前文所提到的难以触达的角落，咱们能够通过微服务洞察的能力帮忙咱们观测这个场景。 针对无损下线的场景，微服务洞察提供了场景化的规定，简略配置一键开启。 在开启了规定之后，微服务洞察会收集无损下线流程中值得关怀的信息，组织成调用链的模式展现。如下图场景，咱们对 108 节点进行缩容操作，咱们就能够失去一条 Tracing 链路，其中蕴含被动告诉、服务登记、利用进行等几个步骤，并且咱们能够在每个步骤中看到所需的信息。 在被动告诉环节咱们能够看到以后 Provider 节点对哪些 Consumer 进行 GoAway 申请的调用，如下图所示咱们将被动告诉 10.0.0.90、10.0.0.176 两个 Consumer 节点。 当 Consumer 收到 GoAway 调用后，会进行负载平衡列表的刷新以及路由的隔离，咱们将在负载平衡地址列表中显示最新抓到的以后 Consumer 对于以后服务缓存的最新地址列表，咱们能够在下图中看到，地址列表中只剩下 10.0.0.204 这个服务提供者节点的调用地址。 咱们也能够看到 Spring Cloud 向 Nacos（注册核心）执行服务下线的调用后果，登记胜利。 微服务洞察通过将无损下线的 workflow 形象成 Tracing 构造的策略，能够帮忙咱们升高大规模场景、简单链路下无损下线问题的排查老本。 全链路灰度全链路灰度是微服务治理中的另一个性能。有时某个性能发版依赖多个服务同时降级上线，咱们心愿能够对这些服务的新版本同时进行小流量灰度验证，这就是微服务架构中特有的全链路灰度场景，通过构建从网关到整个后端服务的环境隔离来对多个不同版本的服务进行灰度验证。在公布过程中，咱们只需部署服务的灰度版本，流量在调用链路上流转时，由流经的网关、各个中间件以及各个微服务来辨认灰度流量，并动静转发至对应服务的灰度版本。如下图： 而在应用该能力的时候，要想探清流量的匹配状况以及流量的走向具备较大的难度。而借助微服务洞察的能力能够帮忙咱们便捷地感知这些信息。 ...

写评测拿好礼，Serverless 评测局邀您参加 SAE 征文活动！ 2022年11月25日-2023年1月25日期间，通过体验 Serverless 利用引擎 SAE 产品，公布评测文章并通过审核，百分百可得阿里云 10 元通用代金券+50 积分社区处分，入选优良征文还有机会赢取价值 8300元 的 SAE 专业版季包、更有 CHERRY 机械键盘、Serverless 卫衣、30元 猫超卡等精爱好礼等你来拿！速速理解 https://developer.aliyun.com/... 产品介绍Serverless 利用引擎 SAE（Serverless App Engine）是一个全托管、免运维、高弹性的通用 PaaS 平台。SAE 反对 Spring Cloud、Spring Boot、Dubbo、HSF、Web 利用和 XXL-JOB、ElasticJob 工作的全托管，零革新迁徙、无门槛容器化、并提供了开源侧诸多加强能力和企业级高级个性。 评测要求1、流动工夫： 2022年11月25日-2023年1月25日 2、参加形式： 申领免费资源额度-->场景体验-->发表原创评测-->提交-->审核通过-->参加评比/支付福利 流动地址： https://developer.aliyun.com/... 3、评测内容：通过体验 Serverless 利用引擎 SAE 产品，您的测评能够抉择以下三大主题其中一个进行创作： 1、SAE 利用场景测评，能够包含但不限于以下内容： （1）SAE 的微服务利用托管能力是否匹配您的业务，在应用上有什么长处或者有余？（比方：零门槛迁徙、注册配置、灰度公布、利用监控等） （2）SAE 的多语言反对能力是否匹配您的业务，在应用上有什么长处或者有余？ （3）SAE 的弹性和免运维个性，给您或公司带来的老本、收益如何？ （4）SAE 的继续集成与交付能力是否匹配您的业务，在应用上有什么长处或者有余？（比方：DevOps 自动化、一键部署到云端、CI/CD 等） （5）SAE 的 Job 定时工作托管能力是否匹配您的业务，在应用上有什么长处或者有余？（比方：定时工作、一次性工作、批处理数据、异步执行解耦、XXL-JOB 迁徙等） 2、SAE 服务体验评测，能够包含但不限于以下内容： （1）在体验过程中，您是否能从 SAE 帮忙文档中取得足够的指引？如果没有的话，联合您对于本文档或其余产品文档的应用体验，您还有哪些期待，例如文档正确性、及时性、易用性、丰富性等？ ...

作者：卜比 全链路灰度是微服务畛域，很实用的企业级场景下的技术能力。 从本期开始，咱们将通过《全链路灰度：自顶向下的办法》的系列文章，由远及近的分析全链路灰度全貌，系列文章分为 4 篇： 《从三万英尺看全链路灰度》：介绍微服务的根底概念、支流的部署模式。 《从三千英尺看全链路灰度》：介绍全链路灰度和波及的组件，以及如何组装成全链路灰度的能力。 《从三百英尺看全链路灰度》：从技术细节动手，分享如何实现路由能力和灰度能力。 《总结篇》：总结全链路灰度，目标是更加高效反对好业务同学，进一步保障线上稳定性。 微服务架构的劣势划分微服务层次结构，拆分复杂度在微服务架构呈现之前，更多的业务采纳的是单体架构。单体架构在简单业务场景下，每一个开发人员都无奈精确的评估复杂度：每一个批改都须要遍历代码库，确定这个批改不会影响其余性能。 在微服务架构呈现后，通过 RPC、音讯队列等技术，咱们能够很好的划分出微服务体系结构（microservices hierarchy）：架构师关注业务逻辑；业务开发者关注微服务内的业务自洽；中间件开发者关注基础设施的高效和稳固。拆散、拆分了复杂度。 高内聚低耦合，让业务更加聚焦在单体架构中，代码的模块化个别是通过 package、namespace 等语言个性来实现的，但这种模块化的实现，会有各种各样的问题： package、namespace 等个性是语言相干的，如果呈现跨语言的状况，须要从新组织代码构造模块化划分没有规范。以 Java 为例，是以 controller、service 等组件类型来划分 package？还是以各个业务域来划分 package？package 划分短少强制工具。即便咱们定了划分规范，但 package 仍不能强制限定模块化，业务同学写出了跨模块的调用，依然能通过测试、上线。面对上述问题，亚马逊提出了 API-first、FaceBook 开源了 Thrift、Google 开源了 gRPC，帮忙开源社区构建了微服务基础设施。 限度不好的架构设计，让代码可能无累赘进化在单体架构时代，常常遇到一些比拟难看的设计，然而改变这些代码，总是会遇到兼容性问题，不能彻底移除。 拆分成微服务后，每个微服务都能够有本人的开发语言、设计模式，即便呈现了设计问题，咱们也可能将这些蹩脚的设计限定在每个服务外部，阻止了架构的腐化和失控。 微服务的根底概念 微服务生态图 下面这张图很好的展现了微服务体系下，咱们须要依赖的基础设施以及相干开源我的项目，上面咱们分模块简要介绍下： 微服务之间要可能相互发现、相互调用，就须要注册核心。微服务的部署须要标准化，不便迁徙、扩缩容，业界比拟风行的部署模式有 Kubernetes。微服务的问题排查、监控等，须要可观测组件。微服务体系须要引入内部流量、鉴权等，须要微服务网关。微服务的数据存储，依据存取的形式、老本不同，能够应用 MySQL 或者 Redis 等。须要实现全链路灰度、API 治理等微服务治理性能，就须要治理核心。微服务的拆分技术层面上，微服务的拆分，通常能够依照业务模块、业务场景等进行拆分，尽量确保服务逻辑自洽、对外其余比拟少，做到高内聚低耦合。严密关联的业务逻辑，放在一个微服务内，防止在服务与服务之间共享数据。 从组织构造层面上，微服务解决的基本问题是团队分工问题，详见康威定律，这是大型软件倒退的必然，不因为人的爱好而扭转。当你读懂康威定律，就会发现“服务拆分粒度难以精确把握”基本不是实质问题。 你有几个 2 pizza 团队，最好就拆成几个微服务。举一个事实的例子：只有一个开发人员时，尽量就做单体利用，不要没事找刺激拆成 10 个微服务，最终这个开发人员还会把他合成一个。微服务要求纵向的 2 pizza 团队（无数个小团队，蕴含开发、测试、运维），当然咱们也施行过一些传统大型企业，但团队还是处在横向构造的场景下（开发、运维、测试各是一个团队），拆分微服务让他们很苦楚，尤其是运维团队。 微服务的部署从大体上来看，微服务至多须要部署在线上和测试环境。但须要留神的是，开发口中的环境和此处的环境会很容易混同，所以咱们借用 K8s 命名空间的概念，应用命名空间来避免混同。 在线上命名空间中，咱们可能保障代码都是通过 review 的、数据库都是线上数据。线上的利用版本，个别分为 prod（生产版本）、gray（灰度版本，少部分线上流量进入）、pre（预发版本，仅内部人员可用）。 在测试命名空间中，测试同学和开发同学发动流量进行测试和开发。在测试环境中，个别每个利用都部署了 stable 版本，提供一个稳固的测试环境；依据我的项目、开发流程的不同，相干的利用也会部署一些 project1 版本等。 另外，对于注册核心、Kubernetes 集群、音讯队列等根底组件，也该当在不同的部署环境中独自部署一套。比方线上命名空间中的注册核心，和测试命名空间中的注册核心，该当离开部署，做到硬性隔离。 ...

作者： 颍川 引言微软 Windows 是以后支流操作系统之一，在桌面和服务端均有较大市场份额。 对于 Linux 操作系统，Prometheus 能够通过 Node Exporter 来进行根底资源（CPU、内存、磁盘、网络等）监控，相似地，对于 Windows 操作系统，咱们也须要对这个 OS 环境下的根底资源进行 Prometheus 监控。 Windows 简介Windows 是美国微软公司以图形用户界面为根底研发的操作系统。目前罕用的版本 Windows Server 2008R2 和 Desktop Windows 7 及以上。因为 Windows 已广为大家所相熟，本文不再赘述其性能和特点。 Windows Metric 监控参考模型咱们从指标采集、监控大盘、告警规定等 3 方面定义了 Windows Metric 监控的参考模型，以便实现监控闭环。 指标采集Windows 根底监控指标次要蕴含 CPU、内存、磁盘、网络和过程等四方面。上面别离介绍各方面的次要指标。 CPU 指标CPU 是计算机的大脑，作为计算机系统的运算和管制外围，是信息处理、程序运行的最终执行单元。咱们倡议关注如下次要指标。 内存指标内存是用于暂存 CPU 中的运算数据，以及与硬盘等内部存储器替换的数据。它是磁盘与 CPU 进行沟通的桥梁，计算机中所有程序的运行都在内存中进行，内存性能的强弱影响计算机整体施展的程度。咱们倡议关注如下次要指标。 磁盘指标艰深来讲，咱们所说的磁盘是计算机内部存储设备的总称，当初常见的有传统硬盘 HDD [5 ] 、混合硬盘 HHD [6 ] 和固态硬盘 SSD *[7 ] *。咱们倡议关注如下次要指标。 网络指标计算机网络是计算机之间进行实时互通的渠道。目前通常是基于 TCP/IP 协定构建的。咱们倡议关注如下次要指标。 ...

云原生技术和数字化转型是相互促进的，并且云原生技术能够减速和推动数字化转型 。 据 Gartner 预测，到 2025 年寰球将有 85% 的企业会在生产中应用容器。相比于 2021 年低于 40% 的比例，将会是一个微小的增长。云原生技术为开发高效、可扩大且牢靠的软件，晋升企业研发能力开拓了路线。这就意味着，云原生技术带来的资源弹性等劣势天生实用于将来软件的倒退，企业对云原生技术及理念的刚性需要将进一步开释。 数字化转型的蓬勃发展给云计算带来微小的机会，云原生作为云的服务新界面，进入疾速倒退阶段，全面应用云原生落地零碎架构的时代曾经到来。作为开释云计算技术红利的新形式，云原生架构通过联合企业本身业务的特点，从办法和实践、工具集、技术最佳实际角度登程，重塑和降级整个企业架构，助力企业的数字化转型。 随同着数字经济的一直倒退，数字化落地场景不断丰富，实用于各行业的云原生解决方案与产品也出现井喷式暴发，为利用的数字化和智能化带来了更多可选项。对于企业来说，须要真正从场景登程，通过实际测验的云原生落地方法论和教训复制。基于此，阿里云联结 Intel 发动第三届云原生实战峰会，聚焦容器、中间件、可观测、Serverless 畛域最新进展，邀请高德地图、中免日上、爱福路、华泰证券、埃森哲等企业技术负责人分享云原生实战经验和趋势洞察，给更多企业提供参考。 工夫： 2022 年 12 月 28 日（周三） 14：00-17：30** 点击此处或扫描下图二维码 ，立即预约直播！

作者：么敬国（新东方教育科技团体云教室直播平台技术负责人），灏正（ 阿里云 Serverless 架构师） 新东方教育科技团体定位于以学生全面成长为外围，以科技为驱动力的综合性教育团体。新东方线上教育业务的云教室零碎反对了视频直播、转码、点播等新东方所有在线教育场景。随着业务量的增大，因为直播转录及视频转码工作解决平台具备显著的波峰波谷个性，自建机房较低的资源利用率成为了业务的外围痛点。为了晋升计算资源利用率，进一步实现降本提效指标，在几次尝试之后，新东方踏上了 Serverless 实际之路。以下内容是由新东方教育科技团体云教室直播平台技术负责人 么敬国 在云栖大会的分享。 如何应答难以预测的业务量？新东方除了本人的线上教育业务应用云教室平台以外，还通过美刻云直播对外开放了新东方的直播能力。云教室直播平台次要反对四种业务模式: 云教室：在线直播互动课，考究互动性。云点播：录播课。云直播：大型直播，以主播为主。智慧教室：软硬件联合的计划，提供相似于双师的教育模式。直播+录播是新东方主推的课程交付模式。直播课程互动性强，能够实现良好的课堂互动，激发学生的学习趣味；老师能够基于学生的课堂反馈或互动间接与学生进行互评，便于老师及时对教学环境作出微调，从而让教学过程更有针对性；通过互动和课堂答疑，能够让教学过程和成果更有保障，直播课程比拟适宜低幼年龄段的学生。 而面对高中及高中以上年龄段的学生，录播课更为适合，录播课特点为学习工夫灵便，学生能够自主对学习内容进行检索，进行有选择性的学习，个别实用于高中和高中以上年龄段学生。录播课的长处在于能够对授课内容一直进行打磨、编辑，制作精品课程，需求量逐渐加大。 最后团队采纳地录制技术计划为客户端录屏，将老师的直播进行录制，不便学生重复观看，但这样的形式出错率高， CPU 占用率也较高，无奈对录制 UI 布局进行灵便定制，只能是看到什么录什么，这样的形式仅能满足低幼年龄段的课程需要。 往年，新东方开始对接大学生线上教育业务，对录播课程的品质提出了更高的要求。团队开始思考采纳服务端录制的形式解决问题。服务端录制的两个外围点在于直播录制和视频标准化生产。咱们的业务模式决定了咱们很难精确预测业务量，因而，新东方要害的技术工作是实现计算弹性 。 三种抉择，函数计算怀才不遇三种抉择，函数计算怀才不遇要解决服务端录制的问题，摆在团队背后的有三个可选的技术路线： 间接应用 ECS 自建，该计划的劣势是灵活性比拟高，但问题在于计算没有弹性，尽管云厂商提供了弹性调配 ECS 资源 API ，然而本人实现整个计算弹性须要微小的开发量，同时后续运维比较复杂，资源老本高，难以做到标准化。云录屏 SaaS 计划，这个计划的劣势是具备标准化的服务，研发投入比拟少，运维工作也较少，然而问题在于灵活性差，资源老本极高，难以进行进一步的性能优化。咱们心愿寻找一家成熟的 SaaS 厂商提供地服务以疾速反对业务，然而通过试用，这些平台的成熟度和技术指标等均无奈满足咱们的需要。采纳阿里云函数计算 FC，咱们发现阿里云的函数计算产品能够完满满足计算的弹性需要，只须要关注具体需要在平台上做开发即可，研发投入小同时免运维，开发过程自主可控，灵活性高，可按需应用极大升高了应用老本，实现标准化绝对容易。不过函数计算是一个比拟新的技术，团队须要一段时间来相熟。通过重复比对，新东方团队抉择应用函数计算来解决服务端录制问题。 新东方的 Serverless 实际录播转码，函数计算小试牛刀咱们首先在录播转码场景下进行了尝试。录播转码的外围诉求是对直播流进行实时转码，保留为规范的视频格式，不便后续加工应用。 在这个场景中，咱们第一次感触到了函数计算 FC 带来的弹性劣势。在老师进入房间发动转码申请后，可疾速启动函数实例进行转码。在上课完结后，完结转码工作，将长期音视频后果上传至云存储后即可立刻开释函数实例，不会存在任何计算资源的节约。有了在录播转码我的项目中利用函数计算的教训当前，咱们对函数计算计划有了更大的信念。 初露锋芒，函数计算直播合流转码计划之后，咱们启动了云端录制我的项目。应用 Chrome 浏览器退出直播房间，对浏览器界面进行截屏录制，该计划的关键在于弹性提供浏览器实例。 因而，咱们利用阿里云函数计算启动 Linux 容器，在 Linux 容器运行 Chrome 浏览器实现弹性提供浏览器实例。整个的录制流程是这样的：老师进入教室当前，开始进行音视频推流以及白板操作。同时，录制平台发动录制申请，启动函数解决，开始接管教室的音视频流和白板操作，并在浏览器展示整个教室的画面，同时做截屏。课程完结后，平台发动完结录制申请，函数计算平台会优雅地终止实例。终止之前，实例会将长期后果上传至云存储，随后函数实例被销毁，不存在任何资源节约。 开箱即用的可观测能力咱们认为，可观测能力对于函数计算平台至关重要。首先，业务高峰期须要启动大量函数实例，因而，必须要残缺的 metrics、log 和 trace 能力无效对海量实例进行监控。其次，因为函数计算实例按需创立，实现工作之后被销毁，平台必须保留残缺的日志，以便发现问题后开发人员进行排错。 咱们曾在开发录制服务的过程中面临的问题是：启动函数实例当前，Chrome 浏览器要拜访直播服务，此时网络呈现问题，导致录制失败。后续咱们应用阿里云 SLS 日志平台查看日志，发现 Chrome 浏览器内核对网络解决过于敏感。找出问题后，隔靴搔痒，退出了重试机制，问题得以解决。 超出预期，函数计算带来更多惊喜在应用函数计算技术之前，咱们冀望它能通过百毫秒拉起上万个实例，定时预热彻底解决冷启动艰难，帮忙咱们承载直播转码和录屏业务业务洪峰。有效应对大规模突发在线流量，按量付费，进步资源利用率，缩小 20% 资源老本开销，极大水平升高运维老本，让咱们能够只专一业务翻新。在理论应用的过程中，咱们发现函数计算岂但可能中咱们完满满足咱们的需要，还带来了惊喜：让咱们的开发人员只需把握几个新概念、应用几个 API ，即可轻松应用平台。 函数计算计划运行一段时间以来，云资源费用失去较大升高。另外，函数计算容许依据本人的业务场景制作模板，并且可供其余业务方应用，也为咱们带来意外播种。 点击此处，查看新东方残缺视频讲说！

作者：灵轮（阿里云前端技术专家） 作为前端工程师，咱们的使命是为用户提供良好的前端用户体验。随着云原生时代的到来，不言而喻的，咱们能做的更多了。Serverless产品的特点是免运维、按量付费和自适应弹性，所以咱们能够利用云上的各种 Serverless 能力，用绝对更低的老本开发出更酷的产品，为咱们的客户发明更多价值。 如何构建云原生现代化的 Web 利用？让咱们先回顾一下，咱们是如何把一个动态网站公布进来的。在云原生时代之前，咱们想到的可能是须要先找一台服务器，装置 Nginx，而后上传动态文件，再通过一系列的配置，最终实现网站的公布。实现这些当前，发现曾经花掉了小半天的工夫，实际上这些花在运维下面的工夫其实并没有为咱们的客户发明价值。但这其实还只是一个开始，随着业务的倒退，稳定性、弹性、平安和老本等问题，咱们都要逐个解决，咱们花在运维上的工夫和精力会越来越多。否则，这个网站可能只是一个玩具。 然而随着云原生时代的到来，公布动态网站简略了很多，咱们能够通过云产品，轻松地托管咱们的网站。例如，能够将网站通过阿里云对象存储 OSS 提供的工具，将动态资源上传到 OSS，而后开启一键托管。此外，为了让客户可能更快地关上页面，还能够通过阿里云 CDN，将 OSS 设置为 CDN 的源站，从而让动态资源离客户更近，让客户的应用体验更好。这两款产品都是按量付费的免运维 Serverless 产品，它们大大地缩小了咱们各种繁冗的运维老本。咱们能够把更多的工夫花在研发和体验上，为咱们的客户发明更多价值。 然而随着业务的倒退，咱们的网站如果并不只是一个动态网站了呢？对外服务的 API（须要对接缓存，数据库，音讯队列，文件存储等）定时执行工作，甚至是执行海量工作发送电子邮件/短信/即时消息（钉钉，微信，飞书），拨打智能语音电话对用户上传的图片，音视频等进行解决（转码，缩略图，鉴黄，加水印，GPU 推理）服务端渲染 SSR 页面大促，秒杀采集用户在网站上的行为，剖析如何进步用户的转化率面对这些需要，难道咱们又要去找服务器？为了保障服务的稳定性，弹性，平安和老本，难道咱们又要把大量的工夫花在运维上？有没有云产品能够像 OSS/CDN 解决动态网站的运维问题一样，解决咱们的这些后端需要呢？ 面对这些挑战，阿里云的 Serverless 产品函数计算 FC 是一个不错的抉择。除了通过函数计算 FC 解决 API 申请和大规模工作之外，还能够在函数计算 FC 中拜访阿里云的 RDS、SLS、Tablestore、NAS 等丰盛的云服务或者是其余第三方服务，从而满足对存储，计算，网络，平安，大数据，人工智能等各种业务的需要。 各种 Serverless 云产品就像是前端工程师的“武器库”，咱们能够应用这些云产品来为咱们的客户提供高质量的服务。 函数计算 FC 的劣势和相干原理介绍极致弹性，轻松应答流量洪峰函数计算 FC 会依据申请量主动进行毫秒级弹性扩容，疾速调度计算资源。从而使咱们能够轻松应答海量 API 申请和大规模的并发工作。 在应用函数计算时，能够为函数配置一个“实例并发度”，这个并发度代表一个函数实例最多能够同时解决多少个申请。函数实例实质上是一个 Linux 平安容器，它是函数对外提供服务的最小单元。 例如，在“实例并发度”设置为 20 时，如果函数计算平台同时收到了 100 个申请，则会拉起 5 个函数实例来解决这些申请。解决完这些申请后函数实例会被解冻，如果在接下来的 2～5 分钟内（实例解冻当前就不再计费了）如果没有新的申请，函数实例将被主动销毁。在某些场景下，如果业务对提早十分敏感，或者业务代码启动很慢，能够通过配置弹性规定，设置最小函数实例数量，这样函数计算 FC 会事后启动好函数实例，从而保障用户的应用体验。也能够通过设置函数实例的最大数量，限度函数实例的最大数量，从而爱护上游服务，并管制老本。 比照传统服务器模式下须要本人进行服务器的扩容缩容的操作，函数计算 FC 这种主动弹性的形式不仅能够缩小此类繁锁的扩缩容运维操作，也能够防止传统服务器模式下因为扩容不及时导致的业务不可用，从而进步零碎的稳定性。 降低成本，进步资源利用率函数计算 FC 中能够自在配置 CPU，内存，GPU 等实例的规格。最小能够创立 0.05 核，128 MB 的函数，并提供了极小梯度的规格抉择，根本能够做到利用须要什么规格就配置什么规格。 ...

阿里云是国内最早提供 Serverless 计算服务的云厂商。2017 年推出的函数计算 FC 是一款 FaaS 产品，这是一种以事件驱动为外围的全托管计算服务，用户只需编写代码并上传，函数计算就会主动筹备好计算资源，以弹性、牢靠的形式运行代码，并提供残缺的可观测能力，大幅简化开发运维过程。 新课上线：函数计算让研发效力再晋升作为企业研发人员，你是否有以下问题1、业务快速增长和 IT 能力有余之间带来的驱动力矛盾 2、运行环境简单、关注点无奈聚焦导致线上业务可能面临危险，企业研发效率低下 3、业务波峰波谷导致闲置资源大量节约，效力与 IT 老本重大不符4、Serverless 技术比拟新，传统架构如何迁徙？ 函数计算 FC 自公布至今曾经帮忙上万家国内外企业在 Web、挪动后端、音视频、AI 推理、批量工作解决等宽泛场景落地现代化利用。 为了帮忙各位疾速理解应用函数计算，阿里云 Serverless 产品经理刘宇带来 7 分钟微课程「函数计算 FC : 让研发效力再晋升」，27 节课程蕴含技术了解，架构解析、案例实际、入手实操等内容，以短视频模式，循序渐进讲透 Serverless 运行原理，深度解析 Serverless 落地实际，设置丰盛的体验场景，让你疾速实现 Serverless 技术从入门到实际的逾越。 课程预约即日起 每周三（18:00） 锁定【阿里云云原生】微信视频号 极速击破 Serverless 落地难点 开课期间，每堂课都有精美礼品送出 讲师介绍 刘宇（花名：江昱） 开源我的项目 Serverless Devs (CNCF Sandbox Project) 发起人和负责人，国防科技大学博士研究生，阿里云 Serverless 产品专家。 畅销书《Serverless 架构：从原理、设计到我的项目实战》、《Serverless 工程实际：从入门到进阶》、《Serverless 架构下的 Al 利用开发：入门、实战与性能优化》作者；电子书《架构师特刊：人人都能学会的 Serverless 实际》、《Serverless 开发速查手册》作者。 你将播种： 全面理解函数计算的工作原理以及是否适宜您的场景应用；辞别零散技术点，每次7分钟搭建残缺 Serverless 常识体系；深刻解读源码，直击 Serverless 企业落地常见问题及解决方案；前沿视线，洞察技术变化趋势把握开发提效进阶指南；适宜人群 ： ...

作者：陈欣昊 Serverless 在构建利用上为 TapTap 节俭了大量的运维与开发人力，在根本没投入基建人力的状况下，间接把咱们十分原始的基建，或者说是资源管理程度拉到了业界绝对前沿的规范。最直观的数据是，仅投入了个位数的人力，就能够为TapTap整个搜广推相干的所有业务提供全套AI和大数据方面的反对。 ——陈欣昊  TapTap/IEM/AI平台负责人 心动创建于 2003年，是一家寰球游戏开发和发行商，领有丰盛的研发、发行和代理经营教训。截至 2022 年中，心动经营 38 款收费和付费游戏，在全世界领有 5,000 万月沉闷用户，次要散布在大中华地区、东南亚、北美和南美。2016 年，心动推出手机游戏社区和利用商店 TapTap，玩家能够通过官网渠道收费或付费购买下载手机游戏，亦可在社区中与其余玩家交换，截至2022年6月，TapTap 在寰球已领有超过5,000万月沉闷用户。 业务背景TapTap 不同于传统的利用商店的分成模式，至今始终保持做渠道零分成，这也决定了，TapTap 目前的商业化，次要由广告驱动。TapTap 的广告属于站内的原生广告，与其余非商业化在内容上状态放弃高度一致，给用户更好的体验。比方首页的游戏举荐，发现页的内容举荐，搜寻疏导页的底纹词，以及搜寻输出时会呈现的搜寻倡议词，还有搜寻最初的落地页等等，广告的局部就穿插在这些策略内容之间。 TapTap的 Serverless 实际也是基于这几个业务场景的理论需要来进行推动的。例如，目前搜广推都依赖的深度学习模型自动化更新/部署，以及组内算法同学都须要依赖的模型试验记录平台，还有站内新内容的一些 NLP 剖析解决等。 晚期，TapTap 绝大部分的后端服务都是部署在 ECS，通过 Rundeck 来进行治理和部署，在效率和治理上并不是那么现实。在基建降级计划的需要上，我总结了4点： 1. 能大幅晋升开发运维效率 **2. 以较低的人力老本来满足业务需要 3. 服务足够牢靠，可能具备良好的性能 因为 TapTap 工程目前次要是以 Go 语言为主，所以在后续基建降级上须要对 Go 有良好的支 持。**计划比照咱们思考了两种支流的计划架构，一个是云主机+自建 K8s 全套的解决方案， 还有一种就是 Serverless 架构，应用 Serveless 利用引擎（SAE）和函数计算 FC。 通过比照后，咱们抉择了后者。一方面是 Serverless 能够免去机器的购买流程，不须要提前购买 ECS。而且自身也自带了一些可选的默认环境，如果没有非凡需要的话，能够根本免去环境搭建的繁琐；另一方面是 Serverless 曾经集成了很多根底组件，基本上能够说是做到免运维间接上线的水平。 而后在后续保护上，Serverless 产品在计费精度上相比 ECS 有更高的精度，能够做到分钟级，甚至秒级的计费，做到真正业务应用资源时才进行付费，相比 K8s+ECS 的模式，在晚期开发和后续运维上, 都能节俭较大的人力老本。 从 TapTap 理论试验的体验来了解 Serverless 的两个产品的话。 ...

作者：十眠 Service Mesh 简介Service Mesh 早已不是一个新兴的概念，目前曾经有许多对于 Service Mesh 的摸索以及实际。 2016 年能够说是 Service Mesh 的元年，Buoyant 公司 CEO William Morgan 率先公布 Linkerd ，成为业界首个 Service Mesh 我的项目，同年 Lyft 公布 Envoy ，成为第二个 Service Mesh 我的项目。2017年，Google、IBM、Lyft 联手公布了 Istio，它与 Linkerd / Envoy 等我的项目相比，它首次给大家减少了管制立体的概念，提供了弱小的流量控制能力。通过多年的倒退 Istio，曾经逐渐成为管制立体的事实标准。1.0 版本的问世标记着 Istio 进入了能够生产可用的时代，越来越多的企业将服务网格利用于生产中。1.5 版本开始将原有的多个组件整合为一个单体构造 istiod；同时废除了被诟病已久的 Mixer 组件，对立为 Istiod 服务，不便部署和运维。在目前看来 Istio 是最风行的开源服务网格，它由管制立体和数据立体两局部形成。 在 Istio Mesh 架构中，其管制立体是一个名为 Istiod 的过程，网络代理是 Envoy 。Istiod 作为管制面的对立组件，负责对接服务注册发现、路由规定治理、证书治理等能力，Envoy 则是作为数据面通过 Sidecar 形式代理业务流量，Istio 和 Envoy 之间通过 XDS 协定接口实现服务发现、路由规定等数据的传递。Istiod 通过监听 K8S 资源例如 Service、Endpoint 等，获取服务信息，并将这些资源对立通过 xDS 协定下发给位于数据立体的网络代理。Envoy 则是独立于利用之外的一个过程，以 Sidecar 的形式（个别是以 Container 形式）随同业务利用 Pod 运行，他与利用过程共用同一个主机网络，通过批改路由表的形式劫持业务利用的网络流量。 ...

近年来，人工智能钻研又有了令人瞩目的停顿，AI技术被广泛应用到各个领域。阿里灵杰始终和开发者们一起，独特推动AI的翻新落地，迈向新的增长。 12月22日，阿里云将举办 “2022阿里灵杰Al开发者峰会暨英特尔翻新大师杯寰球AI极客挑战赛颁奖典礼”，本次峰会将面向宽广AI开发者解读阿里灵杰AI能力全景和开发者服务体系，并通过丰盛的场景化演示，出现全新的AI开发体验。 此外，峰会还将为英特尔“翻新大师杯”寰球AI极客挑战赛——DeepRec CTR模型性能优化赛的获奖选手颁奖。挑战赛由阿里云联结英特尔主办，阿里云天池平台、机器学习PAI等组织机构承办，与社会各界的开发者独特摸索CTR模型性能优化方向，旨在推动工业场景中点击率预估模型的训练效率晋升。2022年12月22日14:00【阿里灵杰AI开发者峰会】如约而至，点击预约报名「大咖已就位」本次峰会邀请了阿里巴巴团体副总裁贾扬清等9位技术专家为开发者们带来最前沿的技术分享「主题演讲」阿里巴巴团体副总裁贾扬清分享“开源+工程化：AI普惠的土壤”「硬核技术分享」AI技术资深专家分享行业利用与技术实际，并联合入手演示，展示从模型到服务的开发全流程点击链接即可预约报名和理解更多阿里灵杰AI开发者峰会详情https://tianchi.aliyun.com/sp...

以后，Serverless 笼罩的技术场景正在一直变广。Serverless 已在微服务、在线利用、事件驱动、工作解决等泛滥场景被验证且广泛应用 。当你想要部署一个网站时，须要本人购买服务器并破费工夫去保护，造成资源节约不说，还要消耗精力。而 Serverless 可能很好地解决这个问题，简略来说，就是既省钱又省力。如果你业务的流量不可预测，或者有潮汐稳定，有显著资源闲置，资源利用率低于 30% 以下等，Serverless 肯定会成为最适宜你降本增效的利器。 无论你是零根底开发者还是资深技术专家，都能够在学习 Serverless 技术过程中，晋升研发效力的开发方式，Serverless 是一种将来的开发方式，它是属于每一位开发者的。 为了更多开发者可能享受到 Serverless 带来的技术红利，阿里云云原生利用平台精心研发制作 37节 微课程「Serverless 实战攻略：7 分钟击破 Serverless 落地难点」。适宜你利用碎片工夫疾速晋升技术，让你即学即用，轻松拥抱云计算的新范式——Serverless。 课程介绍本套课程积淀阿里云 Serverless 技术多年实际成绩，37节课程蕴含技术了解，架构解析、案例实际、入手实操等内容，以短视频模式，循序渐进讲透 Serverless 运行原理，深度解析 Serverless 落地实际，设置丰盛的体验场景，让你疾速实现 Serverless 技术从入门到实际的逾越。 11月28日起 每周一、周三（18:00） 锁定【阿里云云原生】微信视频号 讲师阵容 左：刘宇（花名：江昱）--《函数计算 FC : 让研发效力再晋升》 阿里云 Serverless 产品经理，开源我的项目 Serverless Devs 发起人、负责人，多本 Sereverless 畅销书作者。 右：陈涛（花名：毕衫）--《降本增效利器 Serverless 利用引擎》阿里云高级技术专家，阿里云 SAE 研发负责人，在 Serverless、云原生、微服务等方面有多年丰盛的教训。 你将播种： 学以致用、深刻解读源码，直击 Serverless 企业落地常见问题及解决方案可互动、强实操，提供收费场景体验，夯实你的底层代码逻辑适宜人群： 计算机科学、软件工程等畛域的软件工程师和大学生；应用/尝试应用 Serverless/FaaS 技术的应用程序开发者；前端、后端工程师、架构师；正在摸索 Serverless 的技术管理者。课程纲要 — 新课开播，有奖互动 — 11月30日 10:00 前 评论区写下 ...

作者：凌楚 在 RocketMQ 5.0 中，更加强调了客户端类型的概念，尤其是消费者类型。为了满足多样的 RocketMQ 中一共有三种不同的消费者类型，别离是 PushConsumer、SimpleConsumer 和 PullConsumer。不同的消费者类型对应着不同的业务场景。 消费者类型概览本篇文章也会依据不同的消费者类型来进行讲述。在介绍不同的音讯类型之前，先明确一下不同 RocketMQ 消费者中的一个通用工作流程：在消费者中，达到客户端的音讯都是由客户端被动向服务端申请并挂起长轮询取得的。为了保障音讯达到的及时性，客户端须要一直地向服务端发动申请（申请是否须要由客户端被动发动则与具体的客户端类型无关），而新的符合条件的音讯一旦达到服务端，就会客户端申请走。最终依据客户端解决的后果不同，服务端对音讯的处理结果进行记录。 另外 PushConsumer 和 SimpleConsumer 中还会有一个 ConsumerGroup 的概念，ConsumerGroup 相当于是一组雷同订阅关系的消费者的独特身份标识。而服务端也会依据 ConsumerGroup 来记录对应的生产进度。同一个 ConsumerGroup 下的音讯消费者将独特生产合乎以后订阅组要求的所有音讯，而不是独立进行生产。相比拟于 PullConsumer，PushConsumer 和 SimpleConsumer 更加实用于业务集成的场景，由服务端来托管生产状态和进度，相对来说更加的轻量与简略。 简略来说： PushConsumer ： 全托管的消费者类型，用户只须要注册音讯监听器即可，合乎对应订阅关系的音讯就会调用对应的生产办法，是与业务集成最为广泛的消费者类型。SimpleConsumer： 解耦音讯生产与进度同步的消费者类型，用户自主承受来自服务端的音讯，并对单条音讯进行音讯确认。和 PushConsumer 一样也由服务端托管生产进度，实用于用户须要自主管制生产速率的业务场景。PullConsumer： 应用流解决框架进行治理的消费者类型，用户依照队列（Topic 的最小逻辑组成单位）来进行音讯的接管并能够抉择主动或者手动提交生产位点。PushConsumerPushConsumer 是 RocketMQ 目前应用最为宽泛的消费者。用户只须要确认好订阅关系之后，注册绝对应的 Listener 即可。合乎对应订阅关系的音讯在由 Producer 收回后，消费者的 Listener 接口也会被即时调用，那么此时用户须要在 Listener 中去实现对应的业务逻辑。 应用简介以下是 Push 消费者的应用示例： PushConsumer pushConsumer = provider.newPushConsumerBuilder() .setClientConfiguration(clientConfiguration) // set the consumer group name. .setConsumerGroup(consumerGroup) // set the subscription for the consumer. .setSubscriptionExpressions(Collections.singletonMap(topic, filterExpression)) .setMessageListener(messageView -> { // handle the received message and return consume result. LOGGER.info("consume message={}", messageView); return ConsumeResult.SUCCESS; }) .build();// block the main thread, no need for production environment.Thread.sleep(Long.MAX_VALUE);// close the push consumer when you don't need it anymore.pushConsumer.close();用户须要依据本人业务处理结果的不同来返回 ConsumeResult.SUCCESS或者 ConsumeResult.FAILURE。当用户返回 ConsumeResult.SUCCESS时，音讯则被视为生产胜利；当用户返回 ConsumeResult.FAILURE时，则服务端视为生产失败，会进行该条音讯的退却重试，音讯的退却重试是指，在音讯被生产胜利之前，以后音讯会被屡次投递到用户注册的 MessageListener 中直到生产胜利，而两次生产之间的工夫距离则是合乎退却法则的。 ...

作者：涂鸦 背景随着云原生技术一直遍及，越来越多的业务利用开始向云原生架构转变，借助容器治理平台 Kubernetes 的不可变基础设施、弹性扩缩容和高扩展性，助力业务迅速实现数字化转型。其中，集群入口流量治理形式在云原生技术演进过程中逐渐通用化、标准化，用户通过 Kubernetes 定义的 Ingress 资源来治理内部拜访集群外部服务的形式。 微服务架构下，有一些需要开发，波及到微服务调用链路上的多个微服务同时产生了改变，通常每个微服务都会有灰度环境或分组来承受灰度流量，咱们心愿通过进入上游灰度环境的流量，也能进入上游灰度的环境中，确保1个申请始终在灰度环境中传递，即便这个调用链路上有一些微服务没有灰度环境，这些利用申请上游的时候仍然可能回到灰度环境中。通过 MSE 提供的全链路灰度能力，能够在不须要批改任何您的业务代码的状况下，可能轻松实现上述能力。 Kubernetes 网关概述Kubernetes 集群对外裸露流量的形式次要分为三种，Node Port、LoadBalancer 以及 Ingress。 对于 Node Port 而言，实现了奢侈的端口和后端 Pod 的一一对应，不仅存在单点问题，而且因为端口范畴的限度，一旦后端的服务数量回升，会呈现无端口可用的状况；而对于 LoadBalancer 来说，其解决 Node Port 的单点问题和端口数量的问题，奈何它是一个纯正的流量转发资源，并没有路由配置能力，也无奈治理后端泛滥的 Service 利用，所以 Ingress 的诞生就是必然的后果。Ingress 不仅有这人造的路由定义的能力，也扮演者后端泛滥 Service 管理者的角色。不过这里须要提一句，公众所熟知的 Ingress 资源只是单纯的一个 路由 Resource 定义，真正的实现者和执行者其实是具体的 Ingress 规范实现，包含大家所熟知的 Nginx Ingress Controller 都属于此列。 在阿里云 ACK 平台上，有着泛滥 Ingress 的实现形式，其中包含 Nginx-Ingress 、ALB-Ingress 以及最近推出的 MSE-Ingress，本文将讲述一种较为通用的基于 MSE 微服务治理的对立计划，在 Ingress 网关上实现全链路流量灰度。 如何实现在 Ingress 上实现全链路流量灰度首先咱们要晓得在实现全链路灰度时所必须具备的因素，而后再在 Ingress 环境中实现这些因素，就可能实现在 Ingress 网关下的全链路流量灰度。由历史教训可知，咱们这里次要靠标签路由、节点打标以及流量染色这三个因素去实现。 标签路由通过对服务下所有节点依照标签名和标签值不同进行分组，使得订阅该服务节点信息的服务生产端能够按需拜访该服务的某个分组，即所有节点的一个子集。服务生产端能够应用服务提供者节点上的任何标签信息，依据所选标签的理论含意，生产端能够将标签路由利用到更多的业务场景中。 节点打标，如果是在应用Kubernetes Service作为服务发现的业务零碎中，服务提供者通过向ApiServer提交Service资源实现服务裸露，服务生产端监听与该Service资源下关联的Endpoint资源，从Endpoint资源中获取关联的业务Pod资源，读取下面的Labels数据并作为该节点的元数据信息。所以，咱们只有在业务利用形容资源Deployment中的Pod模板中为节点增加标签即可。 ...

作者：董善东、陈昆仪 引言某位资深 SRE 同学示意“一天不收个几十条告警，我都感觉不安心”，“告警天天告，咱们的利用一点事件都没有”。这都反映了一个十分广泛的景象 -- "误告警泛滥"，而“真”告警容易被吞没。ARMS AIOps 团队对超过 6 万条对于响应工夫和错误率突增的告警进行了剖析，发现其中只有 3.05%的告警是“真”告警。同时发现误告警泛滥本源在于单靠现有告警产品的能力很难配置出卓有成效的告警规定。因而，ARMS 基于托管版 Grafana  推出智能告警插件——Smart Metrics，用算法帮忙用户解决"告警配置难、保护难"的问题。 本文从两类常见的有效告警规定动手，剖析无效告警配置难，误告警泛滥的起因，介绍 Smart Metrics 是如何帮忙用户解决告警难配的问题的，并介绍一些最佳实际。最初，欢送退出 SmartMetrics 交换群，钉钉群号 25125004458。 告警现状剖析误告警泛滥咱们通过对 ARMS 告警数据及用户访谈进行剖析，发现许多用户一天收几百条告警，但其中真正有用的只有几条。更可怕的是，那几条“真”告警往往被吞没在大量误告警中，导致用户没能在第一工夫对实在故障做出解决。这些误告警往往是由一些不良的告警配置习惯造成的，比拟典型的有上面两种： “一刀切”式配告警形式：比方一位 SRE 同学要治理很多接口，但为了节俭告警配置工夫，所以抉择对所有利用/接口的响应工夫、错误率和调用量配置对立且固定阈值。然而，不同利用/接口失常状态下的响应工夫、调用量和错误率指标的失常水位自身就不雷同，成千盈百的利用/接口应用同一阈值天然会产生大量误告警。 “疏于打理”的告警阈值：有的告警规定在利用起初是没有问题的，但随着业务增长，响应工夫、调用量等业务指标，以及 CPU 使用率等机器指标的均匀水位线已发生变化。但 SRE 没有及时更新阈值，导致系统失常时也会一直产生告警。 一般而言，只有针对上述两种告警策略进行优化，就能够无效防止大量误告警。但实际上，它们的优化并不简略。起因在于现有告警产品往往只反对用户应用动态阈值配置告警。 咱们先来看一下典型告警配置页面：它提供了很多罕用聚合算子：均值、最大值、最小值、差分等，用户能够用这些算子自定义告警规定。 咱们再来看看实在的运维指标，比方 qps(每分钟调用量)，发现它长这个样子： 那么，当初应该 min\max\avg 什么？阈值该设置成多少？ 无效告警配置难、保护难的起因面对实在多变的运维指标，即便是经验丰富的运维专家也很难配出无效告警。咱们总结无效告警配置难、保护难的次要起因： 1. 许多运维指标起伏不定，很难设定适合的动态阈值。它们往往呈现出以小时、天、周为周期的季节性特色。这些指标自身就起伏不定，导致动态阈值、同比阈值都不好配。 2. 同一指标，不同利用\接口\主机阈值不同。以 RT 指标(响应工夫)举例， 有的接口失常时 RT 在 200ms 左右，那么当 RT 大于 300ms 时，能够断定为异样。然而，有些接口长期访问量大， 整体指标在 500ms 左右失常稳定，适合的告警阈值可能是 600ms 左右。而一个利用可能有几百个接口，运维同学要对所有接口配置适合的阈值，工夫老本十分高。 3. 指标的失常水位会随着业务的增长变动。随着公司业务倒退、新利用上线，一些指标失常状态水位会一直变动。如果没有及时更新阈值，就很容易产生大量误告警。 综上，靠现有告警产品中依赖动态阈值形式，须要 SRE 同学投入大量工夫老本且难以获得较好成果。 为解决这个问题，ARMS推出基于 Grafana 的智能告警插件——SmartMetrics，用算法来帮忙用户配置无效告警。 ...

作者：子葵 背景在日常运维 ZooKeeper 中，常常会遇到长时间无奈选主，复原时过程启动又退出，进而导致内存暴涨，CPU飙升，GC频繁，影响业务可用性，这些问题有可能和 jute.maxbuffer 的设置无关。本篇文章就深刻 ZooKeeper 源码，一起探索一下ZooKeeper 的 jute.maxbuffer 参数的最佳实际。 剖析首先咱们通过 ZooKeeper 的官网上看到 jute.maxbuffer 的形容： jute.maxbuffer :  (Java system property:jute.maxbuffer). ......, It specifies the maximum size of the data that can be stored in a znode. The unit is: byte. The default is 0xfffff(1048575) bytes, or just under 1M. When jute.maxbuffer in the client side is greater than the server side, the client wants to write the data exceeds jute.maxbuffer in the server side, the server side will get java.io.IOException: Len error ...

作者：吴森梵（仰森） 在刚刚完结的 2022 杭州 · 云栖大会上，阿里云发表函数计算 FC 开启全面提价，vCPU 单价降幅 11% ，其余的各个独立计费项最高降幅达 37.5% 。函数计算 FC 全面提价，让 Serverless 更加普惠，用户可随用随取，按量计费，用更低成本采纳 Serverless 架构，然而函数计算 FC 到底在技术上作出怎么的降级才促成本次提价产生呢？本文将全面揭秘幕后关键技术——函数规格自主选配性能。 痛点：规格灵便度低，老本节约随着越来越多用户逐渐将更多样化的负载部署至函数计算，比方 CPU 密集型，IO 密集型等，这些负载中有的须要更大的磁盘，但函数计算却只提供了依照内存大小等比例调配算力的能力，此时为了满足需要最大的一项，用户须要设置比理论所需更大的规格，这并不利于更准确的管制老本。但因为可选的规格计划数量较少，加上较大的梯度，进一步减弱了灵活性。 为解决以上痛点，函数计算提供了规格自主选配性能，不仅放开了 CPU 和内存固定比例的限度，同时提供极小的梯度，准确地设置函数规格，让函数须要多少用多少，晋升资源利用率的同时，升高用户老本。 规格自选性能如何帮忙升高用户老本？接下来以具体案例进行展现，让大家直观地理解函数规定自主选配性能的劣势。 贴合理论资源用量的函数规格下图展现了函数运行期间 vCPU 和内存的应用状况，该函数的 vCPU 用量始终低于1.5核，内存用量低于 6GB，资源节约显著，用户须要为没应用到的资源付费。 在推出自主选配性能前，函数计算提供的内存规格有 4GB、8GB、16GB、32GB。因为该函数内存最大使用量超过 5GB，为确保函数失常执行，只能配置内存为 8GB，该内存对应的 vCPU 规格为 4 核。 当初，咱们能够将函数规格调整为 1.5核 vCPU 和 6GB 内存，显著晋升资源利用率的同时，老本也升高到了原来的 44%。 调整前：4核 8GB规格的函数，每秒费用是 4核0.000127元/(核秒) + 8GB0.0000127元/(GB秒) = 0.0006096元调整后：1.5核 6GB规格的函数，每秒费用是1.5核0.000127元/(核秒)+6GB0.0000127元/(GB秒)=0.0002662元tips：察看监控指标页面的实例指标，如果函数不能充分利用vCPU或内存资源，思考调整函数规格以降低成本。更细粒度 GPU 算力在一些算法场景下，咱们将模型部署到云上提供在线推理服务，假如模型须要应用 1.8GB 的显存，如果采纳传统计划，购买装备 GPU 资源的云服务器，最低显存是 8GB，运行单个在线推理服务时，GPU 利用率低于 25%，存在微小的节约。即便通过单机运行多个在线推理服务来进步利用率，但须要额定开发申请调度性能、均衡其余类型资源的调配，减少开发和运维的复杂性，并且弹性能力简直为 0。 ...

近日，阿里云函数计算产品团队撰写的对于 Serverless 调度的创新性论文，被云计算畛域 ACM SoCC 国内会议长文录用。 去年阿里云函数计算团队首个提出在 FaaS 场景下的去中心化疾速镜像散发技术，团队所作论文被计算机系统畛域的顶级会议 USENIX ATC’21 录用，入选中国计算机协会（CCF）举荐 A 类国内会议列表；往年阿里云函数计算一直冲破：公布基于函数画像的调度算法论文并被国内云计算的首要会议 ACM SoCC 录用，真正做到可能保障晋升函数资源利用率的同时，达到性能高稳定性。 ACM Symposium on Cloud Computing（以下简称 SoCC）是由美国计算机协会主办、聚焦云计算技术的一项学术会议，是云计算的首要会议。它会集了对云计算感兴趣的钻研人员、开发人员、用户和实践者，是惟一由 SIGMOD（数据管理特地趣味组）和 SIGOPS（操作系统特地趣味组）联结主办的会议, 这个会议在近些年蓬勃发展，旨在汇集数据库和计算机系统两大畛域的学者，独特推动云计算技术在工业界的钻研与倒退。 此次被录用的论文为《Owl: Performance-Aware Scheduling for Resource-Efficient Function-as-a-Service Cloud》。 此论文灵感诞生于阿里云 Serverless 产品函数计算，函数计算是阿里云的函数即服务(Function-As-A-Service)产品。阿里云函数计算是事件驱动的全托管计算服务。通过函数计算，您无需治理服务器等基础设施，只需编写代码并上传。函数计算会为您筹备好计算资源，以弹性、牢靠的形式运行您的代码，并提供日志查问、性能监控、报警等性能。现阶段曾经笼罩了事件驱动、音视频解决、游戏、物联网、新批发、AI 等理论业务场景，并服务于阿里云、高德、支付宝、淘宝、CBU 等多个业务或我的项目中。上图是一个经典的 FaaS 调度零碎的架构，调度器负载将不同的函数实例调度到集群中的节点上运行。因为 FaaS 产品函数数量多、函数粒度小、执行工夫短的特点，节点的资源利用率较低。简略地将更多的实例调度到同一个节点上尽管可能肯定水平地晋升资源利用率，然而也带来了资源争抢和性能降落。 论文针对这个问题翻新地提出了基于函数画像的调度算法，在进步资源利用率的同时达到了较好的性能稳定性： 对于高频调用的函数，调度器会辨认不同函数实例在同一个节点共置时的性能体现，以此领导函数实例的调度；对于低频调用的函数，调度器会统计其执行过程中的理论资源耗费，以此来领导函数实例的调度，同时调度器会监控函数的执行延时，当呈现延时上升时通过隔离的伎俩进行缓解；调度器还针对闲置的实例进行迁徙，将它们从利用率低的节点迁徙到利用率高的节点以开释闲置节点。为了评估算法的成果，论文依据生产环境典型的函数负载，形象了 10 个函数，它们笼罩了不同的编程语言、资源耗费、执行时长、内部依赖。列表如下： 试验结果表明，在 100 个节点规模下，OWL 调度算法可能节俭 43.8% 的资源，同时函数执行延时没有显著的减少： 调度延时也没有明显增加： 目前 OWL 的函数画像能力也曾经利用在函数计算线上环境，并获得了不错的成果。此次论文入选 ACM SoCC，是阿里云在 Serverless 调度畛域的又一次翻新。 附论文信息录用论文题目：Owl: Performance-Aware Scheduling for Resource-Efficient Function-as-a-Service Cloud ...

作者：千习 背景简介什么是定时工作定时工作是业务利用零碎中存在定时周期性运行的业务逻辑。因为其运行于后端过程中往往存在执行状态和执行链路的不可见性《常见定时工作技术计划》。 https://developer.aliyun.com/...什么是链路追踪随着散布式微服务化架构在企业中大规模使用，业务运行的利用平台是一个由各个业务研发团队不同业务利用组合而成的庞杂系统工程，相互之间存在各种模式的拜访交互。 面对上述如此简单的系统结构，对于业务入口端利用而言所有的上游服务状态都是黑盒不可知的存在。相应的运维问题也随之而来： 入口服务不可用时，如何疾速定位具体是哪个服务节点不可用及起因？如何疾速定位剖析业务链路中性能瓶颈点？如何掌控业务链路残缺执行过程？ 面对上述问题，从 Google 分布式链路追踪零碎的 Dapper 论文开启了各类分布式链路追踪的实现，呈现了很多相干零碎，如：Zipkin、Skywalking、Pinpoint。所有这些其外围逻辑就是在一次业务申请开始时构建相应申请的链路上下文信息，并在服务调用过程中透传欠缺相应的链路节点信息，最终通过该申请 TraceId（本次申请的链路标识）和每个节点父子依赖关系构建出一个残缺的调用链数据结构。 整个分布式全链路追踪平台各项次要分工： 利用侧实现服务调用埋点，常见形式：手动调用 SDK 埋点、java agent 模式主动埋点服务之间通信交互，相应通信协议上须要增加 Trace 信息进行传递，保障在整个调用链中 Trace 信息共享Trace 信息上报至全链路追踪平台进行存储展示 基于上述几个次要环节，各个开源计划别离实现了各自在采集、传输、存储环节的不同数据结构。为实现链路追踪畛域范畴内数据结构对立，呈现了 OpenTracing 和 OpenTelemetry 来定义相应的标准和协定。 为什么定时工作须要链路追踪剖析工作为什么执行失败当业务一直倒退，业务开发的定时工作也会越来越趋于复杂化，定时工作执行过程中会倒退出如下各种状态： 会调用其余业务方各类上游应用服务会调用其余中间件服务（如：redis、mq 等）会切分出 N 个子工作分发给不同机器进行分布式并行批处理，每个子工作解决又是一整套简单组合 当面对此类简单定时工作场景下工作执行如果出现异常，相应的问题定位将变得很简单。在残缺的全链路追踪能力反对下，问题将能被疾速定位解决。 剖析工作为什么执行慢个别场景下离线工作往往承当着大批量数据处理的业务场景，因此很多定时离线工作有运行耗时长的特色，往往在这些耗时长的工作上存在着微小的性能优化空间，性能晋升能间接优化根底资源应用效率并节俭业务老本。 在任务调度平台上咱们可通工作执行超时报警，再联合工作执行链路追踪能力可无效地锁定业务解决的耗时瓶颈点供进一步业务性能优化作为参考。 全链路流量管制在全链路追踪体系下，能够进行后续其余能力拓展： 灰度公布：定时工作利用公布过程中的工作全链路灰度能力全链路压测：定时工作通过业务测试标签参加全链路压测流量隔离：定时工作调用上游服务，上游服务依据流量起源进行隔离解决 定时工作链路追踪解决方案开源解决方案从开源定时工作平台看，目前常见开源计划都未反对工作执行链路可视化查问，对简单工作或分片工作执行异样下的问题剖析会比拟艰难。 另外在开源链路追踪平台，对应开源计划中局部采集端 agent 集成了定时工作框架执行入口埋点采集，但该模式下与任务调度平台侧较为割裂，从负责定时工作运维的视角登程想具体锁定某一次工作执行链路，须要通过日志或依据执行工夫检索匹配相应的执行记录，当链路追踪平台上数据繁多想疾速惟一锁定目标链路存在很多不便。 阿里解决方案阿里分布式任务调度平台 SchedulerX 提供了一站式的链路追踪解决方案，能够将工作执行信息与链路追踪 Trace 信息绑定，用户能够很不便的从任务调度侧，查看某个工作、某次执行、某个分片的残缺调用链。 阿里 SchedulerX 计划劣势： 精准定位工作执行 Trace 信息：常见链路追踪平台只负责工作执行的时候生成 traceId，不提供和具体任务的绑定关系，想要从成千上万的 traceId 中剖析某个工作的调用链变得非常复杂；SchedulerX 无论是单机工作还是分布式工作的某个分片，每一次调度都能疾速定位到调用链。 调度侧反对管制采样率：手动运行一次反对必采样、动静配置采样率。 免运维低成本：通过 EDAS 部署的 Java 业务利用人造反对定时工作 Trace 能力，无需自建链路追踪服务端平台和 agent 采集，升高业务老本，并且能够从任务调度侧一键跳转到调用链。定时工作链路追踪客户案例某电商业务定位工作执行慢用户案例：目前电商业务场景下都基于微服务架构体系，定时工作运行波及的利用较多且链路较深，用户对某个工作运行慢时，心愿能疾速定位哪个业务利用方哪个业务性能是执行链路瓶颈点。 以下将展现如何剖析工作的执行耗时，工作触发执行后会调用屡次上游业务应用服务以实现整个业务逻辑，整个工作执行耗时较长。 如上图所示，惯例状况下一次执行<5 秒，但最近两次次执行耗时>15s，通过工作配置超时报警可监测到该执行记录超过预期执行工夫，对该执行记录的调用链路进入下一步剖析。 ...

作者：Brae Troutman 随着 OpenClusterManagement（OCM）我的项目的继续倒退，咱们感觉有必要周期性向大家同步近期我的项目的一些停顿了，包含咱们咱们下一步将来倒退的方向以及作为贡献者如何参加进来咱们的社区。2022 年的序幕行将到来，让咱们来进一步看一下我的项目研发方面的新内容吧！ 对于 Open Cluster ManagementOCM 是一款 Kubernetes 多集群平台开源我的项目，它能够帮忙你大大简化跨云/多云场景下的集群治理，无论这些集群是在云上托管，还是部署在自建数据中心，再或者是在边缘数据中心中。OCM 提供的根底模型能够帮忙咱们同时了解单集群外部的容量状况，也能够横跨多集群进行资源/工作负载的编排调度。与此同时，OCM 还提供了一系列弱小的扩展性或者叫做插件框架（addon-framework）来帮忙咱们集成 CNCF 生态中的其余我的项目，这些扩展性也能够帮忙咱们无侵入地针对你的特定应用场景手工扩大个性。 OCM 目前是 CNCF 官网 Sandbox 级别我的项目，吸纳了来自超过 15 个不同组织的维护者横跨不同的云原生厂商和解决方案提供商。咱们认为 OCM 是一种对于目前曾经废除的 Kubernetes 多集群工作小组下的 Kubefed 我的项目的可行的平行代替计划，同时咱们也在致力于在 Kubefed 的正式下线后继承连续 Kubernetes 官网多集群治理的使命。 Website:  https://open-cluster-manageme... GitHub:  https://github.com/open-clust... 新版本 v0.9.0 内容咱们很快乐在此发表 OCM v0.9.0 版本的正式公布。在这个版本中，咱们曾经进一步晋升了托管集群上的安全性相干问题并且能够提供了晦涩的托管集群到主集群的服务裸露性能。你也能够依据这里的研发打算来看到这个版本中的新增个性等等，同时窥见社区整体正在朝哪个方向倒退。 降级 Work 守护容器的平安权限在之前的 OCM 迭代版本中，Work 守护容器通常在托管集群中是运行在管理员权限上的。这个公布版本中，为了实际“权限最小化”的准则，OCM 反对了以 ManifestWork 粒度独自定义非管理员的权限身份，这样以来就容许例如多集群利用运维的最终用户针对场景为不同的集群定义不同的权限。 反对多集群服务的裸露和路由在最新版本的 OCM 的 Cluster-Proxy 插件里新增了在托管集群中裸露/凋谢一个 Service 以使得中枢集群内的客户端能够拜访的个性，即便是横跨 VPC 能够晦涩进行裸露。本来所有的流量是被定向路由到了各个托管集群的 Kube-Apiserver 下面，这肯定水平上减少了运行 master 相干组件的节点的压力。当初 Cluster-Proxy 的插件守护容器反对了能够通过指定某个集群的某个指标服务，以使得流量的负载平衡失去了些优化，同时向中枢集群裸露服务的粒度调整也更加灵便。 反对通用化插件配置对于某些心愿可配置化的 OCM 插件，咱们提供了一些新的插件 API 可扩展性来反对用户提供定制插件的配置援用信息，同时在插件框架中，咱们也反对了在发现对应配置发生变化时，能够即时触发插件相干的资源的重新部署下发。 ...

作者： 澄潭、如葑 前言在 11 月 15 号的直播 《Higress 开源背地的倒退历程和上手 Demo 演示》中，为大家演示了 Higress 的 Wasm 插件如何面向 Ingress 资源进行配置失效，本文对当天的 Demo 进行一个回顾，并阐明背地的原理机制。 本文中 Demo 运行的前提，须要在 K8s 集群中装置了 Higress，并失效了上面这份 quickstart 配置： https://github.com/alibaba/hi...这个 Demo 要实现的性能是一个 Mock 应答的性能，须要实现依据配置的内容，返回 HTTP 应答。本文会按以下形式进行介绍： 编写代码：代码逻辑解析失效插件：阐明代码如何进行编译打包并部署失效测试插件性能：阐明全局粒度，路由/域名级粒度如何失效插件失效原理：对整体流程进行回顾，阐明插件失效的原理三个革命性的个性：介绍 Wasm 插件机制为网关插件开发带来的改革 编写代码package mainimport ( . "github.com/alibaba/higress/plugins/wasm-go/pkg/wrapper" "github.com/tetratelabs/proxy-wasm-go-sdk/proxywasm" "github.com/tetratelabs/proxy-wasm-go-sdk/proxywasm/types" "github.com/tidwall/gjson")func main() { SetCtx( "my-plugin", ParseConfigBy(parseConfig), ProcessRequestHeadersBy(onHttpRequestHeaders), )}type MyConfig struct { content string}func parseConfig(json gjson.Result, config *MyConfig, log Log) error { config.content = json.Get("content").String() return nil}func onHttpRequestHeaders(ctx HttpContext, config MyConfig, log Log) types.Action { proxywasm.SendHttpResponse(200, nil, []byte(config.content), -1) return types.ActionContinue}下面代码中能够看到三个函数： ...

作者：丹坤 近日，Serverless 开发者平台 Serverless Devs 重磅公布基于 Serverless 架构的轻量级 CI/CD 框架——Serverless-cd。Serverless-cd 是一款运行在 Serverless 架构上的功能强大而灵便，平安，低成本的CI/CD开源框架。该框架基于 Serverless Devs 开发者工具打造，通过 Serverless-cd 开发者能够疾速构建企业外部利用治理 PaaS 平台。 开发者更想关注业务价值的发明Serverless Devs 是 CNCF 沙箱孵化我的项目，2020 年由阿里云开源，它是一个开源凋谢的 Serverless 开发者平台，Serverless Devs 也是业内首个反对支流 Serverless 服务 / 框架的云原生全生命周期治理的平台，致力于为开发者打造 Serverless 利用开发一站式服务，帮忙解决目前的工具链之困，让开发者一键体验多云产品，极速部署 Serverless 我的项目。 Serverless Devs 我的项目为利用的开发，调试，部署，运维，监控提供全生命周期的解决方案。在理论应用中，利用部署和交付对于开发者来说依然是一个难题。开发者心愿更专一于利用的开发和价值的发明——也就是关注代码编写和利用的构建，而非应用部署和交付。 在 Serverless-cd 我的项目公布之前，Serverless Devs 我的项目通过集成的形式，集成了支流的 CI/CD 工具，如 Jenkins、Github、Gitlab 等： https://github.com/Serverless...但应用这些传统的 CI/CD 工具个别会面临如下几个问题： 资源利用率低：须要提前准备构建机器，在没有构建工作时，机器资源节约；工作排队：如果资源筹备不短缺，在业务构建的顶峰期间， 工作排队工夫过长；隔离性差：如果某个工作执行过程中耗费大量计算/存储资源，导致其余工作失败；平安问题：应用平台提供的CICD服务：代码和构建机器不在同一个网络环境，不得不凋谢公网拜访，引起平安问题。ECS虚机部署：多个利用同时在一个实例构建，某个歹意利用能够拜访其余的利用的代码CI/CD 流水线的 2个特点CI/CD 流水线有两个显著的特点： 事件驱动无论是接管 Webhook 主动触发，还是调用 Open Api 手动触发，对于 CICD 零碎来说都是被动接管指令进行生产 业务显著波峰波谷触发 CI/CD 构建的顶峰个别在下班的时间段中，上班后以及早晨构建工作比拟少。同时有些工作执行十分耗时，有些工作又须要大量的 CPU&内存资源，很难提前进行无效的容量预估。 ...

作者：闵大为(天未) 序从根底的角度看，设计模式是钻研类自身或者类与类之间的合作模式，是进行形象演绎的一个很好的速成思路。前面浏览设计模式后，为了加深了解，对相干图片进行了描述和微调。 从技术的角度曾经有很多好的总结，本文会换一种角度思考，既然设计模式钻研的是类与类的关系，咱们作为工作的个体，一些工作中的策略是不是也能够进行类比，能够更好地去思考这些模式？答案是必定的。 创立型模式 5形象工厂（Abstract Factory）：多套计划形象工厂模式是对创立不同的产品类型的形象。对应到工作中，咱们确实应该具备提供多套计划的能力，这也是咱们常说的，要提供选择题。当你有这样的前瞻意识，个别也会被打上思考较多的标签，然而外在来说，确实想问题更加全面了。 生成器（Builder）：长于合成生成器模式是对一个个体的创立过程进行细分，拆解为不同的创立局部。这个对应到工作中，作为一些项目管理人员或者团队管理者，须要将一个大泥球一样的事务，正当合成，让大家各司其职，充分发挥能力。同样，咱们对日常的工作内容，也能够依照构造去进行划分，从而更有调节。 工厂办法（Factory Method）：形象思考工厂办法模式是说将提供某一产品的过程进行形象，通过接口的模式去标准进去。相似的，咱们很多做事的过程，都是面向过程，没有形象提炼一下。如果通过进一步思考，那么能够往上再提炼一个档次，发现事物的实质：到底在做什么，咱们的职责是什么，提供什么样的价值。想的更分明，做的也会更加精确。 原型（Prototype）：传承常识原型模式是说，利用拷贝对象的办法，缩小一些简单的创立过程。这里咱们可能学到的是，须要做好日常的积攒，很多计划不是每次来都重写，是能够在原来的计划上进行拷贝复用的。这个clone的过程，往往也是常识传承的过程。如果有比拟好的传承机制，那么会大大晋升服务效率。 单件（Singleton）：专一单件模式是说在多线程的状况下，要保障对象只创立一遍，作为举世无双的资源。这个我感觉，应该去 review 一下咱们的工作模式，尽管咱们经常要并发很多事件，然而如果处处被打断，每件事都想干好，那么可能每件事都干不好。咱们要确保在某个时间段极力地做好一件事。事件是一件件无效解决的，不是一起缓缓解决的。 构造模式 7适配器（Adapter）：适应能力适配器是为了联合原来的能力，适配新的接口服务，比方适配不同的协定入口。工作的时候，其实须要适应不同的人和事，有不同的工作办法形式，然而咱们的外围能力是一样的，都是解决对应的问题域。 桥接（Bridge）：正当关系桥接模式是将原来相互依赖的局部，通过下层接口再往形象层提一下，缩小类之间的间接单干，造成间接关系。这个到对应到工作中来说，有一种场景是，经常开发对开发去case by case解决问题。如果往产品逻辑层走一下，开发对产品，产品层面可能有更好的形象。当然为了更好的服务体验，这样的解耦是不多见的，然而这样的思考咱们可能要get一下。 组合（Composite）：递归思考组合模式通过继承和孩子节点，能够递归地去形容一个对象档次。这个对咱们工作来说，要加深思考的档次，能够某个点拆开去再去思考，同时如果可能在递归合成过程中形象一些共性的点，就能找到一些法则。比方咱们的需要合成，每个需要能够合成为子需要，子需要再往下看又能够递归合成。合成完之后，每个局部有这部分的owner去驱动他的上游，造成一个层次结构。 装璜（Decorator）：增量价值装璜模式是将原来的能力进行包装，并提供新的行为。其实每次性能迭代，咱们大多是在原来的根底上增加新的性能。咱们要定义好新的能力，首要前提是继承、了解好原来的逻辑。这里还想提的是，很多时候，咱们只看到了咱们复用了宏大的根底能力，然而也要看到咱们在我的项目中增量的奉献，这是咱们的闪光点。不要把“拧螺丝”真的看成了拧螺丝。 外观（Facade）：深入浅出外观模式是说咱们不须要了解简单的零碎，而是通过一个外观去操作。这里咱们的工作思路是，咱们不必展现简单的细节，咱们要提供一些高层的了解，汇报如此，零碎的包装也是如此。就比方，服务性能孤立来看，可能很多、很杂，但如果有一个对立的站点去疏导包装，那么感觉会好很多，也会看上去有点收口和聚焦的感觉。 享元（Flyweight）：长于链接享元模式是说，当咱们曾经存在一些内容的时候，能够通过缓存复用，而不是从新创立，缩小开销。咱们在工作中也要做好积攒，然而更要做好缓存的key，通过怎么样的伎俩去链接到咱们的工作中，是须要咱们做好类目治理和继续积攒的。 代理（Proxy）：了解爱护代理是为了包装一个类，对相干操作进行二次转发或者进行一些管控。工作中来说，有些工作模式下，有时候咱们可能会埋怨管理者代理了咱们的决策等操作，然而换个角度想，他们爱护了你不必间接被裸露在业务方侧，可能依照预期内的节奏提供服务，不会被被动设置一些预期外操作或私活。 行为模式 11责任链（Chain of Responsibility）：能力与责任责任链是说将申请让队列内的处理器一个个执行，直到找到能够执行的。这里对咱们工作的启发是，咱们经常埋怨咱们失去的机会少，不能成为队列内优先能够解决的处理器，总是解决人家不须要的。然而换个角度看，首先责任链外面的处理器应该是正交的，大家应该各司其职。退一步来说，如果真的有重叠，那么你应该致力晋升本人，成为能力强的，从而进步队列内的优先级。 命令（Command）：增强单干命令模型是说将申请包装为命令，这样在执行的时候能够与具体的执行逻辑解耦。工作中来说，咱们有时候不应该太关怀一个事件是怎么实现的，当交给他人实现时，信赖他们即可，就是从解决问题的角度来看，不必事事亲为，事事较真。然而这并不障碍咱们被动养成全局视角，理解每个细节。单干能力影响更多的事件。 解释器（Interpreter）：增强了解解释器模式是说针对一套上下文，造成一套语言，能够通过解释表达式含意的形式实现对应的工作。这里来说，咱们能够造成某个个人的畛域语言，外部交换通过相干畛域语言交换，能够减少交换效率。此外，其实不同档次都有不同档次的专业术语，有时候一个术语的解释是一个方面的顿悟，还是要多理解工作内容自身。 迭代器（Iterator）：横向职责迭代器模式是将汇合的拜访性能独立进去，通过迭代的模式去拜访。这种独立职责的操作，工作中咱们经常会看到，咱们会将需要治理，缺点治理，资金平安的一些事件独立进去看。一个方面是这些功能块从主体来说是比拟内聚的，另一个来方面说，对工作职责的细分，能够让大家把本人的事件干好，施展团队作战的效力：开发把开发干好，测试把测试干好，资损防护同学把资损防护干好，整体也就做好了。 中介者（Mediator）：协调能力中介模式是说：当多个类之间要协调的时候，往往引入中介者进行协调，缩小大家的常识老本。这个咱们经常须要一些 PM、PMO 这样的角色去治理我的项目，零碎中也须要一些协调层去协调各个域。因而咱们也重视造就协调事务、具备全局观的能力。 备忘录（Memento）：小步快跑备忘录模式是对操作的一些记录，已被能够复原到之前的版本。在日常工作中，咱们经常须要及时备份、及时保留、及时提交等操作，这样在程序解体的时候能够疾速复原到之前版本。但从形象来说，一些比拟长时费劲的事件，咱们应该合成来做，及时锁住局部收益。 观察者（Observer）：主观能动性观察者模式是说咱们通过注册、回掉这样的合作设计，实现变动告诉的合作机制。这个工作中来说，换个角度思考，咱们能够将一些被动的工作，变成被动的思考。比方：我须要干某局部工作，从工作的角度来说，不得不做，从被动的角度来说，就是须要造就某块的能力。如果对工作内容不太称心，也能够沟通协调，而不是预先暴发，但凡都是能够主观驱动的。 状态（State）：治理本人状态模式是说在不同的状态下，有不同的解决行为。对工作中来说，咱们可能有状态好的时候，有状态不好的时候，主观的解决的伎俩是调整状态。然而如果调整不过去，咱们应该进行不同的操作。比方，脑子好的时候，想一些简单问题；脑子嗡嗡的时候，做一些简略整顿。 策略（Strategy）：了解决策策略模式是说实现一个事件有不同的算法，能够进行相干切换。咱们在工作中，经常会提供不同的计划，不同的计划有不同的老本和收益，然而这些计划的抉择时候，往往不是咱们能决定的，而是客户client被动判断的。 模板（Template）：标准化能力模版模式是说对一个执行过程进行形象合成，通过骨架和扩大办法实现一个规范的主体逻辑和扩大。咱们很多时候，做xxx平台也都是这样的：对过程进行标准化，对变动进行定义，造成一个平台逻辑和业务扩大，实现一个产品模版。只是说这个模版是站点，还是扩大点，还是其余的展现模式。这样标准化的能力也是须要长期训练的。 访问者（Visitor）：学会撒手访问者模式是说把对元素的拜访操作交给访问者来操作，因为对访问者来说经常有不同的拜访行为。在工作中，往往咱们只能陈说事实，这个内容消化后，每个人都有本人的了解。代码合作也是一样，比方：页面到底长什么样，其实还是要交还给业务自身，咱们应该专一于提供根底的能力。 总结作为开发者，咱们对于如何写出优雅的代码，示意纳闷。因为经常背地是简单的问题域，优雅的设计往往产生于部分，很难整体都很优雅。 作为工作者，咱们对于如何做出好的体现，示意纳闷。因为背地经常是综合素质与时机的联合，好的后果往往产生于一个阶段，长期须要较快且继续的成长。 然而，如果咱们有一些指导性的准则，往往咱们可能明确事务的折中点，做出更加正当的设计，以及更加要害的奉献。

间隔 12 月 03 日上海站微服务x容器开源开发者 Meetup 流动正式揭幕还有不到一周工夫，线下席位行将约满。请感兴趣的同学放松报名哦！ 本次流动由阿里云云原生利用平台与飞天 Club 独特打造，整体内容聚焦容器 & 微服务方向。流动将围绕云原生畛域当下 11 个热门开源我的项目的技术分享和企业实际开展，邀请到 Spring Cloud Alibaba、Dubbo、OpenYurt、KubeVela、OpenSergo、Koordinator 等云原生畛域传统&新锐开源我的项目外围维护者，为大家分享社区最近动静、架构实际及企业应用案例等精彩内容。 流动日期：2022年12月03日（周六） 流动工夫： 09:00-17:00 流动地址：上海 · 阿里巴巴西岸国内人工智能核心-7N01 百鸣山庄 11大热门开源我的项目亮点领先看OpenSergo ： 古代微服务架构中，简单微服务架构的稳定性治理怎么破？Higress : Ingress Controller 开源新星 Higress 在集群入口流量治理上的最佳实际云原生利用脚手架 ： 脚手架的性能、定位，以及近期的产品布局是什么?Dubbo ： 我的项目的开源现状剖析、对策以及将来的整体规划Koordinator ： 如何进步 Kubernetes 集群的资源利用效率，帮忙企业升高资源老本？OpenYur t ： 云原生时代的边缘计算面临哪些挑战？基于 OpenYurt 的云边端一体化实际KubeVela ： 如何抉择并借助开源的力量助力产品的疾速降级？如何摸索和实际云原生时代中新一代 Serverless 架构的降级？Fluid ：  如何通过本身弹性数据伸缩的能力，提供了开源，规范而又灵便的解决办法？OpenKruise ： 如何助力云原生利用更好地实现自动化的？sealer ： 如何解决利用整个分布式应用整体交付问题？实现整个分布式应用的 Build,Share,Run !!!欢送扫描下方二维码 退出微服务x容器 Meetup 流动群 参加现场互动，社区精美周边送不停12月 03 日 【微服务 x 容器开源开发者 Meetup】诚邀您来参加，流动现场，你不仅能理解当下最受开发者欢送的开源我的项目最新进展、企业应用实际，结交酷爱开源的开发者搭档，还有大量社区精美周边派发，超萌云小宝公仔抱回家，连忙报名吧！ 残缺议程 本次流动将通过开源中国视频号及阿里云云原生视频号矩阵进行实时直播，欢迎您能够阿里云开发者社区直播间预约收看： https://developer.aliyun.com/... 扫描海报二维码或点击此处，立刻报名！

本文作者：郭雨杰，阿里云智能技术专家。Prometheus 集成的 50 多款云产品中，RocketMQ 在可观测方面实现了十分欠缺的性能，是一个特地具备代表性的云产品。 RocketMQ 如何接入 Prometheus RocketMQ 诞生于阿里外部的外围电商零碎，是业务音讯的首选 MQ 平台。上图是 RocketMQ 5.0 的零碎全貌，在接入层、外围组件和底层运维方面做了十分大的改良，具备性能多样、高性能、高牢靠、可观测、易运维等泛滥劣势。 Metrics、Tracing、Logging 是可观测能力的三大支柱。 Metrics：RocketMQ 以 Prometheus+Grafana 这种在开源畛域宽泛应用的产品组合为用户提供了开箱即用的 Dashboard。指标涵盖了音讯量、沉积量、各阶段耗时等，该大盘联合 RocketMQ 团队在音讯畛域多年的研发和运维教训打磨的最佳实际模板，并提供了继续的迭代更新能力。Tracing：RocketMQ 首次引入了 OpenTelemetry tracing 的开源规范，依照音讯的维度，从新组织了形象的 span 拓扑。 Logging：Logging 方面次要进行了一些客户端日志的标准化解决，可能更简略不便地利用日志定位问题。 RocketMQ 的所有可观测性数据都是围绕一条音讯在生产端、服务端解决、生产阶段开展。从音讯的生命周期图上，能够看到一条音讯从 Producer 开始发送到 MQ server 接管到的耗时；如果是定时音讯依据 Ready time 能够晓得定时的工夫；从 Consumer 的角度上看，能够晓得音讯从开始拉取到到达客户端的网络耗时；从到达客户端的工夫到开始解决音讯的期待解决资源耗时；从开始解决音讯到最初返回的 ACK 的解决耗时。音讯在生命周期的任何一个阶段，都能够清晰地被定义并且被观测到，这就是 RocketMQ 可观测的核心理念。 RocketMQ 团队奉献的 RocketMQ exporter 已被 Prometheus 官网的开源 Exporter 生态所收录，提供了 Broker、Producer、Consumer 各个阶段丰盛的监控指标。Exporter 根本逻辑是通过在外部启动多个定时工作周期性地从 MQ 的集群上拉取数据，而后将数据规范化后通过端点裸露给Prometheus。MQAdminExt 类封装了 MQAdmin 裸露的各种接口逻辑。从构造上看，RocketMQ 的 Exporter 是站在第三方视角的观察者角色，而所有的指标来自于 MQ 集群的外部。 ...

11月3日，2022 杭州 · 云栖大会上，阿里云智能总裁张建锋示意，以云为外围的新型计算体系正在造成，软件研发范式正在产生新的改革，Serverless 是其中最重要的趋势之一，阿里云将动摇推动外围产品全面 Serverless 化，帮忙客户更好地实现麻利翻新。 这篇文章想和大家探讨下，云计算全面走向 Serverless 的偶然性。 软件架构和研发模式演变史企业的业务倒退诉求始终是推动软件架构和研发模式演变的次要力量。企业总是冀望可能更麻利的应答业务规模和复杂度的增长，更快的将产品推向市场，放慢业务翻新的速度，这就要求技术能实现大规模、简单软件的疾速迭代。 传统的企业级利用架构，通常是单体的，所有模块都耦合在一起，同时公布。这种单体架构利用在一开始是易于治理的，但随着业务倒退，会带来复杂度的大幅晋升。这种强耦合的架构带来开发、测试和运维过程中大量的抵触，拖慢了整个迭代速度。 例如，整个利用的开发要求所有模块采纳对立的语言和框架技术栈，如果一个根底库被多个模块共享，其中一个模块想要降级到新版本，则须要压服所有人同时降级，即使其他人并不需要新版本。所有模块的公布节奏被强行拉齐，一个模块的问题会影响整个利用的公布。想要疾速修复某个模块的线上问题也变得十分艰难，因为这须要和其余模块正在进行中的变更合并，解决抵触，从新公布整个利用，运行所有测试，能力从新公布上线。 所以很快，单体利用架构曾经不能满足软件研发效率的要求，被以微服务为次要特色的互联网分布式架构取而代之。 采纳微服务架构后，应用程序由独立的服务组成。这些服务是松耦合的，通过 API 调用、事件触发或者数据流的形式交互。每个服务都实现一个特定的性能，独立开发、运行和公布。微服务解决了单体架构的研发效率瓶颈，然而对利用的基础设施要求提出了十分高的要求。例如为了确保独立开发的微服务可能按预期协调配合，须要进行详尽的集成和端对端测试。测试环境中的利用部署次数通常是生产环境的10倍。如果利用基础设施不能疾速提供独立的测试环境，那么大量的测试工夫将耗费在环境稳定性问题的解决上。 依据阿里巴巴团体的研发统计数据，1人日的研发，通常对应5-7人日的测试。测试环境曾经成为阿里巴巴团体研发提效的最大痛点。微服务的松耦合，也对数据库应用，状态治理，问题诊断，利用交付流水线带来了很大的挑战。对于微服务的复杂度以及解决方案，业界曾经有十分多的探讨，这里不再赘述。以微服务为外围的互联网分布式架构，施行的复杂度较高，必须有很好的工具、平台的撑持，这是业界的共识。 在软件研发流程中，所有工作能够分为以下三类： 业务代码开发，实现业务逻辑。非功能性代码开发，包含实现容错、平安、可观测、可运维、三方软件集成等和业务逻辑无关，但又是企业应用必须具备的能力。利用基础设施治理。包含搭建开发、测试、生产环境，资源布局，平安管控等等。这三类工作中，只有第一类是对业务带来真正价值，和企业外围竞争力密切相关的。但随着软件复杂度的晋升，2、3类工作却耗费了大量的研发资源。尽可能升高2、3类工作的复杂度，让客户专一于业务逻辑开发，是软件架构和研发模式倒退的必然方向。 过来十年，无论是开源社区还是云厂商，都在不同畛域将非功能性代码开发和利用基础设施管理工作形象为标准化，可复用的软件/服务。 云计算全面走向 Serverless 化Serverless 是一个十分狭义的概念，并不局限于计算。一般而言，同时满足以下条件的服务能够称之为 Serverless 服务： 全托管服务。意味着客户应用形象的服务化接口，而不是间接面对底层资源，也就没有装置、配置、保护或者更新软硬件的累赘。全托管服务通常也提供了内置的容错，平安和可观测能力，用户通常不须要再从新构建这些能力。自适应弹性。意味着服务可能依据负载大小主动弹性伸缩，大大晋升了资源应用效率。按理论用量付费。意味着只需依据理论的执行工夫、流量或调用次数付费，升高了老本。因而 Serverless 服务外围价值在于尽可能打消客户非功能性代码开发，简化利用基础设施治理的工作，从而实现研发效率的飞跃。 阿里云智能总裁张建锋示意，Serverless 让云计算从一种资源真正变成一种能力。过来云计算用云服务器代替了物理服务器，但客户仍旧按“几核几 G 服务器”的模式来购买云资源，将来云计算将全面 Serverless 化，更加靠近“电网”模式，按计算的调用次数付费。 因为 Serverless 服务符合了研发模式演进的趋势，过来十年，咱们能够看到，各个云厂商都在一直将产品体系 Serverless 化，新的云服务或新性能大多数是 Serverless 状态。大量的开源商业产品也采纳了 Serverless 模式，包含 Confluent Cloud、MongoDB Atlas、Snowflake、Databricks 等等。 2022 云栖大会，阿里云智能总裁张建锋发表外围云产品全面 Serverless 化 阿里云是国内最早提供 Serverless 计算服务的云厂商。函数计算是一款 FaaS 产品，这是一种以事件驱动的全托管计算服务，用户只需编写代码并上传，函数计算就会主动筹备好计算资源，以弹性、牢靠的形式运行代码，并提供残缺的可观测能力，大幅简化开发运维过程。 Serverless 利用引擎 SAE 是业内首款面向利用的 Serverless PaaS 平台，屏蔽底层 IaaS 和 Kubernetes 的复杂度，提供了零代码革新、老本更优、效率更高的利用托管计划，帮用户实现单体 Web 利用、微服务利用以及定时工作的 Serverless 化。 ...

作者：木吴 关注阿里云云原生公众号，后盾回复关键词【FC】查看论文原文！ 近日，阿里云函数计算产品团队撰写的对于 Serverless 调度的创新性论文被 ACM SoCC 国内会议长文录用。 去年阿里云函数计算团队首个提出在 FaaS 场景下的去中心化疾速镜像散发技术，团队所作论文被计算机系统畛域的顶级会议 USENIX ATC’21 录用，入选中国计算机协会（CCF）举荐 A 类国内会议列表（详情点击浏览）；往年阿里云函数计算一直冲破：公布基于函数画像的调度算法论文并被国内云计算的首要会议 ACM SoCC 录用，真正做到可能保障晋升函数资源利用率的同时，达到性能高稳定性。 ACM Symposium on Cloud Computing（以下简称 SoCC）是由美国计算机协会主办、聚焦云计算技术的一项学术会议，是云计算的首要会议。它会集了对云计算感兴趣的钻研人员、开发人员、用户和实践者，是惟一由 SIGMOD（数据管理特地趣味组）和 SIGOPS（操作系统特地趣味组）联结主办的会议, 这个会议在近些年蓬勃发展，旨在汇集数据库和计算机系统两大畛域的学者，独特推动云计算技术在工业界的钻研与倒退。 此次被录用的论文为《Owl: Performance-Aware Scheduling for Resource-Efficient Function-as-a-Service Cloud》。 论文灵感诞生于阿里云 Serverless 产品函数计算，函数计算是阿里云的函数即服务(Function-As-A-Service)产品。阿里云函数计算是事件驱动的全托管计算服务。通过函数计算，您无需治理服务器等基础设施，只需编写代码并上传。函数计算会为您筹备好计算资源，以弹性、牢靠的形式运行您的代码，并提供日志查问、性能监控、报警等性能。现阶段曾经笼罩了事件驱动、音视频解决、游戏、物联网、新批发、AI 等理论业务场景，并服务于阿里云、高德、支付宝、淘宝、CBU 等多个业务或我的项目中。 上图是一个经典的 FaaS 调度零碎的架构，调度器负载将不同的函数实例调度到集群中的节点上运行。因为 FaaS 产品函数数量多、函数粒度小、执行工夫短的特点，节点的资源利用率较低。简略地将更多的实例调度到同一个节点上尽管可能肯定水平地晋升资源利用率，然而也带来了资源争抢和性能降落。 论文针对这个问题翻新地提出了基于函数画像的调度算法，在进步资源利用率的同时达到了较好的性能稳定性： 对于高频调用的函数，调度器会辨认不同函数实例在同一个节点共置时的性能体现，以此领导函数实例的调度；对于低频调用的函数，调度器会统计其执行过程中的理论资源耗费，以此来领导函数实例的调度，同时调度器会监控函数的执行延时，当呈现延时上升时通过隔离的伎俩进行缓解；调度器还针对闲置的实例进行迁徙，将它们从利用率低的节点迁徙到利用率高的节点以开释闲置节点。 为了评估算法的成果，论文依据生产环境典型的函数负载，形象了 10 个函数，它们笼罩了不同的编程语言、资源耗费、执行时长、内部依赖。列表如下： 试验结果表明，在 100 个节点规模下，OWL 调度算法可能节俭 43.8% 的资源，同时函数执行延时没有显著的减少： 调度延时也没有明显增加： 目前 OWL 的函数画像能力也曾经利用在函数计算线上环境，并获得了不错的成果。此次论文入选 ACM SoCC，是阿里云在 Serverless 调度畛域的又一次翻新。 ...

云原生平安建设曾经成为企业云原生平台建设、利用云原生化革新过程中的必备项。在云原生的大势所趋下，云的分布式架构、容器化部署、边界隐没等特点也带来了有别于传统硬件安全的模式：镜像破绽、容器逃逸、租户隔离等平安问题威逼着企业的云原生平台和利用。 阿里云联结信通院邀您参加云原生平安调研为进一步理解我国云原生平安产业倒退全貌，阿里云将联结中国信息通信研究院、云原生平安实验室独特启动 2022 年《中国云原生平安考察》问卷征集流动，以剖析企业云原生平安倒退现状、行业利用驳回度、技术成熟度。本次流动将继续至 2022 年 11 月 30 日，流动期间，所有参加调研的用户均可在提交问卷后取得一次抽奖机会，期待您的反馈！ 流动工夫：即日起至2022年11月30日流动形式：扫描下图中的二维码即可参加问卷调研 阿里云与信通院共推云原生平安标准化能力建设为了为企业云原生平安能力建设提供自检标尺和建设指南，往年5月，中国信通院联结包含阿里云在内的业界20余家单位、近40名专家历时1年实现了国内首个云原生平安成熟度模型规范的编撰。 与此同时，阿里云也成为首批实现“云原生平安成熟度评估”的云厂商，并在现规范所有 5 个域测评中均获国内惟一的全域最高等级认证，展示了阿里云云原生产品安全能力的丰盛度和当先性，通过大规模企业客户服务积攒和创新性技术打磨，继续为云上客户提供原生利用、数据、业务、网络、计算的爱护能力。 本次阿里云与信通院联结发动的“2022云原生平安考察问卷”流动征集完结后，信通院将依据问卷实在统计数据，主导撰写并面向社会公布《2022年中国云原生平安调查报告》，剖析企业云原生平安现状、分析问题和挑战，探索将来发展趋势。 阿里云云原生平安全景从容器镜像服务 ACR、容器服务 ACK 到云平安核心、Web 利用防火墙，阿里云丰盛的云原生平安产品家族保障了阿里巴巴本身的大规模云原生化实际，确保利用全生命周期的云原生平安。同时这些云原生平安能力也撑持了云上百万企业，从基础设施、云原生基础架构、云原生利用、云原生研发经营到云原生平安运维，晋升了全链路的安全性及企业平安治理的效率。 目前，阿里云正式公布云原生平安全景图，波及阿里云原生平台10余条产品线，50+款产品，共计522项外围平安能力，助力企业打造更平安可控、更先进智能的业务体系。 ACR EE 大促限时 75 折起！点击浏览原文，理解阿里云 ACR EE 与云原生制品平安托管及高效散发计划。

作者：扬少 随着云原生技术一直遍及，越来越多的业务利用开始向云原生架构转变，借助容器治理平台 Kubernetes 的不可变基础设施、弹性扩缩容和高扩展性，助力业务迅速实现数字化转型。其中，集群入口流量治理形式在云原生技术演进过程中逐渐通用化、标准化，用户通过 Kubernetes 定义的 Ingress 资源来治理内部拜访集群外部服务的形式。入口网关的标准化制订将入口流量治理与网关的实现解耦，不仅促成了各种 Ingress Controller 的倒退，而且打消了开发者存在的与厂商绑定的顾虑，日后也能够依据本身业务理论场景切换到不同 Ingress Controller。 阿里云容器服务 Kubernetes 版（简称容器服务 ACK）提供高性能的容器化利用治理服务，让用户轻松高效地在云端运行 Kubernetes 容器化利用。MSE Ingress 是在 MSE 云原生网关之上提供更为弱小的 Ingress 流量治理形式，兼容 Nginx Ingress 50 多个Nginx Ingress 的注解，笼罩 90%以上的 Nginx Ingress 业务应用场景，反对多服务版本同时灰度公布、灵便的服务治理能力以及全方位的平安防护保障，可能满足大规模云原生分布式应用的流量治理诉求。本文次要介绍如何利用容器服务 ACK 和 MSE Ingress，让集群入口流量治理更丰盛、更容易。 如何更好的灰度公布业务的倒退须要利用零碎一直的迭代，咱们无奈防止利用频繁变更发版，然而咱们能够晋升利用降级过程中的稳定性和高可用。比拟通用的做法是采纳灰度公布，俗称金丝雀公布。金丝雀公布的思维则是将大量的申请引流到新版本上，因而部署新版本服务只需极小数的机器。验证新版本合乎预期后，逐渐调整流量，使得流量缓缓从老版本迁徙至新版本，期间能够依据以后流量在新老版本上的散布，对新版本服务进行扩容，同时对老版本服务进行缩容，使得底层资源失去最大化利用。 用户借助 MSE Ingress 能够实现服务多个灰度版本共存，不便服务多个个性性能同时开发并且独立灰度验证。MSE Ingress 反对多种灰度流量辨认形式，基于 HTTP Header、基于 Cookie 和基于权重的形式，用户能够按需针对路由级别施行灰度匹配策略。 此外，MSE Ingress 针对服务的灰度版本默认提供了Fallback能力，当服务灰度版本不存在或者不可用时，流量会主动容灾到服务正式版本，在肯定水平上保障了业务利用的高可用。用户依然能够通过 MSE Ingress 提供的 default-backend 的注解来明确管制容灾服务的方向。 如何构建端到端的全链路灰度对于分布式架构的微服务利用而言，服务之间的依赖关系盘根错节，一个业务性能须要多个微服务独特提供能力，一次业务申请须要通过多个微服务能力实现解决，牵一发而动全身。 在这种场景下，业务新性能公布可能同时波及到多个服务公布，对新性能验证时就波及到了对多个服务同时灰度的问题，通过构建从网关到整个后端服务的环境隔离来对多个不同版本的服务进行灰度验证，这就是微服务架构中特有的全链路灰度场景。 目前，全链路灰度的解决方案包含基于物理环境隔离和基于逻辑环境隔离。基于物理环境隔离的做法是通过减少机器的形式来搭建真正意义上的流量隔离，该形式存在肯定的人力老本和机器老本，所以业界比拟罕用的做法是更灵便的基于逻辑环境治理。该形式尽管看起来是服务正式版本和灰度版本都部署在一个环境中，然而通过灰度路由匹配策略，能够准确管制灰度流量优先流经服务对应的灰度版本，只有当指标服务不存在灰度版本时，才会容灾到服务正式版本。从总体视角上看，针对新性能的灰度验证流量只会流经波及到待发版服务的灰度版本，对于本次新性能未波及到改变的服务，灰度流量失常通过，这种精准化的流量管制形式大大不便了开发者在微服务架构中多版本并行开发和验证的痛点，同时也升高了搭建测试环境的机器老本。 容器服务 ACK 用户，能够搭配应用MSE微服务治理和 MSE Ingress，在不改任何一行代码的状况下，轻松疾速上手全链路灰度能力，通过这种精细化的流量控制能力在用户在微服务架构治理过程中得心应手。 具体实际例子，能够参阅该文档：配置基于 MSE Ingress 的全链路灰度 ...

“阿里巴巴正在享受云上研发带来的技术红利。”11 月 11 日，阿里巴巴 CTO 程立示意，作为寰球最大、最简单的电商交易系统，淘宝首页已实现了全面 Serverless 化，显著晋升了研发运维效率，Severless 化正减速重塑阿里利用架构和研发模式。 以后，以云为外围的新型计算体系正在造成，软件研发范式正产生新的改革，容器化、Serverless 化是其中最重要的趋势之一。在 Serverless 架构下，企业通过应用形象的服务化接口方式取代传统的面向底层 IT 资源管理形式，依据负载大小主动弹性伸缩，只需依据理论资源用量计费，大大晋升了资源应用效率，进而升高了整体老本。 依靠于 Serverless 架构，云上研发形式正在产生根本性的扭转。无论用户体量是 2 万还是 2000 万，基于 Serverless 构建的 IT 架构都能够自适应伸缩，进行组装式研发，让超大规模软件系统也能具备实时弹性能力，更灵便地应用云资源。 作为寰球最大、最简单的电商零碎，淘宝领有数百业务利用组成的简单链路关系，淘宝首页采纳 Serverless 架构后可实现全链路疾速调整容量的能力，预计业务资源老本将降落 18%。 另一方面，基于容器技术，宏大简单的业务通过分层架构能够大幅晋升研发、交付效率。 以淘宝业务利用为例，上万名研发工程师常常有不少工夫要节约在 IT 运维上，频繁的降级，每月上千次的利用公布，每一次利用部署的等待时间都是对工程师宝贵时间的节约。 往年双 11 前，淘宝首页率先实现了 Serverless 化，在晋升架构一致性的根底上，将来不同团队能够更高效地降级根底软件版本通过下沉通用软件模块，利用部署时长缩短了 50%，晋升了运维效率。 据介绍，将来淘宝会把 Serverless 能力从首页笼罩到整个外围链路，最初实现全面的 Serverless 化。 “从‘阿里巴巴上云’到‘云上的阿里巴巴’，阿里巴巴正走向深度用云，通过 Serverless 化，研发更专一下层利用的开发，使得利用具备更轻量的架构、极致弹性能力和灵便用云的能力。只有全面 Serverless 化能力实现真正的深度用云。”程立示意。

作者： 纳海、孤弋 前言从 Kubernetes 诞生以来，以 DevOps、容器化、可观测、微服务、Serverless 等技术为代表的云原生，催生了利用架构新一轮的降级。有意思的是，与以往的技术迭代更新不同，本来是一个技术圈惯例的一次技术实际，在千行百业数字化转型大背景，叠加继续疫情冲击的双重影响之下，加上局部传统行业科技自主政策的催化；这一次的技术迭代简直变成了 IT 从业人员全民参加的一次盛宴。然而平缓的学习曲线、简单的技术体系、瞬态的根底资源状态，让企业的信息体系建设在研发、构建、交付、运维等多方面都带来了不少的挑战。这些挑战也加深了日益更新的技术栈与习惯于聚焦在一线业务开发的开发者之间矛盾，这个矛盾间接催生了最近的平台工程理念的诞生。这个理念抓住这个冲突点，提出了“外部研发自助平台”的构想：“企业应该以平台化建设的形式，提供一系列的自助型工具，帮助开发者在各个环节中解决遇到的各种技术问题”。这个说法一下戳中泛滥开发者的痒点，这也是这一概念忽然之间大火的起因之一。理念背地又引申进去了一个更为间接的问题：这个工具外面应该有点啥？ 揭开问题的面纱早在 2018 年，EDAS 产研团队访问一家具备百人研发团队的客户，过后客户正在进行微服务拆分和迁徙上云，他们遇到了一些新问题： 本地因为依赖问题，没法起动残缺的环境，导致开发艰难。云上环境调用关系简单，无奈做调试。客户冀望将特定的实例启动到本地，云端能调本地，本地调云端，实现微服务端云联调。对于这些问题咱们没有任何筹备，于是回来后连忙开始调研剖析，于是缓缓揭开了藏在水面下的冰山。 客户的诉求很简略，就是想把微服务利用起在本地，利用能跟云端微服务相互调用，如下所示： 迁徙上云后，客户的网关、利用、音讯队列、缓存、数据库等组件模块都部署在云端网络内，本地须要通过堡垒机能力进行拜访。在这种状况下，本地节点是不可能失常启动的（因为连不通数据库等要害组件），也是不可能跟云端服务相互调用的。采取了云原生架构之后，客户却再也回不去原来简略高效的本地开发方式了。 这个问题只有这个客户遇到吗？不是的，这几年咱们跟很多客户聊下来他们都有这个问题。但其实也不是一点解决办法都没有，最间接的方法是：通过架设公有网络的形式，连通本地办公网跟云端网络，实现网络互通。但实际上这个方法有三大缺点，导致并不是很多客户采纳。 老本昂扬：搭建专线网络的投入相当大，相比于收益来说并不划算。安全性低：买通本地到云上网络，对本地办公网和云上生产网都带来了不稳固因素，实质上扩充了平安域，也扩充了攻击面。运维简单：网络运维是相当简单的，在高度可伸缩的云原生架构下打平本地和云端网络，这个是很多网络工程师的噩梦。本地和云端两张网络必须做好布局，两边网段不可抵触，同时双向网络路由和安全策略都须要人工治理，简单费劲且容易呈现问题。对于这些问题，有的企业采取折中的方法，在云端找一台机器作为 VPN 服务器，搭建本地到云端的 VPN 链路。这个计划同样须要保护网络路由以实现网络互通，另外 OpenVPN 虽便宜但不稳固，专用 VPN 性能高但费用低廉，鱼与熊掌不可兼得。 意识到这些问题之后，咱们便开始了“路漫漫其修远兮”的摸索之路。 端云互联，问题的初解答在一开始咱们就确定两个指标：一是双向买通本地和云端链路，二是不须要对网络架构进行伤筋动骨的革新。 在历经三个月的闭关研发之后，咱们在 2018 年底研发进去了这个工具。它反对双向联通，而且是插件化开箱即用，反对 Windows 和 MacOS 零碎。咱们把它命名为端云互联，其整体组成如下所示： 端云互联插件会在启动微服务的时候拉起一个sidecar过程--通道服务，通道服务负责接管本地微服务的流量，并通过堡垒机转发至云端指标微服务。上面进一步阐明其中三个外围要点。 本地微服务调用转发到 sidecar咱们应用了 Java 原生的流量代理技术，通过注入启动参数，能够使得本地微服务流量以 socks 协定转发至通道服务 sidecar 上。对于具体参数细节，可浏览 Java Networking and Proxies 来理解细节。 sidecar 将调用转发到云端微服务其实 SSH 自身就能够用来进行数据转发，充当正向代理和反向代理。SSH 协定从下到上分为传输层、认证层和连贯层三层协定： 传输层协定（Transport Layer Protocol） ：这层协定负责建设起平安的连贯通道，是整个 SSH 的安全性基石。用户认证协定（User Authentication Protocol） ：这层协定负责实现近程身份认证。连贯协定（Connection Protocol） ：这层协定实现 SSH 通道的多路复用和信息交互，能够通过它来实现近程命令执行和数据转发等多种性能。咱们基于 SSH 的连贯协定来使得通道服务 sidecar 将调用转发到云端微服务，尽管SSH底层原理有点简单，但下层应用是挺简略的，支流的编程语言也根本都有现成的库来应用。 ...

作者：阿里云用户组 2022 年 9 月 24 日，阿里云用户组（AUG）第 12 期流动在厦门举办。流动现场，阿里云高级技术专家史明伟（花名：世如）向参会企业代表分享了《将来已来——从技术升级到降本提效》。本文依据演讲内容整顿而成。 从技术升级到降本提效 大家好，非常高兴能和大家一起分享明天的 Serverless 议题。 在后面的解说中，我看到到很多同学也是明天来到现场才有这个机会理解 Serverless。作为 Serverless 事件驱动生态、异步零碎和 Serverless 工作流的研发负责人，我心愿通过明天的分享，可能帮忙大家深刻理解 Serverless 背地的技术原理、 Serverless 如何帮忙企业实现技术升级到降本提效的指标。 同时，我也会分享一些最佳实际领导，当企业还处于容器化到 Serverless 的过渡阶段，如何利用 Serverless 进行技术升级，实现架构革新，达到降本提效的目标。最初，还会分享一些利用于理论生产的 Serverless 客户案例，帮忙大家了解 Serverless 在理论生产过程中如何应用并解决业务的痛点问题。 企业技术升级外围驱动力及痛点企业技术升级外围驱动力首先，让咱们来理解下企业生产过程中技术升级的三个外围驱动力： 第一个 就是业务快速增长和 IT 能力有余之间的矛盾带来的驱动力。 当一个新兴业务到来的时候，因为业务的不可预期性，实际上咱们很难提前对业务进行预测和布局并做好 IT 层面的根底筹备，企业须要在很短的工夫内具备与之匹配的 IT 能力撑持业务快速增长。第二个就是研发提效。 能够通过技术手段晋升研发效率，也能够通过人员优化实现目标。第三个就是企业 IT 老本优化的诉求。 无论是处在一个倒退的绝对晚期阶段，还是处在一个业务稳定增长的阶段，为了活下来，亦或是为了实现收支平衡，企业都会非常重视老本，在降本诉求的驱动下，寻求技术上的降级实现这一指标。 企业应用开发之痛《Serverless 的前世今生》这篇文章给大家做了一个很好的铺垫，帮忙大家了解为什么 Serverless 要呈现？它到底想解决的外围问题是什么？回到企业开发谋求的外围指标：更快地实现业务逻辑，缩小在环境搭建和零碎连贯上的开发工夫，将更多的工夫聚焦在业务开发上。 实现开发之后，你须要一个运行环境，将开发的业务代码部署起来提供服务，还包含运行过程中波及的相干保护工作，也就是咱们通常所说的运维。整个过程（即咱们常常所说的 DevOps）大家所面临的痛点，我想各位研发运维同学都有显著体感，总结起来也就是企业研发效率的问题。 除了研发效率，对于企业来说十分重要的另一件事就是研发老本的问题。当然，这里咱们只探讨企业研发中的 IT 老本问题，现实的模型当然是只为那些真正产生业务价值的计算去付费，但通常状况下，真正产生业务价值的计算是和业务申请生命周期统一的，真正业务申请到来之前，或者说在申请的间歇期，咱们依然须要在这些工夫为持有的计算资源付费，只管对于业务而言这些工夫计算资源都是处于闲置状态的，这也是 Serverless 心愿可能实现按申请付费实现客户降本的诉求。 为了帮忙大家更好了解依照申请付费，这里举一个 K8s 或者 ECS 的免费模式。当你购买了 K8s 之后就要付费，当你创立了 Pod 之后，集群给你调配了资源，你的申请流量并没有来的时候，依然须要为 Pod 资源付费； ...

作者：创头条 在经济面临上行压力、疫情重复等不确定因素之下，推动数字化转型就成为了许多企业的“救命稻草”。然而，较高的数字化转型门槛、不成零碎的数据服务，以及不足标准的行业标准等都成了企业数字化转型路上的“绊脚石”。 2015 年，袋鼠云成立并决然投身于具备微小想象力的数字经济倒退浪潮，通过7年致力实际，不断完善本人的数字化服务能力，在牢固地基的根底上一直向上搭建应用层，致力于让更多的企业可能一站式实现数字化转型。 现在，袋鼠云已胜利服务 5000 多家客户，涵盖金融、政务、教育、制作等 20+行业。11 月初，袋鼠云刚刚发表实现过亿元 C+轮融资。袋鼠云秉承着“让数据产生价值”的使命，以科技翻新驱动倒退，一直迭代优化解决方案和生态构造，其中与阿里云的单干不得不说。 从“打地基”到“建房子”，袋鼠云全链路布局往年 7 月，以“数智进化，当初即将来”为主题的袋鼠云 2022 产品发布会正式揭幕。发布会上，袋鼠云公布了以数栈 DTinsight、易知微 EasyV、数雁 EasyDigit、数驹 DTengine 为外围的全新产品体系。 该产品体系涵盖一站式大数据开发与治理平台、低代码数字孪生平台、数据智能剖析与洞察平台、极速湖仓引擎，将在贮存计算、开发治理和利用三个层面助力更多企业一站式实现数字化转型。这次全新产品体系降级帮忙袋鼠云实现了从“数字化基础设施供应商”降级为“全链路数字化技术与服务提供商”，也标记着它从“根底层”到“应用层”的拓展。 对此，袋鼠云董事长陈吉平示意：“Google 的安卓生态体系成熟之前，得做好安卓操作系统，同样，微软生态体系，包含 Office 崛起之前，是先做了 Windows 操作系统。用户抉择某个平台，更看中的是下面所附带的利用。咱们当初做事件的逻辑跟它们是一样。” 过来，袋鼠云专一于“打地基”，做好根底技术底座与数据治理服务，在技术层和数据价值开掘上施展出最大的劣势；现在，随着服务的深刻以及客户事实需要的呈现，袋鼠云在此之上一直地“建房子”，发明了更多应用层。 例如在银行业，规范化指标加工与治理，主动进行指标工作的调度、指标数据生成，实现监管报送、征信报送、危险管制等场景，让信贷经营更加高效。 在证券行业，通过剖析行情数据、股票交易数据、两融数据、资金等数据，进行标签萃取，造成360°的证券用户标签体系，对用户进行标签的分级分类治理，实现智能选股、智能投研、危险管制等场景，助力证券业务营销与风控。 在基金行业，通过剖析清理零碎、自营 APP、OTS 零碎、客服零碎等数据，搭建画像剖析体系，实现“业务、技术、数据”的三位一体，精准地为用户匹配理财产品。 袋鼠云将来在产品研发上将一直晋升国产大数据软件的比例，通过进步技术的深度和自主掌控力。 比方极速湖仓引擎“数驹 DTengine”中的大数据根底平台 EasyMR 基于最新的开源技术，提供 Spark、Flink、Trino、HDFS 等大数据组件和服务，可为企业提供大数据基础设施底座。 比方，袋鼠云基于长期价值登程，于 2021 年 5 月投资成立了子公司易知微，深耕数字孪生产业生态，致力于“让每一个组织和个体都看见并受害于数字化”。自主研发、自主可控的低代码数字孪生可视化平台 EasyV，联合 WebGL、3D 游戏引擎等技术，致力于建设数字加强世界，帮忙客户实现数字化治理，减速数字化转型。 同时，基于 DataOps 理念，袋鼠云整合四大产品，买通不同产品之间的流程，进步产品间的协同和联动效应，打造集数据全生命周期的开发、治理、服务于一体的一站式大数据平台，大大缩短数据体系建设的周期，并升高后续的数据经营投入老本。 11 月 9 日，易知微将举办在线发布会，包含自研数字孪生渲染引擎 EasyTwin、可视化 SaaS 平台 EasyV6.0，以及数据治理和数字孪生行业最佳实际等，将正式和大家见面。 从“保姆式”到“管家式”to B，继续为客户发明价值陈吉平负责过阿里团体数据资产与数据安全团队负责人，还曾是淘宝第一代数据仓库建设者，见证了阿里巴巴团体数据中台“从 0 到 1”的整个过程。 正是在阿里的过程中，陈吉平发现市场对大数据的强劲需要，即使是占据中国公共云市场 50%份额的阿里云也无奈齐全满足，阿里云急需生态合作伙伴。正在打算守业的陈吉平，随即自立门户于 2015 年 11 月成立了袋鼠云。 ...

作者：云原生产业联盟 在翻新倒退需要的一直驱动下，用户关注点逐渐上移，麻利成为破局高频竞争的利器。以利用为核心、屏蔽底层简单逻辑，灵便扩大，按需取用的服务器无感知（Serverless）技术合乎云时代的实质需要。能够预感，将来的计算、中间件、数据库等服务都将与服务器无感知技术深度交融。 在此背景下，中国信息通信研究院与上海交通大学牵头，联结产学研用各方于往年 7 月独特发动成立“服务器无感知翻新打算”（以下简称“翻新打算”）。 服务器无感知翻新打算启动典礼 中国信通院牵头制订了 Serverless 畛域首个行业标准《云计算服务客户信赖体系能力要求第 9 局部：函数即服务》，通过多年钻研目前已建设国内最欠缺的 Serverless 规范与评估体系，涵盖 Serverless 计算、工具、服务等维度。 为进一步摸清产业现状，探明新周期下 Serverless 倒退的新特色、新变动、新需要、新趋势，现正式发动 2022 中国 Serverless 用户考察。 本次考察依靠“服务器无感知翻新打算”，由中国信通院联结创原会、云原生社区、Serverless Devs、腾讯云 燎原社、百度智能云 云原生技术站、火山引擎开发者社区、上海交通大学 IPADS 实验室、天津大学、中国科学院计算技术研究所（排名不分先后）独特发动，参加问卷的用户有机会取得精美礼品！ 请扫描下方二维码进入问卷 截止工夫：2022.11.27 牵头发起方 联结发起方 后续，翻新打算将围绕技术钻研、规范制订、供需对接、产业交换、生态建设等方面继续发展工作，以期促成服务器无感知技术的蓬勃发展，疏导服务器无感知技术的规范化建设，推动服务器无感知技术的宽泛落地。 为凝聚各方力量，翻新打算正在招募成员单位，诚挚邀请产学研用各相干主体退出。 如有动向，请填写成员单位申报表 （点击“ 此处 ”获取） 并发送至联系人邮箱，截止工夫为2022.11.30。 调查报告及最新一批成员单位名单将在12月5日由工信部主办的 ICT中国.2022高层论坛-云原生倒退论坛 （点击查看相干信息） 上正式颁布。 开创发动单位 阿里云计算有限公司 北京百度网讯科技有限公司 华为云计算技术有限公司 上海交通大学 腾讯云计算（北京）有限责任公司 招商银行股份有限公司 中国工商银行软件开发核心 中国农业银行研发核心 中国信息通信研究院 （按首字母排序） 联系人：周老师 电话：18801269210 邮箱：zhoudanying@caict.ac.cn

作者：十眠 “从一次常见的公布说起，在云上某个零碎利用公布时，重启阶段会导致较大数量的 OpenAPI、上游业务的申请响应工夫明显增加甚至超时失败。随着业务的倒退，用户数和调用数越来越多，该零碎又始终放弃一周公布二次的高效迭代频率，公布期间对业务的影响越来越无奈承受，微服务下线的治理也就越来越紧迫。” 云原生架构的倒退给咱们微服务零碎带来了主动的弹性伸缩、滚动降级、分批公布等原生能力，让咱们享受到了资源、老本、稳定性的最优解，然而在利用的缩容、公布等过程中，因为实例下线解决得不够优雅，将会导致短暂的服务不可用，短时间内业务监控会呈现大量 io 异样报错；如果业务没做好事务，那么还会引起数据不统一的问题，那么须要紧急手动勘误谬误数据；甚至每次公布，都须要发告示停机公布，咱们的用户会呈现一段时间服务不可用。 微服务下线有损问题剖析缩小不必要的 API 报错，是最好的用户体验，也是最好的微服务开发体验。如何解决这个在微服务畛域内让人头疼的问题呢？在这之前咱们先来理解一下为什么咱们的微服务在下线的过程中会有可能呈现流量损失。 如上图所示，是一个微服务节点下线的失常流程 下线前，消费者依据负载平衡规定调用服务提供者，业务失常。服务提供者节点 A 筹备下线，先对其中的一个节点进行操作，首先是触发进行 Java 过程信号。节点进行过程中，服务提供者节点会向注册核心发送服务节点登记的动作。服务注册核心接管到服务提供者节点列表变更的信号后会，告诉消费者服务提供者列表中的节点已下线。服务消费者收到新的服务提供者节点列表后，会刷新客户端的地址列表缓存，而后基于新的地址列表从新计算路由与负载平衡。最终，服务消费者不再调用曾经下线的节点 微服务下线的流程尽管比较复杂，但整个流程还是十分合乎逻辑的，微服务架构是通过服务注册与发现实现的节点感知，天然也是通过这条路子实现节点下线变动的感知，整个流程没有什么问题。 参考咱们这边给出的一些简略的实际数据，我想你的认识可能就会变得不同。从第 2 步到第 6 步的过程中，Eureka 在最差的状况下须要耗时 2 分钟，即便是 Nacos 在最差的状况下须要耗时 50 秒；在第 3 步中，Dubbo 3.0 之前的所有版本都是应用的是服务级别的注册与发现模型，意味着当业务量过大时，会引起注册核心压力大，假如每次注册/登记动作须要破费 20～30ms，五六百个服务则须要注册/登记破费掉近 15s 的工夫；在第 5 步中， Spring Cloud 应用的 Ribbon 负载平衡默认的地址缓存刷新工夫是 30 秒一次，那么意味着及时客户端实时地从注册核心获取到下线节点的信号，依旧会有一段时间客户端会将申请负载平衡至老的节点中。 如上图所示，只有到客户端感知到服务端下线并且应用最新的地址列表进行路由与负载平衡时，申请才不会被负载平衡至下线的节点上。那么在节点开始下线的开始到申请不再被打到下线的节点上的这段时间内，业务申请都有可能呈现问题，这段时间咱们能够称之为服务调用报错期。 在微服务架构下，面对每秒上万次申请的流量洪峰，即便服务调用报错期只有短短几秒，对于企业来说都是十分痛的影响。在一些更极其的状况下，服务调用报错期可能会好转到数分钟，导致许多企业不敢公布，最初不得不每次发版都安顿在凌晨两三点。对于研发来说每次发版都是心惊胆颤，苦不堪言。 无损下线技术通过对微服务下线的流程剖析，咱们了解了解决微服务下线问题的要害就是：保障每一次微服务下线过程中，尽可能缩短服务调用报错期，同时确保待下线节点解决完任何发往该节点的申请之后再下线。 那么如何缩短服务调用报错期呢？咱们想到了一些策略： 将步骤 3 即节点向注册核心执行服务下线的过程提前到步骤 2 之前，即让服务登记的告诉行为在利用下线前执行，思考到 K8s 提供了 Prestop 接口，那么咱们就能够将该流程形象进去，放到 K8s 的 Prestop 中进行触发。 如果注册核心能力不行，那么咱们是否有可能服务端在下线之前绕过注册核心间接告知客户端以后服务端节点下线的信号，该动作也能够放在 K8s 的 Prestop 接口中触发。 客户端在收到服务端告诉后，是否能够被动刷新客户端的地址列表缓存。 如何尽可能得保障服务端节点在解决完任何发往该节点的申请之后再下线？站在服务端视角思考，在告知了客户端下线的信号后，是否能够提供一种期待机制，保障所有的在途申请以及服务端正在解决的申请被解决实现之后再进行下线流程。 如上图所示，咱们通过以上这些策略能够确保服务消费者端尽可能早实时地感知到服务提供者节点下线的行为，同时服务提供者会确保所有在途申请以及解决中的申请解决实现之后，再进行服务下线。这些想法看起来没什么问题，接下来看一下咱们是如何在 Spring Cloud 跟 Dubbo 服务框架中实现的。 ...

Grafana 9.0 是一个晋升 Grafana 易用性的版本，通过全新的和改良的操作界面来获取数据，以及默认的 Grafana 警报体验。 Grafana 的一个次要使命是让可观测性、数据可视化和剖析更容易的惠及到每个人。对于像 Prometheus 和 Loki 这样的风行数据源，编写和了解查问可能很艰难。在 Grafana 9.0 为这两个数据源提供了新的可视化查问生成器。这些可视化查问生成器将升高学习老本，帮忙任何人编写、了解和学习底层查询语言。 该版本还包含一个全新的弱小和疾速的热力求可视化，一个更容易拜访的导航菜单，仪表板搜寻的改良，高级平安和认证性能，等等。 全新的和改良性能列表: 新的 Prometheus 查问生成器新的 Grafana Loki 查问生成器新的导航条及搜寻新的 Explore 性能新的 Panel 面板新的 Grafana Alerting 新的 Prometheus 查问生成器PromQL(Prometheus Query Language)是一种弱小的查询语言，有着非常复杂和高级的查问语法。但对于 Prometheus 老手来说，即便是绝对简略的查问语句，也是难以编写和浏览的。 Prometheus 的新 UI 查问生成器正是为了解决这个问题而建设的。在 Grafana 9.0 中，你将在 Explore 中看到一个全新的可视化查问生成器界面，它容许任何人编写和学习 Prometheus 查问是如何工作的。 指标(Metric)和标签过滤器(Labels)新的查问生成器容许你通过多词搜寻来搜寻和抉择一个指标。你能够从抉择一个指标或一个标签过滤器开始。 对指标进行操作(Operations)Operations 字段用于通过各种函数(Functions)、区间函数(Range Function)、聚合(Aggregations)和二进制操作(Binary Operations)对感兴趣的指标进行数学操作。你能够通过 + Operation 按钮将这些操作分层。因为 Operations 是依照执行的程序出现的，而不是依照文本查问中的倒序排列，这使得浏览和编辑查问变得更加容易。 反对多种形式来编写 PromQL您能够抉择在文本编辑模式（Code）或可视化查问生成器模式（Builder）中编写 PromQL 查问。你能够在这些模式之间进行切换，同时保留你的 PromQL 批改。 PromQL 执行打算(PromQL Explain)如果你是 PromQL 的老手，你能够应用第三种模式，即 Explain，通过理解曾经写好的 PromQL 的执行打算。你能够在 Builder 模式和 Explain 模式之间切换，同时保留查问，以理解更多对于被查问的指标执行的操作。 ...

流动介绍微服务 x 容器开源开发者 Meetup 是由阿里云飞天 club 与云原生利用平台独特打造，面向一线开发者的技术交流活动，整体内容聚焦容器 & 微服务方向，旨在通过热门的开源技术、云原生在企业的利用实际案例、架构设计思维等，帮忙开发者学习云原生技术、交换实际中的问题和痛点，推动云原生技术和架构的规模化利用落地过程。 百花齐放逐梦云原生，开源分享赋能开发者。12 月 03 日上海站，微服务x容器开源开发者 Meetup 将围绕云原生畛域当下 11 个热门开源我的项目的技术分享和企业实际开展，邀请到 Spring Cloud Alibaba、Dubbo、OpenYurt、KubeVela、OpenSergo 等云原生畛域传统&新锐开源我的项目外围维护者，为大家分享社区最近动静、架构实际及企业应用案例等精彩内容。 流动信息流动日期：2022年12月03日（周六） 流动工夫： 09:00-17:00 流动地址：上海 · 阿里巴巴西岸国内人工智能核心-7N01 百鸣山庄 流动限额抢报中... 点击“ 此处 ”或扫描下方二维码即可报名 分享嘉宾及议题介绍09:30-10:00 | Spring Cloud Alibaba 全新异地多活解决方案 饶子昊（铖朴），Spring Cloud Alibaba 开源我的项目负责人 Spring Cloud Alibaba 社区负责人，阿里云研发工程师，参加阿里云微服务引擎 MSE，企业级分布式应用平台 EDAS，云服务总线 CSB 等多个云产品研发 议题简介： Spring Cloud Alibaba 在联结 AppActive 为 Spring Cloud 生态带来了利用于阿里巴巴外部多年的异地多活解决方案，为宽广社区内外部用户构建高可用零碎提供解决方案。 10:00-10:30 | OpenSergo 微服务治理重磅反对 Go 生态 赵奕豪（宿何），OpenSergo & Sentinel 开源负责人 阿里云云原生利用平台技术专家，在微服务稳定性及治理畛域具备多年的实践经验，致力于推动微服务治理标准化，目前次要负责微服务治理畛域技术演进及产品化 议题简介： 在古代微服务架构中，针对简单微服务架构的稳定性治理是宽广开发者关注的重点。OpenSergo 由多家企业联结发动，从微服务的角度登程，涵盖流量治理、服务容错、服务元信息治理、平安治理等要害治理畛域，提供一系列的治理能力与规范、生态适配与最佳实际。本次分享将为大家整体介绍 OpenSergo 微服务治理场景、规范与生态，并重磅公布 OpenSergo Go 生态反对。 10:30-11:00 | Higress: 云原生趋势下 Ingress Controller 新抉择 范扬（扬少），Higress 联结创始人 MSE 云原生网关外围研发，Higress Maintainer 议题简介： 本次分享将介绍 Ingress Controller 开源新星 Higress，以及 Higress 在 集群入口流量治理上的最佳实际。 11:00-11:30 | 云原生利用脚手架正式开源 陈曦(良名)，云原生脚手架开源我的项目负责人 阿里巴巴技术专家，Spring Cloud Alibaba Member，致力于将阿里云打造为 Java 开发者最好用的云 议题简介： 云原生利用脚手架开源介绍，介绍脚手架的性能、定位，以及近期的产品布局。 11:30-12:00 | Dubbo 开源现状的思考与将来布局 江河清(远云)，Apache Dubbo PMC ...

作者：赵奕豪（宿何） 为什么须要微服务治理与 OpenSergo？在经典微服务架构中，咱们通常将服务调用中各角色划分为三局部：服务提供者、服务消费者、注册核心。经典的微服务架构能够解决微服务能调通、能够运行起来的问题。随着分布式服务架构的一直演进、业务规模的扩张，诸多简单的稳定性与易用性问题显现出来，这时候就须要一些伎俩来针对日益简单的微服务架构进行“治理”。微服务治理就是通过流量治理、服务容错、平安治理等技术手段来缩小甚至防止公布和治理大规模利用过程中遇到的稳定性问题，对微服务畛域中的各个组件进行治理。服务提供者、消费者、注册核心、服务治理，形成古代微服务架构中重要的几环。 微服务治理是把微服务做稳做好的要害一环。然而，业界微服务治理存在概念不对立、配置模式不对立、能力不对立、多框架对立管控较为简单等问题。比方咱们心愿配置流量灰度规定，在 Spring Cloud Alibaba 中可能须要通过 YAML 形式配置，在 Dubbo 中须要通过另一种配置格局进行配置，在 Istio 体系内中可能又须要通过 Istio CRD 的形式进行配置。不同框架治理配置形式的不统一使得微服务对立治理管控的复杂度相当高。另外，业界的各种框架反对的服务治理能力都不对立，且通常比拟根底，很多时候无奈笼罩生产级的场景。 基于下面这些痛点，阿里巴巴在 2022 年 1 月开始和 bilibili、字节等企业探讨服务治理如何规范化和更加遍及，从而独特发动了 OpenSergo 我的项目。OpenSergo 是凋谢通用的，笼罩微服务及上下游关联组件的微服务治理我的项目，从微服务的角度登程，涵盖流量治理、服务容错、服务元信息治理、平安治理等要害治理畛域，提供一系列的治理能力与规范、生态适配与最佳实际，反对 Java, Go, Rust 等多语言生态。OpenSergo 的最大特点就是以对立的一套配置/DSL/协定定义服务治理规定，面向多语言异构化架构，笼罩微服务框架及上下游关联组件。无论微服务的语言是 Java, Go, Node.js 还是其它语言，无论是规范微服务还是 Mesh 接入，从网关到微服务调用，再到微服务对数据库/缓存的拜访，开发者都能够通过同一套 OpenSergo CRD 标准配置进行对立的治理管控，而无需关注各框架、语言的差别点，升高异构化、全链路微服务治理管控的复杂度。 OpenSergo 提供 Java、Go 等多语言的 SDK，各个框架生态能够十分不便地通过 OpenSergo SDK 来对接 OpenSergo 标准配置，接入到 OpenSergo 生态中，通过 OpenSergo 管制立体 (Control Plane) 对立治理服务治理规定。 微服务视角的数据库治理是保障服务稳定性的要害一环提到“微服务治理”，很多开发者会首先想到针对微服务之间的调用流量进行治理，但很多时候大家容易漠视掉微服务拜访存储与其它中间件的这部分流量。在一个实在的业务生产环境中，流量首先先进入入口网关（如 Nginx、Envoy），再流转到后端 Web Server，再流转到微服务之间的 RPC 调用，再流转到针对数据库、缓存、音讯等存储/中间件的拜访。在这样一个全链路的架构中，仅仅关注微服务之间的调用是不够的，咱们须要针对链路中的每一环别离进行针对性的治理。其中微服务对数据库的拜访是十分广泛的，也是容易呈现稳定性问题的一环。比方： 某个利用某类报表 SQL 访问量十分大，且查问十分耗费性能，把数据库 CPU 打满慢 SQL 拜访十分多，占满连接池/业务线程池，导致服务无奈解决失常申请，甚至导致级联雪崩连接池参数配置不合理，导致大量 SQL 写操作时无奈无效获取连贯，业务大量报错数据库拜访须要按环境标进行隔离，比方灰度数据写入到灰度表中  ...

11 月 3 日，天池大赛·第三届云原生编程挑战赛在杭州云栖大会圆满收官。三大赛道18大战队手历经 3 个月强烈的角逐，终于交上了称心的答卷，同时也捧回了属于他们的光荣奖杯。 云原生编程挑战赛发起人王荣刚在收场分享中提到，“在阿里外部有一种文化叫工程师文化，所以 2015 年咱们设计了第一届中间件性能挑战赛，让大家挑战双十一场景下的极致性能，大赛一经推出就受到了技术同学的好评，起初咱们想为什么不把大赛面向全国高校凋谢，学生群体作为将来开发者的主力，让大家提前能学习到最新最前沿的技术，并使用到实际中，这应该是一件很 cool 的事件，所以咱们就开始面向高校学生凋谢，也受到了寰球高校选手的青眼。起初咱们又把大赛面向社会选手凋谢，咱们也会依据每年不同的状况，设计西行游学、24 小时极客挑战赛，多赛道解围等赛制，缓缓的有了咱们现在的大赛样子。大赛的赛题也从原来的中间件微服务、音讯、畛域，扩大到当下最炽热的云原生畛域。2020 年咱们确定云原生的时代曾经到来，于是咱们把大赛更名为云原生编程挑战赛，涵盖容器、Serverless、中间件等泛滥畛域，每年咱们都会和大家探讨新的技术趋势，设计新的赛道，让开发者感触到云原生的价值。” 云原生是将来十年最热的技术趋势之一，对于每一个参赛团队而言，解决这些技术问题和挑战，都会为大家积攒教训和技能。天池大赛·第三届云原生编程挑战赛，共吸引了 17900+ 支队伍，超过 18000+ 选手报名参赛，笼罩中国、美国、德国、加拿大、新加坡等 13 个国家和地区，汇聚 440+ 国内外顶尖高校和 240+ 当先企业，企业选手占比达 30%+，其中决赛企业选手占比达 75%，大赛规模再创新高！ 通过强烈角逐，本届云原生编程挑战赛三大赛道冠亚季军诞生。 云原生作为一直倒退后退的技术浪潮，吸引了越来越多的年老力量，将来十年是云原生的黄金时代，也是开发者们的黄金时代。阿里云智能开发者关系负责人、阿里云智能培训中心负责人孟晋宇示意，“2020 年的首届云原生大赛，就吸引到超过万名开发者参赛，是业界首个万人规模的云原生赛事。2021年，咱们设置了三个赛道，让开发者在更细分的畛域发现志趣相投的敌人。往年的大赛，除传统的 Serverless 外，咱们设置了服务网格和边缘容器两个新赛道，对不少开发者来说是新常识，有学习门槛。但即便这样，咱们再一次刷新了大赛规模，再次验证了云原生技术对开发者的微小吸引力。” 相干浏览：为研发效力而生｜一场与 Serverless 的博弈 登顶之路｜数字海南架构师谈云原生编程挑战赛参赛心路历程 云原生编程挑战赛决赛名单公布，巅峰问难行将开启 【周周有奖】云原生编程挑战赛“边缘容器”赛道邀你来战！ 云原生编程挑战赛炽热开赛，51 万奖金等你来挑战！ 有奖征文 | 2022 云原生编程挑战赛征稿流动开启！ 2022 云原生编程挑战赛炽热报名中！看导师如何拆解 Serverless 赛题？ 2022 云原生编程挑战赛启动！导师解析服务网格赛题 官宣！第三届云原生编程挑战赛正式启动！

作者：风敬 本文篇幅超过 7 千字，通读全文大略须要 20 分钟。文章内容源自大量实在场景的积淀和剖析，倡议珍藏，以供查阅。在 K8s 中，Pod 作为工作负载的运行载体，是最为外围的一个资源对象。Pod 具备简单的生命周期，在其生命周期的每一个阶段，可能产生多种不同的异常情况。K8s 作为一个简单零碎，异样诊断往往要求弱小的常识和教训储备。联合实战经验以及 EDAS 用户实在场景的演绎，咱们总结了 K8s Pod 的 13 种常见异样场景，给出各个场景的常见谬误状态，剖析其起因和排查思路。 Pod 生命周期在整个生命周期中，Pod 会呈现 5 种阶段（Phase）。 Pending：Pod 被 K8s 创立进去后，起始于 Pending 阶段。在 Pending 阶段，Pod 将通过调度，被调配至指标节点开始拉取镜像、加载依赖项、创立容器。Running：当 Pod 所有容器都已被创立，且至多一个容器曾经在运行中，Pod 将进入 Running 阶段。Succeeded：当 Pod 中的所有容器都执行实现后终止，并且不会再重启，Pod 将进入 Succeeded 阶段。Failed：若 Pod 中的所有容器都已终止，并且至多有一个容器是因为失败终止，也就是说容器以非 0 状态异样退出或被零碎终止，Pod 将进入 Failed 阶段。Unkonwn：因为某些起因无奈获得 Pod 状态，这种状况 Pod 将被置为 Unkonwn 状态。一般来说，对于 Job 类型的负载，Pod 在胜利执行完工作之后将会以 Succeeded 状态为终态。而对于 Deployment 等负载，个别冀望 Pod 可能继续提供服务，直到 Pod 因删除隐没，或者因异样退出/被零碎终止而进入 Failed 阶段。 ...

11 月 5 日，在 2022 杭州 · 云栖大会上，数字化平安生产平台 DPS 重磅公布，助力传统运维向 SRE 转型。 阿里巴巴资深技术专家 周洋 十四五布局下，各行各业全面减速数字化转型与降级。随着企业数字化业务规模变大，迭代速度放慢，零碎复杂度越来越高，如何保障业务稳定性这一话题也变得愈发重要。下述有几点典型场景和挑战： 场景一：分布式系统面临稳定性保障新挑战近年来，尽管稳定性关注度日益进步，新技术蓬勃发展，重大故障仍然频发且影响微小。例如，2021年，某证券 IDC 故障 2 小时，导致客户无奈交易，产生资损；某视频网站，服务器故障 3 小时无法访问，引发舆论……技术的不失当应用、人为操作失误、硬件故障、自然灾害、平安攻打仍然给生产带来极大危险。 场景二：政策疏导IT零碎稳定性建设安稳推动随着数字化转型政策的推动，越来越多国民级利用诞生，大大不便了人们的日常生活，各个企业也相继推出本人的客户端。然而，大多数企业没有经验过多年互联网倒退的锻炼，应答线上危险能力有余，亟需以最短时间实现稳定性运维能力的积攒，少走弯路。 场景三：传统运维伎俩已无奈满足要求传统运维存在运维工具割裂、面向基础设施而非业务、被动运维、不足规范化的流程机制体系等问题。企业应遵循 SRE（Site Reliability Engineering）和平台运维（Platform Ops）的翻新理念，通过软件来实现系统管理、问题发现、问题解决和自动化运维工作。 在现实生活中，无论建造摩天大楼还是家庭工程保护，在保障工程质量的同时，更重要的是避免出现安全事故，造成人员挫伤，因而须要一套标准化的工艺流程、技术标准和验收伎俩等。在软件行业中，同样须要标准化的技术能力和方法论，来保障线上业务稳定性。于是，从 2018 年起，阿里巴巴团体便致力于 IT 软件畛域的平安生产建设：一方面增强高可用架构的根底建设，另一方面，提供 SRE 转型的流程机制体系，配合可用性能力、组织能力和劫难恢复能力等指标，造成一套残缺的平安生产办法体系。 为此，数字化平安生产平台（DPS）应势而生。DPS 稀释了阿里巴巴十年运维教训，以 PlatformOps 为理念，以保障业务连续性为指标的一站式管控 SRE 运维平台，具备场景化、数字化和云原生化三大典型特色。 场景化： DPS 以应急场景为核心，弱化组织架构带来的运维限度，同时，DPS 全面的监控和告警规定配置能够反对涵盖业务的各个场景。数字化： DPS 提供数字化监控大屏、智能化告警、智能故障定位、白屏化故障快恢伎俩和数字化度量、人员治理等能力，为企业数字化过程添砖加瓦。云原生化： DPS 以阿里云丰盛的云原生产品作为技术撑持，且具备足够的开放性，能够与阿里云一方、二方和开源零碎等进行关联。数字化平安生产平台 (DPS) 作为阿里巴巴团体数十年互联网摸索的积淀，在平台的架构和演进方面次要关注以下几点： 明确指标和场景： 平安生产是全局工程，其能力取决于木桶最短板。因而平安生产须要有明确的指标和场景，且保障主体框架的残缺。买通组织架构： 平安生产不仅要解决人和零碎、代码的问题，还须要解决人和人、人和制度的问题。因而平安生产须要阿里和行业的优良技术在一个体系内集成和买通。 面向未来架构： 平安生产同时关注老本和缩小损失。因而，平安生产需具备肯定的抗技术周期性，架构设计除了要兼容最新的技术栈，也要面向未来架构进行设计。 数字化平安生产 DPS 反对两大典型业务场景：“1-5-10”故障快恢和“变更三板斧”故障预防。 “1-5-10”故障快恢数字化平安生产平台提供对应急事件和故障的发现、响应和复原的全生命周期治理。“1-5-10” 对应故障的“1 分钟发现 - 5 分钟响应- 10 分钟复原”，是定义故障解决的时效性指标。 1 分钟发现： 通过建设围绕业务利用的全链路监控能力，可能实时监控业务衰弱度，如发现稳定性问题将秒级通报至应急保障服务组进行排查，升高故障产生的可能性。5 分钟响应： 通过建设应急响应渠道和全链路故障定位能力，可能疾速拉通故障排查人员，基于AIOps智能故障定位和基于ChatOps进行故障状态更新和告诉流转，晋升故障解决效率。10 分钟复原： 通过建设欠缺的故障快恢体系，基于计划内置丰盛的快恢能力，可能依据不同的故障类型智能化举荐适合的快恢预案，缩短故障复原时长。 “变更三板斧”故障预防数字化平安生产平台 DPS 将极易引发线上故障的变更操作纳入稳定性管控体系，做到对变更操作的“可观测、可灰度、可回滚”。 在“变更可管”方面，咱们笼罩欠缺的变更零碎，极大水平缩小对变更零碎的革新老本；在“变更可控”方面，咱们提供基于工夫、人员等维度的变更管控规定，预防可能呈现的危险；在“变更可用”方面，咱们可主动发现变更引发的故障，提供变更回滚等智能化快恢能力。 ...

看上去是像Excel一样的在线协同表格，却能把文件、表格、图片、视频、填表单等变换出各种视图，它能帮忙你高效不便的治理各种系统的信息和数据；也能依据你的想法DIY各种性能，5分钟即可搭建一个适宜本人的文档管理系统，实现数据高效剖析流通、信息整顿跟踪自动化…… 其实，它的性能还远不止于此。维格表将Excel、可视化数据库、实时网络合作、低代码开发技术“四合一”，同时反对API与可视化看板。 维格表创始人陈霈霖示意：“维格表的外围特点在于，表面像电子表格，性能延展性又像数据库那般弱小。因为它既有低代码的根底，又具备SDK、API甚至在线编程等高代码的能力。” 作为多维表格的首创者，维格表打造了一套可配置的新型数字化零碎，提供1000种以上的零碎模板，可满足不同行业宏大简约的数据管理需要，并且将简单的SaaS软件简化得像Excel一样灵便易用。 把 SaaS软件简化得像Excel一样简略互联网的下半场，来到产业互联网的主战场。站在数字化转型的风口上，各行各业都在涌入转型大潮。市面上也充斥着各种帮忙企业数字化转型的SaaS软件。然而，无论是OA、ERP零碎，还是CRM、PDS软件，它们的流程往往十分固化，在不同的畛域要买不同的软件，还要不同的落地流程，价格还很贵。 2019年初，陈霈霖的亲戚经营了一家服装店，抉择了多款经营软件系统都用不惯，最终还是用起了Excel。彼时，陈霈霖正负责喜茶CTO，率领着百人团队一手打造出“喜茶GO”小程序，解决了用户和公司长年头疼的排队难题。 这家服装店的痛点引起了陈霈霖的留神。 陈霈霖发现，在传统的业务中可操作的数据界面跟关系型数据库是分来到的，企业为此须要洽购大量可操作的数据界面。而市面上很多软件并不能无效满足企业简单多样的业务需要。甚至有的即便洽购了新零碎，依然须要多个Excel表格来撑持工作。 陈霈霖在想，为什么不能把这两局部进行整合，并且保留像Excel一样简略的操作，这样业务人员都能简略地上手。 于是，他萌发了打造一款全新数据合作工具的想法。 2019年底，陈霈霖裸辞守业，创建深圳维格云科技有限公司。把传统的软件技术变成一种可操作的数据界面，而后用关系型数据库把它给串起来，这是vika维格表要做的事件。 几个月之后，维格表便公布了外围产品“维格表vika.cn”。这款帮忙企业进行数据管理的软件，交融了数据库与Excel电子表格性能，将简单的SaaS软件简化到像Excel一样简略。 维格表反对图片、视频、文档等数据存储，能够将集体、工作碎片化的信息结构化地整顿起来。 在应用维格表前，公司人手一份Excel，各种文件满天飞，重要业务数据资料散落各处，无奈实现共享。应用之后，不同部门的重要数据文件均可保留在云端工作站，部门内可实时协同在线编辑，突破传统文件互传和业务壁垒带来的数据孤岛效应。 作为多维表格的首创者，维格表成为很多软件服务产品的连接器，以往这些产品的数据都来自Excel。另外，维格表还能帮忙用户轻松实现项目管理与团队合作，不必写代码就能够做出适配业务倒退须要的IT零碎，即便不懂编程也能搭建本人的数据库。 维格表给企业提供了一种对于数字化转型的全新思路，即如何用关系型数据库、一种可视化的SaaS思维去从新扫视整个世界。 作为国内SaaS赛道中的全新品类，维格表也面临诸多挑战。其中之一便是外界对维格表的认知天壤之别，有人将其称为低代码工具，有人认为是一种更先进的电子表格，还有人了解为协同办公。如何从零开始进行市场教育，成了摆在维格外表前一道难题。 如同一把能解锁数字化生产力宝藏的万能钥匙陈霈霖谈道：“维格表是一款可视化的数据库，其外围特点在于表面像表格，性能的延展性又像数据库。这基于维格表既有低代码的根底，又具备SDK、API甚至在线编程等高代码的能力。” 在任意一张维格表上点击右上角的API按钮，一键弹出API窗口，用十分简短的代码，应用Python、JavaScript等编程语言的SDK，实时对数据进行读取、批处理、回写，连贯其它业务零碎，能生成插件，解锁各种性能。 早在成立之初，陈霈霖就并未将其只定位为一款纯工具产品，而是要从技术产品到解决方案的赋能者。 这次要体现在，维格表要与其它软件进行连贯，疾速搭建轻量级的解决方案零碎，满足用户多样化需要。另外，反对API和嵌入，当企业须要基于软件做各种扩大时，只需把维格表嵌入进去，无需大量工程师搞开发，从而升高研发和交付老本。 陈霈霖介绍：“不少大型科技公司用维格表做生产系统管理，还有客户间接把维格表当成一个数据库、API去调用，把多维表格嵌入到他们的软件系统里，就能够帮忙客户做交付。” 在此过程中，维格表也实现了商业化从0到1的冲破。 据陈霈霖介绍，维格表的第一个客户就是购买API服务。还有客户估算花100万研发将后盾数据库做出可操作的界面，嵌入维格表只须要花2万多元。也有客户在打印插件上嵌入维格表，只需把数据填入维格表中就能打印出100个不同的文档。 “维格表让企业过来100个程序员1年能力做成的零碎，缩短到1个文员1天就能实现。维格表想要解决的终局行业问题，一是降低成本，产生真正的价值；二是进步工作效率，帮忙公司早上班。”陈霈霖称。 维格表产品刚上线三个月，就接触到数千家企业客户，并实现7位数营收，其中大多数为亿元营收以上中大型企业客户。2021年12月，维格表实现盈亏均衡。 维格表打造了一整套可配置的新型数字化零碎，能提供1000种以上的零碎模板，波及项目管理、客户治理、数据BI、市场流动、营销中台、企业数据库、OKR等企业各个业务条线，能无效满足互联网、电商、教育、生产、制作、政务等全行业盘根错节的数据管理需要。 维格表就像一把能解锁数字化生产力宝藏的万能钥匙，人人能够轻松上手。而反对API，能够帮忙客户定制个性化需要。作为数据中台，维格表可连贯万物，让数据合作起来真正实现驱动组织翻新。 艾瑞征询的数据显示，自2016年起国内企业级SaaS市场规模就呈稳步扩张趋势，到2020年市场规模约为538亿元，同比增长48.7%，预计到2023年将达到1304亿元。 在陈霈霖看来，SaaS这个赛道在国内尚不乐观。他举例道，SaaS全称是software-as-a-service（软件即服务），然而国内常常将它称为service-as-a-software（服务即软件），前者偏重software，后者偏重service。因而，目前国内SaaS软件公司不只承当service的老本，还得负责software的研发费用。 陈霈霖说：“这只是翻译层面上的一个缩影。其实真正的SaaS和企业服务天壤之别，国内SaaS类产业处于比拟晚期的阶段，很可能对标上世纪70年代重服务的美国软件业。” 此外，SaaS行业广泛面临着人力老本高企、续费率大跌、现金流吃紧等难题……陈霈霖判断，随着钱袋子越来越紧，国内SaaS行业必将走向分化，将来强人恒强，弱者渐亡的“马太效应”会更加显著。 成长在阿里云，云原生加速器助力SaaS企业打造全新交付模式千行百业上云，让云原生的概念变得“炽热”起来。然而，随着云的生态和边界一直延展，其定义也是形形色色。 陈霈霖认为，云原生是一种以容器为根底的运维形式，它最外围的价值就是造成对立的规范，从而升高外部的运维老本、交付老本，加强客户的稳定性。 从整个生态来说，云原生代表了一种全新的软件交付模式。它为商业软件的App Store发明了可行性。 “过来咱们须要软件就必须跑去电脑城买光碟，当初只有在手机App Store点一下即可。生产级软件早就实现了App Store化了，商用级软件却还迟迟未能实现。这次要是因为部署太简单，云原生的呈现为当前商业软件APP Store发明了机会。”陈霈霖示意。 事实上，云原生领有传统IT无法比拟的劣势。它能从技术理念、外围架构、最佳实际等方面，助力企业实现“云”落地，是帮忙企业数字化转型的最短门路。 2021年11月，阿里云公布云原生加速器。阿里云云原生加速器帮忙企业以更“聪慧”的形式去经营，节俭不必要的工夫破费，可能专一地聚焦业务价值发明以及翻新。 陈霈霖云原生加速器路演问难现场 阿里云领有国内最丰盛的云原生产品家族和最宽泛的云原生客户群体，笼罩各行各业。80% 以上的中国科技公司都是跑在阿里云上。 在与阿里云的深刻单干中，陈霈霖最大的感触是，阿里云“以客户为核心，求实不自嗨”。 陈霈霖在云原生加速器业务共创交流活动 “阿里云非常重视落地。”陈霈霖深有感触：“之前加入过云原生加速器的流动，大家集思广益，一起探讨怎么为客户发明价值，如何把产品销售进来，维格表从中受到很多启发。” 国内云厂商星散，为企业数字化转型提供诸多便当。陈霈霖坦言，“守业型公司不足资源和资金，心愿与云厂商单干共享基础设施和流量，真正帮忙企业实现天下没有难做的生意。”

容器技术曾经逾越鸿沟，广泛应用于金融、通信、制作、交通等千行百业。Kubernetes撑持的工作负载也从晚期繁多的互联网利用倒退到数据库、AI、大数据等等，并笼罩了公共云、专有云、边缘云等多样化、动静的云环境。 11月5日，2022杭州 · 云栖大会上，阿里巴巴研究员、阿里云智能云原生利用平台容器技术负责人易立在云原生峰会上发表主题演讲，公布阿里云容器服务全面智能化降级，帮忙企业精益用云，以增效促降本，实现IT架构在云上的高质量倒退。 容器服务助力企业数字化翻新通过7年的倒退，阿里云容器服务产品线曾经成为企业的云原生操作系统。基于阿里云容器平台，阿里团体实现了100%业务云原生上云。 2021 年，阿里云公布了 ACK Anywhere，进一步拓展产品的宽度，笼罩从公共云、边缘云、到本地数据中心的各个场景。让所有须要云能力的中央，都能基于对立的容器基础设施之上。 得益于阿里团体和阿里云的大规模容器利用实际，阿里云容器产品能力失去了业界的宽泛认可 。 2022年1季度，在权威咨询机构Forrester 公布的寰球公共云容器平台分析师报告中，ACK稳居寰球领导者象限，这也是中国科技公司首次进入该象限；2022年2季度，在 Omida 公布的寰球容器治理解决方案报告中，因为在公共云、专有云、混合云等环境欠缺的产品体系，ACK成为寰球领导者，产品能力与规模国内当先；2022年8月，在CSDN 2022中国开发者调查报告中，有52%的国内开发者抉择阿里云容器云平台。 过来几年，降本增效成为了泛滥企业IT管理者关注的重要问题。企业曾经到了精益用云的时代，晋升资源效率、研发效率，IT管理效率成为要害。 四大全新降级，阿里云容器服务迈入智能化时代智能化是容器平台倒退的必然趋势。明天，阿里云基于过来10年的大规模容器实战经验，通过数据化伎俩和智能化算法，推动容器服务ACK面向基础设施层、容器编排层、利用架构层和经营治理畛域 4 大维度全面降级，迈入智能化新阶段。 降级1：新算力在基础设施层，利用面向云原生优化的新算力，晋升计算效率。 2021 年，阿里云公布了新一代云原生CPU，倚天710，基于ARMv9架构，曾经在电商、阿里云外部规模化利用，实现了卓越性价比。 相比 X86 芯片，典型 Web 利用性价比高50%，视频编解码利用性价比高 80%。倚天芯片面向云原生优化，vCPU 采纳独立物理核，没有超线程架构中的性能争抢。能够提供更加确定性的性能。 ACK 通过对芯片微架构的拓扑感知调度优化，相比开源K8s实现，帮忙 Web 利用吞吐晋升 20%。 为了更好反对 AI、HPC等I/O密集型利用。ACK 正式提供了对eRDMA高性能容器网络反对。 通过软硬一体优化的网络实现，能够提供更高的带宽与更低的提早。利用在AI训练减速20%，微服务吞吐晋升10%； ACK 反对多容器高效复用eRDMA设施，满足了容器利用部署密度的需要。 为了更好反对有状态利用容器化，阿里云公布新一代容器网络文件系统 CNFS 2.0，它采纳全链路减速技术，能够实现： 容器利用对后端存储系统的拜访并行化，晋升网络带宽的利用率。对近程NAS存储的吞吐能够晋升100%，满足高性能AI训练和基因计算的需要。利用元数据缓存和独有的lease机制，使得近程文件存储的元数据拜访性能，晋升了18倍，非常适合Web利用和CI/CD等须要对海量小文件进行拜访的场景。反对文件的通明生命周期治理，能够主动将低频拜访的冷数据搁置在低成本的NAS低频介质或OSS中，升高存储老本50%以上。它反对对NAS/CPFS/OSS全链路可观测，帮忙开发者更好诊断和优化I/O性能问题。 企业与集体对数据隐衷爱护日益关切，秘密计算技术应运而生。其中一个重要的技术是通过芯片的可信执行环境（TEE）实现数据保护。在TEE内执行的利用，不必放心来自其余利用、其余租户或者平台方的威逼。 为了进一步推动秘密计算的遍及，阿里、蚂蚁团队在Kata Container社区与红帽、Intel等公司进行单干，将容器计算与可信执行环境相结合，推出秘密容器 Confidential Container 我的项目，同时为 Intel® SGX、Intel® TDX等不同的TEE实现，提供了统一的容器界面。 基于新一代的秘密容器架构，开发者能够确保利用是通过可信软件供应链进行构建和散发的；容器利用运行在可信执行环境中，具备更小的攻击面，而且所有内存中数据是加密的并受完整性爱护；利用对数据的拜访是基于加密的可信数据存储服务。 秘密容器能够在须要隐衷数据处理的场景中，如金融风控、医疗衰弱等，提供高效的隐衷增强型算力。 降级2：新平台在容器编排层，通过智能化、云边端一体的新平台，晋升资源利用率和运维效率。 K8s目前曾经成为云时代的操作系统。心愿充分利用多种利用负载之间的削峰填谷，晋升K8s集群资源利用率。这也是大家常说的“混部”能力。 阿里巴巴早在 2016 年就启动了云原生混部技术研发，历经多轮技术架构降级和双11锻炼，目前已实现全业务规模超千万核的云原生混部，日常CPU利用率在 50% 左右。 ...

作者：奥陌 11 月 5 日，在 2022 杭州 · 云栖大会上，云原生技术中台 CNStack2.0 正式公布。 阿里巴巴资深技术专家 谢吉宝介绍 CNStack2.0 企业在数字化转型的过程中，一部分问题失去了解决，但随着 IT 程度的一直晋升，新问题也在逐步浮现。业务零碎越加简单，所需的计算、存储和网络设施也变得越来越难以治理。 以往一台虚拟机、一个数据库便能部署利用的时代曾经一去不复返了。简单的零碎架构须要更多根底软件的反对能力良好运行，而开源社区的蓬勃发展，尽管为决策者提供了更多抉择的可能性，但从选型开始问题就接踵而至。交付、运维、故障解决和选型后保护，所有这些都与业务价值无关，但又必不可少，根底软件呈现问题对下层业务零碎来说将是致命的，而这对于短少丰盛生产教训的运维人员来说，更是雪上加霜。 随着云原生技术的深刻倒退和行业解决方案的一直落地，企业越来越心愿看到这样一种平台，依靠云原生技术能力，岂但能够撑持大规模业务零碎的公布与运行，也能够将外部各种简单、零散、不对立和不规范的软硬件体系给集中管理起来，以中台化的运作形式，向企业外部源源不断的输入通过实际测验的成熟技术能力与规范体系，推动企业数字化建设向着更高效的方向倒退。在这样一个趋势背景下，云原生技术中台 CNStack 隆重公布了其具备变革意义的新一代 2.0 版本。 接下来咱们将从几个企业数字化转型遇到的常见艰难开始，向大家逐个介绍 CNStack 2.0 所具备的突破性能力，以及能给企业带来哪些外围价值。 异构资源管理艰难大部分企业曾经从“建好云”的阶段过渡到了“用好云”，不论是共有云还是公有云，用云和上云的理念曾经深入人心。但云平台的品种和数量都在一直减少，尤其是基础设施局部，这就如同 PC 时代的主机硬件，须要有更通用的操作系统加以屏蔽和晋升，否则面对不拘一格的 IaaS 基础设施，治理、运维和适配都将是反复且效率低下的工作。 跨云、混合云和分布式云早已从实践步入生产，对异构资源的治理能力也须要更上一层楼。在某些局点的实际中，咱们发现客户现场有存在多家云厂商的平台，且都散布在不同机房中，单开明资源这一项操作，就须要经验繁琐的申请过程，更不用说对整个环境体系的保护了。 CNStack 2.0 面向基础设施提供了云原生化的管理手段，能够对不同厂商、不同架构（x86/ARM）、不同计算类型（CPU/GPU）和不同地区（私有云/本地云/边缘云）的资源进行治理。多集群纳管能够将扩散的基础设施对立纳管到平台下，并能进行跨集群的资源分配、对立调度和集中运维，极大升高了异构基础设施的治理难度。 不仅如此，CNStack 在我的项目实际中能够管控上千节点或上万核规模的集群资源，特地实用于批发和互联网行业等对于大规模、高并发和低成本管控的要求。而且在超交融及混部等能力的加持下，系统资源利用率能够由通常程度的 6%~12%，晋升到 45%。 系统软件选型与保护艰难一个平台如果只能解决资源问题，其实还无奈为业务提供可用的环境，因为在资源之上还存在各种系统软件，对这些系统软件进行技术选型并解决选型后的继续保护问题，也是平台必须要解决的。 现如今，开源技术在软件畛域有着无足轻重的位置，单 CNCF 下注册的我的项目就曾经超过了 140 个，是否应用开源技术曾经成为了评估软件标准化和开放性的必要条件之一。但问题是，这么多开源我的项目，该如何进行技术选型？哪些项目能满足需要？哪些版本能用于生产？哪些技术经验过大规模实战？这些都是技术选型须要思考的问题。 与此同时，对技术选型的继续保护也同样重要。版本迭代、技术革新，每次都须要投入新的人力、物力和财力能力跟得上开源社区的疾速倒退，否则就会面临版本生命周期终结、性能落后和性能低下等问题，更有甚者会遗留重大的平安危险，这些都是数字化决策者所不得不思考的问题。 CNStack 2.0 能够从两个方面来解决技术选型时遇到的问题。首先，平台提供了很多内置的、开箱即用的产品组件和中间件，正是这些内置组件所提供的能力才使咱们所提倡的“让企业数字翻新只需专一业务自身”变为可能。 这些内置组件从资源管理到利用治理，从服务治理到流量治理，从可观测到可运维，从平台稳定性到数字化平安生产……渗透到了平台和业务零碎的方方面面。如果想要通过开源产品搭建具备等同能力的技术中台，其投入将是无比微小的。 CNStack 背靠阿里云云原生团队，其所提供的中间件产品无论在性能、性能、规模还是可靠性方面都是引人注目的，且经验过十分多的生产实践测验，能默默地为业务零碎保驾护航。另外，在能力中心里，CNStack 还精选了各种原厂和搭档提供的产品及组件，当内置性能不足以满足业务须要的时候能够在此进行有限扩大，并享受平台提供的统一化产品体验。 多环境交付艰难基于云原生技术的 PaaS 平台是近年来治理 IaaS 的首选计划。从开源到商业化，企业总能找到满足业务须要的解决方案，但也不是全然没有问题。 比方，既往的工作模式和治理标准都是建设在非云原生的基础设施之上，简言之，就是以物理机或虚拟机为单元进行资源管理的。那个时候环境的申请简直等同于筹备主机节点，但这并不意味着一个环境处于可用状态，最终使用者还须要在下面部署很多系统软件和根底组件，这些软件系统的反复部署，不仅节约人力和工夫，后续保护也是一笔继续的开销，更不利于环境的复用、开销的节俭和规范的建设，整体老本十分之高。当开发和测试等工作波及多个零碎和集成商的时候，环境获取老本将成倍增长，甚至失控。 CNStack 2.0 的环境交付是基于容器来实现的。在零碎建设之初，交付人员将基础设施资源整合成资源池（即容器集群），之后资源的申请便等同于在集群中划分配额。这些被调配的配额仅用于部署理论业务零碎即可，系统软件的交付则是通过能力核心来实现。能力中心里散发的产品与组件是开箱即用的，平台管理员只需轻点鼠标即可实现全自动的装置与部署，交付即可用。能力核心散发的是组件能力，不再是资源自身，齐全有可能在企业外部复用这些能力，并依此建设欠缺的根底软件应用规范。 在实践中，资源分配和能力供应是有严格权限隔离的，齐全实用于多地区、多组织和多我的项目的企业级管理模式。环境搭建周期从月变为天或小时，而且应用能力核心交付的组件会人造具备平台级的运维能力，岂但可能晋升环境搭建的效率，长期运维的老本也会一降再降。 生产运维艰难环境交付和利用部署都是一次性投入，而环境本身和其上业务零碎的运维却是须要继续投入的。对大多数的运维人员来说，因为不足大规模拜访下的生产运维教训，在突发状况时想做到零碎的安稳运行是十分艰难的，这往往不仅须要难得的实践经验，更须要业余工具或产品能力的反对。 即使在失常状况下，想要确保零碎稳固也是看似简略，实则艰难的指标。假使没有平台的反对，运维人员将无奈预知问题的产生，产生问题时也无奈做到及时止血或疾速定位，最初迅速复原和安稳降级能力让零碎回归到来日的失常状态。所有这些远非“一个有教训的运维人员”所能轻易做到的。 但依靠 CNStack 2.0 的产品能力，保障线上零碎的稳固运行只须要一个一般运维人员即可，这全都依附了平台提供的一站式利用治理能力。简单的业务零碎催生了利用状态的多样化，微服务利用、多语言利用、批处理或定时工作利用、AI 利用和大数据利用等，所有这些在实现上线之后都须要针对性的运维和治理能力。 ...

11 月 5 日，2022 杭州·云栖大会上，阿里巴巴研究员、阿里云智能云原生利用平台总经理丁宇在云原生峰会上发表主题演讲，提出云原生激活利用构建新范式。在分享中公布阿里云在云原生畛域多款新产品与全新降级，继续引领行业云原生技术趋势。 云原生曾经变成十分风行的技术趋势，从上云到用云，云原生可能从PaaS层面帮忙企业解决利用构建的一系列问题。具体有三大范式正在成为事实： 第一个范式是全面容器化。 因为容器造成了运维的规范，成为企业上云用云的新界面，也变成开发者和利用零碎交互的新界面，有利于构建高弹性、可伸缩的零碎，从而实现降本增效。通过容器，企业能够享受到运维标准化、弹性架构带来的益处，也带来了软件能够无处不在的部署交付，标准化的治理运维。 第二个范式是整个行业利用的核心技术互联网化。 咱们正在用互联网的技术、互联网的架构思维来重构利用零碎，从而带来了很多益处：分布式可扩大，撑持业务麻利迭代，构建弹性架构，从容应对流量顶峰。 第三个范式是利用的Serverless化。 从技术角度来看，可能实现技术组件分层解耦，让利用能够做到全托管免运维，晋升零碎的可运维性，降低成本。通过极致弹性，可能把所有的组件笼罩，在云上构建利用变得非常简单。 容器服务全面进入智能化时代尽管容器服务 ACK 大幅升高了 K8s 的门槛，但治理和运维一个大规模、分布式的集群仍然充斥挑战，比方说，如何调度利用，在保障稳固的同时，晋升资源利用率；如何对利用进行老本布局、剖析优化；当集群呈现问题后，如何及时的定位和修复。 智能化能够解决这些问题，智能化是容器平台倒退的必然趋势，阿里云容器服务全面进入智能化时代。 其中有三个降级： 第一个降级，智能化的混部调度，新一代调度零碎Koordinator， 帮忙用户晋升整体资源利用率。 第二个降级，智能化的老本治理，容器服务 FinOps套件， 帮忙用户实现上云老本可见、可控、可优化。 第三个降级，智能化的运维体验，容器服务 AIOps套件， 帮忙用户实现数据驱动诊断决策，助力故障进攻定位，自动化诊断能够笼罩 90% 以上的问题。 这些能力降级，会进一步升高容器技术的应用门槛，让 ACK 做到普惠化，服务更宽泛的客户群体。 核心技术互联网化重磅公布一 | 微服务再降级：新增云原生网关开源云原生时代，微服务面临着新的诉求和技术挑战，尤其是在性能、高可用性和安全性方面。明天，阿里云正式开源云原生网关 Higress，它是业内首个标准化、高集成、易扩大、热更新的云原生网关。 标准化： 随着K8s的遍及，K8s Ingress 逐步成为云原生时代API事实标准，Higress全面反对该规范，并且在服务治理方面（包含灰度、限流、预热、超时、重试）做大幅加强，引领规范演进方向。 高集成： Higress首次将流量网关、微服务网关、平安网关三合一，打造高集成网关，在入口建设高性能、平安防线，后端反对 K8s / Nacos / ECS / Serverless 多种运行时路由，打造性能最弱小网关实现。 易扩大： Higress 提供最丰盛插件扩大机制，满足客户灵便路由和平安定制需要，反对最全面语言扩大机制；当然为了升高客户应用门槛，默认集成了数十个插件，并且通过插件市场不便开发者奉献通用能力，产生良性互动。 热更新： 因为传统Nginx更新规定须要 reload 会导致链接抖动，导致流量损失，对实时通信、视频、IoT无奈容忍，因而 Higress 从证书、路由、平安规定、插件全副采纳热更新机制，毫秒级失效且业务无感知。 除了开源云原生网关之外，阿里云全面降级微服务引擎 MSE3.0，蕴含三大外围能力： 第一大能力是注册配置核心， 相比 Nacos 等支流开源计划，性能晋升40%，提供70+的监控指标，提供衰弱检测，帮忙客户实现服务异样自治。 ...

作者：阿里云云原生 本篇内容连载自《Serverless 架构下的 AI 利用开发：入门、实战与性能优化》。Serverless 架构与 CI/CD 工具的联合CI/CD 是一种通过在利用开发阶段引入自动化流程以频繁向客户交付利用的办法。 如图所示，CI/CD 的外围概念是继续集成、继续交付和继续部署。 作为一个面向开发和经营团队的解决方案，CI/CD 次要针对集成新代码时所引发的问题。具体而言，CI/CD 能够让继续自动化和继续监控贯通于利用的整个生命周期（从集成、测试阶段到交付和部署阶段）。这些关联的事务通常被统称为“CI/CD 管道”，由开发和运维团队以麻利形式协同反对。 CI/CD 的概念与内容简图 在 Serverless 架构下，通常会有很多函数形成一个残缺的性能或服务，这种比拟细粒度的性能往往会给前期我的项目保护带来极大的不便，包含但不限于函数治理、我的项目的构建、公布层面等的不便。此时在 Serverless 架构中，CI/CD 就显得尤为重要。更加迷信、平安的继续集成和部署过程不仅会让整体的业务流程更加标准，也会在肯定水平上升高人为操作、手工集成部署所产生谬误的概率，同时也会大规模加重运维人员的工作累赘。 如果想要通过 CI/CD 平台，迷信且不便地进行 Serverless 利用的继续集成、交付和部署，通常状况下咱们须要借助相应的开发者工具，例如 Serverless Framework、Serverless Devs 等。Serverless开发者工具配置到 CI/CD 平台的流程能够简化为下图。 Serverless开发者工具配置到 CI/CD 平台的流程 与 GitHub Action 的集成在 GitHub Action 的 Yaml 文件中，减少 Serverless Devs 相干下载、配置以及命令执行相干内容。例如，在 GitHub 仓库中创立文件.github/workflows/publish.yml，文件内容如下： name: Serverless Devs Project CI/CDon: push: branches: [ master ]jobs: serverless-devs-cd: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - uses: actions/setup-node@v2 with: node-version: 12 registry-url: https://registry.npmjs.org/ - run: npm install - run: npm install -g @serverless-devs/s - run: s config add --AccountID ${{secrets.AccountID}} --AccessKeyID ${{secrets.AccessKeyID}} --AccessKeySecret ${{secrets.AccessKeySecret}} -a default - run: s deploy与 GitHub Action 集成次要包含以下几局部内容： ...

2022 年 11 月 3 日，第三届云原生编程挑战赛行将迎来终极问难，18 支战队、32 位云原生开发者入围决赛，精彩行将开启。 云原生编程挑战赛项目组特地策动了《登顶之路》系列选手访谈，期待通过参赛选手的故事，看到更加活泼鲜活的中国开发者。 2022 云原生编程挑战赛共吸引了 17900+ 支队伍，超过 18000+ 选手报名参赛，笼罩中国、美国、德国、加拿大、新加坡等 13 个国家和地区，汇聚 440+ 国内外顶尖高校和 240+ 当先企业，企业选手占比达 30%+，其中决赛企业选手占比达 75%，大赛规模再创新高！ 本次咱们邀请了来自中原银行股份有限公司的战队「为研发效力而生」—徐志亮、岳同书同学，针对参赛历程与感悟进行了一次深度采访。 深度采访两位是在什么背景下理解到阿里云云原生编程挑战赛，是什么吸引了你们组团参赛？ 徐志亮：咱们是通过阿里云云原生公众号理解到，作为云原生顶级品牌赛事，曾经举办到了第八届，它的较量内容都是围绕热门技术畛域，对于开发者来说十分有影响力和挑战性。同时，大赛的处分也很有吸引力。 中原银行对云原生架构建设高度重视，曾经制订了欠缺的云原生技术倒退策略。咱们所在中原银行的工程效力团队，致力于继续改良晋升企业级研发效力程度。通过加入本次较量有助于加深咱们对于云原生架构的了解，进一步拓展咱们的技术视线，为今后云原生架构相干利用研发实际提供更多的思路与启发。 本次为何抉择了赛道三作为参赛方向？徐志亮：Serverless、云端开发都是近些年的热门话题，之前对于 Serverless 的理解更多地处于技术原理认知层面，本次参赛可能给咱们一个深刻技术实际的机会。同时IDE 是咱们开发者每天都在用的软件开发生产力工具，所以对于赛道三题目的了解上会更加深刻一些，因而抉择了赛道三作为咱们的参赛方向。 对赛道三：之前对Serverless架构方向有接触吗？针对实现一个 Serverless 架构的 Web IDE 服务的了解如何？岳同书：之前理解过 Serverless 架构的一些常识，但并没有深度进行过Serverless架构利用实际，所以本次参赛对于咱们来说，挑战还是比拟大的； 就赛道三的赛题来看，Serverless 架构的特点与 WebIDE 服务的业务场景是符合的，但美中不足的是 Serverless 架构要求的“无状态”与 WebIDE 服务的“有状态”之间存在矛盾，如何平安、高效的存储和复原数据便是重中之重，参赛期间赛道三的导师也给了咱们很多的帮忙和启发，在这里要特别感谢他们； Serverless 架构按量付费、灵便的弹性伸缩策略，以及更高的资源利用率，都是相较于其余计划的显著劣势。 两位在参赛过程中有遇到什么挑战吗？你们是如何解决的？攻破后对您的技术方面有什么帮忙吗？岳同书：第一个挑战是咱们对于函数计算平台并不相熟，大略花了几天的工夫通读了所有的技术文档，列出了一些咱们可能会用得上的个性，逐渐论证造成了最终的技术计划。高质量的技术文档对于晋升开发质效至关重要，这点要给函数计算团队点赞，通过浏览文档，根本解决了绝大多数问题。 第二个挑战是技术计划的经济性，如何以最小的老本投入来实现参赛指标，这也很大水平上影响了咱们技术计划的制订和优化调整。举个印象最粗浅的例子：最后咱们打算通过泛域名解析来实现不同租户的 WebIDE 服务拜访，但起初动辄几千块的泛域名 HTTPS 证书使得咱们最终放弃原先计划，促使咱们进行了第一次技术计划的优化调整。 第三个挑战是开发过程中一直呈现的技术难题，如：如何中断 Open VSCode 的长链接实现资源利用率的优化、如何解决多个 WebIDE 实例在同一域名下拜访时呈现的动态资源文件失落、IndexedDB 错乱等问题。面对这些长时间困扰的妨碍问题，咱们急躁深刻钻研源码，最终圆满解决上述问题，进一步晋升了咱们钻研解决技术难题的实际能力。 两位目前任职的公司岗位教训，在参赛过程中有带来什么灵感吗？岳同书：为了给开发者提供开箱即用的体验，咱们决定给 WebIDE 减少“环境模版”这个个性，因而须要基于不同编程语言来定制根底环境、编译工具、构建工具与依赖源配置等。这里联合了函数计算平台的 Custom Container 性能，实质上不同的“环境模版”就是一个个不同的容器镜像。这个性能的实现借鉴了理论工作中的业务场景，即在继续集成流水线运行环境中也面临同样的问题，不同的工程应用不同的开发语言与不同的编译工具，解决构建环境的可复制性与 WebIDE 的“环境模版”个性不约而同，这给咱们带来了很大的灵感助力。 作为赛道三中的一支优良团队，两位认为在这次参赛过程中，都播种了什么？有没有什么感悟能够跟大家分享的～徐志亮：首先，通过此次参赛进一步加深了对于云原生架构的了解，较量的过程也是咱们对于云原生、函数计算等技术深刻学习和利用的过程。其次是角色的转换，从IDE的使用者转换为了WebIDE的设计者和开发者，新的视角带来了全方位新的思考。另外，咱们也是站在伟人的肩膀上进行具体实际，本次作品借助了开源 Open VSCode Server和阿里云一系列产品的能力，体验到了开源技术的力量和阿里云基础设施的弱小。最初，团队单干的力量十分重要，在参赛过程中咱们一直遇到问题、解决问题，最终达成了预期指标。 ...

作者：阿里云用户组 从云计算到 Serverless 架构大家好，我是阿里云 Serverless 产品经理刘宇，很快乐能够和大家一起摸索 Serverless 架构的前世今生。 从云计算到云原生再到 Serverless 架构，技术飞速发展的轨迹都有肯定法则可循，那么 Serverless 架构为何而来，因何而生呢？ 云计算的诞生从世界第一台通用计算机 ENIAC 开始，计算机科学与技术的倒退就从未进行过后退的脚步，近些年来，更是突飞猛进。有一直冲破和翻新的人工智能畛域，有 5G 带来更多机会的物联网畛域，还有一直走进寻常百姓家的云计算。 在图中能够看到三个关键词，这是 2003 年到 2006 年间，谷歌发表了三篇重要的论文，这些文章指明了 HDFS（分布式文件系统），MapReduce（并行计算）和 Hbase（分布式数据库）的技术根底以及将来机会，正式奠定了云计算的倒退方向。对于这三个文章，或者这三个技术点，也有人曾说“因为它们，云计算才正式拉开帷幕”。 云计算倒退是飞速的，也是引人注目的；然而随着云计算的过程，另一个名词诞生并迅速霸占了“风口大旗”，被公众更为宽泛地关注，那就是——云原生。 通过对云计算与云原生的文字组成构造剖析，能够看到云原生实际上就是在云与计算之间，加了一个 Native，所以能够认为，云计算的飞速发展，无论是从技术迭代还是从概念降级，最终产生了现在耳熟能详的：云原生计算。 云计算是什么？其实早在 1961 年云计算的雏形概念就曾经诞生了，在麻省理工学院百周年留念仪式上，约翰·麦卡锡，也就是 1971 年图灵奖获得者，第一次提出了一个概念，这个概念起初被喻为是云计算的“最后的、超前的”遥想模型。它翻译粗心为：“计算机在将来，将变成一种公共资源，会像生存中的水、电、煤气一样，被每一个人应用。”工夫到了 1996 年，云计算这个词被正式提出；而到了 2009 年，UC Berkeley（加利福尼亚大学伯克利分校）更是在公布的论文中，对云计算进行了较为粗疏形容，它说云计算是一个行将实现的古老幻想，是计算作为基础设施这一长久以来幻想的新称呼，它在正疾速变为商业事实。同时在该文章中，也明确地为云计算做了定义：云计算蕴含互联网上的应用服务，以及在数据中心提供这些服务的软硬件设施。 云原生的炽热 时至今日，云原生技术的倒退同样迅猛，那么什么是云原生呢？在文章“什么是真正的云原生”中，给出了一个十分明确的解释：因云而生的软件、硬件、架构，就是真正的云原生；因云而生的技术，就是云原生技术。的确如此，出生于云，成长在云，因云而生，就是云原生。 那么云原生都包含哪些货色呢？耳熟能详的技术，加上云原生三个词，就都是云原生相干技术了，例如：数据库，云原生数据库；网络，云原生网络等。在 CNCF Landscape 中，能够看到云原生基金会对云原生产品维度的一个形容，包含了数据库、流、音讯、包含容器镜像、包含 servicemesh、包含网关、包含K8S、当然，这里还包含一个十分热门的词汇：Serverless。 Serverless 架构的呈现在很多时候 Serverless 架构被称为是一种粘合剂，它将云原生的其余很多产品和用户的业务进行了链接，同时又提供了极其迷人技术红利，为此也被很多我的项目，业务所抉择。那么什么是 Serverless 架构？ 通过 Serverless 的构造，不难发现其所要传递的心智，Server 指的是服务器，Less 示意的是更少的精力，所以 Serverless 架构所传递的心智是：把更业余的事件交给更业余的人，开发者可能较少地关注服务器等底层相干内容，把更多的精力放在更具价值的业务逻辑之上。 2009 年，UC Berkeley 发表了一篇对于云计算的文章，在文章中，UC Berkeley 为云计算做出了明确的定义，同时也提出了包含服务的可用性，数据安全性和可审计性等在内的十项云计算所面临的各种艰难和挑战，并断言云计算将会引领将来的十年。 2019 年，恰好时隔十年，UC Berkeley 再次发文，不仅从多角度阐明了什么是 Serverless 架构，例如从构造角度，必定了 Serverless 是 FaaS 与 BaaS 的联合；从个性角度，对于被认为是 Serverless 架构的产品或者服务须要具备按量付费和弹性伸缩的特点；并十分激进地示意 Serverless 将会成为云时代默认的计算范式，将会取代 Serverful 计算，由此也意味着服务器 - 客户端模式的终结。 ...

作者： 井轶 为什么要进行可观测性建设可观测性并不是一个新词，该词来源于管制实践，是指零碎能够由其内部输入推断其其外部状态的水平，随着 IT 行业几十年的倒退，IT 零碎的监控，告警，问题排查等畛域的逐步成熟，IT 行业也将其形象造成了一整套可观测性工程体系。而之所以该词在这几年愈发炽热，很大水平是因为云原生，微服务模式，DevOps 等技术的一直风行，对可观测性提出了更大的挑战。 云原生架构所提倡的微服务、DevOps 模式，同时带来了效率、可用性的晋升， 但同时也极大水平减少了零碎的复杂度， 也因而加强可观测性成了升高复杂度的惟一伎俩。 这里须要特地留神的是可观测性并不是监控，传统监控仅仅可能做到问题被动发现，可观测性的外围是基于对当时未定义的属性和模式的摸索， 其不仅仅单纯是发现问题，更着重于对系统在运行时提供对其了解、探查以及调度的能力。 可观测性的基石指标、日志、事件、链路数据可能帮忙咱们更好的了解运行的零碎，为事先预防、事中解决、预先复盘提供了重要决策依据， 同时可观测性体系也可能减速利用的继续交付，这就是为什么咱们须要进行可观测性建设的起因。 如何针对网关场景进行可察看性建设确定可观测性体系建设的指标在没有监控或是监控凌乱的状态下，开发者掂量零碎的运行状态，都是靠一些不成体系的零散指标，盲人摸象，看不到全局。产生问题时，多是靠一些元老级开发者通过本人教训，从多个指标里含糊构建出业务全局状态，这个教训往往是不可复用的。 因而咱们须要是通过技术手段建设零碎的可观测性，能够清晰地“看见”零碎运行的全面具体状态，升高教训门槛和不确定性，做出及时无效的决策。可观测性解决方案该当实现如下指标： 通过可观测性体系可能决定是否施行服务降级或者服务中断当服务不可用、服务降级、失败时，可能疾速发现。在服务不可用，失败时，可能帮忙调试。确定容量布局和业务指标的长期趋势。揭示更改或增加的性能的意外副作用。 构建网关通用可观测性指标可观测性体系构建的指标是清晰的，然而仅仅只是应用了某些工具，加了某些监控并不足以实现目标，基于不同的业务场景须要对症下药，不同教训的工程师可能会用不同类型的监控体系,  但外围是可观测性体系应用的监控体系可能正确反馈零碎的真实情况。 在网关可观测性体系的构建中，将次要的监控分为黑盒监控与白盒监控 黑盒监控:  一种基于采样的办法。黑盒零碎将监控负责用户申请的同一零碎。最罕用的是应用拨测模仿用户失常申请来拜访业务。 白盒监控: 监控和可观测性依赖于从处于监控的工作负载发送到监控零碎中的信号。这通常能够采纳三个最常见组件的模式：指标、日志和 trace  白盒监控中，指标的抉择是件绝对主观的事件，抉择的指标是否精确体现零碎的实在情况严重影响到整体可观测性体系指标的实现。 这里咱们无妨回到网关最根底的性能，正是因为网关的代理性能，网关会人造积淀通用逻辑如鉴权等，但实质依然是对流量进行转发。 在这里咱们将申请发起方称为网关的上游，申请转发的目标服务成为称为上游,  上游请求者是最能感知整体零碎状况的，因而咱们将网关服务类型指标的上游的成功率，申请量，RT 作为掂量整个网关的外围指标。 当然，这三个指标在少数零碎中都是外围指标。在确定外围指标后，咱们须要确定零碎的门路指标,  即外围指标发生变化的时候，咱们通过查看门路指标，可能疾速定位问题的起因所，比方 CPU 占用百分比一直飙高时网关的耗时会同比增加，因而咱们将零碎指标(CPU， 内存，网络流量，连接数)，服务指标中的上下游依赖(例如后端服务的端点变动状况)作为网关的二级指标。 通过下面的指标咱们就根本确定了网关的可观测性指标，然而网关自身只是业务零碎的一环，业务残缺的可观测性须要联合业务场景去进行构建，例如应用网关日志记录业务侧状态码构建业务指标。 基于云原生网关的可观测性建设最佳实际云原生网关是阿里云微服务引擎(MSE)下的一款托管类型网关产品，其将传统的流量网关与微服务网关进行了整合，作为云上产品他无缝反对来云上的可观测性产品 ARMS、SLS，力争对客户零门槛，同时立足开源，网关也兼容了 zipkin, skywalking, prometheus 等可观测开源产品。上面基于前文所讲述的可观测体系构建的思路，基于云上产品来构建可观测性体系，并以理论场景阐明网关场景的可观测性应用。 灰度公布场景中的可观测性咱们以服务新版本公布的场景作为云原生网关可观测性的具体例子 。 在上图的公布过程中，最前端的流量会在服务 v1 和 v2 之间进行切换，在这个场景中，咱们的外围是可观测性可能及时保障利用公布过程中利用公布导致的异样可能及时被观测到。 在新利用部署前，咱们该当首先将网关默认提供的可观测性能力开启， 首先开启网关的根底指标监控(cpu, 内存, 整体成功率)， 并针对该场景在告警配置中开启服务级别监控，以便在 httpbin 服务的成功率下降时可能及时发现。 在开始之前咱们曾经部署了 httpbin v1 版本。 之后咱们开始正式在阿里云 ACK 集群中部署 httpbin v2 版本的利用，该集群之前曾经部署过 httpbin v1 的利用。 ...

2022 年 11 月 3 日，第三届云原生编程挑战赛行将迎来终极问难，18 支战队、32 位云原生开发者入围决赛，精彩行将开启。 云原生编程挑战赛项目组特地策动了《登顶之路》系列选手访谈，期待通过参赛选手的故事，看到更加活泼鲜活的中国开发者。 2022 云原生编程挑战赛共吸引了 17900+ 支队伍，超过 18000+ 选手报名参赛，笼罩中国、美国、德国、加拿大、新加坡等 13 个国家和地区，汇聚 440+ 国内外顶尖高校和 240+ 当先企业，企业选手占比达 30%+，其中决赛企业选手占比达 75%，大赛规模再创新高！ 第一期咱们邀请了来自数字海南有限公司的曾辉林，针对参赛历程与感悟进行了一次深度采访。 深度采访在什么背景下理解到阿里云云原生编程挑战赛，是什么吸引了你们参赛？起因是我关注了【阿里云云原生】的公众号，偶尔在一次推文中发现了 2022 云原生编程挑战赛的启动报名文章，查看后发现往年的赛题比拟贴合咱们公司开发的一个理论场景，很想去尝试挑战一下，通过参赛去解决一些将来可能会遇到的难题，提前做好筹备。工作之后比拟少机会加入大赛，我心愿通过这个较量过程可能播种和学习一些实战的技能。 怎么组队的？为何抉择了赛道二作为参赛方向？咱们团队的队员都已经任职在同一家公司，因为技术方向雷同、对彼此的技术能力也都比拟认可，所以我在看到这篇推文后便分割了另外两位小伙伴收回组团的邀请，大家看过大赛介绍后都觉得很有意思，因而立即组团开始报名。 战队：浩瀚武林（居中是本次受访嘉宾） 咱们同时报名了赛道一与赛道二，其中赛道一的服务网格技术与咱们公司目前的业务较为贴近，而抉择主攻赛道二的起因是公司外部 RPC 框架注册核心模块想以 Kubernetes 作为注册核心，就须要调用 kube-apiserver 来获取服务地址列表，刚好赛道二考查基于 list/watch 机制实现高效的边缘自治计划与公司调研的怎么放弃服务地址信息的可靠性、实时性、程序性、高性能也很贴近。也算是着眼于将来，咱们最终抉择了这个赛道，当然这也意味着咱们要去挑战之前不太涉及的新技术畛域，有兴奋也有担心。 之前对边缘云原生方向有接触吗？针对云原生边缘计算场景的 ACK@Edge的高效边缘自治计划，感觉这套计划和同类型计划比有何劣势？对边缘云原生在参赛之前接触比拟少，因为它次要畛域是在 IoT (物联网)和 CDN 等畛域。而我所在的公司是比拟偏政企化，所以接触的比拟少。 在参赛过程中咱们进一步理解了 ACK@Edge 高效边缘自治计划，我的了解是它在边缘节点和云端管控网络断连等异常情况下，业务重启还是节点重启后，节点内或者跨节点间的业务利用通信都将主动复原，比拟实用于边缘计算的弱网络连接状态下利用跨节点通信的场景。 而这套计划和同类型的计划，我感觉它的长处在于性能更高效，资源占用比拟低。 这个赛道吸引您的起因是什么？ 赛道二吸引我的起因次要有两点：第一点是对于边缘计算技术，是我作为零碎架构师心愿去被动学习的货色；第二点是因为目前赛道二的内容与公司我的项目中所调研的内容比拟贴合，两者都须要去调用 kube-apiserver 去获取服务列表，有些类似且能够借鉴之处。 在参赛过程中有难忘的事件吗？在较量的最初一周，排行榜的第一和第二的分值与咱们相差较大。咱们团队连着几个早晨进行了语音探讨，并且尝试了多种计划。最初，在较量截止的前三天，咱们探讨出了一个可行性的计划，同时跟导师发展探讨后进行了验证。最终咱们的比分跟第一、第二名的分值相差不大，期间也有一次反超了他们的分值。 您目前任职的公司岗位教训，在参赛过程中有带给您什么灵感吗？目前，我在数字海南次要负责公司零碎架构师一职，次要是零碎架构设计，中间件选型和零碎性能调优。这次参赛在性能调优上给了我很多灵感，较量中采纳 Golang 的长期对象池，减少长期对象重用率和缩小 GC 累赘和采纳内存缓存策略进步程序的性能。 有没有什么感悟能够跟大家分享的？这次参赛次要是晋升了我的编程技能以及对云边端的更深层次的认知。随着近年来5G 网络、物联网的疾速倒退，云技术利用的边界也在一直拓展和深刻，来应答爆炸式增长的数据量和终端侧“大连贯、低时延、大带宽”的市场需求，这将是边缘云的趋势与机会 之前用过印象比拟深的阿里云的产品是？印象比拟深的有两个，一个是利用实时监控服务 ARMS  能够基于前端利用、业务自定义等维度，迅速便捷地构建秒级响应的利用监控能力。另外一个是阿里云利用高可用服务 AHAS，它能够进步利用及业务的高可用能力，次要提供流量防护、故障演练、容灾等外围能力。 参赛过程中最难的是什么时候？比方在开始的时候，咱们团队参加了赛道一和赛道二，同时在两个赛道中都获得了较好的问题。但前期因为工作以及一些其余起因，加上参赛节奏较缓和，所以那段期间略微有些松散，甚至产生了放弃的想法。 在较量行将截止的时候，咱们团队又沟通了几次，大家还是感觉咬咬牙要保持下来。咱们团队在赛道二的问题与后面选手差距不大，还是十分有机会的，于是三个人熬夜写代码，在工作之余探讨优化计划，与导师沟通，一直解决技术问题，最终实现了这个赛季的冲刺。不管能不能拿到一个好名次，起码可能在这次较量中学习到一些工作中未曾波及的畛域常识。 您是怎么了解云原生的？我是近一两年理解到云原生技术，与云原生相干的产品、开源、演进历程等都吸引我去一直理解这个畛域的倒退。作为一名程序员，是须要一直的去学习一些新的常识，理解前沿的技术趋势。 我在云原生畛域比拟专一于容器和微服务，微服务解决“利用架构复杂度”问题，容器解决“利用部署问题”问题，Kubernetes 解决利用“编排和调度”问题。我认为容器算是云原生畛域中的代表技术，容器提供了利用散发和交付规范，将利用与底层运行环境进行解耦。我在退出到数字海南后，2020 年末公司发展了所有的服务容器化上云打算，用 Kubernetes 解决容器的编排与调度。 ...

作者：草谷 背景许多企业在做微服务架构革新的时候，在自建还是上云的抉择上难以决策，抉择上云后，在微服务上云过程中，如何可能做到不影响业务状况下平滑迁徙呢，通过浏览本文，你能够疾速取得以下知识点和能力： 理解微服务上云给企业带来的价值理解微服务迁徙过程中带来的挑战把握通过 MSE 提供的迁徙计划平滑上云微服务迁徙上云背景自建微服务平台面临的问题在晚期的时候，因为平台型 PaaS 设施服务还不够欠缺，有不少企业的微服务平台是自建的，咱们明天一起看下，这些企业在运维自建微服务组建过程中，遇到哪些比拟典型的问题： 这张图是一个典型的微服务架构，次要蕴含接入层和微服务中心两块，终端的 HTTP 申请进入到接入层，这层采纳肯定的调配算法将网络申请散发到后端的多个服务器，后端的服务器组成了一个微服务中心，外面部署着大量业务机器和注册配置核心等微服务组件，这些组件根本采纳的都是开源组件： 微服务组件复杂度高，保护难网关和注册配置核心是微服务架构中外围的组件，要保障高性能，高可用稳固的设计，必然导致组件的复杂度晋升，同时部署构造要保障多级容灾，这也加大了整体的保护难度。自建组件无业余运维，线上稳定性无奈保障线上呈现问题时，须要可能相熟组件设计的业余运维同学参加排查，否则难以疾速找到问题，导致故障复原工夫缩短。开源自建组件性能缺失，问题反馈周期长，无奈满足企业需要采纳开源的组件，呈现问题，往往短少专职保护跟进，凭借社区的志愿者激情，一些紧急问题很难失去及时反馈。互联网的流量难以预知，无奈精确做容量评估自建组件在面临极其流量时，如果筹备大量机器应答，峰值过后又是一笔节约，无奈做到资源的高效利用。MSE提供一站式微服务平台针对下面这些问题，MSE 提供了一站式的微服务平台，集成了微服务外面罕用外围的组件，对立构建运维： 托管易用免运维提供白屏化监控告警、容灾、宕机重启、扩缩容等能力，缩小运维老本，有技术兜底，让客户专一于业务开发自身。高性能高可用MSE 基于开源在性能和稳定性上做了大量优化，大规模服务数据下 SLA 99.95%。平安防护网关反对多种服务起源，丰盛的路由策略和认证鉴权形式，可对不同架构、多个业务域的服务调用进行对立的配置、治理和爱护。无厂商绑定100%兼容开源，代码无需更改，实例无需停机即可平滑迁徙。企业上云案例MSE 服务了大量的微服务架构企业，这里给大家介绍两个典型的标杆客户，他们通过 MSE 解决了一些在它们畛域外面遇到的微服务问题，大家能够看看是否有值得借鉴的中央。 互联网金融-上海费芮上海费芮是一家提供业余互联网金融服务的企业，提供业余的在应用 MSE 之前，他们是本人部署的 Nginx Ingress 作为流量网关的，面临以下问题： 网关运维能力有余，不足业余的网关运维人员原生的 Ningx Ingress 部署在用户集群外面，稳定性和平安容易受业务影响原生的 Ningx Ingress 的性能无限，例如短少 TLS 版本设置，IP 黑名单等在迁徙到 MSE 云原生网关后，这些问题都失去了解决，在整个迁徙过程中，改变老本也非常低，MSE 云原生网关齐全兼容 Nginx Ingress 注解，无需二次编辑路由规定，MSE 提供了网关的全托管服务，将网关与业务集群拆散，大幅度提高了稳定性，安全性。 批发行业-斯凯奇斯凯奇是批发行业里十分有名的鞋类品牌，它的架构就是典型的微服务架构，接入层曾经迁入了 MSE 云原生网关，微服务中心采纳的是 Dubbo+MSE Nacos，配置核心采纳的也是 MSE Nacos。 MSE 给斯凯奇提供了对立的微服务路由、流控、平安治理，丰盛的可观测等能力，不便内外部多零碎间的集成，极大进步了中台服务的开发效率，并升高运维老本，顺利应答双 11 流量洪峰，撑持斯凯奇双 11 业绩超 12 亿的交易系统。 迁徙上云常见问题MSE 反对了许多企业把微服务平台迁徙上云，在这个过程中，遇到了不少的问题，次要分为以下几点： 云上云下数据不统一自建网关外面有大量的路由配置，微服务外面注册核心和配置核心外面存储着大量的地址信息和配置信息，这些都是微服务运行时必不可少的，这些数据在云上都是没有的。迁徙操作过程简单，如何切流能力业务不中断迁徙过程必然存在云上云下组件同时工作的状况，流量如何无损的从云下切到云上呢，如果呈现问题是否可能疾速回切止损呢。微服务组件兼容问题，客户端须要改变云下和云上是否存在兼容问题，MSE 是否兼容自建 Eureka，客户端是否须要做代码层面的改变等。 MSE 平滑迁徙计划针对迁徙过程中遇到的常见问题，MSE 提供了一套迁徙工具：MSE Sync，并给出了残缺的迁徙计划，次要包含注册配置核心及网关的迁徙。在实际操作过程中，个别会先从注册配置核心进行迁徙，而后再做接入层的迁徙，接下来，给大家介绍下每个模块的具体迁徙计划。 ...

作者： 屿山 事实零碎往往有着较高的复杂度，咱们借助 Trace、Log、Metric 三驾马车使咱们的零碎具备了肯定的可观测性，但观测地位和信息往往是固定的，而咱们所遇到的问题经常是意料之外的，这就导致咱们可能定位问题的范畴，然而难以更进一步，这时候咱们就须要在咱们想要的地位采集信息来帮忙咱们，在通常的实际中这就意味着咱们须要增加日志逻辑并重启利用，这种做法老本较高而且会失落现场。而借助日志治理，只须要通过在控制台配置规定便能够在不重启利用的前提下，动静采集任意点位信息。接下来通过一个假想的排查流程来简略介绍下日志治理的实际。 动静日志打印假如咱们有一条如图所示的简略的申请数据库的申请调用链路，当该调用链路的申请呈现了异样，在定位问题的过程中，咱们往往会须要晓得调用的堆栈信息，进而去排查堆栈上的办法，获取这些办法的参数、返回值、异样等信息，从而帮忙咱们查清问题的起因。借助日志治理的能力，咱们能够很不便地进行这些操作。 在这个场景下，当发现 AppB 的/sql 申请局部报错，但咱们并没有事后编写可能记录无效信息的日志，这时咱们就能够通过配置一条日志治理的规定来打印现场的堆栈信息，以获取咱们须要排查的办法列表，再进一步对一一办法进行剖析。咱们抉择/sql 作为 Target，如果不晓得具体的接口，也能够放弃默认抉择全副。 因为咱们只须要剖析谬误的申请，所以在过滤规定条件中开启异样过滤，在打印内容中选中调用堆栈，其余的内容能够依据须要抉择。 开启该规定后，能够看到零碎帮忙咱们在日志文件中打印了蕴含堆栈信息的日志： /home/admin/.opt/ArmsAgent/logs/mse-log-governance.log at com.mysql.cj.jdbc.ClientPreparedStatement.executeQuery(ClientPreparedStatement.java:989) at com.alibaba.druid.pool.DruidPooledPreparedStatement.executeQuery(DruidPooledPreparedStatement.java:213) at com.alibabacloud.mse.demo.service.DruidCon.doCommond(DruidCon.java:57) at com.alibabacloud.mse.demo.service.DruidService.query(DruidService.java:15) at com.alibabacloud.mse.demo.BApplication$AController.sql(BApplication.java:89) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)截取其中一部分能够发现其中有一部分是咱们本身的业务逻辑办法，也是咱们须要关注的办法，咱们能够持续借助日志治理的能力，去获取这些办法的现场信息，比方参数、返回值、类加载器等等。 本身业务逻辑办法： com.alibabacloud.mse.demo.service.DruidCon.doCommondcom.alibabacloud.mse.demo.service.DruidService.query以 doCommond 办法为例，咱们只须要减少一条新的规定，指定该自定义办法。 随后在过滤规定条件中开启异样过滤，在打印内容中选中申请参数，其余的内容能够依据须要抉择。 开启该规定后，能够看到零碎帮忙咱们在打印了 JSON 格局的日志信息，蕴含了咱们所勾选的参数信息：  /home/admin/.opt/ArmsAgent/logs/mse-log-governance.log{ "appName": "app-b", "attributes": { "mse.tag": "base", "mse.param": "{"sql":"select * from log_demo where id = ?","id":"1"}", "mse.app.tag": "base", "mse.service.type": "CUSTOM" }, "endTime": 1665974434728, "events": {}, "ip": "10.0.0.166", "name": "com.alibabacloud.mse.demo.service.DruidCon:doCommond(java.lang.String,int)", "needRecord": true, "parentId": -4669550334584716586, "ruleIdSet": [ 288 ], "spanId": -8047278153886744300, "startTime": 1665974434725, "statusCode": 2, "traceId": "ea1a00009d16659744347231724d0001"}以上只是简略的例子，然而可能由此发现，日志治理的能力可能让咱们在 Java 办法任意点位收集信息，将排查工作变成零代码且动静的，因为不须要在测试环境中反复减少日志代码并一直重启利用，可能大大减小某些难以在测试环境中复现的问题的排查难度。 ...

作者：阿里云云原生 本文将具体介绍如何开发和部署 Serverless 利用，并通过阿里云函数计算控制台与开发者工具 Serverless Devs 进行利用的初始化、部署；最初分享利用的调试，通过迷信公布、可观测性等介绍利用的部署和运维总结，进而实现从利用初始化到调试、公布、运维根底流程、外围步骤的摸索。 如何开发、部署 Serverless 利用通过控制台进行函数创立上面咱们将基于 Serverless 架构，在 FaaS 平台上实现 Hello world 的输入，根本步骤可分为： 1）注册账号，并登录； 2）找到对应的 FaaS 产品：阿里云的函数计算； 3）单击“创立函数”按钮，进行函数的创立； 4）配置函数，包含函数名称、运行时（能够认为是要应用的编程语言，或者要应用的编程环境等）； 5）实现创立，并测试。 以阿里云函数计算为例，当注册并登录阿里云账号之后，须要找到函数计算产品，并单击进入产品首页，如图所示。 阿里云函数计算产品首页 抉择左侧的“服务及函数”，并进行服务的创立，如图所示。 阿里云函数计算创立服务页面 而后进行函数的创立，如图所示。 阿里云函数计算创立函数页面 绝对于其余的云平台，在阿里云函数计算平台，咱们不仅要为行将创立的函数设置函数名称、抉择运行时等，还须要设置该函数所在的服务。在阿里云函数计算的体系中，引入服务的概念会带来肯定的益处。 相关联的函数能够放在一个服务下进行分类，这种分类实际上比标签分类更直观明了。 相关联的函数在同一个服务下共享肯定的配置，例如 VPC 配置、NAS 配置，甚至某些日志仓库的配置等。 通过服务，咱们能够很好地做函数环境的划分，例如对于一个相册我的项目，该我的项目可能存在线上环境、测试环境、开发环境，那么能够在服务层面做辨别，即能够设定 album-release、album-test、album-dev 三个服务，进而做环境的隔离。  通过服务，咱们能够很好地收纳函数。如果我的项目比拟大，可能会产生很多函数，对立放在同一层级会显得十分凌乱，这时就能够通过服务进行无效的收纳。 实现函数的创立之后，咱们能够进行代码的编辑。阿里云函数计算反对从对象存储上传代码，反对间接上传代码包，以及在线编辑。除此之外，阿里云函数计算还反对间接上传文件夹，如图所示。 保留代码之后，能够单击“执行”按钮进行函数的触发、测试。 能够看到，零碎曾经输入相干日志：Hello world。至此，一个非常简单的函数就创立胜利了。 通过工具进行函数创立与部署通过 Serverless 开发者工具入门 Serverless 利用开发、部署、运维是十分不便的，咱们以 Serverless Devs 为例介绍阿里云函数计算利用的部署，并对工具侧的函数创立、部署以及其余相干性能进行摸索。 Serverless Devs 是一个开源的 Serverless 开发者平台，致力于为开发者提供弱小的工具链。通过该平台，开发者能够一键体验多云 Serverless 产品，极速部署 Serverless 我的项目。依照官网目前的形容，Serverless Devs 曾经反对包含 AWS Lanbda、阿里云函数计算、百度智能云函数计算、腾讯云云函数、华为云函数工作流等在内的多个云厂商的 Serverless 相干产品。 上面通过 Serverless Devs 开发者工具，以阿里云函数计算为例进行实际，摸索如何创立、部署 Serverless 利用。 ...

作者：涌月 背景随着近年来微服务体系倒退，微服务上下游链路的越来越简单，在阿里云的线上实际场景中，咱们发现应用微服务架构的公司的业务动辄会呈现上千条调用链路，排查问题代价微小。 在这种背景下，阿里云微服务引擎(MSE)推出了 Nacos 托管产品，大幅晋升可观测性，升高排查问题老本，本文将全面介绍 Nacos 可观测性体系。 微服务上下游盘根错节的调用关系 Nacos 可观测能力概述可观测性（Observability）是帮忙微服务持重运行的重要一环，是指零碎能够由其内部输入推断其外部状态的水平。“咱们的微服务零碎是否还是失常的？”，“微服务上下游调用的体验是否合乎预期？”，“咱们如何提前被动发现微服务零碎的危险？”。 如下图所示，让用户对微服务有更强把控力，咱们在设计 Nacos 可观测性的时候，着重思考了如下两点： 监控内容方面：咱们将服务发现零碎、配置管理系统、底层的 JVM、操作系统等个外围零碎的各项指标进行了提炼和展现；交互设计方面：咱们采纳了业界支流的 Grafana 大盘作为默认的可观测性展现计划，并且反对了用户将咱们提供的大盘链接嵌入自定义的运维平台、以及获取各项指标的具体数据的需要。 Nacos 的可观测性的设计思路 在邻近双十一之际，咱们已将上述 Nacos 的加强可观测性体系全面上线。 可观测能力详情在 Nacos 的加强观测能力建设中，咱们构建了 7 个表现力丰盛的大盘，并且建设了相干的告警零碎。另外，为了让用户可能不便地将微服务的大盘嵌入业务方的业务平台，咱们还为用户们透出了可嵌入的 url 和具体采集数据。 7 个大盘别离为业务概览大盘、注册核心大盘、配置核心大盘、推送轨迹大盘、连接数大盘、JVM 监控大盘、资源大盘，它们的详细信息别离如下： 业务概览为了让用户疾速看到以后业务的外围指标，咱们将阿里巴巴团体客户和云上客户们最关注的指标进行整顿和设计，对立形象成为了"概览"大盘。 在该大盘中，用户能够查看到如下信息： 在概览区域，可查看引擎的节点数、配置数、服务提供者数、每秒查问数、每秒操作数和连接数等信息；当某项指标达到或者超出个别水位之后，相干的指标色彩会变成红色，以揭示用户尽快进行扩容或业务公布解决。在使用量水位区域，用户能够查看到相应指标的应用水位，超出阈值的指标也会变色揭示。  资源监控资源监控页签中，咱们将注册与配置核心周边的各种资源应用状况全面而精确地展现给用户。咱们次要选取了注册配置核心的入口流量、进口流量、内存使用率、CPU 使用率、磁盘应用百分比、磁盘读写量、节点个数和 Load 指标等数据。 在呈现业务异样的时候，用户能够不便地定位到该注册与配置核心的零碎外部的各种资源应用状况，找到是哪个指标导致了以后业务异样的产生。 JVM 监控除此之外，用户能够单击 JVM 监控页签，查看 Young GC 工夫和次数、Full GC 工夫和次数以及堆内存使用率等数据。不便疾速进行 GC 剖析和问题定位。 注册核心监控对于注册核心，MSE Nacos 也提供了专门的监控页面，次要监测指标包含： 服务发现业务指标：服务数、服务提供者数、服务订阅者数；服务发现访问量指标：注册核心 TPS、QPS、写 RT、读 RT 等数据。 用户能够不便地通过该监控进行各项指标的核查，例如当服务发现业务上呈现推送或查问提早，能够通过 RT 数据疾速定位以后注册核心的相应工夫； 在压测场景下，用户也能够通过该大盘进行服务发现压测量级的实时观测。 配置核心监控对于配置核心，MSE Nacos 同样提供了专门的监控页面，次要监测指标包含： 配置核心次要业务指标：配置数、配置监听者数；配置核心访问量指标：配置核心 TPS、QPS、写 RT、读 RT 等。在这个大盘下，用户能够进行各项配置管理外围指标的校验，例如当配置管理业务上呈现推送配置不及时时，能够通过读写 RT 指标疾速定位以后配置核心的相应工夫； ...

背景11 月 5 日，2022 杭州 · 云栖大会上，阿里云发表函数计算 FC 开启全面提价，vCPU 单价降幅 11% ，其余的各个独立计费项最高降幅达 37.5% 。 本次云栖大会上，阿里云智能总裁张建锋示意，以云为外围的新型计算体系正在造成，软件研发范式正在产生新的改革，Serverless 是其中最重要的趋势之一，阿里云将动摇推动外围产品全面 Serverless 化，帮忙客户更好地实现麻利翻新。函数计算 FC 全面提价，让 Serverless 更加普惠。用户可随用随取，按量计费，用更低成本采纳 Serverless 架构，尽享 Serverless 带来的研发效率晋升和技术红利。 关注阿里云云原生公众号，后盾回复关键词【手册】查看 Serverless 产品手册！ 阿里云函数计算 FC 全面提价，让 Serverless 更普惠计费粒度更精密，按需付费就是省函数计算 FC 计费粒度精密，按执行环境的内存和执行工夫计费，**计费规格最低可达到 1 毫秒粒度的计费时长，0.05 核 vCPU、128MB内存、1/16 GPU 卡用户能够只为申请产生的资源耗费买单，极致管制老本。 函数计算 FC 上线新版资源包，函数规格 vCPU、内存、磁盘等各个计费项的绑定彻底解绑，让用户能够按需自在选配，贴合本人的利用运行时开销选取规格，进一步升高资源闲置比例。预留模式作为函数计算 FC 打消冷启动的利器，新增了闲置计费仅 1/10 价格更加让业务能罢黜高老本的后顾之忧。 据团队测算，一个集群的资源如果日均利用率在 30% 以下，或者有显著的闲置节约，就适宜应用函数计算 FC。采纳函数计算 FC 之后资源利用率可能进步到 60% 甚至 90% 以上，综合老本升高 15% 到 70%。当您的业务 CPU 利用率低于 50%，或 GPU 利用率低于 30%，迁徙上函数计算 FC 能够实现降本。 ...

作者：徒钟 什么是音讯过滤在消息中间件的应用过程中，一个主题对应的消费者想要通过规定只生产这个主题下具备某些特色的音讯，过滤掉本人不关怀的音讯，这个性能就叫音讯过滤。 就如上图所形容的，生产者会向主题中写入不拘一格的音讯，有橙色的、黄色的、还有灰色的，而这个主题有两个消费者，第一个消费者只想要生产橙色的音讯，第二个消费者只想要生产黄色的和灰色的音讯，那么这个成果就须要通过音讯过滤来实现。 音讯过滤的利用场景咱们以常见的电商场景为例，来看看音讯过滤在理论利用过程中起到的作用。 电商平台在设计时，往往存在零碎拆分细、功能模块多、调用链路长、零碎依赖简单等特点，消息中间件在其中就起到了异步解耦、异步通信的作用，特地是在双十一这样的流量高峰期，消息中间件还起到了削峰填谷的作用。 而在消息中间件应用方面，电商平台因为笼罩的畛域泛滥会产生很多的音讯主题，音讯收发量也随着交易量和订阅零碎的减少而增大。随着业务零碎的程度拆解和垂直减少，相干的音讯呈现出高订阅比和低投递比的状态，比方一个主题订阅比是 300:1，即 1 个主题的订阅者有 300 个，然而投递比却只有 15:300，即一条音讯只有 15 个订阅者须要投递，其余 285 个订阅者全副过滤了这条音讯。那解决这些场景，就须要应用到音讯过滤。 举例来说，在交易链路中，一个订单的解决流程分为下单、扣减库存、领取等流程，这个流程会波及订单操作和状态机的变动。上游的零碎，如积分、物流、告诉、实时计算等，他们会通过消息中间件监听订单的变更音讯。然而它们对订单不同操作和状态的音讯有着不同的需要，如积分零碎只关怀下单音讯，只有下单就扣减积分。物流零碎只关系领取和收货音讯，领取就发动物流订单，收货就实现物流订单。实时计算零碎会统计订单不同状态的数据，所有音讯都要接管。 试想一下如果没有音讯过滤这个性能，咱们会怎么反对以上音讯过滤的性能呢？能想到的个别有以下两个计划： 1. 通过将主题进行拆分，将不同的音讯发送到不同主题上。对于生产者来说，这意味着消费者有多少生产场景，就须要新建多少个 Topic，这无疑会给生产者带来微小的保护老本。对消费者来说，消费者有可能须要同时订阅多个 Topic，这同样带来了很大的保护老本。另外，音讯被主题拆分后，他们之间的生产程序就无奈保障了，比方对于一个订单，它的下单、领取等操作显然是要被程序解决的。 2. 消费者收到音讯后，依据音讯体对音讯依照规定硬编码自行过滤。这意味着所有的音讯都会推送到消费者端进行计算，这无疑减少了网络带宽，也减少了消费者在内存和 CPU 上的耗费。 有了音讯过滤这个性能，生产者只需向一个主题进行投递音讯，服务端依据订阅规定进行计算，并按需投递给每个消费者。这样对生产者和消费者的代码保护就十分敌对，同时也能很大水平上升高网络带宽，同时缩小消费者的内存占用和 CPU 的耗费。 RocketMQ 音讯过滤的模式RocketMQ 是泛滥消息中间件中为数不多反对音讯过滤的零碎。这也是其作为业务集成音讯首选计划的重要根底之一。 在性能层面，RocketMQ 反对两种过滤形式，Tag 标签过滤和 SQL 属性过滤，上面我来这两个过滤形式应用形式和技术原理进行介绍 Tag 标签过滤性能介绍Tag 标签过滤形式是 RocketMQ 提供的根底音讯过滤能力，基于生产者为音讯设置的 Tag 标签进行匹配。生产者在发送音讯时，设置音讯的 Tag 标签，消费者按需指定已有的 Tag 标签来进行匹配订阅。 过滤语法单 Tag 匹配：过滤表达式为指标 Tag，示意只有音讯标签为指定指标 Tag 的音讯合乎匹配条件，会被发送给消费者；多 Tag 匹配：多个 Tag 之间为或的关系，不同 Tag 间应用两个竖线（||）隔开。例如，Tag1||Tag2||Tag3，示意标签为 Tag1 或 Tag2 或 Tag3 的音讯都满足匹配条件，都会被发送给消费者进行生产；全 Tag 匹配：应用星号（*）作为全匹配表达式。示意主题下的所有音讯都将被发送给消费者进行生产。应用形式发送音讯，设置 Tag 标签Message message = provider.newMessageBuilder() .setTopic("TopicA") .setKeys("messageKey") //设置音讯Tag，用于生产端依据指定Tag过滤音讯 .setTag("TagA") .setBody("messageBody".getBytes()) .build();订阅音讯，匹配单个 Tag 标签//只订阅音讯标签为“TagA”的音讯FilterExpression filterExpression = new FilterExpression("TagA", FilterExpressionType.TAG);pushConsumer.subscribe("TopicA", filterExpression);订阅音讯，匹配多个 Tag 标签//只订阅音讯标签为“TagA”、“TagB”或“TagC”的音讯FilterExpression filterExpression = new FilterExpression("TagA||TagB||TagC", FilterExpressionType.TAG);pushConsumer.subscribe("TopicA", filterExpression);订阅音讯，匹配所有 Tag 标签，即不过滤//应用Tag标签过滤音讯，订阅所有音讯FilterExpression filterExpression = new FilterExpression("*", FilterExpressionType.TAG);pushConsumer.subscribe("TopicA", filterExpression);技术原理 ...

作者：Regan Yue 本文选自“Serverless 函数计算征集令”流动什么是 ServerlessServerless 是一种基于云计算的开发方法，它让开发人员能够专一于编写代码来解决业务问题，而不是解决服务器问题。它是举世无双的，因为它反对 Auto Scaling，执行应用程序所需的计算能力是按需分配的。并且应用一种称为事件驱动函数的模型来确定这些需要的范畴。这就是 Serverless 架构，也称为性能即服务 (FaaS)。 部署、初步体验工作开明阿里云函数计算 FC，点击下方链接追随提醒即可开明。开明地址：https://fcnext.console.aliyun...通过模版创立利用 绑定 Github，而后抉择好角色，点击创立 这样就部署胜利了。 拜访域名即可： 无论是网页调用还是脚本调用，调用速度都比拟快！ 能够看到应用阿里云 Serverless Devs 部署基于 Serverless 图像预测案例是非常晦涩的。上面是评分和点评： 上手容易度：⭐⭐⭐⭐⭐ 服务监控性能：⭐⭐⭐⭐⭐ 部署速度：⭐⭐⭐⭐ 执行速度：⭐⭐⭐⭐ 案例资源丰盛度：⭐⭐⭐ 总体评估：⭐⭐⭐⭐ 体验在线编辑、再次部署通过服务列表-》服务 png-compress 详情-》函数治理-》函数详情-》函数代码能够在线编辑函数，进行开发。 我将阐明删除后，再次部署： 整个流程很晦涩，不过不晓得为什么利用那里部署历史没有变动，没有看到函数的部署历史。如果是这样的话，那么函数部署如何回滚？ 体验后我有几方面的倡议和心得： 在线编辑代码性能倡议上线上传文件性能函数部署倡议有历史部署性能，以便能够回滚。 通过应用阿里云 Serverless Devs 部署基于 Serverless 图像预测案例，体验了阿里云 Serverless 的局部次要性能，阿里云 Serverless 的功能强大、上手容易、性能也不弱，不过目前利用模板还不够丰盛，大部分是环境类模板，这方面有待增强；此外阿里云每月有 100 万次函数调用收费额度、每月前 400,000（GB-秒）函数实例资源的收费使用量，这对开发者来说非常敌对。

作者：丁宇 11月5日，2022杭州·云栖大会上，阿里巴巴研究员、阿里云智能云原生利用平台总经理丁宇在云原生峰会上发表主题演讲，提出云原生激活利用构建新范式，并示意Serverless将引领下一代利用架构。 阿里云将动摇推动外围产品全面Serverless 化，帮忙客户最大限度的加重运维工作，更好的实现麻利翻新。 云计算时代，企业上云后，利用构建仍然面临很多挑战，如何保障系统资源的弹性、降本增效；如何做到利用麻利开发，实现业务疾速迭代；如何保障系统的稳固以及业务的连续性，这些问题没有齐全解决。 咱们看到，云原生曾经变成十分风行的技术趋势，从上云到用云，云原生可能从PaaS 层面帮忙企业解决利用构建的一系列问题。具体有三大范式正在成为事实： 第一个范式是全面容器化。 因为容器造成了运维的规范，成为企业上云用云的新界面，也变成开发者和利用零碎交互的新界面，有利于构建高弹性、可伸缩的零碎，从而实现降本增效。当下所有的负载都在容器化，包含耳熟能详的微服务、在线利用到整个数据库、大数据、AI、中间件等，所有的工作负载都在容器化。 通过容器，咱们能够享受到运维标准化、弹性架构带来的益处，也带来了软件能够无处不在的部署交付，标准化的治理运维。 第二个范式是整个行业利用的核心技术互联网化。 咱们正在用互联网的技术、互联网的架构思维来重构利用零碎，从而带来了很多益处：分布式可扩大，撑持业务麻利迭代，构建弹性架构，从容应对流量顶峰。 举例来说，筹备一场促销流动、一场跨年晚会，都可能有不可预期的流量顶峰，数字化零碎须要应答不确定的流量，必须要用互联网架构来实现；此外保障系统高可用、高牢靠，保障业务的连续性，也是互联网技术可能带给企业的红利。 第三个范式是利用的Serverless化。 从技术角度来看，可能实现技术组件分层解耦，让利用能够做到全托管免运维，晋升零碎的可运维性，降低成本。通过极致弹性，可能把所有的组件笼罩，在云上构建利用变得非常简单。 以前构建利用，须要买ECS实例，搭建开源软件体系而后保护它，流量大了扩容，流量小了缩容，整个过程很简单繁琐。用了Serverless服务当前，这些问题都简化了，从半托管到全托管，所有的服务API化，有限容量充沛弹性，能够组装应用，可能感触到生产力大幅度的扭转。也会在软件开发的全生命周期进行优化，降级研发模式，让开发者更多的聚焦在业务上，减速迭代。 以上这三个范式代表着云原生十分支流的演进方向。 全面容器化：容器服务进入智能化时代Gartner预测，到2022年，超过75%的寰球组织会在他们的生产环境中运行容器化的利用，而这一数据在2020年才不到30%。 咱们看到，容器技术曾经逾越鸿沟，从晚期的互联网行业到当初的千行百业，都在生产零碎中应用。 尽管 ACK 大幅升高了K8s的门槛，但治理和运维一个大规模、分布式的集群仍然充斥挑战，比方说，如何调度利用，在保障稳固的同时，晋升资源利用率；如何对利用进行老本布局、剖析优化；当集群呈现问题后，如何及时的定位和修复。 智能化能够解决这些问题，智能化是容器平台倒退的必然趋势。 阿里云基于过来10年的大规模容器实战经验，通过数据化伎俩和智能化算法，推动容器服务ACK走向智能化。其中有三个降级： 第一个降级，智能化的混部调度，新一代调度零碎Koordinator，帮忙用户晋升整体资源利用率，智能化混部调度助力识货 App节俭 20% 资源老本。 第二个降级，智能化的老本治理，容器服务 FinOps套件，帮忙用户实现上云老本可见、可控、可优化，中华保险基于容器 FinOps 套件实现资源闲置率从30%升高到 10%。 第三个降级，智能化的运维体验，容器服务 AIOps套件，帮忙用户实现数据驱动诊断决策，助力故障进攻定位，自动化诊断能够笼罩 90% 以上的问题，得物 App 基于容器 AIOps 套件定位问题工夫从周缩短到小时。 这些能力降级，会进一步升高容器技术的应用门槛，让 ACK 做到普惠化，服务更宽泛的客户群体。 核心技术互联网化互联网中间件产品有三个特点： 第一个就是开源全兼容，齐全没有厂商锁定，像微服务、音讯、服务注册发现、网关等，都是跟开源齐全兼容的。 第二个特点是大量的企业级个性加持，包含性能、稳定性、扩展性等。互联网分布式技术的先进性须要十分好的场景锻炼，阿里云的劣势就在于多年双11简单场景的打磨，基于双11的加持以及海量客户的利用，使得阿里云互联网技术在企业级个性上有十分强劲的劣势。 第三个特点有丰盛的技术类解决方案，包含异地多活，利用容灾的计划、技术中台、业务中台的计划，以及混部、混沌工程和全链路压测计划等。云原生中间件实现了开源、自研和商业化的三位一体，可能助力更多企业应用规范凋谢的技术实现数字化转型。 重磅公布一 微服务再降级：新增云原生网关开源云原生时代，微服务面临着新的诉求和技术挑战，尤其是在性能、高可用性和安全性方面。明天，阿里云正式开源云原生网关 Higress，它是业内首个标准化、高集成、易扩大、热更新的云原生网关。 标准化： 随着K8s的遍及，K8s Ingress 逐步成为云原生时代API事实标准， Higress全面反对该规范，并且在服务治理方面（包含灰度、限流、预热、超时、重试）做大幅加强，引领规范演进方向。 高集成： Higress首次将流量网关、微服务网关、平安网关三合一，打造高集成网关，在入口建设高性能、平安防线，后端反对K8s/Nacos/ECS/Serverless多种运行时路由，打造性能最弱小网关实现。 易扩大： Higress提供最丰盛插件扩大机制，满足客户灵便路由和平安定制需要，反对最全面语言扩大机制；当然咱们为了升高客户应用门槛，默认集成了数十个插件，并且通过插件市场不便开发者奉献通用能力，产生良性互动。 热更新： 因为传统Nginx更新规定须要reload会导致链接抖动，导致流量损失，对实时通信、视频、IoT无奈容忍，因而Higress 从证书、路由、平安规定、插件全副采纳热更新机制，毫秒级失效且业务无感知。 除了开源云原生网关之外，阿里云全面降级微服务引擎MSE3.0，蕴含三大外围能力： 第一大能力是注册配置核心 ， 相比Nacos等支流开源计划，性能晋升40%，提供70+的监控指标，提供衰弱检测，帮忙客户实现服务异样自治，例如禾连衰弱这家医疗行业的SaaS企业，通过MSE注册配置核心，晋升开源注册配置核心性能达50%，解决了业务高速倒退中的扩展性问题，保障全国 200 多个城市、2000 多家医院体验业务的稳定性超99.99%。  第二大能力是微服务治理 ， 积淀了阿里巴巴10+的实践经验，帮忙客户缩短30%微服务治理落地周期，晋升50%开发测试效率，打消80%线上危险。例如纺织产业互联网企业致景科技，未修改任何代码就接入了MSE微服务治理所有能力。微服务施行周期降落 30%，构建开发测试环境从天升高到分钟。 ...

作者： 魁予 问题提出流量有损是在利用公布时的常见问题，其景象通常会反馈到流量监控上，如下图所示，公布过程中服务 RT 忽然升高，造成局部业务响应变慢，给用户的最直观体验就是卡顿；或是申请的 500 谬误数突增，在用户侧可能感触到服务降级或服务不可用，从而影响用户体验。 因为利用发布会随同流量有损，所以咱们往往须要将公布打算移到业务低谷期，并严格限度利用公布的持续时间，尽管如此，还是不能完全避免公布带来的危险，有时甚至不得不抉择停机公布。EDAS 作为一个通用利用管理系统，利用公布是其最根本的性能之一，而 K8s 利用是 EDAS 中最广泛的利用的状态，下文将通过对 EDAS 客户实在场景的演绎，从 K8s 的流量门路动手，剖析有损公布产生的起因，并提供实用的解决方案。 流量路径分析K8s 中，流量通常能够从以下几种门路进入到利用 Pod 中，每条门路天壤之别，流量损失的起因各不相同。咱们将分状况探索每种门路的路由机制，以及 Pod 变更对流量门路的影响。 LB Service 流量 通过 LoadBalancer 类型 Service 拜访利用时，流量门路中外围组件是 LoadBalancer 和 ipvs/iptables。LoadBalancer 负责接管 K8s 集群内部流量并转发到 Node 节点上，ipvs/iptables 负责将节点接管到的流量转发到 Pod 中。外围组件的动作由 CCM（cloud-controller-manager）和 kube-proxy 驱动，别离负责更新 LoadBalancer 后端和 ipvs/iptables 规定。 在利用公布时，就绪的 Pod 会被增加到 Endpoint 后端，Terminating 状态的 Pod 会从 Endpoint 中移除。kube-proxy 组件会更新各节点的 ipvs/iptables 规定，CCM 组件监听到了 Endpoint 的变更后会调用云厂商 API 更新负载均衡器后端，将 Node IP 和端口更新到后端列表中。流量进入后，会依据负载均衡器配置的监听后端列表转发到对应的节点，再由节点 ipvs/iptables 转发到理论 Pod。 ...

作者：Koordinator 团队 Koordinator 从 2022 年 4 月公布以来，迄今一共迭代公布了 8 个版本。我的项目经验的大半年倒退过程中，Koordinator 社区吸纳了包含阿里巴巴、小米、小红书、爱奇艺、360 在内的大量优良工程师，奉献了泛滥的想法、代码和场景，一起推动 Koordinator 我的项目的成熟。 11 月 3 日，在 2022 杭州 · 云栖大会上，阿里云智能云原生利用平台负责人丁宇发表，Koordinator 1.0 正式公布。 如果你对混部、调度畛域不太关注，可能对 Koordinator 还没有做过太深刻的理解。本文就借着 v1.0 公布机会，为你具体的梳理一次 Koordinator 我的项目的倒退脉络，解读它的核心思想和愿景，把握这个正在疾速倒退的云原生混部零碎的技术理念。 我的项目的前生今世Koordinator，名字取自 coordinator，K for Kubernetes，发音雷同。语意上符合我的项目要解决的问题，即协调编排 kubernetes 集群中不同类型的工作负载，使得他们以最优的布局、最佳的姿势在一个集群、一个节点上运行。 容器混部技术最早起源于 Google 外部的一个 Borg 零碎，在其论文公开发表（2015）之前在行业上始终是十分神秘的存在。在业界，基于 Hadoop 的大数据任务调度技术后行，在比拟晚期很好的解决了企业对于大数据计算的诉求。相熟历史的同学应该晓得，云原生容器调度编排零碎 Kubernetes 开源于 2014 年， 而  Kubernetes 正是受 Borg 设计思维启发，由 Borg 零碎的设计者联合云时代利用编排的需要从新设计而来。Kubernetes 良好的扩展性使其能适应多样的工作负载，帮忙用户很好的解决工作负载日常运维效率。随着 Kubernetes 的蓬勃发展，逐渐成为行业的事实标准，越来越多的工作负载开始运行在 Kubernetes 之上，特地是在这两年，大数据相干的负载逐渐迁徙到 Kubernetes 之上。 阿里巴巴早在 2016 年就启动了混部技术研发，到往年，内混部零碎经验了三轮大的架构降级，并经验多年“双11”峰值流量的锻炼。目前，阿里巴巴实现全业务规模超千万核的云原生混部，混部 CPU 利用率超 50%，混部技术帮忙 2022 年“双11”计算成本大幅降落。在这个过程中，阿里巴巴混部也走过了一些弯路，积攒了大量的生产实践经验。 ...

11 月 3 日，2022 杭州·云栖大会上，阿里云智能总裁张建锋示意，以云为外围的新型计算体系正在造成，软件研发范式正在产生新的改革，Serverless 是其中最重要的趋势之一，阿里云将动摇推动外围产品全面Serverless 化，帮忙客户更好地实现麻利翻新。 “咱们心愿让用户做得更少而播种更多，通过Serverless化，用云就像用电一样简略。”张建锋示意，Serverless 让云计算从一种资源真正变成一种能力，将来云将全面Serverless化，更加靠近“电网”模式，按计算的调用次数付费。 Serverless 并不是不必服务器，它是将服务器全权托管给了云厂商，依据业务流量大小主动弹性伸缩，开箱即用免去保护老本，按使用量计费。用户无需关怀和治理底层IT资源，只有聚焦业务代码，依据理论申请解决业务。 依靠于 Serverless 架构，云上研发形式正在产生根本性的扭转。从过来的集中式研发、分布式研发，到云上的组装式研发，实现了软件研发的服务化、模块化、可编排、可组装。无论是2万用户还是2000万用户体量，基于 Serverless 构建的IT架构都能够自适应伸缩，峰值秒级主动扩容、峰谷主动缩容。 基于 Serverless 产品，云产品都变成模块化、API 化、服务化，它能够进行组装，通过利落拽的形式就可能构建利用，并通过流程驱动和事件驱动，让利用构建可视化，从而取得更弱小的利用能力。 阿里云是国内最早提供 Serverless 计算服务的云厂商。 2017 年推出的函数计算 FC 是一款 FaaS 产品，这是一种以事件驱动的全托管计算服务，用户只需编写代码并上传，函数计算就会主动筹备好计算资源，以弹性、牢靠的形式运行代码，并提供日志查问、性能监控、报警等性能。2018年当先业界推出 Serverless 容器服务 ASK，基于弹性容器实例 ECI（Elastic Container Instance），能够实现 1min 扩容 2000个 pod，升高了 Kubernetes 应用门槛，让用户更专一于应用程序，而不是治理底层基础设施。2019年推出首款面向利用的 Serverless PaaS（SAE），提供老本更优、效率更高的一站式微服务和 K8s 托管计划，零革新实现 web/微服务/工作的迁徙。2020年开源 Serverless 开发者平台 Serverless Devs，这是业内首个反对支流 Serverless 服务/框架的云原生全生命周期治理平台。2022 年 9 月，Serverless Devs 正式成为 CNCF 官网沙箱我的项目，也成为 CNCF 首个 Serverless Tool 我的项目。2022年 Serverless 利用核心公布，它是一个 Serverless 利用全生命周期治理平台，用户不须要在部署利用之前进行额定的克隆、构建、打包和公布操作，就能够疾速部署和治理利用。权威剖析机构 Gartner 预测，2025 年将有 50% 以上的寰球企业部署 Serverless 架构。从利用场景上来看，除小程序外，Serverless 还受到电商大促、音视频转码、AI 算法服务、游戏利用包散发、文件实时处理、物联网数据处理、微服务等场景的青眼。 ...

引言随着云计算的遍及，企业用到越来越多云产品，例如：ECS、RDS、Redis 等。服务泛滥企业之后，阿里云可观测团队发现在运维场景愈发精细化的明天，对于指标按需再加工、对于告警规定的灵便设置成为刚需，云监控等根底默认监控能力，无奈满足当下的运维需要，例如： 查看各 Region ECS CPU 使用率 Top10；为 Kafka 服务间断 10 分钟沉积增量超过 500 的 ConsumerGroup 设置告警；基于磁盘空间的变动预测清理工夫，防止告警无奈及时处理导致故障。 与此同时，Prometheus + Grafana 成为可观测性事实标准。运维团队能够应用 Prometheus 监控云原生 Kubernetes 体系 Node、ApiServer、workload 等根底指标的同时，还能够通过 Prometheus Exporters 采集各种组件（如 Redis、Kafka 等）和业务利用的相干指标，最初通过 Grafana 进行整体可视化展现，借助 AlertManager 进行告警，实现云原生时代的指标可观测闭环。 回到最开始的话题，随着云产品利用愈发遍及，基于“Prometheus + Grafana”的指标可观测体系是否能够针对云产品的相干指标提供更加精细化的加工与利用能力，实现对云产品的指标可观测闭环？ 答案是必定的。 自建 Prometheus 监控云产品的挑战尽管 Prometheus 官网社区保护了很多 Exporter，第三方厂商或者支流开源我的项目也参加到奉献及保护中。但因为云产品的特殊性，如果用户想要通过自建 Prometheus 去监控云产品，就须要用户通过 Prometheus Exporter 模式将观测到的 Metric 数据收集到服务端。但这里就会呈现一些对于 Exporter 的额定工作量： 额定的研发工作量尽管官网提供了四种语言（Go/Java/Python/Rubby）的正式客户端库用来开发一个集成 http server 的 Exporter 库，并提供了残缺的开发标准。但这须要运维工程师针对不同云产品开发定制 Exporter（调用企业云监控实时导出服务获取 Metric 数据），对于开箱即用的云服务而言，拖慢了业务上线效率。 额定的 Exporter 资源耗费因为 Exporter 自身提供了一个 REST 服务器，会带来一些线程耗费，随着 Exporter 接入云产品越多、指标越多耗费的资源也会随之越多。 ...

2022年云栖大会上，阿里巴巴团体副总裁、阿里云计算平台事业部负责人贾扬清发表阿里云一体化大数据平台ODPS全面降级。降级后的ODPS反对对立存储、对立调度、对立元数据的一体化交融架构，反对离线计算（ODPS-MaxCompute）、实时交互式剖析(ODPS-Hologres)等引擎，提供机器学习、流式计算等可扩大的计算能力，具备寰球当先的技术性能和产品性价比。 10月31日，国内事务处理性能委员会（TPC，Transaction Processing Performance Council）官网公布TPC-H 30,000GB规范测试最新后果，首次加入此项评测的ODPS-Hologres以QphH超2786万分的性能后果斩获寰球冠军，当先第二名23%。TPC-H是公认的掂量产品数据分析能力的权威规范测试之一，其QphH指标反映了零碎解决查问的多方面能力，包含数据规模的大小、串行提交时的Query提早、多租户并行提交时的Query吞吐等，是代表产品的综合性能的重要指标。TPC官网显示，ODPS-Hologres在[email protected],000GB达2786万分，为寰球第一。该问题证实了ODPS-Hologres在大规模数据多维分析（OLAP）场景上兼具超低提早和高吞吐性能，具备世界级数据分析性能，技术先进性可满足业务对数据的极速摸索需要。同时，ODPS-Hologres在性价比指标Price/kQphH的体现也领跑寰球，彰显了其以较低成本在大规模数据上取得极致性能的能力。 此外，作为ODPS的另一个主力计算引擎MaxCompute，也在TPCx-Bigbench 100TB规范测试中，从数据规模、性能、老本三个方面，自2017年以来间断6年放弃寰球冠军。2022年，更是较2021年在性能上晋升40%，同时老本降落近30%。 友邦人寿基于阿里云ODPS建设云上数据中台，实现外部数据对立的开发、服务、治理，数据处理效率晋升20倍，整体老本优化数百万元。依靠云的弹性扩大能力平滑应答“开门红”等业务流量顶峰，保障高峰期的实时剖析决策。 阿里云一体化大数据平台ODPS将继续夯实一体化的体验同时，满足客户多元化计算需要，为企业智能翻新提供基石般稳固保障。

11月3日，2022云栖大会上，阿里巴巴团体副总裁、阿里云计算平台事业部负责人贾扬清示意，为满足用户多元化数据计算需要，阿里云ODPS降级为一体化大数据平台。 降级后的ODPS反对大规模批量计算、实时剖析等服务，提供实时流式计算、机器学习等多种计算能力，可同时调度超10万台以上服务器规模进行并行计算。ODPS也是目前中国惟一自研、利用最为宽泛的一体化大数据平台。 ODPS降级：存储、调度、元数据一体化交融 随着数据技术和数据利用的倒退，催生了多元计算需要。贾扬清介绍，例如交通畛域，须要实时数据计算，来做城市大脑外面人流车流的优化；科研方面，须要AI算法辅助传统物理化学生物钻研翻新；保险畛域，须要大量数据聚合来进行更精确的危险精算。 ODPS实现了存储、调度、元数据管理上的一体化架构交融，撑持上述各类数据的高效解决。 自2009年诞生以来，ODPS从冲破单集群规模到通过多租户隔离打造金融级云上平安，为冲破业界难攻的技术难点而一直降级架构。2017年，ODPS将大规模批处理引擎MaxCompute以独立产品模式对外提供服务。2019年，应答数据实时交互剖析的需要，交互式计算引擎Hologres正式上线。 在刚刚颁布的TPC-H 30000GB基准测试中，ODPS-Hologres刷新世界纪录，分数超过2786万分，当先第二名23%。ODPS-MaxCompute则在TPCx-BB 100TB规范测试中，间断6年放弃性能和性价比第一。 大数据和AI走向交融 小鹏汽车AI训练提速170倍 “大数据平台和AI平台正在走向交融”，贾扬清示意，不论是大模型生产利用、AI for Science、还是传统的搜推广服务，典型的AI利用场景背地，都离不开数据的高效流转和剖析。例如小鹏汽车与阿里云单干，建设了大数据AI一体化平台，实现从海量路采数据的传输存储剖析、到AI模型训练推理的全流程提效。此外，基于软硬件协同优化技术，小鹏汽车主动驾驶外围模型训练提速近170倍，训练性能较开源计划晋升30%。 自公布大数据+AI一体化产品体系“阿里灵杰”以来，阿里云一直推动数据智能在产业中广泛应用。机器学习平台PAI继续夯实AI工程能力，实现深度学习框架和计算硬件的多样化兼容，以弹性且稳固的云原生AI平台服务，撑持主动驾驶、生命科学、金融等畛域翻新。此外，达摩院基于阿里灵杰，推出模型凋谢生态 ModelScope 和 AI 凋谢服务平台 OpenMind，进一步推动AI普惠。

作者：三辰 前言大家好，明天给大家带来 MSE 高可用方向的重要性能——风险管理的公布。 浏览这篇文章，你将可能理解以下知识点和能力： 相熟微服务体系高可用如何设计把握如何控制系统中的危险理解MSE微服务引擎风险管理性能能解决什么危险相熟如何应用风险管理性能理解风险管理更多高级性能的将来布局微服务高可用如何设计大促场景如何做高可用阿里巴巴十几年的大促教训，积攒了一套成熟的微服务高可用评估体系。 咱们当初以大促场景为例，谈谈如何做好高可用。 大促高可用 首先从架构上看，外部的电商、物流、娱乐等业务零碎，都是基于 MSE 微服务引擎提供的云原生网关和 Nacos 注册配置核心构建的微服务体系。并且在整个链路上基于 MSE 的 Sentinel 笼罩限流降级的能力，基于 ARMS 的 Prometheus 和 Tracing 能力做好链路的可观测。 底层容器化，基于 K8s 这一套成熟的调度体系，解决资源利用率、疾速交付和弹性的问题。 在大促行将到来之前，通过 PTS 提供的全链路压测能力，对整个大促波及的所有链路进行端到端的压测，模仿实在大促流量，观测每个业务子系统的体现，验证限流降级预案执行准确无误。峰值前疾速弹性上线，峰值后疾速缩容下线。 MSE 微服务引擎介绍基于这一套双十一大促实践经验，阿里中间件团队将这一套微服务最佳实际开源，并提供了一套残缺的商业化解决方案。以满足内部客户对高性能、高可用、高集成度和平安的述求。 微服务引擎（Micro Service Engine，简称 MSE）是一个面向业界支流开源微服务生态的一站式微服务平台。 高可用设计思路零碎组成那么，一套微服务零碎如果从零开始搭建，应该如何设计保障高可用呢？ 咱们用一张简略的图来示意一个微服务零碎的根本架构。 微服务零碎全链路蕴含网关、注册配置核心、业务子系统，任何中央都是「牵一发而动全身」，一个抖动都可能会较大范畴地影响整个零碎。 每个业务子系统之间调用关系通常也非常复杂，甚至是网状的。 可能产生什么问题？这套最小零碎的每一个局部都可能产生问题，咱们来看看都有哪些。 先从入口的网关来看，最典型的问题就是容量有余，导致吞吐量降落。体现就是用户拜访零碎呈现超时；也有可能是错配导致流量失落，用户拜访的页面找不到打不开，比方最风行的 Nginx，没有页面操作，都是黑屏管制，很容易呈现漏配、错配的问题，也短少配置版本的治理，非常容易失误。 注册核心故障，会导致注册失败，影响大促场景下疾速弹性上线，新的容器都无奈注册上来。在服务调用方还可能收到空列表的状况。 配置核心出问题，会导致危险预案无奈下发，不能对业务降级。 业务子系统更加简单，可能呈现某个子系统流量瓶颈，拖垮整个流量的状况。业务异样短少观测伎俩，该打日志的中央没有任何信息。这些都须要借助服务治理的能力解决。 这些问题都是以往的大促流动中实在案例，每一个高可用计划的背地，都是一段血泪史。 面对危险设计咱们不得不抵赖一个事实：没有任何零碎是百分之百没有问题的。 高可用架构就是面对失败设计，或者说是面对危险设计。 基础设施意外危险，最典型的就是几年前，杭州某条光缆被地铁施工挖断，导致全国的支付宝都用不了。这种危险一旦产生，业务很难接受。 还有操作系统依赖上，可能有存储故障、网络抖动、工夫服务不稳固、DNS 故障等等，零碎 hang 死了连监控报警都有可能上不来。 还有业务零碎服务端故障、内存泄露，客户端连接池满，运维人为误操作等。 尽管咱们不可避免危险产生，然而，咱们能够管制危险。高可用的实质：管制危险 如何管制危险危险管制的策略大抵能够分为四种策略管制危险，如下图： 有了相应的策略，咱们如何提前辨认危险并加以控制？ 辨认不同危险咱们把危险分成几类： 架构危险版本危险容量危险平安危险 架构危险例如： 注册配置核心、网关、业务零碎单节点都无奈高可用Nacos、ZK等注册核心一致性协定对单数节点存在无奈选主的问题，写申请不可用注册核心节点在可用区散布不均，可用区故障可能导致集群不可用业务零碎架构危险：无注册核心容灾措施（如推空爱护、服务列表缓存&降级计划）这些都能够算作架构危险。 MSE 注册配置核心三 AZ 容灾架构 ...

作者：卜比 在公布过程中，为了产品整体稳定性，咱们总是心愿可能用小局部特定流量来验证下新版本利用是否能失常工作。 即便新版本有问题，也能及时发现，管制影响面，保障了整体的稳定性。 整体架构咱们以如下 Demo 为例： 为了保障稳固，咱们约定如下上线流程： 其中，在灰度验证中，有几种不同的策略： 间接应用线上小局部流量来测试（依照百分比放量）从线上依照特定规定抉择流量（比方特定的 header、特定的 cookie 等）在客户端或浏览器上标识出流量是否灰度（比方通过 header 传递）部署利用&创立泳道依照参考文档在 Kubernetes 集群中部署利用后，咱们首先要辨别线上流量和灰度流量。 部署文档： https://github.com/aliyun/ali... 创立泳道组，抉择入口利用以及整个链路波及到的利用： 而后创立泳道，将合乎规定的流量划入 gray 泳道： 注：没有匹配的流量，会走到基线环境，也就是没有打标的利用节点上。配置实现后，拜访网关，如果不合乎灰度规定，走基线环境： 如何合乎灰度规定，走灰度环境： 配置云效流水线在本例中，应用“其余 · 空模板”创立云效流水线，创立后，须要进行四局部配置： 流水线源配置好流水线的起源，比方代码仓库等。 代码仓库：https://gitee.com/mse-group/a...（为了防止网络提早，所以采纳 gitee 仓库）默认分支：master服务连贯：能够通过增加服务连贯按钮增加，因为本例中代码仓库为公开代码仓库，所以只须要依照默认值创立即可。 配置实现后，增加到流水线中。 构建阶段配置此阶段配置云效如何构建 docker 镜像。 删除原有的阶段和空工作，手动增加新工作“镜像构建”： 配置参数如下： 构建集群：就近抉择，国内能够抉择“北京构建集群”服务连贯：您能够依照提醒增加 ACR 的服务连贯，通过 RAM 受权的形式，让云效能够推送镜像到 ACR 中仓库：抉择您须要推送、部署的镜像仓库标签：保留默认${DATETIME}即可。Dockerfile 门路：mse-simple-demo/A/Dockerfile 配置好后，增加即可。 部署 gray 阶段配置本步骤批示云效如何部署 gray 节点。因为云效能够间接替换 Kubernetes 中的 workload 镜像，咱们能够间接应用此机制来公布。 配置参数如下： 集群连贯：用来受权云效批改 ACK 集群中 workload 配置。依照受权增加对应 ACK 集群连贯即可Kubectl 版本：抉择相近版本即可命名空间：依照理论状况抉择Workloads 类型：本例中是 DeploymentWorkloads 名称：本例中是 spring-cloud-a-gray容器名称：本例中是 spring-cloud-a-gray镜像：抉择上一步构建的后果，能够抉择“镜像公网地址” 部署线上阶段配置 ...