项目架构
这是第一版的系统架构，后续设计是以这个为基础考虑的，但不是终版！贴出来主要是方便理解技术选型。
技术选型
前端虽然会写，但是确实不擅长，所以直接采用Figma使用的React，并没有什么选择的余地。
框架
后端当然采用SpringBoot作为框架，小项目没必要特意采用SpringCloud。
但是还是会采用新版本来使用的 SpringBoot3.5.0、SpringCloud 2025.0.0.0、SpringCloud Alibaba 2023.0.3.2
大概就是这些版本，小版本号可能没对齐，但是问题不大。
注册中心
Nacos 3.0
没什么理由，足够熟悉、足够强大，要是真能发现什么问题就顺手提PR了。简单方便、开箱就能用，不用考虑几个软件组合起来。
数据库
PostgreSQL 15 + Redis
版本选择比较新的稳定版，Redis没啥好说的，你有问题他都不会有问题，有事自己身上先找找，开个玩笑，其实缓存确实没啥好选的，能用就行，况且Redis我也是读过源码的，足够熟悉了，而且这么多年的使用确实没有任何超过边界的需求。
重点是PostgreSQL。我用Q.A.的形式来讲解一下选型理由。
为什么选择PostgreSQL而不是MySQL？
最关键的一点是在于对于JSON的支持 ，前者对于JSON的支持十分高效，本项目由于对接AI居多，并且在开发过程中会由于提示词的频繁更改涉及到数据结构的变化，如果采用Mysql的固定表结构就会经常地震(纵向修改整个项目)，字段存储json是一个比较好的方案，那么我自然会采用支持更好的PostgreSQL。另外PostgreSQL的一些分词、数据类型、生态、性能都是考虑过的点，但是实际上也算是加分项，并不是决定因素。
最后一个原因是因为我不了解PostgreSQL ，没错，我其实并没有使用过PostgreSQL，我看过许多文章，了解过许多特性，但是唯独没有实践过，于是我在简单用DEMO项目测试使用过之后发现和MySQL的学习过渡曲线较为平滑，就借此机会学习一下。
对象存储
MinIO
选用这个其实有点重了，实际上整理文章的时候发现开发过程中也注意到实际上没有这么大的文件存储需求，只是单纯的想学习一下。
搜索引擎
ElasticSearch 8.x
搭建知识库会用到（没还写呢），这个没什么好说的，没啥好选的。
消息队列
RabbitMQ 3.11
轻量并且和Spring结合好，配置少。
监控
Prometheus + Grafana + Micrometer
这个其实是一套十分成熟的监控体系了，本人工作中有足够的使用经验，所以还是十分熟悉的，但是后来整理文章的时候想到，其实也没有那么需要自定义，其实skywalking就够了。
服务间通信
同步调用：OpenFeign
异步消息：RabbitMQ（任务队列、事件通知）
配置管理：Nacos
对于OpenFeign后面会有大篇幅解释使用方式和选型理由，并不是单纯的给自己找事做。
总结
虽然内容不多，可能有些选型只是短短几个字，但是实际山背后是很多功能点的权衡，而且即便实现仔细考虑，在后续的开发过程中还是会后悔当初的一些选择，不过这都会成为下一次选型的经验（必可活用于下次）。