【C++项目】手撕JRpc框架（单机怎么优化到分布式思想）

从单机小作坊到分布式大集团

第一阶段：原始小作坊

核心逻辑：你喊我干，干完告诉你

一开始，系统非常的简单，只有两个人：客户端和服务端

bash 复制代码

[ 客户端 Client ]  =====( 发送请求，比如：帮我算1+1 )=====>  [ 服务端 Server ]
       ^                                                             |
       |                                                             |
       +=================( 返回结果，比如：结果是2 )==================+

缺点：

单点故障：服务器一旦挂了，客户端就彻底找不到人干活了
压力太大：如果有一万个客户端同时找这个服务端，服务端会累死（负载过高）

第二阶段：引入"中介"的分布式大集团

核心逻辑：干活的人多了，需要一个"**登记处"**来协调

为了解决这个小作坊的问题，我们引入了注册中心。服务端不再是一个，而是很多个（形成一个集群）

bash 复制代码

                      [ 注册中心 Registry ]
                      (像是一个通讯录/黄页)
                             ^         ^
            (1. 我来注册服务)  |         |  (2. 我要找服务)
                             |         |
                             |         |
[ 客户端 Client ] -----------+         +----------- [ 服务端集群 ]
       |                                           ├─ [ 服务端 1 (算加法) ]
       |                                           ├─ [ 服务端 2 (算加法) ]
       |                                           └─ [ 服务端 3 (做翻译) ]
       |                                                        ^
       +====(3. 客户端拿到地址后，直接找某个服务端干活，拿到结果)====+

升级点：

服务注册：服务端启动时，跑去注册中心说："我是算加法的，我的地址是IP1"
服务发现：客户端要算加法，先去注册中心问："谁会加法"，注册中心把IP1、IP2给它
负载均衡：客户端看到IP1，IP2，随便挑一个（或者轮流），这样压力就分摊了
容灾：如果注册中心也挂了怎么办？可以让服务端自己兼任"备用注册中心"，形成分布式架构

第三阶段：扩展新业务 ------ "群发广播"

核心逻辑：除了"你问我答 "，还要实现"一人喊话，万人听到"

这就是消息的发布订阅功能。它不是一对一，而是多对多

bash 复制代码

[ 发布者 Publisher ] ===( 发布一条消息：今天放假！ )===> [ Broker (消息中转站) ]
                                                              |
                                                              | (根据主题分发)
                                                              |
+-------------------------------------+-------------------------------------+
                        |                                     |                                     |
                        v                                     v                                     v
                 [ 订阅者 A ]                             [ 订阅者 B ]                             [ 订阅者 C ]
                 (收到：今天放假！)                       (收到：今天放假！)                       (收到：今天放假！)

升级点：

引入了Broker（消息中间件）作为中转站
引入了Topic（主题）的概念，比如订阅了"体育新闻"主题的人，就只会收到体育新闻，不会收到"娱乐新闻"
意义：把发消息的人和接收消息的人解耦了，发布者不需要知道谁在听，只要把消息扔给Broker就行

第四阶段：终极形态 ------ 全能分布式架构

核心逻辑：把 "RPC干活 " 和 "发布订阅的"整合到一个系统

bash 复制代码

=============================== 客户端侧 (Client Side) ===============================
[ RpcClient ]  [ RpcClient ]  [ RpcClient ]    [ 发布者客户端 ]       [ 订阅者客户端 ]
       \             |             /                  |                     |
        \            |            /                   |                     |
         v           v           v                    v                     v
    [ MprpcChannel (通信通道) ]              [ 消息队列客户端 (处理Topic) ]
         |                                                |
         |                                                |
=========|================================================|==========================
         |                                                |
         v                                                v
[ 注册中心 (Registry集群) ] <---(注册/发现)---> [ Broker (消息中转站) ]
(可能由Server兼任备用)                             (包含 Topic 和 Queue)
         ^                                                ^
         |                                                |
         | (获取到服务地址后，直接发起RPC调用)               | (消息转发)
         |                                                |
[ RpcServer 1 ] <---(提供具体服务)--- [ RpcServer 2 ] <---(提供具体服务)--- [ RpcServer 3 ]
包含方法：                                 包含方法：                                 包含方法：
- Add(int, int)                           - Add(int, int)                           - Translate(char*)

总结：

PRC远程调用（主干）：客户端 -> 注册中心找地址 -> 直接连服务端 -> 服务端执行方法 -> 返回结果
服务注册与发现（神经系统）：服务端上线/下线 -> 通知注册中心；客户端调用前 -> 询问注册中心。保证系统知道谁活着、谁在干活
发布订阅（广播系统）：发布者 -> Broker -> 根据 Topic 分发给订阅者。实现异步通信和多对多通信