微服务api管理（微服务api版本管理）

本篇文章给大家谈谈微服务api管理，以及微服务api版本管理对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享微服务api管理的知识，其中也会对微服务api版本管理进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、微服务架构设计模式（八）外部API模式
• 2、基于ServiceMesh服务网格的去中心化微服务管控治理平台
• 3、Spring Cloud Zuul微服务网关的API限流
• 4、什么是微服务？

微服务架构设计模式（八）外部API模式

API Gateway是一种服务，它是外部世界进入应用程序的入口点。它负责请求路由、API组合、身份验证等功能。
（1）功能

（2）架构

（3）模式：

（4）API Gateway模式的好处和弊端

（5）API Gateway设计过程面临的问题

（6）开发使用API Gateway的选择

基于ServiceMesh服务网格的去中心化微服务管控治理平台

首先说明下微服务api管理我最近在思考微服务api管理的一个产品规划，即基于ServiceMesh服务网格思路，参考开源的Istio等实现架构来搭建一个完整的微服务治理管控平台。

在前面文章里面我就提到了，在实施微服务架构后，由于微服务将传统的单体应用进行了拆分，颗粒度更细。因此整个集成的复杂度，后续的管控治理复杂度都急剧增加。

当前也出现了类似SpingCLoud主流的微服务开发框架，实现了服务注册和发现，安全，限流熔断，链路监控等各种能力。同时对于服务注册，限流，服务链监控等本身又出现了大量的开源组件，类似服务注册的Nacos，Consul，限流熔断的Sentinel，链接监控的SKyWalking等开源组件。

当我们在思考微服务开发框架和开源组件的时候你会发现。

在SpingCLoud外的各类开源组件本身和微服务开发过程是解耦的，也就是说这些开源组件更加方便地通过配置增加管控能力，或者通过下发一个SDK包或Agent代理组件来实现管控能力。以尽量减少对微服务开发过程的影响。

而对于SpingCLoud微服务框架，在使用中有一个最大的问题就是开发态和治理态的耦合，也就是说一个微服务模块在开发的时候，你会引入很多治理态的内容。类似限流熔断，类似链路监控等能力，都需要你在开发状态增加配置文件，或对接口实现类进行扩展等。

微服务开发本身应该是一个简单的事情。

其核心是实现业务功能和规则逻辑，并暴露轻量的Http Rest API接口实现和前端交互或者实现和其它微服务模块之间的横向交互协同。

也就是说如果不考虑管控治理层面的内容，你采用最小化的SpingBoot来进行微服务开发足够的，或者你仍然可以采用传统的Java架构进行微服务开发，只要确保最终暴露Http API接口即可。

但是如果要考虑治理的内容，你会发现会引入注册中心，限流熔断，安全，服务链监控一系列的管控治理组件，导致整个微服务开发过程，集成过程都复杂化。

因此构建微服务治理平台的初衷即微服务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架构来实现微服务治理管控能力。

Spring Cloud Zuul微服务网关的API限流

微服务开发中有时需要对API做限流保护，防止网络攻击，比如做一个短信验证码API，限制客户端的请求速率能在一定程度上抵御短信轰炸攻击，降低损失。

微服务网关是每个请求的必经入口，非常适合做一些API限流、认证之类的操作，这里有一个基于zuul微服务网关的API限流库：

https://github.com/marcosbarbero/spring-cloud-zuul-ratelimit

比如我们要对 user-service 这个服务进行限流，限制每个请求源每分钟最多只能请求10次。

首先在项目中添加 spring-cloud-zuul-ratelimit 依赖：

然后再添加如下配置即可：

对API限流是基于Zuul过滤器完成的，默认情况下限流数据是记录在内存中的，实际上是用ConcurrentHashMap保存，当然也提供了多种存储方式，包括Redis、Consul、Spring Data JPA，使用这三种存储方式要添加相关依赖。

然后再添加存储配置，比如使用Redis的配置：

限流过滤器是在请求被转发之前调用的

限流类型主要包括url、origin、user三种

在过滤器的run方法中判断请求剩余次数，小于0就拦截请求：

可以看到，单位时间内剩余请求次数小于0时抛出ZuulRuntimeException，直接返回客户端TOO_MANY_REQUESTS异常消息，达到拦截请求的效果。

https://github.com/yunTerry/spring-cloud-netflix

什么是微服务？

微服务架构是一种软件设计方法，它将应用程序分解为通过定义明确的 API 进行通信的小型独立服务。由于每个服务都可以由自治团队开发和维护，因此它是最具可扩展性的软件开发方法。

微服务设计与单体开发截然相反。单体是一个实现所有功能的大型代码库（“厨房水槽”）。一切都在一个地方，没有一个组件可以孤立地工作。这意味着应用程序必须作为一个整体进行测试。

从好的方面来说，单体应用很容易启动和运行。由于单体架构不同部分之间的关系是透明的，因此进行广泛的更改很容易。

然而，随着公司的发展和团队规模的扩大，单体开发变得更加困难。很快，系统就不能再装在一个头上了——移动部件太多了，所以事情变慢了。

微服务使公司能够保持团队规模小而敏捷。这个想法是将应用程序分解为可以由紧密结合的团队自主开发和部署的小型服务。

公司采用微服务的主要原因是 可扩展性 。服务可以独立开发和发布，无需在组织内安排大规模的协调工作。

拥有分布式系统的一个好处是能够避免单个故障点。您可以使用支持云的技术在不同的可用区部署微服务，确保您的用户永远不会遇到中断。

使用微服务，开发团队可以保持小而有凝聚力。小组越小，沟通开销越少，协作越好。

亚马逊通过他们的两个披萨团队将团队规模发挥到了极致。这意味着一个团队应该足够小，可以吃两个比萨饼。

对于单体应用，语言和技术堆栈选项几乎从一开始就设置好了。新开发人员必须适应过去做出的任何选择。

相比之下，每个微服务都可以使用最适合解决手头任务的技术堆栈。因此，团队可以为工作和他们的技能选择最佳工具。例如，您可以使用 Go 或 C 实现高性能服务，并使用 Erlang 或 Elixir 实现高容错微服务。

随着小团队迭代速度更快，开发和测试周期更短。而且，由于他们还可以随时部署更新，微服务的部署频率比单体应用要高得多。

有这么多好处，似乎为新项目选择微服务是一件轻而易举的事。但是微服务设计也带来了一些严峻的挑战：

你怎么知道你是否在做正确的微服务设计？如果您的团队可以在不与其他团队协调的情况下随时部署更新，并且如果其他团队可以类似地部署他们的更改而不影响您，那么恭喜您，您掌握了微服务的诀窍。

失去微服务提供的好处的最可靠方法是不遵守解耦规则。如果我们仔细观察，我们会发现微服务都是关于自治的。当这种自主权丧失时，团队必须在开发和部署期间进行协调。需要完美的集成测试来确保所有微服务协同工作。

即便如此，详尽的测试也无法捕捉到所有问题。当出现问题时，耦合服务是很难调试的。当问题被发现时，修复它并不总是像回滚更新那么容易。

紧密的服务依赖关系创建团队依赖关系。

这些都是分布式计算带来的问题。如果您曾经使用过云服务，您就会知道将服务或机器分布在多个地理位置与在同一站点上运行所有内容不同。分布式系统具有更高的延迟，可能存在同步问题，并且更难管理和调试。这种高度耦合的服务架构实际上是一个 分布式单体 架构，具有两全其美的优点，也没有微服务应该带来的任何好处。

如果您在不与其他团队协调或依赖其他微服务的特定版本来部署您的微服务的情况下无法进行部署，那么您只是在分发您的单体应用。

微服务并没有 取代 单体。两者都是有效的方法。事实上，当团队仍在 探索 他们正在构建的东西时，单体应用可能是最佳选择。

单体应用就像是项目的自然起点，因为它易于开发、快速迭代、快速部署、易于调试，并且更能容忍设计错误。在可扩展性成为问题之前，单体应用可以让您走得更远。

微服务是我们开发软件的最具可扩展性的方式。但它们不是免费的午餐。如果您不小心，它们会带来一些很容易发生冲突的风险。当团队正在成长并且您需要保持快速和敏捷时，它们非常有用。但是你需要对要解决的问题有一个很好的理解，否则你最终会得到一个分布式的单体。

关于微服务api管理和微服务api版本管理的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 微服务api管理的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于微服务api版本管理、微服务api管理的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。