首页 文章 精选 留言 我的

精选列表

搜索[向量检索],共10000篇文章
优秀的个人博客,低调大师

实现企业级 MCP 服务统一管理和智能检索的实践

作者:孤弋、正己 在 AI 大模型应用爆发的今天,Model Context Protocol (MCP) 作为连接 AI 大模型与应用的关键协议,正在快速普及。然而,如何在企业级环境中高效部署和管理 MCP 服务,成为技术团队面临的重要挑战。本文将深入剖析 MCP Server 的五种主流架构模式,并结合 Nacos 服务治理框架,为企业级 MCP 部署提供实用指南。 MCP 架构的演进与挑战 MCP 协议为 AI 应用提供了标准化的交互方式,但在企业级落地过程中,我们面临着认证鉴权受限、部署模式多样、技术债务风险等多重挑战。目前,MCP Server 主要有五种架构模式,每种架构各有优劣,适用于不同的业务场景。 五种 MCP 架构模式详解 架构一:MCP Client 直连 Remote Server (SSE) 这种架构就像你直接打电话给专家咨询问题 ------ MCP Client 通过 SSE 方式直接连接到远程 MCP Server,全程保持 HTTP 长连接。 优点? 超简单!没有中间层,部署维护成本低 实时性好,模型的流式输出体验一流 集中化管理,监控和运维不费劲 缺点? 网络一卡,体验就崩了 所有数据都得传到云端,敏感信息有顾虑 安全风险较高,服务端点直接暴露 适合谁?如果你是做 SaaS 应用、轻量级客户端或公共云服务,对安全要求不那么高,这种架构就挺合适的。 架构二:MCP Client 通过 Proxy 连接 Remote Server (SSE) 这种架构就像有个翻译在中间帮你沟通 ------ MCP Client 先连接到 Proxy Server,再由 Proxy 转接到 Remote Server。 优点? 安全性更高,代理层可以做各种防护 支持智能路由和负载均衡,流量调度更灵活 可以聚合多个后端服务,一个接口通吃 缺点? 架构复杂了,维护成本自然上升 多一层代理可能增加延迟,体验稍差 代理层可能成为新的故障点 适合谁? 多租户环境、企业网关集成、需要调用多种模型的场景,这种架构就很给力。 架构三:MCP Client 直连 Local Server (STDIO) 这种架构就像你家里有个私人助理 ------ MCP Client 通过 STDIO 方式直接连接本地 MCP Server,进程间直接通信。 优点? 数据安全性拉满!敏感数据可通过 Local Server 加密授权再出本地 几乎零网络延迟,响应速度飞快 完全离线环境也能用,不依赖外网 缺点? 本地计算资源得够强,不然 Server 太多可能造成负载太大 每个环境都要单独部署维护,运维成本高 Server 服务更新很麻烦,得一个个环境去更新 适合谁? 金融核心系统、医疗数据分析、工业现场系统等对数据安全和隐私有高要求的场景。 架构四:MCP Client 通过 Local Proxy 连接 Local Server (STDIO) 这种架构就像你有个私人秘书帮你协调多个本地专家 ------ MCP Client 先连接到 Local Proxy,再由 Proxy 连接到 Local Server。 优点? 服务抽象做得好,客户端不用关心实现细节 支持本地多实例部署,自动故障转移 可以实现不同业务线或部门的资源隔离 缺点? 本地环境更复杂了,维护难度加大 本地代理需要额外的计算资源 多层架构让问题定位和调试变得更困难 适合谁? 大型企业内部平台、高可用要求场景、需要统一管理本地 AI 资源的场景。 架构五:MCP Client 通过 Local Proxy 连接 Remote Server (STDIO+SSE) 这种架构就像你有个超级助手,既能处理本地事务又能帮你对接外部专家 ------ MCP Client 通过 STDIO 连接 Local Proxy,Local Proxy 再通过 SSE 连接 Remote Server。 优点? 混合云战略的最佳选择,本地云端资源随意切换 企业从本地向云端迁移的平滑过渡方案 客户端体验一致,不用关心服务在哪里 缺点? 架构最复杂,维护和排障难度最大 需要确保本地和云端服务的一致性 性能受网络状况影响,可能有波动 适合谁? 实施混合云战略的大型企业、需要弹性扩展的业务、多区域部署的全球企业。 Nacos 如何赋能 MCP 架构 在企业级 MCP 部署中,MCP Server 的自动发现与选择及其 Server 的动态安装能力比较高效的解决了各个架构中遇到的场景。在 Nacos 3.0 之前的版本,主要围绕着分布式应用的服务注册发现以及配置管理,提供了三大核心能力: 服务发现与注册:支持服务的自动注册和发现,实现服务的动态扩缩容 配置管理:支持配置的动态更新和推送,无需重启应用 服务治理:提供服务路由、负载均衡、流量控制等治理能力 这些能力与 MCP 架构的需求高度契合,特别是在多 MCP 服务器的场景下。Nacos 3.0 发布后,正式提供了面向 MCP 的服务发现与注册、动态配置能力。功能架构图如下。 Nacos MCP Router:连接 MCP 与 Nacos 的桥梁 Nacos MCP Router (https://github.com/nacos-group/nacos-mcp-router) 是一个基于 MCP 协议的服务器,它与 Nacos 深度集成,提供了三个核心功能: MCP 服务器搜索:根据任务描述和关键词搜索合适的 MCP 服务器,重点解决 MCP 工具过多时解决大模型选择工具的效率的问题。 MCP 服务器添加:支持添加 stdio 和 SSE 两种协议的 MCP 服务器,配合 Nacos Server 的管理能力,重点解决软件供应链安全的问题。 工具代理调用:代理 LLM 对目标 MCP 服务器工具的调用,通过一个本地代理的方式解决 Local Server 与 Remote Server 调用的灵活切换问题。 通过以上的几个能力,我们搭建了一种混合 MCP Server 架构的模式,可以实现 MCP 服务的统一管理和智能路由,大大简化提升工具选择时的性能与企业级 MCP 部署的复杂度。 Nacos 与 MCP 的实战集成 下面通过一个实际案例,展示如何使用 Nacos 和 Nacos MCP Router 构建企业级 MCP 服务。 部署 Nacos MCP Router 在有 NodeJS 的开发环境中,我们可以通过以下命令手动部署 Nacos MCP Router(不过这一步不是必须的) $ pnpm i nacos-mcp-router@latest 配置 MCP 客户端 然后,在 MCP 客户端配置中添加 nacos-mcp-router: { "mcpServers": { "nacos-mcp-router": { "command": "npx", "args": [ "nacos-mcp-router@latest" ], "env": { "NACOS_ADDR": "127.0.0.1:8848", "NACOS_USERNAME": "nacos", "NACOS_PASSWORD": "your_password" } } } } 使用MCP服务 现在,我们可以通过 nacos-mcp-router 使用各种 MCP 服务(注:以下步骤为 MCP Client 与 Nacos Router 自动交互时的核心方法,并不是程序员在开发过程中需要硬编码的实现): 搜索 MCP 服务器: search_mcp_server(task_description="生成一张猫的图片", key_words="图像生成") 添加 MCP 服务器: add_mcp_server(mcp_server_name="image-generator") 使用 MCP 服务器工具: use_tool(mcp_server_name="image-generator", mcp_tool_name="generate_image", params={"prompt": "一只橙色的猫"}) 企业中落地 MCP 架构选型指南 MCP 社区还在飞速的发展之中,在企业级场景的能力上的诸多核心功能还暂时未形成统一的标准,基于目前的能力,我们在选择适合企业的 MCP 架构进行落地时,我们需要考虑以下关键因素: 数据安全与隐私 高敏感数据:优先考虑本地部署架构(架构三、架构四) 一般业务数据:可考虑云端或混合架构(架构一、架构二、架构五) 性能与延迟要求 低延迟关键应用:优先考虑本地部署架构 一般性能要求:云端架构通常足够 可扩展性需求 需要快速弹性扩展:优先考虑云端架构 可预测的稳定负载:本地部署可能更经济 基于这些因素,不同行业可能的选择可能的参考如下: 金融行业:架构四(本地代理+本地服务器)最为适合,满足严格的数据安全要求 互联网行业:架构二(代理+远程服务器)支持快速弹性扩展,适合高并发场景 制造业:架构五(混合模式)平衡了本地实时控制和云端智能分析的需求 政府部门:架构三(直连本地服务器)提供最高级别的数据安全和隐私保护 结论与展望 MCP 目前默认成为了 AI 大模型与存量业务数据互通的管道,但由于目前的 MCP 协议本身从设计上未太多考虑企业级落地的情况,导致很多的企业还处在观望的状态。MCP 要想完整落地,中心化的注册中心、可控的软件供应链、安全的访问控制这三方面的建设必不可少。在我们的方案中,主要通过 Nacos 作为 MCP 的未来企业 MCP 的注册中心,通过 Nacos Server 对 MCP 服务器的管理能力,结合 Nacos Router 做到软件供应链的精准控制;同时配合 Higress 做到 MCP 的安全访问,以此给我们的企业级客户带来 MCP 完整的解决方案。 特别致谢 Lingma-Agents (https://github.com/apps/lingma-agents) 在 Nacos Router 实现的过程中提供自动化的 Code Review 能力。 阿里云 MSE Nacos(Nacos 商业版)已发布铂金版,支持 Nacos 2.0 向 3.0 的平滑迁移,提供面向 MCP 场景的服务发现与注册、动态配置能力,相比开源版本,更易用、更稳定、更安全。

优秀的个人博客,低调大师

每日一博 | 京东 APP 百亿级商品与车关系数据检索实践

导读 本文主要讲解了京东百亿级商品车型适配数据存储结构设计以及怎样实现适配接口的高性能查询。通过京东百亿级数据缓存架构设计实践案例,简单剖析了jimdb的位图(bitmap)函数和lua脚本应用在高性能场景。希望通过本文,读者可以对缓存的内部结构知识有一定了解,并且能够以最小的内存使用代价将位图(bitmap)灵活应用到各个高性能实际场景。 1.背景 整个汽车行业行特殊性,对于零配件有一个很强的对口特性,不同车使用的零配件(例如:轮胎、机油、三滤、雨刮、火花塞等)规格型号不一样。在售卖汽车零配件的时候,不能像3C家电、服饰,需要结合用户具体车辆信息,推荐适合的配件商品。基于此原因,京东自建人车档案模型并且利用算法清洗出百亿级的车型-零配件的适配关系数据,最终形成“人->车-〉货”关系链路,解决“人不识货”的问题。 具体使用场景如下图: . 图1.1京东商详推荐商品 图1.2京东加购弹窗推荐商品 2.数据模型 “人-> 车->货”关系的核心链路是由人(京东用户)、乘用车和SKU这三部分组成。 首先,用户在京东APP的商搜页、商详页多个位置都可以选择自己的车型信息进行绑定(例如:图2.1,京东商详绑车入口位置“+添加爱车”按钮),建立“人车档案”数据。 . 图2.1.京东商详绑车入口位置 图2.2.京东商搜绑车入口位置 其次,运营在后台管理系统中将商品与车型进行绑定,建立“商品与车型关系”数据(商品与车型的关系数据量级在百亿级别)。 最终,购买商品的时候,京东推荐系统可以通过用户自己绑定的车型推荐出适合该车型的商品。具体商品适配车型数据模型,见图2.3。  图2.3京东商品适配车型数据模型 3.缓存结构设计 基于前面两个部分的介绍,我们可以了解到整个商品搜索适配推荐存在两个最核心问题。第一、百亿级商品适配车型数据的存储结构设计,尽可能的占用资源成本最小;第二、商详通过用户车型来搜索适配商品时,必须保证接口性能的TP99位于毫秒级。最终技术选型的时候,采用了jimdb的位图(bitmap)函数来进行数据存储。 3.1位图(bitmap)结构 位图(bitmap)是通过最小的单位bit来进行0或者1的设置,表示某个元素对应的值或者状态。一个bit的值是0或者1;也就是说一个bit能存储的最多信息是2。 • 位(bit):计算机内部数据存储的最小单位,例如:11001100是一个八位二进制数。 • 字节(byte):计算机中数据处理的基本单位,习惯上用大写B来表示,1B(byte,字节)=8bit。  图3.1位图(bitmap)内部结构 3.2位图(bitmap)数据写流程 位图(bitmap)是基于jimdb的SDS(简单动态字符串)类型的一系列位操作,遵循jimdb的SDS特性,例如:位图(bitmap)最大长度512M,最大可以存储232位。以下是“big”字符串的SDS结构示例: 图3.2.1“big”字符串的SDS结构 SDS(简单动态字符串)为了保证性能采用了空间预分配的策略:空间预分配用于优化SDS的字符串增长操作。SDS的API对一个SDS进行修改并且需要对SDS进行空间扩展的时候,程序不仅会为SDS分配修改所必须要的空间,还会为SDS分配额外的未使用空。具体预分配流程图如下:  图3.2.2SDS预分配流程图 位置1:创建SDS简单字符串预分配空间为:偏移量/8+1。 位置2:剩余空间不足时,预分配空间流程。 3.3压缩商品与车关系缓存 偏移量(自增ID) 全量车型 商品SKU 1 1165788 101362 2 1165793 101362 商品适配车型关系(百亿级数据量) 商品与车关系缓存存储过程中,采用了商品SKU作为KEY,全量车型ID的偏移量(采用偏移量是为降低内存消耗)作为VALUE值来进行存储。 全量车型ID大约有几十万的数据量,极限情况下一个商品SKU可以适配几十万辆车,很容易造成缓存大KEY的问题,为此我们进行了偏移量(全量车型ID对应的自增ID)的分段处理。具体是按照:SKU作为缓存KEY的基础上,追加一个分段标记数字作为新KEY,每个偏移量都会按照分段范围对应一个分段标记数字。例如:偏移量1~50000,对应缓存KEY为SKU+0;偏移量50001~100000,对应缓存KEY为SKU+1,其它偏移量以此类推,这样就保证了一个SKU即使适配所有车辆也不会出现缓存大KEY的情况。 BitMap缓存结构底层使用SDS简单字符串,为了保证性能采用了预分配空间的策略(图3.2.2,“缓存BitMap内部存储流程图”的“位置2”中虚线框圈选),这样在缓存商品与车关系的时候浪费了大量的缓存空间。为此我们调整了偏移量存储顺序,首先获取到需要缓存的车型内最大的偏移量,保证同一个缓存KEY第1次创建SDS简单字符串(图3.2.2,“缓存BitMap内部存储流程图”的“位置1”中虚线框圈选)后,不再进行第2次空间扩容,这样来最大限度的提升缓存利用率,起到压缩空间目的。缓存数据关系流程如下: 图3.3.1缓存数据关系流程 位置3:设置分段最大的偏移量,保证后续新增偏移量不再扩容空间。 位置4:设置分段较小的偏移量。 全量车型ID是定长7位的数字,如果用它作为偏移量将消耗内存巨大,所以采用对应自增ID作为偏移量。最终在bitmap缓存的商品SKU与车的适配关系缓存结构如下图: 3.3.2商品与车缓存结构图 位置5:spuId用{}括起来表示缓存路由(Lua脚本中同一次请求,数据必须在缓存同一个分片上,否则会丢失数据)。POP商品spuId是SKU的产品ID,自营商品spuId是SKU的MainSkuId。 备注: 1、自营商品MainSkuId可能发生变化,所以我们接入了商品变化MQ消息,实时调整SKU与车适配关系的存储位置。 2、京东商详页面中每个不同的规格/型号分别对应不同的SKU,但是它们都对应同一个SpuId或者MainSkuId。 4.缓存架构设计 商品与车的关系数据量每天都在不断增长,要求缓存架构设计,需要支持集群横向/纵向扩容和来满足业务发展以及高可用性。整个缓存架构体系主要有前端、京东养车商品与车关系层和存储三部分组成。 “商品与车关系缓存架构”层核心包括:1、“集群路由”层,实现了集群横向扩容,保证数据量增涨的时候,缓存容量也能跟上。2、“分片路由”层,保证搜索的底层数据的分片相同,避免数据丢失。 “存储”层核心包括:1、实现了缓存压缩,参见3.3压缩商品与车关系缓存。2、单元化实现跨区域灾备,保障大促系统稳定性。具体商品与车关系缓存架构如下: 4.1商品与车关系缓存架构图 位置6:集群路由,通过商品类型或者商品编号(POP商品)路由到不同缓存集群,便于横向扩展,每个集群单分片限制,解决分片超过限制问题。 位置7:分片路由,保障Lua脚本搜索数据的底层数据集群分片相同,避免数据丢失。其中自营商品和POP商品的路由分别是main_sku_id和product_id。 位置8:自营商品缓存集群,单元化实现跨区域灾备,采用自研DRC(Data Replication Center)数据同步机制。 位置9:POP商品缓存集群,通过商家编号拆分为两个子集群。 5.高性能搜索 基于BitMap(位图)缓存的商品与车关系数据,商详调用接口的内部实现采用了Lua脚本来降低网络开销,保障整个接口的性能。以下是搜索接口的流程图: 5.1商详搜索商品与车适配关系流程图 位置10:商详调用接口的时候,要传两个参数。第1个参数是全量车型ID列表,大约5个全量车型ID。第2个参数是商品SKU列表,SKU的数量极限超过200个。最后全量车型ID与商品SKU组合为上千个商品与车的关系后,再到百亿级适配关系去搜索看是否匹配的。如果不匹配返回适配商品,反之则返回不适配。 Lua脚本减少了应用服务器与缓存服务器的交互,降低了网络开销的时间,达到提升搜索服务的性能。以下是Lua脚本具体代码:  5.2商详搜索商品与车适配关系Lua代码 基于以上缓存设计和Lua脚本的使用,整个接口T999小于13ms。具体的接口性能监控如下图: 5.3商详搜索商品与车适配关系接口性能 6.总结 整个缓存结构设计的时候,使用BitMap(位图)来存储数据。解析SDS的内部存储流程,通过存储流程机制避开预分配空间节点,最大限度的利用缓存空间,避免资源浪费。采用Lua脚本来实现数据的适配搜索,降低网络开销,进一步提升接口的性能。希望此文对大家后续设计类似场景有一定的帮助和启发。 作者:京东零售 张强 内容来源:京东云开发者社区

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册