多平台统一管理软件接口,如何实现多平台统一管理软件接口
738
2023-03-10
本文目录一览:
作为一个前后端分离模式开发的团队,我们经常会看到这样的场景:前端开发和后端开发在一起热烈的讨论“你这接口参数怎么又变了?”,“接口怎么又不通了?”,“稍等,我调试下”,“你再试试..."。
那能不能写好接口文档,大家都按文档来开发?很难,因为写文档、维护文档比较麻烦,而且费时,还会经常出现 API 更新了,但文档还是旧的,各种同步不一致的情况,从而耽搁彼此的时间。
之前我们团队也遇到了同样的问题,那么作为研发团队的负责人,我是如何带领团队解决这个问题的呢?
方法其实很简单,如果能做到让写文档/维护文档这件事情的短期收益就能远高于付出的成本,那么所有问题都能迎刃而解,开发人员就会非常乐意去写接口文档。
要做到写文档和及时维护文档的短期收益就能远高于付出的成本,无非两个方向:
鉴于此,我们设想如果有一款工具做到以下这些是不是就非常爽了?
总结下来,我们需要的就是这么一款工具:
为此,我们几乎尝遍了市面上所有相关的工具,但是很遗憾,没有找到合适的。
于是,我们自己实现了一个Postman + Swagger + RAP + JMeter
这个工具就是 Apifox,经常很长一段时间不断更新迭代后,我们基本上完全实现了最初的设想,几乎完美解决了最开始遇到的所有问题,在公司内部大受欢迎。并且也形成了我们自己的最佳实践。
没错,现在我们已经将Apifox产品化对外服务了,你们团队也可以直接使用Apifox了。
官网:www.apifox.cn
Apifox = Postman + Swagger + Mock + JMeter
Apifox 是 API 文档、API 调试、API Mock、API 自动化测试一体化协作平台。
通过一套系统、一份数据,解决多个系统之间的数据同步问题。只要定义好接口文档,接口调试、数据 Mock、接口测试就可以直接使用,无需再次定义;接口文档和接口开发调试使用同一个工具,接口调试完成后即可保证和接口文档定义完全一致。高效、及时、准确!
节省研发团队的每一分钟!
如果你认为 Apifox 只做了数据打通,来提升研发团队的效率,那就错了。Apifox 还做了非常多的创新,来提升开发人员的效率。
通常一个接口会有多种情况用例,比如 正确用例 参数错误用例 数据为空用例 不同数据状态用例。定义接口的时候定义好这些不同状态的用例,接口调试的时候直接运行,非常高效。
可以独立定义数据模型,接口定义时可以直接引用数据模型,数据模型之间也可以相互引用。同样的数据结构,只需要定义一次即可多处使用;修改的时候只需要修改一处,多处实时更新,避免不一致。
使用 Apifox 调试接口的时候,系统会根据接口文档里的定义,自动校验返回的数据结构是否正确,无需通过肉眼识别,也无需手动写断言脚本检测,非常高效!
Apifox 自动校验数据结构
设置断言:
Apifox 设置断言
运行后,查看断言结果:
先放一张图对比下 Apifox 和其他同类工具 零配置 mock 出来的数据效果:
Apifox Mock 数据结果对比同类工具
可以看出 Apifox 零配置 Mock 出来的数据和真实情况是非常接近的,前端开发可以直接使用,而无需再手动写 mock 规则。
「Apifox 如何做到高效率、零配置生成非常人性化的 mock 数据」
Apifox 项目可“在线分享” API 文档,分享出去的 API 文档可设置为公开或需要密码访问,非常方便与外部团队协作。
体验地址:https://www.apipark.cn/s/ce387612-cfdb-478a-b604-b96d1dbc511b/http/5041285
根据接口模型定义,自动生成各种语言/框架(如 TypeScript、Java、Go、Swift、ObjectiveC、Kotlin、Dart、C++、C#、Rust 等)的业务代码(如 Model、Controller、单元测试代码等)和接口请求代码。目前 Apifox 支持 130 种语言及框架的代码自动生成。
更重要的是:你可以通过自定义代码模板来生成符合自己团队的架构规范的代码,满足各种个性化的需求。
接口调试
Apifox 多种主题色可选
随着 Web 技术的发展,前后端分离构架变的越来越流行。前后端分离使后端专注于数据处理和定义前端所需要的接口,前端负责数据的展现和交互,大大细化了开发者的职责,提高了开发效率,但与此同时也带来了一些问题:
对于前端工程师,后端提供的接口文档,大多是不规范的,有使用 wiki 的,有 word 文档的,甚至还有用即时聊天软件沟通的,后端接口对于前端就像一个黑盒子,经常遇到问题是接口因未知原因增加参数了,参数名变了,参数被删除了。对于后端工程师,接口对接时总是需要写冗杂繁琐的文档,需要大量时间去维护接口文档。
前端开发的功能在后端功能还没完成前,因为前端的功能依赖于后端的数据,导致工作无法顺利展开。为了解决这个问题,有些前端工程师在代码注入 json,还有后端工程师临时搭建一套测试数据服务器,这种情况下势必会影响工作效率和代码质量,也不能及时进行字段的更新。
接口数据正确性无法得到保证。前端调用后端的接口数据渲染到 视图,数据一旦出错,将会导致视图和交互也出现问题,保证后端接口数据正确性变的愈来愈重要。接口自动化测试就是用来解决这个问题,但传统的接口测试框架使用成本很高,很多团队采用肉眼比对方式,效率很低。
相关产品调研
我们迫切希望有一款产品能够满足我们的诉求,于是开始寻找市面上类似产品,经过一段时间的分析,最终我们找到了几个比较有代表性的产品 Rap,Nei,Easy-Mock。同时我们按照自己的诉求列出了一些关键的特征:
Nei 是网易前端事业部的产品,在这些产品中算是做得比较好的, nei 是专注做 saas 服务这块,没有开源版本。对于去哪儿内部,肯定不会把公司机密的接口数据放到第三方平台。
Rap 是阿里妈妈 MUX 团队2013年出的一款产品,从时间上看是同类产品中最早的。Rap 是后端工程师基于 java 开发的,如果想定制部分功能,还需要学习 java,而我们部门大家对 java 都不熟悉。另一方面 Rap 没有接口测试功能,而后端使用其他工具(postman, restlet)测试接口,将导致不能及时更新接口文档。
Easy-mock 是大搜车无线团队出的一款产品,Easy-mock 定位是接口数据的模拟,解决前端依赖后端接口数据的问题,在同类产品中 mock 服务做得比较好。Easy-mock 专注于前端数据的模拟,但无法解决去哪儿现有的问题。
Nei,Rap 接口管理平台共同存在的问题是不易维护接口返回数据。笔者曾跟一个使用过 Rap 的后端工程师聊过,他说每次定义后端接口返回数据字段,好几个百个字段需要更新很长时间。Nei,Rap 是基于维护一个 json-schema 方式定义后端返回数据结构,我们假设某个接口有100个字段,如果基于 json-shema 那么就要维护差不多 600 多左右字段的更新。这么大工作量的,很可能导致后端工程师根本没有动力去维护。
比较遗憾的是,这几款优秀的产品,都缺失了一些我们在意的关键特征。我们可能需要做比较大的改动才能够基本满足自己的需求,这个工作量很有可能会超过重新开发一次。所以我们开始自主研发一个全新的接口管理平台,我们希望它能够提供接口文档管理,接口数据模拟(Mock),接口调试,自动化测试等功能,让前后端接口相关的工作进行的更加高效。这就是 YApi 接口管理平台斐然由来,下面简要聊聊 YApi 是如何实现上述这些特征的。
YApi 解决方案
1. 共同维护一份接口定义,连接前后端
大家看下图,在后端开发接口过程中,接口开发和测试接口这是必不可少的环节,但文档因为没有跟接口开发和测试联系到一起,被孤立。后端要维护对于他们冗杂繁琐的文档,是件收益很低的事情。没有人喜欢做收益低的事情,所以最终的解决办法就是要提高收益。下面详细说明解决方案。
在接口开发过程中,后端通常都会使用 postman 等类似的工具测试接口,而测试接口是在开发过程中一个必要的过程。假如参数有改动,大家肯定会在 postman 等工具上更新字段和测试接口。由此可以联想到, 如果能有一款工具既可用来做测试接口,又能作为接口文档工具,将接口文档和接口测试连接到一起,不就解决了此问题。YApi 解决方案是将接口文档和测试通过单一数据源连接到一起,如果有改动,因为改的是单一的数据源,就不会出现更新滞后和不及时问题。
2. 前端 Mock Server 方案
数据 Mock 服务在开发前期是非常头疼的一个问题。大多数情况下,接口请求参数和返回数据都是后端规定的,在后端接口没有完成之前,接口对于前端就是一个黑洞,可能最初对接口的定义跟实际后端做出的接口会有非常大的不同。这个时候就需要有一个工具,不仅能模拟真实接口的情况,还能关联接口文档,在后端开发过程中,可以随时调整接口定义,并通知给前端开发者改动信息。
在 YApi 平台,前后端只要维护接口定义的响应数据,就可以生成需要的模拟数据,下面这段代码定义了生成数据模板:
{
"errcode": 0,
"errmsg": "@string",
"data": {
"type":"@pick(1,2,3)",
"list|1-10": [{
"uid": "@id",
"username": "@name"
}]
}
}
{
"errcode": 0,
"errmsg": "^*!SF)R",
"data": {
"type": 2,
"list": [
{
"uid": "370000200707276255",
"username": "Ruth Clark"
},
{
"uid": "650000200211185728",
"username": "Anthony Martin"
},
{
"uid": "370000199201143855",
"username": "Laura Rodriguez"
},
{
"uid": "610000198704072775",
"username": "Anthony Perez"
}
]
}
}
基础的 Mock 工具已经能满足大部分的需求了,但有些复杂场景是无法实现的。例如:当我做一个数据列表页面,需要测试某个字段在各种长度下的 ui 表现,还有当数据为空时的 ui 表现。YApi 提供了期望和自定义脚本的功能。 本文主要介绍自定义脚本功能,期望功能可参考 yapi 平台文档。
自定义脚本可根据请求的参数,cookie 信息,使用 js 脚本自定义返回的数据。我们假设有个场景,我希望通过 cookie "_type" 控制列表页面数据显示,假设 _type 是 error,那么列表显示异常错误信息;假设 _type 是 empty ,列表显示为空。可使用下面代码实现:
if(cookie._type == 'error'){3.自动化测试
接口开发完成后,后续的迭代是非常多的,每次对源码的修改,都需要大量的测试才能确保接口是否正确。人工判断肯定是不好的,最好的办法是做成自动化,但自动化测试又是一件成本非常高的事情,需要后端人员和QA人员学习相关的框架,和写大量的代码。YApi 简化了这一个过程,基于一个可视化界面,就算不懂程序开发,只需配置相关的参数和断言语句,就能实现自动化测试,非常的易用。
除了基本的功能外,YApi 还提供了强大的 pre-script 和可视化表达式功能,pre-script 包括请求参数处理脚本和响应数据处理脚本两部分。通过自定义 js 脚本方式改变请求的参数和返回的 response 数据。他的使用场景如下:
接口请求参数需要加密及返回 response 解密
接口请求参数需要添加计算 token
可视化表达主要是为了方便用户生成自动化测试所用到的参数,通过一个树形选择性,快速引用所依赖的参数值。 在所有的需要测试的接口配置完成后,点击开始测试,就会按照指定的顺序依次测试所有接口,测试完成后,可查看测试报告。
4.插件机制
YApi 最强大的一点莫过于他的插件机制,我们去哪儿各个业务线有不同的需求,通过 YApi 预留的钩子,开发不同的插件解决,比如我们现有的 qsso 登录,swagger 数据导入就是通过插件机制实现的,我们团队最近还在跟业务部门讨论使用插件实现压力测试功能等。总得来说,YApi基于插件机制,既满足了产品需求的多样性,又保证了内核足够易用和简洁。
5. 开源和易部署
为了帮助更多开发者和提升大家的工作效率,YApi 不仅开源到 github,还提供了一个 cli 工具方便广大开发者部署。使用 yapi-cli 提供的可视化部署方案,即便你不懂任何 nodejs、mongodb 的知识,也能轻松一键部署。
后记
YApi 已在去哪儿大面积使用,对 200+ 项目接口进行管理,每周有上万次 mock 请求。在开源以后,越来越多的公司和团队使用 YApi, github star 数已经上升到 1.3k了。YApi 在未来还将继续专注于接口管理方面的功能,让 YApi 成为各位开发者的好帮手。
首先说明下我最近在思考的一个产品规划,即基于ServiceMesh服务网格思路,参考开源的Istio等实现架构来搭建一个完整的微服务治理管控平台。
在前面文章里面我就提到了,在实施微服务架构后,由于微服务将传统的单体应用进行了拆分,颗粒度更细。因此整个集成的复杂度,后续的管控治理复杂度都急剧增加。
当前也出现了类似SpingCLoud主流的微服务开发框架,实现了服务注册和发现,安全,限流熔断,链路监控等各种能力。同时对于服务注册,限流,服务链监控等本身又出现了大量的开源组件,类似服务注册的Nacos,Consul,限流熔断的Sentinel,链接监控的SKyWalking等开源组件。
当我们在思考微服务开发框架和开源组件的时候你会发现。
在SpingCLoud外的各类开源组件本身和微服务开发过程是解耦的,也就是说这些开源组件更加方便地通过配置增加管控能力,或者通过下发一个SDK包或Agent代理组件来实现管控能力。以尽量减少对微服务开发过程的影响。
而对于SpingCLoud微服务框架,在使用中有一个最大的问题就是开发态和治理态的耦合,也就是说一个微服务模块在开发的时候,你会引入很多治理态的内容。类似限流熔断,类似链路监控等能力,都需要你在开发状态增加配置文件,或对接口实现类进行扩展等。
微服务开发本身应该是一个简单的事情。
其核心是实现业务功能和规则逻辑,并暴露轻量的Http Rest API接口实现和前端交互或者实现和其它微服务模块之间的横向交互协同。
也就是说如果不考虑管控治理层面的内容,你采用最小化的SpingBoot来进行微服务开发足够的,或者你仍然可以采用传统的Java架构进行微服务开发,只要确保最终暴露Http API接口即可。
但是如果要考虑治理的内容,你会发现会引入注册中心,限流熔断,安全,服务链监控一系列的管控治理组件,导致整个微服务开发过程,集成过程都复杂化。
因此构建微服务治理平台的初衷即:
在这里还是先简单梳理下业务需求和业务功能场景。
01 服务注册和服务发现
仍然需要实现最基本的当前微服务自注册,自发现能力。这个在开发阶段需要暴露的接口增加注解还是必须的。在ServiceMesh下,由于存在本地Sidecar代理,因此在本地代理和微服务一起容器化部署下去后,会扫描微服务中需要暴露的接口,并完成微服务和API接口服务的注册工作。 也就是传统的应用开发集成中,手工接口API接口服务注册和接入的过程没有了,这个过程应该彻底地自动化掉。
注意这里的注册不仅仅是到微服务粒度,而是可以到微服务API接口粒度。
因此我们需要实现在微服务部署和交付后,微服务注册和微服务中的API接口注册全部自动完成。在微服务集群扩展的时候,相关的注册信息和配置信息也自动更新和扩展。
一个微服务模块在部署和交付后。
进入到微服务治理平台就能够看到当前有哪些微服务已经注册,进入到单个微服务里面,就可以看到当前微服务究竟有哪些细粒度的API接口已经注册。
02 服务安全和双重管理
对于一个微服务暴露的API接口,可以看到部分API接口仅仅是提供给前端微服务使用,但是部分API接口是需要提供给其它横向的微服务模块使用。
一个是前端调用后端API接口,一个是后端各个微服务中心间接口交互。
在安全管理的时候实际需要对这两类API接口分别进行管理。如果仅仅是前端功能使用,那么类似JWT+Token的安全措施即可,同时对于的日志流量并不一定需要完全记录和入库。如果是横向微服务间调用,那么安全要求更高,需要支持Token,用户名密码,IP地址验证等多种安全管控要求。
对于前后端的使用,往往仅授权到微服务层级即可。但是对于横向微服务间调用,那么服务授权必须到API接口服务粒度, 能够针对单个微服务API接口独立授权和管理。
03 服务限流熔断
同样这个功能不应该在微服务开发阶段进行任何配置或代码文件的增加。
在微服务成功的部署和交付上线后,应该能够针对微服务,微服务API接口两个不同的颗粒度进行服务限流设置。当然需要支持类似并发量,时长,错误数,数据量等多种限流熔断策略。
比如一个微服务单点能够支撑的最大并发量是1000TPS,那么这就是最基本的限流条件。我只需要设置单点能量,而不是设置集群能力。管控治理平台要管理的是通过负载均衡分发后到单个节点的流量能够控制到1000TPS。如果你部署了5个微服务节点,那么实际能够支撑的最大流量就是5000TPS。
由于采用Mesh去中心化的架构模式,因此实际微服务间的调用数据流量并不会通过微服务治理平台,微服务治理平台本身并没有太大的性能负荷压力。这个是和传统的ESB或API网关不同的地方,即API网关的限流一方面是保护API网关本身,一个是保护下游的微服务模块。
04 接口调用日志记录
注意这个功能本身也是可以灵活配置的,可以配置单个微服务,也可以配置单个API接口服务是否记录日志,包括日志记录是只记录调用时间和状态,还是需要记录想的接口调用消息报文数据。
在去中心化架构模式下,接口调用日志记录相对来说很容易实现。
即通过Sidecar边车首先对消息和数据流量进行拦截,任何将拦截的数据统一推送到消息中间件,消息中间件再将日志信息存入到分布式文件存储或对象存储中。
对于接口调用日志本身应该区分日志头信息和消息日志信息,对于日志头调用记录信息应该还需要推送到类似ELK组件中,以方便进行关键日志的审计和问题排查。
05 服务链路跟踪和监控
注意,在传统的服务链跟踪中,需要在微服务端配置Agent代理。而采用Mesh化解决方案后,该部分代理能力也移动到了Sidecar边车代理中实现。
服务链路监控不仅仅是微服务和API接口间的调用链路,也包括融入常规APM应用性能监控的能力,能够实现前端界面操作后发起的整个应用链路监控。
应用链路监控一方面是进行日志和错误分析,一方面是进行性能问题排查和优化。
06 和DevOps和容器云的集成
简单来说就是开发人员只需要按照标准规范开发单个微服务模块,然后走DevOps持续集成和交付过程进行部署。
在和DevOps平台进行集成后,DevOps在进行自动化部署前会下发Sidecar代理边车,实现对微服务本身的流量拦截和各种管控治理能力。在整个过程中Sidecar对开发者不可见,满足最基本的服务透明要求。
在通过DevOps部署到容器云平台后,满足基于资源调度策略进行后续微服务集群资源的自动化动态扩展能力。同时微服务在扩展后自动进行相应的集群注册,微服务API接口注册等操作。
在传统的SpingCLoud开发框架中,本身注册中心包括了对微服务模块的心跳检查和节点状态监控能力。在和Kurbernetes集群集成和融合后,完全可以采用Kurbernetes集群本身的心跳监控能力。
简单总结
最后总结下,整个微服务治理平台基于ServiceMesh去中心化架构思路来定制,但是需要实现类似传统ESB总线或API网关的所有管控治理能力。
对于最终的使用者来说并不关心治理能力实现是否是去中心化架构,而更加关心两个点。第一个点是开发阶段不要引入治理要求,第二就是能够实现核心能力的集中化管控和可灵活配置扩展。
也就是你可能上层看到的是一个传统的SOA治理管控平台,但是底层却是采用了去中心化的ServiceMesh架构来实现微服务治理管控能力。
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。
发表评论
暂时没有评论,来抢沙发吧~