干货 | 以模型为中心，携程契约系统的演进

作者简介

 

章鱼， 携程资深后端开发工程师，契约系统创始人与核心研发。

Sylar， 携程资深研发经理，专注Java技术栈相关研究。

一、前言

随着微服务化在携程的全面落地，业务被拆解得越来越细，接口数量和内外部调用方不断增多；另一方面，随着产品迭代的不断增速，对接口的修改也变得愈加频繁。

接口契约，作为各端的沟通桥梁，在微服务时代显得尤为重要。如何管理好不断变化的接口契约，是携程机票BU在微服务化过程中遇到的一大难题。本文结合一些契约管理的实践经验，介绍下携程契约管理的演进，以及携程机票BU自研发的契约系统（简称MOM - model object management，以下都以此代替）。

二、携程契约管理演变史

2.1 线下管理契约

在携程机票BU以及其它的一些团队里，早期的契约管理，主要由程序员线下进行。当发生需求变更，需要增加新的接口，或改动原有契约时，由相应的开发线下编辑契约文件（如XSD文件），再生成指定格式的契约（如Java类，Protobuf文件），提供给使用方。

在单体应用时代，或业务没有拆分很细的时候，接口契约并不会太多，调用方也相互熟悉，只要有专人负责线下契约维护，这种管理方式并不会有太大问题。但随着微服务化，接口和契约不断增多，此种管理方式的瓶颈逐渐凸显，问题主要集中在以下几点：

1）线下管理，契约容易丢失。

2）契约变更，只有编辑者才能主动感知，无法很好的周知到所有使用方。若契约变更不当，容易在上线时才发现问题。

3）当有多个需求，需要对同一份契约进行修改时，需手工解决各种冲突，这个过程极易出现问题。就好比不用Git，手工去进行代码分支管理一样。

4）契约可读性差，接入沟通成本大，各团的原始契约也没有一个统一的标准。

2.2 第三方工具管理契约

由于线下契约管理，存在太多各式各样的问题。携程内部各团队都在积极探寻，尝试借助一些第三方工具，去更好地管理契约。常见的有Swagger、Knife4j、YAPI等工具。

Swagger是一款非常受欢迎的开源框架，它通过文档与代码的绑定，能很好地对API进行文档化描述，接入起来也比较方便。Swagger一定程度解决了线下管理契约易丢失、可读性差等问题。但由于Swagger单机或集群的契约管理方式，会使得携程内部各项目（应用）之间，显得比较割裂，所以Swagger并未在携程内部大范围推广。同时，Swagger的界面比较粗糙，文档的编写需要遵守一系列的规范，上手有一定难度。

Swagger

Knife4j是一款国产开源项目，也是用于API文档的生成。与Swagger相比，它有着更加出色的界面，并且能够支持如离线文档、安全控制、在线调试等功能。但是与Swagger有相同问题，Knife4j并不是一个中心化的契约管理方案。

Knife4j

YAPI是去哪儿为推进API标准化，研发的一款API治理工具。本身也拥有丰富的功能，携程内部也有一些团队在使用，但它的设计更注重于API的多样化管理，不支持模型共享，不支持单独模型聚合方式管理，必须要有接口名称和输入输出信息。这些限制给契约的管理带来不少麻烦。

YAPI

总的来说，Swagger、Knife4j和YAPI，将契约管理方式从线下转到了线上，一定程度解决了契约易丢失ÿ