管理平台接口文档,优化业务流程的灵魂之匙
373
2023-02-15
本文目录一览:
在App开发过程中少不了跟服务端打交道,各种HTTP接口调试、返回数据处理占据了不少开发时间,一款好的接口管理工具就非常有必要了。接口管理工具一方面起到链接后台开发人员和App开发人员的作用,另一方面也可以作为传统的接口文档使用,且比文档的实时性更强。
因为各个团队的情况不太一样,可能对接口管理有不一样的需求,目前有不少接口管理工具,足以覆盖不同团队的需求,下面来简单介绍一下。
1. YApi
https://github.com/YMFE/yapi
YApi是由去哪网前端团队开源的一款接口管理工具,功能强大,可以轻松的自己部署。而且支持使用docker部署,使用成本很低了。
使用docker部署可以参考这篇文章: https://www.jianshu.com/p/a97d2efb23c5
2. Rap2
https://github.com/thx/rap2-delos
Rap2是由阿里妈妈前端团队开源的一款接口管理工具,相对YApi来说,至少文档上面差一些,Github上没有太多介绍,也没提及用docker部署,但也是一个选择吧。
3. eolinker
https://www.eolinker.com/
eolinker是一个接口管理服务网站,如果不想自己部署YApi、Rap2的团队可以使用,免费版的功能对于小型团队来说足够了。
4. Postman
https://www.getpostman.com/
跨平台的管理工具,可以免费使用,支持mock,支持团队协作,免费版本的限制主要在于每个月1000次的限制,包括Mock请求、API请求等等,对于小型团队(3~5人)应该是足够了。
5. Paw
https://paw.cloud/
仅支持Mac平台,可以试用30天,正式版要49.99美元,不是特别推荐使用,毕竟不能跨平台。
以上几个都能满足我们对于接口管理的需求,综合来看,多数团队可以直接使用eolinker提供的服务,Postman也可以,但是考虑到国内的网络情况并不推荐。对于有一定技术实力的团队可以使用YApi、Rap2,自己部署,甚至二次开发满足团队需求。
首先说明下api接口链路管理平台我最近在思考api接口链路管理平台的一个产品规划api接口链路管理平台,即基于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小时内删除侵权内容。
发表评论
暂时没有评论,来抢沙发吧~