阿里云

一、背景AIoT行业发展势头日益迅猛，各大云厂商也在构建各自的AIoT生态，设施接入量也将作为各大厂商实力掂量的重要指标。AIoT横蛮成长过程中，碎片化的景象已日益凸显，因而去"碎片化"的呼声日益低落。如何建设一个行业认同度高、生态丰盛的对立标准化AIoT平台，也成为行业朝万物互联方向迈进中急需解决的问题，这也将成为掂量AIot能力的畛域重要指标。碎片化也进一步减轻了硬件商、集成搭档、场景服务商之间的沟通老本、设施接入的较高老本。目前设施在物联网平台整个生命周期能够包含：开发、生产、运维、售卖、集成、运行6个阶段。其中参加角色最多的就是售卖和集成2个阶段，售卖环节目前曾经有了"寰球散发核心"，而在设施的集成环节，物联网平台还未深度参加，目前不同角色次要通过线下的形式进行沟通； 二、AIoT认证设施核心定位AIoT认证设施核心，定位为AIoT生态系统的连接器： 1、 产业链：提供设施认证+设施可发现串联硬件搭档、集成搭档、场景服务商，设施认证核心提供设施认证能力，由物联网平台进行设施审核/认证，并提供相应透出渠道，升高三者之间的信息差；       "认证设施"是通过物联网平台认证/审核并颁布证书的，可能保障其品质；同时物联网平台提供了认证设施的搜寻和展现页面，方便使用硬件的商家可能在线理解分明硬件； 2、 开发链：即插即用串联设施开发态、设施运行态、设施生态池，升高设施集成老本；      "认证设施"审核通过后，会有1个无效的AliThingCodes，应用该AliThingCodes可能一键创立产品，同时物联网平台能保障该产品下的设施可能失常运行； 3、 阿里云AIot生态链：规范的模型积淀/推广减少高质量设施模型的曝光与推广；      每个审核通过的AliThingCodes其实对应着一套物模型/Topic/script，这套模型信息来自于线上可运行的设施，咱们将这套模型进行积淀/推广，减少设施市场占有率； 三、整体流程 四、线上体验1、AIoT 设施核心：（相干内容请关上下方链接理解详情）https://devices.iot.aliyun.co... 设施详情：（相干内容请关上下方链接理解详情）https://devices.iot.aliyun.co...基于认证设施一键创立产品：（相干内容请关上下方链接理解详情）https://iot.console.aliyun.co...硬件合作伙伴入驻：（相干内容请关上下方链接理解详情）https://certificate.iot.aliyu...入驻胜利：公布认证设施并审核通过后，对应设施将取得阿里云认证证书物联网平台产品介绍详情：https://www.aliyun.com/produc... 阿里云物联网平台客户交换群

一、前言近年来，物联网技术正以指数级的速度日渐成熟，并耳濡目染的扭转着人们的生存。依据国际数据公司IDC的预测预计，到2025年，将有416亿台联网的IoT设施或“物”，生成79.4 ZB的数据。同时IDC中国钻研数据显示，2020年寰球物联网收入达到6904.7亿美元，其中中国市场占比23.6%。IDC预测，到2025年寰球物联网市场将达到1.1万亿美元，年均复合增长11.4%，其中中国市场占比将晋升到25.9%，物联网市场规模寰球第一。 阿里云企业物联网平台基于阿里云的基础架构，提供设施接入、设施治理、监控运维、数据流转、数据管理、解决剖析等物联网构建能力，帮助企业在数字化转型时领有更残缺的生产资料。而对于第一步设施如何疾速上云并且实现寰球就近接入尤其重要，上面笔者将具体介绍阿里云物联网平台的设施散发服务是如何实现设施寰球疾速就近接入的。 二、 名词解释物联网平台：是阿里云的一个物联网治理平台，为设施提供安全可靠的连贯通信能力和治理能力，反对设施数据采集上云，规定引擎流转数据和云端数据下发设施端。 Alink通信协议：Alink协定是阿里云物联网平台的通信协议，该协定使设施与云端领有上下行指令承受与下发的能力，并且为设施端与云端提供上下行通信的信道。 设施三元组：每台设施领有productKey(产品标识)，pruductSecret(产品秘钥)，deviceName(设施名称标识)，deviceSecret(设施秘钥)，productKey和deviceName惟一标识一台设施，即一个产品下能够有多台设施。咱们通常称productKey、deviceName和deviceSecret为设施的三元组信息。 设施接入点：设施连云须要指定接入点，接入点蕴含实例id信息${instanceId}.mqtt.iothub.aliyuncs.com 实例：物联网平台的产品模式，用户以实例的模式购买，能够分为独享实例(独享的计算资源)和公共实例(和其它租户共享的计算资源) Bootstrap：设施疏导服务 IHV(Independent Hardware Vendor)：独立硬件开发商 ISV(Independent Software Vendors)：独立软件开发商 SI(Service Integrator)：服务集成商 三、 以后面临的问题物联网平台的设施散发服务要解决什么问题？先来看如下两个典型的业务场景： 场景一用户软硬拆散，IHV须要将设施交付给SI/ISV治理：IHV对设施进行建模和开发，并线下量产设施；ISV/SI在阿里云物联网平台批量生成设施三元组信息；ISV/SI线下向IHV购买设施，同时把本人实例下创立的三元组信息和设施接入接入点信息提供给IHV；IHV用上一步骤的三元组和实例信息烧录设施，并交付设施给ISV/SI；ISV/SI集成软件并部署应用设施。以后的场景存在的问题： 因为设施开发者和设施使用者(ISV/SI)在不同的实例下，而设施接入又要烧录指标的实例id接入点，导致设施开发者无奈提前备货提前将三元组和连接点信息进行烧录，须要用户下单后能力拿到设施真正要接入的实例信息；因为设施要交付给最终的使用者(ISV/SI)所在的实例进行治理，所以设施使用者须要在本人的实例内生成设施三元组并提供实例id信息给设施开发者烧录，最终设施数据能力在所在实例进行治理，操作繁琐；场景二厂商是软硬一体的开发者，能够本人开发设施并集成软件。厂商在本人的实例内生成的设施三元组信息，同时产线烧录三元组信息和实例接入点信息，而后将设施卖给C类用户，设施可能被用户带到不同的国家进行应用。以后的场景也存在一些问题： 厂商的三元组信息是在指定的实例下生成的，也就是这一批设施烧录的是一个固定的实例接入点，如果用户把设施带到不同的国家，那么设施只能接入烧录的指定接入点，无奈就近抉择机房，就会导致设施和云端通信提早减少；因为设施会被用户带到不同的国家应用，然而设施连贯的始终是一个实例的数据中心，所以也可能存在数据合规问题；四、如何解决这些问题形象一下咱们要解决的三个问题： 解决设施跨实例跨region跨租户的归属：因为物联网的简单场景，设施的开发者和使用者往往不是同一个用户，须要提供一种形式解决跨实例跨region的设施归属问题；设施能够提前烧录备货：无需在设施出厂时对不同region和不同实例的连贯信息进行硬编码，设施对立烧录寰球对立接入点信息即可(无region信息)，解决设施提前备货；设施能够寰球就近低延时的接入：因为设施可能被用户带到任意region，心愿设施能够连贯到就近region的阿里云物联网平台的用户实例下，防止数据合规和连贯指定烧录实例接入点造成的高延时问题。针对于以上三个问题，阿里云物联网平台提出了设施散发的概念：物联网平台通过设施散发实现设施跨地区、跨实例或跨账号的散发。散发后，云端下发新的连贯地址给设施，设施本地固化收到的信息之后，间接连贯新的地址，免去二次烧录设施信息。设施散发次要解决的就是两个问题：设施的寰球接入，设施的归属关系。 先来看一下设施散发服务的整体架构：物联网平台在寰球8个region部有核心机房，设施散发服务整体上是分为两个阶段的： 配置阶段：用户通过凋谢接口或者控制台对要散发的设施进行信息配置；接入阶段：设施通过Bootstrap疏导服务上云，触发配置，实现接入；上面将具体看一下上述提出的三个问题是如何解决的：1、设施跨实例跨region跨租户的归属问题而设施散发服务的第一个工作就是买通了阿里云外部的所有网络环境，对用户只裸露实例间的操作屏蔽底层简单的网络和隔离策略。对于跨账号的操作，散发服务采纳短信鉴权，并买通了国内站和国内站间账号的操作，用户只须要关怀要散发到哪个账号下的哪个实例即可。网络买通后就是如何在这个链路上实现数据高牢靠的传输，因为跨region和跨库的数据拜访可能会遭逢网络抖动或中间件拜访超时等异样流；针对这些问题，零碎除了有异样主动重试策略外还在业务上做了跨库的事务回滚，最大水平上保障业务数据的一致性。 因为设施数据的散发操作都是采纳长工作进行解决，所以为了避免服务器宕机或者重启导致的工作中断，零碎内置了故障转移机制，来保障工作肯定会走到状态机终态，其外围思路就是采纳心跳包和单机定时检测(quartz)来实现服务器的故障转移。下图演示了server1接管申请并，如果呈现故障，是如何转移到server2当中的。 2、设施提前烧录备货问题因为上云须要指定实例的接入点，所以对于设施不确定交由给哪个企业实例用户连贯哪个企业实例的场景就没有方法提前烧录接入点，提前备货。 所以对于设施端通过烧录的global域名能够去核心环境申请散发服务，设施通过申请散发核心的bootstrap服务，该服务会返回设施疏导信息，蕴含设施真正要接入的物联网平台实例的接入点信息，设施拿到指标接入点通过mqtt直连即可连贯到指标用户的实例即可。 思考设施还可能产生重配的状况，即设施曾经连贯在指标实例，然而用户在控制台重新配置了设施的指标实例接入点，这时候如果设施曾经连云处于在线状态，服务端会推送一条mqtt音讯给设施，通知设施的接入信息发生变化请从新连贯。如果设施不在线用户重配后，设施建连依然走上面的流程仍旧能够连贯到指标实例。        3、设施寰球就近低延时的接入问题对于散发设施的接入策略服务端提供两种：指定地区和就近接入。这两种有各自的应用场景，对于指定地区策略如果用户明确设施要散发到哪个实例下应用能够抉择指定地区策略，设施能够抉择配置到指定实例进行接入，典型的场景是设施开发商在本人的实例下量产设施，而后将设施散发到渠道商的实例下，设施的指标实例是固定的，而且心愿只连贯在固定的实例下。 对于就近接入策略，例如设施厂商是软硬一体的，在指定的实例开发并量产了设施，然而设施售卖到C端用户手中会被用户带到寰球任意region应用，这时设施厂商能够在物联网平台反对的每一个region购买一个实例，并配置就近接入策略，这样设施在挪动到特定region申请bootstrap服务的时候，散发服务会依据设施的进口ip信息，动静的将设施身份散发到就近region用户的实例下进行连贯。 设施只须要烧录一个寰球域名iot-auth-global.aliyuncs.com，在解决了就近接入的同时，散发服务配置了ADNS智能域名解析。实现了寰球就近低延时接入指标实例。 五、 产品个性万级设施能够实现跨账号、跨实例、跨region在阿里云各物联网平台任意的散发；同时平台对散发的设施提供了多种数据高牢靠的保障策略；提供多种散发策略，满足不同业务场景的需要；设施bootstrap服务接入无额定鉴权，简化了设施接入流程；一次配置，设施就能够实现毫秒级的寰球就近接入；六、接入文档1、性能应用文档：https://help.aliyun.com/docum...2、云端开发指南：https://help.aliyun.com/docum...3、设施端开发指南https://help.aliyun.com/docum... 物联网平台产品介绍详情：https://www.aliyun.com/produc... 阿里云物联网平台客户交换群

一、前言Pulsar是一个多租户，高性能的服务间音讯解决方案。最后由Yahoo开发，当初由Apache Software Foundation负责。 Pulsar是音讯队列畛域的一匹黑马，其最大长处在于它提供了比Apache Kafka更简单明了、更强壮的一系列操作性能，反对地区复制和多租户。此外，相比传统的Kafka、RocketMQ等，Pulsar更加适宜IoT的场景。 二、架构设计2.1 整体架构Apache Pulsar 和其余音讯零碎最基本的不同是采纳分层架构。Apache Pulsar 集群由两层组成：无状态服务层：由一组接管和传递音讯的Broker组成有状态长久层：由一组Apache BookKeeper存储节点组成，可长久化地存储音讯。Pulsar客户端不间接与存储层Apache BookKeeper交互。客户端也没有间接的 BookKeeper 拜访权限。这种隔离，为 Pulsar 实现平安的多租户对立身份验证模型提供了根底。 2.2 BrokerBroker集群在Apache Pulsar中造成无状态服务层。Broker不在本地存储任何音讯数据。Pulsar主题的音讯，都被存储在分布式日志存储系统（Apache BookKeeper）中。 每个主题分区（Topic Partition）由Pulsar调配给某个Broker，该Broker称为该主题分区的所有者。Pulsar 生产者和消费者连贯到主题分区的所有者 Broker，以向所有者代理发送音讯并生产音讯。 如果一个Broker产生故障，Pulsar会主动将其领有的主题分区挪动到群集中残余的某一个可用 Broker 中。重点阐明：因为Broker是无状态的，因而当产生Topic 的迁徙时，Pulsar 只是将所有权从一个 Broker 转移到另一个 Broker，并不会有任何数据复制产生，故障转移十分轻量。 下图显示了一个领有 4 个 Broker 的 Pulsar 集群，其中 4 个主题分区散布在 4 个 Broker 中。每个 Broker 领有并为一个主题分区提供音讯服务。 2.3 BookeeperApache BookKeeper 是 Apache Pulsar 的长久化存储层。Apache Pulsar 中的每个主题分区实质上都是存储在 Apache BookKeeper 中的分布式日志。 每个分布式日志又被分为Segment分段。每个Segment分段作为Apache BookKeeper中的一个 Ledger，均匀分布并存储在BookKeeper群集中的多个Bookie中。 通过 Segment 分段的形式，主题分区中的音讯能够平均和均衡地散布在群集中的所有 Bookie 中。这意味着主题分区的大小不仅受一个节点容量的限度；相同，它能够扩大到整个 BookKeeper 集群的总容量。 ...

一、背景Link SDK（原名为Link Kit SDK）是阿里云物联网平台提供的设施端软件开发工具包，可应用尽量少的硬件资源，简化开发过程，实现设施疾速接入阿里云物联网平台。目前LinkSDK曾经笼罩的开发语言c、node.js、java、python、以及android、ios操作系统。（Link SDK相干内容请点击文末浏览原文理解详情） C LinkSDK 4.x于2020年5月初版上线，作为C LinkSDK的主版本与物联网平台性能同步更新，目前曾经迭代近两年。在4.x推出之前，C LinkSDK曾经迭代了三个大版本1.x、2.x、3.x，这三版本有肯定的继承关系，可实现局部接口兼容。4.x则是齐全的新版本，在接口上和之前的版本不再兼容。       为什么要推出新版本4.x呢？从性能及稳定性角度上看，3.x都能够满足应用需要，推出4.x最次要的起因是改善资源开销及易用性问题。IoT设施不同于互联网设施，碎片化问题很重大，为了LinkSDK利用范围广，在3.x提供了多种场景的接入办法及相干性能，从而导致接入硬件资源耗费大，进步了设施门槛；为了给3.x瘦身，咱们提供了配置项、代码抽取工具帮忙用户裁剪；最初后果就是，3.x倒退胜利能丰盛、配置项多的一个大型IoT工具库，易用性反而降落了，进步了开发者应用门槛。因而，咱们决定研发LinkSDK 4.x，以低消耗、易移植、易使用作为设计指标，帮忙设施疾速轻便的上云。 二、 挑战问题是客观存在的，IoT设施的碎片化，局部设施资源无限，利用场景差别大。LinkSDK 4.x设计，既要满足多场景疾速适配，又要用尽量少的硬件资源，还要满足能力定制化的需要。 IoT设施碎片化IoT设施品类多，跨度大，有小型的智能开关、中型的音响、大型的机器人；软件操作系统有RTOS、linux、windows，有些低端设施都没有操作系统；硬件平台架构和主频跨度都很大；跨平台运行能力是一大挑战。IoT设施资源受限资源是设施的老本，有些IoT设施为节约老本，只有几十K的rom，顾此失彼。在IoT畛域，大部分设施上应用的是mqtt协定，风行mqtt开源协定栈资源开销根本已大于100K。如何让资源受限设施上云，也是一大挑战。实现接口易用很多时候，开发成本也是设施老本的一个大头，做到接口易用也能够升高开发成本。但对于SDK来说，丰盛的利用场景，要求SDK肯定具备定制能力，可配置能力，如何解决易用且反对定制，也是一大挑战。三、 设计及实现3.1 碎片化问题解决性能聚焦LinkSDK通过多年的倒退，咱们也明确了少即是多的情理，保留次要的性能能力带给大部分用户好的接入体验。所以4.x在功能设计上聚焦设施与物联网平台交互性能，云端一体的能力建设。不再解决与具体环境或具体业务相干内容，如本地通信，本地存储，业务利用。缩小依赖4.x设计只保留必要的零碎及网络接口，升高设施应用门槛。 互斥锁(可选)：保障接口的线程平安，无OS或只会单线程调用LinkSDK能够不实现。 时钟：用于计算心跳发送距离及重发逻辑 内存：用于动态内存申请，能够节俭内存(RAM)应用 随机数：用于建连，减少随机数进步传输平安 TCP：用于连云时的网络操作3.2 资源受限问题解决能力原子化，反对裁剪LinkSDK除外围模块，其它性能封装成独立的组件，组件反对裁剪。在下载是基于可视化裁剪工具，零门槛实现裁剪。裁剪后，若只保留外围模块，可降至30K左右的rom耗费；自建简节尺寸小的根底库自研实现mqtt协定栈、http协定栈、json解析库，实现资源开销方面业内当先。内存遵循应用时申请准则SDK实现根本不应用动态变量及全局变量，保障模块独立同时防止不要的内存耗费；提供mcu+模组上云计划对于一些极其资源受限的设施，提供协定栈跑在模组上的计划，进一步升高连云对mcu资源需要。3.3 易用性问题解决3.3.1 下载阶段(定制化)：提供可视化SDK定制下载，用户下载LinkSDK时，能够通过简介疾速理解组件性能，仅抉择本人须要的性能，防止不必要的资源耗费； 3.3.2 移植阶段：缩小移植接口：移植形象目前接口已缩减至15个(4个可选实现)，移植难度大幅升高； 罕用零碎免移植：提供posix、linux、freertos等罕用环境移植实现，用户可间接应用，免移植； 免mbedtls移植：已基于移植形象接口实现mbedtls开源库适配，用户不用关怀mbedtls移植； 提供AT驱动框架：对于MCU+通信模组接入形式，基于AT驱动框架能够疾速开发模组驱动，用户只须要定义好AT指令格局，AT驱动框架会实现指令协定栈实现，以及实现模组驱动与LinkSDK移植形象接口的适配工作。 提供移植验证工具：用户移植后，应用移植验证工具验证是否移植胜利。 3.3.3 开发阶段：晋升api易用性： 清晰的软件框架，只有外围模块和高级组件两层架构，易了解。保持一致的观感和应用体验, 包含文件布局, API格调, 编码格调等欠缺的配套阐明，官网文档介绍应用流程，API具体应用（https://gaic.alicdn.com/ztms/...）提供可视化低代码开发工具：用户应用物模型进行业务开发时，LinkSDK只提供了根底的属性上报、属性设置、事件上报、服务调用接口。然而具体是什么样的属性、事件、服务解决，须要用户本人解决。可视化低代码开发工具，能够依据不同的产品物模型，主动生成对应物模型的具体代码。 工具入口：控制台-->抉择产品-->性能定义-->生成设施端代码。 3.4 LinkSDK 4.x软件主体架构 外围组件:最重要的连云局部, 其内容是固定和精简的(因而不存在如何增删), 其接口也是充沛丰盛和细粒度的下层组件:所有外围之外的能力, 都原子化拆分, 造成互相独立, 互相拆散的平级下层组件内部工具: 第三方软件库, 不是SDK的内容, 目前仅有mbedtls四、应用示例连贯物联网平台须要具备公网连贯的能力，依据网络连接的类型，大抵能够分为四种接入形式。 直连设施：直连设施本人具备公网IP，间接集成LinkSDK即可实现接入。 子设施与网关设施：子设施无公网IP，通过局域网与网关通信，由网关代理上云，网关需集成集成LinkSDK。 MCU+通用模组设施：对于无公网IP的MCU，通过模组的TCP/TLS能力上云。 MCU+云模组设施：云模组已集成LinkSDK，MCU可通过简略的AT指令实现接入。 上面以ubuntu作为虚构直连设施为例，介绍LinkSDK的应用过程。 定制化下载SDK后，解压，进入SDK根目录抉择一个demo，此处以mqtt的根底性能demo为例，演示demo应用。关上demo源码(./demos/mqtt_basic_demo.c)，批改设施的认证信息及接入点信息，保留。编译make，完结后查看输入文件output/运行demo，./output/mqtt-basic-demo，demo会主动实现建连及音讯收发，流程如下。摸索体验更多功能，能够先查看性能列表，再从demos都能找到对应的demo体验。五、性能列表5.1 外围模块 5.2 高级组件 六、结束语LinkSDK 4.x设计准则遵循低消耗、易移植、易使用，反对细粒度的性能裁剪，次要满足中小型的嵌入式设施的应用需要。对于一些中大型的设施，如IPC、机器人、网关等，它们对资源不那么敏感，大多也应用linux零碎，不须要移植。往往对性能丰富性、易用性、性能有要求。对此，咱们也在研发针对中大型设施应用的LinkSDK 5.x，进一步提高接口的易用性，性能的丰富性，以及更高的性能，或将于下半年公布，纵情期待。 物联网平台产品介绍详情：https://www.aliyun.com/produc... 阿里云物联网平台客户交换群

在采纳Istio 服务网格技术的很多客户案例中, 熔断是其中一个十分广泛的流量治理场景。在启用网格技术之前, 在一些应用Resilience4j 的Java 服务中客户曾经应用了熔断性能, 但相比之下, Istio可能在网络级别反对启用熔断能力，无需集成到每个服务的利用程序代码中。 深刻了解熔断器在不同场景下的行为, 是将其利用到线上环境之前的要害前提。 介绍启用熔断性能，须要创立一个指标规定来为指标服务配置熔断。其中, connectionPool下定义了与熔断性能相干的参数, 相干配置参数为： tcp.maxConnections: 到指标主机的最大 HTTP1 /TCP 连接数。默认值为2³²-1。http.http1MaxPendingRequests：期待就绪的连接池连贯时，最多能够排队的申请数量。默认值为1024。http.http2MaxRequests：对后端服务的最大沉闷申请数。默认值为1024。这些参数在一个简略的场景中, 如一个客户端和一个指标服务实例（在 Kubernetes 环境中，一个实例相当于一个 pod）的状况下是清晰的。然而, 在生产环境中，比拟可能呈现的场景是： 一个客户端实例和多个指标服务实例多个客户端实例和单个指标服务实例客户端和指标服务的多个实例咱们创立了两个 python 脚本——一个用于示意指标服务，另一个用于调用服务的客户端。服务器脚本是一个简略的 Flask 应用程序，它公开一个休眠 5 秒的API服务端点，而后返回一个“hello world!”字符串。示例代码如下所示： #! /usr/bin/env python3from flask import Flaskimport timeapp = Flask(__name__)@app.route('/hello')def get(): time.sleep(5) return 'hello world!'if __name__ == '__main__': app.run(debug=True, host='0.0.0.0', port='9080', threaded = True)客户端脚本以 10 个为一组调用服务器端点，即 10 个并行申请，而后在发送下一批 10 个申请之前休眠一段时间。它在有限循环中执行此操作。为了确保当咱们运行客户端的多个pod 时，它们都同时发送批处理，咱们应用零碎工夫（每分钟的第 0、20 和40秒）发送批处理。 #! /usr/bin/env python3import requestsimport timeimport sysfrom datetime import datetimeimport _threaddef timedisplay(t): return t.strftime("%H:%M:%S")def get(url): try: stime = datetime.now() start = time.time() response = requests.get(url) etime = datetime.now() end = time.time() elapsed = end-start sys.stderr.write("Status: " + str(response.status_code) + ", Start: " + timedisplay(stime) + ", End: " + timedisplay(etime) + ", Elapsed Time: " + str(elapsed)+"\n") sys.stdout.flush() except Exception as myexception: sys.stderr.write("Exception: " + str(myexception)+"\n") sys.stdout.flush()time.sleep(30)while True: sc = int(datetime.now().strftime('%S')) time_range = [0, 20, 40] if sc not in time_range: time.sleep(1) continue sys.stderr.write("\n----------Info----------\n") sys.stdout.flush() # Send 10 requests in parallel for i in range(10): _thread.start_new_thread(get, ("http://circuit-breaker-sample-server:9080/hello", )) time.sleep(2)部署示例利用应用如下YAML部署示例利用： ...

一、背景阿里云IoT物联网平台2020年初上线企业实例，企业实例在性能、计费、稳定性方面相比原有公共实例有不小劣势。但如何从公共实例迁徙到企业实例，并不是一个简略的事件。实例的业务场景中波及用户服务、阿里云IoT物联网平台服务、设施等，业务链路长、场景简单。（企业实例迁徙相干内容请点击文末浏览原文理解详情） 二、业务介绍&挑战如上图1为一个典型的IoT业务场景。 共享设施联网接入阿里云IoT物联网平台，而后上报数据。用户利用通过阿里云IoT物联网平台的音讯通信，接管设施上报的数据、状态等。消费者，通过用户提供的APP扫码认证受权后，能够查看共享设施状态，而后管制共享设施提供服务。APP连贯用户利用，鉴权后开始计费。用户利用调用阿里云IoT物联网平台提供的设施管制服务，管制设施开始工作。设施运行过程中，上报设施状态。服务实现后上报状态，通过数据流同步给用户利用，用户推送PUSH给APP，揭示消费者，服务完结揭示计费等信息。业务场景中波及用户服务、阿里云IoT物联网平台服务、设施，业务链路长、场景简单，给实例迁徙工具设计带来了很大的挑战。设施无奈批改，须要升高用户革新老本。IoT设施可能部署在公开、装置在商场中或者散落在城市不同角落（如公共自行车），同时设施数量会很多，手动降级设施简直不可能。同时OTA波及用户设施二次革新开发， 设施型号碎片化、SDK版本碎片化存量设施革新老本高， OTA降级周期会较长。波及性能和业务方多，影响面广对于稳定性要求高。IoT物联网平台波及控制台性能如产品治理、设施治理、拓扑治理、分组治理、标签、检索等泛滥性能。业务数据类型多且异构，数据须要依照业务维度迁徙，无奈采纳工具对立进行。阿里云IoT物联网平台波及数据如产品、设施、脚本、拓扑等多张表，同时数据存储在RDS、DRDS、OTS、TSDB云产品中。业务模型上依照产品维度迁徙产品、设施波及的数据，不能采纳工具如DTS对立进行。业务链路长设施流量和用户管制流量路由需统一，业务上须要无损，用户革新计划老本高。曾经迁徙到企业实例的设施，通过长连贯连贯到企业实例中，用户可能不晓得管制设施时会管制失败。 三、实例迁徙设计企业实例迁徙面临设施无奈批改、波及性能和业务方多、业务数据类型多且异构、业务链路长设施流量和用户管制流量路由需统一四个方面的挑战，对咱们的产品和技术设计方案从用户应用门槛、稳定性提出了肯定的要求。用户迁徙过程可灰度、可监控、可回滚。用户设施体量大从几千到几十万都有，且设施都是通过长连贯连贯到平台，迁徙的工夫必然较长。同时用户设施可能波及到民生如公共交通畛域，降级须要凌晨按区域先灰度而后降级。降级的过程中用户须要可能感知和监控降级是否胜利，作为服务提供者咱们本人也须要能监控服务胜利信息防止故障的产生。计划实现中采纳状态机联合异步工作形式解决，做到用户侧状态可控，数据迁徙执行稳固。设施不做革新，用户服务端少革新。基于开发成本考量，方案设计中须要兼容设施能主动路由到企业实例，防止设施革新。用户服务端少革新，保障和设施路由一致性防止业务有损。 四、实例迁徙可控用户迁徙企业实例，波及用户服务端开发不是简略的开发一下切下流量，须要业务评估、革新、公布、切流同时须要和咱们提供的实例迁徙无缝的联合。咱们从迁徙过程可控、零碎设计稳固、监控等方面保障迁徙过程可灰度、可监控、可回滚。 4.1 实例如何迁徙整个迁徙过程次要分为4局部：业务评估、零碎革新、实例降级、接口切流。 业务评估。实例降级前须要评估业务影响，具体参考文档实例迁徙。零碎革新。针对评估的点，对业务零碎进行兼容革新。如实例降级后，凋谢接口须要传企业实例id。实例迁徙。通过IoT实例迁徙性能，看待迁徙产品进行迁徙。灰度迁徙。灰度迁徙局部设施，察看影响面。灰度迁徙后，如零碎应用规定引擎流转。须要零碎应用新的规定引擎配置，并重启利用。全量迁徙。灰度后无异样，开始全量迁徙。回滚。全量迁徙过程中如果业务有问题能够进行回滚。接口切流。如设施管制接口，针对已迁徙到企业实例设施传企业实例id。4.2 实例迁徙零碎设计状态治理        如图3所示，实例迁徙过程分为不同的状态，很适宜采纳状态机形式治理业务流程防止业务代码耦合。同时采纳分布式锁，保障工作状态惟一。 数据迁徙因为实例迁徙数据从业务模型上是依照产品维度，迁徙产品下所有的设施。须要先查问出产品和设施波及的数据，而后迁徙到对应的企业实例存储（存储目前逻辑隔离，物理隔离单元化我的项目曾经进行中）。依据业务诉求和数据个性，采纳不同的策略。数据复制一份如产品、规定引擎相干数据。产品数据设施运行过程中会应用到，产品下局部设施已迁徙到企业实例，局部设施未迁徙到企业实例，须要保障业务兼容须要复制一份雷同的数据。数据先减少后删除设施数据全局惟一，须要保障数据唯一性，因而先减少后删除 异步工作须要迁徙的数据类型多、迁徙的设施数量多，导致迁徙的工夫比拟久。须要保障异常情况下数据迁徙的稳固牢靠，防止ECS宕机、利用公布、依赖服务异样时迁徙的稳定性。 采纳异步工作形式，形象实例迁徙过程。灰度迁徙、全量迁徙、迁徙回滚采纳工作形式执行，并配合状态机业务可中断从业务维度保障稳固。实例迁徙工作执行过程中，针对工作心跳保活、异样检测、异样重试、限流排队等策略保障业务执行的可靠性。业务执行过程，业务谬误（约定错误码）接口级别重试，零碎异样工作维度重试。存储&查问实例迁徙过程中，设施数量多且状态更新查问频繁，迁徙工作和迁徙设施状态更新须要思考对于的压力，同时思考性能对于实时性和容错的需要。因为实例迁徙工作和设施状态重要水平，在存储上进行拆分，实例迁徙工作存RDS，工作设施设施详情存OTS。数据的查问依赖高效的检索服务，通过配置形式能够反对RDS、OTS数据应用SQL的形式查问形式。 五、监控设计监控面向受众包含阿里云IoT物联网平台用户和IoT外部开发者，其须要看到的监控指标和展现形式各不相同。从用户和性能开发者的诉求触发，针对不同场景进行埋点（日志、存储），采纳现有的监控产品构建咱们的监控告警体系。 数据收集数据迁徙零碎，能够将工作执行的状态长久化存储到RDS中。设施的迁徙状态因为数据量比拟到能够存储到OTS或者Hbase中。迁徙过程中的一些操作，能够打印日志，收集到云产品SLS中。业务零碎如零碎A和零碎B，针对设施在线量、音讯量进行统计打印到日志中，通过云产品SLS收集。数据聚合针对日志SLS、RDS、OTS不同维度的数据，按需进行不同的维度聚合剖析。数据展现针对阿里云IoT物联网平台用户，聚合后的数据采纳云监控的视图。提供不同实例要害链路业务指标比照，如设施在线数、音讯数、规定引擎流转数。针对IoT外部开发者sunfire提供要害接口维度监控如接口成功率，零碎异样。Grafana聚合统计分析提供根底的大盘展现外，还提供不同工作状态的告警，防止如工作积压等异样。六、设施少革新实例迁徙过程，采纳设施不革新，服务端少革新的形式策略，防止阿里云IoT物联网平台用户革新老本过高。用户设施 设施连贯到物联网平台时，对立接入层能查问到设施信息，判断企业实例信息，主动路由到企业实例。设施建连认证过程中依赖的一些数据，如拓扑关系，云端也做了响应的兼容，防止网关子设施的场景实例迁徙过程中建连认证失败。用户服务端因为迁徙企业实例后凋谢API必须传实例id,   用户零碎调用凋谢API管制设施须要和设施迁徙放弃同步。用户零碎通过规定引擎，订阅实例降级状态变更音讯。当实例迁徙过程中，设施迁徙实现后的音讯中会流转设施胜利的音讯。用户零碎批改曾经存储的设施实例信息，调用接口时传新的实例ID。同时须要订阅灰度后迁徙到企业企业实例的服务端订阅以及规定订阅等，避免音讯失落。物联网平台产品介绍详情：https://www.aliyun.com/produc... 阿里云物联网平台客户交换群

中国边疆 其余国家和地区 企业实例接入点查看 物联网平台产品介绍详情：https://www.aliyun.com/produc... 阿里云物联网平台客户交换群

设施掉线怎么办？数据分析让寒冷的设施“闭口谈话”网站链接：https://developer.aliyun.com/... https://www.aliyun.com/page-s... 物联网平台产品介绍详情：https://www.aliyun.com/produc... 阿里云物联网平台客户交换群

5分钟入门物联网大数据计算网站链接：https://developer.aliyun.com/... https://www.aliyun.com/page-s... 物联网平台产品介绍详情：https://www.aliyun.com/produc... 阿里云物联网平台客户交换群

手把手教你如何疾速检测设施异样网站链接：https://developer.aliyun.com/... https://www.aliyun.com/page-s... 物联网平台产品介绍详情：https://www.aliyun.com/produc... 阿里云物联网平台客户交换群

一、内容摘要新增Native指纹解锁和手势解锁等组件反对构建H5利用流水线反对公布H5利用iOS反对大写字母包名重签名利用开放平台1.0公布EMAS Serverless 优化函数拜访数据库等服务网络提早挪动推送公布Android 3.8.2EMAS Surperapp解决方案寰球公布上线魔笔独立站、魔笔物料市场等 二、产品动静 三、技术交换欢送退出开发者技术交换钉钉群：EMAS技术交换群：35248489 Mobi技术支持群：32946835

作者： 如葑 Metrics 指标在可观测体系的利用可观测体系的概念由来已有，随着散布式微服务迅猛发展，对可观测体系的依赖也越来越深，可观测体系通常包含 Metrics、Tracing、Logging 三类数据，再外加报警机制，即可形成残缺的监控报警机制，业界对可观测也有系统性阐明，如下： 回到咱们日常问题排查，根本门路大抵分为 Detect（检测）、Troubleshoot（问题初步定位）、Pinpoint（精确定位）三个阶段，其别离对应可观测的三局部内容：Metrics、Traces、Logs，置信读到这里您曾经了解 Metrics 指标的重要性了，它是咱们发现问题的首要伎俩。 Metrics 指标的分类咱们心愿应用指标来检测问题，首先咱们要定义各种指标，指标的定义多种多样，不同的业务利用也都会有其合乎本身要求的一些指标，但咱们依然能够对指标做一些粗粒度的分类，如下 其中最受关注的无疑是外围业务指标，其重要性毋庸置疑，例如所有业务都会具备的三大外围指标：QPS、成功率、RT，其次是根底指标与其余指标。所以任何利用肯定要保障外围业务指标精确与实时。同时，搭配根底指标能力对问题发现实现事倍功半的成果，尤其是程序运行期的一些问题。 Metrics 指标在网关场景的利用聚焦于网关的可观测场景，网关的职责是高效的将合乎某组个性的流量转发给指标服务，外围次要在于对网络流量的解决，三大外围指标：QPS、成功率、RT 仍然是反映服务外围运行状况的外围指标。 值得阐明的是，在网关场景中三大指标并不能齐全实在反映网关理论运行状况，三大指标异样抖动经常跟后端服务抖动相干。因而，理论观测中咱们将网关分为 Downstream 指标（观测 Client 侧的指标汇合）、Upstream 指标（观测上游 Service 服务维度的指标汇合)、路由指标（观测路由转发规定维度的指标汇合）。同时，网关作为流量入口还有一些功能性指标，如解压缩 GZip、认证鉴权 Authz 等指标。 理论利用中还会有其余网络指标如接手、发送的数据量等，限于篇幅就不进行赘述。 MSE 云原生网关在可观测体系的实际在虚拟化期间的微服务架构下，业务通常采纳流量网关 + 微服务网关两层架构，流量网关负责南北向流量调度和平安防护，微服务网关负责东西向流量调度和服务治理。而在容器和 K8s 主导的云原生时代，Ingress 成为 K8s 生态的网关规范，赋予了网关新使命，使流量网关 + 微服务网关合二为一成为可能。MSE 云原生网关正是在这种背景下诞生，其基于阿里开源 Higress [ 1] 构建，在能力不打折的状况下将两层网关二合一，不仅能够节俭 50% 的资源部署老本，还极大升高运维及应用老本。 MSE 云原生网关 [ 2] 与阿里云利用实时监控服务 ARMS、Prometheus 监控深度集成，在网关场景下提供 Metrics、Tracing、Logging 残缺可观测体系，为用户带来一站式可观测体系能力，升高可观测的应用门槛。 接下来咱们简要介绍下 Metrics 指标在 MSE 云原生网关的理论利用。 MSE 云原生网关 Metrics 指标大盘介绍根底指标对于 CPU、Memory 等根底指标建设了独立指标大盘“资源监控”，不便一键查看网关以后的资源应用状况。 ...

作者： 智真 在 Gartner 公布的 《2023 年十大策略技术趋势》 [ 1] 报告中,「利用可观测性」再次成为热门趋势。用户须要建设可观测体系来兼顾、整合企业数字化所产生的指标数据，并以此为根底进行反馈并制订决策，这对于进步组织决策有效性和及时性，将是最强有力的撑持。 新需要带来新反动，Prometheus 产品应运而生，引领新一轮可观测技术反动。得益于良好的产品设计，Prometheus 部署与轻度应用体验十分晦涩：敲两三个命令就能运行起来，配置几行 yaml 就能收集数据，编辑一个规定就能触发告警，再配合上 Grafana，写一句 PromQL 就能画出趋势图表。所有简略而美妙，好像SRE光明的将来正向咱们招手，这所有来的太忽然，它真的如此轻易么？ 当然不是。 Prometheus 用良好的用户接口覆盖了外部简单实现。深刻其中，咱们会看到时序数据存储、大规模数据采集、工夫线高基数、数据搅动、长周期查问、历史数据归档等等。像潜藏在平静湖面下磨牙吮血的鳄鱼，静待不小心掉进坑中的 SRE 们。 主观的讲，这些问题早已存在，并不是 Prometheus 带来的。云原生的到来让这些问题变得更显著且难以回避。想解决这些问题，须要投入大量人力、物力和精力。作为国内当先的云服务提供商，阿里云提供了优良的可观测全套解决方案，阿里云 Prometheus 服务正是其中重要一环，相比于开源版本 Prometheus，阿里云的 Prometheus 服务无论是易用性、扩展性、性能均有大幅度晋升。 明天，咱们将联合企业日常运维过程中常见疑难场景，将两者存储能力进行比照。 测前概念解读在开始前，咱们先论述测试过程中波及的问题与概念。 1.工夫线（Time Series） 工夫线的概念在Prometheus中十分重要，它示意一组不雷同的label/value 的汇合。比方temperature{city="BJ",country="CN"} 和 temperature{city="SH",country="CN"}就是两条不同的工夫线。 因为其中的city这个label对应的值不同；temperature{city="BJ",country="CN"}和 humidity{city="BJ",country="CN"} 也是两条不雷同的工夫线，因为在Prometheus中，指标名称也对应一个非凡的label __name__。工夫线中的label会被索引以减速查问，所以工夫线越多存储压力越大。 2.工夫线高基数（High Cardinality） 如果指标设计不合理，label 取值范畴宽泛，如 URL，订单号，哈希值等，会造成写入的工夫线数量难以预估，会产生爆炸式增长，为采集、存储带来微小挑战。对于这种状况，咱们称之为工夫线高基数或者工夫线爆炸。工夫线基数过高带来的影响是全方位的，如采集压力大，网络和磁盘 IO 压力大，存储成本上升，查问响应缓慢等。 高基数场景常见应答思路有两种：依附时序存储自身的能力，或更优良的架构来硬抗压力；或应用预聚合/预计算等伎俩来被动升高基数。阿里云 Prometheus 在两方面都进行了很多优化和加强，但开源版本中并没有提供残缺预聚合/预计算性能，所以此次测试中不会波及到预聚合/预计算。 3.高搅动率（High Churn Rate） 高搅动率是高基数的非凡场景之一，如果工夫线的“寿命”很短，常常被汰换，这种场景咱们称之为高搅动率。比方 k8s 场景下，deployment 每次创立新的 pod 时，都会产生新 pod name，即旧 pod 相干工夫线被淘汰，新 pod 相干工夫线被产生进去。如果经常性产生重启（或相似场景），那么可能从某个工夫点来看，工夫线并不多，但在较长时间范畴来看，工夫线总量可能就很宏大。换句话说，在高搅动率场景下，“沉闷”的工夫线不肯定很多，但累积工夫线总数十分宏大，所以对时间跨度较大的查问影响尤其重大。 阿里云 Prometheus 服务与开源版本 Prometheus 能力比照↓ ...

1.应用IoT Studio疾速构建可视化利用在物联网业务场景中设施数据可视化利用是最广泛的需要，阿里云物联网利用开发（IoT Studio）提供了Web可视化开发、挪动可视化开发、业务逻辑开发与物联网数据分析等一系列便捷的物联网开发工具，解决物联网开发畛域开发链路长、定制化水平高、投入产出比低、技术栈简单、协同老本高、计划移植艰难等问题。 本次物联网场景最佳实际咱们用六合一传感器（温度、湿度、二氧化碳、PM2.5、PM10、甲醛）实现家庭环境数据实时采集，通过家中Wi-Fi上报到阿里云IoT物联网平台，借助IoT Studio低代码工具搭建可视化大屏，实时监控家中环境指标变动。 残缺链路参考如下： 2.操作步骤2.1 物联网平台开发1.返回物联网平台控制台。 阐明：如果您未开明物联网平台，请您依据页面提醒，开明物联网平台。2.在实例概览页面，抉择您的实例。阐明：本试验以企业实例进行试验操作。3.在新建产品页签，产品名称输出六合一环境传感器，所属品类抉择自定义品类，其余配置放弃默认即可，单击确认。4.在性能定义页签，单击性能定义。在增加自定义性能对话框中，性能名称输出温度，标识符输出temperature，设置数据类型和取值范畴等，单击确认。5.同理，咱们顺次增加湿度、二氧化碳、PM2.5、PM10、甲醛浓度，如下图。最初，单击公布上线。6.在增加设施对话框中，产品抉择六合一环境传感器，DeviceName输出sensor007，单击确认。 2.2 IoT Studio我的项目搭建当咱们实现物联网平台开发后，即可进入到物联网利用开发服务（IoT Studio）的工作台实现物联网利用的搭建。注：物联网利用开发服务（IoT Studio）企业版购买入口 https://common-buy.aliyun.com...1.返回IoT Studio工作台，抉择上一步创立设施的实例。2.在左侧导航栏中，单击项目管理，在新建空白我的项目对话框中，项目名称输出家庭环境监控，单击确认。3.进入我的项目开发控制台，在Web利用页签，单击新建。4.在新建Web利用对话框中，利用名称输出家庭环境实时监控大盘，单击确定。5.在左侧导航栏中，单击产品。6.在产品页面，单击关联物联网平台产品，选中六合一环境传感器，单击确定。关联后如下图。7.在设施页面，单击关联物联网平台设施，选中sensor007，单击确定。关联后如下图：至此，咱们实现了IoT Studio我的项目的资源筹备工作，接下来进入Web利用搭建环节。 2.3 Studio利用开发1.在家庭环境监控页面的Web利用页签，找到家庭环境实时监控大盘，单击右侧的编辑，接入利用搭建控制台。2.抉择左侧组件，而后在下拉框抉择工业组件，选中刻度表，拖拽到页面即可。3.同理，咱们增加须要的组件(室内温度-刻度表、室内湿度-单色仪表盘、PM2.5和PM10指数-多色仪表盘、二氧化碳浓度和甲醛浓度-数码管)，实现页面布局，如下图。4.页面布局好后，咱们须要关联六合一传感器设施sensor007。点击刻度表组件，在右侧找到配置数据源按钮。5.在数据源配置页面，咱们关联产品，选中设施sensor007，并抉择属性值温度。6.同理，咱们配置好其余组件的数据源后，即可点击右上角预览，查看成果页面7.IoT物联网家居环境监控大屏利用预览成果如下 2.4联机运行实现开发后，咱们回到物联网平台控制台，进行设施模仿联调。1.在物联网实例控制台，设施模拟器页面，咱们调试设施抉择为六合一环境传感器sensor007，单击启动设施模拟器。2.在上行指令调试的属性上报页签，输出模仿数据，单击发送指令，即可看到IoT Studio预览家居环境监控大屏页面上数据指标实时刷新。 3.相干产品阿里云物联网平台阿里云物联网平台为客户提供全托管的企业级实例服务，具备低成本、高牢靠、高性能、高平安的劣势，无需自建物联网基础设施即可接入各种支流协定的设施，治理运维亿级并发规模的设施，存储备份和解决剖析EB量级的设施数据。帮忙企业在物联网时代疾速实现设施数据和利用数据的交融，是每个企业实现设施智能化降级的绝佳抉择。物联网利用开发（IoT Studio）物联网利用开发（IoT Studio）是阿里云针对物联网场景提供的生产力工具，是阿里云物联网平台的一部分。可笼罩各个物联网行业外围利用场景，帮忙您高效经济地实现物联网数据分析、设施、服务及利用开发，减速物联网SaaS构建。物联网平台产品介绍详情：https://www.aliyun.com/produc... 阿里云物联网平台客户交换群

我的项目背景在碳达峰和碳中和的大背景下，寰球各个国家对可继续能源的器重，光伏发电以其散布广发、装置灵便、清洁可继续等长处，曾经成为次要的新能源生产方式之一。光伏电站一旦建设实现投入生产，就会进入长达20年以上的运维阶段，因而高效便捷的运维形式对于进步运维效率、升高运维过程中老本和危险就变得极为重要。 数字孪生技术通过各类传感器及联网设施，能够实时感知光伏电站的各项运行状态，通过教训规定及数据智能（大数据分析）形式及时检测出设施异样，第一工夫告诉运维人员进行故障解决以升高更大故障的产生，进步电站的发电效率，进而晋升电站整体收益。3D全场景模型利用往往能够晋升大屏监控的效率及汇报展现的成果，因而3D利用零碎经常会作为数字孪生零碎的重要组成，与实时的外围数据联动，以清晰易懂的模式展现在3D模型上，帮忙客户更好了解以后零碎的运行状态。 在开发光伏电站数字孪生零碎过程中，须要波及物联网、孪生模型构建、实时数据计算、数据智能、3D模型渲染及数据联动等多项简单的工作，阿里云物联网平台及其IoT孪生引擎增值服务提供了开发数字孪生零碎的多种外围性能，利用这些性能开发者可疾速构建出合乎本身业务个性的数字孪生零碎。本文重点介绍如何从零开始构建出光伏电站数字孪生零碎的具体步骤。 次要流程 筹备阶段梳理业务流程所有的数字化零碎都是为了特定业务目标而开发的，因而零碎全面地梳理整个业务零碎的运行流程、零碎形成及特定规定等是构建数字孪生零碎的外围根底。在此案例中，咱们整顿的业务架构图如下（发电阵列架构组成都一样，图上B区发电阵列省略了PV与组件）：整个光伏电站由四大局部组成：1.光伏发电零碎：由两个发电阵列（A和B）及气象仪组成，次要将光能转化成电能，是整个运维系统监控的外围。发电阵列是一个逻辑治理单元，是由上面多个逆变器组合而成，每个逆变器下又由多个PV组串形成，每个PV组串上面连贯多个光伏组件；气象仪提供实时气象测量数据，辅助判断以后发电效率是否失常。2.电器自用：光伏发电零碎发的电首先给该团体外部的各种工厂设施及商用电器应用，优先保障电力的自力更生，这外面次要关怀每天、每月及年度的电力使用量，取计量电表的数据。3.电力储能站：光伏发电零碎发的电如果自用有亏损，白天的时候能够将多余电力存入储能站，以便早晨无奈发电时由储能站向自用的电器设备供电。储能站电表和多个主控组成，每个主控下又由多个电池堆组成，为了简化零碎阐明，咱们只关注储能站的电表数据。4.余电并网：光伏发电零碎供应电器自用及储能站之后，如果还有亏损，则能够通过并网柜将多余的电量输送到电网中售卖以取得额定支出，为了简化零碎阐明，咱们只关注余电并网中电表数据，以理解某个时间段内售卖给电网的电量。 确定零碎指标在光伏电站数字孪生运维零碎建设实现之后，会通过实时采集各个设施上传的数据，并通过对历史数据比对、横向设施数据比对、数据实时计算、数据智能剖析等形式，能够向客户提供：1.零碎状态实时感知，这是最根底的能力。如组件级、组串级、逆变器级、阵列级、电站级的实时发电量，通过实时计算获取到当日、当月及年度累计发电量；团体内电量的应用状况、储能站的充放电及输出到并网零碎中的电量等。2.发电零碎异样及时感知及解决，以缩短故障解决工夫，进步整个零碎的发电效率。如逆变器过压过流异样、光伏组件的发电效率异样等，这里除了惯例的教训规定阈值办法，还能够通过深度学习算法对历史数据进行训练学习，生成光伏发电畛域的智能算法模型，通过对采集的数据进行智能剖析来判断异样状态，如I-V曲线算法。3.月度发电量预测，便于依据预测的发电量对用电进行正当布局。这个能够通过天气预报数据、历史发电数据、以后发电零碎的状态等多维度数据，应用智能算法进行预测。 为了简化阐明，本文只针对零碎状态实时感知异样感知进行演示，以此作为整个零碎建设实现后的指标。包含：1.零碎状态的实时数据通过3D模型中点击特定区域展现进去，包含： PV组串：实时电流、实时电压、实时功率（实时计算而来）等时序数据，也包含厂商、型号、倾角、方位角等固定的静态数据。逆变器：装置区域（静态数据）、型号（静态数据）、版本（静态数据）、实时电压（实时计算获取，各PV组串累加）、实时电流（实时计算获取，上司PV的最大电流值）、实时功率（实时计算获取，实时电压实时电流）、交换电压（U、V、W）、交换电流（U、V、W）、交换功率（U、V、W，实时计算获取，实时电压实时电流）、IGBT内芯温度（时序数据）、当天发电量（实时计算，累加）、当月发电量（实时计算，累加）、年度发电量（实时计算，累加）。发电阵列及发电零碎：当日、当月及年度累计发电量，这些都是通过上司的逆变器数据实时计算获取。团体自用电表/储能站电表/余电并网电表/气象仪：为了简化阐明，全副采纳静态数据，理论构建零碎时须要获取实时数据。2.零碎异样剖析采纳简略的规定形式，对以下两种状况进行告警，并在3D模型上实时提醒： 逆变器IGBT温度过高，当温度大于120°时进行告警，并提醒运维人员解决倡议：1.查看装置地位是否符合要求。2.尝试升高四周环境温度。3.敞开逆变器5分钟后重新启动。逆变器直流过压，当电流超过16A时进行告警，并提醒运维人员解决倡议：查看光伏组串的串联配置是否过多，导致开路电压高于逆变器最大输出电压。若属此状况，尝试缩小组串的数量，使组串开路电压降至逆变器规格范畴以内。须要留神的是，零碎告警后除了在3D模型上进行展现揭示外，往往还会通过电话、短信或邮件等形式告诉到运维人员进行及时处理，对于告诉能力的集成能够通过物联网平台的事件响应服务（服务链接：https://help.aliyun.com/docum...）实现。 整顿各设施物模型业务流程梳理实现，并且确定好了零碎指标，接下来须要对相干的设施进行物模型的定义，即每个设施的动态属性（属性值不会变动，如厂商、型号等）有哪些，会实时上报哪些数据及上报频率（这些为时序属性），还有哪些数据（这些数据成为虚构属性）是通过上报的数据进行实时计算获取到的，如果是通过实时计算，计算的规定是什么等等。本文中为了简化开发，咱们仅对光伏组件、逆变器、发电阵列、电站气象仪、光伏发电站5个局部进行物模型的梳理阐明，详情信息如下所示： 光伏组件 逆变器 发电阵列 电站气象仪 光伏发电站 制作3D模型整个光伏电站的实时状态展现及告警展现咱们应用IoT孪生引擎的场景编辑器进行开发，须要依据电站的理论状况进行3D模型的制作，制作实现之后生成GLB或GLTF格局的文件导入到IoT孪生引擎中应用。咱们筹备的3D模型如下所示：筹备好3D模型后，咱们就能够进入理论的零碎开发阶段了。 开发阶段基本概念孪生空间整体的开发步骤，大抵分成四步： 创立孪生空间、构建孪生体、配置数据源、治理孪生场景。 上面是后续操作会波及到孪生引擎的一些外围概念。 前置筹备您需注册一个阿里云的账号，而后登录物联网平台，能够购买一个企业实例也能够先通过收费实例进行体验，收费实例也可进行demo体验。体验地址（需先登录阿里云账号）：https://iot.console.aliyun.co... 创立孪生空间创立孪生空间在空间治理页面，点击“创立空间”按钮，输出空间名称，空间形容、空间坐标创立孪生空间，该空间蕴含孪生体、数据源及孪生场景，一个孪生空间可对应一个理论的我的项目。 构建孪生节点在“孪生实体图”页面，点击“编辑孪生体”进行孪生体编辑器，通过右键“新建节点”或拖拽左上角孪生节点来增加新节点，用于构建孪生体节点关系构造。构建实现的孪生体用于形容客户的业务模型，后续数据源配置，孪生场景的搭建都是基于该孪生体模型进行。其中的节点能够和实在设施绝对应，也能够是逻辑业务节点，咱们依照在筹备阶段梳理的业务流程创立对应的孪生节点。 添加物模型咱们依照筹备阶段整顿的各个设施物模型（光伏组件、逆变器、发电阵列、电站气象仪、光伏发电站），在对应的孪生节点上顺次增加，如下图所示。咱们具体以逆变器_A1节点的实时发电量为例，依照以下形式创立属性，留神属性标识符咱们前面会在配置数据映射时用到，其它属性依照后面表格形容的设施物模型逐个录入即可。 增加虚构属性对于各个设施虚构属性，须要通过其余属性数据的计算得来，在IoT孪生引擎中通过孪生规定来实现，咱们依据在筹备阶段梳理的设施物模型，顺次创立设施的孪生规定来构建虚构属性。节点运算规定分成两种类型： 本身节点规定 ：本身节点物模型属性数据的计算规定父子节点规定 ：父子节点间物模型属性数据的计算规定依然以后面在逆变器_A1增加的powerGeneration属性为例，咱们当初要计算日累计发电量，应该如何去做？先在逆变器_A1节点定义一个虚构属性dayTotalPowerGenerationdayTotalPowerGeneration的起源是本身规定，即dayTotalPowerGeneration=powerGeneration+dayTotalPowerGeneration 本身发电量的累加，咱们依照如下的形式进行配置。即逆变器_A!节点的属性powerGeneration变动时，会触发该规定，进行累加输入回dayTotalPowerGeneration属性。孪生模版为更不便构建孪生实体，可选中孪生实体图中的节点生成孪生模板，会把选中节点的关系、物模型和规定都拷贝到模板中，而后再通过援用、拷贝模板的形式来构建孪生实体图。在光伏电站场景中，逆变器、光伏组件都是须要复用创立的，因而咱们都把第一个创立的孪生节点及其物模型通过创立模板的形式进行复用，以节俭整个开发工夫，操作步骤如下所述。 创立孪生模版 选中心愿复用孪生节点，比方抉择逆变器_A1和它的子节点，点击右键生成孪生模板。 通过模板构建孪生体通过拖拽孪生模版(将模板拖拽到响应的节点上面)，即可构建雷同物模型、阶段运算规定的孪生体节点，简化配置的过程。例如本次咱们通过模板导入的形式增加一组逆变器，将模板_逆变器拖拽到A区_发电阵列上即可，须要留神的是，拖拽后的节点名称须要按需金总从新编辑，比方逆变器_A2： 配置数据源逆变器、光伏组件、电站气象仪三类设施实时上报的数据会先到物联网平台上，通过数据源配置将这三类设施的数据映射到孪生实体的具体节点属性上，以达到孪生实体实时感知物理设施状态的目标。 脚本配置孪生实体与物理设施之间是解耦关系，可应用数据映射性能，将物理设施的原始数据映射到孪生实体的业务模型中，即孪生节点的物模型属性上。数据映射由以下3局部组成： 咱们依然以逆变器_A1的powerGeneration为例，配置一个设施，通过数据映射将其属性映射到逆变器_A1节点的powerGeneration属性，此处咱们抉择设施通过物模型上报，以及具体的设施和topic，如下图所示。而后通过上面的destConfig将设施属性映射到孪生节点的具体属性，其中配置如下，iotId为逆变器_A1节点的节点id(点击节点详情即可看到)，identifier为逆变器_A1节点的属性标识符，key为设施上报的物模型数据，设施上报的属性key为powerGeneration，因为须要从物模型的规范流转数据格式中解析到该key的值，所以残缺的key为items\.powerGeneration\.value。 [ { "identifier": "powerGeneration", "iotId": "sGTmVQUGWJxSAb2hEI5Mg6pa00", "key": "items\\.powerGeneration\\.value", "name": "逆变器A01" }]运行后果咱们通过气筒模拟器设施来进行数据模仿上报，其中模拟器抉择的设施就是上一步咱们在数据映射配置的设施，具体操作如下：而后能够通过查看孪生节点的快照、历史数据、运行日志等来察看孪生体的运行状况，下图为逆变器_A1的实时发电量。 场景配置场景是数字孪生计划中的展现及交互页面，以3D形式展现孪生模型中的实时数据、状态及告警信息。可在场景中关联孪生模型中的数据源，配置状态及告警，实现配置后可预览并发布页面，页面公布实现后可嵌入至业务零碎中进行展现，咱们这里新建一个光伏商业电站的场景进行配置。 场景治理点击“场景治理”页面，创立一个名称为“光伏商业电站”的场景，形容可选填。若敞开提醒面板，可在场景列表，单击场景卡片，或单击卡片右下角的更多图标后单击进入编辑工作台，进入场景编辑工作台。 3D资源管理场景当中依赖的3D资源在此处进行上传和治理，将筹备阶段制作的光伏电站3D模型（gltf/glb类型）文件进行上传。 场景编辑器进入场景编辑器后将前一步上传的模型拖拽到场景中，本模型不做款式调整，仅调整角度及缩放比例。 场景数据配置在场景编辑器中，点击“数据配置”TAB，再点击组件面板“+”增加一个组件，在右侧面板中顺次对组件进行命名（抉择一个有业务含意的名字，如本图中“A区电站-1号逆变器”），抉择该组件对应的3D文件MESH（可抉择多个），再抉择该组件关联的孪生节点，之后该孪生节点的物模型属性数据可作为根底数据配置不同的数据看板，如下图所示配置了5个数据看板（可依据看板偏好抉择仪表盘、趋势图、水位图等款式）。以后面演示的实时发电量和当日累计发电量为例，看一下这两个数据面板和趋势图的配置，针对实时发电量，咱们抉择逆变器_A1节点的powerGeneration属性，而后款式抉择仪表盘，别离再填写展现名称和展现单位，最初抉择不同数据范畴对应的色彩款式即可。同理依照如下形式构建趋势面板，当月累计发电量。告警配置：如下图所示，点击编辑组件面板告警标示，新建一个告警，告警内容为在“筹备阶段-确定零碎指标”章节定义的告警内容，即IGBT心田片温度大于120度，触发告警，此处能够应用简略的条件表达式，也能够自定义简单表达式。这样当关联的数据超过所设定的阈值后就能够以告警图标显示进去，点击告警图标后能够显示具体的告警内容及培修倡议。 依照上述数据配置步骤将其余须要在3D模型上展现的数据及告警顺次进行配置实现即可。 场景分享&预览在所有数据配置实现之后，点击场景编辑器右上角“预览”图标，查看配置是否失常。若所有配置合乎预期，点击场景编辑器右上角“分享”图标将页面分享给其余用户，其余用户可间接通过链接URL和明码查看曾经配置好的光伏电站数字孪生运维零碎，比方接入到监控大屏或在展会时间接通过URL拜访向客户进行演示。 结语通过浏览本文，置信您曾经理解了构建数字孪生零碎的根本步骤以及如何应用阿里云IoT孪生引擎来开发数字孪生零碎。如果您后续想要进一步理解IoT孪生引擎能够通过咱们的官方网站进行查看，或者间接通过上面的钉钉二维码分割咱们单干。 物联网平台产品介绍详情：https://www.aliyun.com/produc... 阿里云物联网平台客户交换群

本文作者： 何淋波: 阿里云技术专家 陈绍强: Intel 资深软件架构师 俞林: Intel 高级软件工程师 北京工夫 1 月 30 号公布的 OpenYurt v1.2.0 版本，社区呼声最高的几大个性终于落地，OpenYurt 的特点更加显明，次要特点包含：Kubernetes 无侵入，云边端全协同，可编程的资源访问控制，以及申明式云原生设施治理。 v1.2 版本聚焦在节点池治理，重点打造 OpenYurt 零碎的差异化技术竞争力，次要个性有升高云边通信的流量老本，边缘自治能力加强，更丝滑的跨地区通信能力等。 大幅升高云边通信流量老本在云边协同场景下，边缘通过公网和云端连贯，当集群中部署了大量的业务 Pod 和微服务零碎(引入大量 Service 和 Endpointslices)，边缘节点和云端之间须要耗费大量带宽，给用户带来极大的公网流量老本压力。 社区对升高云边通信流量始终有比拟强的诉求，如何在不侵入批改 Kubernetes 的根底上满足需要，首先大家比拟容易思考到的计划是在节点池内减少一个 sync 组件，实时同步云端的数据，而后再分发给节点池中的各个组件。然而这个计划落地将面临不小的挑战，首先数据拜访申请都是边缘被动向云端发动的，sync 如何拦挡这些申请并散发数据呢？同时如果 sync 组件故障，边缘的申请将面临中断，而保障 sync 组件的高可用会十分辣手。 OpenYurt 社区独创基于 pool-coordinator+YurtHub 的云边流量复用机制，既与原生 Kubernetes 的云边通信链路无缝交融，又优雅的保障了通信链路的高可用(YurtHub Leader 选举)，实现云边通信老本的消减。 在节点池内，节点从云端获取的数据，能够分为两种类型： pool scope data:  组件从云端获取的数据完全一致，如每个节点的 kube-proxy 获取到的 endpointslicesnode scope data: 组件从云端获取的数据和本身节点相干，如每个节点的 kubelet 获取到的 pods同时通过测试 [ 1] 发现，真正占用云边带宽的数据是 pool scope data。OpenYurt v1.2 中通过在节点池中复用 pool scope data，从而大幅升高云边的数据通信量。如下图： ...

业务背景随着物联网技术的疾速倒退成熟，物联网设施从一开始的传感器类感知设施向智能化设施降级，传统企业也开始将本身设施产生的数据作为企业的重要资产进行治理，如何稳当的存储和备份这些设施数据资产，并在关键问题呈现时进行回溯，以及通过对这些设施数据的深度剖析来帮忙企业实现经营提效变的尤为要害。本实际以一个道路交通场景下设施经营治理的实在需要为背景来介绍如何应用物联网平台的数据服务实现对设施数据的存储、备份、预处理和深度剖析，以达到企业经营提效的成果。 业务问题设施数据量大，存储老本过高当企业的设施规模达到十万甚至百万以上时，设施实时产生的数据量会十分大，如果企业有对数据长周期存储和追溯的需要，产生的数据存储老本会十分高，同时设施数据量大了当前也会对数据读写的性能和稳定性造成影响，带来额定的资源和运维老本。 设施品种繁多，数据格式不对立道路交通场景下的设施品种丰盛多样，如一体化锥桶、一体化疾速封路器、收费站被动预警灯、车载预警LED屏等，不同类型的设施可能是由不同的生产商提供或者由不同的技术团队开发的，设施上报的数据格式千差万别难以对立，存储也无奈实现标准化、结构化的存储，为企业后续的数据处理、剖析和治理带来了很大的困扰。 短少数据分析，价值难以开掘企业将设施数据采集上来当前，短少业余的剖析工具，无奈对设施数据进行多维度的聚合剖析，暗藏在数据中的业务价值也就难以开掘，导致设施数据上云反而徒增了老本，没有起到经营提效的成果，也没有真正实现企业进行设施智能化降级的业务指标。 最佳实际数据存储/备份 - 实现设施数据冷热拆散，大幅升高存储老本阿里云物联网平台提供了设施数据存储和备份的残缺解决方案，缩小了数据流转和两头存储带来的额定老本开销和架构复杂度。同时基于阿里云弱小成熟的云计算底座，反对可扩大的海量数据存储、超高的数据压缩比和冷热数据存储拆散等能力，可极大升高数据存储和备份的老本。 操作步骤概要1.进入物联网平台控制台，开明企业版实例，和数据服务相干的是如下4个规格。控制台地址：https://iot.console.aliyun.com 开明实现后，点击企业版实例卡片进入实例详情页，再点击数据服务进入数据相干的性能页。2.进入数据服务-数据存储的热数据存储性能页，实时保留设施上报的时序数据。创立热数据存储规定配置数据源Topic（反对通配）配置自定义存储脚本启动热数据存储规定3.进入数据服务-数据接入性能页，开启产品级别的冷数据备份，低成本长周期保留设施数据。配置产品备份（会备份产品下所有设施的数据）4.进入数据服务-数据存储的冷数据存储性能页，查看产品备份工作状态。查看产品备份状态 相干产品文档如您想要理解更细节的产品性能使用指南，能够拜访物联网平台的官网产品文档。热数据存储：https://help.aliyun.com/docum...冷数据备份：https://help.aliyun.com/docum...冷数据配置：https://help.aliyun.com/docum... 数据解析 - 实现不同类型设施异构数据的统一化和预处理IoT设施数据比起IT数据有如下三个特点：第一个特点是IoT数据是时序的，通常是基于工夫范畴剖析，而且随着工夫流逝数据价值衰减更显著，特地是监控场景下，对数据处理的实时性要求高；第二个特点是数据品质不稳固，设施上报的数据可能会受所处网络或者简单工况影响，与典型的互联网数据比照往往须要进行数据预处理，比方插值计算和降采样等；第三个特点是碎片化比较严重，不同类型的设施或者同一类型不同生产商的设施在数据格式的定义上都实现不一样，给后续的数据处理带来了很大的麻烦。阿里云物联网平台针对以上IoT数据的特点，提供了组件式的数据解析服务，包含可自定义解析脚本的数据格式转换，以及窗口聚合、超时插值、相邻音讯计算、函数转化等内置算子，助力客户疾速实现对设施数据的预处理。 操作步骤概要1.进入数据服务-数据解析性能页，创立数据解析工作。 2.点击查看进入工作编辑画布，配置数据源节点，抉择设施上报数据的Topic（反对通配）。3.编写自定义解析脚本（源节点须要将数据格式抉择为原始数据），对设施数据进行解决。 除了可在自定义节点编写数据解析脚本外，也能够在数据源节点配置其余类型数据格式的转换，如下图所示。4.配置数据指标节点，将解析后的数据写入自定义存储表（解析后的数据字段须要和自定义存储表中的统一）。5.配置实现后，将数据解析工作启动并公布上线。 相干产品文档如您想要理解更细节的产品性能使用指南，能够拜访物联网平台的官网产品文档。数据解析：https://help.aliyun.com/docum... 剖析洞察 - 实现设施数据的实时和离线剖析，深度开掘业务价值设施数据通过数据解析并输入到自定义存储表后，能够应用SQL开发工作台来剖析这些数据，比方设施新增/沉闷剖析、设施工况和经营统计等，深度开掘设施数据的业务价值。剖析洞察的后果配置为自定义服务API后，能够被客户的业务系统集成调用，客户只需专一于业务开发，无需关注设施数据的存储、备份、剖析和API凋谢等技术细节，大大放慢了业务利用的开发。 操作步骤概要1.进入数据服务-剖析洞察性能页，创立SQL剖析工作，再点击进入SQL开发工作台。 2.在SQL开发工作台编写SQL语句，对自定义存储表中的设施数据进行深度剖析。3.将剖析后的数据存入另一张自定义存储表。4.进入数据服务-数据利用性能页，创立自定义服务API，客户业务零碎可通过SDK查问剖析后果。 数据API地址：https://help.aliyun.com/docum...下载地址：https://help.aliyun.com/docum... 相干产品文档如您想要理解更细节的产品性能使用指南，能够拜访物联网平台的官网产品文档。剖析洞察：https://help.aliyun.com/docum...自定义服务API：https://help.aliyun.com/docum... 物联网平台产品介绍详情：https://www.aliyun.com/produc... 阿里云物联网平台客户交换群

业务背景企业数字化过程热火朝天，更多传统企业拥抱数字化革新，冀望从数字化过程中开掘更多商业机会，企业从一次性产品的销售的商业模式，转型为为客户提供更多增值服务。其中围绕着设施智能化革新，及后续的数据业务价值开掘是增值的关键点。本实际以一个摩托车数字化场景下设施经营剖析的实在需要为背景，来介绍如何应用物联网平台的数据服务实现对设施数据进行深度业务剖析，带来更多用户的摩托车增值价值。 业务问题用户快速增长，摩托车越卖越多，用户需要正从实用性向娱乐喜好型过渡。如何满足多媒体车机座舱个性化需要 ？如何解决车辆散布和经营剖析优化销售策略？如何基于车辆全生命周期数据进行性能优化和更优质服务报修服务？这些问题都是企业急需解决的外围问题，本实际以摩托车驾驶行为剖析为例。 最佳实际前置条件数据分动洞察前须要进行数据备份，另外如果数据是非结构化或者须要预处理的，须要进行数据解析。具体操作能够参考《IoT设施数据的存储、解析和价值开掘实际》https://yuque.antfin-inc.com/...。 剖析洞察设施数据通过数据解析并输入到自定义存储表后，能够应用SQL开发工作台来剖析这些数据，来深度开掘设施数据的业务价值。剖析洞察的后果配置为自定义服务API后，能够被客户的业务系统集成调用，客户只需专一于业务开发，无需关注设施数据的存储、备份、剖析和API凋谢等技术细节，大大放慢了业务利用的开发。 操作步骤概要具体操作步骤能够参考《IoT设施数据的存储、解析和价值开掘实际》https://yuque.antfin-inc.com/...，这里不赘述。本文次要建设“剖析洞察”的应用场景及具体操作形式。 场景剖析车载T-Box能够采集发动机转速、水温，行驶速度，车辆驾驶模式，启停事件等传感数据。基于这些车载传感数据分析用户的驾驶习惯，剖析后果能够用以：1）用户手机客户端展现剖析统计信息，能够加强用户应用黏性；2）同时依据驾驶习惯举荐车辆周边产品，及车友社区内容经营。 SQL开发工作台以车辆减速档位最近一天应用剖析为例，在数据服务-剖析洞察下“新建SQL剖析”工作，在“开发工作台”编写相应的经营剖析工作。 数据表“开发工作台”的左侧边栏曾经组织好了“产品存储表”、“自定义存储表”、“平台零碎表”，能够在“SQL剖析”工作按需应用这些数据做聚合、关联等剖析。“产品存储表”：T-Box上传的传感数据通过“数据备份”操作后默认呈现，及快捷提供了数据的最新值表“产品快照表”。“平台零碎表”：用户在物联网控制台的“设施治理”-“产品”、“设施”、“分组”设置的数据，数据服务会提供对应的数据表，更加不便的取得设施相干的配置数据，用以聚合剖析设施。“自定义存储表”：能够应用设施时序数据，平台零碎数据做聚合剖析，剖析后果将存储在用户本人定义的表里。●零碎表和产品表文档地址：https://help.aliyun.com/docum...●自定义存储表文档地址：https://help.aliyun.com/docum... 交互式剖析在无奈确定数据分析模型时，能够在“开发工作台”随便编写SQL并点击功能区的“执行”按钮，SQL的执行后果马上能够在“后果”里展现进去。工作周期调度当分析模型曾经合乎业务需要时，咱们须要设置任务调度来周期地产出剖析后果。点击“执行设置”能够配置工作的调度失效日期、调度周期（目前提供日调度和小时调度）。自定义存储表能够跳转到“数据存储”-“冷存储”-“自定义存储表”页面去新建，依照“交互式剖析”时展现的“输入构造”定义表构造。调度设置实现点击“公布”后，将依照调度周期产出后果。工作公布后能够点击“工作运维”进行运维工作，查看工作状态、重跑工作，或者创立“手动工作”来弥补历史数据 数据后果SQL工作定期执行的后果会写配置的自定义存储表中，剖析后果能够通过以下形式被应用。 数据导出如何后果数据须要线下备份或者应用xls进一步剖析，能够应用“导出”性能。能够依照工夫范畴进行数据导出，目前导出格局只反对csv。 数据API如果后果数据是用于利用集成，比方客户app展现用户减速操作散布，则能够配置API及SDK调用获取后果数据。具体操作步骤能够参考《IoT设施数据的存储、解析和价值开掘实际》https://yuque.antfin-inc.com/...，这里不赘述。 大数据集成如果用户曾经建设了企业数仓，能够应用IoT DataSource集成到企业数仓。具体操作参考文档：https://yuque.antfin.com/g/th... 《IoT Reader》*目前只反对阿里云Dataworks 相干产品文档如您想要理解更细节的产品性能使用指南，能够拜访物联网平台的官网产品文档。剖析洞察：https://help.aliyun.com/docum... 物联网平台产品介绍详情：https://www.aliyun.com/produc... 阿里云物联网平台客户交换群

背景挑战快手容器云平台旨在为快手一直增长、一直变动和多样化的业务，提供基于容器化部署的超大规模基础设施服务。为了实现这一指标，快手工程师须要解决弹性、稳定性、效率和无服务器架构等挑战，在这些挑战中，镜像散发的稳定性和效率也是最辣手的问题之一。 解决方案为了让快手容器云平台的镜像散发更加稳固和高效，快手容器云技术团队携手阿里云、蚂蚁团体在龙蜥社区适配优化落地解决方案。事实证明，Dragonfly 及其子项目 Nydus 是以后场景下适合的解决方案，该计划可能与现有零碎很好地兼容，在现有能力根底上平滑过渡，同时也为服务交付带来了大幅的效率晋升。 成果Dragonfly 上线后，整个集群通过 P2P 组建散发网，所有节点帮忙中心化镜像仓库缓解网络带宽压力。镜像仓库的网络带宽压力均匀缓解 70% 以上，峰值压力缓解 80% 以上，镜像散发零碎变得更加稳固、牢靠、高效，零碎可能同时反对更多数量的镜像并发拉取申请，尤其是在应答 Daemonset 部署和要害、大批量实例业务服务更新的场景中，高并发镜像拉取仓库不再是瓶颈。 应用我的项目Dragonfly:https://github.com/dragonflyo...Nydus:https://github.com/dragonflyo...containerd:https://github.com/containerd...相干数据峰值缓解 80% 以上     镜像拉取工夫节俭 90% 以上     POD 实例服务耗时节俭 50% 计划详解为每月10 亿用户提供稳定性和性能反对“在快手，Dragonfly 无效解决了海量文件散发问题。”  ——吴宏斌 快手综合经营平台负责人 对于快手的镜像散发系统升级革新来说，最大的挑战不仅仅是镜像仓库峰值压力的缓解和镜像拉取减速，如何让服务散发无缝连接平滑过渡，尽可能让业务无感、不受零碎变动影响同样重要。快手容器云平台工程师通过调研发现，Nydus 与 Dragonfly 零碎深度集成，同时也反对传统 OCI 镜像，可能以兼容敌对的形式提供疾速、稳固、平安、便捷的容器镜像拜访，非常容易地就能适配容器云平台已有工作，实现业务从已有镜像应用形式平滑过渡到新镜像格局。平台惟一要做的就是将容器运行引擎从 Docker 切换到 containerd，因为 containerd 与 Dragonfly 的集成体验更好。在快手工程师的致力下，大规模节点的容器引擎安稳切换轻而易举，containerd 和 Dragonfly 均已被疾速全面采纳。 稳固高效的镜像散发对于稳固、高效的镜像散发，Dragonfly 给出了完满的答案。在快手，有许多重要的服务须要在短短几分钟内扩容到成千上万个实例，例如快手的818 购物节或双 11 流动的业务扩容需要。这种缩放须要数千 GB 带宽能力间接从镜像仓库下载。在另外一些场景中，预测模型和搜寻业务须要定期更新模型参数文件和索引文件来保障举荐成果和检索成果，这在技术上意味着必须立刻将数百 GB 的文件散发到每个相干实例。 快手工程师在所有容器云主机部署了 Dragonfly 组件：Dfdaemon 和 Dfget，通过 P2P 算法拉取文件。同时，在每个 AZ 部署了独立的超级节点集群，为 Dfget 设计了 Schedule Server，抉择适合的超级节点来防止跨 AZ 或者跨 Region 的流量。更重要的是，工程师基于 Dragonfly 独特的片治理 P2P 算法实现了数据流 P2P 传输，升高了磁盘负载。得益于 Dragonfly，数以万计的实例能够同时拉取镜像或下载文件，而不会减少工夫老本和磁盘负载。 ...

作者简介： **宋子暨 阿里云智能日本及韩国大区总经理 宋子暨学生领有15余年的IT和云计算的全球化工作教训。他于2014年退出阿里云，作为阿里云国际化初始成员负责寰球的合作伙伴和渠道体系建设，随后从零开始搭建了阿里云日本业务。他凭借了敏锐的商业嗅觉和粗浅的业务洞察，将阿里云在日本的业务拓展方向聚焦于游戏互联网，并且在这一细分畛域与泛滥本地头部企业建设了良好的单干关系，建立了良好的口碑。 作为亚洲最成熟的市场之一，日本的云计算市场方兴未艾。依据权威钻研机构IDC测算，2021年日本云计算的市场规模达到300亿美元，同比增长34.7%。将来五年，这个数字还将增长至2.5倍。 作为云计算服务商出海的先驱者，阿里云于2016年就开始了在日本市场的布局，先后于2016年和2019年设立两座数据中心，为泛滥包含日本头部的游戏互联网企业在内的客户提供算力、存储、数据库等根底云资源以及AI算法类服务。就在这个月，阿里云在日本正式启用第三座数据中心，以造成更高可靠性、高弹性的3AZ可用区状态，满足日本市场疾速倒退的业务需要。 现在，许多日本企业曾经实现了从传统IT架构向云计算平台转移，并踊跃尝试大数据分析和AI技术以促成业务效率的晋升。如何在客户要求高、谋求极致的日本市场为客户提供真正的价值呢？自从踏上日本这片疆土，我便始终思考这个问题。 日本是一个传统的互联网大国。作为Business Continuity Plan（业务持续性打算）的伎俩之一，许多公司十余年前便开始应用云计算服务，以保障在地震等自然灾害降临之时业务也能失常运行。随着业务扩充和行业竞争日益强烈，游戏互联网行业的客户迫切需要更高品质的云服务，在实现业务稳固运行的前提下，加重工程师在基础设施的搭建运维累赘。 游戏上市公司Enish采纳了阿里云云原生数据库PolarDB以及容器技术，确保了游戏上线期间的海量拜访，在为玩家提供更顺畅体验的同时，节俭了30%以上的云服务应用和运维老本。 日本最大人工智能企业Preferred Networks则通过阿里云独特的cGPU技术极大晋升了AI服务开发时所需的GPU应用效率。咱们还通过提供响应速度远超友商的7*24小时专属TAM（Technical Account Manager)服务，为日本客户的服务上线保驾护航。 另一方面，咱们也踊跃利用阿里巴巴在大数据和AI算法畛域的技术能力，助力解决日本企业和社会面临的一些挑战。 例如，阿里云通过和日本互联网公司M3单干，利用阿里达摩院的医疗图像解析技术，帮忙日本200多家医院在20秒之内就能取得了初步诊断后果，极大地加重了医生的累赘。 此外，咱们的车牌隐衷爱护AI以超过95%的准确度，帮忙日本最大的二手车团体IDOM实现业务流程自动化，削减了90%的人员老本。这些单干作为中日两国互联网企业的单干案例，取得了NHK、日本经济新闻和雅虎日本媒体屡次的关注。 和其余国家一样，疫情促使日本的批发等传统线下行业放慢了数字化转型的脚步。将来，咱们将进一步将阿里云在中国的生态劣势和服务日本本地市场的教训联合起来，联结本地合作伙伴进一步打造电子价签等合乎本地市场需求的一站式解决方案，为传统行业数字化转型做出更大奉献。

屡获殊荣，翻新不止。 2022 年，阿里云根底产品通过了一系列权威评估和奖项认证，进行了 CIPU 重大架构降级，公布了一系列翻新产品，并始终走在开源奉献的前列，为发明客户价值而奋勇向前。

云原生曾经变成十分风行的技术趋势，从上云到用云，云原生通过全面容器化、核心技术互联网化和利用Serverless化三大范式，帮忙企业解决利用构建的一系列问题，让利用更麻利，助力企业业务疾速倒退。 阿里云通过多年的技术倒退，曾经帮忙了千行百业胜利上云，积攒了相当多的实战经验，对寰球云原生的利用态势也有肯定洞见。《云原生实战指南》正是在这种背景下产生的，它凝聚了阿里云云原生丰盛的技术思考，旨在以利用为核心，构建企业数字化转型最短门路。 让云原生成为企业疾速倒退的助推器。 扫描二维码 输出：实战指南 即可下载《云原生实战指南》全本 内容板块寰球云原生利用洞察与趋势 阿里云在云原生畛域的最新产品与技术布局 阿里云 All in Serverless 全新思考与投入 心动、传音、新东方、小红书等企业实战经验 章节检索《云原生实战指南》不仅着眼于寰球的倒退态势，也聚焦于本身在云原生畛域的耕耘成绩，更有多个客户的上云实战案例，供宽广开发者浏览参考。 4 大板块中分为 12 章节，由多位阿里云技术专家和企业代表执笔，与大家独特分享云原生的实战之路。 云原生激活利用构建新范式——Part. 1 容器服务助力企业精益用云——Part. 2 云原生可观测套件:构建无处不在的可观测基础设施——Part. 3 传音挪动互联可观测体系设计与落地——Part. 4 利用 Serverless 化，让业务开发心无旁骛——Part. 5 优化 20%资源老本，新东方的 Serverless 实际之路——Part. 6 心动网络算法平台的 Serverless 摸索之路——Part. 7 以服务治理为基石构建可管可控互联网利用架构——Part. 8 禾连云原生微服务治理实际——Part. 9 音讯队列 RocketMQ5.0：从音讯服务到云原生事件流解决平台——Part. 10 云原生技术中台 CNStack2.0 正式公布 助力企业高效用云——Part. 11 数字化平安生产平台 DPS 重磅公布——Part. 12 在此援用阿里巴巴团体研究员、阿里云智能云原生利用平台总经理丁宇的一句话： “将来，阿里云在云原生畛域将继续的引领规范，一直冲破，推动畛域和产业疾速倒退。”     期待越来越多的开发者和阿里云一起实现云原生的美妙蓝图，助力产业蓬勃发展。

以下文章来源于谐云科技 ，作者陈炜舜 在 OAM 最早推出时，谐云就参加其中，并基于社区中 oam-kubernetes-runtime 我的项目二次开发，以满足容器云产品中 OAM 利用模型的性能需要。该性能是将利用划分为多个 Kubernetes 资源 —— 组件(Component)、配置清单(ApplicationConfiguration = Component + Trait)，其目标是心愿将用户侧的开发、运维视角进行拆散，并可能借助社区的资源疾速上线一些开源组件和运维特色。 后续，KubeVela 我的项目在组件和配置清单两个资源上形象出利用资源(Application)，并借助 cuelang 实现 KubeVela 的渲染引擎。谐云疾速集成了 KubeVela，并将原有的多种利用模型（基于 Helm、基于原生 Workload、基于 OAM 的利用模型）对立成基于 KubeVela 的利用模型。这样做既加强了谐云 Kubernetes 底座的扩展性和兼容性，同时又基于 Application 这一形象资源拆散的基础架构和平台研发，将许多业务性能下沉到底座基础设施，以便适应社区一直倒退的节奏，疾速接入多种解决方案。 除此之外，确定的、对立的利用模型可能帮忙谐云多产品间的交融，尤其是容器云产品和中间件产品的交融，将中间件产品中提供的多款中间件作为不同的组件类型疾速接入到容器云平台，用户在解决中间件个性时应用中间件平台的能力，在解决底层资源运维时，应用容器云平台的能力。 基于以上背景，谐云对社区版本治理、纳管性能进行了加强，并心愿可能分享至社区进行探讨，引发更多的思考后，对社区性能做出奉献。 利用版本治理版本控制与回滚在利用运维时，利用的版本控制是用户十分关怀的问题，KubeVela 社区中提供了 ApplicationRevision 资源进行版本治理，该资源在用户每次批改 Application 时将产生新的版本，记录用户的批改，实现用户对每次批改的审计和回滚。 而谐云的利用模型当中，因为组件可能会蕴含一些“不须要计入版本”的纯运维 Trait，例如版本升级的 Trait，手动指定实例数的 Trait 等，咱们在降级、回滚时，须要将这些 Trait 疏忽。 在社区晚期版本中，TraitDefinition 含有 skipRevisionAffect 字段，该字段在晚期社区版本中实现如下： ApplicationRevision 中仍会记录 skipRevisionAffect 的 Trait若用户触发的批改范畴仅蕴含 skipRevisionAffect 的 Trait，将此次更新间接批改至以后记录的最新版本中若用户触发的批改范畴不仅蕴含 skipRevisionAffect 的 Trait，将此次更新作为新版本记录这样实现的 skipRevisionAffect 无奈真正使 Trait 不计入版本，例如，咱们将 manualscaler 作为不计入版本运维特色，与 Deployment 的伸缩相似，当咱们仅批改 manualscaler ，新的实例数量会被计入到最新版本，但当咱们的版本真正产生扭转产生新的版本后，再次手动批改了实例数量，最初因为某些起因回滚到上一个版本时，此时实例数量将产生回滚（如下图）。而通常状况下，决定利用实例数量的起因不在其处于什么版本，而在以后的资源使用率、流量等环境因素。且在 Deployment 的应用中，实例数量也不受版本的影响。 ...

点击此处即可查看容器服务 ACK 产品详情

作者：孤戈 在 JDK 9 之前，Java 基本上均匀每三年出一个版本。然而自从 2017 年 9 月分推出 JDK9 到当初，Java 开始了疯狂更新的模式，基本上放弃了每年两个大版本的节奏。从 2017 年至今，曾经公布了 十一个版本到了 JDK 19。其中包含了两个 LTS 版本（JDK11 与 JDK17）。除了版本更新节奏显著放慢之外，JDK 也围绕着云原生场景的能力，推出并加强了一系列诸如容器内资源动静感知、无进展 GC（ZGC、Shenandoah）、原生的运维能力等等。这篇文章是 EDAS 团队的同学在服务客户的过程中，从云原生的角度将相干的性能进行整顿和提炼而来。心愿能和给大家一起意识一个新的 Java 状态。 云原生场景定义云原生的外在推动力之一是让咱们的业务工作负载最大化的利用云所带来的技术红利，云带来最大的技术红利就是通过弹性等相干技术，带来咱们资源的高效交付和利用，从而升高最终的资源的经济老本。所以如何最大化的利用资源的弹性能力是很多技术产品所谋求的其中一个指标。 同时，另外一个外在推动力是如何去防止云厂商技术的锁定，实现伎俩就是推动各个领域的规范的建设。自从云原生诞生以来， 随着 Kubernetes 的大获胜利，以开源为次要状态的技术产品，继续从各个领域中造成既定的标准和规范，是技术产品谋求的另外一个指标。 有了最终的指标，通过一直优化的规范，那么如何在这个新场景下利用上相干的规范能力，是很多产品一直往前演进的方向。以上两点，咱们本人的产品如此，Java 亦如此。 Java 针对性能力针对 Java 的近十个版本更新，咱们将从运维、编程模型与运行时、内存三个场景进行解读。其中运维局部次要是如何利用现有的容器技术获取运维指标以及在这个场景下的一些原生能力的反对。同时 Java 也在字符串和新的 IO 模型与能力。另外一个最大的变动来自于内存局部，除了在容器场景下对于 CGroup 有更好的反对之外，还提供了令人期待的 ZGC 和 Shenandoah GC 两款无进展的垃圾回收器，除了提供低时延的 STW 之外，还具备偿还局部内存给操作系统，最大限度的提供了利用在云原生场景下利用硬件资源的能力。 整个解读分为高低两篇，除了内存会应用一个独自的文章进行解读之外，剩下的内容次要在这章解说。更原生的运维场景1、OperatingSystemMXBean容器的其中一个能力是过程级别的隔离，默认状况下，容器内的 Java 程序如果基于 JMX 中提供的 OperatingSystemMXBean 中的办法进行拜访，会返回所在宿主机的所有资源数据。在 JDK 14 的版本之后，在容器或其余虚拟化操作环境中执行时，OperatingSystemMXBean 办法将返回容器特定信息（如：零碎可用内存、Swap 、Cpu、Load 等），这项能力在基于 JMX 开发的很多能力（如：监控、零碎限流等）是一一项特地敌对的能力。JDK 14 中波及到的革新的 API 如下： ...

本系列文章由余凯执笔创作，联结作者：阿里云容器服务 谢石 对本文亦有奉献 近几年，企业基础设施云原生化的趋势越来越强烈，从最开始的IaaS化到当初的微服务化，客户的颗粒度精细化和可观测性的需要更加强烈。容器网络为了满足客户更高性能和更高的密度，也始终在高速的倒退和演进中，这必然对客户对云原生网络的可观测性带来了极高的门槛和挑战。为了进步云原生网络的可观测性，同时便于客户和前后线同学减少对业务链路的可读性，ACK产研和AES联结共建，合作开发ack net-exporter和云原生网络数据面可观测性系列，帮忙客户和前后线同学理解云原生网络架构体系，简化对云原生网络的可观测性的门槛，优化客户运维和售后同学解决疑难问题的体验 ，进步云原生网络的链路的稳定性。 鸟瞰容器网络，整个容器网络能够分为三个局部：Pod网段，Service网段和Node网段。这三个网络要实现互联互通和访问控制，那么实现的技术原理是什么？整个链路又是什么，限度又是什么呢？Flannel， Terway有啥区别？不同模式下网络性能如何？这些，须要客户在下搭建容器之前，就要根据本人的业务场景进行抉择，而搭建结束后，相干的架构又是无奈转变，所以客户须要对每种架构特点要有充沛理解。比方下图是个简图，Pod网络既要实现同一个ECS的Pod间的网络互通和管制，又要实现不同ECS Pod间的拜访， Pod拜访SVC 的后端可能在同一个ECS 也可能是其余ECS，这些在不同模式下，数据链转发模式是不同的，从业务侧体现后果也是不一样的。 本文是[全景分析容器网络数据链路]第五局部局部，次要介绍Kubernetes Terway ENI-Trunking模式下，数据面链路的转转发链路，一是通过理解不同场景下的数据面转发链路，从而探知客户在不同的场景下拜访后果体现的起因，帮忙客户进一步优化业务架构；另一方面，通过深刻理解转发链路，从而在遇到容器网络抖动时候，客户运维以及阿里云同学能够晓得在哪些链路点进行部署观测手动，从而进一步定界问题方向和起因。 系列一：全景分析阿里云容器网络数据链路（一）—— Flannel 系列二：全景分析阿里云容器网络数据链路（二）—— Terway ENI 系列三：全景分析阿里云容器网络数据链路（三）—— Terway ENIIP 系列四：全景分析阿里云容器网络数据链路（四）—— Terway IPVLAN+EBPF 系列六：全景分析阿里云容器网络数据链路（六）—— ASM Istio (To be continued) Terway ENI-Trunking 模式架构设计弹性网卡中继Trunk ENI是一种能够绑定到专有网络VPC类型ECS实例上的虚构网卡。相比弹性网卡ENI，Trunk ENI的实例资源密度显著晋升。启用Terway Trunk ENI性能后，指定的Pod将应用Trunk ENI资源。为Pod开启自定义配置是可选性能，默认状况下创立的Pod，未开启Terway Trunk ENI性能，应用的是共享ENI上的IP地址。只有当您被动申明为指定Pod开启自定义配置后，相应的Pod能力应用Pod自定义配置能力，Terway才能够同时应用共享ENI以及Trunk ENI为Pod调配IP。两种模式共享节点最大Pod数量配额，总部署密度和开启前统一。 金融、电信，政府等行业对数据信息安全有着十分严格的数据安全要求，通常，重要的外围数据会放在自建的机房内，并且对拜访此数据的客户端有严格的白名单管制，通常会限度具体的IP拜访源。业务架构上云时，往往是通过专线，VPN等买通自建机房和云上资源买通，因为传统容器中PodIP 是不固定的，NetworkPolicy 只能在集群内失效，这对客户的白名单设置有了十分大的挑战。ENI 在 Trunk 模式下，能够配置独立的平安组、vSwitch能力，带来更为细化的网络配置能力，提供极具竞争力的容器网络解决方案。 在trunking的命名空间内能够看到相干的pod信息和节点信息，其中pod利用的IP 的网络咱们稍后会具体阐明 Pod内有只有指向eth0的默认路由，阐明Pod拜访任何地址段都是从eth0为对立的出入口 那么Pod是如何ECS OS进行通信呢？在OS层面，咱们一看到calicxxxx的网卡，能够看到是从属于eth1的，对于节点和Pod的通信连贯，这个相似于《全景分析阿里云容器网络数据链路（三）—— Terway ENIIP》 ，此处不再进行过多阐明。通过OS Linux Routing 咱们能够看到，所有目标是 Pod IP 的流量都会被转发到Pod对应的calico虚构往卡上，到这里为止，ECS OS 和Pod的网络命名空间曾经建设好残缺的出入链路配置了。 让咱们把眼光聚焦ENI Trunking自身。ENI Truning 是如何实现Pod的交换机和平安组的配置呢？Terway减少一种名为PodNetworking的自定义资源来形容网络配置。您能够创立多个PodNetworking，来布局不同网络立体。创立PodNetworking资源后，Terway将同步网络配置信息，只有status成为Ready后，该网络资源能力对Pod失效。如下图所示，类型为Elastic，只有namespce的标签的合乎tryunking：zoneb， 就给pod应用指定的平安组和交换机。 ...

作者：澄潭 在去年11月的云栖大会上，咱们开源了云原生网关 Higress，时隔 2 月，Higress 的 Github 我的项目曾经播种了 700+ star，以及大量社区小伙伴的关注。在社区的交换中咱们发现有不少微服务开发者在应用如 Spring Cloud Gateway/Zuul 等微服务网关对接 Nacos 注册核心实现微服务的路由，并且心愿理解迁徙到 Higress 网关能带来哪些益处。 Higress 的 Github 我的项目 https://github.com/alibaba/hi...本文将介绍 Higress 组合 Nacos 作为微服务网关能力，并介绍微服务网关倒退的两个趋势，为网关的选型指明路线： 趋势一：对立 API 规范，向云原生微服务架构演进趋势二：合并平安&流量网关，向 DevSecOps 演进Higress：Nacos 的最佳拍档 Higress 和 Nacos 其实是师出同门——阿里中间件团队。在 Higress 撑持阿里外部业务的阶段，Higress 就曾经搭配 Nacos 作为微服务网关应用，凭借高性能撑持了双十一的洪峰流量；到了云产品商业化阶段，Higress 和 Nacos 持续基于阿里云 MSE（Microservices Engine）产品，严密合作演进产品性能；Higress 开源之后，如果想要自建微服务网关，抉择 Higress 配合 Nacos 应用，具备以下劣势： 比照 Spring Cloud Gateway/Zuul 等传统 Java 微服务网关性能高出 2-4 倍，能够显著升高资源老本作为云原生网关，实现了 Ingress/Gateway API 规范，兼容 Nginx Ingress 大部分注解，反对业务渐进式向基于 K8s 的微服务架构演进与 Dubbo/OpenSergo/Sentinel 等开源微服务生态深度整合，提供最佳实际Higress 的装置部署请点击原文参考 Higress 官网文档，这里默认曾经装置好 Higress，搭配 Nacos 应用的具体形式如下： ...

作者：卜比 本文是《容器中的 Java》系列文章之 4/n ，欢送关注后续连载 :) 。 系列1：JVM 如何获取以后容器的资源限度？ 系列2：Java Agent 踩坑之 appendToSystemClassLoaderSearch 问题 系列3：让 Java Agent 在 Dragonwell 上更好用 最近在容器环境中，发现在 Java 过程是 1 号过程的状况下，无奈应用 arthas。 提醒 AttachNotSupportedException: Unable to get pid of LinuxThreads manager thread。具体操作和报错如下： # java -jar arthas-boot.jar[INFO] arthas-boot version: 3.5.6[INFO] Found existing java process, please choose one and input the serial number of the process, eg : 1. Then hit ENTER.* [1]: 1 com.alibabacloud.mse.demo.ZuulApplication1[INFO] arthas home: /home/admin/.opt/ArmsAgent/arthas[INFO] Try to attach process 1[ERROR] Start arthas failed, exception stack trace:com.sun.tools.attach.AttachNotSupportedException: Unable to get pid of LinuxThreads manager thread at sun.tools.attach.LinuxVirtualMachine.<init>(LinuxVirtualMachine.java:86) at sun.tools.attach.LinuxAttachProvider.attachVirtualMachine(LinuxAttachProvider.java:78) at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:250) at com.taobao.arthas.core.Arthas.attachAgent(Arthas.java:117) at com.taobao.arthas.core.Arthas.<init>(Arthas.java:27) at com.taobao.arthas.core.Arthas.main(Arthas.java:166)[INFO] Attach process 1 success.之前也遇到过，总是调整了下镜像，让 Java 过程不是 1 号过程就能够了。但这个不是长久之计，还是要抽时间看下这个问题。 ...

作者：十眠、牧思 Spring Cloud 利用为何须要服务治理随着微服务技术的倒退，微服务(MicroServices) 的概念早已深入人心，越来越多的公司开始应用微服务架构来开发业务利用。 如果采纳切当，微服务架构能够带来十分大的劣势。微服务架构的最大益处是它能够晋升开发效率和零碎整体的稳定性： 开发部署简略：单个微服务的性能能够更快地更改，因为能够独立部署、影响范畴更小，启动和调试单个微服务的工夫老本相比于单体利用也大大减少。横向扩大简略：依据业务的顶峰低谷周期疾速的横向扩大非常简单，因为单个微服务通常很小，能够随着零碎整体负载的变动更快地启动和进行。架构降级灵便：单个微服务的“外部架构”能够迅速降级，因为微服务之间涣散耦合，只面向定义好的通信接口进行编程。这使开发团队可能基于本身的技术背景和偏好灵便抉择，而不会间接影响其余应用程序、服务或团队。更好的容错性：微服务之间能够实现更好的故障隔离，单个服务内的内存泄露等故障不容易影响其余服务，相比单体利用一个组件故障会拖垮整个零碎。然而微服务在施行过程中，也很容易遇到一些难点。如果微服务治理得不失当，反而有可能事与愿违，不仅不能享受到微服务架构带来的益处，反而会因为微服务带来的零碎复杂性，造成开发、运维部署的复杂度减少，进而影响开发迭代的速度，甚至影响零碎的整体稳定性，比方： 服务之间应用近程调用进行通信，这比过程内的间接调用简单很多。因为通信链路的复杂性，可能会呈现很多不确定的问题，会呈现近程调用不可用或者提早较高的状况，开发人员须要可能解决这些偶发问题，防止影响业务。随着业务的倒退，微服务之间的拓扑图开始变得复杂，排查问题变得艰难，搭建残缺的开发测试环境老本也越来越大。当性能波及到多个微服务模块时，迭代时须要审慎地协调多个开发团队的迭代排期，能力保障迭代可能按时交付，达到麻利开发的成果。因而， 微服务落地的胜利与否，很大水平上取决于是否很好的对这些微服务进行治理，对于传统的 Spring Cloud 利用，并没有提供开箱即用的服务治理机制，用户只能通过本人去实现 Spring Cloud 中的各种扩大点来实现服务治理。与其让用户费神费劲去本人写代码实现扩大点，不如 Spring Cloud Alibaba 间接来代替用户做这些事件，用户只需导入 Spring Cloud Alibaba 中的 starter，即可疾速给本人的 Spring Cloud 利用增加对应的微服务治理能力。 Spring Cloud Alibaba 新版本服务治理能力预览最新公布的 Spring Cloud Alibaba 2.2.10-RC1 新版本，基于社区 2.2.x 分支进行的构建公布，其中 2.2.10-RC1 版本通过首次给 Spring Cloud 生态带来了微服务治理能力，并给 Spring Cloud Alibaba 利用带来了 Proxyless Mesh 的能力，让 Spring Cloud Alibaba 利用更好的拥抱服务网格。具体的新版本预览内容如下： 2.2.10-RC1 是在 Spring Cloud Hoxton.SR12、Spring Cloud 2.3.12.RELEASE 的根底上，反对 Istio 以及 OpenSergo 管制面下发的服务治理规定，对 Spring Cloud 生态中的 Ribbon 负载均衡器以及 Spring MVC, Spring WebFlux 的各种拦截器做了加强，实现了服务治理的局部能力，属于一个重大个性公布的新版本 [ 1] 。 ...

作者：孤戈 最近一年来，随着咱们的客户对于云技术的诉求从资源疾速交付的服务，转变为对资源精益使用的服务。EDAS 团队联合公共云上所服务的企业类客户的几万个利用，选取了 8 个最具代表性的指标，进行了一次系统性的剖析整顿和总结，心愿能够给以后正在从事软件架构的从业人员一个侧面的视角，来理解一些当下产生在身边的技术景象。 报告内容JDK 版本散布 解读在 JDK 9 之前，JDK 基本上均匀每三年出一个版本。然而自从 2017 年 9 月分推出 JDK9 到当初，JDK 开始了疯狂更新的模式，基本上放弃了每年两个大版本的节奏。到当初曾经公布了十个版本到 JDK 19。其中包含了两个 LTS 版本（JDK11 与 JDK17）。除了版本更新节奏显著放慢之外，JDK 也围绕着云原生场景的能力，推出了一系列诸如容器内资源动静感知、无进展 ZGC、云原生平安等方面的能力。不过从 EDAS 中的数据也能够看出，目前大部分的用户目前次要停留在 JDK8 上，近一年能看得出大家无意识的在往高版本上聚拢。这里情谊揭示一下，JDK8 的确是最为经典的一个版本，然而他的推出曾经是八年前，官网的反对与更新也曾经进行一段时间，倡议大家尽快降级到比拟新的 LTS 版本。如果的确因为客观原因无奈降级的用户，也倡议应用阿里巴巴开源的收费的 JDK 版本 DragoonWell ，可取得无差别的兼容能力。 微服务框架散布 解读服务框架是微服务体系中最为重要的一个技术组件，在业务开始之初确定选型之后，基本上会随同整个业务的生命周期，直至业务呈现大范畴重构。HSF 是阿里巴巴外部应用最为宽泛的一个服务框架，整个电商零碎都围绕 HSF 进行构建，EDAS 产品化之后，HSF 也追随商业化节奏输入到了很多的国计民生的业务中。到起初咱们重启了 Dubbo 的开源，Dubbo 以优雅的设计，丰盛的扩大能力，和性能强劲的通信框架取得了程序员的宽泛认可。在起初的云原生席卷之下，有越来越多的客户开始抉择了 Spring Cloud + Kubernetes 这一状态作为架构选型上的默认搭配。云原生下另一被认为是将来的微服务架构是 Service Mesh，它以语言无侵入的设计，交融全流程的流量治理能力推出之初就足够惊艳，然而任何技术都不会相对的完满，近几年微服务框架是 Fast SDK 还是 Mesh 的争执也始终在进行。在目前咱们察看到的景象来看，这一理念曾经被越来越多的客户承受，但落地场景目前大部分还是存量异构业务架构的通信能力上。从技术成熟度曲线来看，Mesh 行将往成熟期迈进。 云资源状态散布 解读在公共云上 EDAS 一共反对虚拟机 ECS、Kubernetes 与  Serverless 三种状态，从数据上看，随着 Kubernetes 成为微服务架构状态下的默认抉择，Kubernetes 利用的占比第一年超过ECS，从去年的 45% 攀升至 67%。另外随着大家对于降本诉求显著减少，Serverless 以低资源碎片、免运维全托管、随用随弹的个性，变得越来越风行。阿里云本身的云产品也很多都在以 Serverless 的状态进行从新托管，而微服务以无状态的属性，和 Serverless 的弹性更加的符合。针对存量利用曾经是 Kubernetes 集群的场景，EDAS 也反对以原有资源为根底，应用 Serverless 资源承载弹出来的负载的混合资源调度形式。也加强了以利用为维度将微服务和 Serverless 的技术交融，可使原有利用在无需任何革新和迁徙的状况下取得 Serverless 的技术红利。 ...

作者：翼严 Nacos 简介 Nacos 是一个更易于构建云原生利用的微服务根底平台，外围蕴含动静服务发现，配置管理，服务治理平台。 配置管理是 Nacos 的外围性能，它提供了运行期不重启利用的状况下动静批改配置值的性能。 Nacos 配置核心倒退历程 Nacos 配置核心是从阿里团体内配置核心 Diamond 孵化而来，其整体倒退分为三个阶段： 1.阿里团体外部孵化期nacos 配置核心诞生于阿里巴巴团体外部的配置核心 Diamond，后期次要服务于团体外部对动静配置的需要。 2.开源&商业化摸索尝试团体 Diamond 经验了从开源再到闭源的过程，公布了商业化产品 ACM，并在 2018 年以 Nacos 配置核心为载体再次开源，期间对配置核心的开源及商业化进行了摸索。 3.三位一体交融倒退明确三位一体倒退策略，以开源 Nacos 为内核，插件化反对团体 Diamond &商业化 MSE 定制的配置核心，三位一体交融倒退。 开源：以开源 Nacos 2.0 为内核，重构通信协议，性能扩展性晋升10倍，反对 10w 级实例规模，晋升开放性，联结开源微服务生态独特倒退。 商业化：反对 Nacos2.0 和专业版，目前 20% 用户降级到 Nacos2.0，并且反对配置鉴权和加密能力，推送轨迹等高级性能。 团体：关注性能和高可用能力，反对大促 1 小时建站，10 分钟反对响应；实现 Diamond Over Nacos2.0 架构演进，扩展性晋升 1 倍，反对 500w 实例规模。 利用场景&双十一实际Nacos 配置管理利用场景 配置核心在业务域，根底技术域都有着宽泛的利用，包含业务利用的开关，微服务生态的服务路由及元数据，高可用生态的预案，切流规定及降级开关等，前端生态的各类文案布告，数据库生态的外围配置参数，动静切库等配置。 在每年阿里团体的双十一大促中，配置核心也是一个不可或缺的根底组件，包含后期热点商品推送，大促气氛流动标调整，大促期间数据库主备切换开关，外围性能降级，各类名单调整，预案限流调整，各种根底中间件的外围参数动静，大促完结后各类预案的复原，大促态到日常态的状态切换，都是配置核心所反对的场景。 配置核心应用指引1.配置核心原理 业务利用：nacos 的应用方，通过 nacos-client 实现配置的公布，查问，监听回调的等根底操作。负载平衡 SLB：与后端的 nacos 服务节点进行交互的地址，在用户自建或者调试的场景下，也能够采纳直连 IP 或者地址服务器 endpoint 的模式。Nacos Server：nacos 服务端存储以后集群全量配置的内存和磁盘缓存，集群节点之间进行程度告诉配置变更事件，和后端数据库进行对账保证数据一致性。Nacos 控制台：治理控制台，能够进行配置查看，配置公布，监听查问等运维性能。商业化 Nacos 反对推送轨迹，监控，事件核心等高级性能。数据库：配置长久化存储的数据库，个别是主备库架构进行容灾。用户在接入 nacos 次要有两种模式，一种是通过原生 nacos-client 的 ConfigService 组件的根底 API 接入，第二种是通过 Spring 框架或者其余相似框架组件接入，包含 SpringCloud 和 SpringBoot 等。 ...

作者：昶风 阿里云音讯队列 RocketMQ 版是阿里云基于 Apache RocketMQ 构建的低提早、高并发、高可用、高牢靠的分布式“音讯、事件、流”对立解决平台，面向互联网分布式应用场景提供微服务异步解耦、流式数据处理、事件驱动解决等外围能力。其自诞生以来始终为阿里团体提供稳固牢靠的音讯服务，历经多年双十一万亿级流量洪峰的验证。 随着业务需要场景日渐丰盛，在多年教训积攒后，阿里云 RocketMQ 也迎来了革命性的更新，正式公布了阿里云音讯队列 RocketMQ 版 5.0，在架构、网络、负载平衡、存储等诸多方面进行了显著优化。其定位不再局限于音讯解耦场景，将全新布局事件驱动和音讯流式解决场景。 阿里云 EventBridge 作为云上事件枢纽始终以来都放弃着对云上事件、数据的敌对生态反对。随着 RocketMQ 5.0版本的用户日渐增多，EventBridge 在近期对 RocketMQ Connector 进行了全面降级。降级之后的 RocketMQ Connector 不仅能够反对RocketMQ 5.0 版本，同时也能反对云上自建 RocketMQ 实例。除此之外，基于成熟的事件流能力，用户应用 EventBridge 也能轻松构建音讯路由能力，实现对灾备、数据同步的需要。 本文将从业务架构和 API 应用等方面解说如何应用 EventBridge 创立阿里云 RocketMQ 4.0、5.0 版本，开源自建版本以及音讯路由的相干工作。 EventBridge-RocketMQ 4.0业务架构RocketMQ 4.0 版本应用较为经典的 client-nameserver-broker 架构，整个利用次要由生产者、消费者、NameServer 和 Broker 组成。 Name Server：是一个简直无状态节点，可集群部署，在音讯队列 RocketMQ 版中提供命名服务，更新和发现 Broker 服务。Broker：音讯直达角色，负责存储音讯，转发音讯。分为 Master Broker 和 Slave Broker，一个 Master Broker 能够对应多个 Slave Broker，然而一个 Slave Broker 只能对应一个 Master Broker。Broker 启动后须要实现一次将本人注册至 Name Server 的操作；随后每隔 30s 定期向 Name Server 上报 Topic 路由信息。生产者：与 Name Server 集群中的其中一个节点（随机）建设长连贯（Keep-alive），定期从 Name Server 读取 Topic 路由信息，并向提供 Topic 服务的 Master Broker 建设长连贯，且定时向 Master Broker 发送心跳。消费者：与 Name Server 集群中的其中一个节点（随机）建设长连贯，定期从  Name Server 拉取 Topic 路由信息，并向提供 Topic 服务的 Master Broker、Slave Broker 建设长连贯，且定时向 Master Broker、Slave Broker 发送心跳。Consumer 既能够从 Master Broker 订阅音讯，也能够从 Slave Broker 订阅音讯，订阅规定由 Broker 配置决定。EventBridge在获取用户受权之后，利用生成的 sts 长期受权对客户的  RocketMQ 实例进行音讯读取或写入。 ...

作者：子葵 背景线上 flink 用户应用 ZooKeeper 做元数据中心以及集群选主，一些版本的 flink 在 ZooKeeper 选主时，会重启 Job，导致一些非预期的业务损失。而 ZooKeeper 在 zxid溢出时，会被动触发一次选主，就会导致 flink Job 的非预期重启，造成业务损失。本篇从原理和最佳实际上剖析和解决因为 ZooKeeper zxid 溢出导致的集群选主问题。查看 ZooKeeper Server 日志呈现。 zxid lower 32 bits have rolled over, forcing re-election, and therefore new epoch start解决办法ZooKeeper 自身提供以后解决的最大的 Zxid，通过 stat 接口可查看到以后解决的最大的 zxid 的值，通过此值能够计算以后 zxid 间隔溢出值还有多少差距。MSE 提供风险管理以及集群选主相干告警，提前预防和及时感知选主危险，防止业务损失。 通过 MSE ZooKeeper 风险管理和集群选主工夫告警，预知危险。MSE ZooKeepr 提供风险管理的能力，风险管理会定期扫描集群危险，告诉用户，zxid 溢出就是集群的危险之一，当 zxid 靠近溢出值之前，通过风险管理对危险的扫描，就能够看到集群zxid溢出的危险，提前做好躲避。 风险管理会每天扫描集群的各项危险，也能够通过手动触发 一键健康检查进行集群危险诊断。 同时通过 MSE ZooKeeper 的集群选主工夫告警，能够检测集群的选主工夫，防止因为集群选主工夫过长导致业务损失。通过告警治理中创立 MSE 告警规定进行集群选主工夫的告警设置。 起因剖析什么是zxid，它是怎么产生的？首先咱们理解一下什么是 zxid，它是怎么产生的：zxid 是 ZooKeeper 中一个事务的全局惟一 id，通过 zxid 形容各个事务之间的全序关系。客户端对 ZooKeeper 外部数据的变更都是通过事务在 ZooKeeper 集群内的流传和解决实现的，因而 zxid 就是客户端对数据进行一次变更所产生的事务在全局事务中的一个惟一 id，这个 id 形容了本次变更的事务在全局事务中的地位，并且不会有两个不同的事务领有雷同的 zxid（全序关系）。 ...

本系列文章由余凯执笔创作，联结作者：阿里云容器服务 谢石 对本文亦有奉献 近几年，企业基础设施云原生化的趋势越来越强烈，从最开始的IaaS化到当初的微服务化，客户的颗粒度精细化和可观测性的需要更加强烈。容器网络为了满足客户更高性能和更高的密度，也始终在高速的倒退和演进中，这必然对云原生网络的可观测性带来了极高的门槛和挑战。为了进步云原生网络的可观测性，同时便于客户和前后线同学减少对业务链路的可读性，ACK产研和AES联结共建，合作开发ack net-exporter和云原生网络数据面可观测性系列，帮忙客户和前后线同学理解云原生网络架构体系，简化对云原生网络的可观测性的门槛，优化客户运维和售后同学解决疑难问题的体验 ，进步云原生网络的链路的稳定性。 鸟瞰容器网络，整个容器网络能够分为三个局部：Pod网段，Service网段和Node网段。这三个网络要实现互联互通和访问控制，那么实现的技术原理是什么？整个链路又是什么，限度又是什么呢？Flannel， Terway有啥区别？不同模式下网络性能如何？这些，须要客户在下搭建容器之前，就要根据本人的业务场景进行抉择，而搭建结束后，相干的架构又是无奈转变，所以客户须要对每种架构特点要有充沛理解。比方下图是个简图，Pod网络既要实现同一个ECS的Pod间的网络互通和管制，又要实现不同ECS Pod间的拜访， Pod拜访SVC 的后端可能在同一个ECS 也可能是其余ECS，这些在不同模式下，数据链转发模式是不同的，从业务侧体现后果也是不一样的。 本文是[全景分析容器网络数据链路]第四局部局部，次要介绍Kubernetes Terway EBPF+IPVLAN模式下，数据面链路的转转发链路，一是通过理解不同场景下的数据面转发链路，从而探知客户在不同的场景下拜访后果体现的起因，帮忙客户进一步优化业务架构；另一方面，通过深刻理解转发链路，从而在遇到容器网络抖动时候，客户运维以及阿里云同学能够晓得在哪些链路点进行部署观测手动，从而进一步定界问题方向和起因。 系列一：全景分析阿里云容器网络数据链路（一）—— Flannel系列二：全景分析阿里云容器网络数据链路（二）—— Terway ENI系列三：全景分析阿里云容器网络数据链路（三）—— Terway ENIIP系列五：全景分析阿里云容器网络数据链路（五）—— Terway ENI-Trunking系列六：全景分析阿里云容器网络数据链路（六）—— ASM IstioTerway IPVLAN+EBPF 模式架构设计弹性网卡(ENI)反对配置多个辅助IP的性能，单个弹性网卡(ENI)依据实例规格能够调配6-20个辅助IP，ENI多IP模式就是利用了这个辅助IP调配给容器，从而大幅提高了Pod部署的规模和密度。在网络联通的形式上，Terway反对抉择Veth pair策略路由和ipvlan l两种计划，Linux在4.2以上的内核中反对了ipvlan的虚构网络，能够实现单个网卡虚构进去多个子网卡用不同的IP地址，而Terway便利用了这种虚构网络类型，将弹性网卡的辅助IP绑定到IPVlan的子网卡上来买通网络，应用这种模式使ENI多IP的网络结构足够简略，性能也绝对veth策略路由较好。 ipvlan： https://www.kernel.org/doc/Do... Pod 所应用的的CIDR网段和节点的CIDR是同一个网段 Pod外部能够看到是有一张网卡的，一个是eth0，其中eth0 的IP就是 Pod的IP，此网卡的MAC地址和管制台上的ENI的MAC地址不统一，同时ECS上有多张 ethx的网卡，阐明ENI从属网卡并不是间接挂在到了Pod的网络命名空间 Pod内有只有指向eth0的默认路由，阐明Pod拜访任何地址段都是从eth0为对立的出入口 那么Pod是如何ECS OS进行通信呢？在OS层面，咱们一看到ipvl_x的网卡，能够看到是从属于eth1的，阐明在OS层面会给每个从属网卡创立一个ipvl_x的网卡，用于建设OS和Pod内的连贯隧道。 ECS OS内对于数据流量是怎么判断去哪个容器呢？通过OS Linux Routing 咱们能够看到，所有目标是 Pod IP 的流量都会被转发到Pod对应的ipvl_x虚构往卡上，到这里为止，ECS OS 和Pod的网络命名空间曾经建设好残缺的出入链路配置了。到目前为止介绍了IPVLAN在网络架构上的实现。 对于eni多IP的实现，这个相似于《全景分析阿里云容器网络数据链路（三）—— Terway ENIIP》原理，Terway Pod是通过daemonset的形式部署在每个节点上的，通过上面命令能够看到每个节点上的Terway Pod。通过terway-cli show factory 命令能够看到节点上的从属ENI数量、MAC地址以及每个ENI上的IP 那么对于SVC来说，是如何实现的呢？看过后面 四个系列的敌人，应该晓得对于Pod拜访SVC，容器是利用各种方法将申请转发到Pod所在的ECS层面，由ECS内的netfilter模块来实现SVC IP的解析，这诚然是个好方法，然而因为数据链路须要从Pod的网络命名空间切换到ECS的OS的网络命名空间，两头通过了2次内核协定栈，必然会产生性能损失，如果对高并发和高性能有极致谋求，可能并不齐全满足客户的需要。那么对于高并发和提早敏感业务，该如何实现呢？有没有方法让Pod拜访SVC间接在Pod的网络命名空间中就实现了后端解析，这样联合IPVLAN这样至实现了一次内核协定栈。在4.19版本内核中，ebpf的呈现，很好的实现了这个需要，这里不对ebpf做过多阐明，感兴趣的能够拜访官网链接，小伙伴们只须要晓得ebpf是一种能够平安在内核层面运行的平安沙盒，当触发内核的指定行为，ebpf设定程序会被执行。利用这个个性，咱们能够实现在tc层面对拜访SVC IP的数据包进行批改。 官网链接： https://ebpf.io/what-is-ebpf/ ...

导读随着Stable Diffusion模型在AI圈的爆火，AI生成内容（AI Generated Content，AIGC）的利用呈现出井喷式的增长趋势。其中，文图生成（Text-to-image Generation）工作是最风行的AIGC工作之一，旨在生成与给定文本对应的图像。在先前的工作中，阿里云机器学习PAI团队开源了PAI-Diffusion系列模型（看这里），包含一系列通用场景和特定场景的文图生成模型，例如新诗配图、二次元动漫、魔幻事实等。这些模型的Pipeline除了包含规范的Latent Diffusion Model，还集成了PAI团队先前提出的中文CLIP跨模态对齐模型（看这里），及图像超分模型，使得模型能够生成合乎中文文本形容的、各种场景下的高清大图。因为在特定场景下，用户往往有对这些中文Diffusion模型调优（Fine-tune）的需要，而且在线上部署方面，因为Diffusion模型推理速度比较慢，而且须要消耗较多的硬件资源。在本次的工作中，咱们在EasyNLP算法框架中，对先前提出的PAI-Diffusion模型性能进行降级，全链路反对模型调优。在模型推理方面，联合由PAI自主研发的编译优化工具 PAI-Blade，反对对PAI-Diffusion模型的端到端的导出和推理减速，在A10机器下做到了1s内的中文大图生成。 本⽂首先介绍如何体验PAI-Diffusion模型以及其在线部署、减速推理能力。其次，咱们简略回顾了PAI-Diffusion模型的架构，之后具体介绍了在EasyNLP算法框架中对上述模型进行调优的全链路反对。 轻松体验PAI-Diffusion模型首先让咱们轻松体验PAI-Diffusion模型。 在线体验PAI-Diffusion模型能够用于各种格调的艺术画的生成。这个模型的参数量仅10亿，应用一张P100 GPU显卡，就能够生成1024*1024的高清大图，示例如下。 咱们在AI模型开源社区ModelScope的创空间上线了咱们的一个PAI-Diffusion模型（体验链接），欢送宽广用户体验。 PAI-Diffusion模型架构回顾咱们简略回顾一下PAI-Diffusion模型的技术架构。简略的说，PAI-Diffusion模型是面向中文的、基于隐式扩散模型（Latent Diffusion Model, LDM）的文图生成模型。因为中英文在文化和表白上具备很大的差异性，产出的模型通常无奈建模中文特有的景象。PAI-Diffusion模型由阿里云机器学习（PAI）团队公布并开源，除了能够用于通用文图生成场景，还具备一系列特定场景的定制化中文Diffusion模型，包含新诗配图、二次元动漫、魔幻事实等。PAI-Diffusion的模型Pipeline架构，包含中文CLIP模型、Diffusion模型、图像超分模型等： 具体地说，中文CLIP模型把中文文本输出转化成 Embedding 向量，咱们采纳EasyNLP中文CLIP跨模态对齐模型（看这里）的Text Transformer作为Text Encoder。咱们把中文CLIP模型的输入作为LDM的输出，训练模型生成文本对应的图片。可选地，PAI-Diffusion模型链路中还集成了ESRGAN作为图像超分模型，晋升图片的分辨率。 PAI-Diffusion模型减速推理技术 PAI-Blade 采纳多种模型编译优化技术，能够对基于Tensorflow/Pytorch 训练的模型进行推理优化减速。 针对基于PAI-EasyNLP的 PAI-Diffusion模型 和社区的Stable-Diffusion模型的推理进行测速剖析，针对推理的次要局部，引入了编译优化和flashattention的推理减速技术，胜利将整个推理链路均匀提速75%以上，具体减速比视推理步数略有不同，具体能够参考下表（测试推理机器 Nvidia-A10，输入图片分辨率 512x512）： 综上能够看到， 引入PAI自主研发的模型推理减速工具Blade 能大幅度晋升DiffusionModel的推理速度，升高服务提早，节俭计算资源。 PAI-Diffusion模型的微调和微调后模型部署在本次更新中，咱们在PAI-EasyNLP算法框架对PAI-Diffusion模型的调优做了全面反对。咱们介绍如何在PAI-Diffusion模型的训练流程，以及如何在PAI的产品中部署上述微调后的模型用于在线服务。 装置EasyNLP用户能够间接参考链接的阐明装置EasyNLP算法框架。 数据筹备首先筹备训练数据与验证数据，为tsv文件。这⼀⽂件蕴含以制表符\t分隔的三列（idx, text, imgbase64），第一列是文本编号，第二列是文本，第三列是对应图片的base64编码。样例如下： 64b4109e34a0c3e7310588c00fc9e157 韩国可恶日系袜子女中筒袜春秋薄款纯棉学院风街头卡通兔子长袜潮 iVBORw0KGgoAAAAN...MAAAAASUVORK5CYII=为了不便开发者，咱们也提供了转换图片到base64编码的示例代码： import base64from io import BytesIOfrom PIL import Imageimg = Image.open(fn)img_buffer = BytesIO()img.save(img_buffer, format=img.format)byte_data = img_buffer.getvalue()base64_str = base64.b64encode(byte_data) # bytes下列文件曾经实现预处理，可用于测试： ...

点击此处查看可观测产品大促专场

作者：可观测团队 什么是性能压测可观测如果说2022年最热的运维话题，非可观测莫属。可观测性从传统监控场景一直延长，逐步笼罩 Metrics、Traces、Logs 三个维度并将之互相交融，可观测性帮忙企业在简单的分布式系统中更加疾速的排查、定位问题，是分布式系统中必不可少的运维工具。 在性能压测畛域中，可观测性更为重要，除了有助于定位性能问题，其中 Metrics 性能指标更间接决定了压测是否通过，零碎最终是否能够上线，具体如下： Metrics - 监控指标零碎性能指标，包含申请成功率、零碎吞吐量、响应时长资源性能指标，掂量零碎软硬件资源应用状况，配合零碎性能指标，察看系统资源水位Logs - 日志施压引擎日志，察看施压引擎是否衰弱，压测脚本执行是否有报错采样日志，采样记录API的申请和响应详情，辅助排查压测过程中的一些出错申请的参数是否失常，并通过响应详情，查看残缺的错误信息Traces - 分布式链路追踪用于性能问题诊断阶段，通过追踪申请在零碎中的调用链路，定位报错 API 的报错零碎和报错堆栈，疾速定位性能问题点。 本篇论述如何应用 Prometheus 实现性能压测 Metrics 的可观测性。 压测监控外围指标压测过程中，对系统硬件、中间件、数据库资源的监控也很重要，包含零碎性能指标、资源指标、中间件指标、数据库指标、前端指标、稳定性指标、批量解决指标、可扩展性指标、可靠性指标等。 零碎性能指标交易响应工夫定义及解释响应工夫指用户从客户端发动一个申请开始，到客户端接管到从服务器端返回的响应完结，整个过程所消耗的工夫。在性能检测中个别以压力发动端至被压测服务器返回处理结果的工夫为计量，单位个别为秒或毫秒。均匀响应工夫指零碎稳固运行时间段内，同一交易的均匀响应工夫。一般而言，交易响应工夫均指均匀响应工夫。均匀响应工夫指标值应依据不同的交易别离设定，个别状况下，分为简单交易响应工夫、简略交易响应工夫、非凡交易响应工夫。其中，非凡交易响应工夫的设定必须明确该交易在响应工夫方面的特殊性简称 Response Time: RT参考规范不同行业不同业务可承受的响应工夫是不同的，个别状况，对于在线实时交易：对于批量交易：互联网企业：500 毫秒以下，例如淘宝业务 10 毫秒左右金融企业：1 秒以下为佳，局部简单业务 3 秒以下保险企业：3 秒以下为佳制造业：5 秒以下为佳工夫窗口：即整个压测过程的工夫，不同数据量则工夫不一样，例如双 11 和 99 大促，数据量级不一样则工夫窗口不同。大数据量的状况下，2 小时内可实现压测零碎解决能力定义及解释零碎解决能力是指零碎在利用零碎硬件平台和软件平台进行信息处理的能力。零碎解决能力通过零碎每秒钟可能解决的交易数量来评估，交易有两种了解：一是业务人员角度的一笔业务过程；二是零碎角度的一次交易申请和响应过程。前者称为业务交易过程，后者称为事务。两种交易指标都能够评估利用零碎的解决能力。个别的倡议与零碎交易日志保持一致，以便于统计业务量或者交易量。零碎解决能力指标是技术测试流动中重要指标简称个别状况下，用以下指标来度量：HPS（Hits Per Second） ：每秒点击次数，单位是次/秒TPS（Transaction per Second）：零碎每秒解决交易数，单位是笔/秒。QPS（Query per Second）：零碎每秒解决查问次数，单位是次/秒。对于互联网业务中，如果某些业务有且仅有一个申请连贯，那么 TPS=QPS=HPS，个别状况下用 TPS 来掂量整个业务流程，用 QPS 来掂量接口查问次数，用 HPS 来示意对服务器单击申请规范无论 TPS、QPS、HPS，此指标是掂量零碎解决能力十分重要的指标，越大越好，依据教训，个别状况下：金融行业：1000 TPS~50000 TPS，不包含互联网化的流动保险行业：100 TPS~100000 TPS，不包含互联网化的流动制作行业：10 TPS~5000 TPS互联网电子商务：10000 TPS~1000000 TPS互联网中型网站：1000 TPS~50000 TPS互联网小型网站：500 TPS~10000 TPS并发用户定义及解释并发用户数指在同一时刻内，登录零碎并进行业务操作的用户数量。并发用户数对于长连贯零碎来说最大并发用户数即是零碎的并发接入能力。对于短连贯零碎而言最大并发用户数并不等于零碎的并发接入能力，而是与零碎架构、零碎解决能力等各种状况相干。例如零碎吞吐能力很强，加上短连贯个别都有连贯复用，往往并发用户数大于零碎的并发接入连接数。所以对于大部分短连贯类型的零碎，吞吐量模式（RPS模式，Request Per Second）比拟适宜，也是阿里的最佳实际，PTS 反对 RPS 模式的压测，吞吐量的压测构建和掂量一步到位。在测试中，采纳虚构用户来模仿事实中用户进行业务操作简称 Virtual User：VU规范个别状况下，性能测试是将零碎解决能力容量测进去，而不是测试并发用户数，除了服务器长连贯可能影响并发用户数外，零碎解决能力不受并发用户数影响，能够用最小的用户数将零碎解决能力容量测试进去，也能够用更多的用户将零碎解决能力容量测试进去错误率定义及解释错误率指零碎在负载状况下，失败交易的概率。错误率＝（失败交易数/交易总数）×100%。稳定性较好的零碎，其错误率应该由超时引起，即为超时率。简称 Virtual Failure Ratio：FR: VU规范不同系统对错误率的要求不同，但个别不超出千分之六，即成功率不低于 99.4%资源指标CPU定义及解释中央处理器是一块超大规模的集成电路，是一台计算机的运算外围（Core）和管制外围（ Control Unit）。它的性能次要是解释计算机指令以及解决计算机软件中的数据。CPU Load：零碎正在干活的多少的度量，队列长度。零碎均匀负载简称 Central Processing Unit：CPU规范 CPU 指标次要指的 CPU 使用率、利用率，包含用户态（user）、零碎态（sys）、期待态（wait）、闲暇态（idle）。CPU使用率、利用率要低于业界戒备值范畴之内，即小于或者等于 75%、CPU sys%小于或者等于 30%，CPU wait% 小于或者等于 5%。单核 CPU 也需遵循上述指标要求。CPU Load 要小于CPU核数Memory定义及解释内存是计算机中重要的部件之一，它是与 CPU 进行沟通的桥梁。计算机中所有程序的运行都是在内存中进行的，因而内存的性能对计算机的影响十分大简称 Memory 就是内存的简称规范古代的操作系统为了最大利用内存，在内存中寄存了缓存，因而内存利用率 100% 并不代表内存有瓶颈，掂量零碎内有瓶颈次要靠 SWAP（与虚拟内存替换）替换空间利用率，个别状况下，SWAP 替换空间利用率要低于 70%，太多的替换将会引起零碎性能低下磁盘吞吐量定义及解释磁盘吞吐量是指在无磁盘故障的状况下单位工夫内通过磁盘的数据量简称 Disk Throughput规范磁盘指标次要有每秒读写多少兆，磁盘忙碌率，磁盘队列数，均匀服务工夫，均匀等待时间，空间利用率。其中磁盘忙碌率是间接反映磁盘是否有瓶颈的重要依据，个别状况下，磁盘忙碌率要低于 70%网络吞吐量定义及解释网络吞吐量是指在无网络故障的状况下单位工夫内通过的网络的数据数量。单位为 Byte/s。网络吞吐量指标用于掂量零碎对于网络设备或链路传输能力的需要。当网络吞吐量指标靠近网络设备或链路最大传输能力时，则须要思考降级网络设备简称 Network Throughput规范网络吞吐量指标次要有每秒有多少兆流量进出，个别状况下不能超过设施或链路最大传输能力的 70%中间件指标定义及解释罕用的中间件例如 Tomcat、Weblogic 等指标次要包含 JVM、ThreadPool、JDBC，具体如下： ...

随着云原生利用微服务化、Serverless 化，用户须要面对简单业务路由规定配置，保障服务拜访的安全性以及流量的可监控、可观测性。阿里云 ALB Ingress 基于应用型负载平衡 ALB（Application Load Balancer） 之上提供更为弱小的 K8s Ingress 流量治理形式。除了反对根本的路由治理、多种拜访协定之外，还反对跨域、重写、日志拜访、自定义转发规定、平安加强等更高级的能力。 2023年 1 月 11 日（周三）15:00--16:00， 阿里云开发工程师，李宇曈（遐宇）、阿里云高级开发工程师，刘晓冬（晓冬） 将为您具体介绍 ALB Ingress 的高级个性。 本次直播还将在阿里巴巴云原生视频号、阿里云原生 B 站直播间播出，敬请关注~ 直播介绍直播主题原生利用网关进阶：ALB Ingress 高级个性介绍 直播工夫2023 年 01 月 11日（周三）15:00 —16:00 直播嘉宾 阿里云开发工程师，李宇曈（遐宇） 阿里云高级开发工程师，刘晓冬（晓冬） 精彩速递● 什么是 ALB Ingress ● ALB Ingress 高级个性 跨域、重写、灰度公布、日志拜访 自定义转发规定、平安个性加强立即扫码锁定本场直播 点击此处或扫描海报二维码锁定本场直播

作者：全新登程的阿里云云原生

作者：容器服务团队 云上大数据的 Kubernetes 技术路线以后，大数据与机器学习畛域颇为关注存储与计算拆散架构，逐步向云原生演进。以Spark 为例，云下或自有服务器能够抉择 Hadoop 调度反对 Spark，云上的 Spark 则会思考如何充沛享有公共云的弹性资源、运维管控和存储服务等，并且业界也涌现了不少 Spark on Kubernetes 的优良实际。 大数据云原生化面临的挑战存储和计算拆散的架构，同时又带来挑战，例如：怎么构建以阿里云对象存储 OSS 为底座的 HDFS 文件系统？须要齐全兼容现有的 HDFS，还要实现在性能对标 HDFS的同时降低成本；计算引擎 shuffle 数据存算拆散，又要思考如何解决 ACK 混合异构机型的反对问题，以及业界十分关注如何反对 Spark 动静资源。 引入 Kubernetes 之后， 如何调度优化性能瓶颈？性能对标 Yarn、实现多级队列治理。还有，如何借助 K8s，编排组织各种业务的波峰波谷，实现错峰调度？等等。 通过阿里云容器服务 ACK 运行开源大数据工作，将以集群为核心的视角切换成以作业为核心视角，还能够实现在线业务、AI、大数据对立接入 ACK 集群，错峰调度，离线在线混部，晋升机器利用率。并且，实现了运维入口、运维工具链、监控体系的三重对立。此外，还反对多版本，如同时运行 Spark2.x 和 Spark 3.x 工作。 EMR on ACK 的架构与劣势12月，阿里云 EMR 2.0 正式公布，从平台体验、数据开发、资源状态、剖析场景等方面实现全面翻新。其中在资源状态侧，EMR 能够部署在阿里云容器服务 ACK 平台， 缩小对底层集群资源的运维投入，以便于用户更加专一大数据工作自身。 EMR on ACK 为用户提供了全新的构建大数据平台的形式，用户能够将开源大数据服务部署在阿里云容器服务（ACK）上。利用 ACK 在服务部署和对高性能可伸缩的容器利用治理的能力劣势，用户只须要专一在大数据作业自身。用户能够便捷地将 Spark、Presto、Flink 作业执行在 ACK 集群上，100%兼容开源，性能优于开源。 EMR on ACK 架构如下 轻量化管控，对接已有数据平台通过数据开发集群/调度平台提交到不同的执行平台错峰调度，依据业务顶峰低峰策略调整云原生数据湖架构，ACK 弹性扩缩容能力强ACK 治理异构机型集群，灵活性好EMR on ACK 具备以下劣势Remote Shuffle Service 提供两头 shuffle 数据的存储计算拆散计划能够使计算节点无需本地盘和云盘反对关上 Spark 动静资源性能，Spark-25299 终极计划JindoFS 针对 OSS 存储提供湖减速解决方案Block 模式1TB TPCDS 场景下有15%以上的性能晋升调度层面反对 Scheduler Framework V2调度性能比社区晋升3x以上提供多级队列治理引擎能力加强10TB TPCDS Benchmark 场景下，EMR Spark 比社区有3x性能晋升Hudi、DeltaLake 比社区性能性能加强残缺的错峰调度计划国内出名广告营销服务商汇量科技已应用 EMR 产品4年。在业务快速增长的大好形势下，汇量科技面临越来越多的困扰：如数据起源简单、数据量大、数据维度多、实时经营业务秒级数据新鲜度需要等业务需要；本次降级后，汇量科技在素材平台、热力引擎等业务的大数据平台搭建上，数据同步和及查问效率有数倍晋升，零碎稳定性显著晋升，未再呈现之前cpu、mem、io负载低等状况。 ...

在进入千禧年后，随着计算机技术的倒退和业务翻新的不断涌现，许多大公司内的 IT 计算中心也在酝酿着改革。一方面，各部门绝对独立的 IT 治理平台曾经难以满足日益增长和一直变动的计算治理需要；另一方面，IT 计算中心也越来越多的成为业务翻新的发源地，从一个老本核心向营收起源倒退。相应的，一种围绕着资源和负载治理平台的技术畛域逐步称为学术界和产业界的热点。它在不同的倒退阶段和不同的利用场景有着不同的名字，从最早的集群（Cluster），网格（Grid），到起初的数据中心操作系统（DCOS），云计算（Cloud Computing）。同时，在资源管理和负载治理这两大方面也一直的拓展着本身的边界。 目前，以 Kubernetes 为外围代表的云原生技术逐步称为这一畛域的支流。它所带来的不可变基础设施，以资源为治理对象，描述性的 API，最终一致性等等理念，不仅扭转了平台使用者的习惯，可能更好的在资源弹性变动的环境中放弃业务拜访的连续性；更扭转了服务和利用研发人员的思维模式，逐步以这种云原生的形式来设计和开发，进步翻新效率。 阿里云有“公共云”、“专有云”两种产品状态，应用同样基于飞天操作系统的技术路线，为用户提供从服务器开始一整套资源和负载的治理能力，以及运行在下面的各种服务。与此同时，也有很多客户因为种种原因无奈齐全应用私有云服务，也无奈洽购和部署一整套大专。在基于云原生的产品畛域中，这些客户或者接触了 Kubernetes 等开源我的项目，或者试用过红帽，Rancher 等厂商提供的 Openshift，Rancher 等平台产品，甚至体验了围绕这些产品形成的整个产品家族生态，如 IBM Cloud Pak 等。他们惊喜与这些云原生技术带来的麻利，凋谢，韧性等特点。同时，也心愿在此基础上取得反对不同业务场景的丰盛服务，以便疾速晋升创新能力。 应答这种需要，云原生 PaaS 团队通过长时间的技术和教训积攒，历时近半年的研发，创立了 CNStack 2.0 云原生技术中台产品。在接下来的内容里，将分享在 CNStack 2.0产品，架构，研发中次要的设计思维和心得体会。 产品指标阿里云应用云原生技术在资源和负载治理这一畛域的摸索曾经有一段历史了。在长期与解决方案团队，产品团队，内部客户的沟通单干中，发现使用者对云原生技术带来的以下特点最为关注。 麻利麻利并不简略的等同于轻量，它更多的代表灵活性和因而而带来的效率的晋升。 用户心愿平台和服务可能随着不同的利用场景和规模，提供不同的部署配置选项。既可能治理三五台服务器，提供一两种服务或者公共负载类型，也可能治理百台服务器，满足几个业务团队的不同诉求，甚至治理数千上万台服务器，逾越多个地区，反对不同行业线的简单服务。 针对这些场景和规模的差别，用户须要的只是做好资源布局，在部署平台和服务时，抉择不同的配置选项。无论场景和规模的差别，平台都会提供统一的应用体验。同时，所需的治理资源开销最好可能随着规模的增大和性能的减少，对数或者线性级别的增长。此外，用户也能够很不便的获取产品，不须要简单的硬件资源就能够部署和试用，例如私有云申请的服务器上，甚至是本人的笔记本电脑上。 麻利还体现在产品性能的组合和降级，能够依据须要，减少和缩小性能和服务，以响应一直变动的翻新诉求。 凋谢用户心愿能爱护已有的技术投资，也心愿能不便，疾速的补充开源社区或者其余厂商的技术创新。这就须要产品具备凋谢的特点。这里的凋谢次要是指采纳具备开源社区生命力的技术框架和规范的协定标准，产品本身也领有丰盛的扩大机制。 一个凋谢的产品，能够让用户 不便的获取技术材料和试用环境，升高学习门槛通过规范的协定标准和扩大机制，集成其余厂商的产品或者被其余厂商产品集成，爱护技术投资反对更多的基础设施类型和工作负载类型与开源社区一起一直倒退，放弃技术先进性生态技术中台作为业务翻新的外围，须要反对多种业务类型，涵盖业务翻新的生命周期。从微服务框架，中间件，到 AI，数据处理；从研发设计，制品治理，到利用公布，容灾高可用；从本地数据中心，到边缘，私有云。 为了反对如此丰盛的能力，须要围绕技术中台构建产品生态，创立云服务，云组件的标准规范和反对标准规范的工具链。 云服务：通过服务的模式在平台提供能力扩大，能够应用平台提供的用户，租户，鉴权，审计，许可证，多集群部署，UI 框架等根底能力，与平台既有能力或其余服务无缝的合作。和整个平台的运维一样，云服务的生命周期治理由管理员负责。云组件：通过部署申明的形式为平台用户提供软件的部署和运维，所部署的软件能够和用户自研软件一起编排实现业务流程。和用户自研软件一样，云组件的生命周期治理由具体的使用者负责。 上述是 CNStack 2.0 以后所反对的云服务一览。这些云服务与平台本身的公布齐全解耦，阿里云研发团队或者合作伙伴能够不便的针对业务场景扩大技术中台能力，独立公布云服务。须要重点强调的是，CNStack 平台本身也是以云服务形式开发，运维，治理的。 CNStack 2.0 为云服务和云组件的集成，测试和公布提供了一整套标准的工具链，它就是阿里云云原生利用交付平台（Application Delivery Platform，简称 ADP） [ 1] 。CNStack 2.0 本身也是应用 ADP 开发和公布的。 在 ADP 平台上，开发者能够将形成云服务的组件以 helm charts 的模式上传。平台依据研发标准扫描查看后，以自有组件的模式进行版本治理。尔后，开发者能够把这些自有组件和 ADP 平台上提供的公共研发中间件，如数据库，音讯，微服务框架等一起编排为云服务，并在指定的私有云环境创立验证环境，部署 CNStack 2.0（也被称为底座）一起实现功能测试和一系列验证，如高可用等，最终打包为云服务（或者云组件）。云服务（云组件）的公布包标准遵循云原生 PaaS 团队奉献给社区的 CNCF Sealer 开源我的项目。交付时，在用户环境部署的 CNStack 2.0 平台上，管理员将云服务（云组件）公布包导入能力核心。在能力核心，管理员能够实现云服务的部署，降级，变配等一系列生命周期治理。 ...

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

作者：合伯 本文次要向大家介绍如何利用 RocketMQ 可观测体系中的指标监控，对生产环境中典型场景：音讯沉积、音讯收发失败等场景配置正当的监控预警，疾速发现问题，定位问题。 RocketMQ 可观测体系作为一款典型的分布式中间件产品，RocketMQ 被广泛应用于业务外围链路中，每条音讯都关联着外围业务数据的变动。业务链路有其显著的复杂性： 生产者、消费者多对多：业务调用链路网状结构，上下游梳理艰难上下游解耦、异步链路：异步化调用，信息收集不残缺音讯是状态数据：未生产胜利、定时中等状态减少排查的复杂度音讯链路耦合简单的业务解决逻辑：无奈疾速定位问题边界鉴于音讯链路耦合业务零碎，简单带状态，RocketMQ 通过弱小的可观测零碎和教训撑持，及时发现问题、定位问题、解决问题有助于晋升运维效率，对于业务运行是一项重要的保障能力。 RocketMQ 的可观测体系次要由指标（Metrics）、轨迹（Tracing）和日志（Logging）组成。 指标RocketMQ中定义了具体的Metrics指标，这些指标笼罩生产者、消费者、服务端及音讯收发要害接口和流程的统计数据，并反对从实例、Topic和Group等多个维度进行聚合展现，帮忙您实时监控音讯业务或RocketMQ服务的运行状态。和4.x版本相比，RocketMQ服务端5.x版本减少了音讯沉积场景相干指标、要害接口的耗时指标、谬误散布指标、存储读写流量等指标，帮忙您更好地监控异样场景。 音讯轨迹在分布式应用中，RocketMQ作为全链路中异步解耦的要害服务，提供的Tracing数据可无效将业务上下游信息串联起来，帮忙您更好地排查异样，定位问题。和4.x版本相比，RocketMQ服务端5.x版本反对OpenTelemetry开源规范，提供更加丰盛的轨迹指标，针对生产场景、高级音讯类型场景等细化轨迹内容，为问题定位提供更多要害信息。 日志RocketMQ为不同的异常情况定义惟一的错误码及错误信息，并划分不同的谬误级别，您能够依据客户端返回的错误码信息疾速获取异样起因。和4.x版本相比，RocketMQ服务端5.x版本对立了ErrorCode和ErrorMessage，异样日志中减少了RequestID、资源信息，细化了错误信息，保障日志内容明确靠。 RocketMQ 监控告警介绍RocketMQ 联结阿里云云监控提供了开箱即用且收费的监控报警服务，可帮忙您解决如下问题： 实例规格水位监控预警若您理论应用的指标值超过实例的规格限度，RocketMQ会进行强制限流。提前配置实例规格水位告警能够提前发现规格超限危险并及时升配，防止因限流导致的业务故障。 业务逻辑谬误监控预警您在音讯收发时可能会收到异样报错，配置调用谬误告警能够提前在业务反馈前发现异常，帮忙您提前判断异样起源并及时修复。 业务性能指标监控预警如果您的音讯链路有相干性能指标要求，例如RT耗时、音讯提早等，提前配置业务指标告警能够帮忙您提前治理业务危险。 RocketMQ 版提供了丰盛的 Metric 指标和告警监控项。各监控项可分为运行水位、收发性能、异样谬误事件三类告警。依据大量生产环境实践经验，建议您依据以下准则配置如下告警 接下来重点通过音讯沉积和音讯收发失败这两个典型场景来论述基于可观测体系中的指标（Metrics），RocketMQ 如何通过云监控创立监控规定，将要害的 Metrics 指标作为告警项，帮忙您主动监控服务的运行状态，并主动发送报警告诉， 便于您及时预警服务的异样信息，进步运维效率。 利用场景1：音讯沉积问题音讯沉积指标及监控配置 业界通用指标：应用音讯沉积量（ready + inflight）来度量生产衰弱度，示意未解决实现的音讯量；局部产品额定减少已就绪音讯量来度量音讯拉取的及时性；应用上述 2 个指标间接来配置报警有以下毛病： 有误报或无奈触发报警的问题及时性的间接指标，不直观 RocketMQ 指标：额定反对延时工夫来度量生产衰弱度，涵盖了所有业务场景，依据业务容忍提早度间接配置工夫告警阈值。 音讯解决延迟时间：示意业务解决实现及时度已就绪音讯排队工夫：示意拉取音讯及时度倡议对音讯沉积敏感的用户，都在 RocketMQ 实例页的监控报警，增加如下报警指标，并设置合乎业务需要的阈值。 如何定位和解决沉积问题如果收到沉积报警，确认音讯呈现沉积状况，可参考以下措施进行定位和解决。 判断音讯沉积在 RocketMQ 服务端还是客户端查看客户端本地日志文件 ons.log，搜寻是否呈现如下信息：the cached message count exceeds the threshold呈现相干日志信息，阐明客户端本地缓冲队列已满，音讯沉积在客户端，请执行步骤2。若未呈现相干日志，阐明音讯沉积不在客户端，若呈现这种非凡状况，请间接提交工单分割阿里云技术支持。确认音讯的生产耗时是否正当若查看到生产耗时较长，则须要查看客户端堆栈信息排查具体业务逻辑，请执行步骤3。若查看到生产耗时失常，则有可能是因为生产并发度不够导致音讯沉积，须要逐渐调大生产线程或扩容节点来解决。音讯的生产耗时能够通过以下形式查看： 查看消费者状态，在客户端连贯信息中查看业务解决工夫，获取生产耗时的平均值。 查看客户端堆栈信息。只须要关注线程名为 ConsumeMessageThread 的线程，这些都是业务生产音讯的逻辑。客户端堆栈信息能够通过以下形式获取：查看消费者状态，在客户端连贯信息中查看 Java 客户端堆栈信息 应用 Jstack 工具打印堆栈信息。常见的异样堆栈信息如下： 示例一：生产逻辑有抢锁休眠期待等状况。生产线程阻塞在外部的一个睡眠期待上，导致生产迟缓。 示例二：生产逻辑操作数据库等内部存储卡住。生产线程阻塞在内部的 HTTP 调用上，导致生产迟缓。 ...

作者：在峰 MySQL 作为最风行的关系型数据库管理系统之一，十分多零碎的后端存储都有着MySQL 的身影，堪称是广泛应用于各行各业。与此同时，数据库作为应用服务的外围组件，间接影响着应用服务运行。数据库的瓶颈往往也是整个零碎的瓶颈，其重要性显而易见，所以对于 MySQL 的监控必不可少，及时发现 MySQL 运行中的异样，能够无效进步零碎的可用性和用户体验。因而，观测 MySQL 要害指标，实时关注数据库的可用性与性能，成为运维团队的重要工作。 要害指标解读在构建 MySQL 的指标观测体系前，咱们须要梳理在日常运维过程中所关注的维度与指标，做到对症下药。Google 提出系统监控的 Latency，Traffic，Saturation，Errors 作为黄金指标。而 MySQL 作为资源类服务零碎呈现，咱们将之进行细化，从可用性、数据库连贯、查问、流量、文件五大维度动手。 基于 Prometheus 的指标观测&告警体系搭建在设计好所需观测指标后，咱们就能够抉择相应的观测工具。作为最风行的数据库， MySQL 有着十分丰盛的监控工具抉择，比方 MySQL Enterprise Monitor、Prometheus等数据库自带、商业、开源不同属性的工具。 而云原生时代，为了开源敌对、防止厂商锁定、构建多云全栈可观测体系等企业级诉求，Prometheus 成为了 MySQL 指标监控的最佳抉择，并领有社区专门为采集 MySQL 数据库监控指标而设计开发的 MySQL Exporter 。 相较于自建 Prometheus，须要部署 Exporter、传入 MySQL 实例的连贯信息，配置服务发现，再建设大盘。阿里云 Prometheus监控一键集成 MySQL Exporter，并提供开箱即用的专属监控大盘、告警，将诸多配置与操作实现白屏化，尽可能简化配置服务接入工作量。 并基于阿里云本身实际，将常见的 MySQL 告警规定制作成预置模板，帮忙运维团队疾速搭建起指标看板与告警体系，不必再苦恼于提炼本身教训或告警指标的抉择上。 MySQL 停机：如果该指标值是 0 示意以后数据库未在失常运行，为 1 示意失常，能够通过 ${instance} 针对具体的实例告警；mysql_up{${instance}} != 1MySQL 实例运行时长：Prometheus 监控服务提供了默认的告警阈值，监控运行少于半小时的 MySQL 实例，用户能够依据本人的须要批改阈值；mysql_global_status_uptime{${instance}} < 1800MySQL 实例慢查问：该指标能够作为判断以后数据库是否存在 sql 语句须要优化等问题；rate(mysql_global_status_slow_queries{${instance}}[5m]) > 0MySQL 谬误连接数：连贯谬误是数据库中的次要谬误之一，通过 Prometheus 监控服务提供的告警规定，当触发告警时，用户可能承受谬误类型、查问次数等告警信息；rate(mysql_global_status_connection_errors_total{${instance}}[5m]) > 0MySQL 连贯使用率：当呈现时连贯谬误告警时，大部分起因是因为连接数有余，能够通过查看 MySQL 连贯使用率进一步排查问题。100 * mysql_global_status_threads_connected{${instance}} / mysql_global_variables_max_connections{${instance}} > 90注：当使用率达到肯定的阈值时，MySQL 实例开始回绝连贯，能够通过扩充连接数来解决问题。但在进步连接数之前，请务必通过以下语句查看以后零碎可关上的文件数： ...

在成为云计算新界面之后，智能化再次成为容器服务一个重要倒退方向。国内权威咨询机构Forrester在往年公布的《The Forrester WaveTM: Public Cloud Container Platforms, Q1 2022》报告中，阿里云位列寰球公共云容器平台「领导者」象限，这是中国云计算厂商首次进入该象限。 对于阿里云而言，这曾经不是其容器服务第一次闯入国内榜单，在此之前，阿里云容器服务（ACK）曾经间断多年入选 Gartner 公共云容器竞争格局，阿里云 ACK 的产品丰盛度与成熟度曾经显而易见。 2022 年是阿里云容器技术倒退的第十一年，也是在这一年，阿里云再次将容器服务带入智能化时代。 12 月 28 日，在第三届云原生实战峰会上，阿里云资深技术专家汤志敏分享了容器服务助力云原生稳定性的主题演讲，并介绍了容器 AIOps 套件，助力企业做好故障预防与定位。从 2015 年提供容器服务至今，阿里云如何布局与推动容器服务倒退，使其立于国内当先地位，咱们无妨回顾下容器的倒退历程。 阿里云铸「器」2010 年，在边远的大洋彼岸，几位 IT 技术男成立了一家名为 dotCloud 的公司，这家公司次要产品是一个 PaaS 平台，次要业务是为开发者提供技术服务，不过，在当年巨头环伺的云计算赛道，dotCloud 的日子并不好过，直到他们将本人的外围引擎进行开源。 2013 年 3 月，dotCloud 创始人 Solomon Hykes 向全世界发表开源外部我的项目 Docker，由此也就有了容器技术的十年热潮。 阿里巴巴第一个容器我的项目始于 2011 年，过后无论是 Docker，还是起初的 K8s（Kubernetes）这些国际标准都还在酝酿之中，整个行业尚处于前容器时代，那些具备远见的科技公司在触达容器畛域时是齐全靠自研，阿里这一年灰度上线的外部代号为 T4 的产品同样是集成了 LXC，并在内核上退出了资源可见性隔离的 patch，纯靠自研一手打造的容器我的项目。 T4 我的项目更多解决的是容器调度问题，也是阿里在容器技术畛域的一次技术尝试，阿里云容器服务（ACK）正式公测上线是在 2015 年年底，彼时阿里云 ACK 的大规模集群治理、容器集群编排技术曾经通过外部业务验证，开始对外提供技术服务。 汤志敏通知至顶网，“在阿里外部，新技术个别都会抉择先在外围业务落地，2015 年，阿里外围业务曾经开始转向容器化部署。” 2019 年，CNCF 在这年 8 月公布的调研报告中指出，在生产环境中的云原生利用和我的项目增长曾经超过了 200%；来自 Gartner 的预测数据也显示，到 2022 年将会有 75% 的全球化企业在生产中应用容器化利用。也是在这一年的阿里云栖大会上，汤志敏认为，“云原生拐点已至。” ...

本系列文章由余凯执笔创作，联结作者：阿里云容器服务 谢石 对本文亦有奉献 前言近几年，企业基础设施云原生化的趋势越来越强烈，从最开始的 IaaS 化到当初的微服务化，客户的颗粒度精细化和可观测性的需要更加强烈。容器网络为了满足客户更高性能和更高的密度，也始终在高速的倒退和演进中，这必然对客户对云原生网络的可观测性带来了极高的门槛和挑战。为了进步云原生网络的可观测性，同时便于客户和前后线同学减少对业务链路的可读性，ACK 产研和 AES 联结共建，合作开发 ack net-exporter 和云原生网络数据面可观测性系列，帮忙客户和前后线同学理解云原生网络架构体系，简化对云原生网络的可观测性的门槛，优化客户运维和售后同学解决疑难问题的体验 ，进步云原生网络的链路的稳定性。 鸟瞰容器网络，整个容器网络能够分为三个局部：Pod 网段，Service 网段和Node 网段。这三个网络要实现互联互通和访问控制，那么实现的技术原理是什么？整个链路又是什么，限度又是什么呢？Flannel， Terway 有啥区别？不同模式下网络性能如何？这些，须要客户在下搭建容器之前，就要根据本人的业务场景进行抉择，而搭建结束后，相干的架构又是无奈转变，所以客户须要对每种架构特点要有充沛理解。比方下图是个简图，Pod 网络既要实现同一个 ECS 的 Pod 间的网络互通和管制，又要实现不同 ECS Pod 间的拜访， Pod 拜访 SVC 的后端可能在同一个ECS 也可能是其余 ECS，这些在不同模式下，数据链转发模式是不同的，从业务侧体现后果也是不一样的。 本文是[全景分析容器网络数据链路]第三局部，次要介绍 Kubernetes Terway ENIIP 模式下，数据面链路的转转发链路，一是通过理解不同场景下的数据面转发链路，从而探知客户在不同的场景下拜访后果体现的起因，帮忙客户进一步优化业务架构；另一方面，通过深刻理解转发链路，从而在遇到容器网络抖动时候，客户运维以及阿里云同学能够晓得在哪些链路点进行部署观测手动，从而进一步定界问题方向和起因。 系列一： 全景分析阿里云容器网络数据链路（一）—— Flannel 系列二： 全景分析阿里云容器网络数据链路（二）—— Terway ENI 系列四： 全景分析阿里云容器网络数据链路（四）—— Terway IPVLAN+EBPF 系列五： 全景分析阿里云容器网络数据链路（五）—— Terway ENI-Trunking 系列六： 全景分析阿里云容器网络数据链路（六）—— ASM Istio Terway ENIIP模式架构设计弹性网卡 (ENI) 反对配置多个辅助 IP 的性能，单个弹性网卡 (ENI) 依据实例规格能够调配 6-20 个辅助 IP，ENI 多 IP 模式就是利用了这个辅助 IP 调配给容器，从而大幅提高了 Pod 部署的规模和密度。 ...

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

之前看过杨振宁的一个采访，说他最大的成就，不是取得了诺贝尔奖的钻研，而是之前的一个一般实践的钻研：他深信事物是遵循肯定法则的，不是大家认为的不可捉摸，花了7年工夫，陆陆续续，终于找到了一个很好的解释，并且侥幸的是，这个钻研后果能够笼罩十分多的场景。当我看到这个采访的时候，心田触动到的一个点是：尝试寻求表象背地的法则或者通用解释，是可能帮忙更多的人、产生更大的影响的，这也应该是咱们应该致力并保持的方向。 事物背地的法则“谁的青春不迷茫，谁的人生不徘徊”，迷茫和徘徊可能是咱们工作中常常会呈现的景象，而这些景象的背地，很重要的一个关键词是“成长”：新人该如何疾速落地？老人该如何继续冲破？是不是曾经做得很好，没法精进了？是不是，我永远都做不好？...... 本文心愿联合本人感悟谈谈对成长的思考。 成长与能力成长了解成长是一个过程。在这个过程中，可能会产生各种事件，有些是正向的，有些是负向的。这些事件会影响成长的速度与方向，体现到集体能力上。我是这么对待这个过程的： 【正向事件】：可能帮忙你能力减少的事件。 进入一个气氛好的团队：有很好的技能积攒，学会并熟练掌握，就能超过大部分同期间的人员。承接一个倒退快的业务：能够疾速实际与取得反馈，对认知造成冲击，造成较好地业务了解。遇到一个靠谱的师兄：仔细领导你的成长，给你解说很多疑难问题，帮忙你做到学而不惑，引领你做到触类旁通。找到一个欠缺的知识库：可能进行全面地了解，理解问题的前因后果，明确各种设计的衡量点。领有一个自我驱动的志愿：能够不受限于工作内容，进行额定学习，获取到更多的信息与常识。......【负向事件】：减缓你能力减少，甚至削弱的事件。 绩效谈崩了：不称心内部评估，既然干不好，那就躺平，导致没有很好地利用好工夫，蹉跎了岁月。搞了次故障：因为一次故障，对将来失去信念，放弃了长期耕耘的畛域，走上了切换的路线。找不到人交换：全靠本人推敲，没有输出，没有更好的了解，难以变得更好。身材受了伤：身材没爱护好，不能持续写代码了。......【冲破】：能力积攒超过预期。 短时间疾速成长：比方刚入职没多久，就能承接团队内的大部分事务。成长到难以代替：深度积攒、融汇贯通后，疑难问题能疾速解决，问题剖析能切中要害，这样的事件换集体，还真不肯定行。......【下限】：在肯定工夫内，依据教训判断，成长较快的人能达到的地位。 【上限】：个人或部门内靠后的水准，再往后可能也就被淘汰了。 日常纳闷如果有下面的一个形象认知，可能咱们日常的一些纳闷都能够想得比拟明确。上面会基于上述了解来尝试解释一下日常的纳闷： 【问】什么样的人是有后劲的？【答】不是相对能力强的，要看他继续成长的趋势，以及前面能给到的正向事件，是否撑持其成长到一个较高能力的阶段。 【问】为什么绩效比去年还低？【答】可能团队内有人遇到了更多正向事件，比方好的业务，或者本人开窍了，成长疾速，导致你的排名升高了。也可能你可怜地遇到了较多负向事件。 【问】为什么很多人入职没多久就到职了？【答】可能刚进来遇到的负向事件较多，感觉非但没成长，反而心里受到挫伤，影响将来工作状态。 【问】为什么有人不停地切换岗位？【答】因为他可能遇到了负向的事件，比方不靠谱的人和事，而且感觉没有改善的机会，只能动一动。 【问】为什么程序员35岁退休？【答】可能到35岁，工作中可能应用的正向事件曾经差不多了，须要你本人寻找输出，比方多看书，多看开源代码，如果你不做，能力就会处于停滞阶段，加上技术改革，就处于了倒退阶段，难以生存上来。 【问】转岗的时候到底在聊什么？【答】转岗大多是对能力成长或者能力排位不太称心。要么看前面有什么正向事件能够加大成长，要么缩小或改善一下以后的负向事件到一个可承受的境地。 继续疾速成长很多时候，能造成怎么的成长路线，都是命运使然的后果。但如果因而，就任其自然，那很多时候，即便致力地实现工作，也是中等的程度。是不是能够无意识地改善咱们的成长，至多在部分环境，获得一个较好的后果那？ 常说”抉择比致力更重要”，这个抉择不仅是大环境的抉择，更是集体态度和形式的抉择。抉择的前提应该是感性地剖析它，上面会联合成长过程的了解来看一下成长中的关键因素。 成长志愿成长开始的时候，根本都是适应主观要求：公司付你工资，你实现工作工作，工作工作的实现须要进行学习与成长。然而倒退一个阶段之后，大家成长的志愿就可能有差别了： 有些人，通过继续的好评反馈，产生了成就感，把成长当做实现自我价值的一个形式。有些人，喜爱那种形象简单问题，而后通过代码实现它，并看到程序按预期内运行的发明的高兴。有些人，可能过程不太顺利，也没收到比拟好的反馈，把成长当做雇佣关系中的一项工作工作。有些人，发现能够通过做事意识更多的人，积攒更多的资源，把成长的过程当做积攒资源的一个过程。.......什么样的成长志愿是比拟好的？我想这没有定论，志愿只是一个动机，并还没有产生本质上的差别。然而，不同的动机确实会影响到你后续成长过程的投入： 如果这个动机是外在给于的，比方：能够拿好绩效、或者能够失去褒扬，那么当这些外在因素变动的时候，可能就会影响你在成长上的投入。如果这个动机是外在驱动的，比方：就是喜爱攻坚的过程，或者就是冀望通过这些事补足短板，那么即便外在环境变动，你还是可能驱动自我，继续在成长上投入。所以，【如果能定义出一个成长的志愿，它可能牵引你继续地致力成长，那么这就是一个不错的成长志愿】。 那么我牵引本人的成长志愿是什么呢？ 我把它定义为：可能让本人四周的人变得优良，这是我可能优良的中央。为了实现这个指标，我须要一直地学习、提高，并把我的思考分享给他人，让他人在某些中央产生共鸣，可能进一步地造成冲破。 目前为止，这个成长志愿还是很稳固的，不会受到环境、评估、报酬等外在因素的影响，始终让我手不释卷地向前后退。 成长过程成长的过程，其实是输出（多看）-> 实际（多想、多试）-> 排汇（多总结）-> 交换（多分享）的一个过程。做好这个过程，要害是要有以下几个意识： 【更高的档次】：在物理学中，往往越平凡的人，提出的公式越能笼罩更多的景象，因为他们思考的档次更加形象。工作中也是如此：聊实现，看到的是细节之间的关系；聊概念，看到的是模型之间的关系；聊价值，看到的是生产因素之间的关系。越往高层次思考，越可能更好地明确当下的逻辑。【更广的范畴】：有同学会把手上的事件重复相熟与钻研，然而可能还是没有很大的成长。其实，我的感触是，拓宽知识面带来的增量常识收益，远比深挖已有常识取得的存量常识收益，性价比高的多。多看团队、部门、公司的事件，甚至看公司外行业的动静，就能取得更多的信息，就能更好地思考问题。常识的碰撞，往往会产生1加1大于2的成果。【更深的思考】：大家经常会对工作的事件进行总结，造成初步的思考。有些同学想得深的，还能够发表一些文章或者进行一些分享。然而，一般来说，因为投入的精力有限，这些了解还是短少系统性的打磨的。与之绝对的，咱们都能够找到相干书籍，从中取得更加体系化的深度思考。排汇并了解这些深度思考背地的逻辑，那咱们也能够取得疾速的晋升。这个阶段不同的办法和策略，会影响你能力积攒的速度。联合力学中的常识，如果做功的方向正确，那么力量就不会节约，尽管说很难达到“事倍功半”的成果，然而至多不会呈现“事倍功半”的难堪场面。 成长过程的重要意识 那么成长过程中，基于这些意识，我经常做的事是什么？ 为了理解更高的档次，我会去察看更厉害或者信息更多人的逻辑体现，包含：文档、文章、讲话、会议等。为了减少更广的范畴，我会基于工作的内容，顺藤摸瓜理解上下游，以及四周的一些工作，并且留心关注一些团队外的事件。为了寻找更深的思考，我会去寻找一些系统性的文章，有时感觉须要深入研究或者训练时，会买几本书看看。成长后果好的成长过程会决定好的成长后果。尽管外在实力的成长是本人可能感触到的，然而对外实力的成长后果是来自四周评估的。这不像考试那样有十分主观的衡量标准的。可怜的是，成长后果的收益往往是来自外在评估的。所以获取成长后果中，十分重要的一项就是你去展现的能力。 如何更好地展现咱们的成长后果？须要做好以下几件事： 【把我的项目做好】：我的项目即是因，驱动你成长，也是果，展现你成长的中央。如果你的能力晋升了，我置信你必定也能把事件做好：在我的项目中有大局观、关键时刻可能攻坚、长于我的项目总结等。对于程序员而言，能够实现“代码即文档，文档即我的项目，我的项目即口碑”这样比拟高的水准。【把总结做好】：同学们经常会对总结这样的事件比拟懊恼，大都会压到最初时刻匆匆了事，但这却是最值得花工夫的中央。在上一个总结完结的时候，就曾经开始了下一个总结的周期：重点事件提前布局、日常问题长于记录、我的项目教训及时积淀、优化改善继续思考。总结的时候，只是基于这些资料，进一步形象一下，做到瓜熟蒂落，再次升华。【一举两得的能力】：要做到后面两项，要害要有前瞻性的意识，晓得哪些事件在前面的某个阶段须要应用。曾让我更为震撼的是：优良的人，能够把一个事件，再包装或者欠缺一下，实现多个事件，达到一键双雕的境地。例如，有一个好的算法，你可能只是实现一个我的项目，然而牛的人可基于此：申请一个专利、发表一篇论文、加入一个行业分享、推动一个产品建设、进行一次开源奉献、找到一个守业合伙人等。成长后果的展现能力，会影响大家对你的评估，同时不能疏忽的是，这也是大家评估你的一个重要因子。经常，差不多的两个人，就因为一个人会展现，取得了更好的必定。 为了晋升展现的能力，我其实始终是这么做的： 把我的项目做好的要害：我会投入很多的精力去看我的项目中的上下游，每个我的项目要求晓得前因后果，要晓得全局链路。晓得的越多，就越有上帝视角，很多问题都会提前发现，很多事件都能够进行协调，很多工夫都能预计精确。把总结做好的要害：我始终在继续写文章。每个我的项目我都会尝试去总结，并发表进去。在质变的过程中，我会参考他人的写法，无意识地去训练一些不同的展现办法或者文章格调。写什么有时候并不重要，我要练习什么其实才是要害。一举两得的要害：尝试施展一个事件的最大效用。比方：团队内的分享、每年的外部汇报、我的项目的技术文档，能不能再形象一下，发表成文章，进一步扩充本人的影响力。 成长苦楚阶段如果咱们的成长后果并不是很好的话，往往取得是比拟均匀或者中下的工作评估，收益不大是一回事，更重要的是，甚至都不晓得前面该如何发力了。 处于成长苦楚阶段，其实看重的是：人的调整和反思能力，能不能造成要害的领悟。我之前有些要害的领悟，给了我前面成长过程不小的帮忙： 【贴近核心内容】：之前工作中，作为业务开发，花了不少节假日的工夫，做了一个问题排查零碎，然而前面即便投很多工夫，也不能影响到绩效或者说带来收益。过后我是很迷茫的，前面慢慢明确：须要做贴近工作核心内容的事。对于业务开发来说，须要解决业务头部的问题，实现较高的业务价值，致力才会被买单，不然可能只是认可，并没有收益。【思考深层次原理】：之前工作中，也始终在写文章，其实我过后很纳闷，不论文章怎么写，都没有很大的关注。除了业务的关注度、积攒不够等因素，前面受到他人的指导，说我都是在总结，没有去思考这些问题的原理，或者说短少隐喻。这样就很难造成更大范畴的思考，难以获得冲破。【锤炼结构性思考】：之前工作中，其实是没有比拟系统性或者结构性的思考。例如，在定义对象字段的时候，根本是平铺，短少进一步的分类和组织。起初，时不时有人提点要进行结构性思考。才慢慢感触到，如果没有进行归类、档次的思考，往往会停留在事物的外表，没有进一步去剖析内在联系，无奈冲破细节的限度。也因为过于细节，教训前面也难以复用和连贯。苦楚确实能够促成人的成长，然而也经常有人没有走进去。还没想明确，就投入到下一次奔走中，后果可想而知。所以，请不要焦急，肯定要再想想分明。 成长高兴阶段如果咱们的成长后果很好，会进入到一个高兴的阶段。然而正如那句名言“福之祸兮所倚，祸之福兮所伏”，这个阶段不肯定是一个好事件。因为你须要面临新的问题：下个阶段的成长指标是什么？ 很多人在胜利的阶段，会感觉能力够用了，不再谋求本身的冲破，认为基于工作内容的驱动，就能实现后续的成长。事实往往却并不是这样：一段时间后，当你都很相熟之后，会发现这段时间并没有利用好，错过了外围竞争力的建设窗口，而共性的货色其他人很快也都赶上来了。这样后悔的感觉，我之前有过经验的，也继续影响着我： 【跟跑向前阶段】：初中的时候，最多只能考班级第二，没有拿过第一。所以我始终很致力，指标就是拿个班级第一。侥幸的是，始终没有拿到过，所以我致力了三年，问题也不错。就像后面始终有人领跑，跟着跑就能够了，本人累积的也十分快。【当先落后阶段】：高中的时候，预期当地考了一次第一。因为只把第一当指标，认为放弃就能够了，起初也没有以前的那么一鼓作气了，对本人的要求也不再进步，与前面的差距就开始逐步缩小，直至落后。当差距体现进去，再觉醒的时候，曾经错过了十分贵重的一个窗口，再发力，也很难达到一个顶峰了。这种再次落后的感觉是很好受的。【自我冲破阶段】：前面大学、工作中，我汲取了教训，更加关注外在的因素，把指标放在集体的成长上，进行了继续地激励：是否把内容学透彻、事件做极致，某个阶段做到之后，指标又会瞄准下个阶段，间断做到最好。这就进入了精力的内耗阶段，很难有明确的尽头。相似的：乒乓球静止中，如果指标只是拿冠军，那么拿了一次可能就满足了，胜利也经常是过眼云烟；但如果把指标定义为发明新的历史，那么就能始终督促本人刻苦训练，实现技能的精进、短暂地放弃在顶峰。 成长过程中，如果只把绩效等外在因素作为奋斗目标，就会受到环境较大的影响，像浮萍一样，起伏不定，最终吞没在岁月的长河中。要防止陷入这样的窘境，咱们应该更多地向内求倒退：【把本人技能的一直成长与冲破，当做锚点，驱动本人不停地后退，进行继续的成长】。 总结成长是苦楚的，它须要你把它当做高考奋斗一样，放弃一些娱乐的时刻。同时，须要面对难以冲破时，心田的煎熬。 成长又是高兴的，当你破土而出，化茧成蝶的那一刻，所有的彩虹和花朵都为你绽开，让你不禁想握拳呐喊。 成长还是苦楚的，高兴是如此短暂，新的征程又将启程。 那么，咱们那么致力地成长是为了什么？ 我想，最贴切的答复，应该是为了向后退吧，去看看远处那美妙的风光~ 作者：闵大为(天未) 原文链接 本文为阿里云原创内容，未经容许不得转载。

站在 2023 年的明天，Service Mesh 早已不是一个新兴的概念， 回顾过去 6 年多的倒退历程，Service Mesh 从一经推出就受到来自全世界的支流技术公司关注和追捧。 2016 年作为 Service Mesh 的元年，Buoyant 公司 CEO William Morgan 率先公布 Linkerd [ 1] ，成为业界首个 Service Mesh 我的项目，同年 Lyft 公布Envoy [ 2] ，成为第二个 Service Mesh 我的项目。2017年，Google、IBM、Lyft 联手公布了 Istio [ 3] ，它与 Linkerd / Envoy 等我的项目相比，它首次给大家减少了管制立体的概念，提供了弱小的流量控制能力。通过多年的倒退 Istio，曾经逐渐成为服务网格畛域管制立体的事实标准。2018年7月，Istio 1.0版本公布 [ 4] ，标记着其进入了能够生产可用的时代，逐步也有越来越多的企业开始思考和尝试将服务网格利用于生产中。Istio 作为以后最风行的开源服务网格技术，它由管制立体和数据立体两局部形成。 在 Istio Mesh 架构中，其管制立体是一个名为 Istiod 的过程，网络代理是 Envoy 。Istiod 作为管制面的对立组件，负责对接服务注册发现、路由规定治理、证书治理等能力，Envoy 则是作为数据面通过 Sidecar 形式代理业务流量，Istio 和 Envoy 之间通过 xDS 协定接口实现服务发现、路由规定等数据的传递。Istiod 通过监听 K8s 资源例如 Service、Endpoint 等，获取服务信息，并将这些资源对立通过 xDS 协定下发给位于数据立体的网络代理。Envoy 则是独立于利用之外的一个过程，以 Sidecar 的形式（个别是以 Container 形式）随同业务利用 Pod 运行，它与利用过程共用同一个主机网络，通过批改路由表的形式劫持业务利用的网络流量从而达到为利用无侵入地提供如服务鉴权、标签路由等能力。 ...

作者： 顾欣 Triple 是 Dubbo3 提出的基于 HTTP2 的凋谢协定，旨在解决 Dubbo2 公有协定带来的互通性问题。Triple 基于 HTTP2 定制本人的流控，反对通过特定的异样告诉客户端业务层服务端负载高状况，爱护了服务端被大流量击垮，进步零碎高可用能力。 流控反压现状客户端和服务器端在接收数据的时候有一个缓冲区来长期存储数据，然而缓冲区的大小是有限度的，所以有可能会呈现缓冲区溢出的状况， Http 通过流控爱护数据溢出失落危险。 Http1 流控在 HTTP1.1 中，流量的管制依赖的是底层 TCP 协定，在客户端和服务器端建设连贯的时候，会应用零碎默认的设置来建设缓冲区。在数据进行通信的时候，会通知对方它的接管窗口的大小，这个接管窗口就是缓冲区中残余的可用空间。如果接管窗口大小为零，则阐明接管方缓冲区已满，则发送方将不再发送数据，直到客户端革除其外部缓冲区，而后申请复原数据传输。 Http2 流控Http2 应用了多路复用机制，一个 TCP 连贯能够有多个 Http2 连贯，故在 Http2 中，有更加精密的流控制机制，容许服务端实现本人数据流和连贯级的流控制。服务端与客户端首次见了连贯时，会通过发送 Http2SettingsFrame 设置初始化的流控窗口大小，用于 Stream 级别流控，默认为65,535字节。定好流控窗口后，每次客户端发送数据就会缩小流控窗口的大小，服务端收到数据后会发送窗口更新包（WINDOW_UPDATE frame）告诉客户端更新窗口。客户端收到窗口更新包后就会减少对应值的流控窗口，从而达到动态控制的目标。 Triple 流控反压Netty 基于 Http2 实现了根底的流控，当服务端负载过高，客户端发送窗口为0时，新增申请就无奈被发送进来，会在缓存到客户端待发送申请队列中，缓存数据过大，就会造成客户端内存溢出，影响业务程序。 Triple 基于 netty 实现了 Http2 协定，通过 Http2FlowController 接口对立封装，在实现分为进站（inbound）和出站（outbound）两个维度的实现。Triple 在 inbound 流量上应用了 netty 的默认流控实现，在 outbound 上实现了本人流控，基于服务端负载，将服务端流量压力透传到客户端业务层，实现客户端的业务反压，暂停业务持续发送申请，爱护服务端不被大流量击垮。 连贯初始化Triple 在首次建设连贯时，通过 TripleHttp2Protocol 初始化 http2 配置，默认流控窗口 DEFAULT_WINDOW_INIT_SIZE = MIB_8，并在服务端和客户端退出本人的 outbound 流控接口。 ...

作者：李艳林（彦林），Nacos 开源创始人，阿里云微服务引擎 MSE 创始人。 笔者参加过阿里巴巴团体电商业务微服务的降级和革新过程，并始终在反对历年双11的大促流动，沉闷在反对一线，也参加了 Nacos 开源和社区倒退，目前正在阿里云负责微服务的整体开源布局和微服务引擎 MSE 的研发管理工作。因而在微服务技术的利用、开源和商业化服务上，有着比拟平面的感触和思考。微服务虽已陈词滥调，但其生命力之强超出不少人的设想。本文将从微服务倒退的行业趋势和技术趋势两方面进行解读，欢送各位参加评论，一起交换。 2022年盘点内容：云原生微服务技术趋势解读 技术趋势推动行业改革，行业趋势反哺技术价值，两者相互促进，能力持续保持技术的生命力。咱们先来看看这一年国内的一些重要事件，这些事件也恰好揭示并减速着行业和技术趋势： 4月，Linux 下一代架构基金会下成立了微服务技术组 SIG（Special Interest Group），独特探讨微服务治理标准化的解决方案4月，跨不同开发语言和技术框架，微服务治理标准 OpenSergo 开源5月，Envoy 社区推出 Envoy Gateway 产品，退出下一代网关角逐6月，腾讯正式开源 Spring Cloud Tencent，打造一站式微服务解决方案7月，Ingress Nginx 我的项目暂停接管新性能，将专一于稳定性晋升8月，CloudWeGo 正式公布 Rust RPC 开源框架 Volo8月，直流科技公布服务网格我的项目（GA 版本）11月，Apache Dubbo 首个 Rust 语言版本正式公布11月，阿里巴巴开源下一代云原生网关 Higress，基于 Envoy，反对 Nginx Ingress 零老本疾速迁徙12月，字节跳动开源 kube-apiserver 高可用计划 KubeGateway12月，中国开源云联盟公布第二批开源成熟度评估后果，10个我的项目中微服务畛域的开源我的项目有4个12月，《微服务治理白皮书》荣获阿里云开发者社区年度最受欢迎电子书TOP1此外，腾讯云&华为云在往年先后提供了面向 Nacos 的商业版微服务倒退的行业趋势微服务仍在高速增长，关注度从开发效率转向交付效率开源我的项目 Star 在肯定水平上反馈了一个我的项目的热度和生命力，从 Star 的增长上看，目前支流微服务开源我的项目每年以均匀10%以上的速度在增长，每个我的项目均冲破 2 万，数字上出现的是不仅是行业规模，也折射了每年新晋微服务开发者的水位。 Apache Dubbo：4.3w，YoY 12%Istio: 3.3w, YoY 11%Nacos：2.6w，YoY 23%Spring Cloud Alibaba：2.5w，YoY 15%Seata：2.4w，YoY 10%Envoy: 2.2w, YoY 16%SkyWalking：2.2w，YoY 14%Sentinel：2.0w，YoY 13%数据统计自2022年12月25日，计算奴才仓库的累加数据。 ...

本文作者： 李志信，OpenYurt Member，Apache dubbo PMC，专一于云原生边缘计算的零碎架构和解决方案 张逸飞，OpenYurt Member，浙江大学 SEL 实验室 云原生边缘计算智能开源平台 CNCF OpenYurt 于近期公布了 v1.2 版本。OpenYurt 是业界首个对云原生体系无侵入智能边缘计算平台，具备全方位的“云、边、端一体化”能力，可能疾速实现海量边缘计算业务和异构算力的高效交付、运维及治理。 在 v1.2 版本中，OpenYurt 遵循社区提出的“节点池治理”理念，新增组件 Pool-Coordinaotr，提出了一套针对云边场景的资源、网络、利用、监控等角度的边缘治理计划。本文首先聚焦云边场景下的网络优化问题的解决进行解读，敬请继续关注。 Pool-Coordinator 节点池治理及其对云边网络的优化组件背景早在去年年初，社区就提出了 “节点池治理” 的概念。节点池为 OpenYurt 生态概念，示意集群内一组网络互通的边缘机器节点。在云边协同场景，边缘 IOT 设施与算力往往依赖多台机器节点工作，节点池概念为 OpenYurt 生态在边缘算力的管控粒度方面减少了一个维度。而“节点池治理”，专一于边缘机器的资源、网络、生命周期、可观测指标等等角度，提供了边缘测视角与治理思路。 Pool-Coordinator 在社区内首次践行了这一概念，提出了一套针对云边场景的资源、网络、利用、监控等角度的边缘治理计划，具备高可用能力。 边缘根底组件对云边网络的需要与挑战边缘根底组件对于边云网络的要求，驱使着 OpenYurt 为开发者提供更正当、更优化的解决方案。 首先是云边网络带宽根底条件的问题。在云原生边缘计算的场景中，云边网络通路带宽往往受到各个方面的限度，例如机器资源，物理间隔，资金老本等，这就导致对于局部厂商和用户，其云边网络条件带宽较低，甚至在各别特定环境的节点池带宽极低。 其次是集群资源数据量的问题。边缘集群往往笼罩较多地区、机器节点与物理设施，相比于一般集群，其笼罩地区广大，规模较大，集群整体资源量也就绝对较多。对于局部集群根底组件，例如代理组件、CNI 组件、DNS 组件，甚至局部业务组件，例如设施驱动程序，边缘基础架构中间件等，须要在启动时通过 K8S List/Watch 机制来拉取全量资源并监听，这个过程对网络要求较高。 再者是边缘根底组件的重要性，在新节点纳管入边缘集群时，初始化程序会拉起一系列 OpenYurt 边缘根底组件与配置，待顺利初始化，才会调度业务程序至节点。一旦边缘根底组件因为带宽起因，拉取依赖资源失败，会导致边缘机器业务利用无奈启动，边缘节点算力扩容失败。另一方面，处于运行中的边缘根底组件，如果长时间拉取资源失败，可能造成网络、代理、存储资源与核心不同步，造成业务危险。 能力、架构实现与工作形式3.1 Pool-Scope（节点池维度）资源缓存Pool-Coordinator 会为节点池维度的资源提供边缘侧缓存，从而升高因为这些资源的大量 list/watch 申请造成的云边网络带宽问题。 在部署阶段，开发者能够通过装置 Chart 包的形式，将 Pool-Coordinator 组件装置至集群，该过程利用了 OpenYurt 生态的 YurtAppDaemon 资源，将这一组件以节点池粒度部署至所有的边缘节点池，每个节点池一个实例。 待 Pool-Coordinator 实例启动，会由选主机制选出的 Leader YurtHub 将 Pool-Scope 资源，例如 endpoints/endpointslice 拉取至边缘，进而同步至 Pool-Coordinator 组件，缓存起来，以供节点池内全副节点应用。 ...

作者：山猎，珑乘 背景波司登开创于1976年，专一于羽绒服的研发、设计、制作，是寰球出名的羽绒服生产商。波司登用一系列世人注目的辉煌问题证实了本人的实力：间断26年全国销量当先，间断22年代表中国向世界公布防寒服风行趋势，产品滞销美国、法国、意大利等72个国家，寰球超过2亿用户。作为羽绒服反动的旗手，波司登引领了行业内的“三次反动”。 在产品力和销售成绩单背地，波司登在生产、仓储、物流、销售各环节已实现数字化转型和翻新革新。除生产端的智能生产工厂，波司登对仓储和物流环节也进行智能化革新，晋升小单快反、拉式补货的比重，最大限度缩小困扰服装企业多时的“库存”问题；为了精准散发销售端产品，波司登建设数据中台，买通全渠道数据，赋能消费者钻研、商品企划、渠道匹配等。当初，波司登每件羽绒服从生产到到达消费者，背地都是一段数字之旅。 云原生技术倒退随着波司登数字业务的飞速发展，背地的 IT 技术也在不断更新迭代。波司登极为器重客户对服务的体验，并将零碎稳定性、业务性能的迭代效率、问题的疾速定位和解决视为构建外围竞争力的基石。服饰行业会积极参与各大电商平台的促销流动，业务流量的波峰波谷景象显著，如果因为资源分配不合理导致顶峰期间订单溢出、运力有余，会极大影响顾客和商家的体验。此外，波司登自研了用户经营平台（用户洞察零碎、内容管理系统、用户治理 CRM 零碎及用户小程序）、批发经营平台（线上平台订单治理 OMS 零碎、线下渠道管理系统、门店收银 POS 零碎）、商品经营平台（订单解决核心 OPC、库存计算中心 ICC、商品订货零碎、商品经营 iMOS 零碎、洽购制作 GiMS 零碎、物流治理 EWM 零碎、机器人调度 WCS 零碎） 等诸多垂直业务性能，在市场需求的疾速变动下，产品性能翻新和迭代效率问题也是对技术架构的一大挑战。 这些现状的解法和云原生架构带来的外围能力不约而同，在波司登零碎革新上云的过程中，CIO 戴建国亲自带队，围绕着云原生技术体系，推动波司登的各条业务线进行技术升级革新，放慢数智化发展过程。在技术选型上，波司登始终遵循着2条准则： 全面拥抱开源凋谢的支流技术标准。 应用开源凋谢的支流技术标准能够确保技术计划的成熟度，更便捷的从开发者社区获取技术资源和最佳实际，也可能帮忙企业更好的招募技术人才。此外，这样的策略也防止了被关闭技术体系和特定云厂商所捆绑。 尽可能利用云计算的价值。 将稳定性保障、底层技术实现、技术组件保护、弹性伸缩等非功能性需要尽可能交给云厂商解决，让技术团队将更多的精力投入到业务翻新上。 这2个准则并不矛盾，相同，它们之前能够十分好的交融，是所有应用云计算的企业用户都值得借鉴的架构选型规范。比方 Kubernetes 就是典型的满足开源凋谢规范的技术标准，阿里云提供的 Kubernetes 产品能够简化用户的搭建老本，更好的与云计算资源进行集成。同时用户仍然能够基于开源 Kuberntes 的标准协议与 API 应用云产品，这就是2条选型准则互相交融的最好体现。 容器化革新云原生趋势下，Kubernetes 毫无疑问曾经成为了企业新一代云 IT 架构的基础设施。从2021年开始，波司登就开启了微服务和容器化革新打算，将 IT 零碎的底座逐渐从虚拟机迁徙到 Kubernetes。 在 Kubernetes 平台的抉择上，基于技术选型的2条准则，波司登抉择了阿里云容器服务 ACK 。ACK 以阿里云牢靠稳固的 IaaS 平台为底座，向下封装了 30+ 款云产品，造成了自动化运维和云平台交互的新界面，从而晋升企业业务零碎的弹性和自动化运维能力。 基于容器服务 ACK 的易用性以及集成能力，波司登IT零碎容器化革新工作比料想中的要顺利得多。对于每一个业务零碎而言，从虚拟机迁徙到 Kubernetes ，仅仅是底层的承载产生了变动，不会波及到太多的革新老本。在要害的容器网络实现上，容器服务 ACK 通过云原生 Terway 网络模式，间接基于阿里云的虚拟化网络中的弹性网卡资源来构建的容器网络，将容器和虚拟机纳入同一层网络中，便于业务云原生化迁徙。这样齐全能够对传统架构实现渐近式容器化革新，在不中断业务的前提下一点一点的从虚拟机往 Kuberntes 上搬。在容器化革新的过程中，当波司登技术团队遇到疑难问题的时候，能够第一工夫从阿里云获得最佳实际领导，包含集群布局、平台运维、利用适配、平安防护、可观测等多个方面，这也更进一步的晋升了容器化革新的速度。 目前，波司登的自研零碎曾经 100% 基于 Kubernetes。相比传统的基于虚拟机部署形式，容器化帮忙波司登在资源利用率上晋升了30%，在运维效率上晋升了40%。 波司登的技术团队也在容器化革新的过程中，把握了治理超大规模Kubernetes集群的能力，并促成了更多云原生新技术的使用。 ...

目前国内云服务器在重视平安的同时会推出自带的防火墙，比方咱们在默认状况下装置的云服务器阿里云会默认装置安骑士，同时平安组也是必须要设置的。如果咱们不设置平安组，可能网站和面板无奈关上。有些敌人问到是否能够敞开防火墙，这里咱们看看。 对于服务器的端口防火墙，咱们须要设置放行入和出方向端口。比方咱们用宝塔面板的话须要设置8888和888端口，以及惯例的80、443、3306端口才能够应用。这里我看是不能够敞开或者设置全端口放行的。 对于有敌人提到的密钥对问题，这个是咱们设置服务器SSH入口的形式。咱们惯例的会用root明码登录，或者平安一些的咱们也能够用密钥对文件登录，这样平安度更高一些。 阿里云服务器应该开启防火墙吗? 真正的阿里云防火墙是不会凋谢的，即使能够凋谢也是收费应用7天。防火墙是否开启依据用户本身的需要而定，大家可进入阿里云主机控制台，能够自行设定。如果的确须要较强的服务器平安咱们须要针对开启。 1、利用防火墙 阿里云利用防火墙(Web Application Firewall, 简称 WAF), 是阿里基于10余年攻防教训齐全自主研发的平安产品。其基于云平安大数据能力实现，通过进攻SQL注入、XSS跨站脚本、常见Web服务器插件破绽、木马上传、非受权外围资源拜访等OWASP常见攻打，过滤海量歹意拜访，防止您的网站资产数据泄露，保障网站的平安与可用性。 2、云防火墙 阿里云云防火墙是一款云原生的云上边界网络安全防护产品，可提供对立的互联网边界、内网VPC边界、主机边界流量管控与平安防护，包含联合情报的实时入侵防护、全流量可视化剖析、智能化访问控制、日志溯源剖析等能力，是您的网络边界防护与等保合规利器。 这些防火墙都是有针对不同的须要抉择的。如果咱们有开始抉择后不抉择，那间接对应敞开即可。对于个别的高级用户应该用不到。

  福兔迎春，好运将至 新岁启封，万象更新 2023癸卯兔年 祝您肆意向前 与更多微妙际遇相伴 前「兔」无穷、大展鸿「兔」！  

作者：sealer 社区 新春之际，很快乐在此时发表 Sealer [ 1] 0.9 版本的正式公布。Sealer 是一款致力于摸索面向分布式应用的疾速打包、交付和运行的解决方案。2021 年5月 Sealer 我的项目正式开源；短短一年工夫，Sealer 在 2022 年 4 月成为 CNCF Sandbox 我的项目。 Sealer 0.9 版本中，其在外围定位上由专一 “集群维度的 Build，Share，Run” 降级为 “以集群为根底，以利用为核心，帮忙集群和分布式应用实现 Build, Share，Run”，并重点加强了对利用的反对能力。 版本详解加强对利用的反对利用与集群解耦Docker Image 很好的解决了单机利用的打包交付问题，而 Sealer Image [ 2] 尝试在集群维度，解决类 Kubernetes 集群以及分布式应用的打包交付问题。Sealer Image 基于蕴含内容将 Sealer Image 分为集群镜像和利用镜像。其中： 集群镜像，示意一个镜像蕴含 cluster runtime，如 Kubernetes、K0S、K3S 等。Run 阶段既会装置集群也会装置利用（如果蕴含了利用）利用镜像，示意一个镜像未蕴含 cluster runtime，其须要基于已有的集群进行装置。Kubefile 反对 LABEL & KUBEVERSION 指令Kubefile 中 LABEL 指令相似 Dockerfile LABEL 指令，容许用户针对 Sealer Image 指定一些元数据信息，这些元数据信息在构建实现后可通过 sealer inspect 命令查看。 其中，Sealer 官网保留以 *sealer.io/ 为前缀的 label key，如： 针对集群镜像，通过 LABEL 可申明集群镜像反对的能力列表等信息 ...

近日，由阿里云撰写的对于 KOLE 翻新论文被 ACM SoCC 国内会议长文录用。 ACM Symposium on Cloud Computing（以下简称 SoCC）是由美国计算机协会主办、聚焦云计算技术的一项学术会议，是云计算的首要会议。它会集了对云计算感兴趣的钻研人员、开发人员、用户和实践者，是惟一由 SIGMOD（数据管理特地趣味组）和 SIGOPS（操作系统特地趣味组）联结主办的会议, 这个会议在近些年蓬勃发展，旨在汇集数据库和计算机系统两大畛域的学者，独特推动云计算技术在工业界的钻研与倒退。 此次被录用的论文为《KOLE: Breaking the Scalability Barrier for Managing Far Edge Nodes in Cloud》。此论文灵感诞生于阿里云边缘容器产品 ACK@Edge ，ACK@Edge 是阿里云容器服务针对边缘计算场景推出的云边一体化协同托管计划,采纳非侵入形式加强，提供边缘自治、边缘单元、边缘流量治理、原生运维 API 反对等能力，以原生形式反对边缘计算场景下的利用对立生命周期治理和对立资源调度，现阶段曾经笼罩了 CDN、音视频直播、物联网、物流、工业大脑、城市大脑、地产、票务、新批发、能源、交通等理论业务场景，并服务于阿里云 LinkEdge、盒马、优酷、视频云、大麦、CDN 等多个业务或我的项目中。 KOLE  全称：A framework built on top of Kubernetes to Orchestrate Limitless (far)  Edge nodes。KOLE 针对 Kubernetes 在云边一体，大规模边缘节点治理方面的挑战，创新性的提出了基于 Kubernetes的新的云边架构，通过利用新的云边通信协议以及缓存快照的形式，使 Kubernetes 可能轻松治理数百万节点。为了冲破 Kubernetes 治理大量边缘节点的可扩展性限度，KOLE 的设计遵循三个规范： 防止创立大量对象来长久化边缘节点的状态；防止在节点与 APIServer 中放弃大量的 HTTP 连贯；应用 Kubernetes CRD 反对对边缘节点及其运行的应用程序进行所需的治理操作。 基于以上准则，KOLE 创新性的应用了 MQTT 协定作为云边通信机制，MQTT 被设计用于轻量级的公布/订阅式音讯传输，旨在为低带宽和不稳固的网络环境中的物联网设施提供牢靠的网络服务,是专门针对物联网开发的轻量级传输协定，并且适宜百万级设施连贯, MQTT 协定针对低带宽网络，低计算能力的设 备，做了非凡的优化，MQTT 的传输格局十分精小，最小的数据包只有 2 个比特，绝对于 HTTP 协定具备更低的能耗。 ...

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

作者：孙健波（天元） 11月3日，2022 杭州 · 云栖大会上，阿里云智能云原生利用平台总经理丁宇发表：KubeVela 面向四大外围方向能力降级，打造交付治理一体化的云原生利用平台。 本次降级是 KubeVela 从利用交付到利用治理一直质变造成的一次量变，同时也创始了业界基于可扩大模型构建交付和治理一体化利用平台的先河。 降级次要面向四大外围方向： 资源状态可视化。从利用首次部署到后续的继续交付，KubeVela 将整个利用资源的交付流程和拓扑构造通明可视化，并主动生成蕴含 100 多个外围指标的可观测性大盘，帮忙开发者自助式定位问题。更为重要的是，资源可视化能力能够轻松接入用户的自定义资源，满足用户的自定义可观测配置需要，实现在多集群层面的对立可观测。 平台能力插件化。KubeVela 不仅建成了灵便可扩大、自助式装置的平台能力插件核心，还构建了 50 多款开箱即用的插件。这些插件蕴含了云资源、GitOps、可观测性、FinOps、IoT 等多种场景，帮忙业务开发者灵便构建面向不同场景的解决方案，并通过社区的实践经验大幅简化使用者的心智累赘。 交付流程自动化。KubeVela 申明式工作流体系不仅具备操作系统资源的能力，还退出了条件判断、参数传递、分支并发等大量高级个性，每一个流程均能够通过配置语言编程扩大。包含多集群灰度公布、CI/CD 对接、平安合规接入在内的 10 多个场景化工作流帮忙开发者轻松实现自助式利用编排。 环境治理统一化。你再也不须要为了装置 KubeVela 提前准备一个 Kubernetes 集群了，KubeVela 提供了在开发者本地或者虚拟机上自助式一键离线化装置整套管制立体的工具，联合多集群交付和治理能力，帮忙开发者实现开发、测试、生产的全流程多环境对立治理。我的项目背景随着云原生时代的到来，开发者为了构建合乎云原生的利用架构，不得不面对大量云和基础设施的简单 API ，不仅应用难度大、学习门槛高，还会因为间接操作底层基础设施产生很大的稳定性危险。Kubernetes 很好的帮忙基础设施提供了对立的 API 集成界面，然而其定位是“为平台构建者提供的平台”，所以对于下层利用开发者而言就缺失了这样一层“以利用为核心”的应用界面。凋谢利用模型（ OAM） 应运而生，它由阿里和微软在 2019 年联结公布，会集了两家企业在云原生利用开发中的大量实践经验，为构建云原生时代的利用平台提供了理论依据。 OAM 模型一经公布，便受到了包含 Oracle、腾讯、字节、第四范式在内的大量企业欢送和驳回。然而对于更多的企业而言，OAM 只是一个实践模型，不足能够间接应用的实际平台，难以落地。于是，阿里云的工程师联结社区驳回 OAM 的企业，基于大家的独特实际，一起构建了开箱即用的 OAM 实现引擎，KubeVela 便诞生了。 规范可扩大的利用交付引擎KubeVela 于 2020 年 11 月正式公布，并始终保持以灵便可扩大、关注点拆散为设计准则，指标是将云原生技术组件和企业级利用连贯在一起，帮忙企业内的开发者疾速取得易于上手、安全可靠的软件交付和治理体验。 开源仅不到一年的工夫，便具备了多集群对立编排、基础设施无关、利用交付工作流等外围个性，受到社区用户宽泛的青睐，并于 2021 年 6 月正式退出 CNCF 基金会。 现在，KubeVela 已被招商银行、字节跳动、现实汽车、Shein 在内的 300 多家海内外企业采纳，整个 OAM 和 KubeVela 社区蕴含了数十个生态我的项目，累计取得了 8000 多个 star，收到了来自寰球数十个国家 300 多名开发者的大量奉献。 图 1 KubeVela 的对立利用交付 KubeVela 很好地帮忙企业构建了对立的利用交付能力，通过 KubeVela 的对立架构，企业能够在一份配置文件中同时交付微服务容器、云数据库、前端动态页面，以及他们外部自定义的扩大，实现多样化工作负载的编排和运维治理。业务利用的开发者在交付过程中也不再须要关怀 Kubernetes 资源的版本差别，又或者是不同云盘规格的差异。针对这一层对立的利用形容，KubeVela 提供了欠缺的版本治理、灰度公布、CI/CD 对接、多集群治理等性能，大大降低了企业外部应用云原生技术的门槛。 ...

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

作者：Dubbo 社区 Dubbo 简介Apache Dubbo 是一款 RPC 服务开发框架，用于解决微服务架构下的服务治理与通信问题，官网提供了 Java、Golang 等多语言 SDK 实现。应用 Dubbo 开发的微服务原生具备相互之间的近程地址发现与通信能力， 利用 Dubbo 提供的丰盛服务治理个性，能够实现诸如服务发现、负载平衡、流量调度等服务治理诉求。Dubbo 被设计为高度可扩大，用户能够不便的实现流量拦挡、选址的各种定制逻辑。 背景Spring Framework 6.0 于 11 月 16 日正式公布 GA 版本，Spring Boot 3.0 也于11月25日正式公布 GA 版本，并且 Spring 6 & SpringBoot 3 最低反对 JDK17，意味着如果降级应用 Spring 6 & Spring Boot 3 时就必须须要降级应用 JDK17。 然而Java 8 目前是国内支流生产环境 Java 版本之一。尽管近几年陆续公布了 Java 11、Java 17 官网 LTS 版本，然而大部分开发者仍然本着 “你发任你发，我用 Java8” 的认识对待JDK的降级。不过 Java 17 版本在性能上的确做了大量的优化特地是 ZGC 的公布，促成了国内不少企业降级到 Java 17。 ...

联结作者 ：志敏，冬岛，戒空，邓隽，佳旭，谢乘胜，元毅，溪洋 在 2022 年的双 11 大促季中，阿里云容器服务（简称 ACK）、容器镜像服务（简称 ACR）除了撑持团体外围零碎容器化以及为云上产品提供撑持外，也将外部多年大规模容器技术以产品化的能力输入给泛滥围绕双 11 的生态公司和 ISV 公司。ACK 和 ACR 每年继续迭代、公布新的产品性能，同时将治理数万个容器集群的规模化能力和最佳实际也透出给客户，通过技术红利撑持来自寰球各行各业的容器云。本文会介绍 ACK 和 ACR 的新产品能力和实际助力双 11 场景下的客户和业务。近年来，降本增效成为了泛滥企业 IT 管理者关注的重要问题，企业曾经到了精益用云的时代。以容器为根底的云原生技术正在粗浅地扭转企业上云和用云的形式，如何利用云原生技术帮忙企业实现降本增效是很多 IT 负责人关注的话题。 每年的阿里巴巴双 11 都是考验各种前沿技术的最佳“实战场”。2021 年双 11，阿里团体就曾经实现 100% 利用云原生化，电商微服务、中间件等利用，以及搜寻、大数据、 AI 业务全副运行在对立的容器平台根底之上。倒退到往年，容器服务在双 11 期间又实现了哪些技术和利用的新冲破呢？ 本文将介绍 ACK 和 ACR 新产品能力在云原生实际的摸索和教训、带来的价值，及其在双 11 中的利用，心愿为更多企业提供基于 ACK 和 ACR 实现云原生化演进、实现云上 IT 架构高质量倒退的可参考案例。 阿里云容器服务为双11多畛域提供深度反对阿里云容器服务 ACK（Alibaba Cloud Container Service for Kubernetes）是寰球首批通过 Kubernetes 一致性认证的服务平台，提供高性能的容器利用治理服务，反对企业级 Kubernetes 容器化利用的生命周期治理。ACK 在阿里巴巴团体内作为外围的容器化基础设施，有丰盛的利用场景和教训积攒，包含电商、实时音视频、数据库、消息中间件、人工智能等场景，从 2015 年上线起始终在双 11 期间为内外部客户提供宽泛的技术支持；同时，容器服务将阿里巴巴外部各种大规模场景的教训和能力融入产品，向私有云客户凋谢，晋升了更加丰盛的性能和更加突出的稳定性，容器服务间断多年放弃国内容器市场份额第一。 在过来的一年，ACK 进行了踊跃的技术升级，继续晋升产品性能和服务能力，通过这些降级带来的云原生红利也间接使用到双 11 中。ACK 在往年双 11 期间稳如磐石，深度参加了泛滥畛域的撑持，包含在阿里巴巴电商外围零碎在批发云撑持聚石塔，在物流云撑持菜鸟 CPAAS，在中间件云原生撑持 MSE 和 MQ，在边缘云反对撑持 CDN 和边缘计算，同时反对数据库云原生化等。 ...

作者：于雨 dubbogo 社区倒退 7 年多，dubbogo 注销用户已达 63 家【详见 https://github.com/apache/dub... 】，实在用户应该更多。于某在反对某 dubbogo 用户时，曾提议让他们注销下，对方暗示本人的业务是金融 P2P，注销着实不便。如 链家 这种已知未登记用户，那就更多了。 追述历史不少人曾问于某，到底是 dubbogo 还是 dubbo-go 才是正确拼写，集体通常的答复是，两个都对。 于雨 2016 年 3 月在位于上海张江的 张衡路与华佗路 交叉口的 隆重研发核心 工作时，公司大部分我的项目应用了 Java 技术栈，其中相当数量的服务应用了曾经无人保护的 Dubbo v2.5.4-snapshot。公司老板陈大年【外部称说 年总】感觉云原生时代来了，让大家用 Go 语言革新公司的 Java 我的项目。于是公司新我的项目纷纷应用 Go 进行构建，但面临一个很重要的问题：Go 语言服务与 Java 服务之间如何进行通信？ 子曰，没有什么服务解耦是一层代了解不了的，如果一层不够，再来一层。如上图，刚开始大家给出的解决方案就是： 有旧的 Java 服务，如 Service0，则先再构建一个 Service0 的代理 S0-Porxy，实现公司外部通信协议与 Dubbo 服务通信协议的转换；网关 Gateway 层如果检测到服务是 Go 语言构建的服务，则把申请转到 Go 网关 GoGateway Proxy；Go 网关 GoGateway Proxy 如果要调用旧的 Java 服务，如 Service0，则先把申请转到 S0-Porxy 代理。这套零碎运行了一个月后，相干开发和运维同学口碑载道： ...

作者：卜比 近年来，Rust 语言以内存平安、高可靠性、零形象等能力取得大量开发者关注，而这些个性恰好是内核编程中所须要的，所以咱们看下如何用rust来写Linux内核模块。 Rust 与内核模块尽管 Rust 反对曾经在 LinuxKernel6.1 版本合并到主线了，所以实践上来说，开发者能够应用 Rust 来为 Linux6.1 写内核模块。 但理论开发工作中，内核版本不是最新的，比方 Debian 11 的内核就是 5.10 版本的，那么在这种状况下，该如何用 Rust 写内核模块呢？ 原理Rust 如何向内核注册回调、如何调用内核代码。Rust 和 C 的互操作性Rust 如何编译到指标平台上。Rust 的 target 配置Rust 如何申明内核模块入口、并增加非凡 section。Rust 内核模块的二进制约定Rust 和 C 的互操作性第一个问题基本上就是 C 和 Rust 的互操作性了。 得益于 Rust 的抽象层次，C 语言和 Rust 的相互调用都是比拟容易的。rust 官网也提供了 bindgen 这样，依据 .h 文件生成 .rs 文件的库。 这样一来，貌似间接应用 bindgen 将内核头文件翻译成 .rs 就能够了？ 但还有一个问题，如何获取内核头文件门路呢？ 能够应用一个 dummy 内核模块，在编译过程中把编译参数导出来，其中蕴含了头文件门路，编译参数等，用于 bindgen 生成代码。 Rust 和 target 配置内核模块和一般的程序相比，次要的不同在于： 内核模块是 freestanding 的，没有 libc、内存调配也比拟原始内核模块对于异样解决等有非凡约定Rust 提供了 no_std 机制，能够让 rust 代码编译成 freestanding 二进制；Rust 也提供了自定义 target 的形式，能够自定义申明生成二进制的标准。 ...

作者：铖朴、良名 12 月 3 日，微服务 x 容器开源开发者 Meetup 上海站上，阿里云智能技术专家，云原生利用脚手架我的项目负责人良名发表阿里巴巴云原生利用脚手架我的项目正式开源，并在现场做了相干内容介绍。 本次开源的云原生利用脚手架是一款基于 Spring Initializr 我的项目根底之上，反对多种工程架构、提供代码示例片段、组件更丰盛、生态更凋谢的一款脚手架。其致力于在当下云原生时代，为宽广开发者提供更简略、更高效的我的项目构建体验。 云原生利用脚手架惯例的工程构建流程接下来，咱们通过回顾一下过来数十年间一个后端软件工程师个别是怎么来开发一个新我的项目的来理解云原生利用脚手架。随着技术的倒退，和大量晋升研发效力工具的继续涌现，一个后端 Java 企业级我的项目的创立过程总体上经验了手工构建、脚手架构建等历程。 手工构建在 start.spring.io 脚手架我的项目被推出之前，很多后端工程师的我的项目构建过程都是纯手工的模式进行。那时，Spring 我的项目是后端新我的项目构建次要应用框架之一。因而，咱们以一个 Spring 企业级我的项目构建为例进行阐明。该阶段新建我的项目大抵可分为：新建工程、增加依赖、增加配置、编写测试代码和运行测试5个步骤，接下来别离进行具体阐明。 新建工程在 Spring 我的项目流行的手工我的项目构建阶段，新建工程个别采纳得较多的集成开发工具（Integrated Development Environment, IDE）那个时候用得最为广泛的还是 Eclipse。 新建新我的项目总体来说比较简单。依照 IDE 的新建我的项目提醒即可疾速新建一个相干工程。 增加依赖因为一个企业级我的项目个别会依赖于很多内部组件，比方 MySQL 数据库、Redis 缓存，因而须要增加很多第三方组件依赖。这个过程比拟繁琐，须要操作的同学理解具体所需的性能与对应的依赖名称，有的性能还可能须要多个组合依赖。当我的项目所需内部依赖较多时，整个过程会比拟耗时。对于一些有教训的工程师，个别都通过留存一些我的项目依赖模板，在创立新我的项目的时候通过参考模板来进行依赖增加，这样能略微放慢我的项目构建过程。 增加配置Spring 我的项目构建过程中最为简单的局部莫过于进行各种各样的配置了，例如下方所示为一个根本的 MySQL 连贯配置： <?xml version="1.0" encoding="UTF-8"?><beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:context="http://www.springframework.org/schema/context" xmlns:aop="http://www.springframework.org/schema/aop" xmlns:mvc="http://www.springframework.org/schema/mvc" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-4.3.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-4.3.xsd http://www.springframework.org/schema/aophttp://www.springframework.org/schema/aop/spring-aop-4.3.xsd http://www.springframework.org/schema/mvchttp://www.springframework.org/schema/mvc/spring-mvc-4.3.xsd " default-lazy-init="false"> <bean id="dataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource" destroy-method="close"> <property name="driverClass" value="com.mysql.jdbc.Driver" /> <property name="jdbcUrl" value="jdbc:mysql://10.0.xxx.xxx:3306/xxxxx?xxxxx" /> <property name="user" value="root" /> <property name="password" value="root" /> <property name="maxPoolSize" value="40" /> <property name="minPoolSize" value="1" /> <property name="initialPoolSize" value="1" /> <property name="maxIdleTime" value="20" /> </bean> <!--配置sqlSessionFactory --> <bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean"> <property name="dataSource" ref="dataSource" /> <property name="configLocation" value="classpath:mybatis-xxx.xml" /> </bean></beans>除了数据库，依赖的内部组件都须要进行手动编写配置文件，实现我的项目配置，整个过程十分繁琐。就算有参考模板通过拷贝相干文件来做二次批改，也可能稍不留神就呈现漏配或者错配一些内容，导致我的项目运行不起来。 ...

作者：严浩：同程艺龙高级开发，负责服务治理相干工作， Apache Dubbo Committer。 胥皓：同程艺龙高级开发，负责服务治理相干工作。背景在微服务倒退初期，市场上还没有成熟和风行的 RPC 框架，咱们公司外部自研开发了一套名为 DSF (Distributed Service Framework) 的 RPC 框架，撑持起了公司业务的高速倒退。然而随着技术的疾速迭代和人员的一直变更，开发者既要修复之前的 BUG 又要跟上技术的更新，开发保护老本越来越高。另一方面，当初应用程序都在往云原生方向倒退与设计，公司也在这方面做出摸索。因而公司微服务框架的演进曾经到了岔路口，是全新降级原有的 SDK，还是抉择拥抱开源？ 思考到降级现有的 SDK 在一段时间之后可能仍然会面临当初的问题，最初咱们抉择了拥抱开源。在一番调研之后咱们抉择了 Dubbo3 作为公司的下一代 RPC 框架，负责微服务治理体系的数据面。 目前 Dubbo3 在公司的落地开发工作曾经实现，通过本文咱们对公司外部 Dubbo3 的实际及收益做了深刻总结。 Dubbo 3 外围性能介绍Dubbo 社区对于 Dubbo 3 的文档和材料越来越欠缺，以下是咱们从社区援用的一些内容。 Dubbo 3 被社区寄予厚望，将其视为下一代云原生服务框架打造，Dubbo3 提供的外围个性列表，次要包含四局部。 全新服务发现模型。利用粒度服务发现，面向云原生设计，适配基础设施与异构零碎；性能与集群伸缩性大幅晋升。下一代 RPC 协定 Triple。基于 HTTP/2 的 Triple 协定，兼容 gRPC；网关穿透性强、多语言敌对、反对 Reactive Stream。对立流量治理模型。面向云原生流量治理，SDK、Mesh、VM、Container 等对立治理规定；可能反对更丰盛的流量治理场景。Service Mesh。在最新的3.1.0的版本中反对Sidecar Mesh 与 Proxyless Mesh，提供更多架构抉择，升高迁徙、落地老本。Dubbo 3 的外围性能点（如利用级服务发现以 ip、port 为辨别实例）和公司外部的服务模型统一，极大地缩小了咱们的适配工作。还有在 Service Mesh 中对 Sidecar Mesh 与 Proxyless Mesh 的反对也将缩小后续公司对 Mesh 计划的摸索老本，包含 Dubbo3 在多语言体系的倒退也为异构架构提供了撑持。 ...

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

作者：赵奕豪(宿何)｜Sentinel & OpenSergo 开源我的项目负责人一年一度的天猫双11曾经落下帷幕，大家在疯狂买买买的过程中肯定会有疑难：如何保障微服务在双十一的超级峰值下也能如丝般顺滑稳固？这背地的技术原理是怎么的，有没有一些最佳实际与规范？这篇文章就为大家介绍如何联合 Sentinel 与 OpenSergo 玩转双十一背地的流量治理技术与规范。 OpenSergo 是什么？业界微服务治理存在概念不对立、配置模式不对立、能力不对立、多框架对立管控较为简单等问题。比方咱们心愿对某个接口配置熔断，在 Hystrix 中可能须要应用 HystrixCommand 中的配置项进行配置，在 Sentinel 中可能须要通过 Sentinel 动静规定的形式进行配置，在 Istio 中可能又是另一套配置形式。不同框架治理配置形式的不统一使得微服务对立治理管控的复杂度相当高。 基于以上背景，由 阿里云、bilibili、中国移动、SphereEx 等企业及 Kratos、CloudWeGo、ShardingSphere、Database Mesh、Spring Cloud Alibaba、Dubbo 等社区独特发动的 OpenSergo 我的项目应运而生。OpenSergo 是凋谢通用的，笼罩微服务及上下游关联组件的微服务治理我的项目，从微服务的角度登程，涵盖流量治理、服务容错与自愈、服务元信息治理、平安治理等要害治理畛域，提供一系列的治理能力与规范、生态适配与最佳实际，反对 Java, Go, Rust 等多语言生态。 OpenSergo 的最大特点就是以对立的一套配置/DSL/协定定义服务治理规定，面向多语言异构化架构，笼罩微服务框架及上下游关联组件。无论微服务的语言是 Java, Go, Node.js 还是其它语言，无论是规范微服务还是 Mesh 接入，从网关到微服务调用，再到微服务对数据库/缓存的拜访，开发者都能够通过同一套 OpenSergo CRD 标准配置进行对立的治理管控，而无需关注各框架、语言的差别点，升高异构化、全链路微服务治理管控的复杂度。 OpenSergo 涵盖的微服务治理要害畛域： 流量治理与服务容错：流量路由、流量染色、全链路灰度、流量防护与自愈（流量管制、服务熔断、容错防抖）微服务视角的数据库与缓存治理：端侧连接池治理、读写流量路由、SQL 流控等服务元信息与服务发现 OpenSergo 提供 Java、Go 等多语言的 SDK，各个框架生态能够十分不便地通过 OpenSergo SDK 来对接 OpenSergo 标准配置，接入到 OpenSergo 生态中，通过 OpenSergo 管制立体 (Control Plane) 对立治理服务治理规定。 为什么须要流量防护与容错？微服务的稳定性始终是开发者十分关注的话题。随着业务从单体架构向分布式架构演进以及部署形式的变动，服务之间的依赖关系变得越来越简单，业务零碎也面临着微小的高可用挑战。大家可能都经验过以下的场景： 演唱会抢票霎时洪峰流量导致系统超出最大负载，load 飙高，用户无奈失常下单；在线选课时同一时刻提交选课的申请过多，零碎无奈响应；页面服务中某一块内容拜访很慢，始终加载不进去，导致整个页面都卡住，无奈失常操作 影响微服务可用性的因素有十分多，而这些不稳固的场景可能会导致严重后果。咱们从微服务流量的视角来看，能够粗略分为两类常见的运行时场景： ...

作者：阿里云可观测 Kafka 作为以后宽泛应用的中间件产品，承当了重要/外围业务数据流转，其稳固运行关乎整个业务零碎可用性。本文旨在分享阿里云 Prometheus 在阿里云 Kafka 和自建 Kafka 的监控实际。Kafka 简介Kafka 是什么？Kafka 是分布式、高吞吐、可扩大的实时数据流平台。 Kafka 宽泛用于日志收集、监控数据聚合、流式数据处理、在线和离线剖析等大数据畛域，已成为大数据生态中不可或缺的局部。 Producer： 通过 push 模式向 Kafka Broker 发送音讯。发送的音讯能够是网站的页面拜访、服务器日志，也能够是 CPU 和内存相干的系统资源信息。 Kafka Broker： 用于存储音讯的服务器。Kafka Broker 反对程度扩大。Kafka Broker 节点的数量越多，集群的吞吐率越高。 Group： 通过 pull 模式从 Kafka Broker 订阅并生产音讯。 ZooKeeper： 治理集群的配置、选举领导（Leader）分区，并且在 Group 发生变化时，进行负载平衡。 Kafka 特点劣势1. 通信模式： 支持列队和公布/订阅两种通信模式。 2. 高吞吐量、低提早： 在较便宜的硬件上，Kafka 也能做到每秒解决几十万条音讯，提早最低只有几毫秒。 3. 持久性： Kafka 能够将音讯长久化到一般磁盘。 4. 可扩展性： Kafka 集群反对热扩大，能够动静向集群增加新节点。 5. 容错性： 容许集群中节点失败（若正本数量为 n,则容许 n-1 个节点失败）。 须要留神的问题1. Topic/分区数过多，导致性能急速降落： Kafka Topic/分区过多（如，对于一般磁盘，单机超过 500 个topic/分区），会导致存储碎片化，load 会产生显著的飙高景象，topic/分区越多，load 越高，发送音讯响应工夫越长。 ...

作者：阿里云容器服务 近日，阿里云容器服务 ACK 与达摩院数据决策团队单干的论文《AHPA: Adaptive Horizontal Pod Autoscaling Systems on Alibaba Cloud Container Service for Kubernetes》获 AAAI 2023 IAAI 人工智能翻新利用奖 [ 1] 。AAAI 是人工智能畛域的顶级会议之一，入选中国计算机学会（CCF）举荐 A 类国内会议列表。AAAI/IAAI 次要收录人工智能在工业界胜利利用的案例，备受工业界关注，每年仅有 10 项左右工作被评比为 IAAI 人工智能翻新利用奖，往年 AHPA 也有幸获此殊荣。 AHPA 论文截图 团队介绍阿里云容器服务 ACK 治理着海量的 Kubernetes 集群，在集群治理、集群运维等畛域积攒了丰盛的教训，并构建了智能运维平台 CIS(Container Intelligence Service)，旨在通过智能化伎俩解决运维难题。达摩院数据决策团队在工夫序列剖析/预测/异样监测/AIOps 方向深耕多年 [ 2] ，数十篇文章发表在 NeurIPS, ICML, AAAI, KDD, SIGMOD, ICDE 等顶会和多篇中美专利，取得 2022 ICASSP AIOps Challenge(故障定位)冠军等多个国内奖项。 AHPA“极致弹性”吸引着泛滥企业拥抱云原生。企业的业务流量往往呈现出显著的波峰、波谷状态，如果采纳固定实例数的形式则会造成较大的资源节约。为此，Kubernetes 提供了 HPA、CronHPA 等弹性伸缩策略。CronHPA 反对在固定工夫进行实例数伸缩，然而设定定时规定较为简单，也会存在资源节约；HPA 策略依据利用实时负载设置实例数量，然而存在弹性触发滞后的问题，导致利用的服务质量降落。为此，容器服务 ACK 联结达摩院时序智能团队独特打造了 AHPA，能够依据历史时序数据进行被动预测，防止弹性滞后。同时会依据实时数据动静调整被动预测后果，兼容周期变动、数据失落等场景。 ...

云原生架构下，网关承载着流量治理、服务调用、平安治理等多重职能，在稳定性、性能、安全性、易用性上存在着更高的要求。在 CNCF Landscpae 编排和治理的 API Gateway 畛域中，曾经有不少开源的网关抉择，开发者们也有着不小的选型诉求。 云原生网关 Higress 开源后，引起了开发者们的热烈探讨，咱们整顿了大家在 GitHub、钉群、微信群探讨的问题，并将答复汇总如下，不便各位更精确的读懂 Higress，也十分欢迎您和咱们一起共建、定义 Higress。 Q1：Higress 当初适宜上生产零碎么？ A1：举荐公布 GA(General Availability)版本后再上生产，现阶段能够通过浏览源代码、测试环境试用来相熟我的项目。 Q2：Higress 和 Envoy Gateway 有什么区别？ A2：Higress 是基于 Envoy 实现和扩大的，和 Envoy Gateway 一样遵循 Gateway API 规范，不同的是，还提供了： Waf 防护、认证鉴权等平安插件能力多注册核心、协定转化、限流降级等服务治理插件能力，例如，对于传统应用 Dubbo 的微服务用户心愿应用原生 RPC 形式裸露对外服务，但通常提供内部拜访的服务以应用 HTTP 为主，为了帮忙 Dubbo 用户升高服务裸露的开发成本，Higress 提供了 HTTP 转 Dubbo 协定性能，且通过 Console 为用户提供白屏化的配置形式，某客户应用后反馈“这是业界完成度最高的 HTTP 转 Dubbo 协定”性能。反对 WASM、Lua 等自定义插件，例如 Nginx 用户，咱们还会反对过程外插件，满足多语言用户诉求，尤其是 Java 用户因现阶段 Java 社区对 WebAssembly 反对尚不欠缺但又心愿对网关进行扩大的诉求。Q3：Higress 和阿里巴巴的另一款开源网关 Tengine 有哪些不同？ ...

作者： 贺迷信（晨末） 背景纵观软件研发的倒退历程，如果说“业务需要开发”是外围主线的话，那么研发效力建设就是这一外围主线之外最大的一条干线。每个历史阶段的研发效力所面对的主要矛盾次要矛盾都不一样，因而大家能够看到，在不同的历史阶段产生了不同的“研发效力晋升产品”：从文本编辑器到带有各种性能的 IDE（Integrated Develop Environment），从繁多的命令行脚本到笼罩代码公布全生命周期的 CI/CD 零碎，从各种“上古时代”的合作表格或文档到目前曾经倒退出的横跨软件研发生命周期、笼罩软件开发要害维度的在线合作零碎，仿佛你能想到的降本提效的办法和路径，都有人帮你做了业余的产品用来满足你的各种要求和不同凡响的偏好。 可是实际上从实在的体验来看，“研发效力”的大山好像从未被撼动过，让决策者和执行者经验着种种怪现象： 一方面，只管从一线 leader 到一线研发同学都被各种工具全副武装到牙齿，日会连着周会，周会连着复盘会，然而研发效力建设获得的后果仿佛很难让决策者称心：看不到投入的人力物力在短期内给业务倒退带来的踊跃影响，只能在“深信大方向正确”的根底上狐疑研发效力建设的执行过程有问题。 另外一方面反观研发效力建设过程的一线亲历者们，除了业务需要的 deadline 之外，所有人还要恪守领导划下的 guideline，去关怀月度编码量的 redline，以及年度需要交付数量的 bottomline。最终所有人的理论体感就是：会没少开、代码没少写、事件反而变多了，最终整体效率变低了：白天散会早晨编码，写进去的 BUG 能够绕地球 365 天（理论能够绕几圈不晓得，然而简直天天要解 BUG 是必定的）。 从决策者的维度来看，看不到研发效力建设一段时间后的踊跃影响，个别起因有两方面，一方面是实际上曾经产生了踊跃影响却不感知、更有甚者无奈感知。这种状况的本源就在于信心要做研发效力建设的人，没有明确的短期指标，也没有明确的中长期指标，所以事件做了，但不晓得做到了什么水平，更不晓得怎么掂量做到了什么水平。另外一方面是做了很多事件破费了很多人力同时也激发了很多矛盾抵触，然而的确没有对业务倒退产生踊跃影响。决策者的信念也在随之波动，犹豫之中还得持续保持那些本人都在狐疑是不是样子工程的各种措施。这些“为了效力而最终却不怎么效力”的状况，则在于决策者没有搞明确研发效力要解决的问题到底是什么、怎么执行能力失去所有人的卓有成效的反对，只是“他人做了我也要做，别管我做的怎么样，就看我做的跟XX团队像不像”。 从执行者的维度来看，大家感觉事件变多了效率变低了，次要是因为真正“吃效率”的怪兽仿佛始终是藏在屋子里的大象（比喻不言而喻的事物却被人熟视无睹），所有人都熟视无睹，岂但决策者伪装它不存在，上下游协作者也伪装它不存在，甚至连咱们一线研发团队本人也感觉不到它的存在，这也是为什么产品经理经常问你：“我这个月不就是提了这么几个需要么，你怎么会又双叒叕（you、shuang、ruo、zhuo）延期呢”，而你只能回之以满脸的迷茫和后知后觉的愤恨，因为你既不晓得本人的工夫去哪了，也不违心在本人曾经致力得要死的状况下还得背一个不能按时交付需要的黑锅。没错，你在日常工作中用各种工具、各种快捷键、各种飞花摘叶信手拈来的代码片段节俭进去的 10 分钟，抵不过一场 15 分钟都没把问题聚焦起来的对焦大会；你用 git + docker + CI/CD 零碎+蓝绿公布偶然还来下金丝雀公布一整套云原生奢华大礼包跑齐全部流程节省下来的 60 分钟，也抵不过产品经理路过你工位时沉甸甸的给你来一句“需要要改了，早晨加个班”；当然，你用 teambition + 甘特图 + 我的项目工作燃尽图吃力脑汁地做多我的项目并行排班并发推动多条工作线最初节俭进去的 10 天，也抵不过 leader 拉你进入紧急处理群，外面看到的第一句话就是“老板改想法了”。 从决策者到执行者，但但凡在研发效力建设的过程中鸡飞狗跳的，无一不是因为认不清研发效力的实质所以只能邯郸学步随大流，器重它却又不是那么真正地关怀，不愿真正投入精力所以只会机械应酬考核指标从而自欺欺人。在失败的研发效力建设实际过程中，从业务方到产研团队，从决策者到执行者，所有人都是受害者。 为了早日解脱研发效力建设方面的一些误区，走出盲区，能与大家一起变成研发效力建设的受益者，本文会从以下几个方面开展： 先按惯例讲清楚研发效力的实质。联合作者目前正在进行的研发效力建设来抛砖引玉，给面临同类问题的读者提供一个参考；最初联合上一篇《技术一号位的方法论【业务篇】——如何设定业务指标》中讲的一些办法，给出作者在研发效力方面的定制的指标体系，向读者提供“如何定制业务指标体系”的参考样例。本文内容判若两人十分长，文章最开始提供目录，不便大家筛选感兴趣的内容浏览： 一、背景 二、“效力”的定义 2.1 什么是效力 2.2 什么是研发效力 2.3 研发过程的分层模型 2.4 研发效力建设是过程治理、后果掂量、成果评估体系的综合体 2.5 研发效力在业务效力建设中的地位 2.6 研发效力建设与业务生命周期的辩证关系 2.7 研发效力建设与研发团队类型的辩证关系 三、全面构建综合性研发效力晋升体系 四、实际案例介绍 4.1 背景状况介绍 ...

一项技术的全面遍及和通用化，必然会经验标准化的过程，微服务技术也不例外。2022 云栖大会上，阿里云智能云原生利用平台总经理丁宇公布了微服务引擎 MSE 3.0，通过提供凋谢规范、易于集成、易于扩大、稳固牢靠的注册和配置核心、微服务治理和云原生网关，升高了微服务在云原生时代的演进老本。 注册配置核心标准化，谋求更强性能和更高稳定性2018 年，随着阿里巴巴将 Nacos、Sentinel、Seata 等一系列微服务组件开源后，使得国内微服务开发者在 Spring +Netflix 之外多了一套微服务开源技术栈的抉择，这也减速了微服务技术的遍及和落地。 现在，在注册和配置核心畛域，Nacos 曾经占据了50%以上的市场份额[1]，成为了该畛域的事实标准。明天，阿里云发微服务引擎 MSE 3.0，第一大外围能力就是注册和配置核心，相比 Nacos 等支流开源计划，MSE 的性能晋升了 40%，并通过提供 70+的监控指标和衰弱检测，来帮忙客户实现服务异样自治。 禾连衰弱是一家医疗衰弱行业的 SaaS 企业，通过 MSE 注册配置核心，晋升开源注册配置核心性能达 50%，解决了业务高速倒退中的扩展性问题，保障全国 200 多个城市、2000 多家医院体验业务的稳定性超 99.99%。 微服务治理标准化，谋求升高公布危险和缩短构建周期开源升高了微服务的构建门槛，减速解决了微服务的落地问题，但也面临着新的命题。 微服务架构承载起越来越多的在线业务，服务间的调用越来越简单，然而，关系越简单、小的技术问题越可能被放大，造成大的线上故障，尤其是在软件公布过程中，引入的危险更不可控。而微服务治理能够缩小、甚至防止公布和治理大规模利用过程中遇到的稳定性问题。 然而，语言和服务框架的异构会使得微服务治理的老本出现指数级的减少，一是因为每个开源框架和协定针对微服务治理的定义概念和能力都不统一，二是大家的治理模型和治理规定也是不同的。采纳多种微服务框架或 RPC 框架混用的开发者比例已达 24%[2]。往年开源的 OpenSergo，正是为了解决在不同的微服务框架、通信协议之间达成共识，造成服务治理标准。 微服务引擎 MSE 3.0 的第二大外围能力就是微服务治理，源于阿里巴巴 10+的实践经验，遵循 OpenSergo  的微服务治理标准，通过无损上线下、全链路灰度、流量防护等技术手段帮忙客户打消 80%的软件变更危险、开发测试提效 50%，将微服务的施行周期缩短 30%。 致景科技是一家纺织产业的互联网企业，未修改任何代码就接入了 MSE 的微服务治理所有能力。基于开发环境隔离能力，测试环境的构建工夫由天计算升高到分钟级别，微服务的施行周期缩短了 30%，减速客户构建纺织服装纵向一体化的数智化综合服务平台。 云原生网关标准化，谋求更强性能和更高安全性在 K8s 风行之前，网关的入口流量扩散、诉求不尽相同，存在着流量网关、API 网关、微服务网关、集成网关的多种状态，且规范不对立，均是独立构建和保护；而 K8s 通过 Ingress 对立了网关的通信标准，使得流量网关、微服务网关等进行对立构建和治理成为可能，因而诞生了下一代网关——云原生网关。同时，网关入口对立后，建设复杂度减少，在对立治理、性能、稳定性和安全性上有更高的诉求。 微服务引擎 MSE 3.0 的第三大能力是云原生网关，咱们将流量网关、微服务网关、平安网关三合一，架构上也做了降级，将实例级防护降级至路由级防护，整体性能 ，相比传统网关晋升 90%。 费芮互动专一于挪动营销畛域的翻新和研发，每日须要解决 1 亿+粉丝交互，以及 4 万+线下门店、每月 3000 万+笔的挪动领取需要，对网关接入层的性能和稳定性有着较高的要求。通过 MSE 云原生网关构建了零信赖架构，大幅晋升业务入口安全性，采纳软硬件一体化，性能晋升 90%，响应工夫降落 50% 。 ...

咱们心愿让用户做得更少而播种更多，通过 Serverless 化，用云就像用电一样简略。11 月 5 日，激活利用构建新范式：云原生峰会再次聚焦 Serverless，进一步解读阿里云外围产品全面 Serverless 化的意义，重磅公布 Serverless 运行时降级，让云上利用构建更简略。 阿里云智能可观测&Serverless 负责人 司徒放主题演讲 Serverless 引领下一代利用架构要谈利用 Serverless 架构，首先要从云产品托管状态的演进过程去了解 Serverless。 “基础设施托管”是最根底的状态，产品交付的是计算、存储、网络等云资源，用户不仅须要本人在云上部署和运维应用软件和业务逻辑，还要解决软件运行可能遇到的种种问题。 “应用软件托管”是“基础设施托管”的向上延长，客户仍旧须要按“几核几G服务器”的模式来购买云资源，但由产品去提供常见应用软件（如 MySQL 等）的局部运维。 Serverless 全托管是进一步进化，客户不再须要关怀服务器，服务器由云产品全权治理，并且具备两个重要特色：一是按理论使用量付费，更加靠近“电网”模式：例如按申请调用次数，或者按理论数据存储量，用多少付多少；二是自适应弹性、免运维：依据应用状况，云产品对底层资源进行主动伸缩，客户不须要提前预购资源，用完即回收。 Serverless 全托管的呈现正在深度影响和扭转着利用技术架构。 从企业级利用架构，到互联网分布式架构，服务化、可伸缩、松耦合等理念曾经深入人心，但分布式技术的施行复杂度却一直攀升。而 Serverless 的自适应、免运维可能大幅升高复杂度，其高弹性又充分发挥了云的劣势。依靠 Serverless 全托管产品，业务能力和云服务能力能够被形象成灵便、通用的模块状态。用户能够依据须要从中筛选模块，按需调整并把他们编排在一起，组装成本人的利用，从而大幅晋升研发效率。 从资源到服务，阿里云外围产品全面 Serverless 化 Serverless 并不是不必服务器，它是将服务器全权托管给了云厂商，依据业务流量大小主动弹性伸缩，开箱即用免去保护老本，按使用量计费。用户无需关怀和治理底层 IT 资源，只有聚焦业务代码，依据理论申请解决业务。 要想让用户用好 Serverless，单纯在利用运行时层面进行 Serverless 化是远远不够的，利用依赖的上游数据库等零碎，如果它们没有良好的弹性，就会成为零碎整体的“短板”。只有链路上所有的零碎都具备高弹性、高牢靠能力施展出 Serverless 最大价值。 目前，阿里云上曾经有超过 20 款外围产品提供了 Serverless 状态，在弹性速度、计费模型上帮忙客户业务更好的驾驭底层算力，节约老本；同时，围绕 Serverless 架构产品间严密单干，独特解决产品集成、联动伸缩等问题，为业务提供更丝滑的全链路 Serverless 体验。 阿里云是国内最早提供 Serverless 计算服务的云厂商。 2017 年推出的函数计算 FC 是一款 FaaS 产品，这是一种以事件驱动为外围的全托管计算服务，用户只需编写代码并上传，函数计算就会主动筹备好计算资源，以弹性、牢靠的形式运行代码，并提供残缺的可观测能力，大幅简化开发运维过程。 2018 年翻新推出的 Serverless 利用引擎 SAE 是业内首款面向利用的 Serverless PaaS 平台，屏蔽底层 IaaS 和 Kubernetes 的复杂度，提供了零代码革新迁徙、老本更优、效率更高的利用托管计划，帮用户实现单体 Web 利用、微服务利用以及定时工作的 Serverless 化。 2018 年当先业界推出 Serverless 容器服务 ASK，基于弹性容器实例 ECI（Elastic Container Instance），能够实现 1min 扩容 2000 个 Pod，升高了 Kubernetes 应用门槛，让用户更专一于应用程序，而不是治理底层基础设施。2020 年，阿里云开源的 Serverless Devs 成为业内首个反对支流 Serverless 服务/框架的云原生全生命周期治理的平台。往年，Serverless Devs 全程深度参加了信通院《基于无服务器架构的工具链能力要求》的规范制订，并在 9 月正式进入 CNCF Sandbox，成为业内首个入选的 Serverless 工具我的项目。 Serverless 运行时降级：云上利用构建更简略Serverless 利用核心：让 Serverless 更易开发Serverless 倒退至今曾经成为云计算的核心技术，支流场景都在通过 Serverless 解决问题，并且阿里云提供了残缺的工具链，让企业通过 Serverless 架构能够更简略地在云上构建利用，充沛享受 Serverless 化带来的红利。 ...

11月5日，2022 杭州 · 云栖大会-云原生峰会现场，阿里巴巴研究员、阿里云智能云原生利用平台总经理丁宇发表：云原生网关 Higress 正式开源，Higress 是一款标准化、高集成、易扩大、热更新的云原生网关。 Higress 源自阿里巴巴外部电商、交易等外围生产场景的实际积淀，遵循 Ingress/Gateway API 规范，将流量网关、微服务网关、平安网关三合一，并在此基础上扩大了服务治理插件、安全类插件和自定义插件，高度集成 K8s 和微服务生态，包含 Nacos 注册和配置、Sentinel 限流降级等能力，并反对规定变更毫秒级失效等热更新能力。 Higress 的前世今生诞生背景Higress 的创立源于阿里外部的“本地生存战斗”，该战斗始于“支付宝 2020 合作伙伴大会”，在此大会上支付宝发表降级为数字生存开放平台。该战斗的核心技术指标，是实现阿里巴巴业务域与蚂蚁业务域之间 RPC 间接调用，但因阿里巴巴与蚂蚁业务域网络是隔离的，即网络是不通的，很天然想到利用网关来解决此问题。 技术选型利用网关来解决阿里巴巴与蚂蚁跨业务域 RPC 互通问题，首先要对网关做技术选型。 置信大家也都或多或少晓得，阿里巴巴开源的反向代理程序 Tengine。Tengine 在阿里外部对立接入网关 AServer 中被应用，咱们团队就是负责其开发运维，同时咱们团队也在负责阿里巴巴 Service Mesh 的落地，不论是对 Tengine 还是对 Istio + Envoy 这套架构都比拟相熟。 在选型时，尽管也调研过一些其余的软件，但思考到网关对性能、可靠性的高要求，在联合咱们本身的网关运维教训，决定看看 Tengine 与 Envoy 是否能够满足咱们的业务需要，在比照时咱们列举了四个要害要点，其比照如下： 这里提一下“为什么咱们认为配置的热更新，是十分重要的”？ Tengine/Nginx 的配置更新须要 reload，reload 须要重启 worker 过程，重启时会引起流量抖动，对长连贯影响尤为显著。在网关的集群规模十分大时，更是不能随便的做 reload，这时就会引发一个矛盾点：业务向网关提交配置后，心愿能疾速验证，但受限于 reload 机制和稳定性要求，无奈满足业务疾速验证与疾速试错的诉求。 当初曾经有很多支流利用抉择采纳长连贯，HTTP 1.1 个别默认会应用 Keep-Alive 去放弃长连贯，后续 HTTP 2 以及 HTTP 3 也是如此，随着网络协议的倒退，将来应用长连贯会变得更加广泛。而配置热更新人造对长连贯十分敌对。 如何解决这点呢？ ...

作者：叶飞 ChaosBlade随着云原生的倒退，云原生利用一致性、可靠性、灵便编排的能力让大部分企业抉择将利用往云上迁徙，但同时云基础设施在稳定性、可观测、也承受的弱小的考验。 ChaosBlade 是阿里巴巴开源的一款遵循混沌工程原理和混沌试验模型的试验注入工具，帮忙企业晋升分布式系统的容错能力，并且在企业上云或往云原生零碎迁徙过程中业务连续性保障。 ChaosBlade Operator 是 kubernetes 平台试验场景的实现，将混沌试验通过 Kubernetes 规范的 CRD 形式定义，很不便的应用 Kubernetes 资源操作的形式来创立、更新、删除试验场景，包含应用 kubectl、client-go 等形式执行，同时也能够应用 chaosblade cli 工具执行。 本文将次要介绍 ChaosBlade 在 Kubernetes 中故障注入的底层实现原理、版本优化过程以及大规模利用演练测试。 资源模型在 Kubernetes 中部署利用，通常咱们会抉择将利用定义为 Pod、Deployment、Statefulset 等资源类型，这些都是 Kubernetes 曾经内置的；在理论利用中，面对对简单的利用场景，内置的资源类型是无奈满足咱们需要的，Operator 是一种解决简单利用容器化的一种计划，通过自定义资源和自定义控制器来实现简单利用容器化，chaosblade-operator 正是就是基于 Operator 实现的。 在 Kubernetes 中装置完 chaosblade-operator 后，会生成一个 deployment 资源类型的  chaosblade-operator 实例、一个 daemonset 资源类型的  chaosblade-tool 实例、一个自定义资源定义，当然还蕴含 RABC、SA 等等其余资源； chaosblade 将自定义资源类型定义为  chaosblade ，简称 blade ；每次新建演练就能够通过 kubectl 或者 chaosblade cli 创立 blade 实例资源，blade 资源自身也蕴含了 chaosblade 混沌试验定义； chaosblade-operator 会监听 blade 资源的生命周期，当发现有 blade 资源实例被创立时，同时就能拿到混沌试验定义，而后解析试验定义，去调用 chaosblade-tool 真正的注入故障； ...

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

作者：之卫 前言云计算带来的劣势之一便是弹性能力，云原生场景下 Kubernetes 提供了程度弹性扩容能力（HPA），让利用能够随着实时指标进行扩/缩。然而 HPA 的理论工作状况可能和咱们直观料想的状况是不一样的，这外面存在一些认知误区。本文总结了一下 EDAS 用户在应用 HPA 时常遇到的三个认知误区，具体如下： 误区一：HPA 存在扩容死区景象：当 Request=Limit 时，冀望利用率超过 90%时，无奈失常扩容。 起因分析：HPA 中存在容忍度（默认为 10%），指标变动幅度小于容忍度时，HPA 会疏忽本次扩/缩动作。若当冀望利用率为 90%时，则理论利用率在 81%-99%之间，都会被 HPA 疏忽。 避坑指南：当 Request=Limit 时，防止设置过高的冀望利用率，一来防止扩容死区；二来被动扩容有肯定的通畅工夫，留下更多的缓冲余量以应答突增流量。 误区二：误会利用率计算方法，HPA 扩容与预期使用量不符景象：当 Limit > Request 时，配置 50%的利用率，使用量未达到 Limit 的 50%便扩容。 起因分析：HPA 计算利用率是基于 Request 计算，当 Limit > Request 时，理论利用率是能够超过 100%。 避坑指南：对于较为重要的利用，该当设置 Request=Limit 保障资源的独占。对于能够容忍资源共享的利用，对应的冀望利用率也不应设置的过高，在集群资源缓和时，超量应用资源的 Pod 很有可能会被杀死，从而造成服务中断。 误区三：弹性行为总是滞后的，扩缩行为与心理预期不符景象：指标突增时，HPA 不会立即扩容，且扩容可能是分屡次进行，最终稳固时的实例数也与预期不同。 起因分析：HPA 的设计架构决定了，HPA 扩/缩容总是滞后的，且扩/缩容收到弹性行为（behavior）与容忍度独特作用。其中弹性行为限度了扩/缩容速率，不会一口气扩/缩到冀望实例数。而容忍度会疏忽指标的小幅度变动，从而导致在屡次扩容的场景下，最终计算的实例数可能与一开始计算出的实例数不同。 避坑指南：浏览下文理解一下 HPA 工作原理，配置正当的弹性行为（behavior）。 HPA 工作机理在突破认知误区前，咱们有必要梳理一下 HPA 的工作机理。 如图所示，HPA 控制器执行弹性性能次要分为四个步骤： 监听 HPA 资源，一旦生成 HPA 资源或者是更改 HPA 配置，HPA 控制器能及时感知并调整。 从 Metrics API 获取对应的指标数据，这里的 Metrics Server 又能够分为三类：<!----> ...

作者：易立(微垣) Kubernetes 作为云原生计算的根底我的项目，曾经在开发者和企业中取得宽泛的反对。然而其本身复杂性和平缓的学习曲线仍然让人望而却步。在 CNCF 2020 年度调研报告中，在 Kubernetes 技术落地过程中面临最大的挑战就是复杂性。 IBM大型机之父 Fred Brooks 驰名的论文 No Silver Bullet [ 1] ，软件系统中的复杂性能够分为实质复杂性 (essential complexity) 和从属复杂性 (accidental complexity) 。实质复杂性是构建零碎过程中不可避免的复杂性。从属复杂性则是任何非必要的复杂性，比方因为设计失误或者工具不当等引入的复杂性。从属复杂性会随着工具的改善而逐步解决，而本质性的艰难难以解决。 Kubernetes 的实质复杂性与从属复杂性到底有什么？咱们应该如何应答？ Kubernetes 的复杂性挑战分布式系统的复杂性在上世纪 90 年代，Sun 的几位工程师提出了分布式计算的八个舛误 [ 2] ，这也解释了为什么构建牢靠的分布式系统是一项艰巨的工程挑战。 作为分布式集群管理系统，Kubernetes 本身要面临着泛滥的复杂性，比方，节点宕机，网络抖动、组件版本不统一等等。此外 K8s 还要可能用正当的形象向下层利用屏蔽底层的不确定性、差异性和复杂性。 资源调度的复杂性如何高效地利用计算资源，升高计算成本是资源调度的重要指标。 Kubernetes 作为一个分布式集群管理系统，它的一个重要指标是：将适宜的资源分配给适宜的利用，满足对利用的 QoS 要求和取得最优的资源应用效率。 然而，分布式系统的资源调度有着十分高的复杂性。次要挑战包含： 对多状态异构资源的反对，明天利用所需的计算资源不只是简略的 CPU，内存，存储等，而且包含多样化的减速设施，比方 GPU、RDMA 等。而且，为了思考到计算效率的最优化，要思考到计算资源之间的拓扑，比方 CPU core 在 numa 节点间的布局，GPU 设施间 NVLink 拓扑等。此外随着高性能网络的的倒退，GPU 池化、内存池化等相继呈现，给资源调度带来更多的动态性和复杂性。 对多样化的工作负载的反对。从 Stateless 的 Web 利用、微服务利用，到有状态的中间件和数据利用，再到 AI、大数据、HPC 等计算工作类利用。他们对资源申请和应用的形式有不同的需要。 对多维度的业务需要的反对。调度零碎在满足利用对资源的需要的同时，也要满足不同的业务需要，比方计算效率，优先级，稳定性，利用率等等。调度零碎须要在多样化的资源和多样化的束缚之间进行动静决策，整体挑战很高。而且随着时间推移，集群中逐步呈现负载不平衡的景象，资源热点会导致。如何继续调整集群负载 基础设施环境的多样性不同的环境，比方，线下数据中心与云，不同的云供应商之间，他们在基础设施能力上有着很多差别。相似单机操作系统要能反对不同的硬件设施，一个分布式集群零碎要向下屏蔽基础设施的差别，并向下层利用提供统一的编程接口和体验，帮忙利用在不同环境中迁徙。 Kubernetes 的解决之道Kubernetes做出了几个重要的架构抉择，大大缓解了分布式集群管理系统的从属复杂性。 管制循环（Control loops）Kubernetes 架构的外围就是就是管制循环 （control loops），也是一个典型的"负反馈"控制系统。当控制器察看到冀望状态与以后状态存在不统一，就会继续调整资源，让以后状态趋近于冀望状态。 ...

作者：李斌、邱炜 背景咱们公司从 2015 年开始就使⽤ Dubbo 作为微服务框架，当社区推出 Dubbo 3 时，咱们也⽴刻跟进并做了深⼊调研，发现 Dubbo 3 的应⽤/实例级服务注册和发现模式可能在肯定水平上解决咱们以后注册中⼼⾯临的压⼒，解决稳定性和安全性问题。同时 Dubbo 3 在服务治理上也做了降级，符合云原⽣架构，⽽且 Dubbo 3 可能向下兼容 Dubbo 2，这也将升高降级的老本和⻛险。 降级我的项目有了阶段性的停顿，目前依然在进行中。通过本⽂，咱们对公司外部的 Dubbo 3 降级过程及收益等做了深⼊总结。 社区对于 Dubbo 3 的外围性能介绍Dubbo 社区对于 Dubbo 3 的文档和材料越来越欠缺，以下是咱们从社区援用的一些内容。 下一代云原生服务框架 Dubbo 3 被社区寄予厚望，将其视为下一代云原生服务框架打造，Dubbo 3 提供的外围个性列表，次要包含四局部。 全新服务发现模型。利用粒度服务发现，面向云原生设计，适配基础设施与异构零碎；性能与集群伸缩性大幅晋升。下一代 RPC 协定 Triple。基于 HTTP/2 的 Triple 协定，兼容 gRPC；网关穿透性强、多语言敌对、反对 Reactive Stream。对立流量治理模型。面向云原生流量治理，SDK、Mesh、VM、Container 等对立治理规定；可能反对更丰盛的流量治理场景。Service Mesh。在最新的3.1.0的版本中反对Sidecar Mesh 与 Proxyless Mesh，提供更多架构抉择，升高迁徙、落地老本。  首先是性能、资源利用率的晋升。社区材料显示，降级 Dubbo 3 的利用预期能实现单机内存 50% 的降落，对于越大规模的集群成果将越显著，Dubbo 3 从架构上反对百万实例级别的集群横向扩大，同时依赖利用级服务发现、Triple 协定等能够大大提供利用的服务治理效率和吞吐量。 其次，Dubbo 3 让业务架构降级变得更容易、更正当，尤其是 RPC 协定，在 2.x 版本中，web、挪动端与后端的通信都要通过网关代理，实现协定转换、类型映射等工作，Dubbo 3 的 Triple 协定让这些变得更容易与天然；并通过流式通信模型满足更多的应用场景。 ...

作者：binbin0325 背景介绍 随着微服务的风行，服务和服务之间的稳定性变得越来越重要。在 2020 年，Sentinel 社区推出 Sentinel Go 版本，朝着云原生方向演进。Sentinel Go 是一个流量治理组件，次要以流量为切入点，从流量路由、流量管制、流量整形、熔断降级、零碎自适应过载爱护、热点流量防护等多个维度来帮忙开发者保障微服务的稳定性。 无论是流量管制还是熔断降级，实现的核心思想都是通过统计一段时间内的指标数据（申请数/谬误数等），而后依据预选设定的阈值判断是否应该进行流量管控 那么如何存储并统计这一段时间内的指标数据则是外围要害，本文将揭秘 Sentienl-Go 是如何实现的毫秒级指标数据存储与统计。 固定窗口在正式介绍之前，先简略介绍一下固定窗口的算法（也叫计数器算法）是实现流量管制比较简单的一种形式。其余常见的还有很多例如滑动工夫窗口算法，漏桶算法，令牌桶算法等等。 固定窗口算法个别是通过原子操作将申请在统计周期内进行累加，而后当申请数大于阈值时进行限流。 实现代码： var ( counter int64 //计数 intervalMs int64 = 1000 //窗口长度(1S) threshold int64 = 2 //限流阈值 startTime = time.Now().UnixMilli() //窗口开始工夫)func main() { for i := 0; i < 10; i++ { if tryAcquire() { fmt.Println("胜利申请", time.Now().Unix()) } }}func tryAcquire() bool { if time.Now().UnixMilli()-atomic.LoadInt64(&startTime) > intervalMs { atomic.StoreInt64(&startTime, time.Now().UnixMilli()) atomic.StoreInt64(&counter, 0) } return atomic.AddInt64(&counter, 1) <= threshold}固定窗口的限流在实现上看起来比较简单容易，然而也有一些问题，最典型的就是“边界”问题。 ...

作者：千山 随着云原生架构开始落地实际，利用架构从单体零碎逐渐转变为微服务，越来越多企业意识到可观测能力曾经成为云原生的基础设施与必备能力。 那么，最近被频频提及的可观测性，相比监控、APM 等名词，区别在哪里？日前，51CTO 特邀阿里云资深技术专家周小帆，围绕可观测技术的演进等议题进行了采访。 为什么须要可观测性？它是云原生时代的必然产物吗？可观测性不是一个陈腐的名词，云原生时代被再次提及是一个必然的后果。云原生架构所提倡的微服务、DevOps 模式，同时带来了效率、可用性的晋升与复杂度的减少，而加强可观测性成了升高复杂度的惟一伎俩。传统监控伎俩仅仅可能做到问题被动发现，而可观测性则要求不仅发现问题，更对于问题景象背地实质给出清晰解释。可观测性背地指标、日志、事件、链路数据，以及诊断工具的联合应用，为事先预防、事中解决、预先复盘提供了重要决策依据。可观测性是基础设施自动化的基石，优良的可观测性是确保云原生红利高效开释的前提条件。 行业中时常会有“APM 已死，可观测已来”的论调，我不太认同。相同，我认为 APM 的产品状态曾经是在传统监控根底之上做到了”第一波进化“，首次实现了可观测三大支柱（指标、链路、日志）在应用层互相交融的最佳实际。 云原生时代的可观测，是将 APM 产品中的一些经典技术与理念，降级、延长、泛化至整个云的技术架构和组织，促成更严密的协同、笼罩更多场景、施展更大价值。企业数字化转型让业务成败与 IT 基础设施稳定性关联愈发严密，业务在线化凸显了用户体验的重要性。正如其倒退历史，可观测性不是一个陈腐概念，它本来就无处不在。而在云时代，随着散落在各处的可观测数据被一直连贯，小到问题定位发现，平安危险辨认，大到全局老本治理、稳定性治理甚至是业务增长，都依赖于可观测技术和数据，可观测性成为了度量企业 IT 治理程度的重要指标。 大家明天冀望可能失去的“可观测产品”，实际上大部分是在上一代 APM 产品根底之上的“第二波进化”，他们须要具备海量可观测数据的存算能力，以利用为核心，向上关联业务成败与用户体验，向下笼罩基础设施与云服务监控，一站式满足除了 IT 稳定性以外的多种外围诉求。 微服务下可观测面临的挑战微服务下的可观测能力建设有哪些难点？零碎的可观测与故障根因剖析作为重要的运维场景，随着零碎架构、资源单位、资源获取形式、通信形式演进过程，遭逢微小挑战。而这些挑战，也在倒逼着可观测相干技术倒退，接下来咱们以微服务举例： 随着 Spring Cloud 和 Dubbo 等常见微服务框架被广泛应用，微服务架构接受程度一直晋升，由最后以机器为外围的云服务器 ECS 上云，到以容器为外围的容器化云原生部署；为了更加麻利，开始以利用为外围的微服务化。在云原生下的微服务可观测次要面临三个挑战： 发现难：从云服务器 ECS 到容器 Kubernetes，微服务架构复杂度晋升，观测对象复杂度晋升，监测数据笼罩不全。定位难：随着多种治理能力深刻，可观测要求高，服务框架复杂度减少，技术门槛晋升，数据自身复杂度晋升，数据关联性差。合作差：随着组织角色变动，可观测不只是运维工作。 除此之外，还有微服务配置凌乱，不好梳理；微服务利用上 Kubernetes 之后，呈现线程池满，却找不到起因等一系列问题。因而，微服务可观测要解决在客户端输出申请后，能感知其在各服务间进行采集、传输、解决、存储的状态，进而预测、定位、解决零碎运行过程中呈现故障的问题。而这些问题，阿里巴巴在本身建设可观测体系的过程中也都遭逢过。 阿里巴巴可观测技术摸索之路阿里外部是基于什么诉求开始构建可观测能力？经验过哪几次重要的迭代？周小帆：作为最早进行云原生革新的互联网企业，阿里巴巴摸索与实际可观测技术由来已久，并经验过以下几个阶段： 第一代 – 一站式：脱胎于阿里巴巴「鹰眼」产品的利用实时监控服务 ARMS 诞生，为企业提供利用性能治理（APM）能力与前端监控、云拨测等数字化体验（DEM）能力；第二代 – 连贯利用：与利用托管与治理产品无缝集成，笼罩观测、平安、业务稳定性等多个刚需场景。第三代 – 超过一站式：1+1+1>3，让阿里云积攒的可观测技术、开源可观测事实标准、客户存量与自研的可观测数据资产做无缝交融，全面拥抱 Prometheus、Grafana、Opentelemetry 等开源规范，打造云原生时代残缺可观测数据生态与产品套件—阿里云可观测套件。第一代：脱胎于阿里巴巴「鹰眼」产品的利用实时监控服务 ARMS 诞生关键词：从单体走向微服务，自下而上的爆发式增长 2013 年，随着阿里巴巴业务疾速倒退，利用从单体走向微服务，微服务体系催生进来中心化组织架构，产生自下而上的爆发式增长，并疾速向 DevOps 模式演进，工程师们以自助模式向根底软件寻找更多答案。也是从这个阶段开始，监控走向“可观测”的畅想已初备雏形。对立 PaaS 层疾速催生对立可观测基础设施，但微服务下的可观测能力建设初期遇到以下两个难点：指标基数发散、微服务拆分过细、埋点精度一直回升等因素带来的“单笔交易可观测老本”的急剧回升；三代探针技术与管控体系演进带来的可观测数据起源品质问题，以及大规模探针管控与稳定性保障。 关键词：业务中台背地的数字化经营，引领自上而下的稳定性治理体系 与此同时，随着业务中台诞生，为了更好的应答季节性电商大促、多变的业务状态，服务治理、混沌工程等产品诞生进去，碎片化的可观测能力逐步被整合在一起，引领自上而下的稳定性治理体系，构建以业务 SLO 为外围的稳定性治理体系。 通过日志链路指标和诊断工具的整合，阿里巴巴外部 APM 产品的实用性失去大幅晋升，被大家所熟知的「鹰眼」雏形初现。观测能力和管控能力相交融：全链路灰度包含像全链路、灰度、全链路压测、混沌工程这样的简单治理伎俩，包含像容量评估，微服务之间的强弱依赖评估这样的剖析场景，都充沛集成到现有可观测能力中。并在此阶段以利用为核心，以管控集成、畛域常识积攒为主，让数据在一些关闭场景内可能实现价值最大化。 2017 年，阿里巴巴将外部锻炼多年的监控工具对外服务，利用实时监控服务 ARMS 正式商业化。作为云原生一体化可观测性平台，ARMS 提供全栈式性能监控和端到端全链路追踪诊断能力。同时，联合阿里云日志服务 SLS 的日志数据分析能力以及云监控丰盛的云服务与基础设施监控能力，用户能够轻松实现用户体验、应用服务、云产品、容器的一站式监控。 ...

作者：子白 AHPA 介绍背景Kubernetes 中利用实例数设置有固定实例数、HPA 和 CronHPA 三种策略。应用最多的是固定实例数，然而很多业务都存在波峰浪谷，如果采纳固定实例数的形式会造成较大的资源节约。Kubernetes 中提供了 HPA 及 CronHPA 两种机制实现按需扩容实例数量，缩小资源节约。CronHPA 是用户设定定时规定，在固定工夫进行实例数伸缩。然而设定定时规定较为简单，如果定时距离设置较大就会造成资源节约。HPA 能够依据利用实时负载设置实例数量，当利用负载高时扩容，当利用负载低时则缩容实例。HPA 是基于实时负载进行扩容，只有当负载曾经比拟高时才会触发扩容，但此时业务曾经处在高负载中因而业务局部流量呈现响应慢或者超时的问题，即存在“弹性滞后”的问题。为此，咱们提出了一种智能化弹性伸缩计划 AHPA，能够依据历史时序数据进行被动预测，提前扩容，防止弹性滞后。同时，会依据实时数据动静调整被动预测后果，兼容周期变动等场景。 图 1 各种弹性伸缩策略比照图 AHPA 架构 图 2 AHPA 框架图 AHPA 整体架构如图 2 所示，分为数据采集、预测及弹性伸缩三大部分。 Data CollectionData Collection 模块负责从数据源收集数据并将数据转为对立的格局传入给 Prediction 模块。数据源反对如 Prometheus、Metrics Serve、Log Service 以及其余自定义的监控平台。 指标蕴含 CPU、Memory、GPU 等资源指标，也包含 QPS、RT 等业务指标，同时也反对其余用户自定义指标。Adapter 模块负责将从多个数据源收集的各类指标转为对立的格局输出给 Prediction 模块。 PredictionPrediction 模块负责依据输出指标预测所需的 Pod 数量。Preprocessing 负责数据预处理，如过滤非 Running 状态的 Pod 利用率、解决缺失数据等。实现预处理后将时序数据传递给 RobustScaler [ 1] 算法模块。该模块将在第二局部具体介绍。 Revise 模块负责对 RobustScaler 模块给出的预测 Pod 数量进行修改。RobustScaler 分为 Proactive 和 Reactive 两种模式，用户也会为利用 Pod 数量设置上上限。为保障利用安稳运行，咱们采取尽快扩，迟缓缩的策略，因而 Revise 模块会取 Proactive、Reactive 及用户设置的上上限中最大值作为预测的 Pod 数量。 ...

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

作者：易立 本文依据作者在 9 月 20 日由中国计算机学会组织的 CCF TF 会议演讲整顿。明天数字化的生产与生存形式成为后疫情时代的新常态，云计算也曾经成为社会的数字化基础设施。如何利用云原生技术帮忙企业实现降本增效是很多 IT 管理者和开发者关注的话题。 背景阿里云容器产品家族 阿里云容器产品 ACK 笼罩了从公共云、边缘云、到本地数据中心的各个场景，让所有须要云能力的中央，都能取得对立的容器基础设施。 容器服务 ACK 反对了内部数万企业客户 IT 架构的容器化，优化上云老本，晋升用云效率，同时 ACK 也是很多阿里云产品的基础设施，撑持云产品的 Serverless 化。比方阿里云上音讯服务、RDS 数据库、数据湖剖析、弹性 AI 服务等等。同时容器服务也撑持了阿里团体的全面云原生化，目前规模已达到数千万核。 FinOps 与云原生 站在经济学角度，云计算是将 IT 的固定成本转化成为可变老本，这对企业传统的 IT 老本治理办法也带来了挑战。于是 FinOps 理念也应运而生。 在 FinOps 基金会的定义中：FinOps 是一种一直倒退的云财务管理科学与实际，通过数据驱动的收入决策帮忙工程、财务、技术和业务团队进行合作，使组织可能取得最大的业务价值。 FinOps 是“Finance”和“DevOps”的综合体，强调业务团队和工程团队之间的沟通与协同。在 FinOps 施行过程中咱们能够将其划分为：老本洞察、老本优化、老本经营三个阶段，帮忙企业通过数字化伎俩实现老本可视，可优化与可控。 利用云原生技术实现上云效益优化，能够从几个档次动手： 在基础设施层，咱们关注的要点有： 用法 – 抉择适合的算力适配工作负载，比方对高性能计算等场景，抉择计算型实例，或者利用 GPU、RDMA 等减速设施实现降本提效。用量 – 依据工作负载的特色，进行正当的容量布局。价格 – 抉择包年包月、按量付费，采纳不同计费办法，在资源的确定性、老本之间进行正当取舍。 在容器编排层，咱们关注在分布式集群上，让利用更加稳固、高效地运行，并充分利用云的弹性能力降低成本。 在利用架构层，咱们既须要解决架构中的性能瓶颈，也须要关注利用架构的现代化，并将稳定性、可观测性、平安等在研发流程左移，实现利用生命周期中的老本效率优化。 明天我会将聚焦在容器编排中的智能弹性、工作混部与数据减速等几个方面介绍如何实现老本优化和效率晋升。 Kubernetes 实现基础设施弹性与利用弹性 弹性是云最外围的能力之一，能够无效升高计算成本，ACK 在资源层和应用层提供了丰盛的弹性策略。 在资源层，当 K8s 集群资源有余时，ACK 集群能够利用 cluster-autoscaler 在节点池中主动创立新的节点实例。ACK 能够依据利用负载，抉择 ECS 虚拟机、神龙裸金属实例进行扩容。 ...

作者：铖朴、就砺 新版本预览本次公布的 Spring Cloud Alibaba 2.2.9.RELEASE 和 2021.0.4.0 两个新版本，别离基于社区 2.2.x 和 2021.x 两个骨干分支进行的构建公布，其中 2.2.9.RELEASE 版本通过首次给 Spring Cloud 生态带来了阿里巴巴外部应用多年的异地多活能力，对规模较大的中大型企业构建高可用利用提供了参考解决方案。另外，咱们在 2.2.9.RELEASE 和 2021.0.4.0 版本中提供了服务的 IPv6 地址注册与调用能力，可帮忙利用实现 IPv4 向 IPv6 的迁徙。具体的新版本预览内容如下： 2.2.9.RELEASE是在 Spring Cloud Hoxton.SR12、Spring Cloud 2.3.12.RELEASE 的根底上，基于 Ribbon 负载平衡实现了针对 Spring Cloud 利用的异地多活能力。另外，对生态中原有的包含注册配置核心、分布式音讯等在内的泛滥组件进行了降级，属于一个重大个性公布的新版本。本次公布的 Spring Cloud Alibaba 2.2.9.RELEASE 版本对以下组件版本进行了降级： Seata：降级到了 1.5.2 版本 [ 1] ，该版本反对 xid 一致性负载平衡能力，以及修复了一些之前版本所裸露的平安危险问题。RocketMQ：降级到了 4.9.4 版本 [ 2] ，该版本提供了轻量级音讯队列和为提早音讯提供异步发送性能等在内的诸多个性。Sentinel：降级到了 1.8.5 版本 [ 3] ，该版本提供了主动提取参数当应用 ParamFlowSlot 时，以及修复了局部 DashBoard 的 bugs。除了组件降级，另外也修复了一些之前版本所存在的问题，进一步晋升了Spring Cloud Alibaba 应用的稳定性与健壮性。更多内容可参见文末该版本相干发版布告 [ 4] 。 ...

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

作者：王焦 容器和 Kubernetes 的倒退成熟为利用的云原生化提供最根底的撑持，从而使企业最大化利用云上的资源。存储作为利用运行的基石，也在服务云原生化的过程中一直演进。 容器化利用 I/O 性能优化挑战目前在云上的容器化利用场景抉择存储计划时，通常会应用块存储（EBS），文件存储（NAS，CPFS，DBFS）和对象存储（OSS）三种，POSIX 语义的文件系统是面向容器存储应用场景最直观和最敌对的形式，通常也是容器场景下应用最多的存储拜访形式。另一方面，为了实现集群级别的存储编排能力，K8s 在保护容器组（Pod）的生命周期中会将依赖的存储卷以文件系统的模式挂载到容器内，从而从利用角度能够无差别地读写块存储、文件存储和对象存储的外置存储。 当初，云原生利用的规模化趋势日益显著，在大数据分析、AI 等数据密集型场景也失去越来越宽泛地利用，这些场景对 I/O 性能的要求很高。而现实情况是，云上的文件存储和对象存储个别都是以 TCP 和 HTTP(s)协定提供存储服务，是典型的客户端服务器（CS）模式，传统的服务端监控是通过发起者的 IP／连贯来辨别不同的利用，但在容器模式的部署中一个虚拟机／物理机节点能够部署数十个到数百个容器，一个利用能够跨多个主机。因而，传统的服务端监控在古代的容器化部署中不能提供足够的观测粒度和维度来剖析不同利用的 I/O 个性。 基于 ACK CNFS 存储卷的 I/O 可观测性框架为了帮忙企业疾速定位引发容器化利用 I/O 瓶颈的问题，保障业务继续稳固运行，阿里云容器文件存储 ACK CNFS 提供了面向利用和集群维度的 I/O 可观测性框架， 包含 POSIX 细粒度操作可观测性、容器组粒度的可观测性、跨机多正本的利用级可观测性，以及集群维度针对文件系统和对象存储的聚合拜访个性等，帮忙用户构建对立的客户端 I/O 性能问题监测和剖析能力 什么是 CNFS？容器文件存储（CNFS）是对文件存储和对象存储的生命周期治理逻辑形象对象，通过提供 CNFS-OSSFS，CNFS-NAS，CNFS-CPFS，CPFS-DBFS 等存储类（StorageClass）来实现对云上 OSS Bucket，NAS FileSystem，CPFS，DBFS 的全生命周期治理和动静卷（PV）的增删查改（CRUD）： CNFS-OSSFS 明天曾经被宽泛的应用在大数据，主动驾驶，生物计算畛域，作为拜访 OSS 的次要伎俩。 CNFS-NAS 曾经与弹性减速客户端（Elastic Acceleration Client）深度整合，在 NFS 客户端根底上优化了多连贯传输、反对了本地缓存/分布式缓存，预读预写性能减速文件读写，目前曾经在 CICD，机器学习，生物计算等畛域宽泛应用。  CNFS-CPFSv2 作为低提早，百万级文件拜访的高性能存储，也曾经在高性能计算，主动驾驶，生物计算等畛域宽泛应用。 CPFS-DBFS 曾经作为数据库服务提供共享数据库文件存储，无效升高了数据库系统的多正本老本，目前曾经在云上数据库畛域 DBaaS 应用。容器存储卷 I/O 问题类型本文会以对象存储 OSS 拜访为例，通过 ACK 存储卷 I/O 可观测能力对利用内挂载的 I/O 个性剖析、问题诊断和针对热点利用/热点数据分析、挂载失败剖析来解决如下四类问题： 定位容器内利用哪些 I/O 操作高造成的零碎忙碌。 定位容器内利用元数据操作高造成的后盾零碎忙碌。 定位容器内利用数据操作高的热点文件系统和热点文件门路。 利用数据卷文件系统挂载失败剖析。存储卷监控仪表板大盘存储卷的监控仪表板蕴含三个大盘： ...

图片起源：预感2023 · 吴晓波年初秀 纵观过来几年云原生技术的倒退历程，凋谢、规范的开源生态对云原生技术继续演进起到极大推动作用。开源生态带来了泛滥云原生畛域技术创新，并成为技术提高的重要载体。目前，云原生计算基金会 CNCF 领有 148 个寰球开源我的项目，由中国互联网公司发动 37个，占比25%；其中阿里云主导及参加开源我的项目共计 13个，包含： KubeVela/ OpenKruise / sealer / Fluid / OpenYurt / ChaosBlade / Serverless Devs / Vineyard / Inclavare Containers / DragonFly / KubeDL / Open Cluster Management(OCM) / Dapr 此前，木兰开源社区统计了 CNCF Landscape 中的 580 个开源我的项目以及他们所对应的发动企业，察看到近八年来云原生畛域中企业的投入与其发动我的项目的影响力。得出结论，2022年阿里云在CNCF开发 者合作影响力排名中 ，位列寰球第二，仅次于谷歌。** 在多云、混合云畛域，  Kubernetes 经验了从单集群到多集群、混合云、多云状态进化的过程，次要聚焦解决：多地区、规模性、容灾/隔离问题。多云、多集群部署曾经成为常态，云原生进入多云治理服务的时代。过来一年，诸如OCM、Kubevela 等泛滥云原生多云开源计划致力于打造面向多云、多集群场景的利用治理平台，反对用户将云原生化的利用扩大到分布式云，全局视角对立治理和运维分布式云资源，解决混合云、分布式云带来的技术挑战。 在边缘计算畛域， CI/CD、DevOps、MLOps、容器和微服务等被利用到端和边缘。边缘计算云原生旨在通过云原生架构构建边缘计算（物联网、CDN、混合云等）云边一体化协同基础设施。通过云端托管边缘资源/利用，无缝对接丰盛云产品能力，提供边缘计算业务的自动化运维、高可靠性保障，晋升边缘计算业务翻新效率。过来一年能够看到，边缘计算正在成为云原生畛域的一个重要分支，面向不同的业务场景，CNCF涌现了十分多的开源我的项目，如 CNCF OpenYurt 等，并独特推动着这个新兴业务方向的倒退，在云边协同、设施治理、轻量化、云边网络等方面带来了大量翻新。 在利用交付畛域， 云原生技术的发展趋势正在朝着利用 Kubernetes 作为公共形象层来实现高度一致的、跨云、跨环境的利用交付而一直迈进。然而，只管 Kubernetes 在屏蔽底层基础架构细节方面表现出色，它并没有在混合与分布式的部署环境之上引入下层形象来为软件交付进行建模。因而，在云原生开源畛域诞生了以OAM/KubeVela 为代表的利用交付与治理平台，也是一个独立于运行时集群的利用交付管制立体。过来一年，KubeVela 在资源状态可视化、插件化，自动化等方面进行了全面的降级。此外，聚焦于云原生利用自动化（部署、公布、运维以及可用性防护）的开源我的项目 OpenKuise，旨在解决分布式软件的打包、散发与运行的标准化问题的我的项目sealer，都是云原生利用交付治理畛域的要害我的项目。 在云原生 AI 畛域， 在过来一年，不论是开源社区（典型我的项目如Fluid）还是商业计划（阿里云ACK云原生AI套件）都聚焦在继续优化异构资源效率和高效运行 AI 等异构工作负载上。 ...

作者：KubeVela 社区 在 InfoQ 最新颁布的 2022 中国技术力量年度榜单中，KubeVela 取得了 “十大开源新锐我的项目” 和 “开发者最青睐的十大开源我的项目” 两个大奖。 中国技术力量年度榜单是 InfoQ 主办的，聚焦于为数字化转型做出理论奉献我的项目的评比。在本次榜单评比过程中，InfoQ 在邀请宽广用户投票的同时，也组织了来自网易、华为、阿里、信通院、百度、腾讯等二十多位业内顶尖专家作为奢华评审团，助力榜单评比。其中，开源新锐我的项目从技术当先性、标杆案例落地、我的项目活跃度、部署老本、社区生态、业界公信背书、我的项目成熟度等多维度进行评比，最终得分由专家团打分（40%），用户投票 （30%）及 InfoQ 主编团（30%）形成。 感激 InfoQ 作为主办方，在短暂提供可信赖的内容的同时，举办了中国技术力量年度榜单的评比，助力更多优良开源我的项目和开源解决方案的价值被发现。 KubeVela 我的项目于 2020 年 11 月在社区发动，通过灵便的可扩展性将云原生技术组件和企业级利用连贯在一起，提供跨集群的对立编排、基础设施无关、灵便的利用交付工作流等外围个性，受到社区用户宽泛的青睐。2021年6月捐献给 CNCF 后始终位列 CNCF 寰球 TOP 级沉闷我的项目。目前在 GitHub 上领有 4500+ 的 Star，正在筹备进入 CNCF Incubation。至今已被阿里巴巴、招商银行、字节跳动、现实汽车、Napptive、Shein 在内的 300 多家海内外企业采纳。 KubeVela 现在的倒退和成就离不开社区来自十多个国家 300 多名贡献者的提交，以及合作伙伴的一直输出。感激社区中的所有贡献者，以及来自阿里巴巴、招商银行、Napptive、Guidewire Software、京东云、挪动云、亚信科技、谐云等公司的外围维护者继续投入！ 结语您能够通过如下资料理解更多对于 KubeVela 以及 OAM 我的项目的细节： 我的项目代码库： github.com/oam-dev/kubevela 欢送 Star/Watch/Fork！我的项目官方主页与文档：kubevela.io 从 1.1 版本开始，已提供中文、英文文档，更多语言文档欢送开发者进行翻译。我的项目钉钉群：23310022；Slack：CNCF #kubevela Channel退出微信群：请先增加以下 maintainer 微信号，表明进入KubeVela用户群： 点击此处查看 KubeVela 我的项目官网 ...

作者：余凯 本系列文章由余凯执笔创作，联结作者：阿里云云原生利用平台 谢石 对本文亦有奉献 前言近几年，企业基础设施云原生化的趋势越来越强烈，从最开始的 IaaS 化到当初的微服务化，客户的颗粒度精细化和可观测性的需要更加强烈。容器网络为了满足客户更高性能和更高的密度，也始终在高速的倒退和演进中，这必然对客户对云原生网络的可观测性带来了极高的门槛和挑战。为了进步云原生网络的可观测性，同时便于客户和前后线同学减少对业务链路的可读性，ACK 产研和 AES 联结共建，合作开发 ack net-exporter 和云原生网络数据面可观测性系列，帮忙客户和前后线同学理解云原生网络架构体系，简化对云原生网络的可观测性的门槛，优化客户运维和售后同学解决疑难问题的体验 ，进步云原生网络的链路的稳定性。 鸟瞰容器网络，整个容器网络能够分为三个局部：Pod 网段，Service 网段和 Node 网段。这三个网络要实现互联互通和访问控制，那么实现的技术原理是什么？整个链路又是什么，限度又是什么呢？Flannel， Terway 有啥区别？不同模式下网络性能如何？这些，须要客户在下搭建容器之前，就要根据本人的业务场景进行抉择，而搭建结束后，相干的架构又是无奈转变，所以客户须要对每种架构特点要有充沛理解。比方下图是个简图，Pod 网络既要实现同一个ECS的Pod间的网络互通和管制，又要实现不同 ECS Pod 间的拜访， Pod 拜访 SVC 的后端可能在同一个 ECS 也可能是其余 ECS，这些在不同模式下，数据链转发模式是不同的，从业务侧体现后果也是不一样的。 本文是[全景分析容器网络数据链路]第一局部，次要介绍 Kubernetes Flannel 模式下，数据面链路的转转发链路，一是通过理解不同场景下的数据面转发链路，从而探知客户在不同的场景下拜访后果体现的起因，帮忙客户进一步优化业务架构；另一方面，通过深刻理解转发链路，从而在遇到容器网络抖动时候，客户运维以及阿里云同学能够晓得在哪些链路点进行部署观测手动，从而进一步定界问题方向和起因。 系列二： 全景分析阿里云容器网络数据链路（二）：Terway ENI 系列三： 全景分析阿里云容器网络数据链路（三）：Terway ENIIP 系列四： 全景分析阿里云容器网络数据链路（四）：Terway IPVLAN+EBPF 系列五： 全景分析阿里云容器网络数据链路（五）：Terway ENI-Trunking 系列六： 全景分析阿里云容器网络数据链路（六）：ASM Istio Flannel 模式架构设计Flannel 模式下，ECS 只有一个主网卡 ENI，无其余从属网卡，ECS 和节点上的 Pod 与内部通信都须要通过主网卡进行。ACK Flannel 会在每个节点创立 cni0 虚构网卡作为 Pod 网络和 ECS 的主网卡 eth0 之间的桥梁。 ...

作者：跑步迎来2023年的阿里云云原生 步履匆匆，转眼间，咱们曾经站在 2022 年的拐点上，行将迈步迎向 2023 年。 这一年来，阿里云云原生始终陪伴着大家的每一天，共公布了657篇文章，同比去年增长了145篇，这些优质内容不仅来自于阿里云技术专家的笔耕不辍，也来自于企业客户、社区开发者们的投稿，感激你们日复一日地反对，将来，让咱们一起携手，期待更美妙的云原生愿景。 回望2022年度，咱们筛选了号内热度最高的 TOP 20 文章，与大家再次一起回顾。 01 祝贺我的共事丁宇入选年度 IT 领军人物 CSDN 和《新程序员》特地举办“开发者生态汇 —— 2022 IT 技术影响力之星”流动，表彰技术生态优良代表，致敬推动行业倒退的技术英雄们！通过近 4 个月的评比，最终各项获奖名单出炉。其中，阿里巴巴研究员、阿里云智能云原生利用平台负责人丁宇（花名：叔同）取得年度 IT 领军人物。02 31 家企业入选阿里云首期云原生加速器，共建云原生行业新生态 产业数字化浪潮中，云原生已成大势。3 月 9 日音讯，阿里云发表袋鼠云、谐云、黑湖科技、骞云科技等 31 家企业入选阿里云首期云原生加速器，其中超半数企业为 B 轮及以上融资，1/5 企业为 C 轮及以上。入选企业总估值超过 338 亿，笼罩制造业、新批发、互联网、医疗等多个畛域。多方单干减速行业新生态，独特实现云原生技术升级。03 KubeVela v1.2 公布：你要的图形化操作控制台 VelaUX 终于来了！ 在古代云原生技术之上打造一款帮忙开发者从开发、交付以及后续继续运维的一体化平台，始终是 KubeVela 演进的外围指标。在 v1.2 版本中，咱们围绕开发者体验新增了 UI 控制台组件（VelaUX），简化了编排 YAML 的复杂性，欠缺了插件体系建设，丰盛了云资源的扩大能力，减少了大量 CI/CD 等生态对接的能力，进一步欠缺了开发者端到端的应用体验。04 K8s 网关选型初判：Nginx 还是 Envoy？ 部署 MSE 云原生网关并不间接影响原有网关流量，通过 DNS 权重配置能够实现业务流量的平滑迁徙，对后端业务齐全无感知。05 深度解密｜基于 eBPF 的 Kubernetes 问题排查全景图公布 ...

作者：OpenSergo 为了营造良好的开源气氛，为我国开源产业倒退注入更多生机，中国开源云联盟(China Open Source Cloud League，简称“COSCL”) 组织发展了 2022 年度评选活动。并在明天的 2022 木兰峰会中颁布了评比后果。  2022 木兰峰会：https://ke.segmentfault.com/c...中国开源云联盟（COSCL）成立于 2012 年 8 月，在工业和信息化部信息化和软件服务业司领导下，挂靠在中国电子技术标准化研究院，现有我国 180 余家开源生态圈产、学、研、用成员单位。中国开源云联盟（COSCL）作为国家重点研发打算《云计算和大数据开源社区生态系统》我的项目的指定开源组织，致力于联合国内开源产业界相干方，在中国独特推动开源生态系统搭建、技术社区建设、开源我的项目培养、开源个人规范研制、开源技术推广应用、以及开源人才培养等工作，是国内支流沉闷的开源技术组织之一。 致力于构建微服务治理标准和实现的开源我的项目 OpenSergo，在本次评选活动中，荣获“优良开源我的项目” ，成为评比出的十三个年度优良我的项目之一。 感激中国开源云联盟作为主办方，举办了年度评选活动，联结产业各方独特探讨开源产业倒退方向和将来时机，推动我国开源产业的高质量倒退。 OpenSergo 由阿里云和 bilibili、SphereEx、中国移动等企业，以及 Kratos、CloudWeGo、ShardingSphere、Nacos、Spring Cloud Alibaba、Dubbo 等社区联结发动并开源，目标就是构建一个和语言无关、和技术状态无关，但贴近业务的对立服务治理标准和实现。 结语欢送参加 OpenSergo 社区共建，您能够通过以下形式分割咱们： 我的项目代码库： https://github.com/opensergo/...我的项目官网：http://opensergo.io/zh-cn/我的项目钉钉群：34826335退出微信群：请先增加以下 AlibabaCloud888 微信号，备注 OpenSergo 点击此处查看 OpenSergo 我的项目官网

本文是《容器中的Java》系列文章之 3/n，欢送关注后续连载 :) 。1 背景随着越来越多的云原生微服务利用的大规模部署，大家对微服务治理的能力需要越来越强。 Java Agent技术可能让业务专一于业务逻辑，与此同时，中间件通过Java Agent反对无侵入批改程序行为，提供微服务治理能力。 此外，Java Agent反对通过环境变量的形式注入，中间件、云产品团队能够通过设置环境变量来反对 所以目前基于Java Agent实现的云原生可观测、微服务治理能力被越来越多的采纳。比方开源的Skywalking、OpenTelemetry，商业化的阿里云MSE等，都反对Java Agent接入。 问题咱们以MSE微服务demo [ 1] 为例。 先在一个Kubernetes集群中装置好ack-onepilot，而后部署上述demo。 先能够拜访demo中的gateway，验证下能够失常工作： 您也能够参考MSE的帮忙文档 [ 2] 体验下全链路灰度等微服务治理能力。 咱们登陆容器时，就能看到注入的agent： 但这样的后果是容器中所有的JVM，都会挂载Agent。 比方java -version： 比方jstack: java/jps/jstack/jcmd等JDK自带的问题排查工具，都会去从环境变量加载Java Agent因为Java Agent是在JVM初期加载的，所以Java Agent会先消耗6-7s来加载agent逻辑。但作为JDK工具，其实没有任何业务逻辑，不须要微服务治理能力。能够不必加载Java Agent的咱们构想下这个场景：线上利用呈现问题了，运维同学要抓现场，下来就想jstack拉一下stacktrace信息。 后果先要加载java agent，岂但节约了CPU和内存，更容易错过问题排查的现场。 但，一边要通过环境变量无侵入注入Java Agent，一边又要不在某些过程内注入。看起来无解了？ MSE 携手 Dragonwell，让微服务治理更敌对首先，注入Java Agent与否，是JVM确定的。咱们只须要批改JVM即可。 在这一点上，Dragonwell团队有着丰盛的教训。 其次，咱们看下JVM的行为，现有的开源行为如下： JDK相干命令，都会从JAVA_TOOL_OPTIONS加载Java AgentOpenJDK9之后，引入了JDK_JAVA_OPTIONS，这个环境变量只会被java命令应用。jps/jstack等命令不会加载。有些JDK厂商，会有本人的扩大环境变量， 比方，IBM会读取IBM_JAVA_OPTIONS [ 3] ，开源后的OpenJ9开始应用OPENJ9_JAVA_OPTIONS [ 4] ，Oracle/OpenJDK应用_JAVA_OPTIONS。原本JDK_JAVA_OPTIONS可能很好的满足需要，但作为“你发任你发，我用Java8”的业务开发同学，稳固为先，所以 Java 8 是肯定要反对的。 通过和Dragonwell的讨（si）论（bi），确定了如下批改： DRAGONWELL_JAVA_OPTIONS，和IBM_JAVA_OPTIONS [ 3] 相似，设置某些只用于Dragonwell的Java参数。DRAGONWELL_JAVA_TOOL_OPTIONS_JDK_ONLY，和JDK_JAVA_OPTIONS相似。如果DRAGONWELL_JAVA_TOOL_OPTIONS_JDK_ONLY=true，则JAVA_TOOL_OPTIONS只会被java命令加载。jps/jstack不会加载环境变量、不会加载Java Agent。从用意上来说： 如果须要给java和jps等运维工具设置参数，而且这些参数是java通用的，那么应该设置给环境变量JAVA_TOOL_OPTIONS。如果须要给javaj和jps等运维工具j设置参数，而且这些参数是jvm厂商相干j的，比方是dragonwell特有的开关，那么应该设置DRAGONWELL_JAVA_OPTIONS。如果须要给java设置参数，然而不给运维工具设置，而且参数是java通用的，那么应该设置环境变量JAVA_TOOL_OPTIONS，并设置DRAGONWELL_JAVA_TOOL_OPTIONS_JDK_ONLY=true。 3.1. 如果是jdk9及以上，则应该应用更加规范的JDK_JAVA_OPTIONS。如果须要给java设置参数，然而不给运维工具设置，而且参数是jvm厂商相干的，那么应该设置环境变量DRAGONWELL_JAVA_OPTIONS，并设置DRAGONWELL_JAVA_TOOL_OPTIONS_JDK_ONLY=true。通过下面的革新，就能够做到只对业务Java过程加载Java Agent。同时不影响jps/jstack等JDK自带的运维命令。 当然，Dragonwell作为开源我的项目，探讨的整体流程都是在GitHub Issue [ 5] 上实现的，欢送围观、吃瓜、吐槽。** 最终成果让咱们应用最新的Dragonwell版本，跑一下业务利用，模仿一下运维场景： ...

作者：艾阳坤 目前 Apache RocketMQ 5.0 SDK [ 1] 正在社区开源，开发与迭代也在炽热进行中，欢送宽广社区的敌人们可能参加其中。咱们欢送任何模式的奉献，包含但不限于新 feature、bugfix、代码优化、生态集成、测试工作、文档撰写。更加欢送可能认领一个残缺的特定语言实现的同学，踏出第一步，你就是 contributor！更有惊喜礼品和成为 committer 的机会等着你！ 写在后面Apache RocketMQ 是由阿里巴巴团体捐献给 Apache 开源基金会的一款低提早、高并发、高可用、高牢靠的分布式消息中间件，并于 2017 年正式从 Apache 社区毕业，成为 Apache 顶级我的项目（TLP）。也是国内首个非 Hadoop 生态体系的互联网中间件顶级我的项目。 面向过来，RocketMQ 通过多年淘宝双十一的洗礼和考验，博得了诸多客户的认可和青眼。面向未来，RocketMQ 历久弥新，为了更好地迎接云原生时代的降临，基于存算拆散架构的 RocketMQ 5.0 应运而生。 RocketMQ 5.0 中引入了全新的无状态 Proxy 组件，在程度拓展，故障应急，多协定等方面都进行了诸多反对与改良（对于 RocketMQ 5.0 的具体介绍，欢送关注 Rocketmq 官网 [ 2] ）。同时也为接下来多语言客户端的实现打下了良好基础。 新的多语言SDKRocketMQ 5.0 客户端相比拟于 4.x 的版本进行了诸多改良，会是将来社区客户端演进的支流方向。RocketMQ 4.x SDK 的多语言反对并不完满，协定的较高复杂度和语言绑定的实现细节使得多语言的反对与保护都变得辣手，而用户对多语言的诉求是强烈的。值此契机，RocketMQ 5.0 基于 gRPC 正式推出了全新的多语言 SDK。 相比拟于 RocketMQ 4.x 的 SDK。RocketMQ 5.0 展现出了一副全新的风貌： 采纳全新极简的，immutable 的 API 设计，使得 API 上手更简略，跨语言的对齐也变得更加简略；欠缺的错误处理体系和错误码设计，开发者和用户对谬误的解决能够更加得心应手；在 PushConsumer/PullConsumer 之外新推出无状态 SimpleConsumer，实现逻辑轻量，用户能够自行治理生产侧音讯的接管与应答，同时也对有更多定制化需要的客户提供了便当。实现轻量化，代码量相比拟旧有实现缩减 3/4 以上，开发和保护的老本更低；标准化的 logging/tracing/metrics 输入，升高实现复杂度的同时，可观测性的晋升会使得生产环境下的问题更容易被捕获；gRPC 多语言个性，为 RocketMQ 5.0 客户端的多语言实现提供了撑持。RocketMQ 全新的客户端的协定层被替换，语言无关的 IDL 使得协定的保护和实现都更为极为简略。同时得益于 gRPC 弱小的生态体系，使得 RocketMQ 与周边的集成也变得更为简便。 ...

作者：草谷 背景MSE 提供了托管版的 ZooKeeper，领有比自建开源 ZooKeeper 稳定性更高的SLA，同时管控面提供了丰盛的服务自治性能。赶在2022年的岁末，MSE ZooKeeper 上线了一个十分实用的性能-数据导入导出性能，彻底解决了困恼用户长期以来无奈自助解决数据的问题。通过浏览本文，你能够疾速取得以下知识点和能力： ZooKeeper 的长久化文件原理什么场景下会应用到导入导出性能如何在 MSE 下面应用导入导出性能存储原理此次上线的导出性能反对的数据类型蕴含快照文件snap和事物日志，在介绍性能之前，咱们看下 ZooKeeper 的这2个数据文件是用来做什么的。 在 ZooKeeper 中，次要会产生2种和数据相干的长久化文件，一个是内存的数据快照 Snapshot 文件，另外一个是事务日志 log 文件；它们别离是什么作用，有什么区别呢？ 上面2段代码是 Snap 快照的写入内容和产生的机会： public void save( DataTree dataTree, ConcurrentHashMap<Long, Integer> sessionsWithTimeouts, boolean syncSnap) throws IOException { long lastZxid = dataTree.lastProcessedZxid; File snapshotFile = new File(snapDir, Util.makeSnapshotName(lastZxid)); try { snapLog.serialize(dataTree, sessionsWithTimeouts, snapshotFile, syncSnap); } catch (IOException e) { // }}private boolean shouldSnapshot() { int logCount = zks.getZKDatabase().getTxnCount(); long logSize = zks.getZKDatabase().getTxnSize(); return (logCount > (snapCount / 2 + randRoll)) || (snapSizeInBytes > 0 && logSize > (snapSizeInBytes / 2 + randSize));}能够看到，Snapshot 写入的是一个 DataTree 的数据结构，外面存储的是 ZooKeeper 的全量内存数据，而生成 Snapshot 的条件，次要波及到 snapCount，snapCount 是一个可配置的参数，默认是10W，也就是 Snapshot 是 Zookeeper 的内存快照，是一份全量数据，而这份全量数据，也并非实时写入到磁盘中的，须要达到肯定的条件才会写入。 ...

作者：扬少 前言在业务高速倒退过程中，如何最大化保障性能迭代过程中业务流量无损始终是开发者比较关心的问题。通常在利用公布新性能阶段，咱们会采纳灰度公布的思维对新版本进行小流量验证，在合乎预期之后再进行全量公布，这就是"渐进性交付"。该词最早起源于大型、简单的工业化我的项目，它试图将简单的我的项目进行分阶段拆解，通过继续进行小型闭环迭代升高交付老本和工夫。随着云原生架构一直倒退，渐进性交付被广泛应用在互联网业务利用中，开发者通过GitOps、CI/CD形式集成渐进式交付框架，让新性能交付以流水线的形式分批执行，利用A/B 测试、金丝雀公布等技术精细化管制每一批次的流量策略，充沛保障利用公布的稳定性。 什么是HigressHigress 是一款标准化、高集成、易扩大、热更新的云原生网关。 Higress 源自阿里巴巴外部电商、交易等外围生产场景的实际积淀，遵循 Ingress/Gateway API 规范，将流量网关、微服务网关、平安网关三合一，并在此基础上扩大了服务治理插件、安全类插件和自定义插件，高度集成 K8s 和微服务生态，包含 Nacos 注册和配置、Sentinel 限流降级等能力，并反对规定变更毫秒级失效等热更新能力。 更多对于 Higress 的介绍，能够参阅Higress官网 [ 1] 。 什么是Kruise RolloutKruise Rollout 是阿里云开源的云原生利用自动化治理套件 OpenKruise 在渐进式交付畛域的新尝试，反对配合流量和实例灰度的金丝雀公布、蓝绿公布、A/B Testing 公布，以及公布过程可能基于 Prometheus Metrics 指标自动化分批与暂停，并提供旁路的无感对接、兼容已有的多种工作负载（Deployment、CloneSet、DaemonSet）。 这里，相熟 Kubernetes 的小伙伴能够会纳闷，官网的 Deployment 工作负载不是有管制公布的策略吗？咱们为什么还须要 Kruise Rollout 呢？ 首先，Kubernetes 官网的 Deployment 中定义公布策略严格上不合乎渐进性交付的思维，它理论是滚动公布。尽管 Deployment 对于降级而言提供了 maxUnavailable 和 maxSurge 两个参数，然而实质上来讲 Deployment 它只反对流式的一次性公布，用户并不能管制分批以及精细化的流量策略。比方用户无奈严格控制新老版本之间的流量比例，只能依据理论 Pod 数量占比以及调用端的负载平衡策略；用户无奈做 A/B testing 策略，例如限度公司外部员工能够拜访新版本。当新版本呈现问题，只能从新执行一遍滚动公布切回老版本，这样不仅回滚速度慢，而且频繁线上变更自身就具备极高的不稳固因素。 再者，Kubernetes 只提供了利用交付的 Deployment 控制器，以及针对流量的 Ingress、Service 形象，然而如何将上述实现组合成开箱即用的渐进式交付计划，Kubernetes 并没有出规范的定义。 出于以上问题和考量，阿里云开始发动对渐进式畛域的摸索，联合多年来容器化、云原生的技术积淀，推出了无侵入、可扩大、高易用的渐进式交付框架 Kruise Rollout。 Higress & Kruise Rollout工作机制简略介绍一下 Higress 和 Kruise Rollout 在一次利用公布过程中的工作机制。 ...

作者：阿里云云原生团队 受访嘉宾： 阿里云智能 云原生 利用平台负责人：丁宇 阿里云智能容器服务负责人：易立 阿里云智能云原生利用平台产品负责人：李国强 阿里云智能中间件技术负责人：胡伟琪 阿里云智能Serverless研发负责人：杨皓然 Question1：云原生技术往年的倒退状况如何？ 首先来看容器技术。Kubernetes 技术生态继续成熟，Kubernetes成 为云时代操作系统。在CNCF 2021调查报告中，寰球有1/3的后端开发者在应用 Kubernetes 技术。在中国开发者调查报告中，阿里云容器服务成为中国开发者首选，有52% 的开发者在应用阿里云。2022年1季度，在权威咨询机构 Forrester 公布的寰球公共云容器平台分析师报告中，ACK 成为比肩 Google 的寰球领导者，这也是首次有中国科技公司进入容器服务领导者象限。 Kubernetes上运行的工作负载越来越丰盛。The Data on Kubernetes Community 2022调查报告，90%的受访者认为Kubernetes曾经能够很好反对有状态利用，其中70%的受访者曾经将其运行在生产环境。越来越多的数据库、AI、大数据分析类型的工作负载将运行在 Kubernetes 之上。通过K8s能够不同类型的工作负载实现对立的基础设施治理，对立的资源调度，并更好利用弹性能力。 阿里云往年开源了云原生混部我的项目 Koordinator，它在 K8s 之上提供了对编排调度能力的加强，反对针对不同类型的工作负载，实现差异化 SLO 保障，提供面向QoS感知的调度和重调度能力，以及对任务调度能力。通过混部调度，能够无效晋升资源利用率，并让低优先级的工作对提早敏感型工作的影响 < 5% 。 在后疫情时代，如何上好云、用好云成为了企业 IT 信息化转型中的外围关注点，降本增效成为企业云原生上云的一致性共识。FinOps与云原生相结合曾经成为新的趋势。阿里云联合业财一体化实际和 FinOps 理念，推出 ACK FinOps 套件，通过数字化伎俩和智能化办法，帮忙企业实现老本可视化、可优化、可管制。其中蕴含了智能化的弹性伸缩能力，混部等多种老本优化伎俩。 在服务网格畛域，  在往年 4 月，谷歌提议将 Istio 捐献给 CNCF，9月 Istio 正式成为 CNCF 孵化我的项目。更加凋谢的Istio社区治理模式，将会失去更多企业和开发者的反对，推动更多的翻新和技术成熟。往年，Istio 发表引入全新的无 sidecar 数据立体模式Ambient Mesh，通过将数据立体性能从 sidecar 容器转移到网络基础设施来解决常见的操作挑战。Istio 的倒退将来可期。阿里云服务网格ASM产品，是业内首个全托管 Istio 兼容的服务网格产品，自公布以来，继续通过软硬一体化技术优化性能，欠缺零信赖平安体系，晋升对大规模生产环境的反对能力。ASM产品取得了首批通过可信云服务网格性能测评先进级认证、排名第一、全项满分。 在开源社区畛域，自 2017 年以来，阿里云继续在云原生开源技术畛域投入巨大力量，深度参加了 etcd、Kubernetes、ContainerD、Dapr、Knative、Istio 等多个 CNCF 顶级开源我的项目的开发与保护当中。并保持开源和商业双引擎倒退模式，践行“三位一体”开源策略，积极参与打造一个凋谢、规范、衰弱良性的云原生技术生态。截至 2020 年底，阿里巴巴发动并捐献了 KubeVela、OpenYurt、Fluid、OpenKruise、Sealer、Chaosblade、ServerlessDevs、OCM等多个我的项目进入 CNCF，笼罩利用交付治理畛域，边缘计算畛域，多云混合云、混部等多个畛域。 ...