简介： 随着微服务架构越来越风行，越来越多的公司应用微服务框架进行开发。甚至不止是公司，连笔者的研究生导师都要对实验室的 Spring Boot 工程项目转型应用微服务框架了。
本文是《微服务治理实际》系列篇的第四篇文章，次要分享 Spring Cloud 微服务框架下的服务契约。
第一篇：《微服务治理解密》
第二篇：《微服务治理实际：服务查问》
第三篇：《微服务治理实际：金丝雀公布》
在具体讲述服务契约之前，先给大家讲一个场景。
前言
随着微服务架构越来越风行，越来越多的公司应用微服务框架进行开发。甚至不止是公司，连笔者的研究生导师都要对实验室的 Spring Boot 工程项目转型应用微服务框架了。随着工夫的推移，服务量逐步回升，小学妹吃不消跑来问我问题：
一姐，我来交接你之前写的我的项目啦，你什么工夫不便我想问你一些问题。这么多微服务接口，感觉不晓得从哪里去看会比拟好呢。
我想了想本人刚入门时候写的垃圾代码，还没有正文，无语凝噎。
好。我平时工作日在实习，周末给你讲哈。
于是到周末，花了整整一个早晨的工夫，终于给零根底学妹从泛滥接口的含意，到参数列表的解析，最初到解说百度应该搜什么关键词（我好南），全方位视频领导。学妹非常打动：
一姐你太贴心了 555，跟他人合作我的项目的时候，常常能讲上几句就不错了，而后我还是什么都不明确，改完接口也不及时通知我。还是你最好了，前面还有什么不懂的我再来问你哦。
从以上场景，咱们能够总结出应用微服务框架后，会带来的几点进度协同问题：
1、不及时提供接口 API：
尤其体现在我的项目交接上，该问题对人员变动比拟频繁的组织，如高校我的项目的准毕业生和新生交接、企业我的项目的外包人员交接，问题会显得更加突出。开发人员常常过于关注微服务的外部实现，绝对较少设计 API 接口。
程序员最厌恶的两件事：1. 写正文 2. 他人不写正文
是不是常常想着写完代码再写正文，但真正把代码写完当前，正文 / 接口形容一拖再拖最初就没有了？别通知我你没有过。
2、不及时变更接口：
即便有了 API 文档，但因为文档的离线治理，微服务接口变更当前，文档却没有及时变更，影响合作人员的开发进度。
综上咱们看到，咱们岂但心愿所有的微服务接口都能够很不便的增加标准的接口形容，而且也能随着接口的变更及时更新文档。因而，咱们须要服务契约来帮忙咱们解决这些问题。
为什么咱们须要服务契约
首先咱们来看服务契约的定义：
服务契约指基于 OpenAPI 标准的微服务接口形容，是微服务零碎运行和治理的根底。
有人可能会问了，既然想要标准的形容接口，我有很多其余的形式啊，为什么我要用服务契约？
1、我用 Javadoc 来形容接口而后生成文档不能够吗？
能够，但刚刚咱们也提到了“程序员最厌恶的两件事”，要求所有的开发人员都去被动的依照标准写正文，把所有的接口、参数列表的类型、形容等信息全都写分明，是一件比拟费时费力的事件。咱们心愿有一个可能缩小开发人员累赘的办法。
2、当初不是有很多业余的 API 管理工具吗，我间接用业余的 API 管理工具去保护也是能够的吧。
API 管理工具咱们也是有思考的，然而有如下的问题：
• 很多工具仍然短少自动化的 API 生成；
• 不是专一于解决微服务畛域的问题，随着服务量迅速回升，治理起来仍旧比拟艰难。
3、那微服务框架自身也会有提供相干的接口治理性能吧，Dubbo 能够用 Dubbo Admin，Spring Cloud 能够用 Spring Boot Admin，它们不香吗？
这里篇幅无限，咱们不再去具体讲述开源工具咱们怎么去一步步应用，就用一张表格谈话：
从表格能够看到，EDAS 微服务治理的服务契约，反对版本更宽泛了，配置难度更低了，代码侵入性没有了，间接用 EDAS 的 Agent 计划，它不是更香了？
EDAS 服务契约实际
上面咱们来体验一下，EDAS 上如何查看 Spring Cloud 的微服务契约。
创立利用
依据你的须要，抉择集群类型和利用运行环境，创立 Provider 和 Consumer 利用。
服务查问控制台
1、登录 EDAS 控制台，在页面左上角抉择地区；
2、左侧导航栏抉择：微服务治理 -> Spring Cloud / Dubbo / HSF -> 服务查问；
3、服务查问页面单击某个服务的详情；
查看服务契约
服务详情页面包含根本信息、服务调用关系、接口元数据、元数据等信息。在“接口元数据”一栏，便可查看服务的 API 信息。当用户应用 Swagger 注解时，会在“形容”列显示相应信息。
服务契约实现细节
在设计服务契约性能的时候，咱们岂但解决了开源框架中配置难度大，且局部计划具备代码侵入性的问题，而且针对如下阶段的难点都做了相应的计划，置信这些中央也是微服务框架的使用者会关怀的：
1、数据获取
• 获取的同时是否还须要其余配置？
• 如何获取所需的办法名及形容、参数列表及形容、返回类型等信息？
• 会不会影响服务的性能？
• 信息能不能全面的拿到？
• 能不能同步接口的变更？
2、数据解析
• 能不能看到参数类型 / 返回值类型的具体构造？
• 解析参数构造的时候会不会影响启动工夫？
• 泛型、枚举是否反对？
• 循环援用如何解决？
上面咱们来具体介绍一下这几点都是如何解决的。
数据获取
为了缩小用户的配置和应用难度，咱们采纳了 Agent 计划，用户无需任何额定的代码和配置，就能够应用咱们的微服务治理性能。
Java Agent 是一种字节码加强技术，运行时插入咱们的代码，便可稳固的享受到所有的加强性能。
而且通过测试可得，只有在 SpringMVC 的映射解决阶段，选取适合的拦挡点，就能够获取到所有的办法映射信息，包含办法名、参数列表、返回值类型、注解信息。因为该点在利用启动过程中只产生一次，因而不会有性能的影响。
咱们获取的注解次要是针对 Swagger 注解。作为 OpenAPI 标准的次要指定者，Swagger 虽并非是惟一反对 OpenAPI 的工具，但也根本属于一种事实标准。注解解析的内容在表格的形容局部进行展现：
• Swagger2 的注解解析（如 @ApiOperation，@ApiParam，@ApiImplicitParam），解析 value 值在“形容”列显示；
• OpenAPI3 的注解解析（如 @Operation，@Parameter），解析 description 值在“形容”列显示。
当接口产生变更时，只有将新版本的利用部署下来，显示的服务契约信息就会是最新的，无需放心接口形容信息不能同步的问题。
数据解析
如果参数列表 / 返回值的类型是一个简单类型，个别状况咱们只看到一个类型名。那么有没有方法能够看到这个简单类型的具体形成呢？
聪慧的你可能就会想到，通过反射来递归遍历该类所有的 Field，不就都解决了？思路的确如此，但理论要思考的状况会更简单一些。
以该简单类型 CartItem 为例，它可能岂但会蕴含根本类型，还可能会波及到泛型、枚举，以及存在循环援用的状况。
因而在解析该类型之前，咱们须要先判断一下该类型是否存在泛型、枚举的状况，如果是，须要额定解析并存储泛型列表及枚举列表。
而循环援用问题，咱们只需借助一个 typeCache 即可解决。如下图，A 和 B 形成了一个循环援用。
如果咱们不采取任何措施，递归遍历将永远没有进口。然而，如果咱们在遍历 A 的所有类型之前，先判断一下 typeCache 里是否存在 TypeA。对 TypeB 也以此类推：
那么当遍历 ObjB 中所蕴含类型时，如果遇到了 TypeA，同样也会先判断 typeCache 中是否存在。如存在，就无需再递归遍历 ObjA 中所有的类型了，而是间接记录一个 A 的援用。因而，循环援用问题也就得以解决。
最终的解析信息，能够在服务测试性能中得以体现。将来咱们可能会反对间接在服务查问中的服务契约页，通过一个入口显示简单类型的具体解析构造。
由此咱们看到，在服务契约的获取及解析阶段，波及到的可能影响用户体验的问题都失去了肯定的解决。
不止是服务契约
本文介绍了几种接口形容办法，并且和开源框架的微服务接口治理性能进行比照，引出了 EDAS 服务契约。尽管服务契约看起来只是在管制台上的一个接口信息展现性能，但在将来的倒退中不可或缺，其上报的要害信息能够很大水平的优化服务测试、服务鉴权、标签路由的体验，是微服务治理体系中的根底性能。
EDAS 微服务治理在将来甚至还能够在服务契约的根底上减少更多的加强性能，欢送体验。
除了 EDAS 和 MSE（微服务引擎）这些微服务产品之外，咱们还有 ARMS (利用实时监控服务)、ACM（利用配置管理）、SAE（Serverless 利用引擎）等云产品。欢送退出咱们一起，用心服务客户，独特打造产品，让业务永远在线。