企业官网建设流程全解析

很多人第一次翻到早期分布式企业应用的代码时，都会卡在同一个疑问上：一个业务组件为什么要写两个接口？一个叫 Home，一个叫 Remote，方法还都不在同一个地方。更让人困惑的是，真正干活的业务方法全在 Remote 里，而 Home 里只有 create、remove、find 这几个看起来像数据库操作的方法。刚上手的人很容易觉得这是规范设计者的过度设计，恨不得把两边合并成一个接口，省事又清爽。

但只要你真正踩过一次“把生命周期方法和业务方法塞进同一个接口”的坑，就会明白 Remote 接口和 Home 接口的主要作用根本不是冗余，而是把**“怎么拿到对象”和“拿到对象之后干什么”**这两件性质完全不同的事，强行拆到了两个契约里。这个拆分背后牵扯到容器的代理生成、实例池化、事务边界、序列化约束、安全控制等一整套机制。下面我按自己理解这套模型的顺序，把两个接口各自的职责边界、为什么必须分开、合并之后会出什么问题，以及这套思路在今天的技术栈里怎么变形存活，一条条拆开讲。

1. 两个接口不是冗余设计，而是把“找对象”和“用对象”拆成了两步

理解 Remote 接口和 Home 接口，最忌讳一上来就背定义。定义谁都会写：Home 管生命周期，Remote 管业务方法。但这句话不解释“为什么”，背下来也没用。我更喜欢从一次真实的远程调用链路往回倒推，看看这两个接口分别在链路的哪个环节被用到，以及如果去掉其中一个，链路会在哪里断掉。

1.1 一次远程调用在网络上真实走过的路径

假设客户端要调用一个订单组件的提交方法。它手上并没有订单组件的实例，甚至连这个组件的类都没有。它做的第一件事是去一个命名服务里按名字查找，拿回来的东西叫 Home 引用。这个 Home 引用本身也不是服务端的对象，而是一个由容器生成的桩，它实现了 Home 接口，内部封装了网络地址、协议编解码、连接复用这些细节。

拿到 Home 引用之后，客户端调用create()，这时候才真正触发服务端创建一个业务实例，或者从实例池里分配一个空闲实例。返回的是 Remote 引用，同样是个桩。客户端再通过这个 Remote 引用调用submit()，请求才最终落到业务代码上。

这条链路里有两个非常关键的转折点：第一个转折点是“查找并创建”，第二个转折点是“调用业务方法”。两个转折点对应的失败模式完全不同——第一个可能因为名字写错、容器没启动、权限不足而失败；第二个可能因为参数无法序列化、实例已被销毁、事务回滚而失败。把它们放在两个接口里，客户端就能针对性地处理这两类失败，而不是在一个方法里猜测“这次报错到底是找不到服务还是业务逻辑炸了”。

1.2 类型级操作与实例级操作：分离的根本理由

再往深一层想，Home 接口上的方法有个共同特征：它们操作的对象是“某一类组件”，而不是“某一个具体实例”。create是在造一个新的，find是按条件找出一批，remove按主键删除一条记录。这些操作的粒度是类型级别的，跟 Java 里Class对象和实例对象的区别是一个道理——你可以通过类去 new 一个对象，但你不能在实例上再 new 一个同类对象。

Remote 接口上的方法恰好相反，全部是实例级别的：这个订单要提交、那个订单要取消，都绑定在具体的实例身份上。类型级操作和实例级操作的实现者也不一样：Remote 接口的方法体是你自己写的业务代码，Home 接口的方法体基本是容器在部署阶段根据配置生成的，你最多写个主键类或者查询语句。让一个由容器生成的实现和一个由开发者手写的实现挤在同一个接口里，等于把两套完全不同生命周期的代码强行焊死，后续任何一方变更都要动同一个文件，这是架构上最忌讳的耦合。

还有一个容易被忽略的点：Home 引用是可以跨客户端共享和缓存的。一个应用启动时查一次 Home，之后所有请求复用这个引用，完全没问题。但 Remote 引用不一定能共享——对于有状态组件，每个客户端持有的 Remote 引用绑定的可能是完全不同的实例，共享就会串数据。这种“一个可共享、一个不可共享”的差异，也要求它们在类型系统上就是两个东西。

2. Home 接口：容器替你实现的“工厂+登记处”

Home 接口经常被低估，因为它看起来只有寥寥几个方法，还都不是你写的。但我见过太多项目在这上面出问题，原因基本都是没搞清楚它承担的到底是什么角色。我的理解是：Home 接口同时扮演了两个角色——工厂和登记处。工厂负责生产实例，登记处负责按标识定位实例。这两个角色在不同类型的组件上权重不一样。

2.1 create 到底做了什么，为什么它不能有业务逻辑

create()这个方法名很有迷惑性，看起来像构造函数，实际上它触发的动作比构造函数复杂得多。容器收到 create 请求后，通常要走这么几步：检查调用者有没有创建权限、从实例池里取一个空闲实例或者新建一个、调用实例的初始化回调、把实例注册到容器内部的管理表中、生成一个绑定到该实例的 Remote 桩返回给客户端。整个过程都在容器的事务和安全拦截器之下完成。

正因为它承载了这么多容器级动作，你往 create 里塞业务逻辑就非常危险。我见过有项目在ejbCreate里直接写“初始化订单号为当天日期加流水号”这种逻辑，测试环境跑得好好的，一上生产就出问题——因为无状态组件的实例是池化复用的，同一个实例可能先后服务几十个客户端，create 里写入的实例字段在下一次复用时会残留。更麻烦的是事务语义：create 的事务属性和业务方法的事务属性是分开配置的，如果 create 里做了写库操作，它可能在业务方法的事务还没开始时就已经提交了，回滚根本回滚不掉。

正确的做法是把 create 当成纯粹的“状态初始化入口”，只做参数校验和必要的资源绑定，真正的业务初始化放到第一个业务方法里，或者用显式的初始化方法来触发。

2.2 remove 与 find 的语义差异：会话组件和实体组件的分水岭

remove和find这两个方法在不同类型的组件上含义完全不同，这一点初学者最容易混淆。

对于会话型组件（一次会话内有效的业务对象），remove的语义是“结束这次会话，把实例还给池”，find基本不存在，因为会话对象没有持久化身份，你没法按主键去找一个会话。对于实体型组件（对应持久化数据的对象），remove的语义是“删除这条持久化记录”，find则是按主键或者查询条件定位记录，返回的是绑定到那条记录的引用。

这个差异直接决定了 Home 接口的方法签名。会话组件的 Home 通常只有无参或者带初始化参数的 create，实体组件的 Home 则会有一堆findByXxx方法，有的规范还允许返回集合的批量查找。我在做代码评审时有个习惯：看到 Home 接口里出现了find却对应的是会话组件，基本可以判定这个设计跑偏了，要么是把实体当会话用，要么是绕过了持久层自己造了一套查询。

还有一个实操细节：remove传的参数在不同实现里可能是句柄也可能是对象引用，调用之后原来的 Remote 引用就失效了，继续调用会抛“对象不存在”类的异常。这个失效是立即的还是延迟的，取决于容器的实现，不能假设它同步生效。

2.3 Home 引用的获取链路：名字查找那一步绕不开的原因

客户端拿到 Home 引用的标准路径是名字查找。为什么不能直接 new 一个？因为 Home 的实现在编译期根本不存在——它是部署阶段由容器工具生成的，类名、包名都可能是动态拼出来的。客户端唯一能依赖的稳定信息就是那个注册名。

这条链路里有两个坑值得单独说。第一个是注册名的层级结构，很多容器要求写成类似“应用名/模块名/组件名/接口全限定名”的多段形式，少一段就找不到，而且不同版本的容器对分隔符的要求还不一样。排查这类问题最快的办法不是猜，而是把容器启动日志里打印的绑定清单捞出来，对着看。

第二个是 Home 引用的缓存策略。Home 引用本身是可以长期持有的，但它背后指向的容器可能重启、组件可能重新部署，这时候旧的 Home 引用就变成了僵尸。稳妥的做法是在捕获到“引用失效”类异常时，丢弃缓存重新查找一次，而不是在启动时查一次就再也不管。这个重试逻辑我一般会封装成一个小的持有器，把查找、缓存、失效重查三件事包在一起。

3. Remote 接口：业务契约的远程可见边界

Remote 接口看起来最直白——不就是把业务方法列一遍吗？但它的约束比本地接口严得多，因为每一个方法调用都要跨越进程边界，中间隔着序列化、网络传输、容器拦截三层。很多在本地调用里完全合法的写法，放到 Remote 接口上就会直接编译不过或者运行时报错。

3.1 序列化这道硬门槛，卡掉了多少种写法

Remote 接口的方法参数和返回值必须是可序列化的，这是硬性要求，没有商量余地。我见过最常见的三个翻车点：传了一个自定义的普通类但忘了实现序列化接口；传了一个集合但集合里的元素不可序列化；传了一个内部类，而内部类隐式持有外部类的引用，外部类又不可序列化，导致整个对象图序列化失败。

第三种最隐蔽，因为编译完全通过，单元测试如果用本地调用方式跑也没问题，只有真正跨进程时才炸。我一般的处理原则是：凡是出现在 Remote 接口签名里的类型，全部单独建一个传输对象包，强制实现序列化接口，并且显式声明序列化版本号。声明版本号这件事很多人嫌麻烦，但跨版本部署时它能救命——不加版本号，服务端给类加一个字段，客户端反序列化就直接报版本不匹配。

另外要提醒的是大对象问题。有些人图省事，直接把一个包含几十个字段的实体对象整个传过去，其中还带着关联对象的集合。这在本地调用里无所谓，跨进程时序列化开销和网络开销会成倍放大。我的经验是把传输对象裁剪到“这次调用真正需要的字段”，宁可多定义几个小的传输对象，也不要复用一个大而全的实体。

3.2 你手里的引用是桩，不是组件实例

这一点必须反复强调：客户端拿到的 Remote 引用，跟服务端那个真正执行业务的实例之间，没有任何对象身份上的对应关系。它只是一个桩，负责把方法名、参数打包发出去，再把结果解包返回。

这个认知会直接影响你写代码的方式。比如你不能在 Remote 引用上做==比较来判断是不是同一个业务对象——两个引用指向同一个逻辑对象，但桩对象可能是两个不同的实例，比较结果是 false。正确的做法是比较业务主键。再比如你不能依赖桩上的字段状态，因为桩上没有业务状态，所有状态都在服务端。

还有一个更隐蔽的影响：方法调用的开销是不对称的。本地调用一个方法可能就几纳秒，远程调用一次少则几百微秒多则几十毫秒。所以 Remote 接口的设计必须走“粗粒度”路线，一次调用把一批数据带过去，而不是像本地接口那样设计一堆细粒度的 getter/setter。我接手过一个接口，里面有个循环，每轮循环调三次远程方法，一万条数据就是三万次网络往返，性能差到没法看。改成批量接口之后，耗时从几分钟降到几秒。

3.3 异常与事务声明的隐性规则

Remote 接口的方法声明里通常要带上远程异常，这是规范强制的。但真正麻烦的不是这个强制异常，而是业务异常怎么传。

如果业务异常是受检异常，它必须能被序列化，并且客户端要有对应的类，否则反序列化失败，客户端只能看到一个笼统的远程异常，原始的错误信息全丢了。我见过有团队把业务异常定义在服务端模块里，客户端根本没引这个模块的包，结果所有业务错误在客户端都变成了“未知错误”，排查起来极其痛苦。解决办法要么是业务异常单独打成一个共享包，要么统一转成错误码加消息的形式传输。

事务声明则是另一个维度。Remote 接口上的每个方法都要配置事务属性——是加入调用方的事务、还是新开一个、还是不需要事务。这个配置写在部署描述或者注解里，不在方法签名上，所以特别容易被漏掉。漏掉的后果是方法跑在没有事务的环境里，写库操作各自自动提交，出了错也没法整体回滚。我的习惯是给每个 Remote 方法都显式写事务属性，哪怕是“不需要事务”也写清楚，让意图可见。

4. 把两个接口合成一个会怎样：三类翻车现场

理论讲多了容易飘，我拿几个实际遇到过的情况说明，为什么这个分离不能省。下面这三类问题，基本覆盖了合并接口之后最常见的翻车方式。

4.1 生命周期方法污染业务契约后，容器生成代码失效

最直接的后果是容器的部署工具没法正常工作了。Home 接口的实现是容器在部署时生成的，生成逻辑依赖接口里方法的命名和签名约定——create开头的必须返回 Remote 接口类型，find开头的必须返回实体引用或者集合，参数类型也有约束。一旦你把业务方法混进去，生成工具要么直接报错，要么生成出一个残缺的实现，运行到某个方法时抛“未实现”。

更麻烦的是，有些老版本的容器对这种情况不做严格校验，能部署成功，但生成的桩里业务方法是空的，调用时返回 null 或者抛一个莫名其妙的异常。这种问题排查成本极高，因为日志里什么线索都没有，你只能一行行对着接口看。

4.2 有状态组件与池化实例混用导致的状态串台

这个坑我在一个模拟项目里亲眼见过。那个项目把 create 和业务方法放在同一个接口里，客户端调用时看起来一切正常。但那个组件是有状态的，需要在多次调用之间保留会话数据。由于接口合并，客户端每次都是通过同一个入口拿引用，容器没法区分“这是新会话”还是“继续上次会话”，结果实例池把同一个实例分配给了两个不同的客户端，A 的购物车数据出现在了 B 的页面上。

分开之后这个问题天然不存在：create 是唯一的新会话入口，容器在 create 时就知道要绑定一个新实例，后续所有业务调用都通过 Remote 引用路由到那个确定的实例，池化逻辑和会话绑定逻辑各管各的，互不干扰。

4.3 安全与事务边界被摊平后的连锁反应

安全配置通常按方法粒度做，而生命周期方法和业务方法需要的权限完全不同。创建组件的权限往往只开放给特定的内部调用方，业务方法的权限则可能开放给更广的范围。接口合并之后，权限配置只能粗暴地按接口整体配，要么放得太宽，要么收得太紧。

事务也是同样的道理。创建操作可能需要独立事务，业务方法可能需要加入调用方事务。合并到一个接口里，事务属性只能配一套，怎么配都是错的。这两类边界一旦被摊平，后面再想拆回来，改动量会大到没人愿意动，最后就变成了技术债。

5. 这套分工在今天的框架里换了什么外衣

有人会说，这套东西早就过时了，现在谁还写这种双接口。这话对一半——字面上的双接口确实少见了，但“工厂/注册”和“业务契约”这两层职责的分离，在今天的框架里只是换了个形式存在，理解了原始模型，看现代框架的很多设计会豁然开朗。

5.1 容器工厂与业务对象：同一套思路的简化版

现代容器框架里，getBean这类方法扮演的就是 Home 的角色——按名字或者类型定位、创建、返回一个对象。业务对象本身扮演 Remote 的角色。区别在于，现代框架把“实例池化”和“会话绑定”这两个复杂度大幅简化了：默认单例，谁拿到都是同一个；需要多例时显式声明作用域。简化之后，独立的 Home 接口就显得多余了，工厂的职责被合并进了容器本身。

但注意，简化不等于消失。当你需要控制对象的创建过程——比如创建时要读配置、要连接外部资源、要做权限检查——你还是会写一个工厂类或者工厂方法，那本质上就是 Home。我在实际项目里经常保留这种模式：业务接口对外暴露纯业务方法，创建逻辑单独放一个工厂，测试的时候可以 mock 工厂返回假对象，非常方便。

5.2 注册中心与客户端桩：分布式服务版本的 Home/Remote

在服务化架构里，这个分离体现得更明显。服务提供方把自己的地址注册到注册中心，消费方从注册中心订阅地址列表，然后在本地生成一个代理对象，通过代理发起调用。这里的注册中心加订阅逻辑，承担的就是 Home 的职责——发现服务、建立连接、返回一个可调用的引用。代理对象承担的就是 Remote 的职责——把方法调用转成网络请求。

两者的失败模式依然是分开的：注册中心连不上、服务下线、订阅不到地址，属于发现阶段的问题；调用超时、参数反序列化失败、业务异常，属于调用阶段的问题。你看，这跟二十多年前的双接口模型，在职责划分上是完全同构的，只是协议从专有协议换成了通用协议，桩从容器生成换成了动态代理。

5.3 动手写一个 30 行的极简双接口模型

光说不练没意思，我写一段能跑的最小模型，把两个接口的职责边界用代码固定下来。这段代码不需要任何容器，纯手写，但结构跟真实场景是一致的。

import java.rmi.Remote; import java.rmi.RemoteException; // 业务契约：只放业务方法 public interface OrderRemote extends Remote { String submit(String orderId) throws RemoteException; void cancel(String orderId) throws RemoteException; } // 生命周期契约：只放创建、销毁、查找 public interface OrderHome extends Remote { OrderRemote create(String tenantId) throws RemoteException; void destroy(OrderRemote ref) throws RemoteException; }

配套的实现里，Home 的实现内部维护一张从引用到实例的映射表，create 时新建实例并登记，destroy 时移除登记。Remote 的实现只关心业务逻辑，完全不碰实例的创建销毁。

import java.util.Map; import java.util.UUID; import java.util.concurrent.ConcurrentHashMap; public class OrderHomeImpl implements OrderHome { private final Map<String, OrderRemote> registry = new ConcurrentHashMap<>(); @Override public OrderRemote create(String tenantId) { String key = UUID.randomUUID().toString(); OrderRemote ref = new OrderRemoteImpl(key, tenantId); registry.put(key, ref); return ref; } @Override public void destroy(OrderRemote ref) { if (ref instanceof OrderRemoteImpl) { registry.remove(((OrderRemoteImpl) ref).getKey()); } } }

这段代码跑起来之后，你可以做个实验：把create方法挪到OrderRemote接口里，然后你会立刻发现两个问题——实现类得自己管理自己的创建，注册表没地方放了；客户端拿到引用之后不知道该先调哪个方法，因为创建和业务混在一起，调用顺序变得不确定。这就是分离的价值，它在类型系统层面强制了调用顺序。

6. 排查清单：Home 与 Remote 相关问题的定位顺序

真到了线上出问题的时候，最需要的不是原理，是一张能按图索骥的排查表。我把自己这些年遇到过的问题按发生阶段整理了一下，顺便说说定位思路。

6.1 异常对照表与成因速查

这张表不是穷举，但覆盖了我实际遇到问题的八成。用的时候建议按阶段顺序来：先确认能不能拿到 Home，再确认能不能创建，最后才看业务调用。顺序错了容易在错误的层面上打转。

6.2 一条完整的排查链路复盘

说一个我印象最深的案例。某次联调，客户端调用业务方法一直返回空结果，没有任何异常。按常规思路，先怀疑业务逻辑写错了，加日志、打断点，服务端日志显示方法确实被调用了，入参也对，返回值也对，但客户端拿到的就是 null。

这时候把排查往上提一层，检查 Remote 引用的来源。发现客户端为了省事，把 Home 引用缓存在一个静态变量里，而服务端在联调过程中重新部署过一次。旧的 Home 引用指向的是已经销毁的容器上下文，create调用居然没报错，返回了一个“看起来正常”的引用，但那个引用绑定的实例根本不存在于新容器里，调用被静默丢弃了。

定位过程分三步：第一步对比客户端和服务端的时间戳日志，发现客户端调用时间点上服务端没有任何对应记录；第二步检查引用的持有方式，发现是长期静态缓存；第三步验证猜想，手动清掉缓存重新查找，问题消失。修复方案就是前面提到的持有器模式——捕获失效异常时重新查找，同时给缓存加一个最大存活时间，超过就主动刷新。

这个案例给我的教训是：分布式场景下，“没有异常”不等于“调用成功”。任何跨进程的调用都要有明确的成功标志，返回值不能是唯一的判断依据，必要时加一个调用序号或者请求 ID 做端到端对齐。

7. 关于这两个接口，我自己的几条使用心得

写到这里基本把职责边界讲透了。最后补充几条纯经验性的东西，都是文档里不会写、但实际做项目时能省不少事的。

第一条，接口的粒度要跟调用频率反着来。调用越频繁的接口，方法要越粗；调用越少的，可以适当细一点。我一般会把“查列表”和“查详情”做成两个方法，而不是一个方法带个标志位，因为跨进程传标志位的成本比多写一个方法高得多。

第二条，传输对象和业务实体一定要分开。哪怕字段一模一样，也要单独建一个类。原因很简单：业务实体会随着需求变，传输对象要跟着接口版本走，两者绑在一起，任何一边改动都会传导到另一边。分开之后，转换代码虽然啰嗦，但出问题时定位边界非常清晰。

第三条，给每个 Remote 方法都加上超时和重试的显式配置，不要依赖框架默认值。默认值往往是给演示场景准备的，生产环境的网络抖动、下游慢查询，都可能让一个没配超时的方法挂住整个线程池。

第四条，如果团队里有人坚持要把创建逻辑塞进业务接口，别急着争论架构，直接让他做一个实验：把组件部署两次，看看客户端能不能正确区分两个部署实例。这个实验做完，大部分争论就自然结束了，因为问题会以最直观的方式暴露出来。