“ MCP結合Spring MVC，到底有哪些神秘之處？函數(shù)式路由到底什么來頭？”

在 MCP 服務器與 Spring MVC 的深度整合過程中，隱藏著一場函數(shù)式路由與傳統(tǒng)注解式控制器的架構對決。

今天，我們來一探究竟，看 MCP 協(xié)議如何在 Spring MVC 中巧妙選擇函數(shù)式路由，實現(xiàn)高效通信與靈活擴展。

MCP 與 MVC 如何結合

三步走的緊密結合策略

1）路由注冊

WebMvcSseServerTransportProvider 借助 Spring WebMVC 的函數(shù)式編程模型（RouterFunction）定義 HTTP 端點，為 MCP 服務器與客戶端的通信搭建起初步的 "交通網(wǎng)絡"。

2）雙向通信機制搭建

一方面，利用 Server-Sent Events (SSE) 實現(xiàn)服務器到客戶端的推送；另一方面，通過 HTTP POST 接收客戶端到服務器的消息，從而構建起雙向通信的 "高速公路"。

3）與 Spring MVC 應用集成

通過巧妙地暴露 RouterFunction 實例，使開發(fā)者能夠輕松地將其注冊到 Spring 應用程序中，完成 MCP 服務器與 Spring MVC 應用的深度融合。

MCP 的通信模型解密

1）客戶端建立連接：開啟 "對話之門"

客戶端通過訪問 SSE 端點（默認為 /sse）建立持久連接，如同搭建起一條與服務器的專屬 "溝通橋梁"。

2）服務端推送消息：實現(xiàn) "信息反向流動"

服務端借助 SSE 連接推送 JSON-RPC 消息和通知，打破了傳統(tǒng) HTTP 協(xié)議客戶端請求、服務端響應的單一模式，讓服務端也能主動向客戶端發(fā)送信息。

3）客戶端發(fā)送消息：完成 "雙向互動"

客戶端通過 POST 請求到消息端點發(fā)送 JSON-RPC 消息，使雙方能夠真正實現(xiàn)高效、靈活的雙向通信。

4）會話管理：賦予 "連接以身份"

每個客戶端連接都有唯一的會話 ID，用于精準地標識和跟蹤連接，方便對不同的客戶端連接進行有效管理。

這種精心設計的通信模型，讓 MCP 協(xié)議在 Spring MVC 環(huán)境中得以高效、穩(wěn)定地運行，滿足復雜多變的業(yè)務需求。

函數(shù)式路由的核心價值

對外暴露的兩個統(tǒng)一接口

不管注冊了多少個不同的 Tool，也不論這些 Tool 名字如何，MCP 服務器對外暴露的 HTTP 接口始終是相同的：

• SSE 連接端點 ：通常是 /sse（默認值），用于建立服務器與客戶端的通信連接。
• 消息接收端點 ：在示例中是 /mcp/messages（可配置），用于接收客戶端發(fā)送的消息。

基于 JSON-RPC 理念的深度契合

這種設計完美遵循了 JSON-RPC 的理念，即通過單一的 HTTP 端點來接收所有的遠程調(diào)用請求，然后在服務端根據(jù)請求中的 method 字段進行分發(fā)，帶來諸多顯著優(yōu)勢：

• 簡化 API 管理 ：無需為每個工具或方法創(chuàng)建單獨的 HTTP 端點，降低了 API 管理的復雜度和工作量。
• 降低客戶端復雜性 ：客戶端只需記住兩個端點，減少了客戶端開發(fā)的負擔和出錯的可能性。
• 提高擴展性 ：在不改變 API 結構的情況下，能夠輕松添加新功能，為系統(tǒng)的持續(xù)發(fā)展提供了廣闊空間。

函數(shù)式路由 VS 傳統(tǒng)控制器

傳統(tǒng)注解式控制器：熟悉的老朋友

這是 Spring MVC 中廣泛使用的路由方式，適用于大多數(shù)常見的 Web 應用場景：

java

@RestController
@RequestMapping("/api/users")
public class UserController{

    @GetMapping("/{id}")
    public User getUser(@PathVariable Long id){
        // 處理邏輯
    }

    @PostMapping
    public User createUser(@RequestBody User user){
        // 處理邏輯
    }
}

圖片

其典型使用場景包括：

• 資源導向的 RESTful API 設計，完美契合 REST 架構風格，方便對資源進行統(tǒng)一管理與操作。
• 傳統(tǒng)的 Web 應用，滿足常規(guī)的網(wǎng)頁展示、表單提交等需求。
• 需要精細控制請求處理邏輯的場景，開發(fā)者可以憑借豐富的注解對請求處理過程進行細致入微的把控。

函數(shù)式路由：新時代的弄潮兒

MCP 中采用的就是這種 Spring 5 引入的更現(xiàn)代的函數(shù)式編程風格的路由機制：

java

@Bean
public RouterFunction<ServerResponse> routes(){
    return RouterFunctions.route()
            .GET("/api/users/{id}",this::getUser)
            .POST("/api/users",this::createUser)
            .build();
}

圖片

函數(shù)式路由主要適用于以下場景：

• 微服務場景 ：在微服務架構下，服務輕量化、獨立部署成為關鍵需求，函數(shù)式路由能夠很好地滿足這一要求，讓每個微服務的路由定義簡潔明了、靈活自如。
• 響應式編程 ：與 Reactor、WebFlux 等響應式框架無縫集成，助力實現(xiàn)高效、高性能的異步編程模式，應對高并發(fā)場景游刃有余。
• API 網(wǎng)關 ：動態(tài)路由配置是 API 網(wǎng)關的核心需求之一，函數(shù)式路由可以根據(jù)不同的請求條件快速、靈活地調(diào)整路由規(guī)則，實現(xiàn)精準的請求分發(fā)。
• 特殊協(xié)議支持 ：對于 WebSocket、SSE 等特殊協(xié)議的處理，函數(shù)式路由提供了更靈活、更強大的支持，能夠充分發(fā)揮這些協(xié)議的優(yōu)勢，拓展應用的功能邊界。
• 自定義請求處理流程 ：當開發(fā)者需要對請求處理管道進行精細控制，實現(xiàn)一些特殊的業(yè)務邏輯或性能優(yōu)化時，函數(shù)式路由給予了極大的自由度和靈活性。

總結

函數(shù)式路由（MCP）與傳統(tǒng) REST 控制器各具特色，適用于不同的應用場景和需求。

在實際的系統(tǒng)架構設計中，我們應根據(jù)具體的業(yè)務特點、技術要求和團隊的開發(fā)偏好，綜合權衡這兩種路由方式的優(yōu)缺點，選擇最合適的方式來構建高效、穩(wěn)定、可擴展的系統(tǒng)。