开发者社区

文档建议反馈控制台

最新优惠活动

文章/答案/技术大牛

发布

CQRS设计模式的正确实现？

CQRS（Command Query Responsibility Segregation）是一种软件设计模式，旨在将应用程序的读操作（查询）和写操作（命令）分离，以提高系统的可扩展性、性能和灵活性。

在正确实现CQRS设计模式时，以下是一些关键步骤和注意事项：

分离读写操作：CQRS的核心思想是将读操作和写操作分离，使用不同的模型来处理它们。读模型负责处理查询请求，而写模型负责处理命令请求。
领域驱动设计（DDD）：CQRS通常与领域驱动设计一起使用，因为它们的理念相互契合。在实现CQRS时，可以使用DDD的概念来定义领域模型、聚合根、实体和值对象等。
事件驱动架构（EDA）：CQRS常常与事件驱动架构结合使用。在写模型中，可以使用事件来表示状态的变化，并将这些事件发布到事件总线上。读模型可以通过订阅这些事件来更新自身的状态。
数据存储：由于读操作和写操作的数据模型可能不同，因此可以选择不同的数据存储技术来支持它们。例如，可以使用关系型数据库来支持写操作，而使用NoSQL数据库或缓存来支持读操作。
一致性和并发性：由于读写操作被分离，可能会导致读模型和写模型之间的数据不一致。因此，在实现CQRS时，需要考虑如何处理一致性和并发性的问题，例如使用事件溯源、乐观锁等技术。
应用场景：CQRS适用于需要高度可扩展性和性能的应用场景，特别是在面对复杂的业务逻辑和大量并发操作时。例如，电子商务平台的订单系统、金融交易系统等都可以考虑采用CQRS设计模式。

腾讯云相关产品和产品介绍链接地址：

腾讯云数据库（TencentDB）：https://cloud.tencent.com/product/cdb
腾讯云消息队列（TencentMQ）：https://cloud.tencent.com/product/tmq
腾讯云函数计算（Serverless）：https://cloud.tencent.com/product/scf
腾讯云分布式缓存（TencentDC）：https://cloud.tencent.com/product/dc
腾讯云物联网平台（IoT Explorer）：https://cloud.tencent.com/product/explorer
腾讯云人工智能（AI）：https://cloud.tencent.com/product/ai
腾讯云移动开发（移动推送、移动分析等）：https://cloud.tencent.com/product/mobile
腾讯云对象存储（COS）：https://cloud.tencent.com/product/cos
腾讯云区块链服务（Tencent Blockchain）：https://cloud.tencent.com/product/tbc
腾讯云虚拟专用网络（VPC）：https://cloud.tencent.com/product/vpc
腾讯云安全产品（WAF、DDoS防护等）：https://cloud.tencent.com/product/safety
腾讯云音视频处理（VOD、TRTC等）：https://cloud.tencent.com/product/vod

相关搜索:CQRS模式中的Resharper导航 js的设计模式 MVC设计模式在Python3中的实现 php的设计模式下面抽象工厂设计模式的实现是正确的吗？代码实现单例设计模式: Bill Pugh on a Retrofit object 使用CQRS和事件源的状态模式使用java.util.function.Function实现工厂设计模式使用泛型实现对象转换器设计模式在实现CQRS模式时，如何使用Spring处理JWT身份验证？

相关搜索:

页面内容是否对你有帮助？

有帮助

没帮助

相关·内容

耿大侠 Diss国外架构师文章《From CQS to CQRS》

看到耿大侠发了一篇怼InfoQ上的一篇译文的技术文章，仔细拜读之后，收获良多，在征得原作者的同意后，把文章发在这里，供大家品鉴，滋取养分。大多数程序开发人员一定拜读过设计模式的相关文献，想必，也一定在自己的日常工作中，套用个别设计模式优化过自己的局部代码，在局部代码的优化上，设计模式是死的，当你把设计模式放在更宽广的领域，设计模式会变成活的。本文解析了命令模式从面向对象设计过渡到领域驱动设计的思维过程，为您打开视野提供帮助。下面让我们一起看下耿大侠的文章吧。似曾相识最近在InfoQ上看到一篇谈论命令

03

【微服务架构】一文读懂单片到微服务架构的模式和最佳实践

在本文中，我们将学习如何使用设计模式、原则和最佳实践来设计微服务架构。我们将使用正确的架构设计模式和技术。在本文结束时，您将了解如何在微服务分布式架构上设计系统以实现高可用性、高可扩展性、低延迟和对网络故障的弹性，从而处理数百万个请求。 Event-Driven Architecture 本课程将是软件架构设计的旅程，逐步将架构单片演变为事件驱动的微服务。我们将从设计处理少量请求的电子商务整体架构开始软件架构的基础知识。 Journey of Design Architectures 之后逐步演

04

微服务架构及其最重要的10个设计模式

微服务架构，独享数据库、事件驱动、CQRS、Saga、BFF、API 网关、Strangler、断路器、外部化配置、消费端驱动的契约测试

01

设计模式：企业级和大型系统中常用的系统架构设计模式

在现代软件开发中，设计模式是一种至关重要的工具，尤其是在企业级和大型系统的构建过程中。设计模式不仅有助于解决常见的软件设计问题，还能提高代码的可维护性、可扩展性和复用性。在本文中，我们将探讨一些在企业级和大型系统中广泛使用的高级设计模式。

02

CQRS模式学习

当我们系统中的数据模型层级较少时，数据模型足够简单时，模型与数据库可以直接进行映射。这种简单数据模型使我们不需要针对其相互关系进行复杂的建模设计，直接在工程中使用经典的三层模型就足以支撑项目需求。

02

一周技术学习笔记(第62期)-CQRS是”有点不同“的读写分离

图自https://time.geekbang.org/dailylesson/detail/100056986

01

什么是微服务中的断路器设计模式？如何实施？

大家好，微服务设计模式是 Java 开发人员需要学习的非常重要的概念，不仅是为了创建一个健壮的、可扩展的、高性能的微服务架构，也是为了在 Java 开发人员面试中取得好成绩。过去，我分享了几种微服务设计模式，如 eEvent Sourcing、 SAGA、Database Per Microservices、CQRS、 API Gateway，还分享了设计微服务的最佳实践，在本文中，我将讨论断路器设计模式，以及如何使用 Spring Cloud Framework 在 Java 中实现。这不仅仅是一个重要的微服务模式还有一个流行的微服务问题，我在前面关于15 个微服务面试问题的文章中也提到过。如果您还没有阅读那篇文章，我建议您阅读它，特别是如果您正在准备 Java 和微服务面试。

03

微服务架构10个最重要的设计模式

自从软件开发的早期(1960年代)以来，解决大型软件系统中的复杂性一直是一项艰巨的任务。多年来，软件工程师和架构师为解决软件系统的复杂性进行了许多尝试：David Parnas的模块化和信息隐藏(1972)，Edsger W. Dijkstra的关注分离(1974)，面向服务的体系结构(1998)。

01

软件专业人员必知的6种现代化架构设计模式

许多现代应用程序需要在企业规模上构建，有时甚至需要在互联网规模上构建。每个应用程序都需要满足可伸缩性、可用性、安全性、可靠性和弹性要求。在本文中，我将讨论一些可以帮助你轻松实现上述功能的设计模式。我将讨论每种模式，如何在云原生环境中使用该模式，以及何时使用何时不使用。其中一些模式并不新鲜，但在当前互联网规模的云计算世界中非常有用。

01

流行20年的架构设计原则SOLID可能已经不适合微服务了

2000 年，Robert C. Martin 给架构师们总结出了一套原则来指导大家进行软件设计，Michael Feathers 随后按首字母将其总结成 SOLID 原则。从那时起，面向对象的 SOLID 设计原则就不断出现在相关书籍当中，并成为业界广为人知的指导方针：单一职责原则、开 / 闭原则、里氏替换原则、接口隔离原则、依赖倒置原则。

03

微服务架构中10个常用的设计模式

从软件开发早期（1960 年代）开始，应对大型软件系统中的复杂性一直是一项令人生畏的任务。多年来为了应对软件系统的复杂性，软件工程师和架构师们做了许多尝试：David Parnas 的模块化和封装（1972）， Edsger W. Dijkstra （1974）的关注点分离以及 SOA（1988）。

01

微服务架构设计中的设计模式、原则及最佳实践

本文既有理论知识，又有实用信息：我们将学习每一种具体的模式，为什么以及应该在什么地方使用；然后，我们将看下应用了这些模式的参考架构；接下来，我们将综合运用新学到的模式设计我们的架构；最后，我们将确定选用什么技术实现架构。

05

微服务架构设计中的设计模式、原则及最佳实践

本文将介绍微服务架构设计中的设计模式、原则及最佳实践。我们将使用适当的架构设计模式和技术。

02

CQRS距你有多远？

前面两集（微服务业务开发三个难题－拆分、事务、查询（上），微服务业务开发三个难题－拆分、事务、查询（下））翻译了Chris的大作。为了保证原意不跑偏同时通俗易懂，着实费了老大劲。今天我想把自己对CQRS的理解再用大白话说出来，与没时间看长文的各位共享。毫无疑问。CQRS是治愈微服务分布式查询的良药之一。 CQRS核心的内容就是：把写入和读取分离。也就是，Command Query Responsibility Segregation，命令查询责任分离。还是得从背景说起，我们都知道每个微服务应用都有自己的

08

微服务架构设计中的设计模式、原则及最佳实践

本文既有理论知识，又有实用信息：我们将学习每一种具体的模式，为什么以及应该在什么地方使用；然后，我们将看下应用了这些模式的参考架构；接下来，我们将综合运用新学到的模式设计我们的架构；最后，我们将确定选用什么技术实现架构。

07

微服务架构设计中的设计模式、原则及最佳实践

本文既有理论知识，又有实用信息：我们将学习每一种具体的模式，为什么以及应该在什么地方使用；然后，我们将看下应用了这些模式的参考架构；接下来，我们将综合运用新学到的模式设计我们的架构；最后，我们将确定选用什么技术实现架构。

03

网络或分布式场景下的系统设计模式介绍

网络或分布式场景是指一个系统由多个节点（如计算机、服务器、容器等）组成，这些节点通过网络进行通信和协作，以提供一些功能或服务。网络或分布式场景通常具有以下特点：

01

命令和查询责任隔离(CQRS)模式

通过使用单独的接口将读取数据的操作与更新数据的操作隔离开来。这可以最大化性能、可伸缩性和安全性。通过更高的灵活性支持系统随时间的发展，并防止更新命令在域级别引起合并冲突。

02

程序员除了会CRUD之外，还应该知道什么叫CQRS！

我们平常最熟悉的就是三层架构，通常都是通过数据访问层来修改或者查询数据，一般修改和查询使用的是相同的实体。然后通过业务层来处理业务逻辑，将处理结果封装成DTO对象返回给控制层，再通过前端渲染。反之亦然。

03

「软件架构」架构与设计InfoQ趋势报告 - 2019年1月

InfoQ和QCon都关注我们认为属于“创新者，早期采用者和早期多数阶段”的主题。我们尝试做的是确定适合Geoffrey Moore所谓的早期市场的想法，其中“客户群由技术爱好者和有远见的人提供，他们希望领先于机遇或迫在眉睫的问题”。我们也在寻找可能“跨越鸿沟”的想法，以便更广泛地采用。在这种情况下，或许值得一提的是，技术在采用曲线上的确切位置可能会有所不同。例如，湾区公司在这一点上广泛采用微服务，但在其他地方可能不太广泛采用，也许不太合适。

02

领域驱动设计概览

领域驱动设计（Domain Driven Design，DDD）是由Eric Evans最早提出的综合软件系统分析和设计的面向对象建模方法，如今已经发展为一种针对大型复杂系统的领域建模与分析方法。它完全改变了传统软件开发工程师针对数据库进行的建模方法，从而将要解决的业务概念和业务规则转换为软件系统中的类型以及类型的属性与行为，通过合理运用面向对象的封装、继承、多态等设计要素，降低或隐藏整个系统的业务复杂性，并使得系统具有更好的扩展性，应对纷繁多变的现实业务问题。

03

【Go实现】实践GoF的23种设计模式：命令模式

现在的软件系统往往是分层设计。在业务层执行一次请求时，我们很清楚请求的上下文，包括，请求是做什么的、参数有哪些、请求的接收者是谁、返回值是怎样的。相反，基础设施层并不需要完全清楚业务上下文，它只需知道请求的接收者是谁即可，否则就耦合过深了。

00

微服务架构设计和其设计模式介绍

之前在推上看到一张图片，感觉总结的挺好，在我也展开总结了之后发现了这张图的原文，所以整体翻译了一遍。还是非常有价值的，值得学习。

01

整洁架构、DDD 和 CQRS 简介

◆ 介绍在这篇博文中，我将介绍整洁架构（Clean Architecture ），它是一种现代、可扩展的正式软件架构，适用于现代 Web 应用程序。接下来，我将讨论DDD（领域驱动设计）如何适应这幅图景，以及 DDD 概念如何与清洁架构完美契合，从而产生一种称为清洁 DDD 的方法。最后，我介绍了命令查询职责分离 (CQRS)，并描述了它如何补充和增强 Clean DDD 解决方案，以创建优雅、健壮、可扩展和可测试的软件系统。 ◆ 清洁架构清洁建筑是一种相对“现代”的正式建筑，因为它不到十年的历史。它随

02

设计模式：规约模式（Specification-Pattern）

这句话很好的描述了设计模式的由来。前辈们通过实践和总结，将优秀的编程思想沉淀成设计模式，为开发者提供了解决问题的思路。除此之外，设计模式还是开发者之间沟通的桥梁，是程序员的语言，比如我说这段代码用的是单例模式，你就知道它的基本实现和用法。因此非常有必要弄清楚常用的设计模式。

03

程序员除了会CRUD之外，还应该知道什么叫CQRS！

我们平常最熟悉的就是三层架构，通常都是通过数据访问层来修改或者查询数据，一般修改和查询使用的是相同的实体。然后通过业务层来处理业务逻辑，将处理结果封装成DTO对象返回给控制层，再通过前端渲染。反之亦然。

05

DDD -- 领域驱动设计 -- 6步成诗法

记得很多年以前读Evans的《领域驱动设计 – 软件复杂性核心应对之道》，那个时候DDD还很少人知道，更不用说实践了，这本书呢也在我的书柜里沉睡了很多年。而最近发现，不光传统重业务的软件公司，就连很多互联网公司也在推DDD。

01

【看图学技术】- 微服务设计模式

推上看到这个图，也感觉总结梳理的还挺不错的。这类梳理主要针对已经有微服务实践的同学，回头再来看的时候就有点感觉了；如果你是刚开始做微服务，那这个图也就是看看，无法深入的理解。

03

干掉复杂代码 — Spring Boot 与 CQRS 才是黄金组合！

微服务的兴起以及现代软件架构对可扩展性、灵活性和可维护性的需求导致开发人员接受各种设计模式。

01

微服务中数据CQRS操作的事务处理

本文的主要主题是描述如何使用事件源（event sourcing）和CQRS将事件驱动的体系结构与微服务集成。

02

DDD（领域驱动设计）的这些问题，你都知道吗？

本文中的问题精选自上期【你问我答】——DDD（领域驱动设计）专题中读者的提问。【你问我答】是由美团点评技术团队推出的线上问答服务，你在工作学习中遇到的各种技术问题，都可以通过我们微信公众号发问，我们5000+工程师会义务为你解答，欢迎大家踊跃提问。高质量、定义清晰的问题会优先获得解答。编者按 DDD就是帮助工程师快速理解和提炼业务本质或核心的一套方法。 DDD又分战略设计和战术设计，这两个混一块就没法谈了。战略设计就是画一个圈，把里面的模型建出来。战术设计就是，在物理层次想尽一切办法保证边界不被突破和内部

浅谈CDC在微服务中的应用

CDC(Change Data Capture)是一种通过监测数据变更（变更包括新增、修改、删除等）而对变更的数据进行进一步处理的一种设计模式，通常应用在数据仓库以及和数据库密切相关的一些应用上，比如数据同步、备份、审计、ETL等。实际上，早在二十多年前，CDC就已经用来将应用系统的数据变更实时发送到数据仓库，进一步转换后传递到数据分析系统，这样能够在极小地影响生产的情况下，有效而及时地将数据传递到消费方。而在微服务架构逐渐流行的今天，这种古老的技术是否能够焕发新的生机？

03

【愚公系列】2023年01月 .NET CORE工具案例-基于MediatR的CQRS模式

CQRS 是一种与领域驱动设计 (DDD) 和事件溯源相关的架构模式，本质上是一种读写逻辑分离的机制。

01

CQRS架构

CQRS（Command Query Responsibility Segregation），命令查询责任隔离。我最初听到的是Greg Young描述的一种模式。其核心思想是，可以使用与用于读取信息的模型不同的模型来更新信息。在某些情况下，这种分离可能很有价值，但请注意，对于大多数系统，CQRS会增加风险的复杂性。人们用于与信息系统进行交互的主流方法是将其视为CRUD数据存储。我的意思是说，我们具有某种记录结构的思维模型，可以在完成处理后创建新记录，读取记录，更新现有记录以及删除记录。在最简单的情况下，我们的交互都是关于存储和检索这些记录的。随着我们的需求变得越来越复杂，我们逐渐摆脱了这种模式。我们可能希望以与记录存储不同的方式查看信息，也许将多个记录折叠成一个记录，或者通过组合不同位置的信息来形成虚拟记录。在更新方面，我们可能会发现验证规则，这些规则仅允许存储某些数据组合，甚至可能推断出与我们提供的数据不同的数据。

01

基于事件驱动的微服务模式

本文我们将讨论一些经常用在微服务应用中可扩展的设计模式: 事件流事件溯源通晓多语言的持久性内存镜像命令查询职责分离起因 Uber, Gilt和其它的公司由于需要做应用扩展，已经将单体应用转变

天花板级微服务大佬总结出这份451页笔记告诉你微服务就该这么学

小编就在这里推荐一份Chris Richardson写的《微服务架构设计模式》，他本人是微服务领域的专家，和微服务的提出者Martin Fowler一样出名。另外不要买中国人写的那些作者都是骗钱的，他们自己对微服务理解就不深。那些书大部分把微服务和spring cloud 划等号，对领域驱动设计，事件溯源，CQRS，SAGAS分布式事务只字不提。

02

微服务架构及设计模式

点击上方“芋道源码”，选择“设为星标” 管她前浪，还是后浪？能浪的浪，才是好浪！每天 10:33 更新文章，每天掉亿点点头发... 源码精品专栏原创 | Java 2021 超神之路，很肝~ 中文详细注释的开源项目 RPC 框架 Dubbo 源码解析网络应用框架 Netty 源码解析消息中间件 RocketMQ 源码解析数据库中间件 Sharding-JDBC 和 MyCAT 源码解析作业调度中间件 Elastic-Job 源码解析分布式事务中间件 TCC-Transaction

02

CQRS

对于复杂的系统来说，上面的做法做确实很不错。但是对于一个简单地系统来说，这样做是不是玩过火了？如果我们要设计一个博客系统的话，那么我们是不是可以考虑将Write/Read分离就可以了？

04

我的编程生涯里启发我的15本书

从几百本书中整理出一份书单是一件困难的事，但是从这些书中挑选出对自己影响比较大的书确是一件容易的事。在是一份迟来的书单，但是并不是一份适用于每个人的书单。这是我在学习编程过程中看的一些书，启发到我的书，有很多你可能没有听过，也有很多可能是你耳熟能详的。之所以说是启发是因为很多说并没有那么好，但是我从上面获取到了一些灵感。高中时期高中时期，因为想开发游戏的热情才深入计算机世界。并且高中也是一个相当无聊的时期，除了为高考准备的考试，还有就是上课《C++游戏开发》有一些书，你就没有必要去看了，比如这里的

07

如何运用领域驱动设计 - 存储库

在上一篇文章中，我们已经了解过领域驱动设计中一个很核心的对象-聚合。在现实场景中，我们往往需要将聚合持久化到某个地方，或者是从某个地方创建出聚合。此时就会使得领域对象与我们的基础架构产生紧密的耦合，那么我们应该怎么隔绝这一层耦合关系，使它们自身的职责界限更加清晰呢？是的，这就要用到我们今天要讲的内容 - 存储库。在很多地方，我们喜欢叫它为仓储，特别是在现有的AspNetCore应用中，大量的应用都在引入Repository这种东西。那么究竟什么是存储库呢？我们现在的使用方式是正确的吗？它在领域驱动设计中又扮演着怎样的角色呢？本文将从不同的角度来带大家重新认识一下“存储库”这个概念，并且给出相应的代码片段（本教程的代码片段都使用的是C#,后期的实战项目也是基于 DotNet Core 平台）。

03

微服务的设计模式

微服务架构已成为现代应用程序开发的事实上的选择。虽然它解决了某些问题，但它不是灵丹妙药。它有几个缺点，在使用这种架构时，必须解决许多问题。这就需要学习这些问题中的常见模式并用可重用的解决方案来解决它们。因此，需要讨论微服务的设计模式。在深入研究设计模式之前，我们需要了解微服务架构的构建原则：

02

[译] 微服务的设计模式

微服务架构已经成为现代应用程序开发中公认的技术选择。尽管它解决了某些问题，但不是灵丹妙药。它有几个缺点，使用这种体系架构时，还需要解决许多问题。这就需要学习这些问题的通用模式，并通过可重用的解决方案来解决它们。因此，有必要讨论微服务的设计模式。在深入研究设计模式之前，我们需要了解微服务架构的构建原理： 1.可扩展性 2.可用性 3.弹性 4.独立自治性 5.去中心化治理 6.失败隔离 7.自动配置 8.通过DevOps持续交付

05

【微服务】构建应用程序的顶级微服务设计模式

在当今市场上，微服务已成为构建应用程序的首选解决方案。众所周知，它们可以解决各种挑战，但是，熟练的专业人员在使用此架构时经常面临挑战。因此，相反，开发人员可以探索这些问题中的常见模式，并可以创建可重用的解决方案来提高应用程序的性能。因此，在这篇关于微服务设计模式的文章中，我将讨论构建成功的微服务所必需的顶级模式。本文将介绍以下主题：什么是微服务？用于设计微服务架构的原则微服务的设计模式什么是微服务？微服务，又名微服务架构，是一种架构风格，将应用程序构建为围绕业务领域建模的小型自治服务的集

03

【Python 】在 Python 中使用架构模式管理复杂性

你的源代码是不是感觉像一个大泥球？依赖项是否在您的代码库中交织在一起，以至于改变感觉很危险或不可能？随着业务的增长和领域模型（您在应用程序中解决的业务问题）变得更加复杂，我们如何在不从头开始重新编写所有内容的情况下解开我们创建的混乱？更好的是，我们如何避免一开始就陷入混乱？鸟瞰图以下是 Python 架构模式中介绍的技术的简要总结：分层架构单一职责视图 vs 服务 vs 存储库 vs ORM vs 域依赖倒置高级与低级模块抽象领域驱动设计先说“业务上下文” 领域建模（事件风暴等

03

小型系统如何“微服务”开发

https://www.cnblogs.com/wcd144140/p/9782823.html

02

小型系统如何“微服务”开发

提到“微服务”，我相信网上各种“微服务”的演变案例都会给人一种“因大而分”的前提错觉，这可能会导致许多的“小白”产生没有机会接触“大项目”而对“微服务”可望而不可及也。当然，这种错觉的产生可能更多来源自于各种“微技术”的“层出不穷”所以“眼花缭乱”，例如Spring Cloud。虽然“大项目”机会不多，但也阻止不了“钉子们”通过教程把微技术跑一遍来装饰自己可以“微”起来的自信。

02

小型系统如何“微服务”开发

提到“微服务”，我相信网上各种“微服务”的演变案例都会给人一种“因大而分”的前提错觉，这可能会导致许多的“小白”产生没有机会接触“大项目”而对“微服务”可望而不可及也。当然，这种错觉的产生可能更多来源自于各种“微技术”的“层出不穷”所以“眼花缭乱”，例如Spring Cloud。虽然“大项目”机会不多，但也阻止不了“钉子们”通过教程把微技术跑一遍来装饰自己可以“微”起来的自信。

03

超越 DTO：探索 Java Record

如果你跟得上 Java 的发布节奏并且知道最新的 LTS 版本 Java 17，那么你可以了解一下支持不可变类的 Record 特性。

02

API 设计：CQRS（命令查询职责分离）

CQRS（Command Query Responsibility Segregation）指的是命令查询职责分离。这是一种我从 Greg Young 处听到的模式描述。它的核心思想很简单，就是你在更新和读取操作时使用不同的模型，这样的话，会给整个系统的设计带来深远的变革。

01

命令和查询责任分离 (CQRS) 模式

使用独立接口将读取数据的操作与更新数据的操作分离。这可以最大程度地提高性能、可伸缩性和安全性。通过提高灵活性，让系统随着时间的推移而改进；防止更新命令在域级别引发并冲突。

05

扫码

添加站长进交流群

领取专属 10元无门槛券

手把手带您无忧上云

扫码加入开发者社群

相关资讯

热门标签

活动推荐

运营活动

活动名称

广告关闭