阿里云

作者：炎寻 过来一年，ARMS 基于 eBPF 技术打造了 Kubernetes 监控，提供多语言无侵入的利用性能，零碎性能，网络性能观测能力，并公布 Kubernetes 问题排查全景图，验证了 eBPF 技术的有效性。eBPF 技术和生态倒退很好，将来前景宽广，作为该技术的实践者，本文指标是通过答复 7 个外围问题介绍 eBPF 技术自身，为大家解开 eBPF 的面纱。 关注【阿里云云原生】公众号，后盾回复关键词【K8s全景图】获取全景图高清下载地址！ eBPF 是什么eBPF 是一个可能在内核运行沙箱程序的技术，提供了一种在内核事件和用户程序事件产生时平安注入代码的机制，使得非内核开发人员也能够对内核进行管制。随着内核的倒退，eBPF 逐渐从最后的数据包过滤扩大到了网络、内核、平安、跟踪等，而且它的性能个性还在疾速倒退中，晚期的 BPF 被称为经典 BPF，简称 cBPF，正是这种性能扩大，使得当初的 BPF 被称为扩大 BPF，简称 eBPF。 eBPF 的利用场景是什么？网络优化eBPF 兼具高性能和高可扩大个性，使得其成为网络计划中网络包解决的优选计划： 高性能JIT 编译器提供近乎内核本地代码的执行效率。 高可扩大在内核的上下文里，能够疾速地减少协定解析和路由策略。 故障诊断eBPF 通过 kprobe，tracepoints 跟踪机制兼具内核和用户的跟踪能力，这种端到端的跟踪能力能够疾速进行故障诊断，与此同时 eBPF 反对以更加高效的形式透出 profiling 的统计数据，而不须要像传统零碎须要将大量的采样数据透出，使得继续地实时 profiling 成为可能。 安全控制eBPF 能够看到所有零碎调用，所有网络数据包和 socket 网络操作，一体化联合过程上下文跟踪，网络操作级别过滤，零碎调用过滤，能够更好地提供安全控制。 性能监控相比于传统的系统监控组件比方 sar，只能提供动态的 counters 和 gauges，eBPF 反对可编程地动静收集和边缘计算聚合自定义的指标和事件，极大地晋升了性能监控的效率和设想空间。 eBPF 为什么会呈现？eBPF 的呈现实质上是为了解决内核迭代速度慢和零碎需要疾速变动的矛盾，在 eBPF 畛域罕用的一个例子是 eBPF 绝对于 Linux Kernel 相似于 Javascript 绝对于 HTML，突出的是可编程性。一般来说可编程性的反对通常会带来一些新的问题，比方内核模块其实也是为了解决这个问题，然而他没有提供很好的边界，导致内核模块会影响内核自身的稳定性，在不同的内核版本须要做适配等。eBPF 采纳以下策略，使得其成为一种平安高效地内核可编程技术： ...

作者： 渐意 在上篇文章《解密函数计算异步工作能力之「工作的状态及生命周期治理」》中，咱们介绍了工作零碎的状态治理，并介绍了用户应如何依据需要，对工作状态信息进行实时的查问等操作。在本篇中咱们将会进一步走进函数计算异步工作，介绍异步工作的调度计划以及零碎在可观测性方面所反对的各项性能。 任务调度任务调度多指零碎依据以后负载状况，将不同工作放到适合的计算资源中去执行的相干操作。一个欠缺的调度零碎往往须要均衡不同特点的工作间的隔离以及效率最优这两个需要。函数计算异步工作采纳了独立队列模型及主动负载平衡策略，具备在不影响解决性能的前提下进行多租隔离的能力。 Serverless Task 任务调度模型当用户提交一次工作后，零碎会将该工作转换为一条音讯，并通过异步下发的形式放入到外部队列中。一条音讯的解决流程如下图所示： 图 1 整个零碎在任务调度方面的多租隔离及音讯积压管制方面次要依赖的是 Scheduler 对于队列的生产及管制。咱们当时会为每一位用户划分一个账号级别的队列，该用户的所有函数的异步调用（包含工作调用）会共享该队列。 这样的模型构造会保障每个用户的异步执行申请（包含工作调用）均不会受到其余用户的调用状况的影响。然而在一些大规模利用场景，如一个用户的函数很多，并且每个函数的调用量都很大的状况下，所有的异步音讯共用一个队列不免造成调用间的相互影响。局部长尾调用可能会过多的耗费队列的资源，导致其余函数的执行呈现饥饿的景象。 为了防止这种状况影响重要函数的执行，函数计算提供了更细力度的队列 - 函数级别的队列。能够通过对每个不同函数设置独自的队列，确保高优先级函数的生产状况不会受同账号下的其余函数执行的影响。队列间的关系如下图所示： 图 2 典型的利用场景假如某用户 A 具备 2 个不同的工作函数。其中一个工作 A 因为上游服务的限度，须要一个音讯一个音讯的执行；而另外一个工作 B 是大并发工作，并且心愿尽快执行完。在默认模式下，工作 A 和 B 共享同一个用户队列；这时会呈现如下场景：工作 A 因为具备并发度限度，函数计算侧会对整个工作队列进行出队速率管制。这就导致了工作 B 的工作迟迟无奈出队。而当工作 A 执行完后，工作 B 失去了出队机会，此时并发度升高，工作 B 的音讯抢占了资源池进行执行，工作 A 又变得难以出队，很长时间也无奈开始一次执行。这样的后果就是无论 A 还是 B 都受到了对方业务的重大烦扰。 当进行队列调整后，工作 A 和 B 别离独占队列。在这种状况下工作 A 和 B 的生产速度不受对方影响，都能够达到本身的诉求。 目前 Serverless Task 提供了工作积压大盘，您能够在工作界面获取目前曾经积压的工作数，综合剖析是否须要开启函数的独占队列。 Serverless Task 工作队列负载平衡模型下面介绍了如何通过函数级别队列来避免出现 “Noisy Neighbour” 问题。然而在一些场景下，如果工作的并发量级过大，即使对该工作划分了单队列，也会导致工作的积压。这个问题的解决须要引入 Serverless Task 的负载平衡策略。 函数计算的工作解决模块具备 Partition 的概念。每个用户默认属于一个 Partition，负责该 Partition 的 Scheduler 会监听用户对应的工作队列。当呈现重大积压时，咱们会为用户依照负载状况调配多个 Partition，并交由不同的 Scheduler 负责生产，来晋升工作整体的生产速度。 ...

作者：十眠 咱们的生产环境常常会呈现一些不稳固的状况，如： 大促时霎时洪峰流量导致系统超出最大负载，load 飙高，零碎解体导致用户无奈下单“黑马”热点商品击穿缓存，DB 被打垮，挤占失常流量调用端被不稳固服务拖垮，线程池被占满，导致整个调用链路卡死 这些不稳固的场景可能会导致严重后果。大家可能想问：如何做到平均平滑的用户拜访？如何预防流量过大或服务不稳固带来的影响？ 介绍上面两种形式是在面对流量不稳固因素时常见的两种计划，也是咱们在设计高可用的零碎前不得不思考的两种能力，是服务流量治理中十分要害的一环。 流量管制流量是十分随机性的、不可预测的。前一秒可能还惊涛骇浪，后一秒可能就呈现流量洪峰了（例如双十一零点的场景）。每个零碎、服务都有其能承载的容量下限，如果忽然而来的流量超过了零碎的承受能力，就可能会导致申请解决不过去，沉积的申请解决迟缓，CPU/Load 飙高，最初导致系统解体。因而，咱们须要针对这种突发的流量来进行限度，在尽可能解决申请的同时来保障服务不被打垮，这就是流量管制。 熔断降级一个服务经常会调用别的模块，可能是另外的一个近程服务、数据库，或者第三方 API 等。例如，领取的时候，可能须要近程调用银联提供的 API；查问某个商品的价格，可能须要进行数据库查问。然而，这个被依赖服务的稳定性是不能保障的。如果依赖的服务呈现了不稳固的状况，申请的响应工夫变长，那么调用服务的办法的响应工夫也会变长，线程会产生沉积，最终可能耗尽业务本身的线程池，服务自身也变得不可用。 古代微服务架构都是分布式的，由十分多的服务组成。不同服务之间互相调用，组成简单的调用链路。以上的问题在链路调用中会产生放大的成果。简单链路上的某一环不稳固，就可能会层层级联，最终导致整个链路都不可用。因而咱们须要对不稳固的弱依赖服务进行熔断降级，临时切断不稳固调用，防止部分不稳固因素导致整体的雪崩。 Q：不少同学在问了，那么是不是服务的量级很小就不必进行流量管制限流防护了呢？是不是微服务的架构比较简单就不必引入熔断爱护机制了呢？ A：其实，这与申请的量级、架构的复杂程度无关。很多时候，可能正是一个十分边缘的服务呈现故障而导致整体业务受影响，造成巨大损失。咱们须要具备面向失败设计的意识，在平时就做好容量布局和强弱依赖的梳理，正当地配置流控降级规定，做好事先防护，而不是在线上呈现问题当前再进行补救。 在流量管制、降级与容错场景下，咱们有多种形式来形容咱们的治理计划，上面我将介绍一套凋谢、通用的、面向分布式服务架构、笼罩全链路异构化生态的服务治理规范 OpenSergo，咱们看看 OpenSergo 是如何定义流控降级与容错的规范，以及撑持这些规范的实现有哪些，能帮忙咱们解决哪些问题？ OpenSergo 流控降级与容错 v1alpha1 规范在 OpenSergo 中，咱们联合 Sentinel 等框架的场景实际对流控降级与容错场景的实现形象出规范的 CRD。咱们能够认为一个容错治理规定 (FaultToleranceRule) 由以下三局部组成： Target: 针对什么样的申请Strategy: 容错或控制策略，如流控、熔断、并发管制、自适应过载爱护、离群实例摘除等FallbackAction: 触发后的 fallback 行为，如返回某个谬误或状态码 那咱们看看针对罕用的流控降级场景，OpenSergo 具体的规范定义是什么样的，他是如何解决咱们的问题的？ 首先提到的，只有微服务框架适配了 OpenSergo，即可通过对立 CRD 的形式来进行流控降级等治理。无论是 Java 还是 Go 还是 Mesh 服务，无论是 HTTP 申请还是 RPC 调用，还是数据库 SQL 拜访，咱们都能够用这对立的容错治理规定 CRD 来给微服务架构中的每一环配置容错治理，来保障咱们服务链路的稳定性。让咱们来具体看看OpenSergo在各个具体场景下的一个配置。 流量管制以下示例定义了一个集群流控的策略，集群总体维度每秒不超过 180 个申请。示例 CR YAML: apiVersion: fault-tolerance.opensergo.io/v1alpha1kind: RateLimitStrategymetadata: name: rate-limit-foospec: metricType: RequestAmount limitMode: Global threshold: 180 statDuration: "1s"这样一个简略的 CR 就能给咱们的系统配置上一个流量管制的能力，流控能力相当于利用的一个安全气囊，超出零碎服务能力以外的申请将被回绝，具体逻辑可由咱们自定义（如返回指定内容或跳转页面）。 ...

作者： 鲍江南 引言在 2021 年四月左右，我有幸在 sealer 启动初期理解到其相干工作，并且不久后就作为初始的几位开发同学之一，退出到了 sealer 的开发工作中。 本文，我将回顾集体参加 sealer 开源我的项目的机缘巧合，参加过程中的挑战，以及从中获取的所悟所感，写下一段文字进行分享，心愿对开源新人有所帮忙，可能激励想参加开源工作但还未踏出第一步的同学。 个人简介 各位读者好，本文是我公布到阿里云的第一篇文章，所以我先简略进行下自我介绍。 我是鲍江南，是 sealer [ 1] 的 maintainer。本科毕业于中南大学图灵班。现就读于浙江大学，是 SEL 实验室的一名硕士研究生。目前次要钻研方向是混部集群调度。 GitHub: https://github.com/justadogis... 旅途的开始刚开始研究生生存的我，他人看来可能是踌躇满志、蓄势待发，但过后的我有种莫名的焦虑与迷茫。读研时，我的实验室是浙江大学的 SEL 试验，次要的钻研畛域是云计算，因而在云计算工业界，咱们有泛滥的师兄师姐们。过后我来到了一家高新科技云计算公司“谐云科技”负责云原生研发实习生，谐云科技与阿里云有泛滥前沿云原生合作项目，外围团队成员来自于浙大 SEL 实验室。在机缘巧合之下，我进入了谐云&阿里云云原生项目组，意识了在阿里云云原生团队的实验室师兄-孙宏亮，又通过他，意识了 sealer 的发起人-方海涛。他们都有很丰盛的开源经验。在闲聊时，得悉宏亮师兄已经是 Docker 的 maintainer 时，我视宏亮师兄为标杆，作为我致力的方向，这应该是少数人确立指标的办法吧。其中有一段对话令我印象粗浅，师兄问过我“往年（2021）最想做到的事是什么？”，我的答复是“在开源方面留下一些痕迹（其实在过后，我本人并未想分明做开源是为什么）“。当初想来，可能就是”焦虑“+”集体布局不清晰”产生的“病急乱投医”的简略想法。但不论如何，过后也给本人定下了初步的指标，我就抱着 “Make it happen” 的态度全心地投入了。 大略在 2021 年 4 月的时候，我退出了 sealer 开源团队，与几位同学着力于开发 sealer（当初叫集群镜像）的外围能力。 责任与挑战sealer 是一款由阿里云开源的云原生工具，旨在帮忙分布式软件进行更好的封装、散发与运行。现在，因为其设计理念的新鲜，行业用户基数的增长，sealer 曾经捐给 CNCF 基金会，成为一个 CNCF的 sandbox 我的项目，朝着更广大的行业标准迈进。 软件诞生之初，往往是混沌随同着心愿。大指标的背地，须要 sealer 团队解决太多的技术问题，如用户接口、镜像格局、散发模式、运行效率，软件架构等等。最后的 sealer 开发分工中，我次要负责的局部是镜像模块，蕴含集群镜像缓存、集群依赖容器镜像缓存、集群镜像共享等能力。 集群镜像缓存：如何通过集群镜像层的复用，大幅提供镜像构建效率。如 docker build，每次 build 会首先查找之前本地缓存的镜像 build 内容，复用 build cache，缩小硬盘占用与晋升镜像构建效率。 集群依赖容器镜像缓存：如何将集群依赖的所有容器镜像，在用户无感知的状况下进行缓存。晚期， sealer build 构建集群镜像时，须要实在拉起集群，待所有负载失常启动后，再打包集群镜像。其中，很重要的一个局部是缓存所有该集群依赖的容器镜像，使其可打包。 ...

作者：曾庆国 孙健波 背景随着各大云厂商产品幅员的扩充，根底计算设施，中间件服务，大数据/AI 服务，利用运维治理服务等都能够间接被企业和开发者拿来即用。咱们留神到也有不少企业基于不同云厂商的服务作为根底来建设本人的企业基础设施中台。为了更高效，对立的治理云服务，IaC 思维近年来流行，其中 Terrafrom 更是胜利失去了简直所有的云厂商的驳回和反对。以 Terrafrom 模型为外围的云服务 IaC 生态曾经造成。然而在 Kubernetes 大行其道的明天，IaC 被冠以更宽广的设想空间，Terraform IaC 能力和生态成绩如果融入 Kubernetes 世界，咱们认为这是一种强强联合。 理由一：构建对立的企业混合云 PaaS 平台目前大多数企业基于 Kubernetes 服务来构建 PaaS 平台或基础设施治理平台，对立集成云上和自建基础设施。但除了提供基础设施以外，各种中间件，大数据服务，AI 服务，利用可观测等也是云厂商重点提供的产品。企业平台须要具备创立和销毁更多云服务的能力，这时 Terraform 会进入平台构建者的眼帘，那么他们还须要在 Kubernetes 之外再做一次对接开发吗？而且同时还须要思考继续公布，GitOps，灰度公布等需要。显然如果间接 基于 Kubernetes 即可实现对接是更好的选项。 理由二：为开发者打造 Serverless 体验云计算的实质或指标就是 Serverless 化，然而自建的基础设施总是无限的，无缝接入云服务能够开启 “近乎有限”的资源池。同时开发者在架构业务利用时，除了在 Serverless 平台上间接实现业务服务部署以外，还须要间接取得例如消息中间件，数据库等服务。更多的企业会采纳对接云厂商的计划，运维治理老本更低。但对于开发者，这最好是通明的，统一的。 理由三：更彻底的 IaC 能力所有皆服务，咱们须要通过对立的模型来形容云资源、自建基础设施和各种企业应用。Terraform 和 Kubernetes 能够整合并对立为面向开发者的 IaC 标准。带来的益处是同时纳管云资源和容器生态丰盛的运维能力，以及面向简单利用的对立编排。 理由四：Terraform 开源版本是客户端模式工作，无奈像 Kubernetes 一样进行终态维持。Terraform 开源发行版只能以客户端模式工作，即用户进行完一次交付后无奈维持服务状态，且如果遇到网络故障交付失败时须要手动进行重试解决。Kubernetes 为开发者带来了面向终态的 IaC 思维，通过控制器模式实现对指标资源的状态维持，这进一步晋升了 Terraform 工具在自动化层面的劣势。 KubeVela 是一个古代的软件交付管制立体， 面向开发者提供对立的 API 形象，使开发者应用雷同的 IaC 形式来同时交付一般利用和云服务。KubeVela 向下间接反对 Terraform 的 API 和 Kubernetes API，无需批改可复用所有 Terraform 模块和所有 Kubernetes 对象。通过 KubeVela 你能够非常简单的实现上诉三方面诉求。咱们也看到了另外一种模式的 Crossplane 我的项目，通过定义 Kubernetes 原生 CRD 的模式在对接云服务，使其体验更加原生，KubeVela 也人造反对 Crossplane API。 ...

作者：严达 背景注册配置千千万，唯有推送轨迹最解愁。 微服务体系下，注册核心的调用和配置变更是粗茶淡饭，例如阿里每天就有百万级变更、亿级推送。可是，一旦呈现调用或配置异样，问题排查就成了用户最大的困惑：是注册和配置核心导致的，还是上下游业务本身的问题呢？ 微服务体系下用户排查问题时的困惑 因而，长时间以来，用户对注册和配置核心推送性能的可观测性，有了越来越强烈的需要。 业内现有的开源计划以后，业内其余支流的开源注册或配置核心，例如 Zookeeper、Eureka、Consul、Apollo 在外围性能推送状况上，仅提供了一些散落的日志，并没有查问推送胜利与否的能力。一旦呈现调用或配置异样，只能通过手动登录到注册和配置核心的节点上，以较为原始的日志形式来查寻推送相干的信息。如果用户对注册和配置核心的源码及日志内容的具体情况不理解，则会使问题排查的难度大大增加。 基于上述背景，Nacos 在业内首次推出注册和配置核心的推送轨迹性能。 推送轨迹性能介绍推送轨迹，是指 Nacos 服务或配置从 server 端到 client 端的一次推送链路上的相干信息展现。推送轨迹能够让用户十分不便的查问到： 注册核心服务推送的信息配置核心的配置变更公布和推送的信息从而十分清晰地观测到 Nacos 推送性能的履约状况，极大的进步问题的排查效率。 注册核心推送轨迹注册核心的推送轨迹，能够用来排查服务推送的相干问题，例如： 客户端未收到服务推送服务间调用出现异常注册核心是否失常将服务推送到客户端 MSE - Nacos 注册核心推送轨迹查问页面 MSE - Nacos 注册核心推送轨迹，具体展现了注册核心服务推送的记录信息。其中，推送工夫字段是本次推送事件产生的工夫，推送客户端 IP 字段是本次推送所送达的客户端 IP 地址，推送服务名称是本次推送的服务名称，推送服务分组是本次推送服务的所属分组名称，服务实例数量是只本次推送服务中所蕴含的实例 IP 数量，节点名称是产生本次推送的 Naocs 节点名称。 同时，MSE - Nacos  注册核心推送轨迹也反对服务与 IP 多维度的查问。 配置核心推送轨迹配置核心的推送轨迹，能够用来排查配置核心配置变更和公布的相干问题，例如： 配置公布异样配置批改完发现某台机器不失效须要查看配置核心变更及推送事件配置维度查问能够查问和该配置相干的变更事件以及对客户单端 IP 的推送记录。 MSE - Nacos 配置核心推送轨迹配置维度查问页面 MSE - Nacos 配置核心推送轨迹具体展现了配置核心配置变更的记录信息。在推送轨迹页面左侧，展现以后时间段内的配置变更事件 ，点击左侧变更流水能够定位到右侧的变更及推送事件记录。页面右侧，展现以后时间段内的配置变更及推送事件，变更事件中显示本次变更内容的 MD5 值，推送事件中展示推送产生事件，推送到的客户端 IP。鼠标上移推送详情图标能够查看本地推送中，客户端获取到的配置内容 MD5。 IP 维度查问能够依据 IP 查问所有和该 IP 地址相干的推送轨迹 。 ...

作者：陈海波（漂石） 午夜时候，电话响起，线上告急。你从千呼万钉中醒来，睡眼朦胧，慌手慌脚。 恍惚之间，终于梳理分明产生了什么，一个陈年老利用忽然停机，音讯沉积，零碎停摆。而你就像一个下水道小工畅通马桶个别，鼎力出奇观，重启机器，复原服务。只见音讯队列中的沉积事件一落千丈，正告打消。 次日，你再也不想重现午夜凶铃，决定对系统进行永久性修复：加一个定时重启服务的脚本。 斗转星移，许多时日过来了，你也在不同的角落加了有数的脚本，也良久没有中午惊醒，甚至还能悠闲享受下午茶。然而，直到明天。 明天，你们部门要降本增效，为了防止本人成为被砍掉的老本，你决定被动对线上的机器开刀：合并服务，裁撤机器。尽管你对机器上都部署了什么利用了然于胸，然而你曾经不记得都有哪些脚手架撑持着利用的运行。 重建环境难如登天，你又开始难眠了。 变动的基础设施简单、神秘而神奇的线上环境承载了半部都市传说，甚至有些公司的线上环境自身就是一本须要口耳相传的上古神话。 我尽管没有看过沙漠下暴雨，然而看过没人说的分明下面有什么的环境。我尽管没有看过大海亲吻鲨鱼，然而我看过重启再也起不来的机器。 如果你能说分明任何一台机器上都部署了什么利用，以及机器上服务之间的依赖关系是什么样子的，你曾经击败了八成的玩家。而造成这种场面的根本原因就是基础设施的易变。 新增一个服务时：“我找台机器部署一下”某一个服务出问题时：“我上机器改一下”须要对某个系统配置变更时：“我搞个脚本跑一跑”看似惯例运维变更，有文档记录或者没有文档记录，每一个环境都是如此的别致和举世无双，再加上人员变动，造就了有数的“祖传秘技”。 什么是不可变的基础设施容器在被宽泛承受的同时，「不可变」也逐步被耳濡目染的承受。 利用容器沦亡之后，容器内的批改会随着容器一起不复存在，不要在容器内做批改就是最奢侈的不可变理念。在程序启动阶段遇到问题，很少人还会把在容器内修修补补作为正经计划，而会回到最一开始的阶段，从容器构建阶段解决问题。 随之带来的就是大家对容器镜像无尽的信任感，容器忽然呈现问题？重建试试。换个机器跑不起来？必定是机器的问题。 容器带来了什么大家广泛认同 Docker 或者说容器引发了一场反动。然而为何说容器是一场反动，到底革了什么的命？ 有一种说法是 Docker 简化了服务的治理，停启服务更加简略，然而事实上 systemd 或者 supervisor 等老牌服务治理、运维工具在这一点上不见得比 docker 难用多少。 我认为是镜像技术引爆了反动，一个不可长期批改的、固化的、自蕴含的交付物，真正的一次构建到处运行，一个能够疾速铲掉和疾速部署的实体，再也没有 「Works on my machine」，是如此的安心和可依赖。 也正是因为容器的重建是如此的快捷，使得咱们有机会对「重启试试」施展到极致，出问题了，重建容器看看？ 你想尝试应用 Docker，然而你的业务如此简单，上机器重建容器和间接上机器重启服务又有什么实质差异呢。 Pet vs Cattle随之 Kubernetes 的到来，大规模的容器治理成为可能，而划定大规模容器的治理最佳实际也成为了热门议题。 如何豢养一只猫如果你失去了一只猫，你会如何豢养它？我记得我在领回一只猫之后，花了很长的工夫和脑细胞用来约定一个我和它都能承受的名字。 紧接着就是带着我的小猫去医院，制订疫苗打算，来保障我的小猫将来的衰弱。前面便是日复一日的铲屎和等着奴才的眷顾。 小王子通知我：正因为你为你的猫破费了工夫，这才使你的猫如此重要。 经典的运维形式和猫的豢养是一样的，咱们能够称之为宠物式运维。你会对机器和利用做详尽的布局，甚至为这个环境起一个名字，比方叫生产好了。 你也会对这个环境悉心照料，定期看看监控、做下降级颐养。你为你的环境破费了工夫，你的环境如此重要。 很难构想你的猫和你的环境忽然间离你而去的场景，兴许你会伤心的撕心裂肺和破产的撕心裂肺。 农场主入门在取得了一只猫之后，你一不留神又取得了一家牧场。但你可能无奈像养一只猫一样养几千头牛，因为几千个名字应该是很难记住的。 你可能也不会顺次带着你的牛去医院打疫苗，何不间接零售疫苗对立接种呢。如果有小牛犊存在重大的缺点，兴许你会陪在它身边悉心照料，但更可能的是把它尽早的从流程中剔除，省的节约更多的饲料。 从此你的生存便目无全牛，只有为牛群建设足够多的保障设施，某一头牛的状态对整体又有什么影响呢。 放牧式运维当你曾经为上千头牛建设了欠缺的豢养设施，你会惊奇的发现，即便再加 100 头牛，并不会减少太多的老本。而不像豢养猫，当你有两只猫的时候，最好能有 3 个猫砂盆，否则你将有机会体验到鸡飞狗跳。 你信心当一个牧牛人运维，再也不想给生产环境的奴才们铲屎了。拥抱 Kubernetes，像放牧一样治理你的利用。 牧养一群 Pod你把生产环境的奴才们装进集装箱，通过容器镜像对部署形式进行标准化，谁也甭想做非标的操作，再应用 Pod 对利用进行部署，再也不去关怀利用在哪个 Node 上启动，这所有自有牧场（Kubernetes）自行处理。 一个 Pod 异样了？没关系，删掉看看，下次起来又是一个全新的利用。丝毫不会影响到牧场的失常运行。 所有丝般顺滑，岁月静好。 午夜时候，电话响起，线上告急。你从千呼万钉中醒来，睡眼朦胧，慌手慌脚。 ...

作者： 葛天萌（智云） 业界盛传的全链路压测是什么全链路压测诞生于阿里巴巴双 11 备战过程，如果说双 11 大促是阿里业务的“期末考试”，全链路压测就是大考前的“模拟考试”，诞生后被誉为双 11 稳定性保障的“核武器”。全链路压测通过在生产环境对业务大流量场景进行高仿真模仿，获取最实在的线上理论承载能力、执行精准的容量布局，确保零碎可用性。 分布式架构和业务疾速倒退给业务零碎带来了不确定性。分布式环境的任意节点都可能成为瓶颈/短板/问题，同时零碎可用性随着业务的快速增长，面临更严厉的挑战和不确定性。比方： 单链路压测短少内部烦扰和各种资源竞争，单链路压测的后果广泛比拟乐观，不能反映实在的零碎承载能力。某些问题只有在真正的大流量下才会裸露，比方网络带宽、零碎间影响、根底依赖等等。全链路压测不仅仅是做压测，更多的是进行一次实在的大促预演，预案演练、限流验证、破坏性演练等高可用计划的对立验收。其中全链路压测的常见问题就是如何做到生产环境的数据隔离：在生产环境进行写压测时，须要保障在压测进行的同时不影响线上业务的失常运行，那么就须要思考将压测产生的数据与生产的实在数据隔离存储，防止脏数据对线上业务产生影响。阿里云的全链路压测平台除了提供了影子表计划之外，还提供了影子库的数据隔离计划。 在生产环境施行全链路压测的过程中，针对上文谈到的两种计划，又面临着数据隔离计划的抉择问题，本文首先针对影子库、影子表两种计划进行介绍和比照，而后针对常见的场景，给出计划的抉择倡议。 全链路压测数据隔离计划的抉择目前全链路压测平台提供了影子库、影子表等解决方案。应该如何抉择适宜本人的计划呢？本文首先针对两种计划的原理进行论述，而后从性能、稳定性、老本三个考量指标进行比照。 计划一：影子库如图 1 所示，针对影子库计划，是在同一个实例上建设对应的影子库。用户服务挂载的全链路压测探针获取到流量标之后进行相应的旁路解决，如果是影子流量，那么会从影子连接池中获取影子连贯供业务侧应用，从而将压测流量产生的数据旁路到对应的影子库中，以此达到数据和生产库隔离的成果，从而防止了压测流量产生的数据对生产库造成净化。 图 1：影子库计划基本原理 计划二：影子表如图 2 所示，相似影子库计划，针对影子表计划，是在同一个实例上的同一个数据库上建设对应的影子表。用户服务挂载的全链路压测探针获取到流量标之后进行相应的旁路解决，如果是影子流量，那么，探针会针对本次的 DB 调用进行 SQL 解析和替换，从而将压测流量产生的数据旁路到对应的影子表中。 图 2：影子表计划基本原理 计划比照本文次要从性能、稳定性、老本三个方面来论述两种计划的优缺点。 图 3：计划比照 性能机器规格：4c8g 并发规格：需同时模仿失常和压测流量两种类型的流量，这里以 2:8 的比例进行划分，以便于模仿业务流量低峰期进行生产环境全链路压测。 失常流量：200 并发压测流量：800 并发这里次要从服务所在的主机和所用的数据库实例两方面的监控去剖析。其中，利用监控次要以 CPU、内存和均匀 RT 三个指标剖析。数据库实例监控从连接数、QPS 两个指标的维度进行剖析。 从以上两种计划不同维度的指标比照能够看出，影子表计划对 CPU 的耗费略高，这和该计划的实现形式无关。 稳定性谈到稳定性，能够从数据源实例的连接数规格、容量规格、IOPS、网络流量等方面进行剖析。 以上指标，这里以连接数为例进行阐明，具体如下： 针对影子库计划。因为是在同一个实例上建设不同的数据库，所以如果不思考数据库实例可能达到最大连接数下限，实践上影子连贯和失常连贯时互相独立的，执行时互不影响。 针对影子表计划，因为是在同一个实例上的同一个数据库上建设了不同的数据表，那么这里就要思考业务侧的连接池配置了，因为影子流量波及到的 DB 操作和失常流量波及到的 DB 操作，所用的数据库连贯，均来源于同一个连接池，所以如果压测量级较大的时候，是比拟容易呈现连接池连贯瓶颈的。 老本 依据表格中的内容，这里次要以冗余老本和数据迁徙老本进行阐明，具体如下： 冗余老本针对影子库计划，为了保障全链路压测评估后果的精准度，咱们须要在同一个实例上做全量的库迁徙操作，包含表构造和表数据，这会带来一个比拟显著的问题，老本比拟高，所有的根底只读表（此类型的表不会有写操作）均要冗余一份，无奈达到复用的目标，所以对于中大型企业来说，是难以承受的。 针对影子表计划，是在同一个实例上的同一个数据库上建设影子表。那么就能够复用生产库中的根底只读表，只需对写表进行建设影子表即可。影子表计划在肯定水平上升高了数据冗余所带来的老本耗费。 数据迁徙老本从压测的主流程来说，分为压测前、压测中、压测后。其中，数据筹备是处于压测前这一阶段的，压测胜利与否，和数据筹备这一环节密切相关。数据迁徙的过程须要将某张数据表所关联的其余表字段同时做迁徙，这一过程是比较复杂和消耗精力的。所以，具体抉择哪种计划，须要联合业务数据的复杂程度来评估。 总结综上，具体抉择以上两种计划中的哪一种，其实仅靠一个指标判断是不够的，要联合以上多个指标以及具体的业务场景来进行综合评估的。上面针对两种典型的场景来阐明应该如何抉择适宜本人计划，以下意见仅供参考。 场景 1：在波及到的读表比例高于写表、并且整库迁徙老本较高的状况下，举荐抉择影子表计划，在肯定水平上能够缩小简单的数据迁徙带来的老本。 场景 2：在波及到的写表比例高于读表，同时生产库实例容量较为短缺的状况下，举荐抉择影子库计划，在肯定水平上升高了梳理、配置的老本。 目前，全链路压测提供混合云解决方案输入，欢送大家应用。具体详情请点击此处查看。 更多交换，欢送进钉钉群沟通，PTS 用户交换钉钉群号：11774967。 ...

随着企业 IT 数字化转型演变过程，越来越多的企业采纳云原生化架构降级的形式，改善利用开发运维迭代的效率，减速企业业务翻新迭代，改良资源弹性治理和迁徙的效率，帮忙企业降本增效。然而因为云原生弹性、麻利和动静可扩大等个性，也为云原生软件供应链平安引入了新的挑战。 Salesforce 是创立于 1999 年 3 月的一家客户关系治理 (CRM) 软件服务提供商，可提供随需利用的客户关系治理平台。Salesforce 容许客户与独立软件供应商定制并整合其产品，同时建设他们各自所需的应用软件。在社交电商潮流席卷寰球的态势下，2022 年 1 月，Salesforcs 与阿里云联结公布了针对中国市场的软件“Salesforce 社交电商”，这是 Salesforce 与阿里云达成策略单干后在中国市场首发新品。该软件由阿里云托管的 Headless 电商中台产品，能治理和对立企业在 Web 网站、挪动 App 及小程序等多种渠道的电商利用，以取得客户的 360 度视图，从而进步客户体验和促成业务增长。 容器化 ISV 交付的平安挑战在进行容器化交付革新的过程中，以 Salesforce 为例的容器软件 ISV，须要解决云原生场景下环境复杂化、多样化等来的软件供应链危险挑战。为了保障软件从开发、交付到运行的顺利进行，整个软件供应链生存周期应在保障软件可用性、完整性、保密性根底上，升高软件供应链的平安危险，实现全链路可审计，可追溯，可自动化平安经营。为了实现这样的要求 ，在容器化交付革新过程中次要面临以下挑战： 三方及开源组件带来安全隐患：企业软件我的项目越来越趋于依附来自供应商三方或开源社区组件，该些组件常以根底镜像的形式在软件供应链里传递。攻击者可能利用组件中存在的破绽，注入恶意代码或管制第三方机器环境，执行从加密货币挖矿、发送垃圾邮件、到通过大型僵尸网络发动 DDoS 攻打。软件交付长链路埋下更多危险：从软件开发阶段的需要剖析、代码开发、集成、测试，到 ISV 交付阶段的特定渠道软件交付、终端客户验收，最初运行阶段的终端客户软件运行、经营和保护。整个软件供应链周期链路长，在各个环节中均可能存在平安危险，导致软件破绽、软件后门、歹意篡改、知识产权危险、信息泄露等平安威逼。容器化运行引入更多危险攻击面：容器利用部署依赖 Linux 内核个性，很多黑客攻击者利用内核系统漏洞，从容器运行时组件和容器利用部署配置等多个维度发动针对性的逃逸或者入侵攻打。最近几年 K8s、Docker、Istio 等开源社区都爆出了不少的高危破绽，这都给攻击者提供了可乘之机。整个软件供应链生存周期应在保障软件可用性、完整性、保密性根底上，升高软件供应链的平安危险，实现全链路可审计，可追溯，可自动化平安经营。保障从软件开发、交付到运行，整个软件供应链有纵深进攻的平安能力，一旦任何环节呈现问题，可能及时精确实现问题定位和追溯，辨认相干方危险并及时平安加固。 阿里云云原生软件供应链解决方案为了帮忙客户更便捷实际软件供应链平安，阿里云容器服务团队提供了端到端的解决方案。企业客户能够在跨企业交付或者企业内研发迭代场景，晋升平安治理效率及平安加固能力，实现全链路容器利用平安可信交付。 （容器化 ISV 交付场景） 在容器利用交付阶段，容器镜像服务 ACR  企业版提供了云原生利用交付链能力，交融访问控制、镜像构建、内容平安、二进制认证、全球化散发等能力，反对预置危险拦挡策略，实现发现即阻止、安全控制左移。 镜像内容平安，ACR 和云平安核心联结提供了增强型容器镜像扫描引擎，笼罩系统漏洞、利用破绽、基线查看及歹意样本等危险类型，具备高识别率、低误报率破绽扫描能力。同时，提供了容器镜像修复能力，反对自动化高效修复危险破绽，实现从发现到修复的平安闭环。镜像跨账号交付，针对企业间 ISV 利用交付场景，ACR 提供了跨账号同步能力保障容器镜像和签名的散发平安。ISV 将镜像及对应的签名信息通过 ACR 跨账号同步能力交付给 ISV 的客户实例下。对应的镜像开启了不可变镜像版本，确保镜像的版本不可笼罩。ISV 的客户在 ACK 上做镜像部署时，会基于 ISV 的公钥验签，确保镜像残缺且来自 ISV。在容器利用运行阶段，容器服务 ACK 在默认管控组件、零碎组件平安加固之上，提供了部署策略管理、平安巡检，保障容器利用一致性的安全策略。ACK 集成云平安核心提供了容器运行时安全监控和告警能力，笼罩 ATT&CK 杀伤链的 200 余项平安检测模型，晋升整体业务负载运行环境安全性。基于 ISV 利用运行场景，ACK 也提供了平安沙箱容器作为运行时解决方案，确保更好的平安隔离能力和更高的稳定性。 ...

作者：知明 如何讲清楚一件事我置信很多人都很困惑也很无助，尤其是在降职场合，在向上汇报或者是做大范畴分享的时候，巴不得找个地缝钻进去。很多时候咱们经常是这样刺激本人，我是实干派技术人，不须要那些花里胡哨的货色，我技术过硬比什么都重要。已经一度我也是这样认为，最初扭转我这个想法的是一句话：如果你讲不分明多半是想不分明，如果你都想不分明如何可能率领更多人拿到后果？ 所以我总结了一些对于如何讲清楚的一些技巧，以供大家参考。 少做预设多换位在讲的过程中第一个陷阱就是以自我为核心，在依照本人的思路讲。呈现这个景象的实质就是做了大量的预设，假如我的受众都是和我一样的成长环境，一样的业余背景，一样的心态和目标。但事实上这些假如都是不成立的，而这也就是造成讲不分明的本源（这里请勿诡辩说是对方不业余听不懂，人只能扭转自我去想方法扭转）。 对这一点一些具体的倡议如下： 去专业化：比方是字母缩写就加一个括号把原单词写进去，比方专业名词就变为一句话的简要形容。铺垫背景：通过背景的形容是很好将所有人拉到一个水位上的方法。用比喻/故事：用生存中相似的例子去大抵表白成果会好很多，即便不是齐全对等也没关系，这是给人家以体感最好的方法。在全局中找定位举一个很简略的例子，咱们在介绍本人的时候是不是加上一个你是XX团队做什么工作的 会 比独自说一个姓名要来得更加分明。这其实就是使用了全局凸显本人的方法。咱们再很多时候讲一个概念或者一件事的时候往往就只是就着它自身去讲，这就会导致他人听得云里雾里。一旦要害的概念没有搞清楚，你后续所有的讲话内容都可能白瞎，因为听众可能基本就跟不上。 所以要讲清楚本人就要讲全局，在全局中通过本人的作用/定位等办法来更加分明论述。那至于全局全到什么份上，这个能够参考这样一个办法：全局的内容是大家都有肯定认知度的。 举个例子：比方咱们要去给整个蚂蚁的人介绍寰球资金平台，那你必须得先讲国内的次要业务是干嘛的。 上天入地要搭配这个是有一点点形象，举个降职问答的例子：面试官问一个问题，你有没有想过这个平台将来该如何倒退？遇到这类问题很多人都会上当，有以下几种状况： 1、就着平台自身的指标娓娓而谈。比方咱们平台的布局是要做 XX 能力，0 故障等巴拉巴拉一堆。这典型就是违反了全局中找定位的准则，很显然你都不回到业务下来如何可能证实你讲的将来布局是有逻辑的？ 2、先答复业务上的指标，而后再讲咱们平台布局是要做 XX 能力，0 故障等。这个显然是好多了，但依然还是十分飘。为什么呢，因为这都是概念层面的货色，概念是不能推导概念的，否则就是一堆正确的废话。 3、绝对于第二种要更进一步，即讲完第二点的内容，在联合具体的案例来承接你的 XX 能力建设，0 故障等。这就是我提到的上天入地要搭配的技巧了。 具体上天入地要搭配的技巧能够提炼为一下两个方面： 1、即形象的概念就是飘在天上的，要害要点就是入地三尺的，这就叫入地的形象观点和入地的细节撑持的搭配。 2、同样反过来也是必须要满足这个准则，当咱们面试官问到一个很细节的点，如果咱们也只是地就事论事那也不行，咱们解决了细节点这是入地三尺，前面必须得形象拔高，造成更加通用的准则和方法论，这代表可能总结演绎看到相似问题，代表具备触类旁通的能力。 以上两者就是上天入地的搭配，飘在天上的必须要抓到要害落在地底去，细到地底的必须要形象拔高飘到天上去。 多维度多层次思考后面讲的入地我置信个别都不成问题，只有从一线爬起来的入地都没啥问题。但要说到入地可能还真未必是每个人都能把握的技能，其实这背地的实质到底是什么？实质就是如何结构化体系化地思考（哈哈，可能很多人认为这是 PUA）。但如何做到也有很多方法论，我这里就讲一个最简略的办法，那就是看多个维度讲多个档次。最常见的就是很多人发言时就说我讲三个点，人家这套路是对的，是给本人做提醒我得讲得有体系化一点（当然最初是不是体系化未必，但至多这个方向是对的）。 多维度的含意就是你思考一个问题看了哪几个方面，比方下面例子外面对于平台将来倒退的问题，能够思考的维度就很多，业务能力维度，零碎稳定性维度，平台效力维度等等。这些思考的维度其实大家能够去常做总结和反思，积攒下来总有用途。 多层次的含意就是看问题是不是够深刻，最简略的方法就是多问几个 WHY，继续问上来就够找到更加深层次的问题。 能定量就不定性这个就比拟容易了解，定性会让人感觉忽悠感很强或者不那么实在，而具体的数字会让人感觉更加可信。你试着想想，和业务方对话都可能讲进去几个业务数字，是不是霎时感觉相互在一个篇上。要做到这一点除了讲之前，可能做足功夫外惟一的方法就是多去被动记住一些业务数字。有了感觉得到了红利，自然而然就会让你更有趣味去记住这些。 往期回顾 谈谈技术能力 上篇：技术架构的设计办法 下篇：技术 Leader 的思考形式

作者：易立 Knative 是在 Kubernetes 根底之上的 Serverless 计算的技术框架，能够极大简化 Kubernetes 利用的开发与运维体验。在 2022 年 3 月成为 CNCF 孵化我的项目。Knative 由两个次要局部组成：一个是反对 HTTP 在线利用的 Knative Serving，一个是反对 CloudEvents 和事件驱动利用的 Knative Eventing。 Knative 能够反对各种容器化的运行时环境，咱们明天来摸索一下利用 WebAssembly 技术作为一个新的 Serverless 运行时。 从 WASM、WASI 到 WAGIWebAssembly（简称 WASM）是一个新兴的 W3C 标准。它是一个虚构指令集体系架构（virtual ISA），其初始指标是为 C/C++等语言编写的程序，能够平安和高效地运行在浏览器中。在 2019 年 12 月，W3C 正式发表 WebAssembly 的外围标准成为Web规范, 大大推动了 WASM 技术遍及。明天，WebAssembly 曾经失去了 Google Chrome、Microsoft Edge、Apple Safari、Mozilla Firefox 等流浏览器的全面反对。而更加重要的是，WebAssembly 作为一个平安的、可移植、高效率的虚拟机沙箱，能够在任何中央、任何操作系统，任何 CPU 体系架构中平安地运行利用。 Mozilla 在 2019 年提出了 WebAssembly System Interface（WASI），它提供相似 POSIX 这样的规范 API 来标准化 WebAssembly 利用与文件系统，内存治理等系统资源的交互。WASI 的呈现大大拓展了 WASM 的利用场景，能够让其作为一个虚拟机运行各种类型的服务端利用。为了进一步推动 WebAssembly 生态倒退，Mozilla、Fastly、英特尔和红帽公司携手成立了字节码联盟（Bytecode Alliance），独特领导 WASI 规范、WebAssembly 运行时、工具等工作。后续微软，谷歌、ARM 等公司也成为其成员。 ...

作者：易立 2020 年以来，新冠疫情扭转了寰球经济的运行与人们的生存。数字化的生产与生存形式成为后疫情时代的新常态。明天，云计算曾经成为全社会的数字经济基础设施，而云原生技术正在粗浅地扭转企业上云和用云的形式。如何利用云原生技术帮忙企业实现降本增效是很多 IT 负责人关注的话题。 阿里巴巴始终是云原生畛域的的探索者和实践者。阿里团体的云原生之路有几条主线： 第一个阶段是利用架构的互联网化。2007 年起，随着互联网流量大暴发，阿里开始构建互联网规模分布式应用架构，自研微服务、音讯、分布式数据库等外围中间件。 第二个阶段是基础设施云化。阿里云 2009 年开始自研飞天云操作系统，团体业务开始逐步上云。同时，2011 年阿里团体开始摸索落地容器技术，减速利用迁云，最大化利用云的弹性，通过离在线混部优化计算成本，到了 2019 年实现了外围零碎全面上云。 在这个根底上，阿里团体开始实现全面的云原生降级。咱们保持开源技术、阿里云产品和团体利用的 三位一体。到 2021 年，实现了业务 100% 上云，利用 100% 云原生化。 云原生技术曾经为阿里带来了微小的价值红利。目前阿里团体曾经领有寰球最大的 K8s 集群，单集群过万节点，能够对立反对电商、搜寻、大数据、AI 等多样化利用。2021 年阿里双 11 大促峰值的计算成本相较去年降落了 50%。Serverless 也在大量场景落地，研发效力晋升 40%。 得益于阿里的云原生大规模实际，阿里云为企业构建了先进、普惠的云原生产品家族，同时服务阿里团体和各行业客户。2022 年 1 季度，在权威咨询机构 Forrester 公布的公共云容器平台分析师报告中，阿里云容器服务 ACK 成为比肩 Google 的寰球领导者，这也是首次有中国科技公司进入容器服务领导者象限。 企业降本增效之路上面临的难题过来几年，以容器为代表的的云原生技术疾速倒退，在最新 CNCF 开发者考察中，在 2021 三季度年寰球曾经有超过 700 万云原生开发者。应用云原生技术能够驱动企业实现降本增效是当下大多数开发者的共识。但咱们同样能够看到的是，在 2021 年 CNCF《FinOps Kubernetes Report》的调研报告中显示，68% 的受访者示意所在企业过来一年在 Kubernetes 环境的计算资源老本有所增加。这背地的起因是什么？ 通过与企业的沟通和剖析，咱们发现企业目前面临五大难题： 布局难。 当业务迁徙到容器场景后，须要对利用进行容量布局，适度分配资源会导致资源节约，资源超售适度则会导致稳定性问题。计费难。 容器利用与传统利用相比具备更高的弹性和动态性，能够按需创立和开释资源，这也对费用估算带来更大的挑战。分账难。 与传统利用部署与资源绑定的形式不同。当初多个容器利用共享一个 K8s 集群。一个计算节点上能够运行多个 Pod，而且 Pod 能够弹性伸缩，在节点间动静迁徙。应用层与资源层计量计费在空间、工夫等多个维度都无奈做到一对一对应，造成老本治理的复杂性。优化难。 云原生技术中例如：弹性、混部、Serverless、超卖等技术都有各自适宜的典型场景。如果使用不当，比方弹性配置谬误，可能带来意想不到的资源节约甚至稳定性问题。治理难。 混合云曾经成为企业 IT 架构的新常态。Kubernetes 能够帮忙企业屏蔽根底差别。而不同环境财资治理能力参差不一，不足对立凋谢的用量数据模型进行治理，使得企业难以从全局的视角进行整体的老本剖析与优化。近些年，随着企业上云的减速，云财务管理（FinOps）的概念被越来越多的企业提及与驳回，FinOps 是一种云的经营模式，它将零碎、最佳实际和文化联合在一起，以进步组织理解云老本的能力。这是一种为云收入带来财务责任的做法，使团队可能做出理智的业务决策。FinOps 加强了 IT、工程、财务、洽购和企业之间的合作。它使 IT 可能倒退成为专一于利用云技术为业务增值的服务组织。当云原生技术与 FinOps 概念交错在一起，就孕育出了云原生IT老本治理（Cloud Native FinOps）的理念，它是 FinOps 概念在云原生场景下的一种演进与进化。 ...

分布式架构和云原生重塑了中间件的游戏规则，这给国内开发者提供了从新定义中间件的历史时机。 在分布式架构风行前，国外 IT 厂商引领着中间件市场的倒退，且以闭源、重商业的服务模式为主；随着云计算和互联网的遍及，阿里将 RPC 框架、音讯队列、服务发现、配置核心、分布式事务、限流降级等外围利用中间件技术对外开源，减速了分布式架构在国内的落地，也使得开发者在 Spring 技术栈以外多了一种抉择。而云原生则实现了中间件以 BaaS 或 SaaS 的状态呈现，解决了分布式应用架构落地后，中间件在容量治理、交付、运维、容灾上的难题，使用者通过标准化的 API 就能够实现对中间件的调用，从而晋升企业整体的开发和运维效率。 本文讲述了阿里云在利用中间件畛域外围开源我的项目的过来、当初和将来，篇幅较长，故事线列举如下： Apache Dubbo：同步架构通信，从 RPC 框架到全面拥抱云原生基础设施Apache RocketMQ ：异步架构通信，从 Messaging 到 Streaming 和 EventingNacos：从架构下沉到要害组件，继续突破性能瓶颈，市场占有率曾经超过50%Sentinel：首次波及服务治理畛域，但不止于限流降级，行将公布里程碑版本2.0Spring Cloud Alibaba：对国内开发者、阿里云、Spring 三方来说，都是一个好消息Arthas：一款工具型开源我的项目，Stat 行将冲破 3wChaosBlade：业务稳固，不仅须要事中限流降级，更须要事先故障演练Seata：让分布式事务的应用像本地事务的应用一样，简略和高效AppActive：Sentinel、ChaosBlade、AppActive，高可用三家马车胜利集结OpenSergo：解决日益增长的微服务框架混用企业的服务治理难从 RPC 框架到全面拥抱云原生基础设施Apache Dubbo（以下简称 Dubbo）是阿里巴巴于 2012 年开源的分布式服务治理框架，是国内影响力最大、应用最宽泛的开源 RPC 框架之一，2017 年募捐给 Apache 基金会，2019 年正式毕业。 Dubbo 和社区开发者们 “从孵化器毕业是一种荣誉，但这并不是完结，而是另一种开始。这有点像求学，毕业并不意味着学习上的中断，而是施展更大社会价值的开始。毕业也更像是一个成人礼，意味着 Dubbo 团队曾经合乎 Apache 对一个成熟开源我的项目的要求，并开始具备独立倒退的能力。”阿里云高级技术专家北纬过后在承受媒体采访时答复道。 从 Apache 孵化器毕业，并不是完结。服务框架就像铁路的铁轨一样，是互通的根底，只有解决了服务框架的互通，才有可能实现更高层的业务互通，所以采纳雷同的规范是新一代服务框架倒退的必然趋势。2021 年，Dubbo 正式公布 3.0 版本，Dubbo3.0 是 Dubbo2.0 与 HSF 交融而来，是阿里巴巴面向外部业务、商业化、开源的唯一标准服务框架。 来自 Dubbo 官网首页 Dubbo3.0 的公布，也源自全面拥抱云原生基础设施的外围演进方向随着 K8s 成为资源调度的事实标准，Service Mesh 从提出到倒退至今曾经逐步被越来越多用户所承受。Dubbo 这类 Java 微服务治理体系面临了许多新的需要，包含冀望利用能够更快的启动、利用通信的协定穿透性能够更高、可能对多语言的反对更加敌对等。因而，Dubbo3.0 首次提出了全新的服务发现模型、下一代 RPC 协定和适配云原生基础设施等新能力。 ...

作者： 渐意 前言工作零碎中有一类很重要的概念，即工作的状态。其本质是对工作的生命周期治理。细分的状态有助于在应用时可能更分明的理解零碎产生了什么内容，便于针对性的依据业务状况进行操作。函数计算 Serverless Task 提供了多种可查问的状态，并提供了各状态间转移的工夫点。在函数的执行层面，函数计算也提供了工作的生命周期治理概念，用户能够依据需要决定当系统对工作实例进行初始化、回收等一系列动作时的执行逻辑，实现残缺的运行时生命周期治理。本文将别离对工作运行状态及运行时治理这两个方面的内容进行介绍。 工作的状态及生命周期的治理工作的状态治理 当用户提交工作并收到提交胜利的返回后，工作便曾经进入系统对其生命周期的治理流程中。一个工作的状态变更由外部的一个状态机负责管理，并对外透出状态反对实时查问。整个状态转换图如下所示： 图 1 用户触发一次工作后，工作入队，变更为 Enqueued 状态，并返回触发胜利；工作在函数计算后端服务中出队，工作变为 Dequeued 状态；后端会查看工作配置。如果配置了异步音讯有效期性能，并且该音讯出队工夫与入队工夫之差已超过有效期，则工作被抛弃，变更为 Expired 状态。工作终止；工作对应的函数已被删除，或创立实例呈现谬误，则抛弃音讯，工作变更为 Invalid 状态；查看后工作正式进入 Running 状态。此时工作已触发理论的执行；工作执行实现后，依据返回会变更为以下几个状态：Retrying：用户配置了重试次数（默认为 3），且工作执行失败，这时会进入重试中状态，之后会变更为 Running 状态；Failed：工作执行失败，且超过了重试次数。此时会将工作状态改为 Failed；Succeeded：工作执行胜利。如果在整个状态流转过程用户触发 Cancel，则工作会先变更为 Stopping 状态，并尝试进行工作执行。当工作进行执行胜利后，工作进入 Stopped 状态。工作运行时治理及生命周期当工作状态进入 Running 后，工作的理论执行便已交给函数计算的运行时。在安全性方面，函数计算会依照 VM 对不同账号进行隔离，同一个账号下的函数可能运行于同一个 VM 中。VM 内有一个负责管理容器的客户端，来理论触发函数的执行，并收集执行后果。 用户的运行实例有几个不同的状态： 图 2 函数计算对上述所有实例状态变动的过程均提供接口，反对用户侧配置相应的逻辑。 创立实现 -> 执行申请阶段：反对 Initializer 性能，反对初始化实例操作。用户能够配置诸如全局变量、连接池初始化等相干操作；执行中 -> 执行实现后 Pause 实例：反对 PreFreeze 接口，反对在函数 Pause 实例前执行用户侧的自定义逻辑；执行中 -> 内部 cancel：函数计算会强制 Restart 用户实例，在 Restart 前反对 PreStop 接口。用户能够配置优雅进行的相干逻辑，以便反对 Cancel 时的自定义行为；实现后 Pause -> 销毁实例：当一段时间没有申请后，函数计算将销毁实例。此时会调用 PreStop 接口，用户能够配置销毁容器的行为（如敞开连接池等）。 ...

作者：南异 引言在阿里团体，在离线混部技术从 2014 年开始，经验了七年的双十一测验，外部曾经大规模落地推广，每年为阿里团体节俭数十亿的资源老本，整体资源利用率达到 70% 左右，达到业界当先。这两年，咱们开始把团体内的混部技术通过产品化的形式输入给业界，通过插件化的形式无缝装置在规范原生的k8s集群上，配合混部管控和运维能力，晋升集群的资源利用率和产品的综合用户体验。 因为混部是一个简单的技术及运维体系，包含 K8s 调度、OS 隔离、可观测性等等各种技术，之前的 2 篇文章： 历经 7 年双 11 实战，阿里巴巴是如何定义云原生混部调度优先级及服务质量的？ 如何在云原生混部场景下利用资源配额高效调配集群资源？ 明天咱们要关注的是混部在单机运行时的最初一道防线——单机水位线设计。 为什么须要单机水位线 如上图所示，Pod 的运行时的三个生命周期阶段，在通过配额检查和调度后，终于，不同 Qos 等级的 Pod 运行在同一个节点上了，这个时候，高优和中优的 Pod 应用的是节点上的容器调配总量，而低优 Pod，则是基于高中优理论的资源用量，而后被调度器调度到节点下面去运行。从下图能够看到，当一个节点上还有较多的空余资源时，齐全能够提供给低优资源应用，而当高/中优 Pod 理论资源用量高过肯定的值之后，资源竞争十分强烈时，节点上再跑低优 Pod 只会导致高/中优 Pod 的服务质量受损，所以这个时候，咱们将不再容许低优 Pod 在这个节点上运行。为了标识或者说判断节点资源的竞争强烈水平，那么十分牵强附会的一个设计就是，看这个节点上的资源使用率是否过高。 如果超过肯定使用率，那么咱们就须要对低优 Pod 做相应的操作。这个判断的临界阈值，就是单机的水位线。 这里另外能看到的一点是，水位线仅仅是为低优 Pod 所设置的，高/中优 Pod 并不会感知到水位线，他们能够自在地应用整机的所有资源，所有的零碎行为都和没有关上混部是一样的。 水位线的分级对于一个资源趋向于饱和的节点来说，咱们对于低优 Pod 能够有各种操作的伎俩，如果仅仅是简略的杀掉低优 Pod 的话，整个混部零碎也能够工作，这个动作咱们称为“驱赶”。 但如果在肯定工夫后，机器上的资源竞争又升高的话，那么低优 Pod 被杀死并在别的机器上重新启动，这里会大大缩短低优 Pod 的单个工作的执行工夫，所以在设计单机水位线时，须要尽可能的让低优 Pod 也要在能够容许的工夫范畴内可能“降级”运行。所以，咱们有对低优 Pod 的第 2 种操作，就是升高对它的 CPU 供给量，这个操作咱们称为“压抑”。 同时，如果一个节点上的资源趋于饱和，另外还比拟牵强附会的零碎行为就是不让新的低优 Pod 被调度进来。 于是咱们对于节点上低优 Pod 的行为就有 3 种：压抑、驱赶和禁止调度，由此就有三条水位线，同时，对于 CPU 这类的可压缩资源和内存这类不可压缩资源，行为还有区别。 ...

作者：斜阳 RocketMQ 实现了灵便的多分区和多正本机制，无效的防止了集群内单点故障对于整体服务可用性的影响。存储机制和高可用策略是 RocketMQ 稳定性的外围，社区上对于 RocketMQ 目前存储实现的剖析与探讨始终是一个热议的话题。近期我始终在负责 RocketMQ 音讯多正本和高可用能力的建设，和大家分享下一些乏味的想法。 本文想从一个不一样的视角，着重于谈谈我眼中的这种存储实现是在解决哪些简单的问题，因而我从本文最后的版本中删去了繁杂的代码细节剖析，由浅入深的剖析存储机制的缺点与优化方向。 RocketMQ 的架构模型与存储分类先来简略介绍下 RocketMQ 的架构模型。RocketMQ 是一个典型的公布订阅零碎，通过 Broker 节点直达和长久化数据，解耦上下游。Broker 是实在存储数据的节点，由多个程度部署但不肯定齐全对等的正本组形成，单个正本组的不同节点的数据会达到最终统一。对于单个正本组来说同一时间最多只会有一个可读写的 Master 和若干个只读的 Slave，主故障时须要选举来进行单点故障的容错，此时这个正本组是可读不可写的。 NameServer 是独立的一个无状态组件，承受 Broker 的元数据注册并动静保护着一些映射关系，同时为客户端提供服务发现的能力。在这个模型中，咱们应用不同主题 (Topic) 来辨别不同类别信息流，为消费者设置订阅组 (Group) 进行更好的治理与负载平衡。 如下图两头局部所示： 服务端 Broker Master1 和 Slave1 形成其中的一个正本组。服务端 Broker 1 和 Broker 2 两个正本组以负载平衡的模式独特为客户端提供读写。 RocketMQ 目前的存储实现能够分为几个局部： 元数据管理具体指以后存储节点的主题 Topic，订阅组 Group，生产进度 ConsumerOffset。多个配置文件 Config，以及为了故障复原的存储 Checkpoint 和 FileLock。用来记录正本主备身份的 Epoch / SN (sequence number) 文件等（5.0-beta 引入，也能够看作 term）音讯数据管理，包含音讯存储的文件 CommitLog，文件版定时音讯的 TimerLog。索引数据管理，包含按队列的顺序索引 ConsumeQueue 和随机索引 IndexFile。元数据管理与优化为了晋升整体的吞吐量与提供跨正本组的高可用能力，RocketMQ 服务端个别会为单个 Topic 创立多个逻辑分区，即在多个正本组上各自保护局部分区 (Partition)，咱们把它称为队列 (MessageQueue)。同一个正本组上同一个 Topic 的队列数雷同并从 0 开始间断编号，不同正本组上的 MessageQueue 数量能够不同。 ...

现在，越来越多开发者退出到云原生开发浪潮中：据《云原生开发现状报告》显示，寰球云原生开发人员达 680 万，与 2020 年 5 月报告的云原生开发者数量 470 万相比，寰球云原生开发人员数量正在极速增长。 据统计，2022 年有超过 75% 的企业在生产环境中应用容器。企业在建设 IT 架构时，云不再是第三方孤立的平台，而是成为企业 IT 架构的一部分，云原生正变革开发模式。企业需思考云上运维、云上开发、云上迭代、云上容灾等问题，因而全云开发时代未然降临，开发者和企业将迎来技术红利暴发的黄金时代。那么开发者该如何适应这些变动？其中一种形式是降级集体技能和认知，从新适应一些工作模式，比方如何在云上做权限治理、资产治理、云上运维等。 基于此，第三届云原生编程挑战赛正式启动！本届大赛将深度摸索服务网格、边缘容器、Serverless 三大热门技术畛域，针对行业热门技术方向，把握外围解决问题、思考问题的形式，使用最前沿的产品技术工具，全面晋升集体能力。 赛道一：针对 Sidecar 模式下的服务网格数据面应用服务拜访 QPS 和延时的优化在服务网格技术呈现之前，能够应用 SpringCloud、Netflix OSS 等，通过在应用程序中集成 SDK，编程的形式来管理应用程序中的流量。然而这通常会有编程语言限度，而且在 SDK 降级的时候，须要批改代码并从新上线利用，会增大人力累赘。服务网格技术使得流量治理变得对应用程序通明，使这部分性能从应用程序中转移到了平台层，成为了云原生基础设施。以 Istio 为首的服务网格技术，正在被越来越多的企业所注目。 本赛题心愿从Sidecar代理资源分配、Sidecar配置调优、硬件优化几个角度登程，通过构建一种服务网格性能与资源占用动静优化零碎，实现在尽量减少Sidecar代理资源耗费的状况下，尽可能升高集群中服务的申请时延。 立刻扫码报名 赛道二：针对云原生边缘计算场景的 ACK@Edge 高效的边缘自治计划在云边协同的边缘场景架构体系下，随着边缘设施和边缘业务的规模增长，以及业务翻新带来的频繁变更，给云边协同带来了微小的管理效率和老本挑战。在实际过程中咱们发现，在云边协同的边缘场景架构体系下，有着大量的轻量级的设施，这些设施的配置绝对比拟低，升高边缘侧组件的资源占用率，为设施上的业务腾出更多的资源，曾经成为了必须要解决的问题。 本赛题心愿实现一个边缘侧的 edge-proxy 组件，负责转发边缘侧组件例如 kubelet/kube-proxy 的申请，同时可能将云上 apiserver 返回的数据缓存到本地，实现节点自治，并尽可能的升高 cpu，内存的资源占用率，实现一个高效的边缘自治计划。 立刻扫码报名 赛道三：实现一个 Serverless 架构的 Web IDE 服务在云的时代，IDE 越来越向着轻量化、分布式的方向演进。在小程序、Low code/No code、在线编程教育、前端一体化开发、大数据处理等畛域，Web IDE 都体现了越来越重要的价值。Web IDE 的应用通常是多租户、碎片化的。基于传统架构，要实现一个多租平安、可扩大、高性能、低成本的 IDE 服务很简单。而借助 Serverless 架构，将大幅升高难度。本赛题将提供一个 Web IDE 服务的参考实现，您在此基础上进行扩大，施展您的创意，发明一个独特的 Web IDE 服务！ ...

作者：十眠 概述稳定性大于所有，因而咱们须要有更无效的形式防止线上故障。在产生故障不可避免的假如下，咱们须要可能疾速修复，缩小线上影响。基于以上这些想法，咱们提出了 1-5-10 的快恢指标，所谓 1-5-10 的指标就是是要咱们对于线上问题可能做到 1 分钟发现，5 分钟定位，10 分钟修复。上面将会介绍一些阿里云上对于故障复原、诊断的一些最佳实际。 本文摘自 微服务治理技术白皮书 3.9 节关注阿里云云原生公众号，后盾回复关键词【技术白皮书】即可下载！ 1 分钟发现监控监控的作用一句话概括就是：发现利用中的问题，并将问题及时告警给技术人员进行解决。监控类型能够分为零碎问题的监控与业务问题的监控，零碎问题：常见的软硬件相干问题，比方程序异样，内存 fullGC 等，因为没有业务特色，监控策略可实用于各个利用。业务问题：在特定业务场景下定义的问题，比方商品无优惠券，权利超发问题等，须要依据业务特色来定制监控策略。 阿里云实时利用监控服务 ARMS 可能主动发现和监控利用代码中常见的 Web 框架和 RPC 框架，并统计接口的调用量、响应工夫、谬误数等指标。同时能够进一步获取接口的慢 SQL、MQ 沉积剖析报表或者异样分类报表，对错、慢等常见问题进行更粗疏的剖析。 ARMS 还提供了业务监控的能力，以代码无侵入的形式，可视化定义业务申请，提供贴合业务的丰盛性能指标与诊断能力。从业务视角掂量利用性能和稳定性的新形式，对业务的要害交易进行全链路的监控。业务监控通过追踪并采集应用程序中的业务信息，实时展示业务级的指标，例如业务的响应时长、次数和错误率，解决了应用程序和业务体现之间无奈映射关联的难题。 对于监控的要求有以下三点。实时：要求对问题的发现和预警是实时的，缩短问题产生和发现的时延；精确：要求监控和预警是精确的，包含对监控问题的定义，对预警阀值，预警等级，责任人的配置，防止误报；全面：要求预警信息是全面的，可能帮忙排查和解决问题。 “不管利用呈现任何问题，ARMS 都能够分明地展现问题出在哪一行代码。ARMS 对于咱们十分重要，大大缩短了修复故障的工夫，显著晋升了用户体验。自从用了 ARMS，咱们能及时发现和修复问题，再也不会被用户投诉所困扰。”  —— 华润万家 告警当监控发现有问题的时候，就须要通过不同等级的告警将问题及时告警给技术人员进行解决。ARMS 告警治理能从以下几点来晋升零碎的运维效率。 集成事件后治理更高效。告警治理默认反对一键化集成阿里云常见的监控工具，并反对更多的监控工具手动接入，不便对立保护。事件接入模块稳固，能提供 7x24 小时的无间断事件处理服务。解决海量事件数据时能够保障低延时。及时精确地将告警告诉给联系人。配置告诉规定，对事件合并后再发送告警告诉，缩小运维人员呈现告诉疲劳的状况。依据告警的紧急水平抉择邮件、短信、电话、钉钉等不同的告诉形式，来揭示联系人解决告警。通过降级告诉对长时间没有解决的告警进行屡次揭示，保障告警及时解决。帮忙您疾速便捷地治理告警。联系人能通过钉钉随时解决告警。应用通用告警格局，联系人能更好的剖析告警。多个联系人通过钉钉协同解决。统计告警数据，实时剖析解决状况，改良告警解决效率。5 分钟定位故障服务实例隔离与诊断在线上微服务场景中，当服务提供者的某些实例出现异常时，一方面，须要防止服务消费者拜访到异样实例，另一方面，须要保留异样现场，便于后续的问题排查。出于另一个思路思考，咱们都晓得 Dump 内存在肯定水平上会影响咱们利用的性能，可能会对咱们的线上业务造成影响，咱们是否能够在 Dump 内存之前将业务流量从该实例上隔离。MSE 治理核心服务实例隔离与诊断性能能够帮忙咱们将异样实例的流量隔离，一方面反对将来自微服务的流量进行隔离，另一方面反对将来自 K8s Service 的流量进行隔离，能够彻底隔离掉生产环境中的业务流量，而后咱们能够联合阿里云利用实时监控服务 ARMS 所提供的内存快照生成能力，及时生成异样实例的线上环境内存快照，帮忙咱们进行后续问题剖析与诊断。服务实例隔离与诊断性能能很好地帮忙咱们应答线上突发的事变（比方内存泄露等），晋升微服务零碎整体稳定性。 实际咱们能够在 MSE 服务治理的控制台看到在线的实例列表。 抉择特定异样实例，进行服务下线操作，将实例从注册核心中移除，同时如果咱们配置了 MSE 提供的就绪查看探针，还会将来自 K8s Service 的流量进行隔离，咱们能够在事件中心里查看对应实例是否下线胜利。 进行下线操作后，咱们能够通过 MSE 提供的秒级节点监控看到是否还有流量。等流量齐全进行后，可通过阿里云利用监控服务 ARMS 提供的创立内存快照性能，给异样实例创立内存快照，以便后续进一步的问题排查。 点击去创立内存快照按钮，进行内存快照创立。 ...

导读 本文适宜： 想理解 Serverless 灰度公布的同学。 认为以后 Serverless 灰度公布配置太简单，寻求简洁版灰度公布流程的同学。 想理解 Serverless Devs 组件和插件之间关系的同学。 Serverless 灰度公布什么是 Serverless ?Serverless 顾名思义就是无服务器，它是一种“来了就用，功能齐全，用完即走”的全新计算提供形式，用户无需预制或治理服务器即可运行代码，只需将代码从部署在服务器上，转换到部署到各厂商 Serverless 平台上；同时享受 Serverless 按需付费，高弹性，低运维老本，事件驱动，降本提效等劣势。 什么是 Serverless 灰度公布？灰度公布又称为金丝雀公布( Canary Deployment )。过来，矿工们下矿井前，会先放一只金丝雀到井内，如果金丝雀在矿井内没有因缺氧、气体中毒而死亡后，矿工们才会下井工作，能够说金丝雀爱护了工人们的生命。 与此相似，在软件开发过程中，也有一只金丝雀，也就是灰度公布（Gray release）：开发者会先将新开发的性能对局部用户凋谢，当新性能在这部分用户中可能安稳运行并且反馈侧面后，才会把新性能凋谢给所有用户。金丝雀公布就是从不公布，而后逐步过渡到正式公布的一个过程。 那么对于部署在 Serverless 平台上的函数应该怎么进行灰度公布呢？ 下文将以阿里云函数计算 FC 为例，为各位开展介绍。 灰度公布有一个流程，两种形式。 一个流程Serverless 灰度公布是通过配置别名来实现的，别名能够配置灰度版本和主版本的流量比例，在调用函数时应用配置好的别名即可将流量按比例发送到相应版本。 配置灰度公布的流程如下： Service 中公布一个新版本。创立或更新别名，配置别名关联新版本和稳固版本，新版本即为灰度版本。将触发器 ( Trigger ) 关联到别名。将自定义域名 ( Custom Domain ) 关联到别名。在调用函数中应用别名，流量会按配置比例发送到新版本和稳固版本。传统做法的两种形式1、阿里云控制台 web 界面： a.公布版本 b.创立别名 c.关联触发器 d.关联自定义域名 2、应用 Serverless Devs cli a.公布版本 s cli fc version publish --region cn-hangzhou --service-name fc-deploy-service --description "test publish version"b.创立别名并设置灰度 ...

云原生时代，用户对云弹性能力的诉求越来越强烈。弹性需要强度在 VM 时代还是人工操作分钟级别的，在容器时代，曾经达到秒级的要求，用户面对不同的业务场景，对云的冀望和要求也在发生变化。 因而，阿里巴巴云原生团队和阿里达摩院决策智能时序团队合作开发了 AHPA （Advanced Horizontal Pod Autoscaler）弹性预测产品，该产品次要出发点是基于检测到的周期做“定时布局”，通过布局实现提前扩容的目标，在保障业务稳固的状况下，让你真正实现按需应用。 AHPA 适应场景包含： 有显著周期性场景。如直播、在线教育、游戏服务场景等固定实例数+弹性兜底。如常态业务下应答突发流量等举荐实例数配置场景那么，AHPA 该如何配置能力解锁最佳应用姿态？6 月 29 日（周三）15:00，阿里云高级研发工程师 ，李鹏（元毅）将在直播间为大家揭晓答案。 直播主题直播主题：AHPA 弹性预测最佳实际 直播工夫2022 年 06 月 29 日（周三）15:00 直播嘉宾李鹏（元毅），阿里云高级研发工程师 直播简介在云原生场景下，资源容量往往难以预估，而应用 K8s 原生的 HPA，往往要面对弹性滞后以及配置简单问题。阿里云容器服务与达摩院决策智能时序团队单干推出的 AHPA（Advanced Horizontal Pod Autoscaler）弹性预测，能够依据业务历史指标，自动识别弹性周期并对容量进行预测，帮你提前进行弹性布局，解决弹性滞后的问题。 AHPA 如何配置能力解锁最佳应用姿态？本次直播，咱们将通过  AHPA 弹性预测最佳实际为你揭晓答案。 你将理解•AHPA 弹性预测介绍 •指标源及 AHPA 配置参数介绍 •边界爱护的实用状况 •利用降噪、算法分位数能够做哪些事件 •典型场景：从 HPA 转 AHPA•典型场景：弹性举荐 立即锁定本场直播点击“此处”或扫描海报二维码锁定本场直播 本次直播将在阿里巴巴云原生视频号、阿里云原生 B 站直播间同步播出，敬请关注~

作者：智真 基于 Prometheus 的监控实际中，尤其是在规模较大时，时序数据的存储与查问是其中十分要害，而且问题点较多的一环。如何应答大数据量下的长周期查问，原生的 Prometheus 体系并未能给出一个令人满意的答案。对此，ARMS Prometheus 近期上线了降采样性能，为解决这个问题做出了新的尝试。前言问题背景Prometheus 与 K8s 作为云原生时代的一对黄金搭档，是目前许多企业运行环境的标准配置。然而，为了适应业务规模和微服务的倒退演进，被监控对象的数量会一路增长；为了更残缺的体现零碎或利用的状态细节，指标粒度划分越来越粗疏，指标数量越来越多；为了发现更长周期的趋势变动，指标数据的保留周期势必也要更长。所有这些变动最终都会导致监控数据量的爆炸性增长，给观测产品的存储、查问、计算带来十分大的压力。 咱们能够通过一个简略的场景，来更直观的感触下这种数据爆炸的结果。如果咱们须要查问近一个月中我的集群各个节点上 CPU 用量的变动状况，而我的集群是一个 30 个物理节点的小规模集群，每个节点上均匀运行了 50 个须要采集指标的 POD，依照默认的 30 秒采集距离，咱们须要解决的采集 target 共有 3050 = 1500 个，而每个采样点每天会被抓取 606024/30 = 2880 次，在一个月的周期里，共有 1500 2880 30 = 1.3 亿次指标抓取，以 Node exporter 为例，一台裸机一次抓取吐出的 sample 数量约为500，那么一个月内这个集群产生的采样点约有 1.3 亿 500 = 650 亿个！而在事实的业务零碎中，状况往往不会这么现实，理论的采样点数量往往会超过千亿。 面对这种状况，咱们必须要有一些技术手段，在尽可能保证数据准确性的前提下，对存储/查问/计算的老本和效率做优化晋升。降采样（DownSampling）就是其中一种代表性的思路。 什么是降采样降采样基于这样一个前提：数据的解决合乎结合律，多个采样点的值的合并，并不会影响最终计算结果，刚巧 Prometheus 的时序数据就合乎这样的特点。降采样换句话说就是升高数据的分辨率，其思路十分间接，如果将肯定工夫距离内的数据点，基于肯定规定，聚合为一个或一组值，从而达到升高采样点数，缩小数据量，加重存储查问计算的压力。所以咱们须要两个输出项：工夫距离，聚合规定。 对于降采样的工夫距离，基于教训剖析，咱们划定了两种不同的降采样工夫距离：五分钟和一小时，再加上原始数据，会失去三种不同 resolution 的数据，依据查问条件主动将查问申请路由到不同 resolution 的数据。随着后续 ARMS Prometheus 提供更长的存储时长抉择，咱们可能还会减少新的工夫距离选项。 对于聚合规定，通过对 Prometheus 的算子函数的剖析，各种算子函数最终都能够归纳到六种类型的数值计算上： max，用于计算 vector 内最大值，典型算子如 max_over_time；min，用于计算 vector 内的最小值，典型算子如 min_over_time；sum，用于计算 vector 内的和值，典型算子如 sum_over_time；count，用于统计 ventor 内的点数，典型算子如 count_over_time；counter，用于计算变化率，典型算子如 rate，increase 等；avg，取工夫距离内的各个点的平均值； 由此可见，对于工夫区间内的一系列采样点，咱们只须要计算出如上六种类型的聚合特征值，在查问时返回相应工夫区间聚合值即可。如果默认的 scrape interval 为 30 秒，五分钟的降采样会将十个点聚合成一个点；一小时的降采样，会将 120 个点聚合成一个点，同样查问波及到的采样点数，会有数量级的降落，如果 scrape interval 更小，那么采样点缩减的成果会更显著。采样点数的缩减一方面加重了 TSDB 读取压力，另一方面查问引擎的计算压力也将同步减小，进而无效缩小查问耗时。 ...

作者：王夕宁 本文内容基于作者在 2022 年云原生产业大会上的演讲内容整顿而成。背景回顾下应用服务架构体系的演进。从服务调用方与提供方的解决形式来看, 能够分为 3 个阶段。 第一个阶段是集中式负载平衡, 也就是说服务调用方是通过一个内部的负载平衡路由到对应的服务提供方。其劣势不言而喻,  对利用自身无侵入, 能够反对多语言多框架来开发实现利用自身, 负载平衡对立集中管理, 整个部署简略。但劣势也十分显著, 因为是集中式所以导致伸缩性受限, 同时这种集中式负载平衡的服务治理能力绝对都较弱。 第二阶段是指微服务的分布式治理, 即服务调用方内置治理能力, 以 SDK 库的形式集成到利用中。带来的劣势是整个伸缩性较好, 服务治理能力强, 但同时会留神到它的劣势, 包含对利用自身的侵入、因为依赖于 SDK 所以导致对多语言反对比拟艰难、分布式治理部署带来的复杂性等。 第三阶段就是当初的服务网格技术。通过把这些服务治理的能力 Sidecar 化，就可能把服务治理的能力与应用程序自身进行理解耦，能够较好地反对多种编程语言、同时这些 Sidecar 能力不须要依赖于某种特定技术框架。这些 Sidecar 代理造成一个网状的数据立体，通过该数据立体解决和察看所有服务间的流量。管制面对这些 Sidecar 代理进行对立治理。但因而带来了肯定的复杂度。 下图是服务网格的架构图。后面提到, 在服务网格技术下, 每一个应用服务实例都会随同了一个 Sidecar 代理, 业务代码不感知 Sidecar 的存在。这个 Sidecar 代理负责拦挡利用的流量，并且提供流量治理、平安、可观测三大性能。 在云原生利用模型中，一个应用程序可能会蕴含若干个服务，每个服务又有若干个实例形成，那么这些成千盈百个应用程序的 Sidecar 代理就造成了一个数据面, 也就是图中的数据立体层。 而如何对立治理这些 Sidecar 代理, 这就是服务网格中的管制立体局部要解决的问题。管制立体是服务网格的大脑，负责为数据立体的 Sidecar 代理下发配置, 治理数据面的组件如何执行, 同时也为网格应用人员提供对立的 API，以便较容易地操纵网格治理能力。 通常来说, 启用服务网格之后,  开发人员、运维人员以及 SRE 团队将以对立的、申明的形式解决应用服务治理问题。 服务网格加持下的云原生利用基础设施服务网格作为一种用来治理应用服务通信的根底核心技术,  为应用服务间的调用带来了平安、牢靠、疾速、利用无感知的流量路由、平安、可观测能力。 能够看到, 服务网格加持下的云原生利用基础设施带来了重要的劣势, 分为六个方面。 ...

作者：渐意 前言工作零碎中有一类很重要的概念，即工作的状态和生命治理周期。其本质是对工作的生命周期治理。细分的状态有助于在应用时可能更分明的理解零碎产生了什么内容，便于针对性的依据业务状况进行操作。函数计算 Serverless Task 提供了多种可查问的状态，并提供了各状态间转移的工夫点。在函数的执行层面，函数计算也提供了工作的生命周期治理概念，用户能够依据需要决定当系统对工作实例进行初始化、回收等一系列动作时的执行逻辑，实现残缺的运行时生命周期治理。本文将别离对工作运行状态及运行时治理这两个方面的内容进行介绍。 工作的状态及生命周期的治理工作的状态治理 当用户提交工作并收到提交胜利的返回后，工作便曾经进入系统对其生命周期的治理流程中。一个工作的状态变更由外部的一个状态机负责管理，并对外透出状态反对实时查问。整个状态转换图如下所示： 图 1 用户触发一次工作后，工作入队，变更为 Enqueued 状态，并返回触发胜利；工作在函数计算后端服务中出队，工作变为 Dequeued 状态；后端会查看工作配置。如果<!----> 配置了异步音讯有效期性能，并且该音讯出队工夫与入队工夫之差已超过有效期，则工作被抛弃，变更为 Expired 状态。工作终止；工作对应的函数已被删除，或创立实例呈现谬误，则抛弃音讯，工作变更为 Invalid 状态；<!----> 查看后工作正式进入 Running 状态。此时工作已触发理论的执行；工作执行实现后，依据返回会变更为以下几个状态：<!----> Retrying：用户配置了重试次数（默认为 3），且工作执行失败，这时会进入重试中状态，之后会变更为 Running 状态；Failed：工作执行失败，且超过了重试次数。此时会将工作状态改为 Failed；Succeeded：工作执行胜利。<!----> 如果在整个状态流转过程用户触发 Cancel，则工作会先变更为 Stopping 状态，并尝试进行工作执行。当工作进行执行胜利后，工作进入 Stopped 状态。工作运行时治理及生命周期当工作状态进入 Running 后，工作的理论执行便已交给函数计算的运行时。在安全性方面，函数计算会依照 VM 对不同账号进行隔离，同一个账号下的函数可能运行于同一个 VM 中。VM 内有一个负责管理容器的客户端，来理论触发函数的执行，并收集执行后果。 用户的运行实例有几个不同的状态： 图 2 函数计算对上述所有实例状态变动的过程均提供接口，反对用户侧配置相应的逻辑。 创立实现 -> 执行申请阶段：反对 Initializer 性能，反对初始化实例操作。用户能够配置诸如全局变量、连接池初始化等相干操作；执行中 -> 执行实现后 Pause 实例：反对 PreFreeze 接口，反对在函数 Pause 实例前执行用户侧的自定义逻辑；执行中 -> 内部 cancel：函数计算会强制 Restart 用户实例，在 Restart 前反对 PreStop 接口。用户能够配置优雅进行的相干逻辑，以便反对 Cancel 时的自定义行为；实现后 Pause -> 销毁实例：当一段时间没有申请后，函数计算将销毁实例。此时会调用 PreStop 接口，用户能够配置销毁容器的行为（如敞开连接池等）。 ...

现在，不少企业的公布流程要求代码公布到生产环境前须要通过审批。这种公布审批流程，对企业的的CI/CD工具提出了新要求：CI/CD步骤里须要反对人工卡点审批，并在人工卡点审批通过后能主动触发后续的部署工作。 云效流水线Flow公布审批示例 如上图所示，云效流水线Flow很早就已反对人工卡点审批能力。 同时，企业能够依据本身须要，在Flow内灵便设置卡点的验证形式、验证者类型、验证人和告诉形式。 然而，仅仅做到这些，还不够！ 在理论公布流程中，当审批人收到审批告诉后，仍须要返回云效PC端，才可实现审批操作。这对审批人来说是种很大的困扰： 上班路上，忽然接到公布审批告诉，还得掏出电脑、连上强劲的热点，就为了实现那个审批节假日突遇紧急公布，身边没带电脑，纵使兵临城下，就是无奈实现公布当公布过程不太顺利、呈现屡次公布时，每次都须要麻烦审批人登录审批，屡次下来，审批人也很烦 好消息！无需登录就可实现审批！在泛滥用户的强烈呼声下，云效Flow的工程师们快码加编，终于在近期上线了流水线钉钉审批性能。 在云效流水线内配置好钉钉审批流程后，审批人无需登录云效PC端，钉钉上动动手指就可实现审批，真的是不便不少！ 看到这里，你肯定有种激动，心愿可能在本人的企业内可能玩起来，那么，怎么做能力实现流水线中的钉钉审批呢？ 3步走，上手流水线钉钉审批企业须要实现如下2个配置： 步骤1：绑定钉钉企业和个人信息步骤2：云效Flow中增加人工卡点并执行流水线设置好这2个步骤，将主动推送钉钉审批音讯啦。每个步骤具体的配置指南，可点击下方链接查看。 查看云效流水线钉钉审批具体配置指南 写在最初用过Jenkins的同学应该有感触，在Jenkins上要实现公布审批性能并且与企业的账号权限买通，开发工作量还是不小的。而在云效Flow中，这些能力都是收费、开箱即用的。 收费、还香的性能，举荐大家都去用一用！

作者： 铖朴 新版本预览本次公布的 Spring Cloud Alibaba 2.2.8 版本是基于我的项目 2.2.x 分支构建公布的，是在 Spring Cloud Hoxton.SR12、Spring Cloud 2.3.12.RELEASE 的根底上对其中包含注册配置核心、分布式音讯等在内的泛滥组件进行了降级，属于一个组件降级与 Bug 批改的版本。本次公布的 Spring Cloud Alibaba 2.2.8 版本对以下组件版本进行了降级： Nacos：降级 Nacos 客户端到 2.1.0 版本 [ 1] ，该版本新增了包含认证插件和配置加密插件等相干能力。RocketMQ：降级到了 4.9.3 版本 [ 2] ，该版本提供了轻量级音讯队列和为提早音讯提供异步发送性能等在内的诸多个性。Sentinel：降级到了 1.8.4 版本 [ 3] ，该版本欠缺了 transport 和网关流控参数解析模块的扩展性，提供拦截器扩大以反对用户自定义鉴权。Seata：降级到了 1.5.1 版本 [ 4] ，该版本提供了控制台，SkyWalking APM 能力等在内的诸多新个性。 除了组件降级，另外也修复了一些之前版本所存在的问题，进一步晋升了 Spring Cloud Alibaba 应用的稳定性与健壮性。更多内容可参见发版布告 [ 5] 。Spring Cloud Alibaba 与 Spring Cloud 和 Spring Boot 以后各版本对应关系可参见官网 Wiki 版本阐明 [ 6] 。 打造更好用的微服务技术通过三年多的飞速发展，截止到以后，Spring Cloud Alibaba 共公布了 28 个版本，在 GitHub上的累计 stars 数目超过了 22.5k，fork 数达到了 7.0k，用户数达到了 24k 之多，各项要害数据遥遥领先国内外各大云厂商推出的同类开源微服务产品。 ...

作者：肯梦 当下降本增效是各行各业的主题，而 SaaS 利用作为更快触达和服务业务场景的形式则被更多企业熟知和采纳。随着国内 SaaS 商业环境的逐步成熟，传统企业中各个部门的工程师和管理者，能迅速决定洽购晋升效率的 SaaS 产品，而后疾速投入生产和应用。然而随着行业 SaaS 越来越多，如何解决各个 SaaS 零碎的数据孤岛，如何将SaaS 利用数据与现有零碎数据进行买通，未然变成了企业应用 SaaS 的瓶颈。因而，业内也宽泛提出 B2B integration 企业集成的概念。 本文将结合实际业务场景讲述在 SaaS 行业的洞察与 SaaS 集成的摸索实际。 什么是 SaaSSaaS 概述SaaS（Software-as-a-Service，软件即服务）源自于美国 Salesforce 公司（1999 年创建）发明的新软件服务模式。相比于传统软件，用户应用的 SaaS 软件，其数据保留在云端（国内有很多行业 SaaS 因为其数据敏感会独自部署在客户 IDC）。而且，SaaS 公司提供给客户的服务通常是按需租用的，比方按年缴纳使用费5年，第二年再续费，如果不称心也能够不续费，这会大大激发 SaaS 守业公司继续的打磨产品、继续的为客户提供更大价值的能源。 SaaS 典型分类SaaS 分类比拟繁琐，个别有两个分类维度。一个维度依照应用场景，另一个维度依照商业价值。 SaaS 个别分类为 通用 SaaS 和 行业 SaaS 两个根底类。 通用 SaaS 顾名思义是通用的，跨行业的，比方钉钉即时通讯或者某司的 HR 产品，因为应用场景更广，因此客群也会更多。 行业 SaaS 是在某个行业内应用的产品，比方餐饮企业 SaaS、电商 SaaS 等。 当然，还有第二个维度是工具 SaaS 和 商业 SaaS。 工具 SaaS，为客户企业提供一个进步管理效率的工具；商业 SaaS，除了提供一部分“工具”价值外，还能为客户企业提供增值价值，比方减少营收、取得资金等。 商业 SaaS 产品尽管危险更大，但在国内特色的商业环境、管理水平及人才构造下，更容易疾速实现客户价值和自我价值。 ...

作者：渐意 前言无论是在大数据处理畛域，还是在音讯解决畛域，工作零碎都有一个很要害的能力 - 工作触发去重。这个能力在一些对准确性要求极高的场景（如金融畛域）中是必不可少的。作为 Serverless 化工作解决平台，Serverless Task 也须要提供这类保障，在用户利用层面及本身零碎外部两个维度具备工作的精确触发语义。本文次要针对音讯解决可靠性这一主题来介绍函数计算异步工作性能的技术细节，并展现如何在理论利用中应用函数计算所提供的这方面能力来加强工作执行的可靠性。 浅谈工作去重在探讨异步音讯解决零碎时，音讯解决的根本语义是无奈绕开的话题。在一个异步的音讯解决零碎（工作零碎）中，一条音讯的解决流程简化如下图所示： 图 1 用户下发工作 - 进入队列 - 工作处理单元监听并获取音讯 - 调度到理论 worker 执行 在工作音讯流转过程中，任何组件（环节）可能呈现的宕机等问题会导致音讯的谬误传递。个别的工作零碎会提供至少 3 个层级的音讯解决语义： At-Most-Once：保障音讯最多被传递一次。当呈现网络分区、零碎组件宕机时，可能呈现音讯失落；At-Least-Once：保障音讯至多被传递一次。消息传递链路反对谬误重试，利用音讯重发机制保障上游肯定收到上游音讯，然而在宕机或者网络分区的场景下，可能导致雷同消息传递屡次。Exactly-Once 机制则能够保障音讯准确被传送一次，准确一次并不是意味着在宕机或网络分区的场景下没有重传，而是重传对于接受方的状态不产生任何扭转，与传送一次的后果一样。在理论生产中，往往是依赖重传机制 & 接管方去重（幂等）来做到 Exactly Once。函数计算可能提供工作散发的 Exactly Once 语义，即无论在何种状况下，反复的工作将被零碎认为是雷同的触发，进而只进行一次的工作散发。 联合图 1，如果要做到工作去重，零碎至多须要提供两个维度的保障： 零碎侧保障：任务调度零碎本身的 failover 不影响音讯的传递正确性及唯一性；提供给用户一种机制，能够联合业务场景，做到整个业务逻辑的触发+执行去重。上面，咱们将联合简化的 Serverless Task 零碎架构，谈一谈函数计算是如何做到下面的能力的。 函数计算异步工作触发去重的实现背景函数计算的工作零碎架构如下图所示： 图 2 首先，用户调用函数计算 API 下发一个工作（步骤 1）进入零碎的 API-Server 中，API-Server 进行校验后将音讯传入外部队列（步骤 2.1）。后盾有一个异步模块实时监听外部队列（步骤 2.2），之后调用资源管理模块获取运行时资源（步骤 2.2-2.3）。获取运行时资源后，调度模块将工作数据下发到 VM 级别的客户端中（步骤 3.1），并由客户端将工作转发至理论的用户运行资源（步骤 3.2）。为了做到上文中所提到的两个维度的保障，咱们须要在以下层面进行反对： 零碎侧保障：在步骤 2.1 - 3.1 中，任何一个两头过程的 Failover 只能触发一次步骤 3.2 的执行，即只会调度一次用户实例的运行；用户侧利用级别去重能力：可能反对用户屡次重复执行步骤 1，但理论只会触发一次 步骤 3.2 的执行。零碎侧优雅降级 & Failover 时的工作散发去重保障当用户的音讯进入函数计算零碎中（即实现步骤 2.1）后，用户的申请将收到 HTTP 状态码 202 的 Response，用户能够认为曾经胜利提交一次工作。从该工作音讯进入 MQ 起，其生命周期便由 Scheduler 保护，所以 Scheduler 的稳定性及 MQ 的稳定性将间接影响零碎 Exactly Once 的实现计划。 ...

作者：尹航 作为业内首个全托管 Istio 兼容的阿里云服务网格产品 ASM，一开始从架构上就放弃了与社区、业界趋势的一致性，管制立体的组件托管在阿里云侧，与数据面侧的用户集群独立。ASM 产品是基于社区 Istio 定制实现的，在托管的管制面侧提供了用于撑持精细化的流量治理和平安治理的组件能力。通过托管模式，解耦了 Istio 组件与所治理的 K8s 集群的生命周期治理，使得架构更加灵便，晋升了零碎的可伸缩性。从 2022 年 4 月 1 日起，阿里云服务网格 ASM 正式推出商业化版本, 提供了更丰盛的能力、更大的规模反对及更欠缺的技术保障，更好地满足客户的不同需要场景，详情可点击原文链接查看。前言服务网格是一个通过“Sidecar”模式进行服务治理简化的平台。整个服务网格能够划分为包含外围组件 Istiod 的“管制面”以及包含了每个服务的 Sidecar 的“数据面”。如果各位应用过服务网格，置信对下面的概念也算是略有理解了。 在服务网格 Istio 中，咱们晓得每个 Sidecar 都是一个 envoy 利用，外部有着蕴含着 listener、route、cluster、secret 等局部的残缺配置；envoy 就是依据这些配置来扭转本身行为，实现不同的流量管制伎俩的。而管制面组件的次要工作，就是将网格中的 VirtualService、DestinationRule 等资源“翻译”成 envoy 的具体配置，并将配置发送给数据面的每个 envoy，咱们简称这个过程为“配置推送”。 在 envoy 中，cluster 配置对应着 envoy 外部的“集群”这个概念，一个 cluster 是指“Envoy 连贯的一组逻辑雷同的上游主机”，其实大多数时候也就是对应着一个具体的服务。 如果咱们理论查看 envoy 的残缺配置会发现，咱们在什么都没做的时候，envoy 外部就曾经蕴含着一些动静下发的 cluster 了，也就是说，Sidecar 主动发现并蕴含了集群中的服务信息。这里就引出一个外围问题：服务网格的“服务发现”是如何实现的呢？咱们通常会用“网格内服务”来称说对应 Pod 注入了 Sidecar 的服务；那么，是不是说服务网格会将注入了 Sidecar 的“网格内服务”主动的退出每个 Sidecar 的 cluster 配置呢？ 明天这篇文章就来次要聊一聊服务网格的“服务发现”和“配置推送”。 服务网格的“服务发现”一个简略的小试验就能够解答下面的这些问题。咱们在 Kubernetes 集群中装置服务网格平台（能够应用 aliyun ASM + ACK 来疾速搭建服务网格平台），而后在 default 默认命名空间之外，再建设一个 test 命名空间。 ...

作者：铭少 混沌工程是什么零碎架构经验了单机到分布式，再到当初的云原生架构，其复杂度一直上涨，问题定位的难度也随之上涨。面对随时都可能产生的故障，有没有什么的方法能很好解决这个窘境。 混沌工程（Chaos Engineering）在分布式系统上进行试验的学科，通过被动注入故障的形式，提前发现零碎的薄弱点，推动架构的改良，最终实现业务韧性。从而防止故障在线上运行环境上产生。 这里拿云原生架构来举例说明，为什么混沌工程能解决零碎架构中存在的问题。云原生架构准则和混沌工程准则是能够找到对应关系，以服务化准则阐明，服务化准则其根本就是服务如何治理的问题，也就是判断上下游服务之间强弱依赖关系的问题。通过混沌工程，能够通过将申请定位到具体机器，再放大到具体机器上的利用，一直最小化爆炸半径，通过在利用之间注入故障，判断上下游服务是否失常，来判断其强弱依赖关系。 混沌工程的指标是实现韧性架构，这里蕴含两个局部：韧性零碎和韧性组织。韧性零碎具备冗余性、扩展性、不可变基础设施、无状态利用、防止级联故障等。韧性组织蕴含高效交付、故障预案、应急响应机制等。高度韧性的零碎也会呈现预期之外的故障，所以韧性的组织能补救韧性零碎缺失的局部，通过混沌工程构建极致的韧性架构。 混沌工程就是通过被动注入故障的形式，提前发现零碎的薄弱点，推动架构改良，最终实现业务韧性。引入混沌工程对于不同职能的人而言，其业务价值有所不同： 架构师：能帮忙其验证架构的容错能力开发/运维：能进步其故障的应急效率测试：帮忙其提前裸露线上问题，升高故障复发率产品/设计：提醒客户应用体验 如何落地混沌工程对于企业或业务如何对混沌工程进行落地？有无工具或平台能帮忙其疾速落地？ ChaosBlade 是一款遵循混沌试验模型的混沌试验执行工具，具备场景丰盛度高，简略易用等特点，反对多平台、多语言环境，包含 Linux、Kubernetes 和 Docker 平台，反对 Java、NodeJS、C++、Golang 语言利用。反对 200 多个场景，3000 多个参数。是一款用于端侧的故障注入工具，但在业务进行落地时，会存在以下几个问题： 故障注入过程如何可视化？如何同时对多个集群或主机进行故障注入？如何拿到整体演练的统计信息...... 所以在 ChaosBlade 之上还须要平台层，对混沌工程执行工具进行治理与演练编排。 ChaosBlade-Box 是面向多集群、多语言、多环境，开源的云原生混沌工程控制台。 开源平台和注入工具的整体架构如下，次要包含几个组成模块： ChaosBlade-Box Console ：混沌试验用户界面ChaosBlade-Box：Server 后端服务，次要包含演练场景的编排和平安管控、混沌工程工具部署（ChaosBlade、LitmusChaos...）、反对探针治理和多维度试验Agent：探针，次要有（ChaosBlade-Box）Server端进行建联并放弃心跳、上报 K8s 相干数据、演练命令下发通道等性能ChaosBlade：部署在业务的主机或 K8s 集群内，在端侧进行演练的工具 新版 ChaosBlade-Box 平台是一个面向多集群、多环境、多语言的云原生混沌工程平台。反对国际化中英文切换，反对全局命名空间，使得同一用户可依据本人需要，设置不同的全局命名空间，如：测试空间、沙盒空间和线上空间等。提供自动化的工具部署，简化工具装置步骤，进步执行效率。平台反对不同环境的探针装置和演练，如主机和 Kubernetes，其中 Kubernetes 环境下反对 Node、Pod、Container 维度下的演练。在 Kubernetes 环境下会主动收集集群内的 Pod 相干数据，并在利用治理中进行对立治理，这样简化用户演练查问步骤，无需去集群内查看要演练利用的 Pod 名或 Container 名。并反对一键迁徙到企业版，按需将社区版的演练数据同步到企业版。 以下是在新版 ChaosBlade-Box 平台上进行一次演练的全过程，反对程序执行、阶段执行两种流程编排，程序执行指的是多个演练场景顺次失效，阶段执行值得是多个演练场景同时失效。通过多种安全策略保障演练失去复原，如手动处罚和主动进行，主动进行通过在演练配置的时候设置超时参数来进行配置，这样即使平台和探针（Agent）失联，无奈进行手动进行时，也能在超时工夫达到的时候，主动复原故障。 新版劣势是什么此次公布的新版相较于老版，前端界面和企业版进行对立，简化应用习惯的切换老本，更为欠缺的国际化中英文切换，并反对全局命名空间的切换；后端提供了更为晦涩的演练编排，欠缺的利用治理，并增强了对探针的管控，并反对一键迁徙到企业版；增强了探针的性能，提供了更加欠缺的 API，反对多环境部署且反对在不同环境作为演练通道，反对主动装置卸载，并收集并上报数据简化演练晦涩。 相干链接 中间件开发者大会地址（演讲稿 PDF 可下载）： ...

数字经济时代，数字化转型成为社会的广泛共识和口头。越来越多的业务运行在数字化基座之上，软件系统正成为业务翻新的价值外围和翻新引擎。在这一趋势下，软件产业面临着许多新挑战和新机遇：一方面，万物互联下软件系统规模和复杂度持续增长；而另一方面，业务的疾速变动对软件交付效力的要求却一直晋升；软件构建和交付形式亟待改革。 要解决问题，先直面问题。为更好地厘清波涛汹涌的数字化转型浪潮下软件产业所面对的时机与挑战，6月29日，阿里云云效与阿里云开发者评测局栏目，联结特邀了InfoQ极客帮副总裁付晓岩、南京大学软件工程学院传授张贺、Thoughtworks寰球数字化转型负责人肖然、国内精益产品开发最早实践者何勉（阿里云云效解决方案负责人），阿里云资深技术专家陈鑫（云效平台负责人）以及阿里云高级产品专家张裕（云效平台产品架构师）共6位领军人物，一起围绕数字化转型浪潮下的技术变局进行了深度的研究。 数字环境下，各界如何对待科技倒退与业技交融？以后，央行偏重晋升产业的整体数字化，同时还提出了更高的要求：心愿业务零碎或者业务翻新可能实现跨角色、跨流程的自在编排和组合。这个要求即使对互联网企业来说都十分高，银行业等传统企业如果想通过企业级的工程，来整体晋升业务和技术能力、实现业务和技术的交融，更是一件艰难的事件。所以，须要一些新的方法论或工具来撑持。 今年年初，中国银保监会与人民银行公布的《对于银行业保险业数字化转型的领导意见》曾经明确指出，在数字化时代要做到“业技交融”，同时BizDevOps这个词也曾经被写入央行《金融科技倒退布局（2022-2025年）》中。这两份文件曾经为银行的数字化转型提出了具体的要求和办法，变成了行业转型的参照。 金融行业人造走在数字化的前沿，曾经享受到了数字化的红利。然而，还有很多产业和行业仍面临挑战。比方，生产线的呈现能够让企业既失去品质又失去了效率，但肯定水平上就义了体验，而数字化人造能够解决这个问题。如果用户需要的获取、还原、设计、生产、交付和服务等环节有数字化的撑持，就有可能在整个环节里满足用户的个性化体验。 咱们曾经看到，很多企业通过数字化技术打造独特的体验，发明差异化价值。实体经济正在逐步向信息化的世界迁徙。将来，所有的实体经济都要做数字化，甚至将来所有的企业都会成为软件企业。将来任何业务想要有竞争力，都必须运行在数字化基座之上。 那么，数字化的引擎是什么？是软件。软件的燃料是什么？是数据。 因而，整个数字化转型浪潮对软件开发提出了十分高的要求。如何端到端、全链路地去看而不是只看单个阶段或者单个产品？如何建设最实质的模型，从物理世界适度到数字世界，并反过来影响物理世界？如何构建顺畅高效精准的交付模式？这些问题都变得十分重要。 作为一个大的数字经济体，阿里巴巴在业务与技术交融的倒退过程中也经验了三个阶段。 第一阶段，向技术要效力。那时候，企业面对的是如何将技术自动化，实现技术自身的提效；第二阶段，不仅向技术要效力，还要思考技术如何更加高效地去撑持业务。于是，中台的概念被提了进去；第三阶段，也就是这两年，阿里心愿顶层策略能够顺利传达到业务和技术团队，特地在意业务和技术的协同，开始探讨如何通过办法和工具，将技术和业务的协同造成标准化的实际。开发工具自身是为了帮忙一线同学晋升幸福感和效率。作为开发者，关怀的是如何可能专一而高效地工作、高效开发和测试，但更重要的是，保障本人做的是正确的事。 当初有一个趋势：做底层研发的越来越少，软件研发的形式和习惯在发生变化。 当初，开发做的不再是一个通用工具，而是要随着业务一直演变。 为什么肯定要从DevOps走向BizDevOps？如上文所述，作为放慢金融服务智慧再造的重要组成部分，BizDevOps成为重塑智能高效的服务流程的外围能力组成。但BizDevOps也不是重整旗鼓，而是DevOps的天然扩大，从突破IT外部的墙，到突破IT与业务的墙。 DevOps于2009年被提出，次要是为了突破Dev与Ops的墙。过后的墙还是比拟显著的。Dev关注的是快，对象是代码，Ops关注的是稳，对象是机器。两者指标人造有矛盾，部门墙由此建设起来，这当然不利于IT 价值的最大化。 2009 年，在美国举办的第二届Velocity大会上，来自Flickr 公司的John Allspaw和Pauk Hammond发表了一个演讲《10+ Deploys Per Day: Dev and Ops Cooperation at Flickr》。在这个演讲中，Allspaw和Hammond以角色扮演的形式，活泼地体现了开发与运维之间的各种抵触。演讲中呈现很多金句，如“It's not my code, it's your machines!”，这粗浅反映了Dev和Ops关系的现状。接着，他们又展现了开发团队（Dev和运维团队（Ops如何通力合作，借助工具打消单方间的壁垒。 这次演讲是DevOps倒退历程中的标志性事件。它提出了正确的问题：为了更快交付和实现价值，必须弥合开发和运维之间的鸿沟，并给出了解决方案：为了弥合开发和运维之间的鸿沟，须要在文化、工具和实际方面的系列改革。 而在明天的大环境下，咱们面临着一个新的问题：如何买通业务（Biz）与开发运维（DevOps）之间的墙，以更好地应答数字经济下的挑战。 仍以阿里为例，明天阿里的中台也面临两个问题。第一个是协同问题，阿里中台自身是一个大部门，大的业务线和小的业务线从前台传递到中台有优先级，但大家都感觉本人很重要，这就是一个典型的大型企业协同问题。第二个问题就是如何不让技术、中台自身成为瓶颈。阿里心愿业务能够本人去做技术，这样有价值的想法和翻新能够失去最快的响应。 “你们团队是业务主导还是产品主导？”技术人都不心愿被当作资源去做事，而是心愿能够和业务单干以达到业务胜利。其实，业务和技术应该是共生单干的关系。 在批发和金融行业，这种关系比拟显著。比方银行的业务占绝大多数，大略有90%，如果有业务研发一体化的零碎，技术能够满足更多的业务诉求，那么业务就能更快地实现工作。 如何落地 BizDevOps？DevOps静止还没完结，仍在持续倒退。DevOps静止有很多能够给BizDevOps借鉴的中央。 首先，是在指标上进行对立。DevOps为了对立指标，借鉴了精益治理、麻利治理、看板等工作办法，买通了整个DevOps流程，产生了十分好的对于治理办法的驱动。其次，DevOps在开发和运维之间找到了共同点。大家关注的是利用，以利用为核心去做开发，演变成了阿里和微软的OAM模型。因而，既要有理念和办法上的扭转，还要用技术手段来解决问题，这是咱们须要从DevOps静止中学习和借鉴的。 那么，业务和技术的独特指标是什么？在流程中有什么独特关注的货色？独特的指标、独特的关注点，无效的技术或者工程实际，是BizDevOps落地的要害。 首先，要把业务、DevOps对立起来，对立语言十分重要。业务和技术有墙是失常的，因为业务间自身可能就有割裂。以银行为例，每个部门画图的规范不一，对立业务的语言就有难度。业务之间先对立语言，而后和IT用对立的语言沟通，而后对立数据和业务。从根底语法到长期熟练地应用语法，制订业务规范、数据规范，行业上下游企业定义好规范，这个过程的整合须要工夫。 对于软件行业来说，DevOps代表第一生产力，数据代表软件下的生产资料。DevOps倒退多年，相对来说曾经很成熟，因而成为疾速迭代、试错的试验零碎。在曾经有这套零碎的状况下，Biz就更应该好好利用这个零碎。 当初，能够把Biz放在DevOps后面，后续也能够把Biz放在DevOps前面。这意味着业务不是拍脑袋做的，而是有数据验证的。Biz、Dev、Ops这三个单词不应该是在一条线上，而应该是一个环，退出数据这个生产因素之后，咱们能够用试验精力来发明一些商业机会。 以后能做的是，借鉴DevOps的教训，有肯定的工具来承载最佳实际和办法，固化到流水线上帮忙落地。 有的企业搭了一下就感觉本人在做DevOps实际了，其实咱们还是要有更高的谋求。从文化上解决和扭转工作形式，短期内是无奈做到的，更加正当的形式是去造就复合型人才。DevOps让开发要懂测试，DevSecOps让开发要懂平安，Biz加进来当前，开发人员也要懂业务。事件没方法一步到位，兴许在过渡期中，一个比拟好的形式就是产学研联结去造就复合型的人才。 最初依然要强调一下，BizDevOps最大的机会点还是在需要自身，在构建数字化的生态自身。 BizDevOps的产品应该如何打造？特斯拉的Elon Musk曾说 ，“比起造汽车来说，设计这条流水线的难度是它的100倍。”那么，如何做能力把BizDevOps的流水线做进去？ 阿里云云效平台负责人陈鑫提到，在服务泛滥云效客户的过程中发现，科技部门对于DevOps比拟有共识，同时也欣然接受。例如大家都会了解一体化研发运维平台、走向云原生这样的一些概念和说法，DevOps的规范和办法实际都在逐渐收敛以适配开发者需要。 然而，业务部门还齐全没有达成这种共识。现状是只解决技术部门的效率问题，很难扭转业务的翻新效率问题。如果有一个工具能够让业务看到工程流动和业务之间的关系，那么业务部门就能够作出判断和口头。很多企业有十分多的工具能够用，但没有能够实现数字化指标的工具。 打造BizDevOps工具有很多难点。比方目前市面上有很多DevOps工具，但企业还是会再造一个工具，为什么？因为各个工具的数据模型并不统一。因而要想打造一个BizDevOps平台，首先要保证数据统一。大家对一些最根底概念的认知要拉齐。以后不同的人对于“利用”的定义和了解都是不一样的，如何能造成通用标准？ 另外，DevOps须要不同的人合作，BizDevOps作为一个工具或者平台，如何让多个角色有对立的视角，防止相互传递各自视角的信息导致低效，也是十分要害的。此外，工具不是为了扭转而扭转，工具是用来解决问题的，工具自身不能对用户的状态进行假如，必须适配用户在各种条件下的状态。而研发本身也须要做数字化转型。研发过程中也会产生数据，产品研发自身实现数字化转型，能力更好地撑持更大的数字化转型。 整体来说，BizDevOps在概念、流程、办法上如何标准化，须要业内一起致力，独特推动在产品上的落地。 如果BizDevOps真得产生，将来会如何？BizDevOps对业务的翻新速度和有效性会产生很大的作用，数据会变成基本常识，业务和开发之间的别离也会模糊起来。肯定会有局部业务人员违心往开发上凑近。开发人员形象剖析问题的劣势也会给业务人员带来很多的价值。 未来的业务更多是从用户的视角去买通链路，建设实质的认知和数字化模型。所有业务数据化，所有数据业务化。业务可能以更天然的形式向研发过渡。一个人的职业倒退方向也能够有比拟大的抉择，人才培养上也会有一些变动和翻新。 如果BizDevOps真的产生了，可能业务之外的组织上的各个function会成为最大瓶颈，其余BU的决策过程可能都要做相应的调整。将来，企业必定要跟着BizDevOps做转型。 下一步，咱们怎么做？通过深度研究，产学研6位专家在时代挑战与时机、BizDevOps重要性与必要性、落地办法与形式上达成了共识。他们心愿围绕BizDevOps的探讨不仅仅停留在这个层面，而是能够持续从产学研界的共同努力着手，推动BizDevOps真正产生，为软件产业的改革贡献力量。 因而圆桌会后，6位老师独特起草了一份《BizDevOps口头倡议书》并联名签订，这意味着接下来，产业、学术、钻研等各方将进行长期的合作和致力，独特推动软件构建与交付形式的改革。 《BizDevOps口头倡议书》扫描件首页 《BizDevOps口头倡议书》扫描件尾页 如果这篇文章对您或者团队有启发，欢送转发给更多人，点击下方链接观看《BizDevOps：数字化转型浪潮下技术破局之路》直播回放，也欢送退出 BizDevOps 交换钉钉群，群号：44686237。 直播回放地址：https://developer.aliyun.com/... ...

作者：孙健波，曾庆国 KubeVela 是一个现代化的软件交付管制立体，指标是让利用的部署和运维在现在的混合多云环境下更简略、麻利、牢靠。自 1.1 版本公布以来，KubeVela 架构上人造买通了企业面向混合多云环境的交付难题，且围绕 OAM 模型提供了充沛的可扩展性，博得了大量企业开发者的青睐，这也使得 KubeVela 的迭代速度一直放慢。 1.2 版本咱们公布了开箱即用的可视化控制台，终端用户能够通过界面公布和治理多样化的工作负载；1.3 版本 的公布则欠缺了以 OAM 模型为外围的扩大体系，提供了丰盛的插件性能，并给用户提供了包含 LDAP 权限认证在内的大量企业级性能，同时为企业集成提供了微小的便当。至今为止，你曾经能够在 KubeVela 社区的插件中心里取得 30 多种插件，其中不仅蕴含了 argocd、istio、traefik 这样的 CNCF 出名我的项目，更有 flink、mysql 等数据库中间件，以及上百种不同云厂商资源可供间接应用。 在这次公布的 1.4 版本中，咱们围绕让利用交付更平安、上手更简略、过程更通明三个外围，退出了包含多集群权限认证和受权、简单资源拓扑展现、一键装置管制立体等外围性能，全面加固了多租户场景下的交付安全性，晋升了利用开发和交付的一致性体验，也让利用交付过程更加透明化。 外围性能解读开箱即用的认证和受权，对接 Kubernetes RBAC，人造反对多集群在全面解决了架构降级、扩展性等挑战之后，咱们察看到利用交付的安全性是现在整个业界亟需解决的难题。从接触到的用户案例中，咱们发现许多安全隐患： 大量用户在应用传统 CI/CD 的过程中，会间接将生产集群的 admin 权限嵌入到 CI 的环境变量里，只对最根本的交付到哪些集群有肯定的权限拆散。而 CI 体系通常也会被密集的用于开发和测试，很容易引入不受管制的危险。中心化的治理加上粗粒度的权限管制，一旦 CI 体系被黑客攻击、或者呈现一些人为误操作，很容易产生微小的破坏性，结果不堪设想。大量 CRD 控制器依赖 admin 权限对集群资源进行操作，且没有对 API 的拜访进行束缚。尽管 Kubernetes 自身具备丰盛的 RBAC 控制能力，然而因为学习权限治理门槛较高、且与具体性能实现无关，大多数用户并不真正关怀其中细节，通常只是抉择默认的配置便投入生产应用。灵活性较高的控制器（如可能散发 Helm Chart），很容易成为黑客攻击的靶子，比方在 helm 中嵌入一个 YAML 脚本窃取其余命名空间中的秘钥。KubeVela 1.4 中退出了认证和受权能力，且人造反对多集群混合环境，对于每一个 KubeVela 的平台管理员而言，他们不仅能够细粒度的定制任意的 API 权限组合、对接 Kubernetes RBAC 体系，将这些权限模块受权给开发者用户，严格限度其权限；还能够简便的应用 KubeVela 平台预置的权限模块，如间接授予用户某个集群的特定命名空间权限，授予某个用户“只读”权限等，极大的简化了用户的学习老本和心智累赘，全面加固了利用交付的安全性。对于应用 UI 的用户，零碎针对我的项目可用的资源范畴和类型主动实现底层受权并严格校验，从而使得业务层 RBAC 权限与底层 Kubernetes RBAC 体系买通并协同工作，做到从外到内的平安，不在任何环节扩充权限。 ...

是否胜利建网站，是小白走向成熟的一个要害动作。搭建网站个别要弄懂三个问题：域名、网站源码和服务器。 域名很好了解，它就像“手机号”一样举世无双，能够让他人找到你的网站。那如何能一步到位解决网站源码和服务器问题呢？ 这篇文章让你不必思考服务器和网站源码，应用 Serverless 1 分钟轻松搭建你的第一个集体网站。 Serverless 建站无需再思考服务器问题建站申请服务器是很多人的第一个卡点，你须要： 1、比照服务器厂商； 2、抉择服务器配置； 3、购买服务器； 4、服务器备案； 5、装置服务器。 你想着先买个 9.9 的服务器用着玩玩吧，然而接下来你将面临着更多问题，比方存储空间大小、IIS 并发数、CPU 限度率、数据库反对、流量限度、可安装程序反对、网站程序反对、等等。忽然就感觉刚到手的 9.9 服务器套餐不香了…… 那能不能跳过宜人的服务器，只关注代码局部就轻松领有一个集体网站呢？ 当然能够！ 你能够应用 Serverless 技术，阿里云函数计算产品（一个事件驱动的全托管 Serverless 计算服务）。您无需治理服务器等基础设施，只需编写代码并上传，函数计算会为您筹备好计算资源，并以弹性、牢靠的形式运行您的代码，轻松帮你解决服务器的运维治理问题。 收费额度，不便体验函数计算每月为用户提供肯定的收费额度（每月约46元，年度总计约552元）。用户的阿里云账户与 RAM 用户共享每月收费的调用次数和执行工夫额度。收费额度不会按月累积，在下一天然月的起始时刻，即 01 号零点，会清零而后从新计算。 体验有奖当初加入“1分钟 Serverless 极速搭建真网站” ，实现即有机会取得天猫超市代金券！ 流动地址（倡议 pc 端体验）： https://developer.aliyun.com/... 1 分钟阿里云函数计算搭建集体网站教程如果刚开始第一次建站，十分倡议从博客站开始，因为博客站是最简略易于上手的，个别开源收费的博客程序有很多，国内国外都有，国外大家最相熟的就是 wordpress 了，国内有 Zblog 等。 本次试验将以搭建 Zblog 博客为例，让各位感触函数计算建站和网站保护的低成本、免运维、高可用等劣势。Zblog 是一款玲珑而弱小的基于Asp平台的 Blog 程序。十分利于老手操作，能够疾速搭建属于本人的网站。 线上体验地址： https://developer.aliyun.com/... 搭建集体网站： 进入到函数计算控制台： https://fcnext.console.aliyun... 点击左侧的利用按钮： 注：如果之前应用过利用核心，点击利用之后呈现相似于上面的页面： 此时能够点击“创立利用”按钮持续流程。 点击利用/创立利用之后，能够看到利用列表，此时抉择“Zblog”即可： 抉择立刻创立，而后抉择间接部署： 此时还须要关注页面上角色名称局部，例如： 此时须要点击返回受权进行受权，受权实现可能会提醒： 还须要持续点击返回受权： 实现之后点击页面最上面的创立按钮： ...

作者：Seata社区 社区简介Seata 是一款开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简略易用的分布式事务服务。在 Seata 开源之前，Seata 在阿里系外部始终扮演着分布式数据一致性中间件的角色，简直每笔交易都要应用 Seata，帮忙业务安稳的度过历年的双11洪荒流量，对业务进行了无力的技术撑持。2019.1 为了打造更加欠缺的技术生态和普惠技术成绩，Seata 正式发表对外开源，Seata 将以社区共建的模式帮忙用户疾速的落地分布式事务解决方案。短短3年间，Seata 社区曾经播种了 22k star 和超 300 名 contributor，建立了一大批企业标杆用户，成为了分布式事务畛域的事实标准。  GitHub：https://github.com/seata/seata 官网：https://seata.io/zh-cn/ Seata 社区往年联结了开源之夏，阿里巴巴编程之夏和 CCF GitLink 编程夏令营发动了面向高校学生的暑期编程流动。 开源之夏目前已进入正式编程阶段，本文将不再过多介绍，详情参考： https://mp.weixin.qq.com/s/q6... 开源之夏我的项目当选状况请参考： https://summer-ospp.ac.cn/#/o... 目前依然有阿里巴巴编程之夏ASoC和CCF GitLink编程夏令营可承受提案的申请，如果你是在校生满足相应的申请条件，连忙来申请吧。这里有社区资深的导师提供 1v1 的业余领导，也有丰富的奖金等你来拿。 阿里巴巴编程之夏是什么 Seata 社区往年再度与阿里巴巴编程之夏携手，并筹备了 3 项精选我的项目课题，欢送同学们申请！ 我的项目一：事务状态数据的长效存储目前 Seata 的事务 Session 和 undolog 数据尽管会长久化，然而事务 Session 和 Undolog 会随着全局事物的生命周期定期删除，咱们须要一个日志流水将这些 Session 和 Undolog 的进行长久化存储，因为事务 Session和Undolog 是 Seata 重要的状态数据，数据的⻓工夫长久化存储对于数据的剖析有重要的意义。次要工作如下： 1、发送层设计。为了不影响 Seata 事务主流程的性能，记录事务 Session 和 Undolog 数据须要采纳异步的形式，最好的形式就是利用音讯队列，目前音讯队列有很多种，比方RocketMQ、Kafka 等，为了屏蔽音讯队列的具体实现，Seata 须要设计出一套通用的发送接口层，有具体的音讯队列实现，并且由 Seata 启动时通过读取用户配置加载具体实现。最初通过此接口实现能够把事务 Session 和 Undolog 发送到音讯队列中。 ...

作者：宇曾 背景软件技术的倒退历史，从单体的利用，逐步演进到分布式应用， 特地是微服务理念的衰亡，让大规模、高并发、低提早的分布式应用成为可能。云原生时代下，微服务框架自身也在一直地进化和迭代演进。 微服务框架个别会波及到以下几个知识点： 本文咱们着重探讨以下三大微服务框架： SpringCloudDubboServiceMesh （新生代）这三款不同的框架对服务治理畛域的性能点覆盖度弱有差别。本文不着重探讨这几个框架的谁优谁劣，次要来探讨下如何从传统的微服务框架 Dubbo 、SpringCloud 无缝过渡到 ServiceMesh 架构。当下 ServiceMesh 畛域最炽热的我的项目非 Istio 莫属。 阿里云服务网格 ASM 基于 Istio ，对 Istio 进行了云上托管和适配，并且新增了相干性能，以及大规模服务网格场景下的性能优化等。作为业内首个全托管 Istio 兼容的阿里云服务网格产品 ASM，一开始从架构上就放弃了与社区、业界趋势的一致性，管制立体的组件托管在阿里云侧，与数据面侧的用户集群独立。ASM 产品是基于社区 Istio 定制实现的，在托管的管制面侧提供了用于撑持精细化的流量治理和平安治理的组件能力。通过托管模式，解耦了 Istio 组件与所治理的 K8s 集群的生命周期治理，使得架构更加灵便，晋升了零碎的可伸缩性。从 2022 年 4 月 1 日起，阿里云服务网格 ASM 正式推出商业化版本, 提供了更丰盛的能力、更大的规模反对及更欠缺的技术保障，更好地满足客户的不同需要场景, 详情可见产品介绍： https://www.aliyun.com/produc... 上面咱们一起来看下传统微服务迁徙到服务网格技术栈会有哪些已知问题，以及阿里云服务网格 ASM 又是如何无缝反对 SpringCloud 、Dubbo 这些服务的。 关注【阿里云云原生】公众号，回复关键词【0621】获取文中代码压缩包下载地址！ 传统微服务迁徙到服务网格的一些已知问题和场景常见的几个问题服务容器化后，服务 deployment 滚动更新，服务实例的 IP 是常常变动的，对应服务实例IP 同步到注册核心会有提早，这个过程会导致局部业务申请呈现 503。Istio 社区版本对非 HTTP 、gRPC 的其余 rpc 协定反对无限,无奈提供对立状态的路由治理，以及相干治理能力。因 Istio 自身设计的服务路由模型依赖服务间申请为 ServiceName 或 ClusterIp ，SpringCloud 服务没有方法间接 Mesh 化，Dubbo 服务因基于 interface 的服务调用设计，interace 在 Dubbo 协定申请的上下文有传递，尽管不受该模式的限度，但 Istio 社区版本对 Dubbo 路由的反对却没有对应的 RDS 反对，无奈间接采纳社区版本的 VirtualService 配置 Dubbo 路由。除了以上一些常见问题，还有一些具体的业务场景在业务云原生化过程中常常遇到。 ...

作者：CSDN云原生 近日，阿里云 aPaaS&Serverless 前端技术专家袁坤在 CSDN 云原生 meetup 长沙站分享了 Serverless 在阿里云函数计算 FC 的实际。 互联网软件架构演进咱们先简略回顾下互联网软件架构的演进之路。 单机部署在单机部署中，将所有的业务和数据库都部署在一台主机中。 此架构的长处是：开发、部署以及运维都非常简单。毛病是：一旦遇到流量过大或者机器故障，整个零碎瘫痪，甚至失落业务数据，造成微小业务损失。 集群化部署针对上述架构问题，罕用的解决方案是采取程度扩容的形式进行集群化部署。引入 SLB 的流量网关路由，进行负载平衡。集群化部署实质上是单体架构，开发人员在我的项目开发的时候须要额定留神，比方要应用 cookie 进行鉴权，session 就不能存储在本地，须要引入 Redis 进行独自存储。集群化部署能够通过疾速程度扩容解决流量突增或机器故障的问题。 微服务拆分随着业务的倒退以及团队规模的扩张，单体架构这样紧耦合的形式会带来越来越多的问题，架构的灵活性和可扩展性成为妨碍业务倒退的重大挑战。微服务架构应运而生。 比照单体架构，微服务架构远比其简单，也衍生了很多新技术，比方：API 网关、服务注册、服务发现、RPC 通信。 Serverless 架构从单体架构到微服务架构，从单机部署到集群化部署，互联网软件架构越来越简单，公司须要投入大量精力和老本进行底层技术的降级和保护。下图是 Serverless 架构，和单体架构不同的是将对应的组件换成 Serverless 云产品。 技术演进的实质是更好服务业务，传统开发方式使企业破费更多的精力打磨底层技术细节，而 Serverless 架构就是让开发者专一业务实现从而发明更大的业务价值。 Serverless 架构的劣势很显著： 不关注底层基础设施，专一业务价值发明主动弹性，从容面对突增流量按资源应用计费，防止资源闲置节约Serverless 架构探讨先来看一下 FaaS 的执行过程。蓝色局部是用户手动治理，只须要交付代码，其余的启动、运行、运维等都是在 FaaS 平台进行。 然而此架构会产生一些问题： 代码碎片化，无奈对立治理和部署本地环境和线上环境不统一，无奈解决依赖兼容性问题进行本地 Debug 和线上调试艰难FaaS 厂商对代码包有限度，无奈部署大代码包没有对立的规范，导致厂商锁定问题Serverless Devs针对上述问题，Serverless Devs 能够帮忙开发者更好地开发治理 Serverless 利用，它具备以下几个特点： 无厂商锁定，Serverless Devs 帮忙开发者将利用部署在各个厂商下面开源凋谢，代码逻辑无任何黑洞性能可插拨，Serverless Devs 通过组件的模式提供，开发者齐全能够依据需要，疾速开发适宜本人的工具套件我的项目全生命周期治理能力，Serverless Devs 是用户进行我的项目初始化创立、开发、调试、部署等全生命周期治理的工具，简化 Serverless 利用开发如果说 Serverless 架构能够帮忙开发者开发利用，那么 Serverles Devs 就是帮忙 Serverless 开发者更好地开发 Serverless 利用！Serverless 架构实际Serverless Devs 官网实际通过下面的介绍能够看出 Serverless Devs 开发者工具并没有提供业务，业务的实现由组件提供，而组件自身扩散在不同的 GitHub 仓库中。 ...

作者：文婷、不周 本篇文章次要介绍阿里云音讯队列 RabbitMQ 版的可观测性能。RabbitMQ 的可观测能力绝对开源有了全面的增强，为业务链路保驾护航。音讯队列 RabbitMQ 简介阿里云音讯队列 RabbitMQ 版是一款基于高可用分布式存储架构实现的 AMQP 0-9-1 协定的音讯产品，兼容开源 RabbitMQ 客户端，解决开源各种稳定性痛点（例如音讯沉积、脑裂等问题），同时具备高并发、分布式、灵便扩缩容等云音讯服务劣势。 阿里云音讯队列 RabbitMQ 的可观测能力绝对开源有了全面的增强，那么什么场景下能够用到可观测能力呢？ 为什么须要弱小的可观测能力随着分布式和云原生架构的衰亡，零碎的可观测性在问题排查、零碎运维，甚至业务经营方面起到越来越重要的作用。 场景一：线上音讯生产有异样，音讯不能及时被解决，须要及时收到报警，并疾速定位问题； 场景二：线上某些订单状态有异样，须要排查对应的音讯链路环节是否失常发送音讯； 场景三：须要剖析音讯流量变化趋势、流量散布特点或音讯体量，进而进行业务趋势剖析布局； 场景四：须要查看和剖析利用上下游依赖拓扑状况，进行架构降级优化或革新。 音讯队列 RabbitMQ 可观测能力联合上文的内容，上面具体对阿里云音讯队列 RabbitMQ 的可观测性的两个外围性能进行介绍。 外围劣势可观测 Dashboard 大盘1、优化性能，具备超强稳定性； 2、一键开箱，升高搭建老本； 3、出现清晰，问题资源一眼可见。 可观测音讯轨迹**1、可实现多种问题场景的筛查和搜寻能力； 2、反对图形化展现简单的轨迹信息，应用更加便捷。 可观测 Dashboard 大盘利用场景应用 Prometheus 监控服务和 Grafana 的指标存储和展现能力，音讯队列 RabbitMQ 版为企业版和铂金版实例提供 Dashboard 大盘性能。通过该性能，您能够查看实例、Vhost、Queue 和 Exchange 的各种指标数据，帮忙您及时发现和定位问题。 性能特点1、多维度组合查问能力：能够从集群、Vhost、Exchange、Queue 多维度聚合查问数据； 2、排序能力：同一指标下，资源依照健康状况倒序排序，一眼看到集群中最有问题的资源； 3、丰盛的指标数据：音讯量、连接数、沉积量、要害接口申请数据等。 可观测音讯轨迹利用场景如果音讯收发不合乎预期，您能够通过查问音讯轨迹，疾速剖析历史音讯收发详情和定位问题起因，及时复原业务。 性能介绍1、查问能力 按 Queue 查问：查问肯定工夫范畴内，Queue 上的所有音讯的轨迹。实用于只晓得音讯发送到的 Queue，不晓得发送音讯时设置的 Message ID 的含糊查问场景。按 Message ID 查问：依据 Message ID 的准确查问指定音讯。Message ID 设置为和业务相干的惟一 ID。按音讯解决耗时：依据音讯解决耗时（音讯投递给消费者开始工夫到消费者解决实现返回应答的工夫）大于指定工夫来查问音讯轨迹。2、轨迹内容 ...

作者： 鲁严波 从 Java Agent 报错开始，到 JVM 原理，到 glibc 线程平安，再到 pthread tls，逐渐探索 Java Agent 诡异报错。 背景因为阿里云多个产品都提供了 Java Agent 给用户应用，在多个 Java Agent 一起应用的场景下，造成了总体 Java Agent 耗时减少，各个 Agent 各自存储，导致内存占用、资源耗费减少。 MSE 发动了 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-15 06:22:47 [oneagent plugin arms-agent start] ERROR c.a.o.plugin.PluginManagerImpl -start plugin error, name: arms-agentcom.alibaba.oneagent.plugin.PluginException: start error, agent jar::/home/admin/.opt/ArmsAgent/plugins/ArmsAgent/arms-bootstrap-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 ahas-java-agent start] ERROR c.a.o.plugin.PluginManagerImpl -start plugin error, name: ahas-java-agentcom.alibaba.oneagent.plugin.PluginException: start error, agent jar::/home/admin/.opt/ArmsAgent/plugins/ahas-java-agent/ahas-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 报错了。 ...

作者： 江昱 前言2022 年 6 月 15 日，信通院在中国信通院云原生产业大会上公布《基于无服务器架构的工具链能力要求》规范，至此寰球首个云原生 Serverless 凋谢工具链模型正式公布！Serverless Devs [ 1] 作为开源凋谢的开发者工具积极参与工具链模型建设，为建立行业畛域对立标准施展出助推作用。 随着云计算倒退，以及云原生热度的攀升，Serverless 架构锋芒毕露且发展势头迅猛。不仅被更多开发者所关注，市场占有率也逐年进步。然而，业内各平台提供的 Serverless 服务存在较大差别，无形中减少了用户的学习、开发、调试、移植老本。各大云厂商和开源框架所能提供的 Serverless 服务（无论从能力范畴还是从产品状态、应用体验等方面）却不尽相同，因而许多开发者在抉择应用 Serverless 之初，最大的担心便是厂商绑定问题。 在 2021 年中国信息通信研究院公布的《中国云原生用户考察 2021》数据中明确提及：在驳回 Serverless 技术前，31.69% 的用户会思考厂商绑定问题，30.62% 的用户思考相干工具集的欠缺水平。 这些数据背地走漏的实际上是：开发者对于欠缺工具链的强烈需要和渴望。 基于这一景象，中国信通院公布的寰球首个云原生 Serverless 凋谢工具链模型，旨在交融不同实现形式之间的差别，形象出一套卓有成效的工具链标准，对立 Serverless 利用全生命周期的操作体验，驱动 Serverless 技术的标准化倒退与宽泛落地。 Serverless 凋谢工具链模型Serverless Devs 作为开源凋谢的开发者工具，自其立项始，便以晋升 Servelress 利用研发效力为指标，以让 Serverless 架构更好用、更易用为准则，冀望在 Serverless 利用全生命周期施展出重要作用。 Serverless Devs 不仅仅在工具链定位层面和信通院所公布的模型思路吻合（都是心愿通过对 Serverless 利用全生命周期治理能力的建设，助力开发者研发效力晋升，升高学习老本，晋升应用幸福感），在性能反对层面以及工具链产品状态上，也与该模型高度一致。 模型解读此次信通院所公布的《基于无服务器架构的工具链能力要求》规范，是对 Serverless 架构工具链体验层的标准与对立，做出规约。此举能够升高用户的应用与迁徙老本，有助于屏蔽不同实现形式之间的差别，进而推动无服务器架构技术的广泛应用。 （中国信通院公布） 《基于无服务器架构的工具链能力要求》：从能力框架动手，通过接入范畴、应用办法、操作模式等几个方面，对 Serverless 工具链的根本状态进行了规约；通过初始化配置、利用开发、利用调试、利用打包、部署公布以及利用下线几个阶段，对 Serverless 工具链的能力范畴，即全生命周期治理能力进行了更为粗疏的规约； 最初通过对撑持能力（包含不限于受权治理、触发治理、利用治理、运维治理、研运治理等几个方面）以及凋谢能力（包含不限于拓展开发、组件治理等几个方面）进一步对 Serverless 工具链的具体状态，所需性能进行了相干的形容。 通过该模型，各个平台所提供的 Serverless 开发者工具将趋于对立，更为标准。 ...

618 大促正在热火朝天进行中。《618大促来袭，浅谈如何做好大促备战》一文介绍了全方位保障大促高可用的方法论和技术手段，本文持续围绕网关，深入探讨大促场景下，如何做好网关高可用防护，将从以下几点逐个开展介绍： 网关做高可用防护的重要性MSE 云原生网关的“下一代网关架构”，在高可用防护上的微小劣势应用 MSE 云原生网关的高可用防护实战（视频演示）网关做高可用防护的重要性大促场景下，应用网关做高可用防护为什么重要？一言以蔽之，网关具备将大促的各种不确定性因素转化为确定性因素的能力，并且这种能力是不可代替的。别离从三个方面来看： 第一点是应答流量峰值的不确定性，必须通过限流规定将不确定的流量变为确定。业务服务模块本人做限流很难实现这一点。因为实现限流防护有个前提，承载这突发流量的服务仍能放弃失常的 CPU 负载。业务服务模块即便实现了应用层的 QPS 限流，在刹时高并发场景下，仍可能因为网络层大量的新建连贯导致 CPU 猛涨，限流规定也就形同虚设了。业务模块应该专一在应用层业务逻辑上，若要通过扩容去应答其不善于的网络层开销，所需的资源老本是相当高的。而网关作为业务流量入口的位置，决定了其必须善于应答高并发的网络流量，并且这块性能也是掂量网关能力的一个重要指标，应答高并发的性能越强，所需的资源老本就越低，将大促流量从不确定变为确定的能力就越强。 第二点是应答用户行为的不确定性，须要依据不同的大促场景，模仿用户行为进行多轮压测演练，提前发现零碎的瓶颈和优化点。网关既是用户拜访的流量入口，也是后端业务应答的最终进口。这决定了网关是模仿用户行为进行流量压测的必经一站，也决定了是观测压测指标评估用户体验的必须环节。在网关上边压测，边察看，边调整限流配置，对大促高可用体系的建设，能够起到事倍功半的成果。 第三点是应答平安攻打的不确定性。大促期间也通常是黑灰产沉闷的工夫，异样的刷单流量很可能触发限流规定，从而影响失常用户的拜访。基于网关的流量平安防护能力，例如 WAF 等性能，通过辨认出异样流量提前拦挡，以及将异样 IP、cookie 主动退出黑名单等伎俩，既能够使这部分流量排除在限流阈值之外，也能够保障后端业务逻辑平安。这也是大促高可用防护必不可少的一环。 MSE 云原生网关的劣势架构劣势MSE 云原生网关实现了流量网关、微服务网关、平安网关三合一的“下一代网关架构”，和常见的多层网关架构比照如下所示： 常见多层网关架构 在这个架构中，用 WAF 网关实现平安能力，SLB 实现负载平衡能力，Ingress 网关实现集群入口网关能力（非 K8s 场景也会部署一层 Nginx），Zuul 实现微服务网关能力。面对大促的突发流量，这样的架构下，须要对每一层网关都进行容量评估，每一层网关都是潜在的瓶颈点，都可能须要进行扩容。这样造成的资源老本和运维人力老本都是微小的。并且每多一层网关，就多一层可用性危险。 MSE 云原生网关架构 应用 MSE 云原生网关，在保留 SLB 作负载平衡的根底上，只通过一层网关就实现了集群入口网关、WAF 网关、微服务网关的全副能力。应答大促场景，运维人员只需专一在 MSE 网关这一层上，就能做好所有入口流量的治理，实现高可用防护。这就是“下一代网关架构”，让所有回归简略，唯有简略方可依赖。 性能劣势如下图所示，MSE 云原生网关的吞吐性能是 Nginx Ingress Controller 的一倍，具体的性能比照剖析能够参考《K8s 网关选型初判：Nginx 还是 Envoy？》一文。在大促的洪峰流量背后，网关的性能如果不够好，意味着企业要领取更多的 ECS 资源老本，同时还要为网关自身是否扛住流量操心，一旦“门神”失守，对业务造成的损失是不可估量的。 网关规格：16 核 32 G * 4 节点 ECS 型号：ecs.c7.8xlarge 高可用能力方面，MSE 云原生网关内置了 Alibaba Sentinel 高可用模块，历经多年双十一流量考验，提供了丰盛的限流防护能力，包含流控规定、并发规定、熔断规定，能够全面保障后端业务高可用；此外，MSE 云原生网关还具备流量预热能力，通过小流量预热办法，能够无效解决大促场景下，资源初始化慢所导致的大量申请响应慢、申请阻塞问题，防止刚扩容的节点无奈提供失常服务，影响用户体验。 ...

作者：高性能存储 SIG 容器化是最近几年 devops 界风行的趋势，通过业务的容器化咱们将创立一个齐全打包、自蕴含的计算环境，让软件开发人员可能更加疾速地创立和部署本人的应用程序。然而长期以来，因为镜像格局的限度，容器启动镜像的加载是很慢的，相干背景细节能够参考“容器技术之容器镜像篇”。为了减速容器的启动，咱们能够将优化后的容器镜像搭配 P2P 网络等技术，从而无效升高容器部署启动的工夫，并可保障容器继续稳固运行，“让容器利用治理更快更平安，Dragonfly 公布 Nydus 容器镜像减速服务”。 除了启动速度，镜像分层、去重、压缩、按需加载等外围个性在容器镜像畛域也尤为重要。然而因为没有原生的文件系统反对，大多数都抉择了用户态计划，Nydus 最后亦如此。随着计划和需要的一直演进，用户态计划遇到了越来越多的挑战，如性能与原生文件系统相比有较大差距、高密场景下资源开销较大等等。究其原因，次要是在用户态实现镜像格局的解析、按需加载等操作，将带来大量内核态/用户态通信开销。所以看起来解决了启动速度，这些外围性能的研发就会有不小的挑战，有点顾此失彼。 那么有没有可能做到鱼和熊掌兼得呢？为此，龙蜥社区做了一个大胆的尝试，咱们设计并实现了兼容内核原生 EROFS 文件系统的 RAFS v6 格局，心愿将容器镜像计划下沉到内核态 。 同时为了一劳永逸，咱们也尝试将这个计划推动到内核主线以让更多的人收益。最终，随着 Linux 内核各位大佬的挑战和咱们的不断完善，erofs over fscache 按需加载技术终于被合入 5.19 内核（链接见文末），至此 Nydus 镜像服务的下一代容器镜像散发计划逐步清晰起来。这也是 Linux 主线内核首个原生反对、开箱即用的容器镜像散发计划 ，容器镜像的高密、高性能、高可用和易用性从此不再是个问题！ 作者为此也给本人加了个鸡腿，哈哈！ 本文将从 Nydus 架构回顾、RAFS v6 镜像格局和 EROFS over Fscache 按需加载技术三个角度来别离介绍这一技术的演变历程，并通过比照数据展现了以后计划的卓越性能，心愿大家可能尽早享受到容器启动飞一样的体验！ Nydus 架构回顾一句话总结一下，Nydus 镜像减速服务是一种优化了现有的 OCIv1 容器镜像架构，设计了 RAFS (Registry Acceleration File System) 磁盘格式，最终出现为一种文件系统的容器镜像格局的镜像减速实现。 容器镜像的基本需要，实质上是为了提供容器的根目录 (rootfs) ，这能够通过文件系统 (file system) 或者是归档格局 (archive format) 来承载，当然也能够在文件系统的根底上二次套娃 (例如通过自定义的块格局来承载)，但实质载体是一个目录树，体现为文件接口。 先看一下OCIv1 规范镜像，OCIv1 格局是一种基于 Docker Image Manifest Version 2 Schema 2 格局的镜像格局标准，由 manifest、镜像索引 (optional)、一系列容器镜像层及配置文件组成，细节能够参见相干文档，本文不再赘述。实质上说 OCI 镜像是一个以层为根本单位的镜像格局，每个层存储了文件级别的 diff data，以 tgz 归档格局存储，如下所示： ...

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

随着企业 IT 数字化转型演变过程，越来越多的企业采纳云原生化架构降级的形式，改善利用开发运维迭代的效率，减速企业业务翻新迭代，改良资源弹性治理和迁徙的效率，帮忙企业降本增效。然而因为云原生弹性、麻利和动静可扩大等个性，也为云原生软件供应链平安引入了新的挑战。 Salesforce 是创立于 1999 年 3 月的一家客户关系治理 (CRM) 软件服务提供商，可提供随需利用的客户关系治理平台。Salesforce 容许客户与独立软件供应商定制并整合其产品，同时建设他们各自所需的应用软件。在社交电商潮流席卷寰球的态势下，2022 年 1 月，Salesforcs 与阿里云联结公布了针对中国市场的软件“Salesforce 社交电商”，这是 Salesforce 与阿里云达成策略单干后在中国市场首发新品。该软件由阿里云托管的 Headless 电商中台产品，能治理和对立企业在 Web 网站、挪动 App 及小程序等多种渠道的电商利用，以取得客户的 360 度视图，从而进步客户体验和促成业务增长。 容器化 ISV 交付的平安挑战在进行容器化交付革新的过程中，以 Salesforce 为例的容器软件 ISV，须要解决云原生场景下环境复杂化、多样化等来的软件供应链危险挑战。为了保障软件从开发、交付到运行的顺利进行，整个软件供应链生存周期应在保障软件可用性、完整性、保密性根底上，升高软件供应链的平安危险，实现全链路可审计，可追溯，可自动化平安经营。为了实现这样的要求 ，在容器化交付革新过程中次要面临以下挑战： 三方及开源组件带来安全隐患：企业软件我的项目越来越趋于依附来自供应商三方或开源社区组件，该些组件常以根底镜像的形式在软件供应链里传递。攻击者可能利用组件中存在的破绽，注入恶意代码或管制第三方机器环境，执行从加密货币挖矿、发送垃圾邮件、到通过大型僵尸网络发动 DDoS 攻打。软件交付长链路埋下更多危险：从软件开发阶段的需要剖析、代码开发、集成、测试，到 ISV 交付阶段的特定渠道软件交付、终端客户验收，最初运行阶段的终端客户软件运行、经营和保护。整个软件供应链周期链路长，在各个环节中均可能存在平安危险，导致软件破绽、软件后门、歹意篡改、知识产权危险、信息泄露等平安威逼。容器化运行引入更多危险攻击面：容器利用部署依赖 Linux 内核个性，很多黑客攻击者利用内核系统漏洞，从容器运行时组件和容器利用部署配置等多个维度发动针对性的逃逸或者入侵攻打。最近几年 K8s、Docker、Istio 等开源社区都爆出了不少的高危破绽，这都给攻击者提供了可乘之机。整个软件供应链生存周期应在保障软件可用性、完整性、保密性根底上，升高软件供应链的平安危险，实现全链路可审计，可追溯，可自动化平安经营。保障从软件开发、交付到运行，整个软件供应链有纵深进攻的平安能力，一旦任何环节呈现问题，可能及时精确实现问题定位和追溯，辨认相干方危险并及时平安加固。 阿里云云原生软件供应链解决方案为了帮忙客户更便捷实际软件供应链平安，阿里云容器服务团队提供了端到端的解决方案。企业客户能够在跨企业交付或者企业内研发迭代场景，晋升平安治理效率及平安加固能力，实现全链路容器利用平安可信交付。 （容器化 ISV 交付场景） 在容器利用交付阶段，容器镜像服务 ACR  企业版提供了云原生利用交付链能力，交融访问控制、镜像构建、内容平安、二进制认证、全球化散发等能力，反对预置危险拦挡策略，实现发现即阻止、安全控制左移。 镜像内容平安，ACR 和云平安核心联结提供了增强型容器镜像扫描引擎，笼罩系统漏洞、利用破绽、基线查看及歹意样本等危险类型，具备高识别率、低误报率破绽扫描能力。同时，提供了容器镜像修复能力，反对自动化高效修复危险破绽，实现从发现到修复的平安闭环。镜像跨账号交付，针对企业间 ISV 利用交付场景，ACR 提供了跨账号同步能力保障容器镜像和签名的散发平安。ISV 将镜像及对应的签名信息通过 ACR 跨账号同步能力交付给 ISV 的客户实例下。对应的镜像开启了不可变镜像版本，确保镜像的版本不可笼罩。ISV 的客户在 ACK 上做镜像部署时，会基于 ISV 的公钥验签，确保镜像残缺且来自 ISV。在容器利用运行阶段，容器服务 ACK 在默认管控组件、零碎组件平安加固之上，提供了部署策略管理、平安巡检，保障容器利用一致性的安全策略。ACK 集成云平安核心提供了容器运行时安全监控和告警能力，笼罩 ATT&CK 杀伤链的 200 余项平安检测模型，晋升整体业务负载运行环境安全性。基于 ISV 利用运行场景，ACK 也提供了平安沙箱容器作为运行时解决方案，确保更好的平安隔离能力和更高的稳定性。 ...

作者： 张佐玮 李涛 2022 年 4 月，阿里云原生混部零碎 Koordinator 发表正式开源。通过了几个月的迭代，Koordinator 目前曾经陆续公布了 4 个版本，能够无效帮忙企业客户改良云原生工作负载运行的效率、稳定性和计算成本。 昨天（6 月 15 日），在阿里巴巴云栖直播间中，来自 Koordinator 社区的张佐玮(佑祎) 、李涛(吕风)两位技术专家从我的项目的架构和个性登程，分享了 Koordinator 是如何应答混部场景下的挑战，特地是晋升混部场景下工作负载的运行的效率和稳定性，以及对后续技术演进的思考与布局。咱们也将本次直播的核心内容进行了整顿，心愿能给大家带来一些深刻的启发。 点击链接，立刻查看直播回放！ https://yqh.aliyun.com/live/d... 关注阿里云云原生公众号，后盾回复【0615】获取残缺 PPT 混部技术的介绍和倒退混部的概念能够从两个角度来了解，从节点维度来看，混部就是将多个容器部署在同一个节点上，这些容器内的利用既包含在线类型，也包含离线类型；从集群维度来看，混部是将多种利用在一个集群内部署，通过预测剖析利用个性，实现业务在资源应用上的错峰填谷，以达到晋升集群资源利用率的成果。 基于以上的了解，咱们就能够明确混部须要解决的指标问题以及技术计划。实质上，咱们施行混部的初衷是源自对数据中心资源利用效率的不懈谋求。埃森哲报告显示，2011 年私有云数据中心的机器利用率均匀不到 10%，意味着企业的资源老本极高，而另一方面随着大数据技术的倒退迅速，计算作业对资源的需要越来越大。事实上，大数据通过云原生形式上云已成为了必然趋势，据 Pepperdata 在 2021 年 12 月的调查报告，相当数量的企业大数据平台曾经开始向云原生技术迁徙。超过 77% 的受访者反馈预计到 2021 年底，其 50% 的大数据利用将迁徙到  Kubernetes 平台。于是，抉择批处理类型工作与在线服务类型利用混合部署，就牵强附会的成为了业界通用的混部计划选型。公开数据显示，通过混部，相干技术当先企业的资源利用率失去了大幅晋升。 面对混部技术，在具体关注的问题上，不同角色的管理人员会有各自的侧重点。 对于集群资源的管理员来说，他们冀望能够简化对集群资源的治理，实现对各类利用的资源容量，调配量，使用量的清晰洞察，晋升集群资源利用率，以达到升高 IT 老本的目标。 对于在线类型利用的管理员来说，他们则更关注容器混合部署时的相互烦扰的，因为混部会更容易产生资源竞争，利用响应工夫会呈现长尾（tail latency），导致利用服务质量降落。 而离线类型利用的管理员更冀望混部零碎能够提供分级牢靠的资源超卖，满足不同作业类型的差异化资源品质需要。 针对以上问题，Koordinator 提供了以下机制，能够充沛满足不同角色对混部零碎的技术需要： 面向混部场景的资源优先级和服务质量模型稳固牢靠的资源超卖机制细粒度的容器资源编排和隔离机制针对多种类型工作负载的调度能力加强简单类型工作负载的疾速接入能力Koordinator 简介下图展现了 Koordinator 零碎的整体架构和各组件的角色分工，其中绿色局部形容了 K8s 原生零碎的各个组件，蓝色局部是 Koordinator 在此基础上的扩大实现。从整个零碎架构来看，咱们能够将 Koordinator 分为核心管控和单机资源管理两个维度。在核心侧，Koordiantor 在调度器外部和内部别离都做了相应的扩大能力加强；在单机侧，Koordinator 提供了 Koordlet 和 Koord Runtime Proxy 两个组件，负责单机资源的精细化治理和 QoS 保障能力。 ...

作者：黄炎帝 前言咱们是否绕开 http 协定，间接测试数据库的性能？是否感觉从数据库中导出 CSV 文件来结构压测数据很麻烦？怎么在压测完结后做数据清理？能不能通过数据库中的插入（删除）记录对压测申请做断言？应用阿里云性能测试工具 PTS 能够轻松解决上述问题。 什么是 JDBCJDBC（Java DataBase Connectivity，Java 数据库连贯）是一种用于执行 SQL 语句的 Java API，能够为多种关系数据库提供对立拜访，它由一组用 Java 语言编写的类和接口组成。JDBC 提供了一种基准，据此能够构建更高级的工具和接口，使数据库开发人员可能编写数据库应用程序。 简略地说，JDBC 可做三件事：与数据库建设连贯、发送操作数据库的语句并处理结果。 JDBC 的设计原理整体架构 JDBC 制订了一套和数据库进行交互的规范，数据库厂商提供这套规范的实现，这样就能够通过对立的 JDBC 接口来连贯各种不同的数据库。能够说 JDBC 的作用是屏蔽了底层数据库的差别，使得用户依照 JDBC 写的代码能够在各种不同的数据库上进行执行。那么这是如何实现的呢？如下图所示： JDBC 定义了 Driver 接口，这个接口就是数据库的驱动程序， 所有跟数据库打交道的操作最初都会归结到这里 ，数据库厂商必须实现该接口，通过这个接口来实现下层利用的调用者和底层具体的数据库进行交互。Driver 是通过 JDBC 提供的 DriverManager 进行注册的，注册的代码写在了 Driver 的动态块中，如 MySQL 的注册代码如下所示： static { try { java.sql.DriverManager.registerDriver(new Driver()); } catch (SQLException E) { throw new RuntimeException("Can't register driver!"); } }作为驱动定义的标准 Driver，它的次要目标就是和数据库建设连贯，所以其接口也很简略，如下所示： public interface Driver { //建设连贯 Connection connect(String url, java.util.Properties info) throws SQLException; boolean acceptsURL(String url) throws SQLException; DriverPropertyInfo[] getPropertyInfo(String url, java.util.Properties info) throws SQLException; int getMajorVersion(); int getMinorVersion(); boolean jdbcCompliant(); public Logger getParentLogger() throws SQLFeatureNotSupportedException;}作为 Driver 的管理者 DriverManager，它不仅负责 Driver 的注册／登记，还能够间接获取连贯。它是怎么做到的呢？察看上面代码发现，理论是通过遍历所以曾经注册的 Driver，找到一个可能胜利建设连贯的 Driver，并且将 Connection 返回，DriverManager 就像代理一样，将真正建设连贯的过程还是交给了具体的 Driver。 ...

常识付费短信性能同时反对阿里云短信和 crmeb 短信，咱们应用时只须要二选一即可。 那么咱们如何二开阿里云短信性能呢？ 第一步：首先进入阿里云控制台，在阿里云短信模块，申请须要新加的短信模版 第二步：在常识付费总后盾 -> 系统维护 -> 开发配置 -> 配置分类 -> 短信配置下加新的短信模版 id 贮存配置 点击 “短信配置” 名称，进入短信配置下的子配置 点击增加配置，抉择‘文本框’类型，填写上面的配置，提交配置 提交实现后，进入 “零碎设置 -> 零碎设置 -> 阿里云配置 -> 短信配置”，在这里咱们能够看到咱们新加的短信模版 id 配置。 第三步：调取阿里云短信接口，发送短信 常识付费源码的根目录”extend/service/AliMessageService” 下的 sendmsg 办法为阿里云短信的发送办法； $tel：接管手机号 $setTemplateCode ：短信模版 ID $setTemplateParam ：短信内容 参数为数组 $setOutId ：能够为空 /** * 发送短信 * @param string $tel 短信接管号码 * @param string $setSignName 短信签名 * @param string $setTemplateCode 短信模板ID * @param array $setTemplateParam 短信内容 * @param string $setOutId 内部流水扩大字段 */public static function sendmsg($tel = '', $setTemplateCode = '', $setTemplateParam = [], $setOutId = ''){ try { self::init(); $result = AlibabaCloud::rpc() ->product('Dysmsapi') ->version('2017-05-25') ->action('SendSms') ->method('POST') ->host('dysmsapi.aliyuncs.com') ->options([ 'query' => [ 'RegionId' => "cn-hangzhou", 'PhoneNumbers' => $tel, 'SignName' => SystemConfigService::get('smsSignName'), 'TemplateCode' => $setTemplateCode, 'TemplateParam' => json_encode(is_array($setTemplateParam) ? $setTemplateParam : ['code' => $setTemplateParam]), ], ])->request()->toArray(); return $result; } catch (ClientException $e) { return false; } catch (ServerException $e) { return false; }}如果发送短信呢？ ...

6 月 15 日，2022 云原生产业大会发表，阿里云在信通院“云原生平安成熟度”评估中，获得国内惟一全域最高等级认证。信通院“云原生平安成熟度”从基础设施平安、云原生基础架构平安、云原生利用平安、云原生研发经营平安和云原生平安 5 个维度，共计 315 个细分项考查企业云原生架构平安程度。阿里云云原生利用平台通过大规模企业客户服务积攒和创新性技术打磨，积淀了全链路的云原生平安解决方案，全方位展示了阿里云云原生产品安全能力的丰盛度和当先性。 （图 1：阿里云云原生平安成熟度模型测评报告） 平安合规是企业上云、全球化部署的首要需要，随着云原生对计算基础设施和企业应用架构的重定义，传统的企业平安防护架构也面临着新的挑战。 短少体系化的云原生平安能力建设： 传统企业应用平安模型通常是基于不同的信赖域来划分平安边界，在信赖域内的东西向服务交互被认为是平安的。而上云后容器利用可能须要在 IDC 和云上漂移，传统基于边界平安模型中动态标识符（比方 IP 地址）在云原生场景下不再可行，须要企业平安防护更靠近于基于属性和元集群（比方标签标记等）辨认一直变动的动静负载，并采取零信赖的平安保护措施。短少利用侧全生命周期的平安防护伎俩：容器提供了弹性、麻利和动静可扩大等个性，同时也扭转了利用的部署模式。利用本身生命周期被大幅缩短，一个容器利用的生命周期通常是分钟级。这须要在企业应用生命周期和平安设计架构中施行更多自动化的安全控制，从身份体系、资产治理、认证鉴权、威逼剖析检测和阻断等利用侧全生命周期平安防护。短少对云上平安责任共担模型的了解：在企业应用云原生化架构转型过程中，须要企业应用开发者和平安运维人员了解企业本身和云服务商之间的责任边界。从利用设计、开发、构建、散发、部署到运行时各个阶段，一方面须要云服务商提供云原生下的平安防护产品化能力，另一方面也须要企业加强对云原生下平安概念、工具和流程的继续学习并真正长期实践到利用中。云原生平安成熟度模型阿里云云原生平安旨在基于云原生麻利高效、分布式和不可变性等架构特色，在传统平安模式的根底上提供更加全链路、平安可信的纵深进攻。在云原生利用生命周期中“平安左移”，尽早地整合平安并实现预防性的主动防御；同时基于零信赖、安全软件供应链 DevSecOps 等平安架构设计进步企业的平安防护的效率。 本次信通院云原生平安成熟度模型测评，全场景多维度笼罩了云原生平台架构的平安防护能力。整个平安评测规范能够帮忙企业提供云原生平安能力的自检标尺和建设指南。阿里云在此次规范所有 5 个域的测评中均获得了国内惟一的全域最高等级认证。 （图 2：云原生平安成熟度模型） 云原生平安全景图从容器镜像服务 ACR、容器服务 ACK 到云平安核心、Web 利用防火墙，阿里云丰盛的云原生平安产品家族保障了阿里巴巴本身的大规模云原生化实际，确保利用全生命周期的云原生平安。同时这些云原生平安能力也撑持了云上百万企业，从基础设施、云原生基础架构、云原生利用、云原生研发经营到云原生平安运维，晋升了全链路的安全性及企业平安治理的效率。 目前，阿里云正式公布云原生平安全景图，波及阿里云原生平台 10 余条产品线，50+ 款产品共计 522 项外围平安能力，助力企业打造更平安可控、更先进智能的业务体系。 （图 3：阿里云云原生平安全景图） 基础设施平安： 阿里云在计算、存储、网络等云基础设施侧构建了夯实的平台底座平安能力。在计算平安方向，云平安核心和容器镜像服务反对破绽的自动化检测，告警，溯源和攻打剖析，同时反对镜像破绽的自动化智能修复；同时反对多OS，混合云架构的基线扫描和丰盛的策略配置；在网络安全方向，云防火墙服务反对多重边界防护和基于流量学习后果的自适应智能策略举荐下发；在存储平安方向，容器服务备份核心反对利用数据的异地备份和疾速复原，ACK One提供了多云混合云场景下的两地三核心备份容灾能力，同时ACK-TEE还提供了基于软硬一体的秘密计算技术帮忙实现内存维度的残余信息爱护。基础架构平安/供应链平安： 首先在云原生网络侧，容器服务和云平安核心提供了pod维度的东西向策略管制和智能阻断能力，同时反对集群网络拓扑的可视化展现；ASM网格服务提供了Service Mesh框架下全链路的流量加密、观测，监控和七层访问控制能力；在编排和组件平安方向，ACK容器服务反对多维度的自动化平安巡检能力，帮忙发现集群利用潜在危险并提供加固倡议，同时保障所有零碎组件基于CIS等合规标准的配置加固。通过应用托管节点池能够实现集群节点CVE的自动化自愈修复能力。在访问控制上，ACK集群的RRSA性能反对集群利用侧pod维度的云上资源权限隔离；在镜像平安方向，ACR容器镜像服务企业版提供了云原生交付链性能，联合镜像的完整性校验等产品化能力，构建了企业级的供应链DevSecOps能力；在运行时平安方向，云平安核心反对容器维度的runtime威逼实时检测、告警和智能解决，帮忙企业抵挡容器逃逸、敏感文件操作、异样连贯等多种容器内攻击行为。云原生利用平安： 云原生利用平安蕴含了企业应用侧防护的方方面面。首先在通用平安方向，通过应用云防火墙和Web利用防火墙等服务能够实现企业应用南北向和东西向的攻打防护和细粒度的访问控制，反对API破绽、注入攻打和敏感数据泄露的监测、剖析和主动修复倡议，同时企业应用能够接入ARMS RASP服务，实现API维度的调用链监控和API服务资产治理；在微服务平安方向，MSE微服务引擎通过云原生网关联合云防火墙等服务保障微服务网络通信平安，在提供丰盛的微服务治理能力的同时提供了安全监控和利用代码层的RASP防护能力。在Serverless平安方向，函数计算服务反对存储、网络等函数资源的细粒度访问控制和租户隔离，同时反对函数资源、流量的实时监控以及齐备审计。云原生平安运维：云原生利用如何进行平安运维是企业关怀的重点问题。在平安治理方向，容器服务和云平安核心等服务反对丰盛粗疏的可视化资产治理能力，同时基于日志服务提供了管控侧和业务侧齐备的审计日志，并反对基于审计的智能剖析、告警和图表化展现能力。在策略管理上，容器服务反对基于OPA的集群部署时刻策略治理引擎，同时云效服务针对云原生开发、测试流程提供了基于策略的经营流程配置和平安检测性能。身份治理是零信赖平安的根底，阿里云RAM和IDaaS服务反对企业LDAP对接，在服务网格中反对基于身份的服务间拜访策略规定定制以及身份凭证泄露的实时检测告警。在平安经营方向，云平安核心反对通过云蜜罐诱导捕捉攻击者并自定义攻打反制，同时反对多维度可视化的检测预警和溯源剖析，另外阿里云威逼情报平台反对基于IOC搜寻、断定后果，可通过多渠道进行破绽情报的获取并反对行业安全事件报告线下订阅形式的订购，帮忙企业平安运维团队晋升经营管理效率。研发经营平安： 阿里云平安团队对平台外部研发经营流程进行严格的平安审计和治理。在平安需要方向，平安团队针对云产品定制化需要清单，反对面向利用场景特定的定制化需要和自动化的测试用例，同时反对多渠道的需要收集和系统化治理；在开发平安方向，首先在制品平安上实现组件破绽的自动化查看、完整性校验和身份溯源，在平安设计上反对系统化的威逼建模以及外部标准化的平安设计规范和技术栈；在测试平安方向，在研发经营流程具备端到端的测试工具链，配合日常人工浸透测试，及时发现破绽并主动录入零碎告诉修复。整个DevSecOps流程可通过策略配置实现危险辨认和经营，无需人工干预。阿里云容器产品家族 - 高效平安、智能无界阿里云容器服务 ACK 撑持了团体 100% 外围利用的云原生化，同时为云上上万企业实现现代化利用革新降级提供降级服务。从互联网到批发、金融、制作、交通，越来越多的行业在利用翻新的云原生技术解决他们的业务问题。与此同时，容器也在撑持着更多行业场景翻新，比方在智能驾驶畛域，仿真模仿须要海量的算力。只有云计算与云原生技术可能满足业务算力的弹性、规模和效率的需要。 阿里云容器镜像服务 ACR 是云原生架构重要基础设施之一，负责云原生利用制品的平安托管和高效散发。先后服务了数千家企业，托管了数 PB 容器镜像数据，撑持月均镜像拉取数亿次。在 DevSecOps 场景，企业能够应用 ACR 云原生利用交付链，或与自建 CI/CD 工具联合，实现高效平安的云原生利用交付，减速企业的翻新迭代。 阿里云容器服务 ACK ONE 是基于阿里云提供的多云、多集群、多环境治理能力，ACK ONE 可能同时治理阿里云上集群、边缘集群、部署在用户客户核心的集群以及其余云上的 Kubernetes，真正实现集群的对立治理、资源的对立调度、数据的对立容灾和利用的对立交付。 ...

随着企业数字化转型落地，业务增长与 IT 基础设施的关联愈发严密。云原生不仅重塑了企业 IT 架构，也扭转了运维体系与流程。「可观测」理念应运而生，并成为度量企业IT治理程度的重要规范。小到问题定位、危险辨认，大到老本治理、业务连续性治理甚至业务增长，都依赖着可观测技术与数据。能够说，可观测在数字化转型与云原生时代，扮演着重要角色。 6 月 22 日，由中国信通院作为领导单位，阿里云、Grafana Labs 联结举办，云原生利用平台、天池平台主办的首届阿里云可观测技术峰会拉开帷幕。阿里云智能云原生利用平台负责人丁宇正式公布阿里云可观测套件（Alibaba Cloud Observability Suite，ACOS），让可观测数据价值真正做到不止于观测。 与此同时，本次峰会围绕「可观测与开源」主题，邀请友邦人寿、爱福路 F6 企业一线负责人、Grafana、Prometheus 我的项目大咖，为听众出现丰盛且具备实际参考意义的精彩分享与探讨。 基于本身实际，阿里云对于可观测趋势的判断作为国内首批大规模践行微服务架构与 DevOps 的先行者，阿里云认为作为向下连贯基础设施，向上承载业务的重要组成部分，利用是云原生时代的最佳观测视角，并具备着以下趋势： 可观测性成为云原生红利开释的前提条件企业对于运维的要求不再局限于被动发现问题，而是更及时、被动、精确地发现问题与洞察起因，为事先预防、事中解决、预先复盘提供决策依据。与此同时，利用相干的可观测数据类型不断丰富，指标、日志、事件、链路相互连接，其背地的业务价值一直开释。 碎片化观测趋势已成，优良开源我的项目成为规范随着 Kubernetes 为外围的利用编排技术风行，可观测场景与技术百花齐放、去中心化观测、碎片化观测成为趋势。其中，Prometheus、Grafana、OpenTelemetry 等优良的开源可观测规范和实现成为支流。 可观测是保障平安生产与业务连续性的外围因素不止于大促保障与日常轮值，如何围绕本身理论业务需要，打造合乎业务需要的可观测能力，保障业务连续性成为泛滥SRE团队的业务挑战。 不止于观测，阿里可观测套件正式公布阿里云于6  月 22 日正式公布阿里云可观测套件（Alibaba Cloud Observability Suite，ACOS）。阿里云可观测套件围绕 Prometheus 服务、Grafana 服务和链路追踪服务， 造成指标存储剖析、链路存储剖析、异构构数据源集成的可观测数据层，同时通过规范的 PromQL 和 SQL，提供数据大盘展现，告警和数据摸索能力。为 IT 老本治理、企业危险治理、智能运维、业务连续性保障等不同场景赋予数据价值，让可观测数据真正做到不止于观测。 与泛滥第三方服务或开源自建计划不同，阿里云可观测套件实现多层次连贯，全面突破数据孤岛，开掘数据背地的业务价值。 向上造成兼容开源规范的对立观测界面与利用实时监控服务 ARMS 的应用层监控（APM）、前端体验监控（RUM）、基于 eBPF 技术的 K8s 监控、云监控等阿里云自研可观测产品双向连贯，将可观测数据与剖析能力以凋谢规范（PromQL)、对立凋谢界面（Grafana）的模式提供给用户，便于用户的再集成与二次加工。ARMS 也全面反对 OpenTelemetry SDK 进行自定义埋点的加强。 向下连贯阿里云可观测数据存储类产品对立诸如日志服务 SLS、Elasticsearch 服务等可观测数据存储，以及散落在异构数据存储设施中（如 Clickhouse、Lindorm、RDS）的可观测数据，实现可观测数据源治理与异构数据间无缝摸索。 横向连贯阿里云所有利用管控产品与中间件产品阿里云所有利用管控（EDAS、SAE、ACK、FC 等）与中间件产品全面拥抱开源可观测规范，并与可观测套件进行连贯。目前，已有超过 50 款阿里云云服务通过 Prometheus 规范进行观测。 拥抱开源生态，大力发展生态搭档阿里云作为国内可观测畛域的引领者，不试图用一站式产品或计划去解决所有问题。阿里云踊跃拥抱开源生态，提供 Prometheus 监控服务、Grafana 服务、兼容 OpenTelemetry、Skywalking 等支流开源协定的链路追踪服务，独特造成新一代阿里云可观测套件。应用标准化技术向下连贯存量、碎片化可观测数据，向上帮忙客户造成本人独有、无厂商锁定的可观测解决方案，实现真正的客户胜利。 ...

在上篇《为 Serverless Devs 插上 Terraform 的翅膀，实现企业级多环境部署（上）》中，次要介绍了 Serverless Devs 多环境性能的应用，用户读完可能会些疑难，本文会就一些常见问题进行答复。 Serverless Devs 和 Terraform 的关系可能有些用户会问，既然你们曾经反对了 Terraform，那 Serverless Devs 还有什么作用，是不是间接用 Terraform 就能够了？ Serverless Devs 和 Terraform 的定位还是显著不同的。Serverless Devs 面向利用治理及 DevOps，Terraform 面向云资源，是两个不同的畛域，但并不示意不能在某些层面有交加或者不能集成，集成和被集成能力原本就是开源工具是否标准化的一个衡量标准。 Terraform 解决的是云资源的 Provisioning，这个畛域是有十分清晰的方法论的。而 Serverless Devs 更应该强调如何应用好云资源，两者的关系能够用几个场景阐明： Serverless Devs 更多关注如何把代码或者装置依赖分片上传到 NAS 上，更少关注 VPC/交换机/平安组/NAS 挂载点如何创立进去；Serverless Devs 更多关注如何把文件上传到 OSS，并且主动触发函数实现报表的生成，更少关注 OSS Bucket 如何创立；Serverless Devs 更多关注如何构建代码/镜像、制作 Layer、部署代码、公布版本、灰度放量来结构残缺的 CI/CD 体验，更少关注 FC 的网络、日志仓库、ACR 实例如何创立进去；Serverless Devs 更多关注如何近程调试代码，如何登陆到线上实例，如何通过日志以及监控疾速发现业务的异样； 能够看到 Serverless Devs 更加重点关注的是利用运行态以及运维态的操作，这也是 Serverless 架构的工具最重要的使命，但 Serverless Devs 负责的是 Serverless 利用全生命周期治理，必然少不了资源的治理，咱们在实际过程中发现，无论是用云产品 SDK 还是 Pulumi 这类 GPLs 都须要投入很大精力在资源生命周期的对接上，这对于组件开发者对接更多云产品来说是十分低效的。而 Terraform 在这方面是最业余的，无论是标准化水平、受认可水平以及资源的丰盛度都能很好满足终端用户及开发者的需要，因而才触发 Serverless Devs 和 Terraform 联合这一想法。 ...

近几年随着 DevOps 倒退，SRE（Site Reliability Engineering）开始被大家所熟知。随着国内互联网、金融、新批发等行业的飞速发展，SRE 也不再局限于互联网企业大促时的保障与平时的稳定性轮值，并凸显其独特价值：以软件工程的方法论从新定义研发运维，驱动并赋能业务演进。在保障业务高速倒退的过程中，构建零碎高可用的稳定性体系，从用户的角度来保障业务的稳定性和可用性，同时在性能与容量等不同方面撑持业务将来 3-5 年的倒退。 SRE 的工作领域相较于传统运维更加宽敞，涵盖监控、事变响应、事变复盘、测试与公布、容量布局以及构建自动化工具等方方面面。而这其中，可观测体系与工具扮演着重要角色。在理论生产过程中，咱们该如何设计并落地可观测体系？ 立刻报名「阿里云可观测技术峰会」！本次峰会邀请到友邦人寿、爱福路 F6 汽车科技、阿里云等不同行业头部企业的利用架构负责人、SRE 负责人具体解读企业 IT / SRE 团队如何借助可观测能力晋升运维效力，打造更优质、更智能的用户体验，更轻松地实现数字化转型与翻新。 更有 Grafana 、Prometheus、Apache Skywalking 等热门开源我的项目创始人、首席布道师等重磅嘉宾，与泛滥运维工程师独特探讨可观测将来发展趋势与实际挑战，打造可观测体系提供可复制、可借鉴的最佳指南。 点击此处，立即报名峰会！

6 月 15 日，2022 年云原生产业大会在京召开。凭借在云原生畛域的翻新技术积攒与充沛的客户服务教训，阿里云拿下三项业余能力最高级认证：云原生技术架构成熟度-国内惟一全域最高级，云原生平安成熟度-国内惟一全域最高级，服务网格平台性能-先进级。 同时，阿里云云原生技术中台 CNStack 和阿里云容器服务 ACK Anywhere 入选 2022 年度云原生技术创新解决方案和产品； 由阿里云提供技术服务的 vivo AI 计算平台混合云实际与网易云音乐音视频算力弹性化实际取得 2022 年度云原生利用优良案例。 三项业余能力获最高级认证，国内惟一阿里云首次针对云原生综合技术能力在生产环境进行系统性测试，评测过程历时 2 个月，波及数十条业务线的超 100 人，最终首个实现云原生成熟度测评认证，并取得国内惟一全域最高等级认证。阿里云容器产品提供最全体系的云上资源管理能力，最高性能的容器网络，最小攻击面的平安和极致的资源弹性。 此外，阿里云领有寰球当先的可观测产品家族，全面晋升业务零碎问题的发现、定位与诊断能力。在高可用保障方面，残缺的防控、演练与治理工具平台体系化地保障云原生架构下的业务连续性，进步企业面对容灾、容错、容量等问题的稳态零碎建设能力。 阿里云首个实现云原生平安成熟度评估，并取得国内惟一全域最高等级认证。阿里云致力于打造稳固、规范、先进的云原生利用平台，同时是国内最早提出并定义云原生平安的企业之一，将云上通过大规模实际和验证的平安能力利用于爱护云原生利用，并将云原生疾速拉起、便捷部署的劣势特点利用于平安产品技术，继续为云上用户提供原生利用、数据、业务、网络、计算的爱护能力，通过和基础设施深度交融推动平安服务化，反对弹性、动静、简单的行业场景，取得包含政府、金融、互联网等各行业用户认可。 阿里云服务网格 ASM 以满分问题获服务网格性能评估先进级认证。 特地是在管制面高可用及动静扩容、数据面服务调用时延优化、抗雪崩及故障容错等能力上国内当先，达到业界先进程度。此前在 Forrester 2021 容器服务评测中有一项针对 Service Mesh 方面的评估,  阿里云服务网格 ASM 与 AWS、Google 并列满分取得该维度的最高程度。 从 2022 年 4 月 1 日起，阿里云服务网格 ASM 正式推出商业化版本, 提供了更丰盛的能力、更大的规模反对及更欠缺的技术保障，更好地满足客户的不同需要场景。 阿里云以两项翻新技术、两大客户服务案例，继续领航云原生在 2022 年度云原生技术创新领航者评比中，阿里云容器服务 ACK Anywhere 与阿里云云原生技术中台 CNStack 胜利入选。 阿里云 ACK Anywhere 取得 2022 年度云原生技术创新案例阿里云容器服务 ACK 是寰球首批通过 Kubernetes 一致性认证的服务平台，也是目前国内惟一间断三年入选 Gartner 公共云容器报告、惟一进入 Forrester 领导者象限的容器产品。 ...

数字经济时代，数字化转型已成为社会的广泛共识和口头，越来越多的业务运行在数字化基座之上，软件系统正成为业务的价值外围和翻新引擎。在这一趋势下，软件产业面临着许多新挑战和新机遇：一方面，万物互联下软件系统规模和复杂度持续增长；而另一方面，业务的疾速变动对软件交付效力的要求却一直晋升。软件构建和交付形式亟待改革。 6月29日，咱们特邀到阿里云、南京大学、Thoughtworks、InfoQ产学研界6位领军人物，独特探讨这场数字化转型浪潮下的技术变局，并寻找破局之道。 你将理解到： 数字化转型对于产品研发的挑战与机会？为什么咱们须要从DevOps走向BizDevOps？BizDevOps 体系蕴含哪些办法与实际？如何真正利用并落地BizDevOps，晋升企业研发效力？举荐观看人群：企业CIO、CTO、CDO，以及关注研发效力和产研数字化建设的从业者。

大家好，我是专一于交付的王小锤，看过交付铁三角系列故事（专一交付的我小锤，开发老哥铁子和售前大佬强哥）的同学想必都晓得，咱们三人服务于一家提供大数据分析服务的 ISV 企业，在利用交付过程中时常面临各种挑战。 那日，就在咱们为一个交付难题发愁时，有人兴奋的冲过来说找到理解法。就这样，一本独家交付秘籍走进了咱们的世界，而且此秘籍还号称使用好便可让交付更简略。通过认真钻研，咱们发现秘籍中提到许多帮忙解决交付问题的招式，而其中一个让咱们印象很深，是对于在原有社区版容器底座 Kubernetes（以下简称 K8s）的根底上，对容器底座进行改良，可更好的服务于利用交付的招式。上面，请随我一起来看看您是否是那天选之人吧！ 天选之人学习招式前，先来看看您是否为天选之人，适宜应用该招式进行交付吧！ 被沉重的适配与兼容工作压的喘不过气？不同客户的环境均不同，需重复对硬件参数和操作系统配置，造成环境适配老本升高。POC 环境跑起来后，可能还存在零碎库常常缺失或版本不兼容等问题。而如果碰到组件出 BUG 时，还须要期待社区的漫长修复反对，根本只能抉择代替计划绕过。因为每个问题的解决都很耗时，留下产品质量不好的负面印象。大量的组件适配工作需人工调试，极消耗工夫。应用开源的 K8s 及生态组件搭建环境与部署产品，因为短少最佳实际做参考，K8s 自身各组件配置灵便度又十分高，很多组件参数配置并不适合，须要人为本人调试。不仅须要进行各种依赖库装置与性能测试，还需每个环境都定制化适配。 冀望可能实现兼容性检测与参数的主动适配。 信创趋势下的利用革新困难重重？ARM 架构处理器 + 国产操作系统的场景越来越多，而国产化生态圈目前还在疾速倒退阶段，较难找到适合的ARM 版本组件，不仅如此，找适配组件和革新的过程仍需破费大量工夫，而且其中有许多对 IPV6 网络结构的要求或须要反对 IPv4/IPv6 网络双栈。 冀望能轻松找到 ARM 版本组件来兼容信创环境，并轻松解决网络、操作系统等难题。 集群装置与调试过程大汗淋漓？ 因环境不同，在客户现场交付时，需做大量手动配置批改和调试工作。搭建集群后，如果不足集群装置和管理工具，还需研发人员提供很多具体的脚本辅助来进行生命周期治理，操作时出错概率加大且部署速度大打折扣。 集群的装置部署和组件的扩缩容十分繁琐，整体操作不够灵便。每次装置或扩容实现后还需逐个查看节点、网络、磁盘、DNS 等资源是否都工作失常，很容易漏检，许多场景面临不足业余工具进行监测，只能看下层利用是否衰弱来进行全面的察看。 冀望实现分钟级集群的自动化部署、扩缩容等生命周期治理性能。提供节点环境查看、集群健康检查能力，实现麻利易用，省时更省力。 问题解决与运维管控不够高效？不足零碎欠缺的集群装置和运维管理工具，通过集成云原生技术提供的监控、日志、告警能力或七拼八凑组成运维工具，因为运维服务来自多方，时常放心不够稳固。如果本身搭建运维体系，研发周期拉长，交付老本升高。 本身搭建运维工具后，物理资源占用变高，在保障运维能力的同时，心愿将物理资源占用管制在极小范畴，升高业务产品私有化输入老本，心愿保障运行环境可靠性的同时，使产品更具竞争力。 集群监控的数据收集与编制告警老本昂扬。应用 K8s 后，如果想要实现监控工作负载或确保最佳状态，须要采集并了解零碎层面的大量的指标针对不同场景来编制告警，对于利用方的研发来说是一个微小的挑战，须要破费许多工夫。 冀望有一个自动化运维管控平台解决上述难题。 招式简介如果您凑巧遇到了上述问题，或已经被上述问题所困扰，那么您便是那天选之人，许可我持续看上来，来理解这个招式吧。 近年来，随着云原生理念的倒退，越来越多的 ISV 抉择在 K8s 上，以云原生的模式进行利用开发及部署布局，社区版 K8s 作为稳定性高、兼容性好、安全可靠的底座，已能够为客户提供良好的服务，ISV 在理论的应用和交付业务时感觉成果也很好。然而在愈发简单的客户场景下，如何让底座更好用更稳固牢靠呢？ 正如下面提到的，只管社区版 K8s 提供了牢靠的组件供大家应用，但这些组件在应答简单的业务状况时，是否提供更贴合客户的特有场景的服务？在如此多的运维能力可抉择时，如何可能集成出一个全面高效的运维管控平台提供给客户，这都是咱们所思考的问题。 做出有别于社区版 K8s，且具备差异化和增值的服务提供给客户，帮忙客户解决更多交付难题成为咱们一大指标。 好在通过一直摸索，咱们终于找到了方向。遵循客户至上的理念，加以技术打磨，咱们励志打造出好用且稳固牢靠的容器底座。最终，在着眼于利用交付畛域所打造的云原生利用交付平台 ADP（以下简称 ADP）中，咱们提供了 ADP 的容器底座 ADP-Local 。ADP-Local 基于原生 K8s 的技术上，为下层业务利用的运行和治理保护提供必要的零碎反对，含 k8s，日志收集、监控告警、故障诊断等，为软件提供牢靠运行环境及运维工具。帮忙客户在遇到下面所形容的难题与窘境时，可轻松有效应对。 制胜起因家喻户晓，社区版 K8s 作为利用的一部分已被大量的 ISV 交付到客户现场，经验了许多的验证。而咱们所提供的底座同样经验了泛滥简单客户场景的实际，您可放心使用。因为 ADP-Local 是通过对泛滥不同简单现场环境深入研究，一直加以打磨而打造出的容器底座，所以当您应用 ADP-Local 时，您会发现 ADP-Local 具备以下特色： ...

6 月 13 日，2022 阿里云峰会上，阿里云根底产品事业部负责人蒋江伟发表容器服务再降级，正式推出分布式云容器平台 ACK One 及 ACK 云原生 AI 套件。 点击查看相干视频： https://developer.aliyun.com/... 随着云计算等技术在各行业得减速利用，算力正在成为企业新的生产力，麻利灵便的 IT 基础架构、海量数据的高效解决能力成为企业倒退的重要引擎。在此背景下，容器及 Kubernetes 技术在自动化部署、扩展性、容器化利用治理等方面体现出独特劣势。 2021 年，阿里云容器服务全面向 ACK Anywhere 降级，此次的 ACK One 公测开启及 ACK 云原生 AI 套件公布，使 ACK Anywhere “计算无界、承载有限” 的服务能力迈向新阶段。 ACK One 是阿里云面向混合云、多集群、分布式计算等场景推出的分布式云容器平台，可能对立治理阿里云上、边缘、部署在客户数据中心以及其余云上的 Kubernetes 集群，并简化集群治理界面，让企业轻松应答多集群状态，从而灵便地依据本身业务和数据管控等需要，同时使部署在客户数据中心的集群也能获取云上弹性算力，实现“计算无界”。 阿里云分布式云容器平台 ACK One 国内当先的癌症精准医疗公司泛生子基于分布式云容器平台 ACK One 的对立调度治理能力，单样本解决老本相较于云下节俭 60%，日解决数据能力在过来三年晋升了 10 倍。 此次公布的 ACK 云原生 AI 套件则使阿里云容器服务能力进一步向 AI、大数据等数据密集型应用领域拓展，实现“承载有限”。 ACK 云原生 AI 套件是为了解决企业在大数据、 AI 等数据密集型利用场景下计算性能、管理效率等挑战推出的服务。 具体来说，ACK 云原生 AI 套件基于 Kubernetes 提供了异构资源对立运维治理、AI 任务调度和弹性伸缩、数据编排与减速、作业生命周期治理等外围能力，深度优化 AI 生产效率和资源应用老本，助力企业疾速构建 AI 平台。它能够帮忙 AI 工程效率晋升 50%，AI 数据拜访减速 35%，分布式训练效率晋升 20%。 ...

Serverless 作为云计算的最佳实际和将来演进趋势，其全托管免运维的应用体验和按量付费的老本劣势使得它在云原生时代备受推崇。Serverless 的应用场景也由事件驱动，数据处理等局部特定场景转向更为宽泛通用化的 WEB，微服务，AI，进而在电商，互娱，出行，乃至传统行业都有浸透。 在 Serverless 的遍及与推广过程中，开发运维人员尽管认同其降本提效的外围价值，但同时被诸如厂商锁定，黑盒化，全屏蔽等一系列 Serverless 全包的个性所困扰；进而所引发的迁徙老本高，问题排查难度大，根因定界剖析艰难等痛点亟需解决。 所谓凋谢，是指用户能够解脱心智累赘的，在不变更语言利用的前提下从任意平台迁徙至 Serverless，是指用户能够即开即用的获取 Serverless 利用的全生命周期外围数据，更是指用户能够将其原有的架构与 Serverless 架构进行交融，实现云上云下云间的互通与混部。 拥抱凋谢后 Serverless 将不会是须要革新以适配兼容的，可望而不可即的技术试验品，也不是一座独立进去的，与原有技术体系割裂的数据孤岛，而是承载技术开发者们现实与事实的，可能让技术变得更加普惠、通用、共享的最短门路之一。 阿里云保持在 Serverless 畛域继续投入并在技术竞争力上维持领先地位, SAE（Serveless 利用引擎）作为业界首款面向利用的 Serverless PaaS，可能提供老本更优、效率更高的一站式利用托管计划。 SAE 在 2018 年外部孵化之初就秉持着零门槛，零革新的主旨进行利用（工作）的 Serverless 革新和落地实际，并且在产品的倒退历程中一直踊跃寻求被集成，增进 DevOps 全流程体验，三年内助力千余家客户实现利用的云原生 Serverless 化。SAE 目前已有和行将推出的性能均围绕着 “拥抱凋谢” 开展，上面咱们一起看看 SAE 目前所提供的产品性能个性以及它背地的思考逻辑。 Serverless 部署架构的开放性许多用户的利用其实并不是从零便开始应用 Serverless，而是出于对 Serverless 理念的认同，基于架构降级演进的诉求，冀望将原有的部署环境如物理机，云主机，Kubernetes 进行迁徙或者是混部于 Serverless 之中。那么在此场景下，利用迁徙革新的老本显得尤为重要，然而 Serverless 平缓的学习曲线和厂商生态锁定的刻板印象，令诸多开发者望而生畏。 正如先前所述，SAE 主打零门槛，零革新迁徙，利用其实无需批改任何代码逻辑，便可间接部署在 SAE 当中，而对于非容器类的利用，SAE 也提供内置的镜像构建能力，并借助公布单使得全 CICD 变得流程化、自动化、可视化。上面咱们重点介绍一下跨平台的应用场景。 SAE 与云主机混部SAE 反对与云主机（ECS）实例进行混部，以便于在存量迁徙的场景下实现疾速弹性，施展 SAE 的劣势，整个过程无需任何开发革新。 具体的形式为：将存量 ECS 实例退出到 SAE 实例申明应用的 SLB 后端虚构服务器组中，SAE 利用在部署、扩缩容、进行、启动、重启、垂直扩缩容等场景中，会主动动静保护 SLB 后端的实例，对立对外提供服务。 ...

Dubbo 官网文档写手召集令Dubbo3 是 Dubbo 新的里程碑，Dubbo 的生态组件（包含 Dubbo Java SDK，Dubbo Golang SDK 等）都在向 Dubbo3 的指标聚拢，在用户实际方面，包含阿里巴巴、淘宝、天猫、饿了么、工商银行、安全衰弱等企业都已胜利降级 Dubbo3 版本，随着更多的企业和用户关注或降级 Dubbo3，整个社区对 Dubbo3 的文档的需要开始变得更加迫切，以帮忙用户正确应用 Dubbo3 性能或晓得如何排查遇到的问题。 官网的文档目前次要面临两个问题：文档内容绝对滞后、文档构造不够清晰，为了进步 Dubbo 官网文档的品质，让 Dubbo 官网的文档可能帮忙到更多的用户，Dubbo 社区借着 Dubbo3 这一里程碑，对 Dubbo 官网的文档构造进行了全面降级，集火解决以上两个痛点。 在文档建设和降级的过程中，Dubbo 社区也心愿能招集一些小伙伴一起参加进来。并拆分了一些文档工作给社区的小伙伴进行认领。 参加奉献的小伙伴可能通过撰写文档全面的理解 Dubbo 的个性，并且依据贡献者的贡献度排名，会失去相应的奖品，比方限量版 Dubbo 社区周边T恤、水杯等。除此之外沉闷的贡献者有机会被提名为 Apache Dubbo Committer。 对于 Dubbo3 全新文档构造为了满足不同用户的需要，Dubbo 社区对文档的构造做了降级，全新的文档分为 “门面文档“  和 “高级文档” 两局部。 入门文档门面文档次要从 Dubbo 生态整体的视角来介绍 Dubbo，除了介绍 Dubbo 生态以外，它也包含索引到各个生态组件高级文档的能力，次要用于帮忙用户能疾速理解 Dubbo，并从中找到本人所需的内容。具体的文档构造如下： 什么是 Dubbo：蕴含 Dubbo 的简介（定义 Dubbo、解决什么问题、秀重点性能）、外围概念（架构与概念串讲）、Dubbo 生态。疾速开始：蕴含 Golang 疾速开始、Java 疾速开始、Rust 疾速开始等内容。3.0 速览：蕴含 Triple、利用级服务发现、IDL、云原生、Mesh、多语言等新个性的简述。示例实际：蕴含以一个残缺的 demo 残缺的体验 Dubbo 个性的实际示例。用户手册：分语言建设的高级文档入口。FAQ：其余一些如 Benckmaking、兼容性等用户会关怀的问题高级文档（语言相干）Dubbo 从 Java SDK 起家，到当初曾经有 Golang SDK 、生态也越来越宏大，高级文档则是对 Dubbo 生态组件的内容进行粗疏的形容，蕴含了所有用户想要关系的细节。所有生态组件的文档顶层构造都是统一的，具体的构造如下： ...

作者：陈昕 Serverless 时代下微服务倒退与挑战 晚期业务规模比较简单，大多团队开发采纳单体利用，曾经可能很好地满足团队的业务需要，并且可能疾速迭代。但随着业务规模的一直增长，零碎变得越来越简单，单体利用逐步无奈满足线上生产的问题。比方电商业务中，如果将交易、领取，商品等所有性能都集中在单体利用中开发，有可能会呈现公布简单商品性能影响到交易，从而对整个电商零碎产生影响，给企业造成损失。 这个时候很多团队会把单体利用架构改为微服务的架构，解决单体利用的问题。但随着业务进一步倒退，零碎更加简单，加之新技术的到来，比方云原生时代下成了规范的 K8s 以及 容器镜像 Docker 等，研发运维投入会越来越大，须要保障几十甚至几百个服务失常运行与合作，这给运维带来了很大的挑战: 1、效率：随着利用规模的扩张，新的研发团队须要面临很多开发和测试中的复杂性问题。在团队合作上，不同利用团队之间如何更好地造成稳固的调用链路，在几十，几百甚至上千个利用的大规模场景里如何进行调用链路上利用的疾速部署和灰度。此外，如此多利用的流量的解决、调用链路的跟踪和服务鉴权也十分影响效率。 2、稳固：微服务化之后，会呈现调用链路上某外围利用呈现问题，导致整体零碎产生雪崩，而且有时短少可视化、可观测性的零碎来帮忙疾速定位剖析问题，导致难以疾速定位到呈现问题的利用，造成长时间的损失； 3、老本：单体利用个别只需部署几台机器；到了微服务时代，随着利用数的剧增，出于可用性的思考须要为每个利用放弃一些冗余，比方一次大促中，一个调用链路会波及到十几个利用，为了稳定性以及调用链路的平安，会进行整个链路利用的扩容，而实际上很多利用可能长时间没有流量，服务器闲暇，导致微小的老本节约。  面对微服务带来的这些问题和需要， Serverless 利用引擎在这方面都做了哪些工作? 带来哪些扭转？ SAE 微服务利用全托管解决方案介绍 SAE 是面向微服务利用的 Serverless PaaS 平台。作为云平台，它可能为微服务利用进行全生命周期的托管。它能将 Serverless 和 K8s 自身的红利集中在一起，让微服务利用疾速上线。以产品化的模式疾速提供给用户，开箱即用，解决用户常见的微服务问题，晋升研发效率。 SAE 提供了蕴含但不限于 CI/CD 流水线、微服务框架、 Spring Cloud、 Dubbo 、共享注册核心、K8s 容器以及诸多运维相干的性能，蕴含调用链、日志、告警、性能监控、流量的治理以及主动弹性等。它是 Serverless 框架与微服务进行深度联合的最佳实际的平台。 SAE 微服务性能和实际底层能力：微服务性能加强 在 Serverless 时代下，微服务的趋势是客户端越来越薄，其中与服务治理、业务逻辑无关的局部被积淀在 Java agent 等组件里，通过字节码的形式注入到业务中，对业务开发无侵入、无感知，并在过程中提供了丰盛的微服务治理能力。比方流量治理相干的无损高低线、金丝雀公布、可视化数据上报等能力。 针对非 Java 场景，Java agent 也可能与不同的微服务框架进行通信。此外，与 Sidecar 之间的通信也正在不断完善建设中。 开发态实际：端云联调 Serverless 利用引擎（SAE）基于 Alibaba CloudToolkit 插件+ 跳板机能够实现： 本地服务订阅并注册到云端 SAE内置的注册核心；本地服务能够和云端 SAE 服务相互调用。 在实现的时候用户须要有一个 ECS 代理服务器，理论注册的是 ECS 代理服务器到 SAE 的注册核心，IDEA 在装置 Cloudtoolkit 插件当前，在启动过程时，会在本地拉起一个通道服务，这个通道服务会连上 ECS 代理服务器，本地所有的申请都会转到 ECS 代理服务器上，云端对服务的调用也会通过 ECS 代理转到本地，这样就能够以最新的代码在本地断点调试，这就是云端联调的实现。 ...

阿里巴巴编程之夏2022正式启动 寰球18岁以上的高校学生皆可报名 26个顶级开源我的项目，87个凋谢工作 期待同学们的参加 ↓↓↓ 站在2022年的工夫节点回看开源，它曾经从一个小众的爱好者行为变成了技术圈的支流。 不变的是，开源像有引力一样吸引着寰球的开发者，超过国籍、语言的差别，围绕着本人认可的开源我的项目，一直地应用、奉献代码。这些奉献，重塑了咱们当初的技术幅员。 据《中国开源十年洞察报告》，阿里间断十年蝉联了中国企业开源活跃度第一。阿里开源我的项目共3000多个，取得了寰球有3万多开发者参加，并失去100多万的star。 在刚刚过来的2021年，咱们硕果颇丰： 阿里开源新增了1494万行代码，是过来十年总量的30%；代码仓库新增了715个，总量超过了3000个，占过来十年的23%；commits数超过了20万次，占过来十年的40%；新增了16864个沉闷开发者，其中代码贡献者达新增了2316个，占过来十年总量的35%。往年，阿里巴巴再次邀请各位同学参加编程之夏 深度参加开源开发流动 以第一视角感触开源世界的魅力， 找到开源路上的“同路人”！ 注意事项： 您必须年满 18 周岁，并且是全日制或非全日制的在校学生。 阿里巴巴编程2022之夏流动工夫为2022年7月4日-2022年8月27日。您须要每周破费大概 40 个小时参加编程之夏，如果您曾经有实习或暑期工作，请掂量一下参加工夫。 点击此处，立即报名！

作者：封崇 前言随着现代化利用的遍及和企业上云的深刻，我的项目中会波及越来越多的云资源应用。企业上云过程中，往往会有平台（Platform）团队和基础设施（Infra）团队：平台团队关注业务，依据业务场景进行形象，对研发人员屏蔽基础设施；基础设施团队关注平安及老本，为平台团队布局了不同的子账号、权限策略以及网络配置。这种分层治理的必然结果导致利用和基础设施的生命周期会齐全不同，因而基础设施管理员、平台管理员、研发人员关注的云资源视角也不尽相同。比方： 基础设施管理员治理整家企业的云账号，布局企业的网络配置，并为各个平台团队设置不同子账号以及拜访策略；平台管理员持有子账号，依据容灾及高可用场景划分地区、平安、流量策略；依据业务场景布局日志、存储、数据库的规格、备份配置、Quota 等；依据研发流程要求布局 CI/CD 流水线；研发人员在应用平台过程中，仅需关注代码、数据、配置等程序相干内容：当须要拜访数据库时，向平台索要数据连贯串；当需进行日志采集时，将采集门路提交给平台，由平台操作日志服务实现日志采集配置挂载；当须要应用长久化存储时，将本地挂载门路提交给平台，由平台操作存储服务实现文件目录挂载；公布代码，主动触发 CI/CD 流水线的执行；因而，随着职责边界的不同，平台团队面临着更大的挑战，既要面向研发人员消化业务，又要面向基础设施团队解释云产品的应用，无疑减少了很多沟通老本，升高了业务的迭代效率。如果能建设一种自动化的管道，让不同团队自助化地实现各自的边界，势必会极大地晋升生产力。这须要几个很重要的概念来连贯 Dev 和 Ops： 服务：对代码、程序的形容，只形容跟程序相干的信息，比方函数配置、日志采集门路对于函数型利用，服务个别形容一个函数对于容器化利用， 服务个别形容一个 Workload环境：服务运行在不同的环境上，环境是服务运行的载体，形容了基础设施（如网络、集群、存储）的配置，以及利用运行时的运维配置（如弹性伸缩、资源规格）流水线：对 CI/CD 的形容，实现代码到服务的构建，并将服务部署到所有的环境上利用：一组服务、环境、流水线所有资源的汇合 要实现高效的自助化操作，合理化的计划是将上述概念进行模板化，并应用如下的工作流来实现： 平台管理员将网络、日志服务、存储、数据库等基础设施资源依据测试/生产隔离的要求，封装成环境模板；将阿里云函数计算（FC）的函数、Serverless 利用引擎（SAE ）利用这些研发关注的业务资源封装成服务模板；将 CI/CD 的根底流程封装成流水线模板；基础设施管理员审核模板，通过后为平台管理员调配对应的子账号；平台管理员持有子账号抉择环境模板创立不同的测试、预发、生产环境，而后授予研发子账号拜访权限，或者授予研发写权限来自助创立环境；研发人员抉择服务模板以及关联的环境来创立服务，实现将应用程序主动部署到指定的环境上；研发人员抉择流水线模板，通过被动触发或者代码提交主动触发 CI/CD 的执行。通过这种分边界的模板化解决形式，能够让企业不同的团队自助实现基础设施的搭建，进步生产效率的同时，又保障了权限隔离，让基础设施受到爱护。 Serverless Devs 反对多环境所面临的挑战Serverless Devs [1]是一款面向 Serverless 利用全生命周期的管理工具，其模型标准中存在利用和服务的概念，但目前短少对环境的外在反对，代码+基础设施独特保护在一个 s.yaml 下。这种模式在多环境时的限度次要有 3 点： 要为不同的环境保护不同的 s.yaml，保护老本比拟高。更新环境时须要从新发动部署，对接 CI/CD 服务时就要从新发动一次残缺的公布上线操作。（但通常状况下环境的变动，例如升降配、更新权限，对程序来说是平安的，不须要发动一次上线）；难以实现基础设施团队、平台团队、研发团队分层合作的场景。比方阿里云函数计算的服务形容提供了日志、网络、NAS、服务角色等平台管理员视角的配置。收到客户反馈，这些配置是干嘛的研发根本都不分明，无疑减低了研发效率并减少了平安危险，经常出现研发改错配置导致线上服务有损的状况；Serverless Devs 的资源操作次要由组件来实现，但对于一些资源的变更可能会引起实例重建或者不能提供服务（比方更改数据库引擎、更换了 FC 的服务角色、更换VPC）的危险，组件开发者未必会分明也可能会疏忽，即便分明也须要 Case By Case 的通过很多判断代码来解决，这无疑减少了组件开发的复杂度和应用老本；\如果采纳本文前言章节中形容的分层的模板化计划，以上问题就能够顺利解决： 平台团队通过封装环境模板，仅需对研发人员裸露平安的参数（比方实例规格），研发人员应用模板创立环境，填写必要的参数即可实现基础设施的搭建；通过更新环境即可自助化地实现基础设施的降级，并且不须要从新发动代码公布操作；平台团队在环境模板中申明更加严格的拜访策略，回绝某些有危险的资源操作，能够更好地管制爆炸半径；那么，接下来的问题就是：如何在 Serverless Devs 中定义环境模板？ 当 Serverless Devs 遇见 Terraform环境模板面向的是基础设施，也就是云资源。Serverless Devs 离不开对云资源的操作，传统的做法是在组件中间接应用云产品 SDK，但反对新资源时须要开发相应的组件代码，因而面临着资源扩张带来的开发效率升高以及代码越来越难以保护的问题，更好的形式是通过基础设施即代码（IaC）来实现云资源的创立。 Serverless Devs 在之前的实际中采纳 Pulumi ，通过一个独自组件实现对 Pulumi Stack 的封装，但实际下来发现，用 GPLs 来定义 IaC 还是须要模型层面良好的形象，因而将 Pulumi 推广到组件开发者，在生态成熟度以及灵活性上都不是太好。目前 IaC 生态最弱小的工具是 Terraform，已成为事实标准。Terraform HCL 自身是一种 DSL，任何生态都能很好地兼容，特地是 Provider 极其丰富。 ...

在云原生带来的云计算将来趋势下，容器曾经成为用户应用云的新界面。据 Gartner 预测，到 2023 年，70% 的组织将在生产环境中运行三个或更多容器化应用程序。容器技术和服务为企业业务倒退带来麻利高效、增强韧性、减速交融翻新三大外围价值，企业也正以越来越踊跃的态度拥抱容器。 然而在帮忙互联网、金融、游戏、制作、交通等千行百业的客户进行云原生转型的过程中，阿里云云原生团队发现，规模化治理和运行容器化利用对于很多企业来说仍是不小的挑战。 因而，阿里云云原生团队近 40 位阿里云容器服务架构师、技术、产品专家联手打造，将容器产品最佳实际出现为每次 5 分钟的系列短视频教程， 以容器服务产品实操领导演示为主，通过系统化总结阿里云容器服务应用办法和技巧，帮忙开发者晋升应用容器产品的效率，升高应用难度，心愿帮忙企业联合本身场景，基于容器服务打造业务可继续倒退的解决方案。 「5 分钟玩转阿里云容器服务」将于 6 月 21 日正式上线，同时，英文版也将于近期公布。如果在学习的过程中有什么问题，也欢送及时在视频评论区留言反馈，咱们将在后续的课程中为你解答，并随机抽取侥幸用户赠送阿里云精美周边纪念品。 6月21日(周二)18:00「5 分钟玩转阿里云容器服务」系列课程，首期重磅上线！关注【阿里云云原生】微信视频号 每周二、周四 18:00，每次 5 分钟，把握一个容器服务知识点，连忙马住！ 扫描下方二维码，立刻预约直播！ 课程劣势疾速上手，每次 5 分钟，玩转一个阿里云容器服务小技巧简略实用，35+ 课程大节，容器服务应用办法一网打尽专家教学，30+ 阿里云架构师/技术/产品专家手把手带你通关适宜人群对云上容器化有需要的人员企业 IT 施行和运维工程师微服务软件开发等相干人员课程举荐官 易立，阿里巴巴研究员，容器服务技术负责人 通过 10 余年国内最大规模集群下的技术实际积淀，阿里云容器服务已具备集高效、智能、平安、无界于一体的残缺能力，为阿里团体 100% 利用云原生化及云上 2 万多名客户提供数字翻新基座。通过 5 分钟系列课程，咱们心愿帮忙更多企业和开发者简略、疾速地把握容器技术利用能力，以更低的老本高效撑持业务交融翻新。 李国强，阿里云资深产品专家 容器技术的遍及和规模化落地是推动云原生体系倒退的外围。从 2016 年正式公布 ACK 到向 ACK Anywhere 全面降级，阿里云容器服务家族已在公共云、专有云、边缘云、本地云 等场景构建了欠缺的产品能力，咱们也将不同场景下企业的常见问题凝练为本套课程，心愿直观、乏味的短视频模式，能帮忙您更好地理解和应用阿里云容器产品。 徐果，阿里云高级解决方案架构师 随着云原生概念的蓬勃发展，越来越多的客户开始把业务迁徙到阿里云容器服务 ACK 上，ACK 的反对的性能、面向的场景、服务的客户也越来越多。然而，很多用户对 ACK 的性能理解得并不全面。本次近 40 位阿里云容器服务架构师、技术、产品专家联手打造短视频课程，咱们能让用户更加疾速、直观地看到 ACK 在社区 K8s 之上的加强能力。 近 40 位阿里云容器专家阵容，每次 5 分钟，手把手教你玩转容器服务，敬请继续关注！ 课程体系 点击此处，理解容器服务 ACK 产品详情！

6月16日-17日，由中国信息通信研究院（以下简称“中国信通院”）主办的2022精益软件工程大会以线上模式胜利举办。会上，中国信通院云大所所长何宝宏颁布了软件研发效力度量平台首批评估后果。 阿里云云效以满分问题顺利通过首批“可信云-软件研发效力度量平台”先进级评估；云效通过了由中国信通院组织的研发效力度量平台能力测评，满足全副3大能力域12小项共计294条能力项要求，首批取得先进级最高级评估，成为国内首家通过DevOps度量域所有能力评估的云厂商。 这意味着，阿里云云效具备了业内当先的软件研发效力度量能力，可能让研发效力看得见、管得了、控得住，让客户对组织、我的项目、资源、集体效力进行无效触达，实现及时、精确、主观无效的感知。 背景介绍：在软件研发畛域，有助于研发效力晋升的方法论始终在疾速倒退，在行业中也曾经有了很多落地与实际。然而，如何掂量组织或团队的研发效力在其所在行业的绝对程度？研发效力的瓶颈位于何处？如何继续优化效力？“效力度量”是答复以上问题的外围伎俩。在数字经济时代下，如何正确、迷信、无效地度量软件研发效力，并对效力晋升起到侧面疏导作用，是效力度量畛域的要害。 国内首部专一于软件研发效力度量的《云上软件研发效力度量分级模型》行业标准在2022精益软件工程大会上进行了公布和解读。该规范填补了研发效力度量规范的空白，标记着该畛域进入到了有标可依的新阶段。《云上软件研发效力度量分级模型》是可信云针对软件研发效力度量体系而制订的行业标准。可信云是中国信息通信研究院上司的云计算服务评估品牌，也是我国针对云计算服务的权威评估体系。基于以后云上软件工程的倒退现状与痛点，可信云推出软件研发效力评估体系，助力企业提质增效、进步数字化生产程度。 该标准规定了软件研发效力度量能力框架，将产研的过程与角色成员作为度量对象，在通用数据采集、加工、可视化等根底能力之上，依据组织效力、我的项目效力、资源效力、集体效力和效力评估模型进行数据的剖析计算，围绕品质、效率、老本三个维度提供无效度量指标，通过效力度量数据可视化、剖析、决策等下层应用服务帮忙用户发现问题、剖析问题和解决问题，最终通过这个循环帮忙用户可继续地、高效地、高质量地交付有价值的软件产品。 产品介绍：本次参评的是云效在研发效力度量畛域的产品汇合，它联合了阿里巴巴对内先进的治理理念和工程实际，以及对外服务不同行业客户所积淀的教训成绩；云效通过构建需要-开发-测试-公布-运维-经营端到端企业级DevOps平台，内置无效的度量模型和数据分析能力，及时帮忙研发组织裸露危险，辅助研发管理决策，继续晋升团队的研发效力。 对于云效 - 阿里云一站式DevOps平台，源于阿里巴巴多年先进的治理理念和工程实际，提供从“需要-开发-测试-公布-运维-经营”端到端的协同服务和研发工具撑持。云效将战略规划、麻利研发、继续集成、继续交付等理念引入金融、新批发、民航、汽车、服装、地产、石化等行业标杆企业和互联网初创企业，助力企业产品疾速翻新迭代，实现业务价值。 点击下方链接，即可体验云效DevOps全家桶。 https://www.aliyun.com/produc...

简介： 本文内容整顿于阿里资深技术专家姜伟华在DataFunTalk上的演讲，为大家介绍阿里巴巴基于一站式实时数仓Hologres建设实时数仓的教训和解决方案。导读：大数据计算正从规模化走向实时化，实时大数据建设过程中开始面临很多的痛点和问题。本文内容整顿于阿里资深技术专家姜伟华在DataFunTalk上的演讲，为大家介绍阿里巴巴基于一站式实时数仓Hologres建设实时数仓的教训和解决方案。 分享的内容从以下三点开展： 实时数仓的演进：一站式实时数仓Hologres：阿里通过大规模验证的实时数仓阿里CCO部门基于Hologres的一站式实时数仓建设过程与教训 点击查看视频回放：https://www.bilibili.com/vide... 作者：姜伟华（果贝） 阿里巴巴资深技术专家 ，实时数仓Hologres负责人 实时数仓的演进：一站式实时数仓1、大数据正从规模化走向实时化大数据计算正从规模化走向实时化。 随着业务的倒退，不论是实时大屏，还是智能交通、银行金融风控、或者是实时举荐都迫切的须要更实时的数据助力业务增长。 常见的实时数仓有两种场景： 面向BI或者内部人员的OLAP剖析：次要通过OLAP引擎做明细+自在剖析面向B/C端的线上服务（Serving）：通过Lambda架构预计算后写入KV零碎，通过KV零碎线上服务。两个场景用了两套架构，导致理论应用时痛点也非常明显，包含：结构复杂保护难、同步数据艰难、数据孤岛、开发成本低等，同时也须要保护很多套零碎，无奈疾速响应业务麻利需要。业务团队上手老本高，必须大数据团队撑持。 image.png 下面是咱们看到的在大数据倒退过程中的广泛现状。上面，咱们也来看看由业务催生的大数据技术发展趋势。 2、实时大数据须要麻利化 image.png 首先第一个趋势就是大数据开发须要麻利化。包含： 应用普惠化业务能自助开发：业务团队心愿本人可能来做业务开发，而不是把需要提给大数据团队排期开发。低代码：业务团队相较大数据团队的开发能力更弱，不肯定都会Java或Scala这样的语言，有的只会SQL，有的甚至SQL都不会，只会各种BI工具，所以要实现业务团队低代码开发，只须要可视化配置就能失去想要的数据。数据治理成为刚需：当把开发能力下沉到业务团队时，须要保障比拟高的数据品质，所以数据治理成为刚需，否则业务团队开发进去的后果与原始数据无奈对齐，会造成十分多的麻烦。 无学习老本像数据库一样应用大数据：大数据组件上手老本远比数据库要高，业务团队心愿自助开发，升高学习老本，最好能像数据库一样开发。规范SQL，容易上手：业务团队心愿开发方式是规范SQL，这样上手门槛更低。适配常用工具（如Tableau)：同时，业务团队心愿开发后果能够和常用工具不便对接，缩小开发量和工具学习老本。 开发麻利化写入即剖析：对业务团队来说，不心愿保护简单的链路体系，最好能写入即剖析，缩小ETL档次，缩小预聚合。存储明细数据，而非预计算后果灵便剖析，疾速上线：业务变动疾速，而预计算灵便度太差，须要更改指标计算逻辑时，须要做十分多的改变。而业务侧有很强的疾速剖析、疾速上线的诉求。 所有麻利化的需要和趋势，都依赖一款弱小的实时数仓引擎能力实现。 3、实时数仓走向在线化传统上，数仓是线下零碎，并非用于生产零碎。但随着业务的倒退，线上数据也须要更加灵便，所以越来越多的业务把实时数仓作为在线零碎来应用。所以咱们能够看到，实时数仓开始从传统的外部应用，逐步走到台前，被越来越多的ToB、ToC在线业务应用。如下图的阿里淘宝的智能客服和达摩院的小蛮驴无人配送服务，背地都依赖实时数仓技术。 image.png image.png 4、从阿里看实时数仓新趋势：一站式实时数仓所以实时数仓的发展趋势，不再是把OLAP剖析和线上服务两个场景齐全割裂，而是心愿通过一站式实时数仓去解决这个问题。业务更心愿，无论是实时写入还是离线写入，都能对立写入至一个实时数仓，而后通过这个实时数仓来对外提供线上服务和OLAP剖析两种能力。 基于此，阿里提出了一个新的理念：剖析服务一体化（Hybrid Serving/Analytics Processing, HSAP），冀望通过一个产品解决就能OLAP剖析和线上服务两个问题。HSAP是比拟技术化的概念，与之对应的业务概念就是“一站式实时数仓”。 image.png 一站式实时数仓的劣势非常明显：实时数据和离线数据对立存储、线上服务和线下剖析不割裂， 同时因为存有明细数据，所以就能麻利响应变动，能够疾速构建数据服务…… 而阿里云产品Hologres，则是HSAP理念下的最佳产物，通过了阿里多个外围场景的生产验证。上面咱们将会对其进行进一步介绍。 Hologres：阿里一站式实时数仓1、Hologres：通过阿里多个外围场景验证的一站式实时数仓基于一站式实时数仓HSAP的理念，阿里外部齐全自研了Hologres。Hologres从诞生至今已有5年多的工夫，经验了阿里外部多个外围场景的生产验证，包含淘系数字化大屏、电商剖析、阿里妈妈广告投放、智能客服、物流的菜鸟、达摩院、飞猪、饿了么等。并且也稳固撑持了历年的阿里大促场景，如双11、618等。在2021年的双11中，写入峰值达11亿+/秒，单个业务点查峰值达到上亿条/秒。OLAP剖析场景，单业务峰值达到2000+QPS，同时反对了PB级数据存储。 image.png 2、Hologres与阿里自研大数据产品矩阵深度兼容Hologres作为大数据OLAP剖析与线上服务的对立进口，一套零碎就能提供剖析和服务2种能力。依靠Hologres，再联合阿里大数据产品矩阵如DataWorks、MaxCompute、Flink、DLF等，能十分完满的反对实时离线一体、剖析服务一体、湖仓一体、流批一体等场景。 image.png 3、一站式实时数仓Hologres的演进过程对Hologres来说，最开始也并不是能齐全反对各种场景，其能力是基于业务了解和技术发展趋势一直演进的。 image.png 2020年，Hologres反对通过一套技术栈，通过行存和列存两种存储格局来别离提供线上服务和OLAP剖析两种能力。相比传统形式，最大的劣势就是对立技术栈、对立模型、对立SQL。同时也比拟不便做数据治理。然而数据须要行存列存各写一份，存在割裂，应用上还是有些不不便。 2021年，Hologres反对了行列共存的表，做到了One-Data ，Multi Workload。即一份数据供线上服务和OLAP剖析两个Workload应用。其中的行存用来给线上服务用，列存用来给OLAP用，行存和列存的数据是强统一的不须要存储多份，缩小冗余和反复导数。同时在企业级能力上提供高可用部署，反对读写拆散，无效的隔离剖析和服务两种场景，保障了线上服务的稳定性。这些能力也在2021年阿里双11生产级验证。 但咱们认为这还不是一站式实时数仓的齐全态。 2021年解决的问题是一份数据多个利用场景，而在之后要解决的问题是如何更加的简化数据加工链路，能在一个平台上把数据加工过程用SQL表达出来。比方实时物化视图。目前相干性能正在开发中。这样在横向（多种利用场景）和纵向（数据加工链路）两个维度上都实现了“一站式”。 阿里CCO一站式实时数仓建设教训Hologres反对了阿里团体内十分多的外围业务场景，比方阿里妈妈、淘宝、菜鸟等。上面咱们将会以阿里CCO为例，介绍其实时数仓建设过程中的教训和思考，以帮忙大家在建设实时数仓这条路线上走得更加便捷。 1、 CCO利用场景介绍阿里巴巴CCO全称Chief Customer Office，次要负责阿里全链路的客户体验。其次要的场景有： 客服现场调度：人工调配客服坐席，疾速响应线上问题购物链路预警：在淘系的购物链路中（曝光、点击、加购、下单、物流、售后）发现潜在问题并对客服做出预警，这样客服就能疾速响应客户的相干问题并及时处理，防止信息滞后。AI智能服务：通过AI智能客服承接淘系的在线客服答疑问题，，防止耗费过多的人力老本。 目前CCO业务背地的实时数仓，承载着上千个Flink实时工作，耗费几万CU，写入峰值4000万+条/秒，产生2000万+条/秒Binlog，有超过上千张的行存表和4000张+的列存表。尽管CCO的数据量在阿里不是最大的，然而业务链路却是最简单之一。 image.png 2、CCO实时数仓的三代倒退历程CCO的实时数仓建设也经验了传统数仓-流批一体数仓-新一代高可用数仓的3代倒退过程，且目前第三代还在一直的迭代中。 image.png 传统数仓1.0： 在2016至2017年，通过Flink实时数据加工，把预计算后果写到HBase或MySQL等KV存储中，而后对外提供查问。强调的是重加工和预计算，并且整个链路都是端到端，作业和作业之间不共享数据，就是端到端的烟囱开发。 流批一体数仓2.0：然而业务倒退太快，到2018年烟囱开发式的数仓无奈更好的承载业务需要。于是用Flink构建了实时数仓的分层（DWD/DWS/ADS)，通过音讯队列Datahub来承载。这样，不同的Flink作业之间就能够共享DWD和DWS层的实时数据。计算结果依据业务需要写入OLAP和KV两个引擎。其中OLAP引擎承载的是对内的明细查问剖析; KV引擎对外提供点查服务。 这个架构也是目前市面上比拟风行的架构，同时也有了数仓分层，能更好的为业务服务。然而在理论业务利用中，也很快遇到了问题。 于是来到了新一代高可用数仓3.0的建设： 2020年CCO开始和Hologres一起构建实时数仓3.0。实时数据通过Flink实时写入Hologres，离线数据在MaxCompute加工后也写入Hologres，在Hologres中对立存储了实时和离线数据。再通过Hologres承载OLAP剖析和线上服务两个能力。如果须要二次加工，间接通过Flink订阅Hologres Binlog。 3.0实时数仓架构相比于2.0架构，次要有以下几个劣势： 流批一体和实时离线一体。与Flink有十分好的配合，缩小了反复开发。可用性和隔离型高。与阿里外部的元数据管理体系有很好地连接。 3、技术架构降级的挑战和解法上面咱们来具体分析CCO实时数仓升级换代过程中遇见的挑战和解法。 实时数仓2.0尽管做到了流批一体，然而实质上还是一个Lambda架构，在理论应用中有很多问题： 首先看业务表象： 工作增速快，老本高：2.0时代也是淘系疾速暴发的时候，业务增长特地快，导致作业增速快，而开发成本十分高，运维压力十分大。实时数据产研效率低。每到大促，实时研发就会成为瓶颈，工作和表无对立元数据管理，灾备通过双联路实现，开发和压测老本都十分高。 ...

作者： 不瞋 当咱们构建一个利用，总是心愿它是响应迅速，老本低廉的。而在理论中，咱们的零碎却面临各种各样的挑战，例如不可预测的流量顶峰，依赖的上游服务变得迟缓，大量申请却耗费大量 CPU/内存资源。这些因素经常导致整个零碎被拖慢，甚至不能响应申请。为了让应用服务总是响应迅速，很多时候不得不预留更多的计算资源，但大部分时候，这些计算资源都是闲置的。一种更好的做法是将耗时迟缓，或者须要耗费大量资源的解决逻辑从申请解决主逻辑中剥离进去，交给更具资源弹性的零碎异步执行，岂但让申请可能被迅速解决返回给用户，也节俭了老本。 一般来说，长耗时，耗费大量资源，或者容易出错的逻辑，非常适合从申请主流程中剥离进去，异步执行。例如新用户注册，注册胜利后，零碎通常会发送一封欢送邮件。发送欢送邮件的动作就能够从注册流程中剥离进去。另一个例子是用户上传图片，图片上传后通常须要生成不同大小的缩略图。但图片解决的过程不用蕴含在图片上传解决流程中，用户上传图片胜利后就能够完结流程，生成缩略图等解决逻辑能够作为异步工作执行。这样应用服务器防止被图片解决等计算密集型工作压垮，用户也能更快的失去响应。常见的异步执行工作包含： 发送电子邮件/即时消息查看垃圾邮件文档解决（转换格局，导出，……）音视频，图片解决（生成缩略图，加水印，鉴黄，转码，……）调用内部的三方服务重建搜寻索引导入/导出大量数据网页爬虫数据荡涤……Slack，Pinterest，Facebook 等公司都宽泛的应用异步工作，实现更好的服务可用性，更低的老本。依据Dropbox 统计，他们的业务场景中一共有超过100种不同类型的异步工作。一个性能齐备的异步工作解决零碎能带来显著的收益： 更快的零碎响应工夫。将长耗时的，重资源耗费的逻辑从申请解决流程中剥离，在别的中央异步执行，能无效的升高申请响应延时，带来更好的用户体验。更好的解决大量突发性申请。在电商等很多场景下，经常有大量突发性申请对系统造成冲击。同样的，如果将重资源耗费逻辑从申请解决流程中剥离，在别的中央异步执行，那么雷同资源容量的零碎能响应更大峰值的申请流量。更低的老本。异步工作的执行时长通常在数百毫秒到数小时之间，依据不同的工作类型，正当的抉择工作执行工夫和更弹性的应用资源，就能实现更低的老本。更欠缺的重试策略和错误处理能力。工作保障被牢靠的执行（at-least-once），并且依照配置的重试策略进行重试，从而实现更好的容错能力。例如调用第三方的上游服务，如果能变成异步工作，设置正当的重试策略，即便上游服务偶然不稳固，也不影响工作的成功率。更快的实现工作解决。多个工作的执行是高度并行化的。通过伸缩异步工作解决零碎的资源，海量的工作可能在正当的老本内更快的实现。更好的工作优先级治理和流控。工作依据类型，通常依照不同的优先级解决。异步工作管理系统能帮忙用户更好的隔离不同优先级的工作，既让高优先级工作能更快的被解决，又让低优先级工作不至于被饿死。更多样化的工作触发形式。工作的触发形式是多种多样的，例如通过 API 间接提交工作，或是通过事件触发，或是定时执行等等。更好的可观测性。异步工作解决零碎通常会提供工作日志，指标，状态查问，链路追踪等能力，让异步工作更好的被观测、更容易诊断问题。更高的研发效率。用户专一于工作解决逻辑的实现，任务调度，资源扩缩容，高可用，流控，工作优先级等性能都由工作解决零碎实现，研发效率大幅提高。工作解决零碎架构工作解决零碎通常包含三局部：工作 API 和可观测，工作散发和工作执行。咱们首先介绍这三个子系统的性能，而后再探讨整个零碎面临的技术挑战和解决方案。 工作 API/Dashboard该子系统提供一组工作相干的 API，包含工作创立、查问、删除等等。用户通过 GUI，命令行工具，后者间接调用 API 的形式应用零碎性能。以 Dashboard 等形式出现的可观测能力也十分重要。好的工作解决零碎该当包含以下可观测能力： 日志：可能收集和展现工作日志，用户可能疾速查问指定工作的日志。指标：零碎须要提供排队工作数等要害指标，帮忙用户疾速判断工作的执行状况。链路追踪：工作从提交到执行过程中，各个环节的耗时。比方在队列中排队的工夫，理论执行的工夫等等。下图展现了 Netflix Cosmos 平台的 tracing 能力。 工作散发工作散发负责工作的调度散发。一个能利用于生产环境的工作散发零碎通常要具备以下性能： 工作的牢靠散发：工作一旦提交胜利后，无论遇到任何状况，零碎都该当保障该工作被调度执行。工作的定时/延时散发：很多类型的工作，心愿在指定的工夫执行，例如定时发送邮件/音讯，或者定时生成数据报表。另一种状况是工作能够延时较长一段时间执行也没问题，例如上班前提交的数据分析工作在第二天下班前实现即可，这类工作能够放到凌晨资源耗费低峰的时候执行，通过错峰执行降低成本。工作去重：咱们总是不心愿工作被反复执行。除了造成资源节约，工作反复执行可能造成更重大的结果。比方一个计量工作因为反复执行算错了账单。要做到工作只执行一次（exactly-once），须要在工作提交，散发，执行全链路上的每个环节都做到，包含用户在实现工作解决代码时也要在执行胜利，执行失败等各种状况下，做到 exactly-once。如何实现残缺的 exactly-once 比较复杂，超出了本文的探讨范畴。很多时候，零碎提供一个简化的语义也很有价值，即工作只胜利执行一次。工作去重须要用户在提交工作时指定工作 ID，零碎通过 ID来判断该工作是否曾经被提交和胜利执行过。工作谬误重试：正当的工作重试策略对高效、牢靠的实现工作十分要害。工作的重试要思考几个因素：1）要匹配上游工作执行零碎的解决能力。比方收到上游工作执行零碎的流控谬误，或者感知到工作执行成为瓶颈，须要指数退却重试。不能因为重试反而加大了上游零碎的压力，压垮上游；2）重试的策略要简略清晰，易于用户了解和配置。首先要对谬误进行分类，辨别不可重试谬误，可重试谬误，流控谬误。不可重试谬误是指确定性失败的谬误，重试没有意义，比方参数谬误，权限问题等等。可重试谬误是指导致工作失败的因素具备必然性，通过重试工作最终会胜利，比方网络超时等零碎外部谬误。流控谬误是一种比拟非凡的可重试谬误，通常意味着上游曾经满负荷，重试须要采纳退却模式，管制发送给上游的申请量。工作的负载平衡：工作的执行工夫变化很大，短的几百毫秒，长的数十小时。简略的 round-robin 形式散发工作，会导致执行节点负载不均。实际中常见的模式是将工作搁置到队列中，执行节点依据本身工作执行状况被动拉取工作。应用队列保留工作，让依据节点的负载把工作散发到适合的节点上，让节点的负载平衡。工作负载平衡通常须要散发零碎和执行子系统配合实现。工作按优先级散发：工作解决零碎通常对接很多的业务场景，他们的工作类型和优先级各不相同。位于业务外围体验相干的工作执行优先级要高于边缘工作。即便同样是音讯告诉，淘宝上买家收到一个商品评论告诉的重要性必定低于新冠疫情中的核酸检测告诉。但另一方面，零碎也要放弃肯定水平的偏心，不要让高优先级工作总是抢占资源，而饿死低优先级工作。工作流控：工作流控典型的应用场景是削峰填谷，比方用户一次性提交数十万的工作，冀望在几个小时内缓缓解决。因而零碎须要限度工作的散发速率，匹配上游工作执行的能力。工作流控也是保障系统可靠性的重要伎俩，某类工作提交量忽然爆发式增长，零碎要通过流控限度其对系统的冲击，减小对其余工作的影响。批量暂停和删除工作：在理论生产环境，提供工作批量暂停和删除十分重要。用户总是会呈现各种情况，比方工作的执行呈现了某些问题，最好能暂停后续工作的执行，人工查看没有问题后，再复原执行；或者长期暂停低优先级工作，开释计算资源用于执行更高优先级的工作。另一种状况是提交的工作有问题，执行没有意义。因而零碎要能让用户十分不便的删除正在执行和排队中的工作。工作的暂停和删除须要散发和执行子系统配合实现。工作散发的架构可分为拉模式和推模式。拉模式通过工作队列散发工作。执行工作的实例被动从工作队列中拉取工作，处理完毕后再拉取新工作。绝对于拉模式，推模式减少了一个分配器的角色。分配器从工作队列中读取工作，进行调度，推送给适合的工作执行实例。 拉模式的架构清晰，基于 Redis 等风行软件能够疾速搭建工作散发零碎，在简略工作场景下体现良好。但如果要反对工作去重，工作优先级，批量暂停或删除，弹性的资源扩缩容等简单业务场景须要的性能，拉模式的实现复杂度会迅速减少。实际中，拉模式面临以下一些次要的挑战。 资源主动伸缩和负载平衡简单。工作执行实例和工作队列建设连贯，拉取工作。当工作执行实例规模较大时，对工作队列的连贯资源会造成很大的压力。因而须要一层映射和调配，工作实例只和对应的工作队列连贯。下图是 Slack 公司的异步工作解决零碎架构。Worker 节点只和局部 Redis 实例相连。这解决了 worker 节点大规模扩大的能力，然而减少了调度和负载平衡的复杂度。 从反对工作优先级，隔离和流控等需要的角度思考，最好能应用不同的队列。但队列过多，又减少了治理和连贯资源耗费，如何均衡很有挑战。工作去重，工作批量暂停或者删除等性能依赖音讯队列性能，但很少有音讯类产品能满足所有需要，经常须要自行开发。例如从可扩展性的角度，通常做不到每一类工作都对应独自的工作队列。当工作队列中蕴含多种类型的工作时，要批量暂停或者删除其中某一类的工作，是比较复杂的。工作队列的工作类型和工作解决逻辑耦合。如果工作队列中蕴含多种类型的工作，要求工作解决逻辑也要实现相应的解决逻辑，对用户不敌对。在实践中，A 用户的工作解决逻辑不会预期接管到别的用户工作，因而工作队列通常由用户自行治理，进一步减少了用户的累赘。推模式的核心思想是将工作队列和工作执行实例解耦，平台侧和用户的边界更加清晰。用户只须要专一于工作解决逻辑的实现，而工作队列，工作执行节点资源池的治理都由平台负责。推模式的解耦也让工作执行节点的扩容不再受工作队列的连贯资源等方面的限度，可能实现更高的弹性。但推模式也引入了很多的复杂度，工作的优先级治理，负载平衡，调度散发，流控等都由分配器负责，分配器须要和上下游零碎联动。 总的来说，当工作场景变得复杂后，无论拉还是推模式，零碎复杂度都不低。但推模式让平台和用户的边界更清晰，简化了用户的应用复杂度，因而有较强技术实力的团队，实现平台级的工作解决零碎时，通常会抉择推模式。 工作执行工作执行子系统治理一批执行工作的 worker 节点，以弹性、牢靠的形式执行工作。典型的工作执行子系统需具备如下性能： 工作的牢靠执行。工作一旦提交胜利，无论任何状况，零碎该当保障工作被执行。例如执行工作的节点宕机，工作该当调度到其余的节点执行。工作的牢靠执行通常是工作散发和工作执行子系统独特配合实现。共享资源池。不同类型的工作解决资源共享对立的资源池，这样能力削峰填谷，进步资源利用效率，降低成本。例如把计算密集，io密集等不同类型的任务调度到同一台 worker 节点上，就能更充沛的利用节点上的CPU，内存，网络等多个维度的资源。共享资源池对容量治理，工作资源配额治理，工作优先级治理，资源隔离提出了更高的要求。资源弹性伸缩。零碎能依据负载的执行状况伸缩执行节点资源，降低成本。伸缩的机会和数量十分要害。常见的依据工作执行节点的 CPU，内存等资源水位状况伸缩，工夫较长，不能满足实时性要求高的场景。很多零碎也应用排队工作数等指标进行伸缩。另一个值得关注的点是执行节点的扩容须要匹配上下游零碎的能力。例如当工作散发子系统应用队列来散发工作时，worker 节点的扩容要匹配队列的连贯能力。工作资源隔离。在 worker 节点上执行多个不同的工作时，资源是互相隔离的。通常应用容器的隔离机制实现。工作资源配额。用户的应用场景多样，经常蕴含多种工作类型和优先级。零碎要反对用户为不同优先级的工作或者处理函数设置资源配额，为高优先级工作预留资源，或者限度低优先级工作能应用的资源。简化工作解决逻辑的编码。好的工作解决零碎，可能让用户专一于实现单个工作解决逻辑，零碎主动并行、弹性、牢靠的执行工作。平滑降级。底层零碎的降级不要中断长时工作的执行。执行后果告诉。实时告诉工作执行状态和后果。对于执行失败的工作，工作的输出被保留到死信队列中，不便用户随时手动重试。工作执行子系统通常应用 K8s 治理的容器集群作为资源池。K8s 可能治理节点，将执行工作的容器实例调度到适合的节点上。K8s 也内置了作业（Jobs）和定时作业（Cron Jobs）的反对，简化了用户应用 Job 负载的难度。K8s 有助于实现共享资源池治理，工作资源隔离等性能。但 K8s 次要能力还是在POD/实例治理上，很多时候须要开发更多的性能来满足异步工作场景的需要。例如： ...

作者：凡勇 什么是压测压测，即压力测试，是确立零碎稳定性的一种测试方法，通常在零碎失常运作范畴之外进行，以考查其性能极限和和可能存在的隐患。 压测次要用于检测服务器的承受能力，包含用户承受能力，即多少用户同时应用零碎时根本不影响品质、流量接受等。另外，通过诸如疲劳测试还能发现零碎一些稳定性的问题，比方是否存在连接池中的连贯被耗尽，内存被耗尽，线程池被耗尽，这些只能通过疲劳测试来进行发现定位。 为什么要压测压测的目标就是通过模仿实在用户的行为，测算出机器的性能(单台机器的 QPS、TPS)，从而推算出零碎在接受指定用户数(100 W)时，须要多少机器能撑持得住。因而在进行压测时肯定要当时设定压测目标值，这个值不能太小，也不能太大，依照目前业务预估的增长量来做一个正当的评估。压测是在上线前为了应答将来可能达到的用户数量的一次预估(提前演练)，压测当前通过优化程序的性能或筹备短缺的机器，来保障用户的体验。压测还能探测利用零碎在呈现交易洪峰时稳定性状况，以及可能呈现的一些问题，发现利用零碎单薄一环，从而更有针对性地进行增强。 压测分类 这几种测试能够交叉进行，个别会在压力测试性能指标达标后，再安顿耐久性测试。 压测名词解释 常见的压测工具abApacheBench 是 Apache 服务器自带的一个 web 压力测试工具，简称 ab。ab 又是一个命令行工具，对发动负载的本机要求很低，依据 ab 命令能够创立很多的并发拜访线程，模仿多个访问者同时对某一 URL 地址进行拜访，因而能够用来测试指标服务器的负载压力。总的来说 ab 工具玲珑简略，上手学习较快，能够提供须要的根本性能指标，然而没有图形化后果，不能监控。 JmeterApache JMeter 是 Apache 组织开发的基于 Java 的压力测试工具。用于对软件做压力测试，它最后被设计用于 Web 利用测试，但起初扩大到其余测试畛域。 JMeter 可能对应用程序做性能/回归测试，通过创立带有断言的脚本来验证你的程序返回了你冀望的后果。 JMeter 的性能过于弱小，这里临时不介绍用法，能够查问相干文档应用(参考文献中有举荐的教程文档) LoadRunnerLoadRunner 是 HP(Mercury)公司出品的一个性能测试工具，性能十分弱小，很多企业级客户都在应用，具体请参考官网链接。 阿里云PTS性能测试 PTS（Performance Testing Service）是一款性能测试工具。反对按需发动压测工作，可提供百万并发、千万 TPS 流量发动能力，100% 兼容 JMeter。提供的场景编排、API 调试、流量定制、流量录制等性能，可疾速创立业务压测脚本，精准模仿不同量级用户拜访业务零碎，帮忙业务疾速晋升零碎性能和稳定性。 作为阿里外部应用多年的性能测试工具，PTS 具备如下个性： 免运维、开箱即用。SaaS化施压、最大反对百万级并发、千万级TPS流量自助发动能力。反对多协定HTTP1.1/HTTP2/JDBC/MQTT/Kafka/RokectMq/Redis/Websocket/RMTP/HLS/TCP/UDP/SpringCloud/Dubbo/Grpc 等支流协定。反对流量定制。寰球施压地区定制/运营商流量定制/IPv6 流量定制。稳固、平安。阿里自研引擎、多年双十一场景打磨、反对 VPC 网络压测。性能压测一站式解决方案。** 0 编码构建简单压测场景，笼罩压测场景构建、压测模型设定、发动压力、剖析定位问题、出压测报告残缺的压测生命周期。100% 兼容开源 JMeter。提供平安、无侵入的生产环境写压测解决方案。压测工具的比拟 如何抉择压测工具这个世界上没有最好的工具，只有最适宜的工具，工具千千万，抉择一款适宜你的才是最重要的，在理论应用中有各种场景，读者能够联合压测步骤来确定适宜本人的工具： 确定性能压测指标：性能压测指标可能源于我的项目打算、业务方需要等确定性能压测环境：为了尽可能施展性能压测作用，性能压测环境该当尽可能同线上环境统一确定性能压测通过规范：针对性能压测指标以及选取的性能压测环境，制订性能压测通过规范，对于不同于线上环境的性能压测环境，通过规范也该当适度放宽设计性能压测：编排压测链路，结构性能压测数据，尽可能模仿实在的申请链路以及申请负载执行性能压测：借助性能压测工具，依照设计执行性能压测剖析性能压测后果报告：剖析解读性能压测后果报告，断定性能压测是否达到预期指标，若不满足，要基于性能压测后果报告剖析起因由上述步骤可知，一次胜利的性能压测波及到多个环节，从场景设计到施压再到剖析，缺一不可。工欲善其事，必先利其器，而一款适合的性能工具意味着咱们可能在尽可能短的工夫内实现一次正当的性能压测，达到事倍功半的成果。 JAVA 利用性能问题排查指南问题分类问题不拘一格，各种各样的问题都会有。对其进行形象和分类是十分必要的。这里将从两个维度来对性能问题进行分类。第一个维度是资源维度，第二个维度是频率维度。 资源维度类的问题：CPU 冲高，内存使用不当，网络过载。 频率维度类的问题：交易持续性迟缓，交易偶发性迟缓。 对于每一类问题都有相应的解决办法，办法或者工具使用不当，会导致不能疾速而且精准地排查定位问题。 压测性能问题定位调优是一门须要多方面综合能力联合的一种技术工作，须要凭借集体的技术能力、教训、有时候还须要一些直觉和灵感，还须要肯定的沟通能力，因为有时候问题并不是由定位问题的人发现的，所以须要通过一直地沟通来发现一些蛛丝马迹。波及的技术知识面远不仅限于程序语言自身，还可能须要扎实的技术基本功，比方操作系统原理、网络、编译原理、JVM 等常识，决不只是简略的理解，而是真正的把握，比方 TCP/IP，必须得深刻把握。JVM 得深刻把握内存组成，内存模型，深刻把握 GC 的一些算法等。这也是一些初中级技术人员在一遇到性能问题就傻眼，齐全不晓得如何从哪里下手。如果领有扎实的技术基本功，再加上一些实战经验而后造成一套属于本人的打法，在遇到问题后能力心中不乱，疾速拨开迷雾，最终找到问题的症结。 ...

简介： 收费体验！阿里云智能logo设计始终致力于用AI技术，帮忙更多有设计需要的敌人能“多快好省”地做logo，让“设计logo”这件有门槛的事件，通过智能工具能轻松打造。称心再付款，首单仅需9.9元。阿里云智能logo设计，为用户生成logo冲破200万件啦！ 感激各位朋友的一路反对，阿里云智能logo设计始终致力于用AI技术，帮忙更多有设计需要的敌人能“多快好省”地做logo，让“设计logo”这件有门槛的事件，通过智能工具能轻松打造。 通过屡次用户调研，咱们将大家对logo的需要次要聚焦在精准匹配、精美难看、个性化筛选、便于注册商标、交付丰盛可视这五个次要方面。上面就为大家具体介绍下本次的五大产品升级。 降级聚焦一：让AI更懂你 AI语义辨认+行业偏好举荐 智能logo只输出名称、行业、形容等根本信息，怎么生成更懂用户的logo呢？ 1、在线填写logo信息.gif 看似简略的信息，能够通过AI自然语言解决技术（NLP）拆分为多个词语，再由算法剖析进行词意联想，简略的关键词就能够被辨认为更丰盛的形容进行平面解读。 2、在线极速智造.gif 加上咱们在不同行业和场景下积淀的数据模型，不仅能够训练语义剖析的准确度，还能够联合风行趋势，为用户提供细分行业热门的logo举荐，让AI更懂你的需要。 降级聚焦二：颜值更好更好看 海量精美模板，每天新增 数千款阿里设计标准的精美模板，笼罩各个行业各种格调，每日都有新增，让你每次关上阿里云智能logo设计时，都能有新的惊喜。 logo案例美食+科技.gif 降级聚焦三：共性格调随心选 共性筛选 色彩字体随心“换换” 新增的“格调筛选”性能，能够帮忙大家疾速筛选心仪的logo，间接抉择你要的色彩、字体、格调，高效便捷。 5、换一换.gif 看到喜爱的logo，试下新增的性能“换换”，一键生成多种抉择，换色彩、换字体、换款式，疾速找到最心仪的logo，个性化筛选，让聚焦再聚焦。 VI场景丰盛多样 成果剑拔弩张 每个生成的logo都有数十种VI利用款式，办公用品、户外广告、品牌周边…可直观感触logo在各种场景下的成果，个性化的丰盛利用成果，帮忙用户进行判断。 4、多场景效果图展现.gif 降级聚焦四：便于注册商标 商标名称检索，中转 “同名商标”注册状况 对于有注册商标需要的客户，可在logo生成后果页一键抉择“可注册商标”。 碰见心仪的logo，详情页新增的“商标名称检索”，能够看到logo同名商标的注册状况，帮忙用户轻松判断logo在指标市场的注册危险，并做相应的设计调整。 商标示范.gif 商用字体永恒受权 下载即用 购买后，咱们将提供logo名称的字体受权和版权证实，永恒受权，商用无忧，无需再为字体二次付费。 9、版权存证下载.gif 降级聚焦五：交付丰盛可视 交付内容全面，所见即所得 智能logo设计分为优享包和品牌包两个档位。 优享包：高清logo、源文件、商标注册专用图和正版受权证书，满足大部分用户需要，首购用户仅需9.9元； 品牌包：优享包+VI标准和场景利用图，满足品牌流传和更多场景应用需要，首购用户仅需99.9元。 所有成果详情页直观展现，所见即所得。 服务包成果.gif 以上就是阿里云智能logo设计的五大产品升级，欢送大家来体验降级后的产品，挖掘更多惊喜的优化细节，并为咱们提出贵重的倡议和意见。 点击下方海报，扫描二维码，间接体验智能logo设计挪动端，或登录阿里云logo.aliyun.com，体验智能logo设计PC端。 image.png AI让设计更轻松，期待您的反馈，与咱们一起打造更加懂你的智能logo设计吧～ 原文链接：http://click.aliyun.com/m/100... 本文为阿里云原创内容，未经容许不得转载。

简介： 专有云已从概念走向落地实际。由云计算规范和开源推动委员会举办的“专有云技术主题沙龙”，除对专有云规范体系等进行解读外，还邀请了业内大咖倾情分享，独特摸索专有云将来发展趋势。banner.jpg 随着十四五布局强调打造数字经济新劣势，将云计算列为数字经济重点产业，明确了以混合云为重点的云服务产业倒退路线：“以混合云为重点培养行业解决方案、系统集成、运维治理等云服务行业”，混合云成为产业内泛滥服务商和政企客户关注的焦点。 2022年6月8日，由中国信息通信研究院、中国通信标准化协会主办，云计算规范和开源推动委员会承办的“专有云技术沙龙”线上直播圆满结束。本次沙龙除对专有云规范体系等进行解读外，还邀请了业内大咖倾情分享，独特摸索专有云将来发展趋势。 阿里云混合云产品解决方案总经理李亮，与会并分享了「混合云建管用一体化摸索实际」。论述了阿里云混合云如何通过提供全栈建云、智能管云、极致用云一体化解决方案、欠缺的混合云服务和凋谢的混合云生态，助力政企应答数字化转型难题。 image.png 现在，越来越多的企业认同，混合云是实现数字化改革的必由之路。但因为每个企业所处的数字化阶段不同、需要各异，所以混合云建设的门路、办法和过程也不尽相同。在实现利用现代化的过程中，企业的IT管理者该如何抉择一条最适宜本人的技术转型路线呢？ 毫无疑问，只有打好数字基础设施的根基，能力进一步加强业务的韧性，有效应对日益简单的利用需要，实现业务的翻新与可持续增长。 李亮指出：作为推动政企数字化转型的外围基础设施，阿里云混合云（Apsara Stack）是业界最早践行公共云和专有云“同一架构”理念的云厂商，采纳历经13年打磨的飞天云计算操作系统，与公共云同根同源，是国内首个全自研大规模成熟商用的原生混合云，且历经多年“双11”测验，集全栈建云、智能管云、极致用云于一体的全栈云平台。 image.png 全栈建云以飞天3.0为外围的阿里云混合云，具备“一云多芯”的能力，全面兼容X86、ARM等多种芯片全场景混部（Region内混部、同城容灾混部、跨Region混部）和对立调度。同时，阿里云混合云能够为政企客户构建大规模的跨地区多数据中心的“一朵云”， 突破地区限度，依照客户需要进行分层部署，分层为多个Region，各个Region之间互相关联、对立治理。 具备全场景容灾能力，反对传统的两地三核心架构&翻新的同城三机房架构，实现外围业务RPO=0。 历经8年行业深耕，阿里云混合云通过公安部等保三级、可信云认证、ISO27001、CSA等泛滥权威机构认证，是国内首家通过商用明码利用安全性评估的云厂商，为客户构建了全方位平安防护体系。 智能管云此外，阿里云混合云提供对立的混合云治理平台，反对云资源智能治理和云平台自动化运维。凋谢的OpenAPI平台提供丰盛的SDK包和RESTful API接口。对于运维治理，通过OpenAPI获取云平台的根底管控信息，能够实现自定义管控零碎的研发。 极致用云阿里云混合云提供云原生利用全生命周期治理，帮忙构建 “双敏”研发能力，实现十倍研发效力晋升；提供面向利用的新一代运维平台以及数字化业务系统安全工程。 在帮忙政企迁云方面，阿里云混合云提供了一个涵盖云上网络布局、利用平迁、跨平台迁徙、数据库迁徙/替换、海量非结构化存储数据迁云的一站式业务上云平台，实现业务单元化、异地多活、利用就近接入等最优体验。 目前，阿里云混合云领有80多个全栈云产品，单集群最大规模达到1万台，可跨集群、跨机房进行云计算及大数据处理。基于底层飞天零碎的对立框架，为客户提供一体化、高集成的技术架构，反对面向未来的业务翻新和持续增长提供灵便的扩大。同时，还从硬件认证、利用生态和联结解决方案三个层面与各行业合作伙伴一起共建共享混合云开放平台。 阿里云混合云（Apsara Stack）建管用一体化的全栈混合云平台，助力企业级客户全栈建云、智能管云、极致用云，致力于成为#政企数智翻新的同行者#！ 更多品牌资讯欢送返回【阿里云混合云】官网（https://www.aliyun.com/soluti...）。 原文链接：http://click.aliyun.com/m/100...本文为阿里云原创内容，未经容许不得转载。

大家好！咱们是阿里云云效智能代码天团！旨在用人工智能解放各位开发者的生产力！或者你们关注过咱们的话会晓得，咱们有一个超酷的产品它叫Alibaba Cloud AI Coding Assistant，小名儿叫Cosy。说起这代码补全和代码搜寻那可是样样精通() 咱们不仅把文档搬进了你的IDE，甚至还把StackOverflow也搬了进来，助力各位在开发旅途中不孤独，实时感触与大佬们结对编程的高兴。 继5月20日公布最爱你的智能编码助手之后，Alibaba Cloud AI Coding Assistant新版本0.10.3-beta版本公布啦！ 这一次的Cosy既晋升了颜值，扩充了搜寻范畴，并！且！成熟的Cosy补全零碎目前曾经可能自我感知主机性能，主动调节补全的速度和长度( *｀´) 是不是很酷！是不是听起来就很厉害！不要急，且听我再为你细细道来咱们还做了什么—— 本期的Changelog恰逢刚完结高考，咱们也思念一下青春来温习一下语文。此处本手是修Bug，妙手是新增性能： 【六脉和谐】防止列编辑和模版同时输出时的补全抵触【飞刍挽粮】给予设施性能主动调节补全配置【随方逐圆】新增补全自定义配置【唯快不破】反对控制台报错问答搜寻、通过正文快捷搜寻文档【管中窥豹】新增全文预览【五谷丰登】减少文档数据源筛选，补充中英文文档数据【…………】修复若干bug 此处有来自高考语文140+的算法小姐姐的大佬の注视(●--●)还不快用起来沾沾喜气！ 裁减中英文文档数据Cosy本期裁减了阿里云产品文档数据以及CSDN中文博客数据，联合原有的StackOverflow问答文档，目前已有三大数据源，后续咱们也会继续不间断裁减数据起源。 与StackOverflow不同，许多文档起源没有凋谢版权，当用户点击文档题目后，Cosy会在IDE面板外部用挪动端的形式关上网页，拜访文档起源： 新增数据源筛选随着文档数据源的增多，交互界面提供了文档数据范畴筛选： 控制台报错疾速搜寻文档本次更新还提供了一个酷炫的文档搜寻性能，当控制台呈现报错时，点击报错信息旁边的Cosy图标，便能够疾速触发文档搜寻，帮忙用户解决问题： 新增浏览全文蒙版新增了文档搜寻后果中的“开展全文”蒙版，使文档后果更加紧凑，防止过长内容影响浏览： 新增了设计小姐姐做的难看的Loading GIF 新增补全个性化配置用户们对补全的个性化配置呼声由来已久，不同环境、不同机器的性能以及用户对补全的不同需要促使咱们设计了个性化配置性能。 如果你不关怀补全的配置，能够抉择【主动模式】，Cosy会思考性能的前提下提供最优质的补全后果（补的越长、补的越多）；抉择【速度优先】，Cosy会尽量用更小的内存，在更快的速度将补全后果返回给用户；抉择【整行优先】，Cosy会略微多斟酌一会，尽量将补全的长度减少。 防止列编辑和模版同时输出时的补全抵触当命中IDEA自带的模板时，Cosy将跳过补全，防止给用户造成烦扰： 在多行编辑的时候防止补全（感激GitHub上 @lldacing 用户的反馈）： 彩蛋夏天来啦，咱们也换了首诗送给你们。 杭州入梅了，在敌人们都纷纷表示“我裂开了”“黏糊糊洗不洁净的日子又来了”的时候，我反而感觉—— Im Sommer ißt man grüne Bohnen,Pfirsiche, Kirschen und Melonen.In jeder Hinsicht schön und lang,bilden die Tage einen Klang. 夏天是吃绿豆、桃子、樱桃和甜瓜的节令，各种意义上都漫长且欢快，日子发出声响。 祝你们也有每天都陈腐爽脆，看夕阳时被风拂过衣角的完满夏天:-） 点击下方链接，即可体验阿里云智能编码插件Cosy。 https://developer.aliyun.com/...

作者：莫源 前言中华财险是国内互联网金融行业的领导者，在企业云原生上云的过程中，实现了大量多租SaaS化业务的微服务化和容器化。其业务具备十分典型的金融属性，对架构稳定性、资源老本效率、数据安全等方面都提出了更高的要求和挑战，须要在实现降本增效的同时兼顾业务稳定性。在迁徙的过程中，遇到了多租业务清理老本难、闲置/浪费资源发现难、优化策略与业务稳定性均衡难等挑战。中华财险工程师团队基于阿里云企业云原生IT老本治理计划积淀了一套成熟的IT企业老本治理流程与零碎，通过开箱即用的业务老本拆分、闲置资源可视化发现、弹性伸缩与混部等优化策略，将集群的闲置资源率从上云前的30%优化到10%以内。 中华财险的上云IT老本治理工作也荣获信通院2022年度云管和云网优良案例：https://mp.weixin.qq.com/s/XB... 中华财险的云原生之路云原生上云是目前企业上云的最佳门路，中华财险作为国内互联网金融行业的领导者也在驱动业务通过微服务化、云原生化的形式实现数字化转型。在云原生上云之前，中华财险的业务存在如下问题： 业务资源的管理权限扩散在各个团队，生产环境和测试环境下沉在业务团队，业务团队为长期验证的版本冗余了大量的资源。局部业务有显著的周期性，峰谷容量相差较大，造成资源低负载运行工夫较长。压测环境单位工夫内须要大量的长期机器，复用闲置资源须要腾挪机器、协调跨团队资源，流程和老本较高。短少可量化的指标发现业务的节约，单纯的利用率指标不能作为节约的评判规范。为了解决上述问题，中华财险工程师团队通过业务的微服务化、容器化的形式，将业务迁徙到了阿里云容器服务之上，基于阿里云企业云原生IT老本治理计划积淀了一套成熟的IT企业老本治理流程与零碎，将IT老本的治理周期从原来的季度、月度，升高到了周、天。通过开箱即用的老本可视化与摊派能力，实时掂量团队资源节约状况，实现数字化的降本增效。 上面是一些优化过程中的要害门路： 通过命名空间进行多租业务的逻辑治理、财资拆分、节约掂量中华财险工程师团队将多租的SaaS化业务通过命名空间作为逻辑单元在同一个集群中进行对立治理，通过调整Request与Limit之间的比例，将原有独立容量治理的模型，转变为池化对立治理，晋升资源的利用率。通过阿里云企业云原生IT老本治理计划提供的命名空间成本核算的能力，在一个集群内能够轻松实现不同业务的费用摊派，实现容量治理与财资治理。 通过ACK老本剖析发现集群节约状况以及各利用老本散布 全量路压测进行容量预估与可靠性验证在进行云原生化的过程中，中华财险工程师团队发现，业务团队提交的容量估算与理论的资源应用存在比拟大的偏差。因而，在上云的过程中，中华财险工程师团队通过应用PTS（阿里云全链路压测服务）高仿真模仿环境全链路压测，确定零碎水位和瓶颈，正当预估资源需要，将老本规模通过数字化的指标进行了建模，在保障集群容量可靠性的前体下，实现了老本规模的管制。 建设老本节约的衡量标准，发现节约状况单纯通过资源利用率的数值来判断业务是否存在节约从理论场景上来看是不够有说服力的，业务团队冗余容量的策略个别会基于业务峰值的状况、程序高效运行的利用率区间、将来业务倒退的状况等因素。在传统的老本治理周期以月度、季度甚至年度等更长时间的状况下，冗余是保障稳定性的最佳抉择。为了解决这个问题，中华财险工程师团队提出了利用节约度模型，通过联合资源利用率、波峰波谷振幅、业务断路器引入、业务老本趋势变动等多个因素进行整合，数字量化节约比例，无效的发现了集群内的实在节约状况。 通过 ACK 老本剖析发现集群利用的节约状况 分时混部在线业务与长期业务错峰应用在中华财险的业务场景中，有大量的长期工作、仿真工作，这些工作具备周期短、资源耗费低等个性，中华财险工程师团队发现集群的实在使用率在白天始终处在比拟低的程度，而闲暇的工夫足够仿真工作和长期工作的执行。此外，在应用分时复用的时候，还配合了快上快下的抢占策略，既保障了集群的整体利用率晋升，又可能在突增流量到来的时候，下线长期作业保障业务的整体的稳定性。 定时伸缩实现外围业务资源预供应中华财险有些业务存在显著的周期性和波峰波谷，资源比例相差数倍，在保障肯定冗余的状况下，通过应用定时伸缩的形式，能够让出更多的集群的调度资源，让其余的长期作业能够跑得更快。 闲置资源回收与业务弹性交付当资源池化后，因为不必节点的调度策略打标和束缚，会造成局部节点的调度水位较低，通过辨认长时间低水位的节点的形式，能够发现集群中的闲置资源状况，升高资源节约。并把一些低频度的资源交付通过弹性的形式进行优化，实现老本效率的进一步晋升。 中华财险基础设施团队一路走来，经验了线上生产业务从传统IT架构到上云、上云原生的过程，在这个云原生化的过程中，中华财险的业务量也翻了数倍。通过云老本优化的一系列措施，某业务容器化后总升高配置：232C 400G ，节俭约7台 32C 64G 的ECS的云计算资源，升高了约20%的服务器老本。在进行了混部、业务顶峰低谷的弹性伸缩等优化后，均匀老本优化率可达约15%。 最初从某种角度而言，中华财险基础设施团队的架构优化策略是十分奢侈和实用的，通过数字化、模型化、可视化企业IT老本，用数据领导和优化IT老本治理，将集群的闲置资源率从上云前的30%优化到10%以内。企业IT老本治理向来不是新技术的试验场，抉择适合本身状况的计划，用数据量化后果，有理有据地驱动企业降本增效。 相干文章：《阿里云首家通过《可信云·云老本优化工具能力要求》评估，云原生企业 IT 老本治理计划助力企业 FinOps

前言之前写过K8S应用阿里云存储卷,并在helm装置redis、rabbitmq和elasticsearch的过程中应用alicloud-nas-fs，然而预先发现，每次装置都会反复生成NAS，然而NAS每个账号最多增加20个，所以这不合乎需要，通过跟阿里工程师的沟通之后，他们举荐应用CNFS来做为存储媒介，所有服务都共享同一个NAS文件系统，当初记录下来分享给大家。 CNFS概述传统的共享文件系统存在短少容量配额的准确管制、无奈复原误删文件、缺失存储卷容量性能等监控指标、无平安加密及小文件读写提早等问题。阿里云容器服务ACK推出了容器网络文件系统CNFS晋升NAS文件系统的性能，QoS管制。本文介绍容器网络文件系统CNFS的性能、存储规格、实用场景、应用限度及计费阐明。 应用CNF这个是官网提供的操作文档：应用CNFS托管NAS文件系统，咱们只有看形式一：应用CNFS创立默认NAS文件系统即可。 # 创立CNFS、storageclass和deployment、statefulset对象。cat << EOF | kubectl apply -f -apiVersion: storage.alibabacloud.com/v1beta1kind: ContainerNetworkFileSystemmetadata: name: cnfs-nas-filesystemspec: description: "cnfs" type: nas reclaimPolicy: Retain #只反对Retain策略，删除CNFS时并不会删除NAS文件系统。 parameters: encryptType: SSE-KMS #可选参数，不指定示意对文件不应用NAS托管加密，指定SSE-KMS示意开启此性能。 enableTrashCan: "true" #可选参数，不指定示意不关上回收站性能，指定true示意开启此性能。---apiVersion: storage.k8s.io/v1kind: StorageClassmetadata: name: alibabacloud-cnfs-nasmountOptions: - nolock,tcp,noresvport - vers=3parameters: volumeAs: subpath containerNetworkFileSystem: cnfs-nas-filesystem path: "/"provisioner: nasplugin.csi.alibabacloud.comreclaimPolicy: RetainallowVolumeExpansion: true #可选参数，指定为true示意容许对NAS文件系统进行扩容。---kind: PersistentVolumeClaimapiVersion: v1metadata: name: cnfs-nas-pvcspec: accessModes: - ReadWriteMany storageClassName: alibabacloud-cnfs-nas resources: requests: storage: 70Gi #如果关上目录限额性能，则storage字段会失效，动态创建目录写入数据量最大为70 GiB。---apiVersion: apps/v1kind: Deploymentmetadata: name: cnfs-nas-deployment labels: app: nginxspec: selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 volumeMounts: - mountPath: "/data" name: cnfs-nas-pvc volumes: - name: cnfs-nas-pvc persistentVolumeClaim: claimName: cnfs-nas-pvc---apiVersion: apps/v1kind: StatefulSetmetadata: name: cnfs-nas-sts labels: app: nginxspec: serviceName: "nginx" replicas: 2 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 volumeMounts: - mountPath: "/data" name: www volumeClaimTemplates: - metadata: name: www spec: accessModes: [ "ReadWriteOnce" ] storageClassName: "alibabacloud-cnfs-nas" resources: requests: storage: 50Gi #如果关上目录限额性能，则storage字段会失效，动态创建目录写入数据量最大为50 GiB。EOF执行一下这个Yaml文件，k create -f xxx.yaml,查看生成状况。 ...

Apache APISIX 是一个开源的云原生 API 网关，作为 API 网关，它兼具动静、实时、高性能等特点，提供了负载平衡、动静上游、灰度公布、服务熔断、身份认证、可观测性等丰盛的流量治理性能。你能够应用 Apache APISIX 来解决传统的南北向流量，以及服务间的东西向流量，也能够当做 K8s Ingress controller 来应用。得益于 APISIX 全动静的设计，能够随时进行配置更改并且均不须要重启服务。 阿里云微服务引擎 MSE 提供了十分易用的流量泳道能力，基于 Java Agent 字节码加强的技术实现，无缝反对市面上近 5 年的所有 Spring Cloud 和 Dubbo 的版本，通过极简的配置与无代码侵入的形式，来实现全链路灰度，开释基于 APISIX 的微服务架构的新价值。 全链路灰度计划简介相干概念泳道：为雷同版本利用定义的一套隔离环境。只有满足了流控路由规定的申请流量才会路由到对应泳道里的打标利用。一个利用能够属于多个泳道，一个泳道能够蕴含多个利用，利用和泳道是多对多的关系。基线环境：未打标的利用属于基线稳固版本的利用，即稳固的线上环境。流量回退：泳道中所部署的服务数量并非要求与基线环境完全一致，当泳道中并不存在调用链中所依赖的其余服务时，流量须要回退至基线环境，进一步在必要的时候路由回对应标签的泳道。泳道组：泳道的汇合。泳道组的作用次要是为了辨别不同团队或不同场景。业务场景基于流量泳道的全链路灰度能力，实用于以下业务场景： 日常开发/我的项目/测试环境隔离；全链路灰度公布；高可用同机房优先路由；全链路压测。技术原理如何在理论业务场景中去疾速落地全链路灰度呢？目前次要有两种解决方案，基于物理环境隔离和基于逻辑环境隔离。 物理环境隔离物理环境隔离，其实就是通过减少机器的形式来搭建真正意义上的流量隔离。 该计划须要为灰度的服务搭建一套网络隔离、资源独立的环境，并在其中部署服务的灰度版本。因为与正式环境隔离，正式环境中的其余服务无法访问到须要灰度的服务，所以须要在灰度环境中冗余部署 这些线上服务，以便整个调用链路失常进行流量转发。此外，注册核心等一些其余依赖的中间件组件也须要冗余部署在灰度环境中，保障微服务之间的可见性问题，确保获取的节点 IP 地址只属于以后的网络环境。 该计划个别用于企业的测试、预开发环境的搭建，对于线上灰度公布引流的场景来说其灵活性不够。并且微服务多版本的存在在微服务架构中是十分常见的，须要为这些业务场景采纳堆机器的形式来保护多套灰度环境。如果利用数目很小，该形式是能够被受的；如果您的利用数目过多的状况下，会造成运维、机器老本过大，老本和代价远超收益。 逻辑环境隔离另一种计划是构建逻辑上的环境隔离，咱们只需部署服务的灰度版本，流量在调用链路上流转时，由通过的网关、各个中间件以及各个微服务来辨认灰度流量，并动静转发至对应服务的灰度版本。如下图： 上图能够很好展现这种计划的成果，咱们用不同的色彩来示意不同版本的灰度流量，能够看出无论是微服务网关还是微服务自身都须要辨认流量，依据治理规定做出动静决策。当服务版本发生变化时，这个调用链路的转发也会实时扭转。相比于利用机器搭建的灰度环境，这种计划不仅能够节俭大量的机器成 本和运维人力，而且能够帮忙开发者实时疾速的对线上流量进行精细化的全链路管制。 基于 Apache APISIX 全链路灰度产品实际全链路灰度是微服务最外围的性能之一，也是云上用户在微服务化深刻过程中必须具备的性能。全链路灰度因为波及到的技术和场景泛滥，如果企业一一进行自我实现，须要破费大量人力老本对其进行扩大与运维。 MSE 服务治理提供了残缺的产品化的全链路灰度解决方案，笼罩 RPC、MQ、可观测性等绝大多数场 景。只有架构是基于 Spring Cloud 或者 Dubbo 框架，利用无需降级或代码改变，即可实现企业级全链路灰度性能。 应用前提第一步：装置 APISIX 相干组件装置 APISIX、apisix-ingress-controller、etcd 等组件。helm repo add apisix https://charts.apiseven.comhelm repo add bitnami https://charts.bitnami.com/bitnamihelm repo updatekubectl create ns ingress-apisixhelm install apisix apisix/apisix \ --set gateway.type=LoadBalancer \ --set ingress-controller.enabled=true \ --set etcd.persistence.storageClass="alicloud-disk-ssd" \ --set etcd.persistence.size="20Gi" \ --namespace ingress-apisix \ --set ingress-controller.config.apisix.serviceNamespace=ingress-apisixkubectl get service --namespace ingress-apisix在 ingress-apisix 命名空间下能够看到无状态的 APISIX 和 apisix-ingress-controller 利用、以及有状态的 etcd 利用。 ...

作者：孙健波，曾庆国 KubeVela 是一个现代化的软件交付管制立体，指标是让利用的部署和运维在现在的混合多云环境下更简略、麻利、牢靠。自 1.1 版本公布以来，KubeVela 架构上人造买通了企业面向混合多云环境的交付难题，且围绕 OAM 模型提供了充沛的可扩展性，博得了大量企业开发者的青睐，这也使得 KubeVela 的迭代速度一直放慢。 1.2 版本咱们公布了开箱即用的可视化控制台，终端用户能够通过界面公布和治理多样化的工作负载；1.3 版本 的公布则欠缺了以 OAM 模型为外围的扩大体系，提供了丰盛的插件性能，并给用户提供了包含 LDAP 权限认证在内的大量企业级性能，同时为企业集成提供了微小的便当。至今为止，你曾经能够在 KubeVela 社区的插件中心里取得 30 多种插件，其中不仅蕴含了 argocd、istio、traefik 这样的 CNCF 出名我的项目，更有 flink、mysql 等数据库中间件，以及上百种不同云厂商资源可供间接应用。 在这次公布的 1.4 版本中，咱们围绕让利用交付更平安、上手更简略、过程更通明三个外围，退出了包含多集群权限认证和受权、简单资源拓扑展现、一键装置管制立体等外围性能，全面加固了多租户场景下的交付安全性，晋升了利用开发和交付的一致性体验，也让利用交付过程更加透明化。 外围性能解读开箱即用的认证和受权，对接 Kubernetes RBAC，人造反对多集群在全面解决了架构降级、扩展性等挑战之后，咱们察看到利用交付的安全性是现在整个业界亟需解决的难题。从接触到的用户案例中，咱们发现许多安全隐患： 大量用户在应用传统 CI/CD 的过程中，会间接将生产集群的 admin 权限嵌入到 CI 的环境变量里，只对最根本的交付到哪些集群有肯定的权限拆散。而 CI 体系通常也会被密集的用于开发和测试，很容易引入不受管制的危险。中心化的治理加上粗粒度的权限管制，一旦 CI 体系被黑客攻击、或者呈现一些人为误操作，很容易产生微小的破坏性，结果不堪设想。大量 CRD 控制器依赖 admin 权限对集群资源进行操作，且没有对 API 的拜访进行束缚。尽管 Kubernetes 自身具备丰盛的 RBAC 控制能力，然而因为学习权限治理门槛较高、且与具体性能实现无关，大多数用户并不真正关怀其中细节，通常只是抉择默认的配置便投入生产应用。灵活性较高的控制器（如可能散发 Helm Chart），很容易成为黑客攻击的靶子，比方在 helm 中嵌入一个 YAML 脚本窃取其余命名空间中的秘钥。KubeVela 1.4 中退出了认证和受权能力，且人造反对多集群混合环境，对于每一个 KubeVela 的平台管理员而言，他们不仅能够细粒度的定制任意的 API 权限组合、对接 Kubernetes RBAC 体系，将这些权限模块受权给开发者用户，严格限度其权限；还能够简便的应用 KubeVela 平台预置的权限模块，如间接授予用户某个集群的特定命名空间权限，授予某个用户“只读”权限等，极大的简化了用户的学习老本和心智累赘，全面加固了利用交付的安全性。对于应用 UI 的用户，零碎针对我的项目可用的资源范畴和类型主动实现底层受权并严格校验，从而使得业务层 RBAC 权限与底层 Kubernetes RBAC 体系买通并协同工作，做到从外到内的平安，不在任何环节扩充权限。 ...

分布式应用畛域的开源诉求，正在发生变化，从解决开发者从分布式应用架构演进到分布式应用治理的难题，因而在分布式应用规模化过程中，业内须要残缺的、可落地的治理能力和解决方案，解决用好、管好分布式应用的问题。 6 月 16 日，主题为“始于架构、精于治理”的阿里云首届中间件开发者大会将在线上进行直播。通过本次大会，您将理解到： 利用中间件开源畛域的趋势解读；Appactive、ChaosBlade、Nacos、OpenSergo、Seata、Sentinel、Serverless Devs、Spring Cloud Alibaba 等阿里云利用中间件畛域开源我的项目的最新进展；Apache Dubbo、Apache RocketMQ 的行业最新实际；广受好评的《微服务治理技术白皮书》上线研读班，并联结喜马拉雅 App 公布音频版。 当初通过文末“此处”进行报名，您还能获取国内中间件开源选型现状调研简报，咱们将把简报发送至您的集体邮箱。

阿里云 ESSD 云盘联合 25 GE 网络和 RDMA 技术，可能提供单盘高达 100 万的随机读写能力和单路低时延性能，同时反对多重挂载在多个 ECS 实例上。本期开源学堂将演示应用一个 ESSD 云盘作为共享存储多重挂载到两个 ECS 实例上，并别离在两个 ECS 实例上部署 PolarDB-PG 节点组成集群。同时简析部署筹备过程中的技术原理。 PolarDB for PostgreSQL 已在 GitHub 开源，欢送关注：https://github.com/ApsaraDB/P... 直播工夫 6 月 10 号（本周五）16:00～17:00 参加形式 钉钉扫描下图二维码退出 PolarDB-X 开源交换群 讲师介绍 张靖棠（棠羽） 阿里云 PolarDB-PG 云原生数据库内核开发工程师，毕业于南京航空航天大学计算机学院。2022 年退出 PolarDB-PG 团队，次要负责 HTAP 和分布式执行层的研发工作。

简介： 本文会通过在 ASK 上试用 Istio 部署微服务利用的形式，来验证 ASK 对规范 Kubernetes 的兼容性。Istio 作为 Service Mesh（服务网格）的领导解决方案，一方面自身足够简单具备代表性，另一方面它也代表了云原生时代微服务架构的趋势具备参考意义。作者：王飞龙（不物） 目前 Kubernetes 曾经成为业界容器编排零碎的事实标准，基于 Kubernetes 的云原生利用生态（Helm, Istio, Knative, Kubeflow, Spark on Kubernetes 等）更是让 Kubernetes 成为云操作系统。在这样的背景下，Serverless 容器成为现有 Container as a Service 的进化方向之一，一方面通过 Serverless 形式根本性解决了 Kubernetes 本身的治理复杂性，让用户无需受困于 Kubernetes 集群容量布局、平安保护、故障诊断；另一方面也进一步开释了云计算的能力，将平安、可用性、可伸缩性等需要由基础设施实现。 ASK 作为阿里云 Serverless Kubernetes 平台[1]，不仅有免运维、秒级弹性、超大 Pod 容量、弹性预测等重磅能力，更重要的是它仍然是一个规范 Kubernetes 平台。 本文会通过在 ASK 上试用 Istio 部署微服务利用的形式，来验证 ASK 对规范 Kubernetes 的兼容性。Istio 作为 Service Mesh（服务网格）的领导解决方案，一方面自身足够简单具备代表性，另一方面它也代表了云原生时代微服务架构的趋势具备参考意义。 当初就让咱们开始吧！ 创立集群 试用 Istio 前，须要筹备一个 ASK 集群。登录阿里云控制台，抉择产品与服务 > 容器服务 Kubernetes 版，在左侧边栏抉择集群进入集群列表页面。点击右上角创立集群开始创立集群，配置集群参数如下： ...

作者：泮圣伟（十眠） 如何无效利用云产品做好咱们的业务大促备战，这是一个大家都比较关心的问题。明天趁着 618 大促来袭前，谈一谈咱们所积攒的最佳实际。 点击下方链接，立刻查看视频解说！ https://yqh.aliyun.com/live/d... 大促的不确定性挑战 上图是咱们的一个业务大图，大促时候咱们会碰到许多的不确定性因素的挑战，如流量不确定，用户行为不确定，平安攻打不确定，研发变更危险不确定，故障影响不确定。最好的形式从入口模仿和防护，然而这么来看其实是不能解决所有问题，所以须要 IDC 外部进一步做故障演练和流量防护。 因为流量不确定，所以咱们须要容量评估以及业务评估确定流量峰值而后通过限流将流量变成确定性的条件；用户行为不确定，所以咱们须要通过仿真、多个场景模仿用户行为进行压测与演练，咱们须要做到更加实在的仿真并且及时发现零碎的瓶颈与优化点，并及时优化；平安攻打的不确定性，咱们须要网关有 waf 防护的能力，比方黑产刷单流量咱们如何辨认并且通过流控限度其访问量，从而爱护失常用户的流量；对于研发变更危险的不确定，咱们须要通过变更管控来限度大促时进行不必要的变更；因为放心出故障时影响面的不确定性，所以咱们须要通过一直的故障演练来锻炼咱们的零碎，理解故障的影响面并且尽可能管制问题的影响面，防止零碎雪崩的问题呈现；大促是一个我的项目，备战的方法论是把大促不确定性变成确定性，心愿能有一些方法论提供给大家，配合咱们产品的最佳实际帮忙到大家。 指标确定大促的指标有很多，比方撑持 XX 的流量峰值，30% 的老本优化，晦涩的用户体验等。大促备战的指标在技术同学看来个别围绕老本、效率、稳定性。老本咱们思考到 Nacos、云原生网关的资源老本，以及利用的机器数量，利用好 K8s 的弹性能力保障稳定性与老本的一个均衡；在效率方面 PTS 全链路压测提供了开箱即用的全链路压测工具，最靠近用户的仿真压测流量，能够极大地晋升效率，同时 MSE Switch 能力提供了动静配置能力帮忙预案的应用；在稳定性方面，MSE 服务治理提供了端到端的流量控制能力，以及弹性过程中的无损高低线能力保障大促过程中的流量平滑无损；同时咱们能够配合 MSE 服务治理的全链路灰度能力，应用测试流量进行全链路的性能预演，尽早裸露问题点。 备战流程简略来说，大促备战流程须要关怀以下四个点：容量评估、预案筹备、预热、限流。将以下这些点都做到了，就能够把不确定因素都变成了确定性的条件，那么即便是面对大促的流量洪峰，整个零碎会十分的安稳。 容量评估容量评估的目标为了实现老本与稳定性的最佳均衡，因而咱们须要基于大促的利用体现，确定咱们的利用在肯定的业务条件下的性能基线；同时另一方面出于老本优化的指标，咱们须要确定机器的老本估算。 通过性能评估以及性能优化，确保利用的性能评估业务变动以及零碎的变动基于业务模型评估，确定全链路压测模型，并进行全链路压测验收评估容量的极限水位，放弃 60% 的容量水位，开启弹性扩缩容能力。 性能评估首先须要通过 PTS 平台对服务进行压测，摸清零碎对外外围接口的服务能力以及相应的零碎水位。阿里云产品对于压测以及全链路压测首推的就是 PTS。 PTS 比照个别的压测工具，具备以下劣势： 劣势一：功能强大 全 SaaS 化状态，无需额定装置和部署。0 装置的云端录制器，更适宜挪动端 APP 场景。数据工厂性能，0 编码实现压测的 API/URL 的申请参数格式化。简单场景的全可视化编排，反对登录态共享、参数传递、业务断言，同时可扩大的指令性能反对多状态的思考工夫、流量蓄洪等。独创的 RPS /并发多压测模式。流量反对动静秒级调整，百万 QPS 亦可刹时脉冲。弱小的报表性能，将压测客户端的实时数据做多维度细分展现和统计，同时主动生成报告供查阅和导出。压测 API/场景均可调试，压测过程提供日志明细查问。**劣势二：流量实在 流量来源于全国上百城市笼罩各运营商（可拓展至海内），实在模仿最终用户的流量起源，相应的报表、数据更靠近用户实在体感。施压能力无下限，最高反对千万 RPS 的压测流量。当性能压测出零碎瓶颈后，咱们须要分档次地对系统进行优化。 业务以及零碎的变动评估每次大促相比之前（如果有参考的话）的稳定性评估，以及业务动向，这次业务相比之前是否有量级的晋升，业务的玩法是否有变动比方 618 的预售以及抢红包、满减等业务玩法是否会对系统造成稳定性的危险，对用户动向进行剖析，从全局视角看零碎的要害门路，保障外围业务，梳理强弱依赖。 基于业务模型评估，确定全链路压测模型，并进行全链路压测验收\ 要发动一次性能压测，首先须要创立一个压测场景。一个压测场景蕴含一个或多个并行的业务（即串联链路），每个业务蕴含一个或多个串行的申请（即 API）。 通过压测能够对咱们的零碎做好一个危险辨认与性能治理的目标，通过全链路压测能够提前发现零碎的瓶颈，辨认性能危险，避免零碎的性能腐化。 云产品的资源容量评估与参考MSE Nacos 容量参考 ...

摘要：精益产品开发体系最佳实际及准则。精益求精是工匠精力实现的最佳办法，通过引入实际精益思维的准则和办法进行精益产品开发，打造对客户最好的产品进行交付，其次通过精益思维的理念升高企业的经营老本，进步企业的经营效率。 精益思维的定义让咱们从精益思维讲起。先给精益思维做一个定义，这个定义来自wikipedia，它最终其实还是引自《精益思维》这本书。它的定义是“精益思维是对于如何无效组织人类流动的一个新的思维办法，它的指标是打消节约，更多地交付对集体和社会有用的价值”。 打消节约是一个方面，减少价值是另外一个方面。当然咱们也能够说，打消节约是伎俩，而减少价值才是最终的目标。 对于方才讲的是人类的流动，精益思维在很多方面都有利用，比方生产制作或者是服务提供，当然产品开发中也会有利用，这是三个次要的畛域。 精益生产：丰田生产方式（TPS）咱们来看一下精益思维在丰田的利用，丰田生产方式（TPS）又被称为精益生产方式。 它的次要缔造者之一大野耐一通过精益生产屋来形容TPS，它由指标，支柱和根底三个局部形成。TPS的指标是高质量、低成本的疾速响应，也就是方才在《精益生产零碎的胜利》这篇文章中所说的，丰田的生产方式品质更高、老本更低、响应更疾速，而大野耐一说，精益生产方式的指标就是高质量、低成本和疾速响应，事实上精益生产方式也达成了这一指标。 它是如何达成的，大野耐一认为它有两个支柱，一个是准时化，一个是自働化。他说准时化和自働化是精益生产的两大支柱，这两大支柱须要有相应的实际作为根底，比方看板、标准化作业、均衡生产、疾速换模、U型生产单元、目视化、5S，这些实际是根底，但它们大多数都是生产制作中所独有的。 精益生产支柱一：准时化接下来看这两大支柱到底是什么意思？ 准时化又被称为Just In Time，是指仅在须要的工夫生产须要数量的须要的产品，这叫做准时化。准时化的目标是灵便应答变动，打消生产过剩的节约，以缩短前置工夫。这可能还比拟形象，咱们来看看准时化具体是如何实现的。 在这幅图中，我把整个生产过程形象为由上下游工序形成的链条，截取了其中一段，上游工序、上游工序以及上下游工序之间的长期库存。假如这外面上游工序是汽车组装环节，上游工序是方向盘生产环节，上下游工序之间的货架放的是生产好的方向盘。 在这外面咱们会看到看板的存在，看板事实上是指一张卡片。在这幅图里咱们看到两种色彩的卡片，一种是蓝色的，称之为取货看板，一种是棕色的被称为生产看板。 咱们来看一看这两个看板是怎么利用。当上游工序（在这外面是指汽车组装环节）须要组装一辆汽车的时候，比如说它须要组装两辆卡罗拉汽车，于是它用它的取货看板就是蓝色的卡片，到上游的货架中去取绝对应的方向盘，它只有凭这个卡片在须要的时候能力去取。 当它拿着这个蓝色的卡片，也就是取货看板，去取回方向盘的时候，原本和方向盘在一起的棕色的卡片也就是生产看板被留了下来，预计大家也能猜到留下的卡片能够做什么。留下的卡片被传递到上游工序，也就是方向盘生产环节，而上游环节仅仅在持有这些卡片，持有这两个生产看板的时候，才能够开始生产。 这两张卡片被传到上游的生产环节的时候，上游环节失去了信号，它说我须要生产两个卡罗拉的方向盘，生产完了干什么，预计大家也可能猜想到。生产完的方向盘与生产看板，一起被传递到货架中或者叫补充货架。 这时候咱们看到看板起到的作用，看板向上游一级一级传递生产的信号，它拉动了上游的生产，也就是拉动了物流，看板形成了信号流，而拉动的是物流，也就是真正的价值流。 这就是实现了准时化的生产——仅仅在须要的工夫生产须要数量的须要的产品。事实上最终拉动整个生产环节的是最上游的客户订单，最终始终拉动到原材料的供应，甚至拉动到原材料提供商。 通过这种办法咱们能够看到，它实现了相比过来那种所谓的集中的管制和治理，看板造成一套零碎，这种零碎实现了一种所谓的去中心化的治理，通过客户的需要拉动整个生产，或者响应对客户的需要，产生最及时和最精确的响应。 咱们来看一看它最终可能达到的成果。过来的生产方式咱们把它称之为推动式生产，也就是上游依照打算生产完产品，把它推到上游去，不论上游这时候是不是须要。 而通过看板实现的形式叫做拉动式生产，也就是说仅仅在上游须要的时候会拉动上游的生产，实现了所谓的准时化，仅在须要的工夫生产须要数量的须要的产品。 不言而喻，这种形式能够降低库存。它还能减速流动，这外面减速流动指的是工件的流动或者是价值的流动，也就是说从原材料进入生产环节到变成成品的工夫变短，或者说从客户订单生成到客户订单被生产进去的前置工夫最小化，因为工件是简直不做停留的，只有须要的时候它才生产，生产完了立马传递到下一个环节，实现了疾速的价值流动。 它同时还实现了灵便的响应，也就是当上游的需要发生变化的时候，整个生产环节立马被由看板所造成的信号系统反映到整个生产过程当中去。最初它也进步了品质，这个将自働化时还会具体介绍。 方才曾经看完了丰田生产方式的第一个支柱，所谓的准时化。再看第二个支柱，自働化。 精益生产支柱二：自働化 这外面的働是有一个人字旁的，丰田称之为人字旁的自动化，日文叫做JIDOKA，英文翻译也是通过日文注音翻译过去的。英文还有另外一个翻译办法，叫Auto-No-Mation，主动的不动。 自働化是什么意思，是指生产零碎可能主动发现异常，当异样产生时可能进行生产并现时现地的解决问题，也就是说异样产生的工夫和地点去解决问题、剖析问题，而且要解除产生异样的根本原因。 这幅图比拟了自动化和自働化的区别，右边这幅图是失常状况，这外面假如是自动车螺纹，工件一直的输出给这个环节，源源不断的输入去，如果没有异样，所有都很好。 右上是传统意义上的自动化，当产生异样时，比如说车刀呈现了裂纹，生产的螺纹就是次品，这时候异样没有被即时发现，它就会源源不断的产生更多的次品。 咱们再来看看丰田的自働化意思是什么。看上图右下，当异样产生时，生产零碎可能主动感知，立马停下这台设施，在触发到一个阈值的时候就会停下整个生产线。 停下生产线有什么益处，感知了异样，停下来，不言而喻的是不能把次品输出给下一个环节，它带来的第二个益处是把这个问题凸显进去，让咱们生产线上的负责人和员工一起来剖析为什么产生了这个问题，这个问题未来怎么躲避，它的根本原因是什么，怎么去解决。 通过一直的发现问题、裸露问题、解决问题，让咱们的生产线变得更加牢靠，让咱们的生产零碎可能更加顺畅地运作。 矛盾的统一体下面咱们介绍了丰田生产方式也就是精益生产方式的两大支柱：准时化和自働化。准时化和自働化是一对矛盾的统一体。 矛盾是指，准时化促成流动，而自働化恰恰相反，它是要进行流动，这看上去是矛盾的。然而它们又是对立的。 准时化是为了让工件沿价值流继续的流动，自働化是呈现问题时进行流动，它们互相制约又相辅相成，两者相结合能力保障价值顺畅、高质量且可继续的流动。如果没有自働化，只有准时化，它的流动可能就很难保障它的品质，也很难保障它的继续。 自働化及时的发现、裸露问题和解决引发问题的根本原因，让流动更加顺畅。所以说自働化和准时化是一对矛盾的统一体，它们两者缺一不可，独特撑持起丰田的生产方式或者精益生产方式，实现高质量、低成本和疾速响应。 后面介绍了丰田生产方式或者精益生产方式的指标： 高质量、低成本和疾速响应；以及它的准则（或支柱）：准时化和自働化。这个准则之下须要有实际的撑持，比如说均衡生产、标准化作业、看板拉动、U型生产、单件流、疾速换模。 这些词可能都很生疏，还好咱们不须要去理解，我之所以把它列出来，是心愿大家可能感知到，它其实都是生产中的实际，是不能被照搬到产品开发当中去的，产品开发须要本人的实际。生产的实际并不适宜其余畛域，所以精益的产品开发还须要回到准则自身。 要去构建一个精益的产品开发形式，必须从准则登程，构建精益产品开发实际体系，而价值观只能作为高层的领导。 精益思维五个外围准则《精益思维》这本书到底讲了什么，他总结了精益思维的五个外围准则，这五个外围准则也是施行精益的五个步骤，作者认为只有依照这五个步骤去做，就能够实现所谓的精益，也就是说打消节约、减少价值，而这是局部行业的。 这五个准则或者五个办法步骤 ● 第一步，是定义价值，外围是站在用户的视角定义什么是价值，并且把这些价值形容为具体的产品或者服务，用户认为它是价值才是价值，比方方才精益生产里，用户的订单才是价值。 ● 第二步，在此基础上要辨认价值流，辨认组织发明价值的流动过程，或者说辨认和映射发明价值的流程步骤，打消不减少用户价值的步骤和流动，比如说期待，比如说没有意义的审批和返工。 ● 第三步，要让价值继续流动起来，使它们继续、顺畅地流向用户。 ● 第四步，是用户价值拉动，由用户的最终价值拉动这个流动，防止不带来用户价值的节约，让用户价值拉动整个价值流。 ● 第五步，是精益求精，不断完善，一直反复第一步到第四步，辨认其中的问题，谋求完满的价值和价值流动，打消过程中所有的节约。 作者认为通过这五步咱们就能够实现所谓的精益，不论是生产还是其余的畛域。起初的实际也曾经证实它简直实用于所有的行业，但须要相干的与行业适配的实际的反对。 要去构建一个精益的产品开发形式，必须从准则登程，构建精益产品开发实际体系，而价值观只能作为高层的领导。 精益产品开发实际体系精益产品开发实际体系。因为精益生产十分成熟也十分胜利，讲到精益产品开发的时候，大家很天然的会用精益生产做类比和映射。 最早介绍精益软件开发书，是Mary Poppendieck的《精益软件开发》，书中就把精益生产的概念映射到了精益产品开发中，用生产中的7个节约来隐喻产品开发中的节约。 ...

作者：白玙 随着技术逐步成熟、市场需求降级，以容器、微服务为代表的云原生技术被越来越多企业所接收。企业 IT 架构全栈上云催生对立监控诉求，分布式云进一步加剧复杂度。可观测成为升高分布式熵增的惟一伎俩，利用成为云原生可观测最佳视角。 与此同时，随同着 Prometheus、Grafana、Opentelemetry、Fluented 等开源我的项目的炽热，企业对于可观测的认知越来越成熟，开始用可观测技术与产品解决理论问题。能够看到，全面云化浪潮中，可观测技术再次成为配角。 6 月 22 日，由中国信通院领导，阿里云、Grafana Labs 联结主办，天池平台、云原生利用平台承办的阿里云可观测技术峰会正式拉开帷幕。围绕「行业实际与开源实际」这一主题，邀请十余位国内外可观测畛域大咖，为听众出现丰盛且具备实际参考意义的精彩分享与探讨。 这其中既有来自阿里云、友邦人寿、新康众等企业应用架构负责人、SRE 负责人将分享云原生可观测实战经验，更有 Grafana 、Prometheus、Apache Skywalking 等热门开源我的项目创始人、首席布道师等重磅嘉宾，与泛滥运维工程师独特探讨可观测将来发展趋势与实际挑战，为企业打造可观测体系提供可复制、可借鉴的最佳指南。具体解读企业IT团队如何借助可观测能力晋升运维效力，打造更优质、更智能的用户体验，更轻松地实现数字化转型与翻新。 四大亮点领先看围绕「开源实际」主题，聚焦业界最热门可观测我的项目与场景。Grafana、Prometheus、Apache Skywalking 等开源我的项目创始人，围绕理论场景解析如何应用相干技术实现可观测落地。三大经典可观测实战案例，运维负责人复盘可观测实际历程。本次峰会邀请友邦人寿、新康众 F6、阿里云 SRE 团队，议题笼罩金融、新批发、企业服务等不同行业，基于日常运维中所遇挑战，分享企业实战干货。《企业可观测体系全景图》公布，为构建可观测能力提供最佳指引。本次峰会将公布《企业可观测体系全景图》，帮忙企业突破数据孤岛、建设对立可观测体系，为可观测体系搭建提供参考。阿里云云原生可观测套件重磅公布，打造云原生可观测最佳解决方案。针对企业落地可观测过程中所遇难题，阿里云公布焕新可观测套件，为企业提供体系化、模块化、个性化可观测体系最佳解决方案。 精彩不容错过，点击此处立刻报名！

Grafana 服务新用户最低 0 元起、利用监控新用户最低 70 元起，老用户全规格低至 9 折！ 点击此处立享优惠！

作者：王思宇（酒祝） 云原生利用自动化治理套件、CNCF Sandbox 我的项目 -- OpenKruise，近期公布了 v1.2 版本。 OpenKruise [ 1] 是针对 Kubernetes 的加强能力套件，聚焦于云原生利用的部署、降级、运维、稳定性防护等畛域。所有的性能都通过 CRD 等规范形式扩大，能够实用于 1.16 以上版本的任意 Kubernetes 集群。单条 helm 命令即可实现 Kruise 的一键部署，无需更多配置。 版本解析在 v1.2 版本中，OpenKruise 提供了一个名为 PersistentPodState 的新 CRD 和控制器，在 CloneSet status 和 lifecycle hook 中新增字段， 并对 PodUnavailableBudget 做了多重优化。 1. 新增 CRD 和 Controller-PersistentPodState随着云原生的倒退，越来越多的公司开始将有状态服务（如：Etcd、MQ）进行 Kubernetes 部署。K8s StatefulSet 是治理有状态服务的工作负载，它在很多方面思考了有状态服务的部署特色。然而，StatefulSet 只能放弃无限的 Pod 状态，如：Pod Name 有序且不变，PVC 长久化，并不能满足其它 Pod 状态的放弃需要，例如：固定 IP 调度，优先调度到之前部署的 Node 等。典型案例有： 服务发现中间件服务对部署之后的 Pod IP 异样敏感，要求 IP 不能随便扭转数据库服务将数据长久化到宿主机磁盘，所属 Node 扭转将导致数据失落针对上述形容，Kruise 通过自定义 PersistentPodState CRD，可能放弃 Pod 其它相干状态，例如：“固定 IP 调度”。 ...

作者：姚辉(千习) 背景先来谈下什么是分布式批处理，从字面来了解就是有大批量的业务数据须要应用程序去批量计算解决，而通过单机模式去执行会消耗很长的解决工夫，也不能充分发挥业务集群中每个利用节点解决能力。通过一些常见的分布式批处理计划，能够无效地让业务集群中所有业务利用节点协同实现一个大批量数据处理的工作，从而晋升整体的解决效率和解决可靠性。 批处理模型 在简略单机场景下能够开启多线程来同时解决一个大工作，在多个机器下能够由多台机器同时并行处理同一个工作。因而，分布式批处理计划须要为开发者在代码开发层面屏蔽上述工作切分后散发、并行执行、后果汇聚、失败容错、动静扩容等业务利用集群间的分布式协调逻辑，让使用者仅聚焦于上述红框形容的业务逻辑分片规定和业务逻辑解决即可。 大数据批处理比拟在大数据处理场景中咱们也会用到 MapReduce 模型，其解决逻辑实质与咱们要探讨的业务批处理逻辑是统一的。在大数据场景下的批处理次要是面向数据自身的解决，并须要部署相应大数据平台集群来反对数据存储和数据批处理程序处理，因而该场景下次要目标是用于构建一个残缺的数据平台。与大数据批处理场景相比拟，本次更次要聚焦探讨分布式业务批处理场景，基于现有业务应用服务集群构建分布式批处理逻辑。通过分布式批处理计划能够解决以下需要 对耗时业务逻辑解耦，保障外围链路业务解决疾速响应充沛调度业务集群所有利用节点单干批量实现业务解决有别于大数据处理，子工作处理过程中还会有调用其余在线业务服务参加批处理过程开源批处理计划ElasticJobElasticJob 是一款分布式任务调度框架，其次要特点是在 Quartz 根底上实现定时调度并提供在业务集群中对工作进行分片协调解决能力。在整个架构上基于 Zookeeper 来实现工作分片执行、利用集群动静弹性调度、子工作执行高可用。分片调度模型可反对大批量业务数据处理平衡的散发至业务集群中的每一个节点进行解决，无效地进步了工作解决效率。 SimpleJobSpring Boot 工程可通过 YAML 配置工作定义，指定以下内容：工作实现类、定时调度周期、分片信息。 elasticjob: regCenter: serverLists: 127.0.0.1:2181 namespace: elasticjob-lite-springboot jobs: simpleJob: elasticJobClass: org.example.job.SpringBootSimpleJob cron: 0/5 * * * * ? overwrite: true shardingTotalCount: 3 shardingItemParameters: 0=Beijing,1=Shanghai,2=Guangzhou配置的 org.example.job.SpringBootSimpleJob 类须要实现 SimpleJob 接口的 execute 办法，并且通过 ShardingContext 参数获取对应业务分片数据进行业务逻辑解决。 @Componentpublic class SpringBootSimpleJob implements SimpleJob { @Override public void execute(final ShardingContext shardingContext) { String value = shardingContext.getShardingParameter(); System.out.println("simple.process->"+value); }}咱们部署 3 个应用服务作为调度解决集群解决上述工作，当工作触发运行时，ElasticJob 就会将对应 3 个分片工作别离给 3 个应用服务进行解决来实现整个工作数据处理。 ...

摘要：什么是DevOps?为大家都在用DevOps，随着市场竞争的加剧，对企业的软件交付速度提出了更高的要求。像大家相熟的大厂也不例外，落地DevOps、实现高效交付成为了企业独特的谋求。 现阶段企业的疾速倒退，人员规模的一直壮大，开发流程规模和工具倒退不匹配，各种问题频频暴发。每个人都感觉推动一件事件太难了，公布流程不标准，好的实际又难于推广。 大家都晓得有问题，可一旦要改良却总是有这样的那样的起因，公布工夫长，须要人工染指多，无论从工夫老本还是因为人工染指带来的危险都很大。短少建设工程效力的无效抓手，想要晋升但短少办法和抓手更短少好用的工具，软件交付要求越来越高和企业面临的事实问题双重叠加，这就像开着拖拉机加入拉力赛怎么办呢？ 答案是 DevOps 那什么是 DevOps，它能帮忙咱们解决什么问题呢？ DevOps是一套集组织文化团队合作工程实际和工具为一身的工作办法，以帮忙企业高效疾速高质量的交付应用程序和服务为目标从而更好的实现客户价值。 云效企业级一站式 DevOps平台，源自阿里巴巴团体先进的研发理念和工程实际，云效目前已服务数十万家企业组织、百万开发者。想要开启你的企业的高效交付之旅吗？立刻体验云效。 相比于开源工具自建 DevOps，为什么大家更违心应用云效DevOps平台，抉择云效 DevOps 的 6 大劣势： DevOps工具链一步配齐，开箱即用；一套账号、数据体系，买通所有零碎；简略易用，优良实践经验模板化积淀；深度集成阿里云产品，云上DevOps工具首选；多重企业级平安防控能力，平安可信；云效公共云产品，根底版，不限人数，收费应用；云效一站式DevOps工具链，开箱即用云效 DevOps 提供我的项目合作、代码治理、继续交付流水线、云原生利用交付、在线IDE、制品仓库、测试治理、知识库 、效力洞察9大产品，返回 http://devops.aliyun.com/,仅需 1 个阿里云账号，这些 DevOps 工具你就能够一站式配齐。无需搭建和保护老本，开箱即用。 一套账号、数据体系，买通所有零碎应用开源工具自建 DevOps，往往项目管理是一个零碎、代码治理是一个零碎、继续集成又是另一个零碎。每个零碎都须要搭建不说，账号、数据都是独立的，保护起来很简单。 抉择云效 DevOps，同一个阿里云账号，即可拜访所有产品。 不仅如此，应用云效的 DevOps 我的项目，从工作 -> 代码分支 -> 代码提交记录 -> CI/CD 公布进度，一个我的项目外面就能够理解全副，无需切换多套零碎。 简略易用，优良实践经验模板化积淀云效提供简略、可视化的操作界面，相比于 jenkins 更容易上手。此外，云效继续交付流水线 Flow 还内置了丰盛的模板。 可视化的流水线配置让之前繁琐的脚本编写工作一去不复返。更重要的是，企业优良的实践经验，也能够保留为模板，积淀复用，缩小反复工作。 深度集成阿里云产品，云上 DevOps 工具首选云效与阿里云产品采纳同一套账号体系，与阿里云云服务器 ECS、容器服务 ACK、函数计算 FC、企业级利用架构 EDAS 、阿里云钉钉等无缝连接，既缩小了账号保护老本，也升高了账号泄露带来的平安危险。 不仅如此，云效流水线还内置了分批、灰度、蓝绿等常见部署策略，同时反对主机和 K8S，缩小额定的开发配置老本。 多重企业级平安防控能力，平安可信开源版本的 DevOps 工具往往短少企业级的平安防控能力，企业想要保障生产平安可控，要么抉择付更多的钱降级为付费版，要么钻研如何集成其余平安工具，更甚者须要基于它进行二次开发以达到企业标准的平安规范。 云效 DevOps 通过了公安部网络安全等级爱护 2.0 三级认证、ISO 27001 信息安全管理体系规范认证、ISO 9001 品质管理体系认证，标记着云效平安实际达到国内外相干权威机构的平安规范要求，用户应用云效的数据保密性、完整性、可用性和隐衷性曾经与国内外最佳实际对标，且失去独立第三方平安认证。 ...

作者：清铭，Seata 创始人 Seata 是一款开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简略易用的分布式事务服务。Seata 在阿里外部始终扮演着利用架构层数据一致性中间件的角色，简直每笔交易都要应用 Seata，帮忙业务安稳的度过历年的双 11 洪荒流量。开源的短短 3 年间，Seata 社区曾经播种了 22k star 和建立了一大批企业标杆用户，成为了分布式事务畛域的事实标准。 Seata 近期正式公布了 1.5.0 里程碑版本，该版本共有 61 名 contributor 奉献了近 7w+代码，公布一系列重大个性反对如控制台的反对。同时，基于 1.5.0 版本在阿里云上正式凋谢了 Seata 企业版的公测，企业版能够让用户免去运维的懊恼，内核性能上也有较大幅度的晋升，让用户能够疾速体验 Seata 的性能和享受云原生时代带来的红利。公测期间用户能够收费开明 Seata 企业版，欢送大家的试用，也心愿您对咱们产品提出贵重的倡议。 Seata 企业版服务开明入口： https://help.aliyun.com/docum... 目前只反对华北 2（北京）地区，公测期间收费应用。 Seata 的前世今生Seata 开源之前其外部产品 TXC（taobao transaction constructor）在阿里外部通过了长时间的打磨，在中间件产品矩阵中承当着"服务一致性"的重要角色。它最早诞生于去“IOE”的互联网中间件时代，用于解决阿里外部大规模服务化遇到的数据一致性问题，其后又经验了 ”高可用和对立电商”，“中间件上云”，“云原生中间件”等重要技术架构的演进。 在过来几年，开源社区推出了多个为人熟知的开源我的项目，反对外围业务的中间件零碎从关闭走向凋谢。阿里在 2019 年实现了全站的外围零碎上云，三位一体的理念，即“自研”、“开源”、“商业化” 造成对立的体系，成为了事实，最大化施展了技术的价值。Seata 成为了分布式应用从 0-1 落地过程中的重要根底组件。 Seata 的外围业务价值当利用演进为分布式架构后，其分布式事务问题尤为突出，次要产生的起因有： 1. 跨数据库操作 业务初始阶段往往规模比拟小，大多状况下，单库就能够满足需要。随着业务规模变得大而简单，会呈现分库的状况，这时原有的单机事务往往会变成分布式事务。 2. 跨零碎的分布式事务 在和第三方零碎（含企业内外）集成时，本地的操作强依赖于第三方零碎的响应后果，并且业务要么一起胜利，要么一起生效，这时会天然地产生分布式事务的场景。 3. 跨服务的分布式事务 业务实现服务化革新后，资源与客户端调用解耦，同时又要保障多个服务调用间资源的变动放弃强统一，否则会造成业务数据的不残缺。 4. 跨数据库与音讯的分布式事务 在某些业务场景中，须要进行多个 DB 操作的同时，还会调用音讯零碎，DB 操作胜利、音讯发送失败或者反过来都会造成业务的不残缺。 ...

作者：渐意 前言无论是在大数据处理畛域，还是在音讯解决畛域，工作零碎都有一个很要害的能力 - 工作触发去重。这个能力在一些对准确性要求极高的场景（如金融畛域）中是必不可少的。作为 Serverless 化工作解决平台，Serverless Task 也须要提供这类保障，在用户利用层面及本身零碎外部两个维度具备工作的精确触发语义。本文次要针对音讯解决可靠性这一主题来介绍函数计算异步工作性能的技术细节，并展现如何在理论利用中应用函数计算所提供的这方面能力来加强工作执行的可靠性。 浅谈工作去重在探讨异步音讯解决零碎时，音讯解决的根本语义是无奈绕开的话题。在一个异步的音讯解决零碎（工作零碎）中，一条音讯的解决流程简化如下图所示： 图 1 用户下发工作 - 进入队列 - 工作处理单元监听并获取音讯 - 调度到理论 worker 执行 在工作音讯流转过程中，任何组件（环节）可能呈现的宕机等问题会导致音讯的谬误传递。个别的工作零碎会提供至少 3 个层级的音讯解决语义： At-Most-Once：保障音讯最多被传递一次。当呈现网络分区、零碎组件宕机时，可能呈现音讯失落；At-Least-Once：保障音讯至多被传递一次。消息传递链路反对谬误重试，利用音讯重发机制保障上游肯定收到上游音讯，然而在宕机或者网络分区的场景下，可能导致雷同消息传递屡次。Exactly-Once 机制则能够保障音讯准确被传送一次，准确一次并不是意味着在宕机或网络分区的场景下没有重传，而是重传对于接受方的状态不产生任何扭转，与传送一次的后果一样。在理论生产中，往往是依赖重传机制 & 接管方去重（幂等）来做到 Exactly Once。函数计算可能提供工作散发的 Exactly Once 语义，即无论在何种状况下，反复的工作将被零碎认为是雷同的触发，进而只进行一次的工作散发。 联合图 1，如果要做到工作去重，零碎至多须要提供两个维度的保障： 零碎侧保障：任务调度零碎本身的 failover 不影响音讯的传递正确性及唯一性；提供给用户一种机制，能够联合业务场景，做到整个业务逻辑的触发+执行去重。上面，咱们将联合简化的 Serverless Task 零碎架构，谈一谈函数计算是如何做到下面的能力的。 函数计算异步工作触发去重的实现背景函数计算的工作零碎架构如下图所示： 图 2 首先，用户调用函数计算 API 下发一个工作（步骤 1）进入零碎的 API-Server 中，API-Server 进行校验后将音讯传入外部队列（步骤 2.1）。后盾有一个异步模块实时监听外部队列（步骤 2.2），之后调用资源管理模块获取运行时资源（步骤 2.2-2.3）。获取运行时资源后，调度模块将工作数据下发到 VM 级别的客户端中（步骤 3.1），并由客户端将工作转发至理论的用户运行资源（步骤 3.2）。为了做到上文中所提到的两个维度的保障，咱们须要在以下层面进行反对： 零碎侧保障：在步骤 2.1 - 3.1 中，任何一个两头过程的 Failover 只能触发一次步骤 3.2 的执行，即只会调度一次用户实例的运行；用户侧利用级别去重能力：可能反对用户屡次重复执行步骤 1，但理论只会触发一次 步骤 3.2 的执行。零碎侧优雅降级 & Failover 时的工作散发去重保障当用户的音讯进入函数计算零碎中（即实现步骤 2.1）后，用户的申请将收到 HTTP 状态码 202 的 Response，用户能够认为曾经胜利提交一次工作。从该工作音讯进入 MQ 起，其生命周期便由 Scheduler 保护，所以 Scheduler 的稳定性及 MQ 的稳定性将间接影响零碎 Exactly Once 的实现计划。 ...

作者：聂晓龙（率鸽） 前言前天回家路上，有辆车强行插到后面的空位，司机大哥火暴地拍着方向盘吐槽道“加塞最可恶了”，我问“还有更可恶的吗”，司机大哥淡定说道“不让本人加塞的”。仿佛和咱们很相似，咱们程序员届也有这 2 件相辅相成的事：最厌恶他人不写正文，更厌恶让本人写正文。 一段蹩脚的代码，往往大家最低的预期是把正文写分明，最正当的做法通常应该对代码做优化。如果咱们将代码真正做到了优良，咱们是否还须要正文？ 正文的意义; **************************************************************************; * RAMinit Release 2.0 *; * Copyright (c) 1989-1994 by Yellow Rose Software Co. *; * Written by Mr. Leijun *; * Press HotKey to remove all TSR program after this program *; **************************************************************************; Removed Softwares by RI:; SPDOS v6.0F, WPS v3.0F; Game Busters III, IV; NETX ( Novell 3.11 ); PC-CACHE; Norton Cache; Microsoft SmartDrv; SideKick 1.56A; MOUSE Driver; Crazy (Monochrome simulate CGA program); RAMBIOS v2.0; 386MAX Version 6.01正文是对代码的解释和阐明，实质目标是为了加强程序的可读性与可解释性。正文会随着源代码，在进入预处理器或编译器解决后会被移除。这是雷布斯 1994 年写的一段 MASM 汇编代码，正文与代码整体构造都十分清晰。如果说代码是为了让机器读懂咱们的指令，那正文齐全就是为了让咱们理解咱们本人到底收回了哪些指令。 ...

寰球数字经济进入高速发展期，数字经济已成为我国经济增长的重要组成部分和推动我国经济倒退的新增长极，放慢推动各产业数字化转型，成为“十四五”期间的重要阶段性指标。构建以云计算为外围的数字基础设施实现IT架构的现代化革新曾经成为社会共识，云原生技术作为下一代云计算的技术内核施展着重要作用。历经多年倒退，我国云原生技术生态已趋于欠缺、行业用户接收度急速晋升、资本市场热潮涌动，能够预感我国云原生产业行将进入高景气周期。 在用户侧，全面转型云原生已是大势所趋，但云原生技术架构的重塑和利用模式的改革引入了新的平安危险，镜像破绽、容器逃逸以及微服务细粒度拆分带来的服务交互平安等问题正威逼着企业的云原生平台和利用，云原生平安建设成为企业云原生平台建设和利用云原生化革新过程中的必备项。鉴于此，中国信通院联结业界20余家单位的近40名专家历时1年实现了国内首个云原生平安成熟度模型规范的编撰，为企业云原生平安能力建设提供自检标尺和建设指南。 阿里云作为寰球当先的云服务商之一，顺利完成首个“云原生平安成熟度评估”。阿里云致力于打造稳固、规范、先进的云原生平台，推动行业面向云原生技术升级与反动，同时是国内最早提出并定义云原生平安的企业之一，将云上通过大规模实际和验证的平安能力利用于爱护云原生利用，并将云原生疾速拉起、便捷部署的劣势特点利用于平安产品技术，继续为云上用户提供原生利用、数据、业务、网络、计算的爱护能力，通过和基础设施深度交融推动平安服务化，反对弹性、动静、简单的行业场景，取得包含政府、金融、互联网等各行业用户认可。 最全评测维度云原生平安成熟度评估涵盖基础设施平安、云原生基础架构平安、云原生利用平安、云原生研发经营平安、云原生平安运维5个维度、15个子维度、46个实际项 、 356个细分能力要求，全场景多维度测验云原生平台架构的平安防护能力。 最广协同范畴投入本次评测的技术团队横跨北京、杭州、深圳三地，协同容器服务、容器镜像服务、云平安核心、Web利用防火墙等二十余款云原生产品，全方位考查阿里云的云原生产品安全能力的丰盛度。 最细考查粒度中国信通院工程师严格对照验证要求，粗疏核验每个评测项，具体记录了测试全过程，所有测试都基于阿里云生产环境实现，最终评测报告近400页。 云原生平安成熟度模型简介云原生能力成熟度模型 （CNMM-TAS） 以晋升企业研发效力、促成业务翻新倒退为指标，从技术架构（T）、业务利用（A）、架构平安（S）三个方面助推企业云原生能力建设。云原生平安成熟度 （CNMM-TAS） 评估交融了零信赖、平安左移、继续监测与响应以及可观测四大理念，从基础设施平安、云原生基础架构平安、云原生利用平安、云原生研发经营平安和云原生平安运维5个维度充沛考查云原生架构平安程度，帮忙企业疾速对照、定位平安能力程度，诊断本身问题，依据业务需要联合模型高阶能力定制平安架构演进方向。 *云原生平安成熟度模型* 在基础设施平安域能力方面，阿里云在计算、存储、网络等基础设施畛域领有寰球当先的技术能力，同时联合云原生技术特点，在混合云/分布式云、边缘等场景下提供了欠缺的平安隔离、攻打防护、威逼检测等伎俩和跨地区多核心的数据备份恢复能力。 在云原生基础架构平安域方面，阿里云提供了全面笼罩的安全措施，基于云原生技术构建容器基础设施、供应链到运行时刻的端到端平安能力，包含在在云原生网络安全侧的七层访问控制和容器防火墙能力；在编排和集群管控侧业界当先的平安加固和访问控制能力以及在云原生供应链侧齐备的DevSecOps能力；在保障最小化攻击面的同时，在运行时刻提供了企业级的智能防护、策略治理和数据安全防护伎俩。 在云原生利用平安域能力方面，阿里云构建了企业级的云原生利用平安架构。针对利用通信提供了全链路多维度的平安隔离和流量剖析能力，同时面向利用外部逻辑提供安全漏洞的主动攻击进攻和接口的敏感信息爱护等能力。在云原生微服务和无服务器架构下，阿里云同样提供了平安熔断、细粒度的租户隔离和智能化的攻打检测能力，为企业应用平安保驾护航。 阿里巴巴在实现外围利用100%云原生化的根底上，云原生研发经营平安域能力方面，阿里云保障了本身研发经营平台从平安需要的自动化治理到功能设计、开发、测试、制品公布的全流程平台化平安治理和DevSecOps能力，保障阿里云平台本身产品从设计研发到经营售卖全生命周期的平安合规性。 在云原生平安运维域能力方面，阿里云针对零信赖架构的特点，面向企业运维侧提供了平台化的身份、明码平安治理能力，以及反对残缺的策略治理、资产治理和全链路平安审计性能，在无效保障企业高效平安运维的同时，阿里云还反对云原生场景下的智能威逼检测、多级响应和溯源剖析的能力，帮忙企业构建全方位平安体系。 总结从互联网到批发、金融、制作、交通等，越来越多的行业在利用云原生技术解决理论业务问题。阿里云丰盛的云原生平安产品家族保障了阿里巴巴本身的大规模云原生化实际，确保利用全生命周期的云原生平安。同时这些云原生平安能力也撑持了云上百万企业，从基础设施、云原生基础架构、云原生利用、云原生研发经营到云原生平安运维，晋升了全链路的安全性及企业平安治理的效率，减速企业的云原生化架构降级，助力企业打造更平安可控、更先进智能的业务体系。

MSE 注册配置核心专业版首购享 9 折优惠，MSE 云原生网关预付费全规格享 9 折优惠。 点击此处，即享优惠！

618 降临，顶峰时段的品牌直播间要同时包容几百万人线上发弹幕、抢货、抢红包，如此大的用户体量、高频交互以及脉冲流量场景，对于后端服务器来说都是不小的挑战。 为了确保线上稳定性以及优质的交互体验，通过性能测试 PTS（Performance Testing Service）进行压测成为很多平台和品牌商的首选。 阿里云 PTS 历经多年双 11 流动的淬炼，是阿里全链路压测的延长。PTS 通过伸缩弹性，可轻松发动百万并发流量，免去机器、人力老本；通过寰球地区的流量发动，以及对流量模型的精准管制，可实在模仿用户的流量起源 。利用 0 编码场景编排、流量录制等性能，可轻松模仿简单的用户互动。压测后通过丰盛的监控及日志数据，以及问题诊断性能，帮忙业务疾速发现瓶颈，晋升零碎性能和稳定性。  5 月 26 日，阿里云性能测试 PTS 2.0 公布，全新计费、丰盛个性、极致体验。新的计费模型大幅升高了用户的压测老本，VPC 内网压测 10 万 VUM 只需 29 元，公网压测 5 万并发最低只需 199 元，百万并发最低只需 6200 元。PTS 进一步拓展了对客界面，用户可通过 JMeter 插件在本地的 JMeter 工具发动云上压测，也可利用 OpenAPI，压测数据凋谢性能将 PTS 能力集成到自建压测平台和 CICD 流程中，更高效地对业务零碎进行检测。PTS 还反对了流媒体、MQTT、RocketMQ、Kafka、JDBC、Redis、Dubbo 等多种协定，用户可对视频直播、IoT、小程序等场景，以及消息中间件、数据库、微服务等自建组件或云产品进行压测。除了新用户 0.99 元起，发布会上还提供了满 100-50、满 1000-200、满 3500-800 等三个阶梯的满减代金券，进一步帮企业升高应用老本。 全网粉丝量超千万的某彩妆品牌，过来在面临大促时，零碎稳定性保障压力很大，第三方接口和一些慢 SQL 就可能导致重大的线上故障；零碎大促时资源与日常资源相差较大，须要频繁扩缩容；此外压测与零碎容量评估的工作十分频繁，须要健常态化的机制来撑持；为了解决这些问题，也为了撑持业务疾速倒退，客户充分利用了 PTS 对系统的单机能力和整体容量进行评估，对单机能承载的业务量、整体能承载的业务量做到提前预判，将来对业务的大促需要能够做出正当的资源布局和老本预测。 某培训公司为了触达更多用户，加强品牌影响力，该机构以独家单干模式资助央视春晚。但在流动筹备期间，客户遇到了规模超大、流量超大、工夫超短等艰难。阿里云帮忙客户疾速建设一套基于云原生的平台撑持春晚流动，同时具备百万并发、千万 QPS、稳固高效、疾速搭建的特点。最终帮忙客户在一个半月落地本应须要半年的新场景大规模我的项目，技术平台的撑持能力晋升了 10 倍+，晋升了客户技术团队在外部的影响力。通过央视春晚的宣传放大，客户走进了全国观众的视线，为培训行业建立品牌新标杆。 某银行机构举办手机 APP 直播流动，须要反对百万用户同时在线，并有频繁的连麦、点赞、红包等互动，对系统的性能、稳定性、应急反馈等有极高的需要。客户利用 PTS 的流量录制和多协定压测能力，将手机用户的在线操作精准地模仿进去。其弱小的施压和调速能力，可模仿终端用户的流量起源和模型。从而帮忙客户精准的规划系统容量，对可能呈现的突发事件进行排练，确保整个零碎的稳定性。同时，PTS 大大缩短了压测引擎的筹备工夫，拉起模仿百万用户在线的引擎工夫缩短到 40 秒；在压测过程中，提供多种压测流量监控伎俩，帮忙定位问题；压测完结后，马上进行压测流量，提供多维度多角度的压测报告和问题诊断工具，大大提高了压测效率。PTS 助力客户顺利完成了直播盛典，当晚观看量冲破 200 万，点赞数超过 1700 万。 ...

2021 年 10 月 20 日，阿里云正式开源云原生分布式数据库 PolarDB-X 的源代码，将自研云原生分布式核心技术分享进去，进一步推动云原生分布式数据库倒退。PolarDB-X 是一款面向超高并发、海量存储、简单查问场景设计的云原生分布式数据库系统。其采纳 Shared-nothing 与存储计算拆散架构，反对程度扩大、分布式事务、混合负载等能力，具备企业级、云原生、高可用、高度兼容 MySQL 零碎及生态等特点。 PolarDB-X 开源至今，在 GitHub 上逐步累积了 1300+ Star，也吸引了宽广开源爱好者的关注。为了帮忙大家可能迅速入门 PolarDB-X 云原生分布式数据库，由阿里云技术专家独特打造 PolarDB-X 开源训练营，本次训练营将实践解说联合手把手的教学，从装置部署到运维实际，更有收费线上场景试验，七天工夫轻松入门 PolarDB-X 开源数据库，实现技术成长与职业冲破，实现技术成长与职业冲破，与阿里云共建云原生数据库生态。优良毕业学员更有机会取得绝佳我的项目内推机会，还有 PolarDB 精美定制礼品、AirPods 等大礼等着你！ 本次训练营限时限额收费抢报！数量无限，报完即止！面向对数据库开源感兴趣的爱好者、数据库 DBA、运维、开发人员以及高校学生等。 报名工夫：即日起-6 月 12 日 开营工夫：6 月 13 日-6 月 19 日 （每晚 20:00-21:00 线上直播授课） 开营名额：3000 人（名额有限，报完即止） 报名地址：https://developer.aliyun.com/... PolarDB-X 源码凋谢地址： 计算层：https://github.com/apsaradb/G... 存储层：https://github.com/apsaradb/G... 报名地址：https://developer.aliyun.com/...

作者：陈锦赐、何淋波 北京工夫 5 月 27 号，OpenYurt 公布 v0.7.0 版本。 新版本中重点公布 Raven 解决方案，该计划在对原生的容器网络计划无侵入的状态下，优雅的解决跨公网的云边，边边的 Pod 间通信问题，不便的满足了云边协同场景下对容器网络的诉求。同时在 OpenYurt v0.7.0 中，也实现对 EdgeX Foundry 的 LTS 版本（Jakarta）的反对，以及 K8s 版本 v1.22 的反对。 无侵入的单集群跨边缘容器网络买通计划 Raven在 OpenYurt 集群中提供包含跨公网边-边、边-云之间的单集群容器网络联通能力，其次要技术原理是通过公网加密隧道让不同的边缘节点上的容器网络互相买通，从而实现跨边的业务流量或者管控流量的通信。并且兼容以后支流的容器网络解决方案(如 flannel，calico 等)，即 NodePool 内的通信仍应用原生容器网络计划。 我的项目背景在边缘计算中，边-边和边-云通信是常见的网络通信场景。对于 OpenYurt 我的项目，咱们曾经引入了 YurtTunnel 来应答边云合作中的运维和监控的网络问题。它提供了对边缘节点执行 kubectl exec/logs 并从边缘节点获取监控指标的性能。然而 YurtTunnel 解决的问题只是边云通信的一个子集，在 v0.7.0 版本以前还没有边-边、边-云容器网络通信的解决方案。 即在某些状况下，OpenYurt 集群中不同物理区域的 Pod 可能须要应用 Pod IP、Service IP 或 Service name 与其余 Pod 通信，尽管这些 Pod 位于单个 K8s 集群中，但它们处于不同物理区域（网络域）中无奈间接通信。 设计理念及架构Raven 我的项目从需要探讨，到方案设计，以及最初的落地实现等都是基于开源社区成员的协同下实现的，整体设计理念次要有： 无侵入：对原生的 K8s CNI 网络无侵入，仅劫持跨边流量进行转发与支流的容器网络计划(如 flannel, calico)可无缝协同运行高安全性：确保跨公网通信的数据安全同时 Raven 解决方案的架构如下图： ...

导读：随着市场竞争的加剧，对企业的软件交付速度提出了更高的要求。落地DevOps、实现高效交付成为了企业独特的谋求。 那么落地DevOps,少不了工具的帮忙。然而，一提到DevOps工具链,很多企业首先想到的就是现下常见的自建工具。是的，这些开源工具都很好，然而企业想要应用它们来搭建一套残缺的DevOps工具链，同时满足账号买通、数据买通、精细化权限治理等企业级需要，须要不少的搭建、开发和保护老本。 而中小企业，往往不足专职的运维人员，抉择阿里云一站式DevOps平台——云效，能够在疾速、低门槛落地DevOps的同时，聚焦外围业务。 相比开源工具自建，咱们为你总结了抉择云效DevOps的6大劣势： 1、DevOps工具链一步配齐，开箱即用 2、一套账号、数据体系，买通所有零碎 3、简略易用，优良实践经验模板化积淀 4、深度集成阿里云产品，云上DevOps工具首选 5、多重企业级平安防控能力，平安可信 6、云效公共云产品，根底版，不限人数，收费应用 上面，咱们将一一论述。 云效一站式DevOps平台，开箱即用云效 DevOps 提供我的项目合作、代码治理、继续交付流水线、云原生利用交付、在线IDE、制品仓库、测试治理、知识库 、效力洞察9大产品，返回 http://devops.aliyun.com/,仅需 1 个阿里云账号，这些 DevOps 工具你就能够一站式配齐。无需搭建和保护老本，开箱即用。 一套账号、数据体系，买通所有零碎应用开源工具自建 DevOps，往往项目管理是一个零碎、代码治理是一个零碎、继续集成又是另一个零碎。每个零碎都须要搭建不说，账号、数据都是独立的，保护起来很简单。 抉择云效 DevOps，同一个阿里云账号，即可拜访所有产品。 不仅如此，应用云效的 DevOps 我的项目，从工作 -> 代码分支 -> 代码提交记录 -> CI/CD 公布进度，一个我的项目外面就能够理解全副，无需切换多套零碎。 简略易用，优良实践经验模板化积淀云效提供简略、可视化的操作界面，相比于 jenkins 更容易上手。此外，云效继续交付流水线 Flow 还内置了丰盛的模板。 可视化的流水线配置让之前繁琐的脚本编写工作一去不复返。更重要的是，企业优良的实践经验，也能够保留为模板，积淀复用，缩小反复工作。 深度集成阿里云产品，云上 DevOps 工具首选云效与阿里云产品采纳同一套账号体系，与阿里云云服务器 ECS、容器服务 ACK、函数计算 FC、企业级利用架构 EDAS 、阿里云钉钉等无缝连接，既缩小了账号保护老本，也升高了账号泄露带来的平安危险。 不仅如此，云效流水线还内置了分批、灰度、蓝绿等常见部署策略，同时反对主机和 K8S，缩小额定的开发配置老本。 多重企业级平安防控能力，平安可信开源版本的 DevOps 工具往往短少企业级的平安防控能力，企业想要保障生产平安可控，要么抉择付更多的钱降级为付费版，要么钻研如何集成其余平安工具，更甚者须要基于它进行二次开发以达到企业标准的平安规范。 云效 DevOps 通过了公安部网络安全等级爱护 2.0 三级认证、ISO 27001 信息安全管理体系规范认证、ISO 9001 品质管理体系认证，标记着云效平安实际达到国内外相干权威机构的平安规范要求，用户应用云效的数据保密性、完整性、可用性和隐衷性曾经与国内外最佳实际对标，且失去独立第三方平安认证。 云效从多方面为企业提供平安性能个性，为企业研发资产保驾护航。 第一，云效提供多种备份机制，叠加阿里云高防产品的防护能力，能够充沛保障企业的代码资产平安及稳定性。 第二，云效敏感行为检测针对成员异样行为触发告警。云效还内置代码敏感信息检测、依赖包破绽检测服务，升高企业敏感信息泄露危险，加强代码安全性。 ...

Seata 1.5.1 正式公布。Seata 社区向所有开发者致敬，祝大家有一个欢快的假期。 用户注销欢送已应用用户在此链接注销，便于咱们更好的针对业务场景优化：https://github.com/seata/seat... 公布概览次要新增个性：反对用户控制台，反对 Skywalking tracing 集成，反对 bRPC、EDAS Hsf，反对 kotlin 协程，反对 TCC 幂等/空回滚/防悬挂，反对分布式任务调度，反对 Redis 存储 lua 模式，反对 ON DUPLICATE KEY UPDATE 等语法解析。 此次 release  批改文件数：872，最终代码变动：+60830，-9435 ，参加代码 commit 人数：60+，合并pr数：230，其中：feature：30+，bugfix：60+，优化重构测试及其他：100+。 https://github.com/seata/seat... 此版本是目前参加代码提交人数最多和合并pr最多的版本，感激大家的奉献。 控制台预览： SkyWalking： 非常感谢 @SkyWalking 社区的大力支持。 版本的次要更新feature：[#4115] 反对用户控制台[#3652] 反对 APM SkyWalking 集成[#3472] 增加 redisLocker 的 lua 模式[#3575] 反对对锁和会话不同存储的混合应用[#3009] 反对 server 端以 springboot  的形式的启动[#3374] 反对 MySQL INSERT ON DUPLICATE KEY UPDATE[#3642] TCC 模式反对应用 API 的模式进行二阶段参数传递[#3064] 反对可配置 GlobalTransactionInterceptor 和 TccActionInterceptor 的 order 值[#2852] 反对自定义 GlobalTransactionScanner 的扫描对象。[#3683] 反对 Redis 分布式锁来防止多 TC 竞争执行工作[#3545] TCC 模式反对幂等管制、防悬挂和空回滚[#3823] TCC 模式二阶段办法参数列表反对自定义[#3642] TCC 模式一阶段反对 BusinessActionContext 隐式传递[#3856] 反对 Edas-Hsf RPC 框架[#3869] 反对从环境 ENV 获取配置[#2568] 反对 GlobalTransactionInterceptor 配置切面表达式[#3886] 反对注册核心注册 ip 的网络偏好设置[#3906] 反对 SPI 卸载[#3668] 反对 kotlin 协程[#3968] 反对 bRPC-java RPC框架[#4268] 减少控制台 Global Session页面File模式实现[#4281] 减少控制台 Global Session页面和Global LockRedis模式实现[#4293] 减少控制台 Global Lock页面File模式实现[#4335] 实现配置核心上传配置交互脚本(nacos,etcd3)[#4360] 实现配置核心上传配置交互脚本(apollo,consul,zk)[#4320] 实现控制台db模式全局事务、锁查问接口[#4435] 控制台前端页面实现[#4480] 实现 DefaultAuthSigner 的默认签名加密办法[#3487] 减少分布式锁的 DB 实现[#3951] 反对 zstd 压缩[#2838] Saga 反对 springboot 我的项目的主动配置bugfix：[#3497] 修复 TCC 模式并发量较大时线程池导致的超时问题[#3686] 修复 Apollo 集群配置项谬误及NPE谬误[#3716] 修复 findTargetClass 办法的谬误[#3773] 修复 consul 注册核心在自定义集群名下无奈获取 TC 集群[#3695] 修复 mariadb 无奈创立XA连贯的问题[#3783] 修复 store mode 不失效问题[#3740] 修复在某些状况下，当Saga事务完结时 LocalThread 未被革除的问题[#3792] 修复 Server 无奈获取 Redis host的问题[#3828] 修复 StringUtils 抛出 StackOverflowError 的问题[#3817] 修复 TC 在SkyWalking拓扑图节点不汇聚的问题[#3803] 修复 ReflectionUtil 抛出不预期异样问题[#3879] 修复 PosrgreSQL多schema无奈找到channel问题[#3881] 修复不存在的雷同 DataId 不同默认值返回雷同值的问题[#3897] 修复 FastjsonUndoLogParser 中 localdatatime类型不能回滚的问题[#3901] 修复 seataio/seata-server 镜像中 servlet-api 抵触无奈启动问题[#3931] 修复 线程池拒绝执行状况下,dump内存文件名和门路谬误的问题[#3949] 修复 nacos-config.py 空白选项的问题和内容失落的问题[#3988] 修复 nacos 的明码带有特殊字符导致用户名不存在问题[#3978] 修复 future timeout 引发的 NPE 问题[#3998] 修复 jedis multi.exec 的 NPE 问题[#4011] 修复 springboot下无奈获取distributed-lock-table配置[#4023] 修复 dubbo局部场景存在xid未革除的问题[#4032] 修复 server端的ShutdownHook在资源开释时，ApplicationContext已敞开的问题[#4039] 修复本地事务抛出异样后 RM 没有革除xid问题[#4074] 修复 XA 模式资源悬挂问题[#4107] 修复我的项目构建时的死锁问题[#4158] 修复 logback 无奈加载到 RPC_PORT 的问题[#4162] 修复  Redis 注册核心内置配置名导致启动报错问题[#4165] 修复 StringUtils.toString(obj) 当obj是根本数据数组时，抛出ClassCastException的问题[#4169] 修复 XA 模式originalConnection已敞开，导致二阶段无奈执行[#4177] 修复当事务超时且TM发动commit决定时,意外造成全局锁开释的问题[#4174] 修复删除 undolog 时连贯敞开问题[#4189] 修复 kafka-appender.xml 和 logstash-appender.xml 配置文件表达式中的默认值问题。[#4213] 修复局部"sessionMode"代码未执行导致启动失败问题[#4220] 修复 zstd-compressor 模块未合并到 seata-all 中的问题[#4222] 修复字段列表为空时，插入语句无奈回滚的问题[#4253] 修复 UpdateExecutor只存储set 字段问题[#4233] 修复 lock 和 branch 数据残留问题[#4278] 修复 MySQL 的Blob/Clob/NClob数据类型无奈反序列化的问题[#4302] 修复 ORM 可能存在获取不到自增主键值的问题[#4308] 修复PostgreSQL多个schema下存在雷同表的TableMetaCache解析问题[#4326] 修复应用 MariaDB 驱动程序时无奈构建 Executor 的问题[#4355] 修复应用 MySQL Loadbalance模式resourceId被误判为resourceIds的问题[#4310] 修复通过 SELECT LAST_INSERT_ID 获取数据库自增id失败的问题[#4331] 修复应用 ONLY_CARE_UPDATE_COLUMNS 配置可能呈现的脏写校验异样[#4408] 修复容器环境中设置环境变量有效的问题[#4441] 修复Redis 存储模式下查问时未敞开 Pipeline 和分支注册后增加分支session时branchSessions为null的问题[#4438] 修复 file 模式下 GlobalSession 在提早删除的状况下无奈被失常删除的问题[#4432] 修复 ServerApplicationListener无奈读取配置核心配置的问题[#4452] 修复 service.disableGlobalTransaction 配置的日志输入谬误[#4449] 修复 Redis 分页查问 NPE 问题,优化readession限度查问条数后平衡返回后果[#4459] 修复 Oracle 和 PostgreSQL 数据库生成前后镜像失败的问题[#4471] 修复运行时切换事务分组对应集群引起的谬误[#4474] 修复 MySQL 多位Bit类型字段回滚谬误[#4492] 修复 eureka 注册核心无奈动静更新服务列表的问题[#4228] 修复 TC 获取不同 ip 的 RM 连贯导致的xa模式资源悬挂问题[#4561] 修复 allSessions/findGlobalSessions 某些状况下返回null 的问题[#4505] 修复 time类型的fastjson序列化问题[#4579] 修复 MySQLInsertOrUpdateExecutor的prepareUndoLogAll[#4005] 修复 PK 束缚名称与属于PK的惟一索引名称不同[#4062] 修复 Saga 简单参数序列化问题[#4199] 修复 RPC TM 申请超时问题[#4352] 修复 SQL 解析器的一些问题[#3687] 修复某些场景下无奈重试全局锁的问题optimize/test：[#3700] 优化buildLockKey办法的效率[#3615] 优化二阶段同步提交时全局事务记录可异步删除[#3689] 修改script/server/config/file.properties中属性编写谬误[#3588] 优化数据源主动代理的流程[#3528] 优化Redis存储模式内存占用[#3626] 移除反复的changeStatus代码[#3722] 增加分布式锁的代码[#3713] 对立enableClientBatchSendRequest的默认值[#3120] 优化Configuration的局部代码，并增加单元测试[#3735] 当TC只有单个节点时，不进行非必要的负载平衡操作[#3770] 敞开一些未敞开的对象[#3627] 应用TreeMap替换 TableMeta 中的 LinkedHashMap 以兼容高版本的MySQL[#3760] 优化seata-server的logback相干的配置[#3765] 将增加配置类的操作从AutoConfiguration转移到EnvironmentPostProcessor中并晋升该操作的优先级[#3730] 重构TCC模式相干的代码[#3820] 在表tcc_fence_log中新增字段action_name[#3738] JacksonUndoLogParser反对解析LocalDateTime(反对微秒工夫)[#3794] 优化seata-server的打包配置，修改Dockerfile的谬误配置，并将Dockerfile也打包进去[#3795] 优化zkRegistrylookup办法性能[#3840] 优化apm-skwalking操作方法生成规定[#3834] 优化seata-distribution减少apm-seata-skywalking包[#3847] 优化ConcurrentHashMap.newKeySet替换ConcurrentSet[#3849] 优化字符串拼接[#3890] 优化insert后镜像仅查问插入字段[#3895] 优化解码异样[#3212] 优化解析OrderBy，Limit条件代码构造[#3898] 减少docker maven 插件[#3904] 加强 metrics 和修复 seata-server 单测不运行的问题[#3905] 优化 nacos-config.sh 反对 ash[#3935] 优化以Redis为注册核心时,发送多条命令应用pipeline[#3916] 优化注册核心服务节点列表地址探活[#3918] 缓存Field和Method的反射后果[#3311] 反对从consul繁多key中读取所有配置[#3907] 优化设置 Server 端口[#3912] 反对通过env配置JVM参数[#3939] 应用map优化大量的判断代码[#3955] 增加启动banner[#4266] 批改因为批改记录过多导致分支注册及lock开释失败的问题[#3949] nacos-config.py 反对默认参数和选择性输出参数[#3954] 移除对druid依赖中过期办法的调用[#3981] 优化服务端口的优先级设置[#4013] 优化可用TC地址检测[#3982] 优化 readme 文档和降级POM依赖[#3991] 敞开SpringBoot下无用的fileListener[#3994] 优化tcc_fence_log表定时删除工作的机制[#3327] 反对从etcd3繁多key中读取所有配置[#4001] 反对从Nacos,Zookeeper,Consul,Etcd3 中读取 yml[#4017] 优化文件配置[#4018] 优化 Apollo 配置[#4021] 优化 Nacos、Consul、Zookeeper、Etcd3 配置[#4055] 优化NetUtil的getLocalAddress0办法[#4086] 分支事务反对懒加载并优化任务调度[#4056] 优化 DurationUtil[#4103] 缩小分支事务注册无需竞争锁时的内存占用[#3733] 优化本地事务下的锁竞争机制[#4144] 反对默认的事务分组配置[#4157] 优化客户端批量发送申请[#4191] RPC 申请超时工夫反对配置化[#4216] 非 AT 模式毋庸清理undolog表[#4176] 优化 Redis 注册核心存储，改用主动过期key代替hash.[#4196] TC 批量响应客户端[#4212] 控制台接口合并优化[#4237] 当所有的 before image均为空的时候，跳过 checkLock 的步骤[#4251] 优化局部代码解决[#4262] 优化 TCC 模块代码解决[#4235] 优化 eureka 注册核心保留实例信息[#4277] 优化 Redis-pipeline模式本地事务下的锁竞争机制[#4284] 反对 MSE-Nacos 的 ak/sk 鉴权形式[#4299] 优化异样提醒[#4300] 优化NettyRemotingServer的close()[#4270] 进步全局提交和全局回滚的性能，分支事务清理异步化[#4307] 优化在 TCC 模式缩小不必要的全局锁删除[#4303] tcc_fence_log表悬挂日志记录异步删除[#4328] 配置上传脚本反对正文[#4305] 优化 TC 端全局锁获取失败时的日志打印[#4336] 增加 AT 模式不反对的SQL语句异样提醒[#4359] 反对配置元数据读取环境变量[#4353] seata-all.jar 瘦身。[#4393] Redis & DB 模式下启动不须要reload[#4247] 在github actions上，增加基于 java17 和 springboot 各版本的测试[#4400] 异步二阶段工作反对并行处理晋升效率[#4391] commit/rollback 重试超时事件[#4282] 优化回滚镜像构建逻辑[#4276] 修复 seata-test 单测不运行的问题[#4407] file模式下无需提早删除globasession[#4436] 优化file模式下的global session查问接口[#4431] 优化Redis模式查问globalSession限度查问条数[#4465] 优化TC 批量响应客户端模式客户端版本传输方式[#4469] 优化控制台db模式下获取配置的形式[#4478] 优化 Nacos 配置和注册元数据属性[#4522] 优化 GC 参数[#4517] 加强失败/超时状态的监控[#4451] fileSessionManager改为单例并优化工作线程池解决[#4551] 优化 metrics rt 统计问题[#4574] 反对 accessKey/secretKey 配置主动注入[#4583] DefaultAuthSigner 的默认签名加密办法替换为HmacSHA256[#4591] 优化开关默认值[#3780] 降级 Druid 版本[#3797] 反对在Try 办法外由用户本人实例化BusinessActionContext[#3909] 优化collectRowLocks 办法[#3763] 优化 github actions[#4345] 修改包目录名[#4346] 优化服务器日志并移除lombok[#4348] 对立治理maven插件及其版本[#4354] 优化saga测试用例[#4227] 对立治理依赖的版本，并且降级spring-boot到2.4.13[#4453] 降级 eureka-clients 和 xstream 的版本[#4481] 优化nacos配置和命名属性[#4477] 优化调试级别日志并修复拼写错误[#4484] 优化TM/RM注册时TC的日志打印[#4458] 修复 metrices 模块 README.md 的配置脱漏问题[#4482] [#3654] 修复typos[#3880] 奉献文档减少中文版本[#4134] 初始化控制台根底代码[#3870] 让seata-bom成为真正的Bill-Of-Material[#3889] 反对注册核心增加心跳[#3702] 批改正文[#4608] [#3110]修复测试用例[#4163] 欠缺开发者贡献文档[#3678] 补充脱漏的配置及新版本pr注销md文件[#4449] 优化 Redis limit 并修复 Redis 分页问题[#4535] 修复 FileSessionManagerTest单测谬误[#4025] 优化潜在的数据库资源泄露英文版： https://github.com/seata/seat... ...

作者：张添翼(澄潭) 为了防止混同，咱们先对一些要害定义做一些厘清： 传统网关：未作容器化革新，未启用 K8s，通过流量网关与业务网关两层网关来构建，流量网关提供全局性的、与后端业务无关的策略配置，例如 Tengine 就是典型的流量网关；业务网关提供独立业务域级别的、与后端业务紧耦合策略配置，随着利用架构模式从单体演进到当初的散布式微服务，业务网关也有了新的叫法 - 微服务网关。K8s 网关：即云原生网关，也被称为下一代网关，Ingress 成为 K8s 生态的网关规范，促使流量网关和业务网关，合二为一。基于 Ingress 标准的实现次要分为基于 Nginx 和基于 Envoy 两大阵营，基于 Nginx 的 Nginx Ingress Controller 是目前大多数 K8s 集群的抉择，基于 Envoy 的实现作为后起之秀，大有赶超之势。MSE 云原生网关：是基于 Envoy，做了深度优化的云上服务。本文将从性能和老本、可靠性、安全性 3 方面，对两大开源实现进行比对，心愿对正在做 K8s 网关选型的企业有所借鉴。 性能和老本MSE 云原生网关的吞吐性能简直是 Nginx Ingress Controller 的一倍，尤其是传输小文本时性能劣势会更显著，如下图所示，网关 CPU 使用率达到 30% 时的吞吐比照： 网关规格：16 核 32 G * 4 节点 ECS 型号：ecs.c7.8xlarge 当 CPU 负载升高时，吞吐差距会更加显著，下图是 CPU 使用率达到 70% 时的状况： 高负载下 Nginx Ingress Controller  吞吐降落起因是呈现了 pod 重启，详情见下一节“可靠性”中的剖析。 ...

产学单干协同育人在教育部高教司领导下，围绕国家重大策略需要、产业转型降级、创新型人才培养，阿里云通过教育部产学单干协同育人我的项目平台反对高校金专、金课建设、助力高校教育品质晋升，独特造就理工农医类业余紧缺型人才，服务制作强国、品质强国、网络强国、数字中国建设。 2022 教育部-阿里云产学单干协同育人我的项目介绍阿里云公司针对 2022 年 4 月批次，将设立  “要害畛域卓越工程师联结造就基地我的项目” 、 “教学内容和课程体系改革” 、 “师资培训” 、 “实际条件和实际基地建设” 四大类共 85 个我的项目。 本篇将介绍 “云原生技术利用与实际” 系列示范课程建设项目 我的项目介绍该我的项目基于以后业界利用宽泛的云原生技术，建设产教交融示范课程和试验案例。面向计算机、软件学院的软件工程类相干课程，如云原生零碎开发、高级软件工程等；基于云的软件开发、部署和演变，对原有的常识体系和课程实际内容进行重构。突出微服务架构、容器化部署、开发运维一体化等云原生软件技术的特点。 建成一批高质量、可向全国高校共享的课程教案和教学改革计划，造就宽广学生云原生技术开发思维和工程技能，晋升学生数字化素养。  我的项目周期：两年申报条件申报课程应以现有课程为根底, 曾经开设或行将在 2022 年秋季学期开设的课程。 申报课程学时安顿应不少于 32 学时，均匀每年开课次数不少于一次。 同等条件下，优先思考已在高校开设一年以上课程，优先思考受害面大的课程申报（须提供学校教务处过来一年内的开课和选课状况证实）。 申报的课程如已成为学校、市级或省级精品课程建设项目，将优先思考（须提供精品课程证书）。 建设要求示范课程建设项目成绩，须蕴含课程内容和典型教学案例两局部，造成残缺的我的项目建设内容。 立项示范课程我的项目须实现以下工作： 加入一次阿里云组织的云原生技术师资培训，取得培训证书；课程纲要：包含具体的课程工夫调配、章节、试验、习题形容；将阿里云云原生的相干技术内容（如容器、微服务、中间件、Serverless 等），系统性融入课程纲要，相干内容的学时不少于 8 学时；老师授课教案：每章节均提供 PPT 课件。提供课程相干的参考书目、论文参考文献、网络资源等内容；典型教学实验案例：围绕课程教学内容，开发不少于 4 个典型教学实验案例（试验形容、试验步骤和代码）；习题：依照教学内容和进度状况，每章节均设计与该章节匹配的习题，并给出参考答案；课程视频内容；公开发表的教学论文；激励编写云原生技术生态的软件工程类教材书籍，须系统性融入阿里云的云原生技术内容包含容器、微服务、中间件、Serverless 以及 RocketMQ、Dubbo、Nacos 等出名开源我的项目等（有额定赞助）；激励学生加入云原生开源我的项目；激励学生基于云原生技术进行原创性科学研究、在国内外高水平会议和期刊上发表学术论文；结题报告和教务处提供的开课与选课人数证实；请明确注明可公开、可共享。技术与教辅资源反对:[1]微服务治理技术白皮书： https://developer.aliyun.com/... [2]Nacos架构&原理： https://developer.aliyun.com/... [3]微服务实战技术图谱： https://developer.aliyun.com/... [4]Serverless 技术图谱： https://developer.aliyun.com/... [5]云原生技术公开课： https://edu.aliyun.com/roadma... [6]Kubernetes 技术图谱： https://developer.aliyun.com/... [7]RocketMQ 官网： https://rocketmq.apache.org/ [8]RocketMQ 代码托管： https://github.com/apache/roc... 我的项目分割我的项目联系人：姜曦：云原生利用平台经营 邮箱：jessie.jx@alibaba-inc.com 注：本批次我的项目申报截止日为 2022 年 6 月 30 日 ...

近日， 深圳前海硬之城信息技术有限公司 SaaS 平台（V1.0）、硬氪ERP（V1.0）通过阿里云产品集成认证测试，与阿里云旗下产品容器服务 ACK 深度集成。此前，硬之城胜利入选阿里云首期云原生加速器，这次取得产品生态集成认证意味着在云原生畛域硬之城与阿里云正式携手单干。 相干浏览： 31 家企业入选阿里云首期云原生加速器，共建云原生行业新生态阿里云云原生加速器成员企业硬之城：基于云钉一体实现智能智造产业链降级阿里云云原生利用平台总经理丁宇：“连贯、单干、赋能”，携手加速器搭档助力企业云上翻新此前，阿里云首次提出了“被集成”策略：将行业解决方案的搭建、施行、复制交由合作伙伴，阿里云只承当基础设施（IaaS）、技术中间件（PaaS）、数据平台（DaaS）层面的产品技术。“被集成”是阿里云对业务边界进行认真思考后作出的一个重要转变，标记着阿里云生态对合作伙伴的全面凋谢。 阿里云产品生态集成认证是面向阿里云合作伙伴自有产品、解决方案与阿里云相干产品的兼容性、可用性的技术能力认证。取得此认证，证实了硬之城的技术能力、产品利用程度已满足阿里云相干产品的适配性要求，硬之城以阿里云技术底座，为用户提供牢靠、无效的产品与解决方案技术服务，这为硬之城与阿里云生态的严密单干提供了强力的技术保障。 深圳前海硬之城，成立于 2016 年，是一家数字化的电子产业供应链和制作平台，它的定位是为具备新硬件需要的科创类公司提供包含电子器件、PCB、SMT 的一站式的交付能力服务。对于中小企业来说，这是一个正当备货正当采买的获取供应链服务+制作加工服务平台。 深圳前海硬之城有限公司 CIO 张兴瑜在承受采访时说：“咱们的定位是参谋式服务于新硬件公司。这些智能科技公司特地是中小企业，刚开始的时候，他们有好的 idea、好的设计方案，然而供应链和制作是他们的短板。咱们做这个事的实质，是因为咱们理解客户的痛点，心愿通过这个数据化的电子产业供应链和平台解决这个痛点，助力客户胜利，也是在这里咱们找到了阿里云。” 在硬之城，基于阿里云容器服务 ACK、 分布式技术、 微服务、服务网格构建的 CRM、BOSS、ERP、MES 则实现了电子产业链端到端全价值链的贯通，分类分级流转、智能举荐询报价、执行和履约，以 MES 实现了工序治理（核料、钢网制作、MSD 烘烤、SMT 贴片、SMT 首件检测、回流焊、DIP 等工序）、工艺路线生成、流转，生产可视化治理。DSMS 买通需要、供应链、制作畛域，实现企业上下游、内部生态的数字协同和价值发明，笼罩了研、供、制、销、服 5 大畛域。 除了弱小的零碎能力，云原生的利用更加颠覆了硬之城传统 MES、ERP 的施行过程，极速体验，开箱即用，用户能够按需疾速容器化 Pod 来部署一套独立的 MES、ERP 零碎，满足客户环境的各种要求，且能够通过共用 ACR 镜像仓库，满足全国版本多地区秒级更新，让客户享受到最新的性能个性。这让硬之城更有底气和能力去助力客户去解决信息不对称的问题，疾速帮忙中小企业高效实现供给产能对接。 阿里云是云原生的引领者和最佳实践者。阿里云领有国内最丰盛的云原生产品家族，有超过 300 款的产品，近千个技术解决方案。随着容器成为用户应用云的新界面，阿里云容器服务也全面降级为 ACK Anywhere，使企业在自建数据中心内也能体验到低成本、低提早、本地化的公共云产品能力。相比开源计划，阿里云容器服务实现了 40%的性能晋升，容器网络延时升高 50%，异构资源利用率晋升 100%，并实现全链路可观测。本次硬之城取得阿里云产品集成认证，代表了硬之城在生态单干建设上迈过了一个新里程碑。 硬之城始终以生态搭档的身份与阿里云放弃着深度单干。将来，借助阿里云的“被集成”生态策略与生态集成技术的全面凋谢，单方的严密单干将进入新的阶段，独特为中国数千万家企业提供数字化转型服务。

作者：草谷 Apache ZooKeeper 在阿里巴巴经验了开源自用、深度优化、反哺社区、开发企业版服务云上客户的演进过程，为了厘清本文脉络，咱们对演进过程中提到的要害名词做以下定义。 Apache ZooKeeper：提供分布式协调服务如分布式锁、分布式队列等，还可用于注册配置核心的能力。TaoKeepeer：基于 ZooKeeper 做了深度革新，于2008年服务于淘宝。MSE：阿里云的一个面向业界支流开源微服务生态的一站式微服务平台。ZooKeeper 企业服务：MSE 的子产品，提供开源加强的云上服务，分为根底版和专业版两种。ZooKeeper 在阿里巴巴的服务状态演进历程早在 2008 年，阿里巴巴基于 ZooKeeper 的开源实现和淘宝的电商业务，设计 Taokeeper 这款分布式协调软件，彼时恰逢淘宝启动服务化革新，那时候，也诞生了各类分布式中间件，例如 HSF/ConfigServer/VIPServer 等。 10 年后的 2019 年，阿里巴巴施行全站上云战斗，所有的产品都须要降级到私有云架构，MSE 就是在那个时候诞生的，上线后便兼容了支流的 ZooKeeper 版本。 整个过程经验了以下 3 个阶段： 第一个阶段：08 年的 1.0 版本，次要反对团体有分布式协调需要的利用，那时候所有的业务都是混着用，有 1000 多个利用，最终大略手动运维着 150+个共享集群。随着工夫的推移，业务都在做微服务拆分，共享集群的容量爆炸式增长，这样带来的问题就是：业务混部，爆炸半径大，稳定性存在着很大的危险；日常的运维，例如机器置换等，牵一发而动全身，如果配置出问题，影响所有业务。 第二个阶段：为了解决阶段一的问题，咱们将 ZooKeeper 演进到 2.0 版本。那时候耿直容器化刚刚衰亡，在认真钻研过容器化的革新计划后，咱们在性能和运维可能同时满足要求的状况下，进行了大量的革新，业务进行拆分、集群迁徙、按最小稳固单元去运维一个集群，这样咱们终于能够睡个安稳觉了，拆分完后，依靠于 K8s 的规模化运维能力，这些问题都失去了很好的解决，由此实现了独享模式集群、资源隔离，SLA 失去了晋升，能达到 99.9%。 第三个阶段：上云提供公共云服务，也就演进到了 3.0。这个版本重点打造了开源加强，例如，基于 Dragonwell 进行构建、JVM 参数调优、集成了 Prometheus、部署状态多 AZ 强制均匀打散、反对动静配置 、平滑扩缩容等革新，在性能、免运维、可观测、高可用和平安等方面做了诸多晋升，SLA 可能达到 99.95%。 ZooKeeper 在技术场景上的最佳实际接下来，给大家介绍下 ZooKeeper 的最佳实际场景，归为了 3 类，别离是： 微服务畛域，代表的集成产品是 Dubbo/SpringCloud大数据畛域，代表的集成产品是 Flink/Hbase/Hadoop/Kafka自研的分布式系统，包含大家本人公司外部的分布式系统，对分布式协调有需要，如分布式锁微服务畛域-注册核心ZooKeeper 在微服务场景外面，次要是用作注册核心，利用了 ZooKeeper 的注册/订阅模式，能够看下 Dubbo 在 ZooKeeper 外面的数据结构： ...

作者：王飞龙（不物） 目前 Kubernetes 曾经成为业界容器编排零碎的事实标准，基于 Kubernetes 的云原生利用生态（Helm, Istio, Knative, Kubeflow, Spark on Kubernetes 等）更是让 Kubernetes 成为云操作系统。在这样的背景下，Serverless 容器成为现有 Container as a Service 的进化方向之一，一方面通过 Serverless 形式根本性解决了 Kubernetes 本身的治理复杂性，让用户无需受困于 Kubernetes 集群容量布局、平安保护、故障诊断；另一方面也进一步开释了云计算的能力，将平安、可用性、可伸缩性等需要由基础设施实现。 ASK 作为阿里云 Serverless Kubernetes 平台 [ 1] ，不仅有免运维、秒级弹性、超大 Pod 容量、弹性预测等重磅能力，更重要的是它仍然是一个规范 Kubernetes 平台。 本文会通过在 ASK 上试用 Istio 部署微服务利用的形式，来验证 ASK 对规范 Kubernetes 的兼容性。Istio 作为 Service Mesh（服务网格）的领导解决方案，一方面自身足够简单具备代表性，另一方面它也代表了云原生时代微服务架构的趋势具备参考意义。 当初就让咱们开始吧！ 创立集群试用 Istio 前，须要筹备一个 ASK 集群。登录阿里云控制台，抉择产品与服务 > 容器服务 Kubernetes 版，在左侧边栏抉择集群进入集群列表页面。点击右上角创立集群开始创立集群，配置集群参数如下： 集群名称：hello-istio集群规格：Pro 版地区：美国（硅谷）付费类型：按量付费Kubernetes 版本：1.20.11-aliyun.1专有网络：主动创立Service CIDR：172.21.0.0/20API Server 拜访：标准型I（slb.s2.small）应用 EIP 裸露 API Server：是时区：Aisa/Shanghai（UTC+08:00）服务发现：CoreDNS应用日志服务：创立新 Project确认配置后点击创立集群进入期待集群创立实现。Istio 依赖 DNS 服务，这里抉择创立集群时默认装置 CoreDNS 组件。 ...

开源之夏是什么？开源之夏是由“开源软件供应链点亮打算”发动并长期反对的一项暑期开源流动，旨在激励在校学生积极参与开源软件的开发保护，促成优良开源软件社区的蓬勃发展，造就和挖掘更多优良的开发者。 流动联结国内外各大开源社区，针对重要开源软件的开发与保护提供我的项目工作，并面向寰球高校学生凋谢报名。 学生可在本流动中自主抉择感兴趣的我的项目工作进行申请，并在当选后取得该开源我的项目资深维护者（社区导师）亲自领导的机会，实现我的项目并奉献给社区后，参加学生还将取得开源之夏流动奖金和结项证书。 我的项目简介作为阿里巴巴开源的一款帮忙分布式应用疾速进行打包、交付和运行的解决方案，sealer 能够通过把分布式应用及其数据库中间件等依赖项一起打包来解决简单利用的交付问题。 sealer 构建进去的产物咱们称之为集群镜像，集群镜像里内嵌了一套残缺的 Kubernetes + 容器，它们双剑合璧，解决了分布式应用的交付一致性问题。 sealer 曾经进入 CNCF sandbox。 点击查看「开源夜聊第一期：聊聊 sealer 开源背地的故事」：https://www.bilibili.com/vide... 题目简介sealer runtime 扩大，反对 k3s k0s sealer 架构分成两大块，Build 模块与 Run 模块，其中 Run 局部次要分成三层，最底层对接各种基础设施，如裸服务器，各种私有云，Runtime 层面反对具体的 K8s 实现，如 kubeadm k3s k0s 等，一旦扩大了 runtime 意味着用户构建镜像的时候就能够这样： FROM k3s:latestCOPY mysql .CMD kubectl apply -f mysql应用 sealer build -t k3s-with-mysql:latest . 构建一个在 k3s 下面的 mysql 集群镜像运行时只须要：sealer run 3s-with-mysql:latest 即可运行一个 k3s 并且启动 mysql 集群本次题目次要是实现 runtime 的 interface: type Interface interface { Init(cluster *v2.Cluster) error Upgrade() error Reset() error JoinMasters(newMastersIPList []string) error JoinNodes(newNodesIPList []string) error DeleteMasters(mastersIPList []string) error DeleteNodes(nodesIPList []string) error GetClusterMetadata() (*Metadata, error) UpdateCert(certs []string) error}制作并提供 k3s k0s 的根底镜像，使用户能够通过 sealer 一键应用 k3s k0s ...

对于运维人而言，如何装置保护一套监控零碎，或如何进行技术选型，从来不是工作重点。如何借助工具对所需的利用、组件进行监控，发现并解决问题才是重中之重。 随着 Prometheus 逐步成为云原生时代可观测规范，为了帮忙更多运维人用好 Prometheus，阿里云云原生团队将定期更新 Prometheus 最佳实际系列。第一期咱们解说了《最佳实际｜Spring Boot 利用如何接入 Prometheus 监控》，明天将为大家带来，音讯队列产品 Kafka 的监控最佳实际。 本篇内容次要包含三局部：Kafka 概览介绍、常见要害指标解读、如何建设相应监控体系。 什么是 KafkaKafka 起源Kafka 是由 Linkedin 公司开发，并捐献给 Apache 软件基金会的分布式公布订阅音讯零碎，Kafka 的目标是通过 Hadoop 的并行加载机制来对立线上和离线的音讯解决，也是为了通过集群来提供实时的音讯。 Kafka 的诞生是为了解决 Linkedin 的数据管道问题，用作 LinkedIn 的流动流（Activity Stream）和经营数据处理管道（Pipeline）的根底。起初 Linkedin 采纳 ActiveMQ 进行数据交换，但过后的 ActiveMQ 无奈满足 Linkedin 对数据传递零碎的要求，经常出现音讯阻塞或者服务无奈失常拜访等问题。Linkedin 决定研发本人的音讯队列，Linkedin 时任首席架构师 Jay Kreps 便开始组建团队进行音讯队列的研发。 Kafka 个性相较于其余音讯队列产品，Kafka 存在以下个性： 持久性：音讯被长久化到本地磁盘，并且反对数据备份避免数据失落；高吞吐：Kafka 每秒能够解决百万条音讯；可扩大：Kafka 集群反对热扩大；容错性：容许集群中节点失败（若正本数量为 n,则容许 n-1 个节点失败）；高并发：反对数千个客户端同时读写。与此同时，区别于其余音讯队列产品，Kafka 不应用 AMQP 或任何其余事后存在的协定进行通信，应用基于 TCP 的自定义二进制协定。并具备弱小的排序语义和持久性保障。 Kafka 利用场景基于以上的个性，Kafka 通过实时的解决大量数据以满足各种需要场景： 大数据畛域：如网站行为剖析、日志聚合、利用监控、流式数据处理、在线和离线数据分析等畛域。数据集成：将音讯导入 ODPS、OSS、RDS、Hadoop、HBase 等离线数据仓库。流计算集成：与 StreamComput e、E-MapReduce、Spark、Storm 等流计算引擎集成。Kafka 技术架构一个音讯队列 Kafka 版集群包含 Producer、Kafka Broker、Consumer Group、Zookeeper。 ...

阿里巴巴利用研发平台 EMAS 4月份产品动静已更新，具体内容包含 Pod装置插件优化，减少fastgit镜像反对； iOS 视频流从 http 协定改成 tcp 协定；Android降级根底库解决隐衷合规问题；Android反对不初始化Sophix，以解决隐衷合规要求在批准隐衷合规协定前不初始化第三方sdk······多项降级服务旨在为您带来更好的应用体验，欢迎您退出EMAS开发者钉钉交换群。 一、内容摘要Pod装置插件优化，减少fastgit镜像反对iOS 视频流从 http 协定改成 tcp 协定Android降级根底库解决隐衷合规问题Android反对不初始化Sophix，以解决隐衷合规要求在批准隐衷合规协定前不初始化第三方sdkAndroid降级根底库解决隐衷合规问题二、产品动静研发工具 平台服务产品公共云Release Note混合云Release NoteHTTPDNS- Android降级根底库解决隐衷合规问题/用户增长产品公共云Release Note混合云Release Note挪动推送-Android降级根底库,修复bug#对立错误码/欢送退出EMAS开发者钉钉交换群 群号：35248489

OpenClusterManagement 开源之夏 2022，奉献社区赢取 12000 奖金 欢送在校同学们参加 OpenClusterManagement 开源之夏，社区导师手把手让你的代码被社会宽泛复用，来赚取最高 12000 奖金，可举荐入职/实习你心仪公司，又拿钱又成长又有价值，你还等什么呢？报名马上截止，快来参加 OpenClusterManagement 开源之夏。 开源之夏是什么？开源之夏是由“开源软件供应链点亮打算”发动并长期反对的一项暑期开源流动，旨在激励在校学生积极参与开源软件的开发保护，促成优良开源软件社区的蓬勃发展，造就和挖掘更多优良的开发者。 流动联结国内外各大开源社区，针对重要开源软件的开发与保护提供我的项目工作，并面向寰球高校学生凋谢报名。 学生可在本流动中自主抉择感兴趣的我的项目工作进行申请，并在当选后取得该开源我的项目资深维护者（社区导师）亲自领导的机会，实现我的项目并奉献给社区后，参加学生还将取得开源之夏流动奖金和结项证书。 OpenClusterManagement&开源之夏 2022OpenClusterManagement 是红帽和阿里云联合推出的 CNCF 沙箱 Kubernetes 多集群联邦治理平台我的项目，用云原生形式解决分布式畛域外围问题，曾多次登陆 KubeCon 在云原生畛域造成影响力。对于 OpenClusterManagement 的总体介绍能够参考视频 <I ntroducing Open Cluster Management> [ 1] ： 能够申请的我的项目包含： <Introducing Open-Tracing into Kubernetes multi-cluster operators> [2] < Topology aware scheduling in cloud native multi-cluster/multi-cloud environments > [ 3]** 参加 OpenClusterManagement 开源之夏条件本流动面向年满 18 周岁在校学生。暑期行将毕业的学生，只有在申请时学生证处在有效期内，就能够提交申请。海内学生可提供录取通知书、学生卡、在读证实等文件用于证实学生身份。参加 OpenClusterManagement 开源之夏，你能取得什么？1.【你的代码被社会宽泛复用】 你的代码可能会运行在上万家企业外围业务逻辑中，帮忙企业解决问题。 2.【博得最高 12000 奖金】 奖金总额依据我的项目难度分为进阶 12000 元、根底 8000 元（注：奖金数额为税前人民币金额） ...

周末的早晨，张大胖照例要去 Hello World 咖啡馆，没想到在这里碰到了好几个老伙计。 感兴趣的小伙伴们，欢送退出 EventBridge 钉钉探讨群（群号：44552972）！ 点击此处，理解更多产品详情～