ucc

作者 | 雷卷 来源| 阿里巴巴云原生公众号 RSocket 分布式通讯协议是 Spring Reactive 的核心内容，从 Spring Framework 5.2 开始，RSocket 已经是 Spring 的内置功能，Spring Boot 2.3 也添加了 spring-boot-starter-rsocket，简化了 RSocket 的服务编写和服务调用。RSocket 通讯的核心架构中包含两种模式，分别是 Broker 代理模式和服务直连通讯模式。 Broker 的通讯模式更灵活，如 Alibaba RSocket Broker，采用的是事件驱动模型架构。而目前更多的架构则是面向服务化设计，也就是我们常说的服务注册发现和服务直连通讯的模式，其中最知名的就是 Spring Cloud 技术栈，涉及到配置推送、服务注册发现、服务网关、断流保护等等。在面向服务化的分布式网络通讯中，如 REST API、gRPC 和 Alibaba Dubbo 等，都与 Spring Cloud 有很好地集成，用户基本不用关心服务注册发现和客户端负载均衡这些底层细节，就可以完成非常稳定的分布式网络通讯架构。 RSocket 作为通讯协议的后起之秀，核心是二进制异步化消息通讯，是否也能和 Spring Cloud 技术栈结合，实现服务注册发现、客户端负载均衡，从而更高效地实现面向服务的架构

作者 | 夏莞 阿里巴巴函数计算团队 本文整理自 《Serverless 技术公开课》 ，关注“Serverless”公众号，回复“入门”，即可获取 Serverless 系列文章 PPT。 **导读：**本文主要分为三个部分：概述中介绍可观测性的基本概念，主要包括 Logging、Metrics、Tracing 三个方面；然后详细介绍函数计算上的 Logging、Metrics、Tracing；最后以几个常见场景为例，介绍在函数计算中如何快速定位问题并解决问题。 概述 可观测性是什么呢？维基百科中这样说：可观测性是通过外部表现判断系统内部状态的衡量方式。 在应用开发中，可观测性帮助我们判断系统内部的健康状况。在系统出现问题时，帮助我们定位问题、排查问题、分析问题；在系统平稳运行时，帮助我们评估风险，预测可能出现的问题。评估风险类似于天气预报，预测到明天下雨，那出门就要带伞。在函数计算的应用开发中，如果观察到函数的并发度持续升高，很可能是业务推广团队的努力工作导致业务规模迅速扩张，为了避免达到并发度限制触发流控，开发者就需要提前提升并发度。 可观测性包括三个方面：Logging、Metrics、Tracing Logging 是日志，日志记录了函数运行中的关键信息，这些信息是离散且具体的，结合错误日志与函数代码可以迅速定位问题。 Metrics 是指标，是聚合的数据

作者 | Montos（一个在后端道路上摸爬滚打的内卷人） 来源| 阿里巴巴云原生公众号 Arthas 是阿里巴巴开源的 Java 诊断工具。让我们能够在线排查项目发生的问题。除了知道它的存在之外，我们也需要知道我们如何去安装使用它，以便于提高我们日常开发解决 BUG 的效率。 方案介绍 方案一：本地直接运行 往往最简单的方法实际是最有效的，它本身就是一个可运行的程序，所以我们可以直接运行即可。 我们可以直接通过官网下载对应的 jar，然后运行再进行 jar，执行对应的命令。 命令如下: java -jar arthas-boot.jar [option] 演示如下: 方案二：Web Console实现 我们可以不通过每次进入 ssh 中进行执行程序，我们也可通过 web 方式进行访问操作.通过官网上面的介绍 arthas 的 Web Console，能了解到大致的搭建思路。 通过下载 arthas-tunnel-server。我们可以拿到对应的 arthas 的 server 端。下载完毕之后直接运行即可（我是将其在 ECS 上直接运行）。 在客户端对应的启动 arthas-boot。并且通过启动参数附加上 server 的地址（我是将其在本地运行）。 选择对应的进程进行 attach，会出现对应的 agent-id，再将其填写到对应的 server 端 http 页面中。

作者 | 阿提说说 来源| 阿里巴巴云原生公众号 前言 Arthas 是 Alibaba 开源的 Java 诊断工具，具有实时查看系统的运行状况；查看函数调用参数、返回值和异常；在线热更新代码；秒解决类冲突问题；定位类加载路径；生成热点；通过网页诊断线上应用。如今在各大厂都有广泛应用，也延伸出很多产品。 这里将介绍如何将 Arthas 集成进 Spring Boot 监控平台中。 SpringBoot Admin 为了方便，SpringBoot Admin 简称为 SBA（版本：1.5.x）。 1.5 版本的 SBA 如果要开发插件比较麻烦，需要下载 SBA 的源码包，再按照 Spring-boot-admin-server-ui-hystrix的形式 Copy 一份,由于 JS 使用的是 Angular，本人尝试了很久，虽然掌握了如何开发插件，奈何不会 Angular，遂放弃💀 版本：2.x 2.x 版本的 SBA 插件开发，官网有介绍如何开发，JS 使用 Vue，方便很多，由于我们项目还在使用 1.5，所以并没有使用该版本，请读者自行尝试。 不能使用 SBA 的插件进行集成，那还有什么办法呢？😅 SBA 集成 鄙人的办法是将 Arthas 的相关文件直接 Copy 到 Admin 服务中，这些文件都来自 Arthas-all 项目 Tunnel-server。 admin

作者 | 行松 阿里巴巴云原生团队 来源 | Serverless 公众号，整理自 《Serverless 技术公开课》 背景 通过前面几节课程的学习，相信大家对于 SAE 平台已经有了一定的了解，SAE 基于 IaaS 层资源构建的一款 Serverles 应用托管产品，免除了客户很多复杂的运维工作，开箱即用、按用量付费；并且提供了丰富的 Open API 可以很容易地与其他平台做集成。 本文将为大家介绍 SAE 在微服务方面的一些能力，SAE 产品把 Serverless 技术和微服务做了很好的结合，天然支持 Java 微服务应用的托管和服务治理，对 SpringCloud/Dubbo 微服务应用能够在只修改配置和依赖，不修改代码的情况下迁移到 SAE 上，并提供服务治理能力，比如基于租户的微服务隔离环境、服务列表、无损下线、离群摘除、应用监控以及调用链分析等。 本次课程分为三部分来介绍，分别介绍微服务应用迁移到 SAE 的优势，如何迁移 SpringCloud/Dubbo 应用到 SAE 上，以及针对 SpringCloud 应用迁移的实践演示。 迁移到 SAE 的优势 在介绍迁移之前，先介绍下 SpringCloud/Dubbo 应用迁移到 SAE 的优势： SAE 内置注册中心 ：所有用户共享注册中心组件，SAE 帮助用户运维，这就节省了用户的部署、运维成本

作者：田杰 查询执行时间长引发应用感知 “卡顿” 的场景在数据库的日常支持和使用中并不少见，但由于时区设置引发的 SQL 执行“卡顿”仍然是一个有趣的现象，之前没有具体关注过。 这次客户的细致与坚持让我们找到了问题的源头。 1. 名词解释 序列号 名词 说明 1 CPU 使用率 非空闲的 CPU 时间占比。 2 User CPU 使用率 用户空间（user-space）应用代码消耗的 CPU 时间占比。 3 Sys CPU 使用率 系统空间（sys-space）内核代码消耗 CPU 时间占比。 4 Futex Linux 内核提供的快速用户态锁/信号量；在无竞争场景完全在用户空间中运行，但在存在竞争场景会引发系统调用。 2. 问题现象 客户 MySQL 8.0 实例在 2020-03-19 22:03 ~ 22:04 出现大量活跃连接堆积，慢日志中出现大量低成本查询，并且 CPU 使用率不高但系统 SYS CPU 使用率出现异常波动。 3. 问题排查 3.1 OS 层面 我们来考虑一下有哪些因素可能会导致卡顿： • 物理机 OS 层面波动（通过 IO_WAIT 指标排除）。 • MySQL 自身机制。 3.2 MySQL 层面 排除掉 OS 层面异常类因素，我们开始聚焦在 mysqld 进程调用栈的分析。 为了更好的分析 MySQL 的行为，阿里数据库提供了扁鹊系统来跟踪

作者 | 潘义文（空易） 来源|阿里巴巴云原生公众号 起源 1. 云原生（Cloud Native）的由来 云原生的概念最早开始于 2010 年， 在当时 Paul Fremantle 的一篇博客中被提及 ，他一直想用一个词表达一种架构，这种架构能描述应用程序和中间件在云环境中的良好运行状态。因此他抽象出了 Cloud Native 必须包含的属性，只有满足了这些属性才能保证良好的运行状态。当时提出云原生是为了能构建一种符合云计算特性的标准来指导云计算应用的编写。 后来到 2013 年 Matt Stine 在推特上迅速推广云原生概念 ，并 在 2015 年《迁移到云原生架构》 一书中定义了符合云原生架构的特征： 12 因素、微服务、自服务、基于 API 协作、扛脆弱性 。而由于这本书的推广畅销，这也成了很多人对云原生的早期印象，同时云原生也被 12 要素变成了一个抽象的概念。Matt Stine 认为在单体架构向 Cloud Native 迁移的过程中，需要文化、组织、技术共同变革。 **解读：** 云原生架构本质上也是一种软件架构，最大的特点是在云环境下运行，也算是微服务的一种延伸 。 2. CNCF 基金会成立及云原生概念的演化 2015 年由 Linux 基金会发起了一个 The Cloud Native Computing Foundation（CNCF） 基金组织

作者 | 易立、张维 来源 | 阿里巴巴云原生公众号 导读 ：当前 Serverless 容器的行业趋势如何？有哪些应用价值？如果 Kubernetes 天生长在云上，它的架构应该如何设计？Serverless 容器需要哪些基础设施？阿里云容器服务产品负责人易立及阿里云 Serverless Kubernetes 产品 TL 张维将分享他们对 Serverless 容器架构和背后的关键思考。 从 Serverless 容器到 Serverless Kubernetes Serverless（无服务器）容器是让用户无需购买和管理服务器直接部署容器应用的产品、技术形态。 Serverless 容器可以极大提高容器应用部署的敏捷度和弹性能力，降低用户计算成本；让用户聚焦业务应用而非底层基础设施管理，极大地提高应用开发效率，降低运维成本。 目前 Kubernetes 已经成为业界容器编排系统的事实标准，基于 Kubernetes 的云原生应用生态（Helm, Istio, Knative, Kubeflow, Spark on K8s 等）更是让 Kubernetes 成为云操作系统。一方面通过 Serverless 方式根本性解决 K8s 自身的管理复杂性，让用户无需受困于 K8s 集群容量规划、安全维护、故障诊断；一方面进一步释放了云计算的能力，将安全、可用性

作者 | 孙健波（天元） 来源| 阿里巴巴云原生公众号 本文由“GO 开源说”第三期 KubeVela 直播内容修改整理而成，视频内容较长，本文内容有所删减和重构。 点击查看视频 KubeVela 的背景 KubeVela 是一个基于 Go 语言开发的云原生平台级开源项目，这个项目是 去年 11 月中旬正式发布 的。虽然发布到现在不足两个月时间，但是 KubeVela 作为"阿里巴巴统一云原生应用平台内核”背后的核心依赖，其实已经在阿里多个产品背后运行了比较长的一段时间，我本人目前也在大量参与这些产品和项目的内核建设工作。 KubeVela： https://github.com/oam-dev/kubevela 这套内核系统诞生自 2019 年年底阿里云联合微软共同推出的 Open Application Model（简称 OAM ）模型基于 Kubernetes 的实现，在不断演进和迭代中融合了大量来自开源社区（尤其是微软、字节跳动、第四范式、腾讯和满帮集团的社区参与者们）的反馈与贡献，最终在 2020 年 KubeCon 北美峰会 上以 “KubeVela” 的名字正式与开源社区见面。KubeVela 项目在官宣后得到了整个云原生生态的持续关注，在发布后的第四天就登上了 Go 语言的开源趋势榜榜首。 图 1 KubeVela 的 GitHub Star 快速增长

首届云原生编程挑战赛正在报名中，初赛共有三个赛道，题目如下： 赛道一：实现一个分布式统计和过滤的链路追踪 赛道二：实现规模化容器静态布局和动态迁移 赛道三：服务网格控制面分治体系构建 立即报名 （报名时间即日起至06/29）： https://tianchi.aliyun.com/specials/promotion/cloudnative#problem-definition 本文主要针对赛道三题目做出剖析，帮助选手更高效的解题。 背景知识 “服务网格” 是近年来非常火热的技术，其全托管的思维非常适合云原生场景。“服务网格” 核心分为控制面与数据面：数据面主要是一个名为 Sidecar 的代理组件，它通过接收控制面发送的路由与控制信息来定向转发或处理数据。这样一些坐落在服务网格里的应用就将整个分布式逻辑交给了底层，自己不用关心了。一旦与底层解耦，灵活性大大增加，更符合云原生的标准。 题目解析 本题的核心考查点还是如何让服务网格的控制面支撑大规模的 Sidecar 实例。为什么会产生这个问题呢？因为在目前服务网格影响最广的实现 Istio 架构中，控制平面 Pilot 负责整个系统的路由转译工作，也就是说所有服务的实例信息都需要通过 Pilot 下发给每一个 Sidecar，当然用户可以通过 SidecarScope 来设置个别 Sidecar 对于系统服务的可见性，但这只会影响到