TaskForce：我做的一个多 Agent 协作平台项目地址：https://github.com/codejaron/TaskForce
为什么做这个项目AI 交互范式的演进
回顾 AI 应用的发展，可以看到一条清晰的演进路径：
最早是网页聊天——ChatGPT 横空出世。但它只能动嘴，无法感知和改变外部世界。
然后有了 Function Calling——2023 年 OpenAI 让模型学会了调用工具，AI 开始能「动手」了。查天气、操作数据库、发邮件。
接着是 MCP 协议——2024 年底 Anthropic 推出 Model Context Protocol，让工具集成有了开放标准。不同平台可以共享同一套工具生态，AI 开始能跨服务协作。
再到 Agent 的爆发——Manus 让大家看到了 AI 自主规划执行任务的可能性，不再是一问一答，而是「给一个目标，AI 自己想办法完成」。紧接着 Microsoft 推出 AutoGen 多 Agent 框架，Google 发布 A2A（Agent-to-Agent）协议，行业开始认真思考 Agent 之间如何协作。
到了现在，C ...
三种策略1. 旁路缓存 (Cache-Aside)
工作方式：应用程序代码既要操作缓存，也要操作数据库。缓存只是一个在“旁边”的辅助工具。
读：应用先读缓存，没有就自己读数据库，再写回缓存。
写：应用直接更新数据库，再删除缓存。
使用场景:
这是最通用、最灵活、最常用的模式，适用于绝大多数互联网应用。
当你使用 Redis、Memcached 这类通用缓存中间件时，基本都是采用这种模式。
适用于读多写少，并且可以接受最终一致性的系统。
2. 读写穿透 (Read/Write-Through)
工作方式：应用程序代码只和缓存打交道，把缓存当作唯一的数据源。缓存服务自身负责与数据库的同步。
读：应用只管读缓存，缓存没有时会自己去数据库加载。
写：应用只管写缓存，缓存会立刻、同步地将数据写入数据库。
使用场景:
对数据一致性要求极高的场景，比如金融领域的账户余额、电商的库存管理等，绝对不能读到旧数据。
当你想简化应用程序逻辑，将数据持久化的复杂性封装在缓存层时。
缺点是写入性能会因为同步等待数据库而降低。
3. 写回 (Write-Back)
工作方式：应用程序 ...
1. 静态代理：基础但“僵化”的起点静态代理是最直观的实现方式，它要求我们为每一个需要被代理的业务类，都手动编写一个对应的代理类。
工作方式：代理类与业务类实现同一个接口，并在内部持有业务类实例的引用。这样，代理类就可以在调用实际业务方法前后，执行我们想要附加的操作。
代码示例
1234// 文件: UserService.javapublic interface UserService { void saveUser();}
1234567// 文件: UserServiceImpl.javapublic class UserServiceImpl implements UserService { @Override public void saveUser() { System.out.println("核心逻辑：保存用户。"); }}
123456789101112131415// 文件: UserServiceStaticProxy.javapublic ...
从 macOS 版本微信 3.0 升级到 4.0 之后，之前的双开策略实效了。
第一步创建微信的「分身」
1sudo cp -R /Applications/WeChat.app /Applications/WeChat2.app
第二步给 WeChat2.app 鉴权
1sudo /usr/libexec/PlistBuddy -c "Set :CFBundleIdentifier com.tencent.xinWeChat2" /Applications/WeChat2.app/Contents/Info.plist
第三步签名
1sudo codesign --force --deep --sign - /Applications/WeChat2.app
第四步运行第二个微信，创建方法体。
1nohup /Applications/WeChat2.app/Contents/MacOS/WeChat >/dev/null 2>&1 &
第五步登录第二个微信即可。
第二个微信能保留在 Dock 。
注：
copyright_au ...
微服务如何获取用户信息JWT 在微服务中的基本传递流程
客户端发送请求到网关：
用户通过登录接口获取 JWT。
登录成功后，客户端在后续请求中将 JWT 放入请求头中，通常格式如下：
1Authorization: Bearer <jwt-token>
网关验证 JWT 并转发请求：
网关解析 Authorization 头中的 JWT。
验证 JWT 是否有效（签名校验、过期时间校验等）。
如果 JWT 有效，将请求转发到相应的微服务，同时可以选择将 JWT 转发到目标微服务（一般会保留在请求头中）。
微服务验证 JWT：
微服务接收到网关的转发请求后，可以再次验证 JWT，确保请求的合法性。
根据 JWT 中的用户信息（如用户 ID、角色等）执行具体业务逻辑。
微服务之间的请求：
当一个微服务需要调用另一个微服务时，通常会将用户的 JWT 附加到新的请求头中，传递到下一个微服务，确保链路中的身份信息一致。
JWT 在网关到微服务的传递1. 客户端到网关
客户端行为：
客户端（如浏览器、移动应用、Postman 等）在登录成功 ...
Java架构
未读Gateway网关路由的作用网关（Gateway）是微服务架构中重要的一环，用于实现请求的统一入口。Spring Cloud Gateway 是基于 Spring WebFlux 构建的高效网关，支持动态路由、限流、过滤、熔断等功能。
网关路由的核心功能：
路由转发：根据请求路径、参数、Header 等规则将请求转发到对应的微服务。
负载均衡：与注册中心（如 Nacos、Eureka）集成，实现服务发现与负载均衡。
统一入口：对外暴露一个公共的 API 网关 URL，隐藏微服务内部细节。
增强功能：支持请求过滤、鉴权、限流、熔断等功能。
使用 Spring Cloud Gateway 实现简单路由以下是一个网关路由的完整使用示例。
场景描述
系统中有两个服务：
user-service：提供用户服务。
order-service：提供订单服务。
使用 Gateway 实现以下功能：
访问 /user/** 路径时转发到 user-service。
访问 /order/** 路径时转发到 order-service。
1. 准备工作1.1 引入依赖在 Gateway 网关服 ...
Java架构
未读OpenFeignOpenFeign 的作用OpenFeign 是 Spring Cloud 提供的一种声明式的 HTTP 客户端工具，用于简化微服务之间的调用。在微服务架构中，服务 A 调用服务 B 的 RESTful 接口是常见需求，传统做法是通过 RestTemplate 手动拼接 URL 并发送 HTTP 请求，而 OpenFeign 提供了更加优雅和简化的方式来实现这一点。
作用
简化服务调用：通过接口 + 注解的方式，将服务调用变得像调用本地方法一样简单。
负载均衡支持：内置支持与 Spring Cloud Ribbon 集成，自动实现服务调用的负载均衡。
统一调用方式：与 Spring Cloud 整合，支持 Eureka、Nacos 等注册中心的服务发现，无需手动指定服务地址。
可扩展性强：支持请求拦截器、日志记录、自定义配置等功能，方便对请求和响应进行增强。
使用步骤以下是 OpenFeign 的使用方法，通过一个简单的例子说明如何实现服务间调用。
场景描述
有两个服务：
user-service：提供用户信息查询的服务。
order-service： ...
NacosNacos 的作用和使用场景Nacos 是一款开源的服务注册中心和配置管理中心工具，主要用于微服务架构中的服务发现、服务配置和动态管理。它支持服务注册与发现（类似 Eureka）、配置管理（类似 Spring Cloud Config）以及动态 DNS 服务。
在微服务中，服务注册和配置管理是两个重要的部分，Nacos 提供了一站式解决方案。
Nacos 的核心功能
服务注册与发现：
微服务启动时，将自身注册到 Nacos 服务中心。
其他服务通过 Nacos 获取目标服务的地址（如 IP 和端口），实现服务间调用。
配置管理：
管理服务的配置文件，支持动态更新配置，而不需要重启服务。
举例：Nacos 的服务注册与发现以下是一个基于 Spring Cloud Alibaba 和 Nacos 的简单服务注册与发现示例。
场景描述
有两个微服务：
user-service：用户服务，提供获取用户信息的接口。
order-service：订单服务，需要调用 user-service。
通过 Nacos，user-service 注册到服务中心，order ...
微信扫码登录过程用户请求登陆，后端生成随机code，保存code和socket映射，拿code和微信平台申请二维码，用户扫描这个二维码，微信平台就会返回给后端openid+code，最后只需要保存openid和socket的关系
游标翻页深翻页问题普通翻页前端一般会有个分页条。能够指定一页的条数，以及任意选择查看第几页。
1select * from table limit 10000,10
其中10000代表需要跳过的条数，10代表跳过指定条数后，往后需要再取的条数。需要先查询10000条进行丢弃，再取那么个10条选用。这个效率太低了
游标翻页为了优化，我们可以加一个where条件
1select * from table where id>100 order by id limit 0,10
只要id这个字段有索引，就能直接定位到101这个字段，然后去10条记录。以后无论翻页到多大，通过索引直接定位到读取的位置，效率基本是一样的。这个id>100就是我们的游标，这就是游标翻页。
因为游标翻页每次都记住上次查询的最后位置，所以游标翻页不适合跳页，只能不断的往下翻。更适合 ...
注解实现分布式锁1、原始写法我们平常使用redisson的分布式锁是怎么做的？
是不是基本都用的这个模板，既然是模板，那为何不把他抽出来呢？
12345678910// 尝试加锁，最多等待100秒，上锁以后10秒自动解锁boolean res = lock.tryLock(100, 10, TimeUnit.SECONDS);if (res) { try { ...业务代码 } finally { lock.unlock(); }}
2、抽出分布式锁工具类我们可以抽出一个LockService方法，把锁的模板写在方法里，调用的时候只需要指定key，把锁内的代码块用supplier函数传进来
1234567891011121314151617181920@Service@Slf4jpublic class LockService { @Autowired private RedissonClient redissonClient; public <T> T ...
