《API网关》第4章：将连接(RPC\HTTP\其他)抽象为数据源

作者：小傅哥
博客：https://bugstack.cn (opens new window)

沉淀、分享、成长，让自己和他人都能有所收获！😄

• 本章难度：★★★☆☆
• 本章重点：拆解Dubbo、HTTP调用，抽象为数据源服务，便于后续功能的扩展和使用
• 课程视频：https://t.zsxq.com/05RzRFmUr (opens new window)

一、学习指引

你发现傅哥开发的套路了没？

在整个API网关的功能实现上，也包括之前的星球里的其他项目如Lottery抽奖等，小傅哥在实现的过程中都会先开发一个只要能满足功能的核心逻辑案例，之后对案例的中代码的职责进行拆解细分。也就是使用框架结构、设计原则和设计模式等手段，将不同的功能模块进行分区实现，构建出界限上下文。

从前期来看这样的实现过程要比仅使用一个类 if···else 所开发的代码交付速度要慢了不少，那么从架构设计和开发上来说，为什么这么干？因为长期来看代码的成本远不是最开始的开发阶段，而是在后期的维护、迭代、扩展，满足产品新增的差异化需求时，所投入的研发资源。所以对于有稳定长发展周期的项目来说，这样做是值得的。

那么本章小傅哥则是带着大家把API网关中关于 RPC 的泛化调用使用提炼出来，把它抽象为一种数据连接资源进行使用。这样也就方便我们在这个框架中扩展其他的连接资源，包括各个厂家的 RPC 实现、HTTP服务、WebService 调用等，并还可以通过SPI的方式进行自定义连接资源扩展，以适应不同场景的诉求。

二、抽象连接

API网关的实现对于RPC接口的泛化调用，类似于ORM框架中对数据库的调用。那么我们也可以把 RPC 抽象成一种连接资源，做数据源的管理和池化的实现。这样既可以方便我们扩展新的连接方式，比如各类厂商的 RPC 框架，或者 HTTP 服务，以及你提供的大数据原始接口服务，也都可以被这样包装处理。所以这是抽象连接为数据源的设计目的。

• 整个API网关的通信模型结构已经逐步的清晰，从网络协议转换->开启通信会话->获取映射关系->执行具体的请求方案，到本章要实现的抽象的数据源。把 RPC、HTTP 当做数据源来维护。
• 在这一系列内容的开发中，你将慢慢体会到职责的分离，功能模块的解耦，为了扩展预留出了哪些东西。