别再把JSF当HTTP：远程调用不背“包”袱！
前言 在我们的日常开发中，RPC（Remote Procedure Call，远程过程调用）扮演着非常重要的角色。它让我们可以像调用本地方法一样调用远程服务，极大地提高了系统的可扩展性和灵活性。然而，我注意到，在日常开发中的很多代码中, 设计JSF接口时，倾向于将返回对象设计得像HTTP请求的响应，包含errorCode、errorMessage、data等字段。 这实际上违背了RPC的设计初衷。RPC的目标是隐藏远程调用的复杂性，使得开发者可以专注于业务逻辑，而不是通信细节。因此，正确的RPC接口设计应该与本地方法的设计一致，返回值简单明了，异常通过抛出异常的方式处理。 今天，我想和大家探讨一下正确的RPC接口设计，希望能对大家有所帮助。 一、走偏的RPC接口设计 1.1 常见的错误方式 很多时候，我们可能会参考HTTP接口的设计，将RPC接口的返回值设计成一个统一的格式，例如： publicclassResult<T> { privateinterrorCode; privateString errorMessage; privateT data; // getters and setters} 然后，我们的RPC方法可能会这样定义： publicResult<User>getUserById(intuserId); 调用方需要先检查errorCode是否为0，再取出data进行业务处理。这种设计看似统一，实际上却增加了调用的复杂度。 1.2 问题何在？ 1.2.1 勿忘初衷 首先,我们违背了RPC设计的初衷.设想一下, 当你写一个本地方法, 你会不会返回一个包含errorCode、errorMessage、data的Result对象？当然不会！因为这样做完全没有必要，反而增加了调用的复杂度。 RPC的目的是隐藏网络通信的细节，让远程方法调用看起来像本地方法调用一样。如果我们在接口设计中人为地增加了复杂的返回值结构，就等于自己给自己制造了麻烦。调用方需要额外的代码来解包、检查错误码，这完全没有必要。 如果有异常发生，我们通过抛出异常来处理，这才是符合Java编程习惯的方式。 1.2.2 异常处理不规范 将错误信息通过返回值传递，而不是通过异常机制，会导致异常处理的混乱。 在Java中，异常处理是一个非常重要的机制。它可以帮助我们捕获和处理运行时发生的错误，提高代码的健壮性和可维护性。 当我们把错误信息通过返回值的方式传递时，会发生什么？ 1.调用方可能忘记检查错误码：开发者在使用方法时，可能只关注data，而忘记检查errorCode是否为0。这会导致错误被悄悄地忽略，埋下Bug的种子。 2.错误处理分散且不统一：每个方法的错误码可能不同，调用方需要根据不同的errorCode来处理错误，代码变得复杂且难以维护。 3.异常堆栈信息丢失：通过返回值传递错误信息，无法获得完整的异常堆栈，给排查问题带来困难。 还是上面的那个例子: Result<User>result=userService.getUserById(userId);Useruser=result.getData();//如果忘记检查errorCode，这里可能为null 如果errorCode表示用户不存在，但调用方忘记了检查errorCode，直接获取data，那么user可能为null，导致后续代码出现NullPointerException。这种异常与实际错误不符，增加了排查难度。 而使用异常机制，可以强制调用方处理错误： try{ Useruser=userService.getUserById(userId); // 处理业务逻辑}catch(UserNotFoundException e) { // 处理用户不存在的情况} 1.2.3 增加了代码冗余 每个RPC方法都需要返回一个Result对象，调用方需要重复地进行错误码的判断和处理，代码显得繁琐。 当我们使用Result对象作为返回值时，调用方的代码往往充斥着大量的重复性检查,此外，返回Result对象还会导致以下问题： •返回值不统一：有些方法可能返回Result，有些方法返回实际对象，调用方需要记忆每个方法的返回值类型，增加了认知负担。 •不便于方法组合：在函数式编程或流式操作中，Result类型的返回值不便于链式调用，限制了编程的灵活性。 •违反了单一职责原则：方法的职责应该是完成特定的功能，而不是既返回结果又传递错误信息。 代码应该是优雅的、简洁的，而不是充满了冗余和重复。 二. 正确的JSF接口设计原则 既然我们已经了解了将RPC接口设计得像HTTP响应一样存在的问题，那么接下来，就让我们看看如何正确地设计RPC接口。毕竟，找到问题还不够，我们还要找到解决方案，对吧？ RPC的魅力就在于：让你忘记网络的存在！ 以下举一个查询方法的例子, 比如你要设计一个承运商指标查询的JSF方法, 那么就按照一个本地方法调用去设计就好了： publicinterfaceProviderQueryService{ /** * 查询供应商指标 * *@paramstatisticDate 统计日期 *@paramproviderIdList 供应列表 *@return供应商指标列表 */ List<ProviderRateInfo>queryByDay(Date statisticDate, List<Long> providerIdList)throwsInvalidInputException, SystemRpcException; 这就是我们正常设计一个本地方法的方式, 通过java的异常机制,我们定义出可能的业务异常, 比如入参错误异常, 系统执行异常等等, 然后再调用时, 通过抛出异常来处理错误. try{ List<ProviderRateInfo> res=providerQueryService.queryByDay(statisticDate, providerIdList); // 处理业务逻辑 //todo... }catch(InvalidInputExceptione) { // 处理参数校验错误异常 //todo... }catch(SystemRpcExceptione) { // 处理系统执行异常 //todo... } 为什么要这样做？ 1.强制性错误处理：异常机制迫使调用者处理异常，避免错误被忽略。 2.清晰的错误传播路径：异常堆栈信息可以帮助我们快速定位问题所在。 3.统一的错误处理方式：通过异常，可以实现全局的异常处理策略。 此外, 需要说明一下, 对于JSF的系统异常,（如网络异常、超时等），JSF框架会抛出相应的异常，例如RpcException。调用方可以根据需要进行捕获和处理。同时, 在JSF框架中，异常会通过RPC框架进行序列化和传输，调用方可以正常地捕获到服务提供方抛出的异常。 同时返回值也变得简洁了很多, 这样也会待了很多好处: 1.减少代码冗余：不用写大量的if-else和错误码检查。 2.提高可读性：代码更易读，更容易理解方法的功能。 3.方便方法组合：更容易进行方法链式调用或使用函数式编程。 总结 让我们想象一下，代码就像艺术品，每一行都应当简洁、优雅。 如果我们的代码充斥着各种Result、Response、ErrorCode，那就像在一幅美丽的画作上涂抹了太多的颜料，反而失去了原有的美感。 因此，在设计JSF接口时，遵循以下原则： 1.远程调用像本地调用一样简单。 2.充分利用异常机制，统一错误处理。 3.返回值清晰明了，专注于业务数据。 这篇文章抛砖引玉, 希望大家在编写JSF接口时，能有所借鉴, 让我们的代码更加优雅，让我们的系统更加健壮！ 扫一扫，加入技术交流群 本文分享自微信公众号 - 京东云开发者（JDT_Developers）。 如有侵权，请联系 support@oschina.cn 删除。 本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
