彩虹马的博客

引言给大模型应用增加一个统一入口，看起来只需要代理几个接口。但当模型数量、Agent数量和调用成本上来以后，问题会逐渐变成：简单问题能不能用便宜的模型？复杂任务什么时候升级？同一个会话是否应该一直使用同一个模型？这些判断应该由业务、网关还是模型服务负责？ 围绕这些问题，对vLLM Semantic Router和Higress做了一次梳理。两者都有路由能力，但关注的层次不同：一个侧重理解请求并选择模型，一个侧重统一接入和流量治理。职责不先讲清楚，两个组件叠在一起，只会多出一套规则和一个排障入口。 先把三个问题拆开请求难不难、应该用哪个模型、最终请求发到哪个节点，是三个不同的问题。 层次 需要回答的问题 输出示例 请求判断 任务属于什么领域？推理要求高不高？上下文是否复杂？ 领域标签、复杂度信号、难度分数 模型决策 在成本、质量、约束和会话状态下选谁？ 某个模型或模型能力路径 流量执行 这个模型的哪个实例能接收请求？ 某个可用后端节点 比如“查询一个Java方法的用法”和“分析一个跨服务事务的一致性方案”，都可能归到编程领域，但适合的模型不一定相同。反过来，同一个 ...

引言大模型应用从“回答问题”走向“完成任务”后，需要查询业务数据、调用内部 API、检索知识库或执行操作。若每个 Agent 都单独适配一种后端，连接方式、工具描述、参数格式和权限控制很快会变得重复而难以维护。 Model Context Protocol（MCP）为模型应用与外部能力之间提供一套通用协议。AgentScope 则在 Agent 运行时中管理工具、MCP 客户端和工具组。理解两者的边界，才能回答工具如何发现、如何暴露给模型、同类工具如何区分，以及升级如何控制风险。本文按 MCP 基础、Tool 设计和 AgentScope 接入逐步展开。 MCP 是什么MCP 是连接 AI 应用与外部数据源、工具服务的一种开放协议。它约定 Client 与 Server 如何初始化、协商能力、交换请求和返回结果，让应用可以用相对一致的方式连接不同能力提供方。MCP 本身不是大模型，也不负责替业务系统实现权限、事务或模型决策。 一个常见部署由三类角色组成： 角色 职责 Host 承载 Agent 和用户交互的应用，例如 IDE、桌面助手或业务 Agent 服务 Clien ...

引言在 Spring Boot 项目里，Controller、Service、Mapper 是熟悉的组合。随着业务规则变多，Service 可能同时承担流程编排、状态校验、数据转换和消息发布等职责，修改一个用例也会牵动多个功能。此时常见的问题是：要不要从 MVC 改成 DDD？@Transactional 应该放在哪层？ 这几个概念解决的不是同一类问题：MVC组织请求入口，DDD帮助团队理解和表达业务，COLA则把面向对象、分层和工程结构落实为一种应用架构实践。理解分层不需要先套入某个业务用例，先看每层拥有什么职责、依赖朝向哪里即可。 MVC 与 DDD 关注点不同MVC用于组织表现层的输入、模型和输出。在 Spring Boot Web 应用中，Spring MVC负责处理HTTP请求、参数绑定和响应；Controller把请求交给应用层，是一种常见实现方式。 DDD（Domain-Driven Design，领域驱动设计）是一套围绕业务领域进行分析和建模的方法。它帮助团队统一业务语言、识别模型边界，并把重要规则放在明确的领域模型中。DDD不是一个Web框架，也不要求项目采用某种固定 ...

引言前面文章中介绍了很多架构相关理论，接下来说一说怎样才能画出一幅好看、好懂、好用的架构图。俗话说“一图胜千言”，一张好的结构图是不需要过多解释的，他应该是自描述的，并且要具备一致性、健壮性和足够的准确性，能够和代码相呼应。 架构图分类 产品/业务架构使用一套方法论/逻辑对产品（项目）所涉及到的业务进行边界划分，需要考虑各个模块的分层和边界。主要包括业务规划、业务模块和流程以及问题域的列表等。 模板可参考我的ProcessOn文件：产品蓝图、产品架构图 应用架构对整个系统实现的总体上的架构，需要指出系统的层次、系统各个层次的应用服务、组成关系、依赖关系。 体现了架构是分层的，不同层次有不同的规则与关联。 类似Java开发里面的三层架构，数据访问层、业务逻辑层、展现层。或者类似领域模型中的领域服务层、应用层、界面接口层分层方法。 模板可参考我的ProcessOn文件：应用架构图 存储/数据架构是一套对存储数据的架构逻辑，根据各个系统应用场景、不同时间段的应用场景 ，对数据进行诸如数据异构、读写分离、缓存使用、分布式数据策略等划分。 技术架构离程序员最近的架构设计，突出技 ...

引言在众多分布式ID中，雪花算法是比较简单且常用的算法，分布式ID一般具有的特性有： 唯一性：生成的ID全局唯一，在特定范围内冲突极小。 有序性：生成的ID全局或按规则有序，便于数据库插入及排序。 可用性：可保证高并发下的可用性，确保任何时候都能正确的生成ID。 自主性：分布式情况下不依赖中心认证即可自行生成ID。 安全性：不暴露系统和业务的信息，如：订单数、用户数…. 常见的分布式ID生成方式比较 比较点 SnowFlake Leaf UidGenerator Redis 依赖数据库 否 是 可选 是 支持分布式 是 是 是 是 可预测 - - - - 依赖性 毫秒级时间戳 + 标识 位 + 序列号 时间戳 + node + pid + 序列号 秒级时间戳 + workId + 序列 Redis单线程自增 维护中 多个变种 是 否 - 雪花算法SnowFlake是Twitter开源的分布式ID生成算法，生成的一个64bit的long类型数值，组成部分使用了时间戳，保证了粗略自增。 优缺点优点 高性能高可用：完全在内存中生成，不依赖数据库。 高吞吐：每 ...

高可用三大核心原理CAP 分布式数据存储系统不可能同时满足一致性、可用性和分区容忍性。 一致性 Consistency 可用性 Availability 分区容忍性 Partion Tolerance BASE 核心思想是即使无法做到强一致性（CAP 的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性。 基本可用 Basically Available 软状态 Soft State 最终一致性 Eventually Consistency FLP 异步通信场景中，即使只允许一个节点失败，也没有任何确定性算法能够保证非失败进程达到一致性。 Safety Fault Tolerance Liveness FEMA具体含义 Failure：假设系统某些组件或者模块出现故障。 Mode： 故障发生的方式、可能性。 Effect ：故障的影响。 Analysis：分析系统的可能反应，以及如何改进。 评估维度 大纲 业务及灾备架构常用架构 同城双中心。 跨域紧邻双中心。 跨域远端双中心。 跨国数据中心。 异地多活架构模式业务定制型按照业务的优先级进 ...

微服务架构详解微服务VS SOA 微服务架构陷阱与挑战六大陷阱拆分颗粒度太细 服务关系复杂 团队效率下降 问题定位困难 系统性能下降 基础设施不完善 无法快速交付 服务管理混乱 四大挑战 分布式事务 全局幂等 接口兼容 接口循环调用 微服务基础设施选型 核心为服务运行层：服务注册、服务发现、服务路由 嵌入SDK式 反向代理式 网络代理式 微服务拆分技巧按业务拆分 业务边界划分 三个火枪手原则 【定义】 平均3个开发人员负责一个微服务。 【剖析】 为什么不是1个？ 因为没有备份，且一个人思维有局限。 为什么不是2个？ 因为异常情况下剩余1个，压力会很大； 2个人负责维护一个微服务，微服务复杂度偏低。 为什么不是4个或者5个？ 如果4个或4个以上，每个人不一定能掌握单个服务所有细节。 【技巧】 微服务数量 = 服务端开发人数 /3 ； 3 = 1 +2，1个有经验的(P7/P6+)，2个普通的(P5/P6)； 处于维护期的服务，维护人员为2人。 按质量拆分 按性能拆分 按业务重要程度拆分 按可用性拆分 按稳定性拆分 ...

多级缓存架构缓存设计 缓存内容 缓存时间 缓存系统 更新机制 多级缓存 客户端缓存 CDN缓存 WEB容器缓存 应用缓存 分布式缓存 分布式缓存架构设计分类 数据缓存：实时性要求高，读多写少 结果缓存：计算量大实时性要求不高 缓存问题 缓存穿透 缓存雪崩 缓存热点 负载均衡架构 DNS F5：100万~1000万 LVS：10万~100万 Nginx：5万~10万 服务路由(Gateway)：1000~5000 负载均衡技巧通用算法 轮训 随机 加权轮训 负载有限 性能优先 hash 服务器性能估算接口性能 线上业务服务器接口处理时间分布为 20~100ms； 平均大约为 50ms； 访问存储或者其它系统接口是主要的性能消耗点。 服务器性能线上单个服务器（32核）性能大约为 300~1000 TPS/QPS 服务器数量服务器数量 = (总 TPS+QPS) / 单个服务器性能 接口高可用 限流 排队 降级 熔断