微服务架构｜go-zero 的自适应熔断器

原文链接： go-zero 的自适应熔断器

上篇文章我们介绍了微服务的限流，详细分析了计数器限流和令牌桶限流算法，这篇文章来说说熔断。

熔断和限流还不太一样，限流是控制请求速率，只要还能承受，那么都会处理，但熔断不是。

在一条调用链上，如果发现某个服务异常，比如响应超时。那么调用者为了避免过多请求导致资源消耗过大，最终引发系统雪崩，会直接返回错误，而不是疯狂调用这个服务。

本篇文章会介绍主流熔断器的工作原理，并且会借助 go-zero 源码，分析 googleBreaker 是如何通过滑动窗口来统计流量，并且最终执行熔断的。

工作原理

这部分主要介绍两种熔断器的工作原理，分别是 Netflix 开源的 Hystrix，其也是 Spring Cloud 默认的熔断组件，和 Google 的自适应的熔断器。

Hystrix is no longer in active development, and is currently in maintenance mode.

注意，Hystrix 官方已经宣布不再积极开发了，目前处在维护模式。

Hystrix 官方推荐替代的开源组件：Resilience4j，还有阿里开源的 Sentinel 也是不错的替代品。

hystrixBreaker

Hystrix 采用了熔断器模式，相当于电路中的保险丝，系统出现紧急问题，立刻禁止所有请求，已达到保护系统的作用。

系统需要维护三种状态，分别是：

  • 关闭： 默认状态，所有请求全部能够通过。当请求失败数量增加，失败率超过阈值时，会进入到断开状态。
  • 断开： 此状态下，所有请求都会被拦截。当经过一段超时时间后，会进入到半断开状态。
  • 半断开： 此状态下会允许一部分请求通过，并统计成功数量，当请求成功时，恢复到关闭状态，否则继续断开。

通过状态的变更，可以有效防止系统雪崩的问题。同时，在半断开状态下，又可以让系统进行自我修复。

googleBreaker

googleBreaker 实现了一种自适应的熔断模式，来看一下算法的计算公式，客户端请求被拒绝的概率。

参数很少，也比较好理解：

  1. requests：请求数量
  2. accepts：后端接收的请求数量
  3. K：敏感度，一般推荐 1.5-2 之间

通过分析公式，我们可以得到下面几个结论，也就是产生熔断的实际原理：

  1. 正常情况下，requests 和 accepts 是相等的，拒绝的概率就是 0，没有产生熔断
  2. 当正常请求量，也就是 accepts 减少时，概率会逐渐增加，当概率大于 0 时，就会产生熔断。如果 accepts 等于 0 了，则完全熔断。
  3. 当服务恢复后，requests 和 accepts 的数量会同时增加，但由于 K * accepts 增长的更快，所以概率又会很快变回到 0，相当于关闭了熔断。

总的来说，googleBreaker 的实现方案更加优雅，而且参数也少，不用维护那么多的状态。

go-zero 就是采用了 googleBreaker 的方案，下面就来分析代码，看看到底是怎么实现的。

接口设计

接口定义这部分我个人感觉还是挺不好理解的，看了好多遍才理清了它们之间的关系。

其实看代码和看书是一样的，书越看越薄，代码会越看越短。刚开始看感觉代码很长，随着看懂的地方越来越多，明显感觉代码变短了。所以遇到不懂的代码不要怕，反复看，总会看懂的。

首先来看一下 breaker 部分的 UML 图，有了这张图，很多地方看起来还是相对清晰的，下面来详细分析。

这里用到了静态代理模式，也可以说是接口装饰器，接下来就看看到底是怎么定义的：

// core/breaker/breaker.go
internalThrottle interface {allow() (internalPromise, error)doReq(req func() error, fallback func(err error) error, acceptable Acceptable) error
}// core/breaker/googlebreaker.go
type googleBreaker struct {k     float64stat  *collection.RollingWindowproba *mathx.Proba
}

这个接口是最终实现熔断方法的接口，由 googleBreaker 结构体实现。

// core/breaker/breaker.go
throttle interface {allow() (Promise, error)doReq(req func() error, fallback func(err error) error, acceptable Acceptable) error
}type loggedThrottle struct {name stringinternalThrottleerrWin *errorWindow
}func newLoggedThrottle(name string, t internalThrottle) loggedThrottle {return loggedThrottle{name:             name,internalThrottle: t,errWin:           new(errorWindow),}
}

这个是实现了日志收集的结构体，首先它实现了 throttle 接口，然后它包含了一个字段 internalThrottle，相当于具体的熔断方法是代理给 internalThrottle 来做的。

// core/breaker/breaker.go
func (lt loggedThrottle) allow() (Promise, error) {promise, err := lt.internalThrottle.allow()return promiseWithReason{promise: promise,errWin:  lt.errWin,}, lt.logError(err)
}func (lt loggedThrottle) doReq(req func() error, fallback func(err error) error, acceptable Acceptable) error {return lt.logError(lt.internalThrottle.doReq(req, fallback, func(err error) bool {accept := acceptable(err)if !accept && err != nil {lt.errWin.add(err.Error())}return accept}))
}

所以当它执行相应方法时，都是直接调用 internalThrottle 接口的方法，然后再加上自己的逻辑。

这也就是代理所起到的作用，在不改变原方法的基础上，扩展原方法的功能。

// core/breaker/breaker.go
circuitBreaker struct {name stringthrottle
}// NewBreaker returns a Breaker object.
// opts can be used to customize the Breaker.
func NewBreaker(opts ...Option) Breaker {var b circuitBreakerfor _, opt := range opts {opt(&b)}if len(b.name) == 0 {b.name = stringx.Rand()}b.throttle = newLoggedThrottle(b.name, newGoogleBreaker())return &b
}

最终的熔断器又将功能代理给了 throttle。

这就是它们之间的关系，如果感觉有点乱的话，就反复看，看的次数多了，就清晰了。

日志收集

上文介绍过了，loggedThrottle 是为了记录日志而设计的代理层，这部分内容来分析一下是如何记录日志的。

// core/breaker/breaker.go
type errorWindow struct {// 记录日志的数组reasons [numHistoryReasons]string// 索引index   int// 数组元素数量，小于等于 numHistoryReasonscount   intlock    sync.Mutex
}func (ew *errorWindow) add(reason string) {ew.lock.Lock()// 记录错误日志内容ew.reasons[ew.index] = fmt.Sprintf("%s %s", time.Now().Format(timeFormat), reason)// 对 numHistoryReasons 进行取余来得到数组索引ew.index = (ew.index + 1) % numHistoryReasonsew.count = mathx.MinInt(ew.count+1, numHistoryReasons)ew.lock.Unlock()
}func (ew *errorWindow) String() string {var reasons []stringew.lock.Lock()// reverse orderfor i := ew.index - 1; i >= ew.index-ew.count; i-- {reasons = append(reasons, ew.reasons[(i+numHistoryReasons)%numHistoryReasons])}ew.lock.Unlock()return strings.Join(reasons, "\n")
}

核心就是这里采用了一个环形数组，通过维护两个字段来实现，分别是 index 和 count。

count 表示数组中元素的个数，最大值是数组的长度；index 是索引，每次 +1，然后对数组长度取余得到新索引。

我之前有一次面试就让我设计一个环形数组，当时答的还不是很好，这次算是学会了。

滑动窗口

一般来说，想要判断是否需要触发熔断，那么首先要知道一段时间的请求数量，一段时间内的数量统计可以使用滑动窗口来实现。

首先看一下滑动窗口的定义：

// core/collection/rollingwindow.gotype RollingWindow struct {lock          sync.RWMutex// 窗口大小size          int// 窗口数据容器win           *window// 时间间隔interval      time.Duration// 游标，用于定位当前应该写入哪个 bucketoffset        int// 汇总数据时，是否忽略当前正在写入桶的数据// 某些场景下因为当前正在写入的桶数据并没有经过完整的窗口时间间隔// 可能导致当前桶的统计并不准确ignoreCurrent bool// 最后写入桶的时间// 用于计算下一次写入数据间隔最后一次写入数据的之间// 经过了多少个时间间隔lastTime      time.Duration // start time of the last bucket
}

再来看一下 window 的结构：

type Bucket struct {// 桶内值的和Sum   float64// 桶内 add 次数Count int64
}func (b *Bucket) add(v float64) {b.Sum += vb.Count++
}func (b *Bucket) reset() {b.Sum = 0b.Count = 0
}type window struct {// 桶，一个桶就是一个时间间隔buckets []*Bucket// 窗口大小，也就是桶的数量size    int
}

有了这两个结构之后，我们就可以画出这个滑动窗口了，如图所示。

现在来看一下向窗口中添加数据，是怎样一个过程。

func (rw *RollingWindow) Add(v float64) {rw.lock.Lock()defer rw.lock.Unlock()// 获取当前写入下标rw.updateOffset()// 向 bucket 中写入数据rw.win.add(rw.offset, v)
}func (rw *RollingWindow) span() int {// 计算距离 lastTime 经过了多少个时间间隔，也就是多少个桶offset := int(timex.Since(rw.lastTime) / rw.interval)// 如果在窗口范围内，返回实际值，否则返回窗口大小if 0 <= offset && offset < rw.size {return offset}return rw.size
}func (rw *RollingWindow) updateOffset() {// 经过了多少个时间间隔，也就是多少个桶span := rw.span()// 还在同一单元时间内不需要更新if span <= 0 {return}offset := rw.offset// reset expired buckets// 这里是清除过期桶的数据// 也是对数组大小进行取余的方式，类似上文介绍的环形数组for i := 0; i < span; i++ {rw.win.resetBucket((offset + i + 1) % rw.size)}// 更新游标rw.offset = (offset + span) % rw.sizenow := timex.Now()// align to interval time boundary// 这里应该是一个时间的对齐，保持在桶内指向位置是一致的rw.lastTime = now - (now-rw.lastTime)%rw.interval
}// 向桶内添加数据
func (w *window) add(offset int, v float64) {// 根据 offset 对数组大小取余得到索引，然后添加数据w.buckets[offset%w.size].add(v)
}// 重置桶数据
func (w *window) resetBucket(offset int) {w.buckets[offset%w.size].reset()
}

我画了一张图，来模拟整个滑动过程：

主要经历 4 个步骤：

  1. 计算当前时间距离上次添加时间经过了多少个时间间隔，也就是多少个 bucket
  2. 清理过期桶数据
  3. 更新 offset，更新 offset 的过程实际就是模拟窗口滑动的过程
  4. 添加数据

比如上图，刚开始 offset 指向了 bucket[1]，经过了两个 span 之后，bucket[2] 和 bucket[3] 会被清空，同时，新的 offset 会指向 bucket[3]，新添加的数据会写入到 bucket[3]。

再来看看数据统计，也就是窗口内的有效数据量是多少。

// Reduce runs fn on all buckets, ignore current bucket if ignoreCurrent was set.
func (rw *RollingWindow) Reduce(fn func(b *Bucket)) {rw.lock.RLock()defer rw.lock.RUnlock()var diff intspan := rw.span()// ignore current bucket, because of partial dataif span == 0 && rw.ignoreCurrent {diff = rw.size - 1} else {diff = rw.size - span}// 需要统计的 bucket 数量，窗口大小减去 span 数量if diff > 0 {// 获取统计的起始位置，span 是已经被重置的 bucketoffset := (rw.offset + span + 1) % rw.sizerw.win.reduce(offset, diff, fn)}
}func (w *window) reduce(start, count int, fn func(b *Bucket)) {for i := 0; i < count; i++ {// 自定义统计函数fn(w.buckets[(start+i)%w.size])}
}

统计出窗口数据之后，就可以判断是否需要熔断了。

执行熔断

接下来就是执行熔断了，主要就是看看自适应熔断是如何实现的。

// core/breaker/googlebreaker.goconst (// 250ms for bucket durationwindow     = time.Second * 10buckets    = 40k          = 1.5protection = 5
)

窗口的定义部分，整个窗口是 10s，然后分成 40 个 bucket，每个 bucket 就是 250ms。

// googleBreaker is a netflixBreaker pattern from google.
// see Client-Side Throttling section in https://landing.google.com/sre/sre-book/chapters/handling-overload/
type googleBreaker struct {k     float64stat  *collection.RollingWindowproba *mathx.Proba
}func (b *googleBreaker) accept() error {// 获取最近一段时间的统计数据accepts, total := b.history()// 根据上文提到的算法来计算一个概率weightedAccepts := b.k * float64(accepts)// https://landing.google.com/sre/sre-book/chapters/handling-overload/#eq2101dropRatio := math.Max(0, (float64(total-protection)-weightedAccepts)/float64(total+1))// 如果小于等于 0 直接通过，不熔断if dropRatio <= 0 {return nil}// 随机产生 0.0-1.0 之间的随机数与上面计算出来的熔断概率相比较// 如果随机数比熔断概率小则进行熔断if b.proba.TrueOnProba(dropRatio) {return ErrServiceUnavailable}return nil
}func (b *googleBreaker) history() (accepts, total int64) {b.stat.Reduce(func(b *collection.Bucket) {accepts += int64(b.Sum)total += b.Count})return
}

以上就是自适应熔断的逻辑，通过概率的比较来随机淘汰掉部分请求，然后随着服务恢复，淘汰的请求会逐渐变少，直至不淘汰。

func (b *googleBreaker) allow() (internalPromise, error) {if err := b.accept(); err != nil {return nil, err}// 返回一个 promise 异步回调对象，可由开发者自行决定是否上报结果到熔断器return googlePromise{b: b,}, nil
}// req - 熔断对象方法
// fallback - 自定义快速失败函数，可对熔断产生的err进行包装后返回
// acceptable - 对本次未熔断时执行请求的结果进行自定义的判定，比如可以针对http.code,rpc.code,body.code
func (b *googleBreaker) doReq(req func() error, fallback func(err error) error, acceptable Acceptable) error {if err := b.accept(); err != nil {// 熔断中，如果有自定义的fallback则执行if fallback != nil {return fallback(err)}return err}defer func() {// 如果执行req()过程发生了panic，依然判定本次执行失败上报至熔断器if e := recover(); e != nil {b.markFailure()panic(e)}}()err := req()// 上报结果if acceptable(err) {b.markSuccess()} else {b.markFailure()}return err
}

熔断器对外暴露两种类型的方法：

1、简单场景直接判断对象是否被熔断，执行请求后必须需手动上报执行结果至熔断器。

func (b *googleBreaker) allow() (internalPromise, error)

2、复杂场景下支持自定义快速失败，自定义判定请求是否成功的熔断方法，自动上报执行结果至熔断器。

func (b *googleBreaker) doReq(req func() error, fallback func(err error) error, acceptable Acceptable) error

个人感觉，熔断这部分代码，相较于前几篇文章，理解起来是更困难的。但其中的一些设计思想，和底层的实现原理也是非常值得学习的，希望这篇文章能够对大家有帮助。

以上就是本文的全部内容，如果觉得还不错的话欢迎点赞，转发和关注，感谢支持。

参考文章：

  • https://juejin.cn/post/7030997067560386590
  • https://go-zero.dev/docs/tutorials/service/governance/breaker
  • https://sre.google/sre-book/handling-overload/
  • https://martinfowler.com/bliki/CircuitBreaker.html

推荐阅读：

  • go-zero 是如何实现令牌桶限流的？
  • go-zero 是如何实现计数器限流的？
  • go-zero 是如何做路由管理的？

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.mzph.cn/news/63536.shtml

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

C# 多线程交替按照指定顺序执行

C# 多线程交替按照指定顺序执行

1.关于AutoResetEvent和ManualResetEvent的区别解释如下&#xff1a; AutoResetEvent和ManualResetEvent是.NET中的两个线程同步类。它们之间的主要区别在于其释放信号的方式以及对等待线程的影响。 AutoResetEvent的作用是在等待的线程被信号唤醒后&#xff0c;将信号自动重…
阅读更多...
Rust 学习笔记（持续更新中…）

Rust 学习笔记（持续更新中…）

一、 编译和运行是单独的两步 运行 Rust 程序之前必须先编译&#xff0c;命令为&#xff1a;rustc 源文件名 - rustc main.rs编译成功之后&#xff0c;会生成一个二进制文件 - 在 Windows 上还会生产一个 .pdb 文件 &#xff0c;里面包含调试信息Rust 是 ahead-of-time 编译的…
阅读更多...
数据库-DML

数据库-DML

DML&#xff1a;用来对数据库中表的数据记录进行增、删、改等操作。 添加数据&#xff08;INSERT&#xff09; insert语法&#xff1a; 指定字段添加数据&#xff1a;insert into 表单&#xff08;字段名1&#xff0c;字段名2&#xff09;values&#xff08;值1&#xff0c;值…
阅读更多...
CSS中如何实现弹性盒子布局（Flexbox）的换行和排序功能？

CSS中如何实现弹性盒子布局（Flexbox）的换行和排序功能？

聚沙成塔每天进步一点点 ⭐ 专栏简介⭐ 换行&#xff08;Flexbox Wrapping&#xff09;⭐ 示例&#xff1a;实现换行⭐ 排序&#xff08;Flexbox Ordering&#xff09;⭐ 示例&#xff1a;实现排序⭐ 写在最后 ⭐ 专栏简介 前端入门之旅&#xff1a;探索Web开发的奇妙世界 记得…
阅读更多...
分布式集群框架——有关zookeeper的面试考点

分布式集群框架——有关zookeeper的面试考点

3.掌握Zookeeper的概念 当涉及到大规模分布式系统的协调和管理时&#xff0c;Zookeeper是一个非常重要的工具。 1. 分布式协调服务&#xff1a;Zookeeper是一个分布式协调服务&#xff0c;它提供了一个高可用和高性能的环境&#xff0c;用于协调和同步分布式系统中的各个节点…
阅读更多...
Java中支持分库分表的框架/组件/中间件简介

Java中支持分库分表的框架/组件/中间件简介

文章目录 1 sharding-jdbc2 TSharding3 Atlas4 Cobar5 MyCAT6 TDDL7 Vitess 列举一些比较常见的&#xff0c;简单介绍一下&#xff1a; sharding-jdbc&#xff08;当当&#xff09; TSharding&#xff08;蘑菇街&#xff09; Atlas&#xff08;奇虎360&#xff09; Cobar&#…
阅读更多...
k8s(kubernetes)介绍篇

k8s(kubernetes)介绍篇

一、Kubernetes 是什么 Kubernetes 是一个全新的基于容器技术的分布式架构解决方案&#xff0c;是 Google 开源的一个容器集群管理系统&#xff0c;Kubernetes 简称 K8S。 Kubernetes 是一个一站式的完备的分布式系统开发和支撑平台&#xff0c;更是一个开放平台&#xff0c;对…
阅读更多...
面试题--从键盘输入网站到网页显示，之间发生了什么

面试题--从键盘输入网站到网页显示，之间发生了什么

文章目录 首先进入HTTP阶段协议栈阶段TCP阶段IP阶段MAC网卡交换机路由器抵达 首先进入HTTP阶段 1.解析对应的URL&#xff0c;访问一个对应的服务器xxx.com的一个文件index.html; 2 使用DNS查询对应的ip地址&#xff0c;通过DNS服务器进行查找 3 组装http报文&#xff0c;生成h…
阅读更多...
低成本32位单片机电动工具无感方波控制方案

低成本32位单片机电动工具无感方波控制方案

RAMSUN介绍基于灵动32位微处理器MM32SPIN0230的BLDC电动工具无感方波控制方案&#xff0c;包括MM32SPIN0230芯片资源。 以下是电动工具无感方波控制方案的简述&#xff1a; MM32SPIN0230电动工具专用板 芯片介绍 MM32SPIN0230系列是灵动微MindSPIN旗下高性能的单电机控制产品…
阅读更多...
Spring Boot框架以及它的优势

Spring Boot框架以及它的优势

文章目录 介绍1. **简化配置**2. **快速启动**3. **自动配置**4. **集成第三方库和框架**5. **微服务支持**6. **内嵌式数据库支持**7. **健康监控和管理**8. **可插拔的开发工具**9. **丰富的社区和生态系统**10. **良好的测试支持&#xff1a;** 核心特性**1. 依赖注入&#…
阅读更多...
ElasticSearch学习4--复杂查询

ElasticSearch学习4--复杂查询

1、查询分类 查询所有&#xff1a;查询出所有数据&#xff0c;一般测试用。例如&#xff1a;match_all全文检索&#xff08;full text&#xff09;查询&#xff1a;利用分词器对用户输入内容分词&#xff0c;然后去倒排索引库中匹配。例如&#xff1a; match_query 根据单个字段…
阅读更多...
yolov8机器视觉-工业质检

yolov8机器视觉-工业质检

使用训练好的模型进行预测 yolo predict taskdetect model训练好的模型路径 source测试图片文件夹路径 showTrue效果展示 切换模型进行训练&#xff08;yolov8s&#xff09; 修改main.py训练参数文件 使用云gpu进行训练&#xff0c;很方便&#xff1a;点击链接转至在线云gpu…
阅读更多...
面试被打脸，数据结构底层都不知道么--回去等通知吧

面试被打脸，数据结构底层都不知道么--回去等通知吧

数据结构之常见的8种数据结构&#xff1a; -数组Array -链表 Linked List -堆 heap -栈 stack -队列 Queue -树 Tree -散列表 Hash -图 Graph 数据结构-链表篇 Linklist定义&#xff1a; -是一种线性表&#xff0c;并不会按线性的顺序存储数据&#xff0c;即逻辑上相邻…
阅读更多...
【算法竞赛宝典】语言之争

【算法竞赛宝典】语言之争

【算法竞赛宝典】语言之争 题目描述代码展示 题目描述 代码展示 //语言之争 #include<fstream> #include<string>using namespace std;ifstream cin("language.in"); ofstream cout("language.out");string a; int n;int main() {int i;bool …
阅读更多...
短信验证码服务

短信验证码服务

使用的是 阿里云 阿里云官网 1.找到 左上角侧边栏 -云通信 -短信服务 2.在快速学习测试处 &#xff0c;按照步骤完成快速学习&#xff0c;绑定要测试的手机号&#xff0c;选专用 【测试模板】&#xff0c;自定义模板需要人工审核&#xff0c;要一个工作日 3.右上角 获取 Acces…
阅读更多...
敦煌网、newegg店铺优化三大方法，测评补单原来可以这样做

敦煌网、newegg店铺优化三大方法，测评补单原来可以这样做

我们都知道敦煌网、newegg流量是一个店铺的血液&#xff0c;没有流量的支撑&#xff0c;其他也都将成为浮云。流量能够成为转化率的保证&#xff0c;如何让店铺拥有傲人的流量成为重要之重&#xff0c;店铺的流量又主要来源于以下几部分&#xff1a; 一、主要流量的来源 1.搜索…
阅读更多...
PyTorch深度学习遥感影像地物分类与目标检测、分割及遥感影像问题深度学习优化实践技术应用

PyTorch深度学习遥感影像地物分类与目标检测、分割及遥感影像问题深度学习优化实践技术应用

我国高分辨率对地观测系统重大专项已全面启动&#xff0c;高空间、高光谱、高时间分辨率和宽地面覆盖于一体的全球天空地一体化立体对地观测网逐步形成&#xff0c;将成为保障国家安全的基础性和战略性资源。未来10年全球每天获取的观测数据将超过10PB&#xff0c;遥感大数据时…
阅读更多...
【unity插件】使用BehaviorDesigner插件制作BOSS的AI行为树

【unity插件】使用BehaviorDesigner插件制作BOSS的AI行为树

文章目录 前言素材插件一、基础使用二、敌人物理攻击三、敌人面向玩家四、敌人法术攻击五、随机进行攻击六、敌人不同的阶段推荐学习视频源码完结 前言 Behavior Designer是一个行为树插件&#xff0c;是一款为了让策划&#xff0c;程序员&#xff0c;美术人员方便使用的可视化…
阅读更多...
再谈IOS开发环境配置（2023-09-01 新）

再谈IOS开发环境配置（2023-09-01 新）

关于IOS的开发&#xff0c;需要配置证书、密钥、管理标识符、功能配置等等&#xff0c;很是繁杂&#xff0c;以前也配置过&#xff0c;这次因为重新购买了新的M1笔记本&#xff0c;准备重新配置下&#xff0c;顺便记录&#xff0c;以便查询。 如果要开发IOS&#xff0c;首先需要…
阅读更多...
Midjourney学习(一)prompt的基础

Midjourney学习(一)prompt的基础

prompt目录 sd和mj的比较prompt组成风格表现风格时代描述表情色彩情绪环境 sd和mj的比较 自从去年9月份开始&#xff0c;sd就变得非常或火&#xff0c;跟它一起的还有一个midjourney。 他们就像是程序界的两种模式&#xff0c;sd是开源的&#xff0c;有更多的可能性更可控。但是…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023