最近部门想让应用无状态化，让服务支持多副本，佬们有什么经验和建议嘛！
目前了解到，文件存储、本地缓存、本地日志这块都需要进行一系列的改造，佬们还有其他的思路嘛 
多副本那就上k8s吧，维护简单，除了对象存储、分布式缓存、日志上报等环境的方案之外，其他的主要是分布式事务的解决了，简单的业务加个分布式锁，在业务上做重试补偿之类的逻辑，复杂一点看具体情况具体分析了，也有对应的中间件去处理
2 Likes
无非就是将「状态」迁移到 redis/数据库 等单独的存储的地方，让应用连接同一套数据库/redis。
这些应用必须能满足 分布式一致性。
日志好做，机器配置够的话直接上一套 ELK。
文件存储走同一套支持 S3 的 OSS。
明白，
关于这一块”简单的业务加个分布式锁，在业务上做重试补偿之类的逻辑“，我理解是在多副本情况下，如果重复执行了通过这种方式来处理是吗？
好的，感谢佬提供的方案！
不过上ELK是不是会太重了。。其他的方案我也想了解一下嘿嘿
轻量级的那就是 Loki 了，但是还是得搭配 Grafana
重复执行只是多副本会出现其中一个问题，可以通过分布式锁和业务唯一id来做限制，如果确实无法避免重复的情况，那么就只能通过数据回滚补偿之类的操作，举个例子就是扣库存，已经做了各种手段避免扣多，但还是可能因为bug之类情况导致多扣，那么就需要有事务回滚的逻辑，不同技术栈有不同的方案，也可以手动实现事务回滚。
不是多副本就要分布式，分布式和这没关系。你的状态无非就是用户信息，如果你现在的应用是一个单体应用，那就更简单了。
第一步：使用 jwt 把登录做成 token 方式授权，实现应用之间的状态分离。
第二步：为不通应用创建 Dockerfile，构建不同的镜像。
第三步：通过 k8s，部署镜像。
一个最基本的无状态应用就部署完了。
如果想继续扩展文件存储，直接再部署一个OSS 应用镜像就行了，付费的或者免费的MINIO都行。
本地日志也不需要上来就 ELK 组合，拿若依的照猫画虎，本地记录就行了。
如果后续，需要启动多应用负载，K8S配置一下就全实现了，就连同一应用的多个镜像日志收集都原生支持,简直不能再爽。
如果业务变得非常复杂了，需要拆更多的服务，还面临上亿的数据，就可以考虑分布式扩展了，在项目基础上增加一个分布式锁就行了，现在都有分布式的轮子，拿来即用，比如org.redisson库，都不需要自己开发什么复杂代码，你写的肯定不如人家大佬封装的完美。
如果没有大公司的实操环境长经验，就多用 AI 了解一些架构相关的基础知识，对于掌控项目很关键，很多架构技术是可以按照业务需求，随意组合的，不是一整套非得用
老哥说得挺好
好的谢谢回复！
好的，谢谢回复！
好的，感谢回复！
此话题已在最后回复的 30 天后被自动关闭。不再允许新回复。