这篇文章想复盘一个我们曾经做过的系统：一个基于 CORBA 的分布式构件组装平台。
很多人会把它简单归类为“老技术”，但如果只看技术名词，很容易错过真正有价值的部分：我们当年解决的问题，今天依然存在，只是实现手段发生了变化。

项目背景：一个异构构件组装系统

系统核心形态很直接：

  • 一个总线组件（Bus）
  • 一个 UI 组件
  • 一个数据库组件（DB）
  • 一个服务器组件（Server）

这些组件由不同语言实现（C++、Java），通过 CORBA 中间件完成跨语言通信。
我们还开发了 4 个 Eclipse 插件，用于分布式应用的构件组装、配置和部署。
此外有一个类似“名字注册空间”的服务（Naming/Registry），负责服务发现与路由。

换句话说，这是一个典型的“异构分布式系统”：语言异构、组件异构、运行环境异构，但要在工程上协同成一个整体。

当年的技术栈为什么看起来“重”

很多人会把 CORBA 体系概括为一串复杂名词：

  • IDL
  • Stub/Skeleton
  • ORB
  • Naming Service
  • Object Lifecycle
  • Distributed Transaction

这套东西看起来重，不是因为设计者喜欢复杂，而是因为要显式回答分布式系统里的基本问题：

  • 契约如何定义和演进（IDL）
  • 跨语言调用如何落地（Stub/Skeleton）
  • 远程对象如何寻址（ORB/Naming）
  • 对象生命周期如何管理（Lifecycle）
  • 跨边界一致性如何处理（Transaction）

这些问题在今天并没有消失，只是被拆散到了不同基础设施里。

关键转折：行业从“远程像本地”走向“远程就是远程”

CORBA 时代有一个理想：尽可能让远程对象调用体验接近本地调用。
但工程现实不断提醒我们：

  • 网络会断
  • 延迟不可预测
  • 超时和重试策略复杂
  • 版本兼容和灰度升级困难

后来行业共识逐步形成：RPC 不是本地函数调用。
从这个共识出发，REST/gRPC/消息驱动架构开始强调边界、失败语义、幂等、可观测性，而不是“透明化远程调用”。

古今映射：名字变了，抽象没变

把 CORBA 时代与现代云原生做一个简化映射，会发现很多是一一对应关系：

  • IDL -> OpenAPI / Protobuf / AsyncAPI
  • Naming Service -> Consul / Eureka / Kubernetes DNS
  • ORB 路由语义 -> API Gateway / Service Mesh
  • 总线通信 -> Kafka / NATS / Pulsar
  • 生命周期管理 -> K8s Controller / Operator
  • 分布式事务 -> Saga / Outbox / 最终一致性

如果只看技术名词，像是“新旧替代”；如果看系统抽象，其实是“能力重组”。

Eclipse 插件体系的现实意义

我们当时做的 4 个 Eclipse 插件，本质上是在做平台化工程能力：

  • 扩展点机制（插件化）
  • 构件编排与组装
  • 部署流程标准化
  • 生命周期与依赖管理

这和今天的 IDE 插件生态、内部研发平台（IDP）、Dev Portal、低代码编排工具，在思想上是连续的。
形式发生了变化，但“通过平台降低复杂系统的交付门槛”这件事没有变化。

Eclipse 插件底层：OSGi 到底解决了什么

Eclipse 插件体系的底层是 OSGi。
如果把它抽象成一句话：OSGi 是一个“可动态装卸、可隔离依赖、可注册服务”的模块化运行时。

在机制上，它主要做了几件事：

  • Bundle 模块化：每个插件是一个 Bundle，有独立元数据与依赖声明
  • 生命周期管理：支持 install/start/stop/update/uninstall
  • 服务注册中心：Bundle 可发布/发现服务，形成运行时解耦
  • 类加载隔离：每个 Bundle 有自己的 ClassLoader，避免 classpath 污染
  • 版本约束：通过 Import/Export package 和版本区间控制兼容性

这也是 Eclipse 插件生态能长期运行的关键原因：不是“把 jar 丢进一个目录”，而是有运行时治理能力。

当然，OSGi 也有明显代价：

  • 学习曲线较高（尤其是类加载与版本冲突）
  • 调试复杂度高于普通单体应用
  • 对团队工程纪律要求更高

OSGi 与当前主流方案对比

今天团队更常用的“插件/扩展”形态，往往是以下几类：

  • IDE 插件：VS Code Extension、JetBrains Plugin
  • Web 平台扩展：前端微插件、微前端、模块联邦（Module Federation）
  • 平台后端扩展：Sidecar、Operator、Hook、Workflow 插件节点
  • 低代码/流程平台：节点化扩展与脚本化能力注入

和 OSGi 对比，可以这样看：

  • OSGi 优势：模块边界清晰、依赖治理强、运行时动态管理能力强
  • OSGi 劣势：心智负担重、开发调试门槛高、生态热度下降
  • 现代插件方案优势：开发体验更轻、社区生态活跃、云原生集成好
  • 现代插件方案劣势：很多只解决“扩展点”，缺少 OSGi 级别的强运行时治理

一个实用判断是：
如果你做的是“企业内长期演进、需要强模块隔离与版本治理”的平台，OSGi 思路仍然非常有价值；
如果你追求“快速交付、低门槛生态扩展”，当前主流插件模型通常更划算。

EJB、CORBA 以及今天的微服务

EJB 在新系统里确实不再常见，CORBA 也不是主流首选。
但这不代表它们没有价值，反而说明行业把这些能力拆分得更细：

  • 通信协议层：REST / gRPC
  • 服务发现层：注册中心 / K8s 原生发现
  • 治理层：网关 / Mesh / 可观测性体系
  • 事务层：从强一致到最终一致

从架构史角度看，这不是“推倒重来”，更像是“从一体化重型中间件，演进到可组合的基础设施拼装”。

回答一个常见问题：这类系统今天还有借鉴意义吗

我的结论是：不仅有，而且很强。

因为很多今天做微服务的人，工具会用，但底层抽象未必扎实：

  • 不熟悉服务发现
  • 不理解 IDL/契约优先
  • 缺少跨语言协议意识
  • 忽略消息总线的解耦价值
  • 忽略组件生命周期和平台化治理

而这些恰恰是异构分布式系统训练出来的“架构基本功”。

总结

我们当年做的 CORBA 构件组装系统，不只是“历史遗留技术实践”，而是一套完整的分布式工程方法。
今天的技术栈已经从 CORBA/EJB 走到 REST/gRPC/Kubernetes，但核心问题依然是同一组：

  • 如何定义稳定契约
  • 如何治理服务发现
  • 如何控制跨语言复杂度
  • 如何管理生命周期与演进成本
  • 如何在不可靠网络上构建可靠系统

技术在演化，思想在延续。
真正会穿越技术周期的，不是某个框架，而是你对这些底层问题的理解与取舍能力。