不停地书写,方能不失在人海茫茫。
1.前言
之前给大家写了ChatGPT对接企业微信的教程,具体可看知乎链接:
【奶奶看了都会】ChatGPT3.5接入企业微信,可连续对话
文章结尾说了教程只能适用于小规模使用,网上能找到的其他ChatGPT对接钉钉、飞书、自定义网页等等教程,原理都是一样的,写个中转程序,在ChatGPT和你用的交互工具之间中转一遍。是个简单的单体系统,逻辑看下图
![](https://img2023.cnblogs.com/blog/2784584/202304/2784584-20230401084704542-1468169287.png)
这种单体系统设计简单,很快就能开发完成并应用。缺点就是性能瓶颈限制在单台服务器上,无法支持高并发场景,举例说明,现在有10万人要用这个系统,系统会直接崩溃。
2.分布式ChatGPT对接系统
基于此,我们需要设计一个分布式系统,整体架构看下图
![](https://img2023.cnblogs.com/blog/2784584/202304/2784584-20230401084727340-474184268.png)
2.1 交互层
交互层就不多说了,就是用户直接使用ChatGPT的工具,可以是企业微信、钉钉、网页等等。这些工具都有对应的官方文档,简单说就是输入和输出接口
2.2 客户端层
- 负责接收交互层传入的文本信息,转发给服务端;
- 同时接收服务端的响应信息,回传给交互工具;
- 缓存对话上下文,支持连续对话
这里的构想是客户端有多个请求入口,比如每个公司都有自己的企业微信,给每个公司分配指定IP的客户端。
这样做的好处是流量入口不会单一,不需要再做一层负载均衡流量分发。链路图可参考下面:
![](https://img2023.cnblogs.com/blog/2784584/202304/2784584-20230401084747526-419567804.png)
2.3注册中心
注册中心的作用:
- 服务注册:服务端启动后,将自己的信息注册到注册中心,包括IP、端口、服务接口等。
- 服务发现:客户端通过注册中心获取路由表,查询服务端的IP和端口,从而调用服务
- 负载均衡:平衡流量,将客户端请求服务端的流量按特定分发策略,分配到不同的服务器上
- 服务健康检查:维护注册中心和服务端的心跳检查,在某个实例故障时能从注册中心上移除,避免服务调用失败
简单地说,有了注册中心后,可通过给服务端水平扩容提升系统的并发能力,能支持更多人使用系统。
2.4 服务端
服务端作用:
- 接收客户端传入的信息,包括:对话上下文、GPT key
- 和ChatGPT API交互,接收API回传的信息文本,并回传给客户端
- 服务降级,支持手动降级,在ChatGPT不可用时,能降级到ChatGLM、文心一言等等对话大模型,保证对话功能仍然可用。
2.5 数据存储层
主要作用:
-
存储对话上下文数据
-
支持数据设置过期时间,到期自动删除
-
要求读取数据和写入数据响应时间短
3.技术选型
系统整体架构设计完后,具体用哪种语言去实现就根据自己擅长的了,这里说说我用的
- RPC框架:Dubbo
- 编程语言和框架:Java8、SpringBoot
- 存储中间件:Redis
- 注册中心:Nacos
- 链路追踪和服务监控:Skywalking(可选)
- 代码托管和自动化部署:阿里云-云效
4.具体实现
目前计划按上面的架构设计实现一版系统,代码不会开源,有使用需求的可以联系我
后续还会更新架构中用到的技术点的文章,大家可以点下关注,文章更新时会及时通知到的