微服务架构下，软件接口看护挑战，及解决之道

微服务架构下，软件接口看护挑战，及解决之道

​ 接口作为软件大厦中各个组件间的契约，无论是在软件诞生过程，还是在软件的发展过程，都扮演着非常重要的作用，看护好接口，保证系统的稳定性可持续性可扩展性，非常重要。如何看护，从如下几个问题来思考？

• 为什么需要做接口看护？
• 当前接口看护到底存在什么挑战？
• 什么样的接口需要去看护？
• 接口看护到底如何做比较靠谱？

为什么需要做接口看护？

回答这个问题，我们可以从反方向思考。假如说我们不做接口看护，会存在什么样的问题？

1. 首先上下游之间接口可以随意变动，随之而来的就是各种问题（编译不通过、持续集成失败、各种基础Bug），开发人员就会陷于Bug修复的死循环中。
2. 其次，内部上下层组件直接也存在同样的问题。
3. 同时，不做接口看护，也就意味着软件之间没有边界，软件将会乱象丛生，最终系统会变得非常庞杂和紊乱，走向终结。

说得太多，做过研发的人，都懂得他的重要性。

当前接口看护到底存在什么挑战？

从单体遗留大颗粒向微服务架构演进过程中，接口看护的难度增加，具体体现在如下方面：

• 微服务架构下，接口管理分散化。在原来单体大颗粒系统下，接口较为集中化，大家基于一套代码、一个框架体系构筑，接口一般集中化管理；而微服务化后，微服务与生俱来的独立性意味着其分散化管理，每个微服务都有自己的代码仓库，拥有独立的框架体系，接口不再集中，也不应该集中。
• 微服务架构下，接口表现形式多样化。在原来单体系统下，大部分接口都是函数接口或者私有消息接口，表现形式上较为统一和单一。而服务化后，伴随而来的多样化技术栈，多种语言（java/c/go）、多种通信技术（RPC、Rest…），所带来的接口表现形式更加多样化。
• 微服务架构下，接口更多。在原来单体系统下，软件上下游之间更多的接口暴露面体现在单体系统本身，相对接口较少。而微服务化后，每个微服务以及相关的sdk都会对外暴露，即使软件发布上对外组合多个微服务发布为服务后，接口数量仍然急剧增加。
• 最后，在架构演进探索过程中，也是逐步认识到微服务化架构所带来的变化，对于接口的看护也并非是一开始构筑好的，当前更多是依赖设计阶段的看护，常常出现接口漏识别，随意变更或者接口设计不合理等等问题，离100%做到接口看护仍然存在非常大的Gap。

什么样的接口需要去看护？

首先看看wiki对接口（API）的定义：

应用程序接口（英语：Application Programming Interface[1]），缩写为API[2]，是一种计算接口，它定义多个软件中介之间的交互，以及可以进行的调用（call）或请求（request）的种类，如何进行调用或发出请求，应使用的数据格式，应遵循的惯例等。它还可以提供扩展机制，以便用户可以通过各种方式对现有功能进行不同程度的扩展[3]。一个API可以是完全定制的，针对某个组件的，也可以是基于行业标准设计的以确保互操作性。通过信息隐藏，API实现了模块化编程，从而允许用户实现独立地使用接口。

如上描述的，接口定义了多个软件中介之间的交互形式。狭义上来说一般指函数、约定的消息接口等等，广义上来看，接口指的更多软件之间依赖的具体表达形式。从广义上梳理来看，可以从如下两个维度理解接口：

• 从接口表达上来看，接口天然具备两种表达方式：显性表达、隐性表达。显性表达是可见的，偏向于软件实体本身，如：程序、数据文件、配置文件等等；隐性表达是不可见的，偏向于承载的业务功能及相关约定，只有运行时才会表达出现。
• 从接口作用域来看，接口作用在软件生命周期各个环节。涉及：
  • 开发、运行约定：开发过程中，会更加相关约定的算法、协议、消息接口等等进行系列开发，采用统一的编译参数进行编译构建。
  • 构建时访问：构建过程中下游软件实体会访问上游软件实体的脚步、软件包，依赖内部的包结构进行集成构建。
  • 启动中配置：启动过程中会访问约定的文件，解析并应用，从运行时获取约定的环境变量初始化，同时按格式解析适配包等等。
  • 运行时访问：运行过程中软件间会相互调用彼此的函数接口，访问相关的数据结构等等。

不管是隐性的还是显性的接口，两者同等重要，都需要进行看护，可以同时构筑。不过从通用性来讲，做好显性的接口看护收益能更高更快。

接口看护到底如何做比较靠谱？

如何做好接口看护才靠谱，一般可以有如下几个选项：

• **靠人。**靠牛逼的SE在一开始设计好接口，靠经验丰富的Commiter检视好代码，靠能力全面的测试人员充分测试接口。当然不靠谱，每个人能力差异且认知也存在差异，靠人当然不靠谱。

• **靠流程。**靠IT化的流程，在设计、开发环节做好接口看护。设计过程中，通过多个专家检视，把关接口设计质量，同时在代码合入环节，多个同行参与评审，避免接口变更等问题。当然也不靠谱，道理很简单，过程中存在不靠谱的因素，且不可控。

既然是程序的世界，那就用程序的方式解决这个问题。

对于显性的接口表达，我们可以通过验证的方式，去检查软件包中的各种程序、配置、数据文件。采用逆向分析的方法，去验证软件包中各种显性的接口是否与定义一致。

对于隐性的接口表达，同样也需要通过验证的方式，去解决。可以设计越来越多的测试用例，构筑自动化测试能力，去帮助接口看护。

两种看护方式都可以落地到代码合入的门禁环节，做到真正有效地接口看护。

对于显性的接口看护细节，请参考下文。