Dx's Tech Notes

Nacos

8 min read

Nacos Feign

1

这也是一个非常关键的问题，你现在正在接触分布式架构的核心概念——API 包与实现分离。 直接回答你：big-market-api 这个 JAR 包本身是“纯本地”的，它不包含联网代码，也不包含业务逻辑源码。它只是一份“菜单” (契约)。 但这并不意味着它没用，相反，它是连接“本地”和“远程”的桥梁。 我结合你的截图（IRaffleActivityService 和各种 DTO）来详细拆解它是如何工作的。

1. 这个包里到底有什么？

看你的截图，big-market-api 只有两类东西：

  1. DTO (Data Transfer Object)：比如 ActivityDrawRequestDTO。
    • 这只是简单的 Java 类，只有属性（id, name…）和 getter/setter。
    • 作用：规定了传参长什么样。
  2. Interface (接口)：比如 IRaffleActivityService。
    • 它只有方法定义（draw(Request request)），没有方法体（{ ... } 里的代码）。
    • 作用：规定了有哪些服务可以调。

结论：这个 JAR 包里全是空的定义。它既没有 HTTP 连接代码（不像 Xiaozhibang），也没有数据库操作代码。

2. 那它怎么用？（RPC 的魔法）

既然是空的，为什么还要把它打包并在 Maven 里引用它呢？这就回到了**RPC（远程过程调用）**的原理。通常这种架构（比如 Dubbo 或 Feign）是这样玩的：

角色 A：服务提供者 (厨师)

  • 位置：在 big-market-app 模块里。

  • 动作：它会引入这个 api 包，并实现这些接口。

    Java

    // 这里才是真正的源码，真正的业务逻辑！
public class RaffleActivityServiceImpl implements IRaffleActivityService {
    public Response draw(Request request) {
        // 查数据库、算概率、发奖品...
        // 真正的干活代码在这里
    }
}

  • 运行：这部分代码运行在服务器端。

角色 B：服务消费者 (食客/你)

  • 位置：在 big-market-trigger 或者其他的客户端应用里。

  • 动作：你也会引入这个 api 包。

  • 神奇的事情发生了：

    当你调用 IRaffleActivityService.draw() 时，你调用的其实是一个**“代理对象”**。 Maven 里的这个 JAR 包告诉你“有个 draw 方法”，RPC 框架（如 Dubbo/Feign） 会在运行时自动生成一段联网代码：

    “既然你调用了 draw 接口，那我就把你的参数打包，通过网络发给‘服务提供者’，等他算完把结果发回来。“

3. 对比总结：它和你之前的依赖有什么不同？

为了让你彻底看清，我们将 big-market-api 与之前的两个例子做对比：

依赖类型Hutool / PageHelperXiaozhibang SDKbig-market-api (当前项目)
本质本地工具 (锤子)远程客户端 (电话机)契约/菜单 (纸)
内容完整的逻辑源码连接代码 + Token处理只有接口定义 + DTO
联网吗?不联网代码里写死了要联网本身不联网 (靠RPC框架代理联网)
在哪里运行?你的电脑你的电脑(发) + 云端(收)接口在你电脑，实现类在服务器

4. 你的困惑解答

“是联网的还是直接下载的源码？”

  • 它是直接下载的源码（编译后的）：你通过 Maven 把这个 api JAR 包下载到了本地。
  • 但它不包含业务逻辑：你下载到的只是“壳”。
  • 真正的业务逻辑在服务器：当你调用这个接口时，虽然你手里拿的是本地的 JAR 包，但程序会自动通过网络去调用部署在服务器上的 big-market-app 里的代码。

一句话总结：

你手里的 big-market-api JAR 包就是一张**“餐厅菜单”。你把它下载到本地（拿在手里），是为了知道有什么菜（接口）可以点。但是当你真的点菜（调用方法）时，做菜的那个厨师（实现类源码）** 依然是在远程的厨房（服务器）里工作的。

2

完全正确！你现在的理解已经非常透彻了。 💯 所谓的“服务器”（Remote Kitchen），指的并不是某台特定的昂贵机器，而是一个**“角色”**。 只要装了 Java 环境，谁运行了那段“实现类代码”（Implementation），谁就是服务器。 我画一张图帮你彻底理清这两个场景的区别：

场景一：开发环境（现在）—— 你的 Mac 就是“服务器”

现在你在 IntelliJ IDEA 里点击绿色的“运行”按钮启动 BigMarketApplication 时：

  1. 厨师（服务端）：就是你的 Mac。
  2. 食客（客户端）：也是你的 Mac（或者是你写的单元测试）。
  3. 网络：请求并没有真的飞到天上去，而是在你的网卡里转了个圈（IP地址是 127.0.0.1 或者 localhost），从左手传到了右手。

这就是为什么你现在不用买云服务器也能写代码的原因。 你既是点菜的人，又是做菜的人。

场景二：生产环境（未来）—— 阿里云/腾讯云 就是“服务器”

当这个项目上线赚钱时：

  1. 打包：你会用 Maven 把代码打成一个 app.jar 包。
  2. 上传：把这个包传到阿里云的一台 Linux 机器上。
  3. 运行：在阿里云上输入 java -jar app.jar。
  4. 厨师（服务端）：现在是阿里云的 CPU 在跑代码。
  5. 食客（客户端）：是你手机上的 App 或者浏览器。

关键点：它们怎么知道“厨房”在哪？

你可能会问：“代码是同一份，它怎么知道该连我的 Mac 还是连阿里云？”

这就是我们刚才费了半天劲修好的 Nacos 的作用！

Nacos 就像一本动态电话簿：

  • 在你电脑上跑时：

    你的 BigMarketApplication 启动后，会告诉 Nacos：“我是做菜的，我现在住在 192.168.1.7 (你的Mac IP)”。

  • 在阿里云跑时：

    代码启动后，会告诉 Nacos：“我是做菜的，我现在住在 47.103.xx.xx (阿里云 IP)”。 调用者（API jar包） 根本不在乎服务器是谁，它只需要问 Nacos：“谁是做菜的？”，Nacos 给它哪个 IP，它就往哪里发请求。

总结

  • big-market-api (菜单)：人手一份，不管是你还是云服务器，都要拿着菜单才能说话。
  • big-market-app (厨房)：
    • 现在：厨房在你的 Mac 里。
    • 以后：厨房在云端的机房里。

代码不用改，只要环境换一下，它就能从“家庭作坊”变成“超级工厂”。这就是 Java 分布式架构的魅力！

Graph View