Dubbo 3.0 前瞻:重塑 Spring Cloud 服务治理

1002头图.png

作者 | 小马哥

**导读:**Dubbo 社区策划了【Dubbo 云原生之路】系列文章,和大家一起回顾 Apache Dubbo 产品和社区的发展,并展望未来发展。系列文章主要涵盖 Dubbo 技术解读、社区运营、应用案例解析三大部分。本文为系列第 3 篇。

前言

在 Java 微服务生态中,Spring Cloud 成为了开发人员的首选技术栈,然而随着实践的深入和运用规模的扩大,大家逐渐意识到 Spring Cloud 的局限性。

在服务治理方面,相较于Dubbo 而言,Spring Cloud 并不成熟。遗憾的是,Dubbo 往往被部分开发者片面地视作服务治理的 RPC 框架,而非微服务基础设施。即使是那些有意将 Spring Cloud 迁移至 Dubbo 的小伙伴,当面对其中迁移和改造的成本时,难免望而却步。

庆幸的是,Dubbo 3.0 的到来将给这一局面带来重要变革,未来 Dubbo Spring Cloud 将无缝对接 Dubbo 3.0 ,作为Spring Cloud Alibaba 的最核心组件,完全地拥抱 Spring Cloud 技术栈,不但无缝地整合 Spring Cloud 注册中心,包括Nacos、Eureka、Zookeeper 以及Consul,而且完全地兼容Spring Cloud Open Feign以及 @LoadBalanced RestTemplate,本文将讨论 Dubbo Spring Cloud 对 Spring Cloud 技术栈所带来的革命性变化,由于 Spring Cloud 技术栈涵盖的特性众多,因此本文讨论的范围仅限于服务治理部分。

本文作为 Dubbo 3.0 的前瞻,将着重讲解当前版本的 Dubbo Spring Cloud 实现,Dubbo Spring Cloud 得以实现的一个重要基础即是我们前瞻之一提到的应用级服务发现。

应用级服务发现是 Dubbo 3.0 规划中的重要一环,是 Dubbo 与云原生基础设施打通、实现大规模微服务集群的基石。其实 Dubbo 社区早在 2.7.5 版本开始便探索了应用级服务发现,尝试去优化 Dubbo 的服务发现模型,因此 Dubbo Spring Cloud 是基于 Dubbo Spring Boot 2.7.x(从 2.7.0 开始,Dubbo Spring Boot 与 Dubbo 在版本上保持一致)和 Spring Cloud 2.x 开发,而本文也将基于 2.7.x 的这个先期版本展开讲解。

无论开发人员是 Dubbo 用户还是 Spring Cloud 用户,都能轻松地驾驭 Dubbo Spring Cloud,并以接近“零”成本的代价使应用向上迁移。Dubbo Spring Cloud 致力于简化 Cloud Native 开发成本,提高研发效能以及提升应用性能等目的。

版本支持

由于 Spring 官方宣布 Spring Cloud Edgware(下文简称为 “E” 版) 将在 2019 年 8 月 1 日后停止维护 13,因此,目前 Dubbo Spring Cloud 发布版本并未对 “E” 版提供支持,仅为 “F” 版 和 “G” 版开发,同时也建议和鼓励 Spring Cloud 用户更新至 “F” 版 或 “G” 版。

同时,Dubbo Spring Cloud 基于 Apache Dubbo Spring Boot 2.7.x 开发(最低 Java 版本为 1.8),提供完整的 Dubbo 注解驱动、外部化配置以及 Production-Ready 的特性,点击查看详情。

以下表格将说明 Dubbo Spring Cloud 版本关系映射关系:

Spring CloudSpring Cloud AlibabaSpring BootDubbo Spring Boot
Finchley0.2.2.RELEASE2.0.x2.7.1
Greenwich2.2.1.RELEASE2.1.x2.7.1
Edgware0.1.2.RELEASE1.5.x❌ Dubbo Spring Cloud 不支持该版本

功能特性

由于 Dubbo Spring Cloud 构建在原生的 Spring Cloud 之上,其服务治理方面的能力可认为是 Spring Cloud Plus,不仅完全覆盖Spring Cloud 原生特性,而且提供更为稳定和成熟的实现,特性比对如下表所示:

功能组件Spring CloudDubbo Spring Cloud
分布式配置(Distributed configuration)Git、Zookeeper、Consul、JDBCSpring Cloud 分布式配置 + Dubbo 配置中心(Dubbo 2.7 开始支持配置中心,可自定义适配)
服务注册与发现(Service registration and discovery)Eureka、Zookeeper、ConsulSpring Cloud 原生注册中心(Spring Cloud 原生注册中心,除 Eureka、Zookeeper、Consul 之外,还包括 Spring Cloud Alibaba 中的 Nacos)+Dubbo 原生注册中心
负载均衡(Load balancing)Ribbon(随机、轮询等算法)Dubbo 内建实现(随机、轮询等算法 + 权重等特性)
服务熔断(Circuit Breakers)Spring Cloud HystrixSpring Cloud Hystrix +Alibaba Sentinel 等(Sentinel 已被 Spring Cloud 项目纳为 Circuit Breaker 的候选实现)
服务调用(Service-to-service calls)Open Feign、RestTemplateSpring Cloud 服务调用 + Dubbo @Reference
链路跟踪(Tracing)Spring Cloud Sleuth +Zipkin Zipkin、opentracing 等

高亮特性

1)Dubbo 使用 Spring Cloud 服务注册与发现

Dubbo Spring Cloud 基于 Spring Cloud Commons 抽象实现 Dubbo 服务注册与发现,应用只需增添外部化配置属性“dubbo.registry.address = spring-cloud://localhost,就能轻松地桥接到所有原生 Spring Cloud 注册中心,包括:- Nacos - Eureka - Zookeeper - Consul。

注:Dubbo Spring Cloud 将在下个版本支持 Spring Cloud 注册中心与 Dubbo 注册中心并存,提供双注册机制,实现无缝迁移。

2)Dubbo 作为 Spring Cloud 服务调用

默认情况,Spring Cloud Open Feign 以及@LoadBalancedRestTemplate 作为 Spring Cloud 的两种服务调用方式。Dubbo Spring Cloud 为其提供了第三种选择,即 Dubbo 服务将作为 Spring Cloud 服务调用的同等公民出现,应用可通过 Apache Dubbo 注解 @Service 和 @Reference 暴露和引用 Dubbo 服务,实现服务间多种协议的通讯。同时,也可以利用 Dubbo 泛化接口轻松实现服务网关。

3)Dubbo 服务自省

Dubbo Spring Cloud 引入了全新的服务治理特性 - 服务自省(Service Introspection),其设计目的在于最大化减轻注册中心负载,去 Dubbo 注册元信息中心化。假设一个 Spring Cloud 应用引入 Dubbo Spring Boot Starter,并暴露 N 个 Dubbo 服务,以Dubbo Nacos 注册中心为例,当前应用将注册 N+1 个 Nacos 应用,除 Spring Cloud 应用本身之前,其余 N 个应用均来自于 Dubbo 服务,当 N 越大时,注册中心负载越重。

因此,Dubbo Spring Cloud 应用对注册中心的负载相当于传统 Dubbo 的 N 分之一,在不增加基础设施投入的前提下,理论上,使其集群规模扩大 N 倍。当然,未来的 Dubbo 也将提供服务自省的能力。

4)Dubbo 迁移 Spring Cloud 服务调用

尽管 Dubbo Spring Cloud 完全地保留了原生 Spring Cloud 服务调用特性,但是 Dubbo 服务治理的能力是 Spring Cloud Open Feign 所不及的,如高性能、高可用以及负载均衡稳定性等方面。因此,建议开发人员将 Spring Cloud Open Feign 或者 @LoadBalancedRestTemplate 迁移为 Dubbo 服务。

考虑到迁移过程并非一蹴而就,因此,Dubbo Spring Cloud 提供了方案,即 @DubboTransported 注解。该注解能够帮助服务消费端的 Spring Cloud Open Feign 接口以及 @LoadBalanced RestTemplate Bean 底层走 Dubbo 调用(可切换 Dubbo 支持的协议),而服务提供方则只需在原有 @RestController 类上追加 Dubbo @Servce 注解(需要抽取接口)即可,换言之,在不调整 Feign 接口以及 RestTemplate URL 的前提下,实现无缝迁移。如果迁移时间充分的话,建议使用 Dubbo 服务重构系统中的原生 Spring Cloud 服务的定义。

简单示例

开发 Dubbo Spring Cloud 应用的方法与传统 Dubbo 或 Spring Cloud 应用类似,按照以下步骤就能完整地实现Dubbo 服务提供方和消费方的应用,完整的示例代码请访问一下资源:

1. 定义 Dubbo 服务接口

Dubbo 服务接口是服务提供方与消费方的远程通讯契约,通常由普通的 Java 接口(interface)来声明,如EchoService 接口:

public interface EchoService {


    String echo(String message);
}

为了确保契约的一致性,推荐的做法是将 Dubbo 服务接口打包在第二方或者第三方的 artifact(jar)中,如以上接口就存放在 artifact spring-cloud-dubbo-sample-api 之中。

对于服务提供方而言,不仅通过依赖 artifact 的形式引入 Dubbo 服务接口,而且需要将其实现。对应的服务消费端,同样地需要依赖该 artifact,并以接口调用的方式执行远程方法。接下来进一步讨论怎样实现 Dubbo 服务提供方和消费方。

2. 实现 Dubbo 服务提供方

1)初始化 spring-cloud-dubbo-server-sample Maven 工程

首先,创建 artifactId 名为 spring-cloud-dubbo-server-sample 的 Maven 工程,并在其 pom.xml 文件中增添 Dubbo Spring Cloud 必要的依赖:

<dependencies>
    <!-- Sample API -->
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-dubbo-sample-api</artifactId>
        <version>${project.version}</version>
    </dependency>


    <!-- Spring Boot dependencies -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-actuator</artifactId>
    </dependency>


    <!-- Dubbo Spring Cloud Starter -->
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-dubbo</artifactId>
    </dependency>


    <!-- Spring Cloud Nacos Service Discovery -->
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
    </dependency>
</dependencie

以上依赖 artifact 说明如下:

  • spring-cloud-dubbo-sample-api: 提供 EchoService 接口的 artifact;

  • spring-boot-actuator: Spring Boot Production-Ready artifact,间接引入 spring-boot artifact;

  • spring-cloud-starter-dubbo: Dubbo Spring Cloud Starter artifact,间接引入 dubbo-spring-boot-starter 等 artifact;

  • spring-cloud-starter-alibaba-nacos-discovery: Nacos Spring Cloud 服务注册与发现 artifact。

值得注意的是,以上 artifact 未指定版本(version),因此,还需显示地声明 <dependencyManagement>:

<dependencyManagement>
    <dependencies>
        <!-- Spring Cloud Alibaba dependencies -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-alibaba-dependencies</artifactId>
            <version>2.2.1.RELEASE</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

注:以上完整的 Maven 依赖配置,请参考 spring-cloud-dubbo-server-sample pom.xml 文件。

完成以上步骤之后,下一步则是实现 Dubbo 服务。

2)实现 Dubbo 服务

EchoService 作为暴露的 Dubbo 服务接口,服务提供方 spring-cloud-dubbo-server-sample 需要将其实现:

@org.apache.dubbo.config.annotation.Service
class EchoServiceImpl implements EchoService {


    @Override
    public String echo(String message) {
        return "[echo] Hello, " + message;
    }
}

其中,@org.apache.dubbo.config.annotation.Service 是 Dubbo 服务注解,仅声明该 Java 服务(本地)实现为 Dubbo 服务。因此,下一步需要将其配置 Dubbo 服务(远程)。

3)配置 Dubbo 服务提供方

在暴露 Dubbo 服务方面,推荐开发人员外部化配置的方式,即指定 Java 服务实现类的扫描基准包。

注:Dubbo Spring Cloud 继承了 Dubbo Spring Boot 的外部化配置特性,也可以通过标注 @DubboComponentScan 来实现基准包扫描。

同时,Dubbo 远程服务需要暴露网络端口,并设定通讯协议,完整的 YAML 配置如下所示:

dubbo:
  scan:
    # dubbo 服务扫描基准包
    base-packages: org.springframework.cloud.alibaba.dubbo.bootstrap
  protocol:
    # dubbo 协议
    name: dubbo
    # dubbo 协议端口( -1 表示自增端口,从 20880 开始)
    port: -1

spring:
  application:
    # Dubbo 应用名称
    name: spring-cloud-alibaba-dubbo-server
  cloud:
    nacos:
      # Nacos 服务发现与注册配置
      discovery:
        server-addr: 127.0.0.1:8848

以上 YAML 内容,上半部分为 Dubbo 的配置:

  • dubbo.scan.base-packages: 指定 Dubbo 服务实现类的扫描基准包;

  • dubbo.protocol: Dubbo 服务暴露的协议配置,其中子属性 name 为协议名称,port 为协议端口( -1 表示自增端口,从 20880 开始);

  • dubbo.registry: Dubbo 服务注册中心配置,其中子属性 address 的值 “spring-cloud://localhost”,说明挂载到 Spring Cloud 注册中心。

下半部分则是 Spring Cloud 相关配置:

  • spring.application.name: Spring 应用名称,用于 Spring Cloud 服务注册和发现。> 该值在 Dubbo Spring Cloud 加持下被视作 dubbo.application.name,因此,无需再显示地配置 dubbo.application.name;

  • spring.cloud.nacos.discovery: Nacos 服务发现与注册配置,其中子属性 server-addr 指定 Nacos 服务器主机和端口。

以上完整的 YAML 配置文件,请参考 spring-cloud-dubbo-server-samplebootstrap.yaml 文件。

完成以上步骤后,还需编写一个 Dubbo Spring Cloud 引导类。

4)引导 Dubbo Spring Cloud 服务提供方应用

Dubbo Spring Cloud 引导类与普通 Spring Cloud 应用并无差别,如下所示:

 @EnableDiscoveryClient @EnableAutoConfiguration public class DubboSpringCloudServerBootstrap {
public static void main(String[] args) {
    SpringApplication.run(DubboSpringCloudServerBootstrap.class);
}
}

在引导 DubboSpringCloudServerBootstrap 之前,请提前启动 Nacos 服务器。当 DubboSpringCloudServerBootstrap 启动后,将应用 spring-cloud-dubbo-server-sample 将出现在 Nacos 控制台界面。

当 Dubbo 服务提供方启动后,下一步实现一个 Dubbo 服务消费方。

3. 实现 Dubbo 服务消费方

由于 Java 服务就 EchoService、服务提供方应用 spring-cloud-dubbo-server-sample 以及 Nacos 服务器均已准备完毕。Dubbo 服务消费方只需初始化服务消费方 Maven 工程 spring-cloud-dubbo-client-sample 以及消费 Dubbo 服务。

1)初始化 spring-cloud-dubbo-client-sample Maven 工程

与服务提供方 Maven 工程类,需添加相关 Maven 依赖:

<dependencyManagement>
    <dependencies>
        <!-- Spring Cloud Alibaba dependencies -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-alibaba-dependencies</artifactId>
            <version>2.2.1.RELEASE</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>


<dependencies>
    <!-- Sample API -->
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-dubbo-sample-api</artifactId>
        <version>${project.version}</version>
    </dependency>


    <!-- Spring Boot dependencies -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>


    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-actuator</artifactId>
    </dependency>


    <!-- Dubbo Spring Cloud Starter -->
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-dubbo</artifactId>
    </dependency>


    <!-- Spring Cloud Nacos Service Discovery -->
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
    </dependency>
</dependenc

与应用 spring-cloud-dubbo-server-sample 不同的是,当前应用依赖 spring-boot-starter-web,表明它属于 Web Servlet 应用。

注:以上完整的 Maven 依赖配置,请参考 spring-cloud-dubbo-client-sample pom.xml 文件。

2)配置 Dubbo 服务消费方

Dubbo 服务消费方配置与服务提供方类似,当前应用 spring-cloud-dubbo-client-sample 属于纯服务消费方,因此,所需的外部化配置更精简:


dubbo:
  cloud:
    subscribed-services: spring-cloud-alibaba-dubbo-server

spring:
  application:
    # Dubbo 应用名称
    name: spring-cloud-alibaba-dubbo-client
  cloud:
    nacos:
      # Nacos 服务发现与注册配置
      discovery:
        server-addr: 127.0.0.1:8848

对比应用 spring-cloud-dubbo-server-sample,除应用名称 spring.application.name 存在差异外,spring-cloud-dubbo-client-sample 新增了属性 dubbo.cloud.subscribed-services 的设置,并且该值为服务提供方应用 “spring-cloud-dubbo-server-sample”。

dubbo.cloud.subscribed-services: 用于服务消费方订阅服务提供方的应用名称的列表,若需订阅多应用,使用 “,” 分割。不推荐使用默认值为 “*”,它将订阅所有应用。

当应用使用属性 dubbo.cloud.subscribed-services 默认值时,日志中将会输出一行警告:

Current application will subscribe all services(size:x) in registry, a lot of memory and CPU cycles may be used,

thus it’s strongly recommend you using the externalized property ‘dubbo.cloud.subscribed-services’ to specify the services

由于当前应用属于 Web 应用,它会默认地使用 8080 作为 Web 服务端口,如果需要自定义,可通过属性 server.port 调整。

注:以上完整的 YAML 配置文件,请参考 spring-cloud-dubbo-client-sample``bootstrap.yaml 文件。

3)引导 Dubbo Spring Cloud 服务消费方应用

为了减少实现步骤,以下引导类将 Dubbo 服务消费以及引导功能合二为一:


@EnableDiscoveryClient
@EnableAutoConfiguration
@RestController
public class DubboSpringCloudClientBootstrap {


    @Reference
    private EchoService echoService;


    @GetMapping("/echo")
    public String echo(String message) {
        return echoService.echo(message);
    }


    public static void main(String[] args) {
        SpringApplication.run(DubboSpringCloudClientBootstrap.class);
    }

不仅如此,DubboSpringCloudClientBootstrap 也作为 REST Endpoint,通过暴露 /echo Web 服务,消费 Dubbo EchoService 服务。因此, 可通过 curl 命令执行 HTTP GET 方法:

$ curl http://127.0.0.1:8080/echo?message=%E5%B0%8F%E9%A9%AC%E5%93%A5%EF%BC%88mercyblitz%EF%BC%89

HTTP 响应为:

[echo] Hello, 小马哥(mercyblitz)

以上结果说明应用 spring-cloud-dubbo-client-sample 通过消费 Dubbo 服务,返回服务提供方 spring-cloud-dubbo-server-sample 运算后的内容。

高阶示例

如果您需要进一步了解 Dubbo Spring Cloud 使用细节,可参考 参考官方 Samples。

其子模块说明如下:

  • spring-cloud-dubbo-sample-api:API 模块,存放 Dubbo 服务接口和模型定义;

  • spring-cloud-dubbo-provider-web-sample:Dubbo Spring Cloud 服务提供方示例(Web 应用);

  • spring-cloud-dubbo-provider-sample:Dubbo Spring Cloud 服务提供方示例(非 Web 应用);

  • spring-cloud-dubbo-consumer-sample:Dubbo Spring Cloud 服务消费方示例;

  • spring-cloud-dubbo-servlet-gateway-sample:Dubbo Spring Cloud Servlet 网关简易实现示例。

问题反馈

如果您在使用 Dubbo Spring Cloud 的过程中遇到任何问题,请在此反馈内容。

反馈链接:https://github.com/alibaba/spring-cloud-alibaba/issues

进阶阅读

关于更多的 Dubbo Spring Cloud 特性以及设计细节,请关注:

系列文章:

作者简介

小马哥(mercyblitz),Java 劝退师,Apache Dubbo PMC、Spring Cloud Alibaba 项目架构师。目前主要负责阿里集团中间件开源项目、微服务技术实施、架构衍进、基础设施构建等。

“阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的公众号。”

相关推荐

推荐一款好用的刷题工具

为了帮助正在准备求职季的开发者提升备战效率,阿里云特别推出“通义灵码陪你备战求职季”活动,精心挑选百道历史校招技术面试/笔试题,借助通义灵码智能问答、代码智能生成、代码优化等核心功能,帮助开发者更加准确地了解程序员职业所需的核心技能,加强对问题解决思维和解题能力的练习。

阿里巴巴云原生的博客 1383

通义灵码 Visual Studio 下载安装指南(附安装包)

本安装步骤适用于 Windows 10 及以上操作系统中安装和使用通义灵码。

阿里巴巴云原生的博客 4436

生产更可信,订阅更耐用丨Higress 社区进展报告

阿里巴巴云原生的博客 54

让 Agent 成为企业生产力丨Alibaba Cloud AgentCore 企业智能体构建与治理沙龙·杭州站精彩回顾 & PPT 下载

近日,让 Agent 成为企业生产力丨Alibaba Cloud AgentCore 企业智能体构建与治理沙龙·杭州站圆满落幕。本场活动吸引了 100+ 名技术从业者深度参与,深度分享了企业 Agent 趋势、AgentCore 构建与治理、Agent 观测与优化、STAROps 智能运维及 AI 网关等相关议题,并设置了动手实操环节。

阿里巴巴云原生的博客 18

如何用 STAROps Elasticsearch 智能助手看穿“搜索变慢”

某电商平台的商品搜索服务使用一台 6 个数据节点的 Elasticsearch 实例。周五北京时间 20:00 起,业务陆续反馈搜索变慢。业务监控中的搜索接口 P99 从平时约 200 ms 升到 2s 以上,部分请求超时。值班工程师打开控制台:集群状态为 Green,没有未分配分片,集群平均 CPU 约 40%,乍看不像资源已经吃紧。

阿里巴巴云原生的博客 97

满帮基于阿里云 AgentCore 打造生产级 SRE 稳定性数字人

满帮基于阿里云 AgentCore 构建“稳定性数字人”:满帮提供业务知识、专业工具与处置流程,AgentCore 提供智能体运行、协作和治理支撑。数字人已在核心链路的巡检与根因分析中得到应用,受控处置能力也在持续建设,让满帮积累的稳定性能力能够在具体任务中得到复用。

阿里巴巴云原生的博客 111

稳定复现超 70% 的缺陷,报警到自动修复的 Agent 流水线实践

本文将分享我们在 PolarDB-X 团队做的一些工程实践:让 Agent 从一条报警或工单出发,自主完成排查、复现、修复和验证,再把结果交给研发评审。

阿里巴巴云原生的博客 294

从“自证清白”到“因果链条”:智能体如何重塑运维排障效率

STAROps 做全域关联分析,把范围从「五个团队依次自证清白」收拢到一条具体链路;证据指向对象存储后,OSS Agent 接手,基于真实配置、访问日志和用量数据往下挖,给出根因和支撑它的证据链。你面对的始终是一个对话框:路由归它管,说清现象、拍板方案归你。

阿里巴巴云原生的博客 125

TechTalk丨从能买奶茶到能进企业,Agent 绕不开同一组问题

史明伟所在的 Alibaba Cloud AgentCore 是企业级 Agent 构建和治理平台,为 Agent 在业务场景下的规模化落地提供基础设施,所以这场对话,他和 Datawhale 主持人从个人助理一路聊到企业 Agent:权限该怎么一步步放开?进了企业,账号打通、数据权限、沙箱隔离又会带来哪些新问题?没有强技术团队的企业,该从哪里起步?

阿里巴巴云原生的博客 207

AgentCore + Codex 构建生产级 Agent 的原理与实践

本文章演示 AgentCore[1]的自定义代码/镜像能力,目的是展示如何基于自定义的 Harness 框架(Codex) 结合 AgentCore 提供的身份、模型、工具、技能、凭证 、观测评估等能力实现一个端到端的 Agent 应用,内容包含两个部分,技术方案和实践教程,文末附相关源码和本次的测试数据,可以根据需要自行查阅。

阿里巴巴云原生的博客 187

让复杂任务由团队完成:阿里云 AgentCore 多 Agent 协作架构及实践

Alibaba Cloud AgentCore 以身份、通信、团队和任务为基础,让专业 Agent 与人类成员共同参与业务协作。企业可以按职责组合知识、工具、Skill 和模型,用任务系统持续追踪工作,再结合 AgentLoop 评估效果、优化配置。

阿里巴巴云原生的博客 334

易点天下:AI 驱动 IT 运维组织提效的实践

易点天下作为一家专注品牌全球化的营销科技公司,由智能营销、全域增长、智能变现三大引擎驱动。公司旗下拥有“整合营销服务”与“广告平台业务”两大业务线。

阿里巴巴云原生的博客 300

阿里云可观测 2026 年 10 月产品动态

阿里云可观测 2026 年 10 月产品动态

阿里巴巴云原生的博客 199

用 Nacos 3.3.0 ARD 让 Agent 按任务发现工具和 Skill

如今,工作中用 Agent 帮忙已经越来越常见。研发同学用 Coding Agent 写代码、补测试、排查问题,业务同学用 Work Agent 整理资料、分析表格、制作演示文稿。不少过去需要自己一步步操作的事情,现在可以把需求交给 Agent,让它协助完成。

阿里巴巴云原生的博客 313

HiRoute 新版本发布:结合自己的真实工作选择最佳模型

HiRoute[1]是一个开源、运行在本地的 Agent 智能路由引擎。你继续用 Codex、Claude Code、Qoder、Pi、OpenCode、Hermes、DeepSeek Harness 等熟悉的 Agent,由 HiRoute 判断每一步交给哪个模型。

阿里巴巴云原生的博客 387

用户说 App“下不了单”:用 Session Replay 看清流程卡在哪一步

Session Replay(会话回放)将采集到的页面变化重建为可回看的过程。研发可以沿着这次会话,查看操作前后的界面变化,先确认流程停在了哪里,再结合当时的事件、日志和代码检查原因。

阿里巴巴云原生的博客 55

欢迎报名丨Alibaba Cloud AgentCore 企业智能体构建与治理八城巡回沙龙 · 杭州站开启

欢迎报名丨Alibaba Cloud AgentCore 企业智能体构建与治理八城巡回沙龙 · 杭州站开启

阿里巴巴云原生的博客 144

运维走出控制台:阿里云 AgentCore AI Native 运维实践

UModel 让现场能够被关联,运维数字员工让经验能够被调用,AgentCore Team 让分析能够协作,AgentLoop 让质量能够被检验。这些建设共同服务于一件事:让团队对系统的理解,成为每个人处理问题时都能接上的能力。

阿里巴巴云原生的博客 300

从长程 Agent 到 Super-agent,解锁更多场景

Deepseek Harness 提升了架构的透明度,但也带来了工程上的复杂度。这次开源的dsh-superagent-prototype,是对 Agent “连续实体”能力的工程拆解。

阿里巴巴云原生的博客 237

排查提效 50%:淘大集新核心系统的观测护航之路

供应链运维,缺的不是更多机器,是“一条能把指标、日志、链路串起来的线”。阿里云 ARMS+SLS+云监控2.0+STAROps 重构观测底座。

阿里巴巴云原生的博客 148

概率、插座与 5000 个爱因斯坦:专访阿里云研发副总裁周琦

这次访谈发生在 2026 年云栖大会之后。大会期间,阿里云发布了智能体构建和治理平台 AgentCore,将企业级 Agent 基础设施进一步标准化和托管化。

阿里巴巴云原生的博客 154

Agent 数据飞轮平台的选型和实践

用统一标准判断修改效果,积累覆盖不同路径的测试样本,沿执行记录排查失败,并将典型问题纳入后续回归。而这也是宙斯接入 AgentLoop 要解决的问题。

阿里巴巴云原生的博客 29

Durable Agent 详解:如何让 Agent 在云端长期稳定运行

本文使用一个具体的用户任务示例“向五位客户发送通知邮件”,解释为什么保存聊天记录还不够,再以 AgentScope 构建的 Agent 为例,展开任务状态、持久提交和故障恢复的通用设计,最后结合 Alibaba Cloud AgentCore 已有的 Harness 托管与节点恢复能力,讨论共享状态、可靠调度及 Brain / Hands 分离如何支撑更完整的长期托管服务。

阿里巴巴云原生的博客 335

Qoder × AgentLoop:智能体规模化应用,敏感数据保护如何跟上?

智能体观测与优化平台 AgentLoop 持续分析已采集的 Qoder 审计日志,将发现的风险线索关联到具体会话、工具调用、成员和环境,帮助安全团队回查任务过程、明确需要整改的环节,并复查处理效果。

阿里巴巴云原生的博客 291

完整还原已经服务千家企业的 AIOps Agent 的评测和调优实践

阿里云 STAROps 是一个生产运维 Agent,通过连接多域数据、运维工具与专家经验,从被动响应走向智能自治,7×24 保障业务连续、稳定运行。本文将分享 STAROps 的评测和调优实践。

阿里巴巴云原生的博客 199

阿里云云原生四项 AI 应用工程化实荣获“鼎新杯”优秀案例

第五届“鼎新杯”由中国通信标准化协会主办、中国信息通信研究院承办,自2026年05月正式启动,历时近 5 个月,聚焦国内政企数智化转型领域的创新成果,旨在为行业提供可复制、可推广的实践参考。

阿里巴巴云原生的博客 323

交付周期从 51 天缩短到 14 天,多 Agent 协作产品⾃进化背后的组织重构

本⽂结合这段实践,介绍评测如何驱动产品持续进化、⼈机协作的边界如何设定,以及团队如何通过统⼀⽬标、结果标准和责任分⼯,减少跨岗位交接,降低沟通损耗,把技术能⼒转化为实际交付效果。

阿里巴巴云原生的博客 328

从部署上线到运维优化:STAROps 与 ROS Agent 的资源运维自动化实践

STAROps 数字员工提供统一的运维对话入口,结合日志、指标、告警等信息理解问题,并通过 alibabacloud-ros-agent 技能,将基础设施规划和变更任务委派给 ROS Agent。

阿里巴巴云原生的博客 130

车企数据隐私保护必修课:如何用 SLS mask 守住日志中的敏感信息

阿里云日志服务 SLS 的 mask 函数可在采集或写入阶段替换匹配的敏感值,同时保留业务状态与调用链,并结合访问控制和保留期限管理减少暴露。下文通过车辆与车主服务、海外联网订阅、智能座舱交互三类业务中的四组日志,介绍规则选择与脱敏效果。

阿里巴巴云原生的博客 112

切换模型会损失缓存,智能路由还省钱吗?

智能路由会把不同的工作交给不同的模型。很多人随之会问:模型一换,之前积累的缓存就用不上了,这笔损失会不会把省下的钱又花回去?

阿里巴巴云原生的博客 209
上一篇: Kubernetes 集群升级指南:从理论到实践
下一篇: 管理自动化:企业上云必由之路
阿里云云原生
阿里云云原生 企业官方账号 企业官方账号
博客等级 码龄8年 1万+粉丝 3151原创
评论 1
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值