接口

按：系统架构经过多年演进，现在越来越多的系统采用微服务架构，而微服务架构最重要的就是面向接口编程，所以接口的设计就尤为重要了，我一直认为一个好的接口自己会说话，也就是看到接口，我就知道这个接口是干啥的、参数是啥、返回值是啥以及可能会遇到哪些问题，但目前对 RPC 接口设计可以说有两派，前一段时间看了一篇文章是我的想法完全一样，特转载到本人博客，希望更多的能够看到、有更多的人参与讨论两种的优劣。 在开始之前呢，先吐槽一个本文没有提到的问题，我不知道有些人是怎么想的，对外暴露的接口，也就是最终被打成 jar 包供外部服务依赖模块，有些人喜欢在里面引入各种无关的第三方依赖，我遇到过把 spring mvc、spring、mybatis、dubbo 等等还有其他的像 POI 什么乱七八糟的第三方 jar 都依赖进来的，说实话，我只想问：可以说脏话吗？不可以啊，那好吧，我无话可说了，我们开始看原文吧。 RPC 框架的讨论一直是各个技术交流群中的热点话题，阿里的 dubbo，新浪微博的 motan，谷歌的 grpc，以及不久前蚂蚁金服开源的 sofa，都是比较出名的 RPC 框架。RPC 框架，或者一部分人习惯称之为服务治理框架，更多的讨论是存在于其技术架构，比如 RPC 的实现原理，RPC 各个分层的意义，具体 RPC 框架的源码分析…但却并没有太多话题和“如何设计 RPC 接口”这样的业务架构相关。 可能很多小公司程序员还是比较关心这个问题的，这篇文章主要分享下一些个人眼中 RPC 接口设计的最佳实践。 初识 RPC 接口设计 由于 RPC 中的术语每个程序员的理解可能不同，所以文章开始，先统一下 RPC 术语，方便后续阐述。 大家都知道共享接口是 RPC 最典型的一个特点，每个服务对外暴露自己的接口，该模块一般称之为 api；外部模块想要实现对该模块的远程调用，则需要依赖其 api；每个服务都需要有一个应用来负责实现自己的 api，一般体现为一个独立的进程，该模块一般称之为 app。 api 和 app 是构建微服务项目的最简单组成部分，如果使用 maven 的多 module 组织代码，则体现为如下的形式。 serviceA 服务 serviceA/pom.xml 定义父 pom 文件 <modules> <module>serviceA-api</module> <module>serviceA-app</module> </modules> <packaging>pom</packaging> <groupId>moe.cnkirito</groupId> <artifactId>serviceA</artifactId> <version>1.0.0-SNAPSHOT</version> serviceA/serviceA-api/pom.xml 定义对外暴露的接口，最终会被打成 jar 包供外部服务依赖 ...