
如果大家了解网络构成的话,对于网关应该就不会陌生了,今天我们就一起来了解一下,API网关的一些基础知识,希望对大家以后的服务器开发工作有所帮助,下面就开始今天的主要内容吧。
一、API网关产生背景
在微服务的架构中,一个大的应用会被拆分成多个小的单一的服务提供出来,这些小的服务有自己的处理,有自己的数据库(也可以共用),也许语言也是不一样的,他们可以部署在一个或多个服务器上,其实也就是对复杂的应用进行了解耦,那为什么微服务需要API网关呢
我们看看微服务后产生的问题:
客户端需要知道多个服务地址
通用的功能怎么处理例如鉴权、流量控制、日志等
以前一个功能可能是一次请求就可以完成,现在可能要多个服务一起进行才可以,那如何减少客户端请求的时间呢
由于以上几点的问题,所以在所有的服务前面还需要定义一个代理,即API网关,所有的客户端请求都必须经过API网关代理到真实的服务地址,这也可以有效的避免真实地址的暴露,同时API网关也可以集成鉴权、流量控制、日志、API聚合、黑白名单等。
二、kong的介绍
Kong是由Mashape开发的并且于2015年开源的一款API网关框架,基于nginx以及OpenResty研发,主要特点是高性能以及其强大的扩展性,由于本身是基于nginx进行开发,因此网上很多关于nginx的调优等资料都可以用到kong的上面,包括负载均衡、或者充当web服务器等
kong的扩展是通过插件机制进行的,并且也提供了插件的定制示例方法,插件定义了一个请求从进入到反馈到客户端的整个生命周期,所以电脑培训认为可以满足大部分的定制需求,本身kong也已经集成了相当多的插件,包括CORS跨域、logging、限流、转发、健康检查、熔断等,API聚合功能从github上看也已经进入开发阶段。
Syslog已被许多日志函数采纳,它用在许多保护措施中——任何程序都可以通过syslog 纪录事件。Syslog可以纪录系统事件,可以写到一个文件或设备中,或给用户发送一个信息。它能纪录本地事件或通过网络纪录另一个主机上的事件。api接口个syslog那个好。
Unix/Linux系统中的大部分日志都是通过一种叫做syslog的机制产生和维护的。syslog是一种标准的协议,分为客户端和服务器端,客户端是产生日志消息的一方,而服务器端负责接收客户端发送来的日志消息,并做出保存到特定的日志文件中或者其他方式的处理。
都不要说微服务架构,就是单体应用架构中,API服务也是需要治理的。
首先是API接口文档的问题,这一点经常会被大家忽视,相信很多公司还在写接口文档,项目开始的时候还好,但是随着项目的发展,如果接口有改动,但是文档更新的不是那么及时甚至是不更新,那么这会加重团队之间沟通的成本。
虽然我们可以通过管理流程强制大家写文档,但是再怎么说,代码和文档是要修改两次的,难免会有疏漏。所以可以考虑使用一些框架或插件,自动地根据代码生成文档,这样开发人员只修改代码就好了,文档始终会和代码保持一致(当然开发人员还是要修改代码和Annotation,但是它们毕竟是在一起的)。
第二就是API接口测试的问题了,新开发一个接口很简单,难的是修改一个接口功能的时候,如何保证之前功能的正确性和稳定性;而对于接口调用方来说,同样需要确保自身依赖接口的正确性,因为用户是不会区别是你们系统的问题还是你们依赖系统的问题。我们是依靠单元测试覆盖率的统计和每天定时跑所有系统单元测试用例的方式,来提高各个系统的可用性(虽然这只是一种管理手段,单元测试用例覆盖率也很容易造假,但正是“防君子不防小人”)。
监控和缺陷追踪,如果是在分布式架构下,就是调用链路的管理;以往的系统,更多的是A系统调用B系统,而现在可能面对这A->B->C->D,而在这种情况下,如果没有链路跟踪的方案,那么查找和定位问题就会非常困难;这时候可以使用Sleuth来做服务之间调用提供链路追踪;使用Sleuth的时候,也可以和zipkin做集成,将搜集到的信息发送到zipkin,利用zipkin进行数据的存储和展示。
个人经验,新项目怎么都好说,老项目的改造是老大难,这种时候,可以考虑引入日志平台吧,对各个系统的API日志进行主动抓取,然后在日志平台里面加工展示。
我将持续分享Java开发、架构设计、程序员职业发展等方面的见解,希望能得到你的关注。
欢迎分享,转载请注明来源:内存溢出
微信扫一扫
支付宝扫一扫
评论列表(0条)