微服务网关组件对比（微服务网关技术选型）

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

本文目录一览：

• 1、微服务核心组件 Zuul 网关原理剖析
• 2、微服务架构中涉及的常见组件的名称以及作用
• 3、微服务架构系列之–最全配置中心对比（面试随便装）
• 4、微服务架构中的组件有哪些？

微服务核心组件 Zuul 网关原理剖析

Zuul 网关是具体核心业务服务的看门神，相比具体实现业务的系统服务来说它是一个边缘服务，主要提供动态路由，监控，弹性，安全性等功能。在分布式的微服务系统中，系统被拆为了多套系统，通过zuul网关来对用户的请求进行路由，转发到具体的后台服务系统中。

本 Chat 主要内容如下：

网关是具体核心业务服务的看门神，相比具体实现业务的系统服务来说它是一个边缘服务，主要提供动态路由，监控，弹性，安全性等功能，下面我们从单体应用到多体应用的演化过程来讲解网关的演化历程。

一般业务系统发展历程都是基本相似的，从单体应用到多应用，从本地调用到远程调用。对应单体应用架构模式（如下图1），由于只需一个应用，所有业务模块的功能都打包为了一个 War 包进行部署，这样可以减少机器资源和部署的繁琐。

图1 单体应用

在单体应用中，网关模块是和应用部署到同一个jvm进程里面的，当外部移动设备或者web站点访问单体应用的功能时候，请求是先被应用的网关模块拦截的，网关模块对请求进行鉴权、限流等动作后在把具体的请求转发到当前应用对应的模块进行处理。

随着业务的发展，网站的流量会越来越大，在单体应用中简单的通过加机器的方式可以带来的承受流量冲击的能力也越来越低，这时候就会考虑根据业务将单体应用拆成若干个功能独立的应用，单体应用拆为多个应用后，由于不同的应用开发对应的功能，所以多应用开发之间可以独立开发而不用去理解对方的业务，另外不同的应用模块只承受对应业务流量的压力，不会对其他应用模块造成影响，这时候多体的分布式系统就出现了，如下图2。

图2 多体应用

如上图在多体应用中业务模块A和B单独起了个应用，每个应用里面有自己的网关模块，如果业务模块多了，那么每个应用都有自己的网关模块，这样复用性不好，所以可以考虑把网关模块提起出来，单独作为一个应用来做服务路由，如下图3：

如上图当移动设备发起请求时候是具体发送到网关应用的，经过鉴权后请求会被转发到具体的后端服务应用上，对应前端移动设备来说他们不在乎也不知道后端服务器应用是一个还是多个，他们只能感知到网关应用的存在。

Zuul是Netflix开源的一个网关组件，在Netflix内部系统中Zuul被用来作为内部系统的门面，如下图是Zuul在Netflix内部使用的一个架构图：

如上图最上层的移动设备或者网站首先通过aws负载均衡器把请求路由到zuul网关上，zuul网关则负责把请求路由到具体的后端service上。

Zuul开源地址 https://github.com/Netflix/zuul

Zuul网关的核心是一系列的过滤器，这些过滤器可以对请求或者响应结果做一系列过滤，Zuul 提供了一个框架可以支持动态加载，编译，运行这些过滤器，这些过滤器是使用责任链方式顺序对请求或者响应结果进行处理的，这些过滤器直接不会直接进行通信，但是通过责任链传递的RequestContext参数可以共享一些东西。

虽然Zuul 支持任何可以在jvm上跑的语言，但是目前zuul的过滤器只能使用Groovy脚本来编写。编写好的过滤器脚本一般放在zuul服务器的固定目录，zuul服务器会开启一个线程定时去轮询被修改或者新增的过滤器，然后动态进行编译，加载到内存，然后等后续有请求进来，新增或者修改后的过滤器就会生效了。

在zuul中过滤器分为四种：

如下图为zuul1.0的工作原理：

如上图，当zuul接受到请求后，首先会由前置过滤器进行处理，然后在由路由过滤器具体把请求转发到后端应用，然后在执行后置过滤器把执行结果写会到请求方，当上面任何一个类型过滤器执行出错时候执行该过滤器。

本节作者使用zuul的版本：

...

....

总结：zuul1.0时候当zuul接受到一个请求后会同步执行前置过滤器、路由过滤器、后置过滤器，等执行完毕后在同步把结果返回为调用方，调用方在整个过程中是阻塞的。其实SpringBoot集成的zuul就是自己实现了个前置过滤器做选择路由，然后自己实现了个路由过滤器根据前置过滤器选择的路由具体做路由转发。

Netty作为高性能异步网络通讯框架，在dubbo，rocketmq,sofa等知名开源框架中都有使用，如下图zuul2.0使用netty server作为网关监听服务器监听客户端发来的请求，然后把请求转发到前置过滤器（inbound filters）进行处理，处理完毕后在把请求使用netty client代理到具体的后端服务器进行处理，处理完毕后在把结果交给后者过滤器（outbound filters）进行处理，然后把处理结果通过nettyServer写回客户端。

...
总: 在zuul1.0时候客户端发起的请求后需要同步等待zuul网关返回，zuul网关这边对每个请求会分派一个线程来进行处理，这会导致并发请求数量有限。而zuul2.0使用netty作为异步通讯，可以大大加大并发请求量。

微服务架构中涉及的常见组件的名称以及作用

微服务架构中涉及微服务网关组件对比的常见组件的名称以及作用

微服务架构中涉及的常见组件有哪些?下面我们一起来聊聊微服务架构中涉及的一些常见组件名称以及作用。

服务注册中心微服务网关组件对比：注册系统中所有服务的地方。

服务注册：服务提供方将自己调用地址注册到服务注册中心微服务网关组件对比，让服务调用方能够方便地找到自己。

服务发现：服务调用方从服务注册中心找到自己需要调用服务的地址。

负载均衡：服务提供方一般以多实例的形式提供服务，使用负载均衡能够让服务调用方连接到合适的服务节点。

服务容错：通过断路器(也称熔断器)等一系列的服务保护机制，保证服务调用者在调用异常服务时快速地返回结果，避免大量的同步等待。
服务网关：也称为API网关，是服务调用的唯一入口，可以在这个组件中实现用户鉴权、动态路由、灰度发布、负载限流等功能。

分布式配置中心：将本地化的配置信息(properties、yml、yaml

等)注册到配置中心，实现程序包在开发、测试、生产环境的无差别性，方便程序包的迁移。

除此之外，读者在学习时，可能还会在一些参考资料中看到服务的健康检查、日志处理等组件内容。以上我们介绍微服务网关组件对比了微服务架构中涉及的一些常见组件名称以及作用

哪些公司适合使用微服务架构?

对于一般的公司来说，微服务的实践有着很大的技术挑战，所以并不是所有的公司都适合将整体架构拆分成微服务架构。一般来说，微服务架构更适合于未来具有一定扩展复杂度、具有大量增量用户期望的应用，比如一些新兴的互联网公司应用。这些公司不可能在业务初期购买大量或昂贵的机器，但他们也必须考虑在成功后应对庞大的用户数量。此时，微服务架构已成为最佳选择。此外，对于那些规模大、业务复杂度高、跟踪时间长的项目，也适合考虑使用微服务架构。

在决定使用微服务架构之后，面临的另一个问题是如何将系统拆分为微服务。有关微服务的拆分，请参阅以下建议。
通过业务功能分解并定义与业务功能相对应的服务。

将域驱动设计分解为多个子域。

按照动词或用例分解，并定义负责特定操作的服务，例如一个负责完成订单的航运服务。

通过定义一个对给定类型的实体或资源的所有操作负责的服务来分解名词或资源，例如一个负责管理用户账户的账户服务。

由于每个公司项目的实际情况不同，所以微服务的拆分在实际操作时，会涉及到很多不同的细节问题，这里就不一一描述了，但总体来说，项目在拆分时按照上述几点建议即可。如果想了解更多微服务架构相关的知识，可以了解 叩丁狼 学院java培训课程。

微服务架构系列之–最全配置中心对比（面试随便装）

本文从社区活跃度、产品特点、成功案例、产品缺点等维度，全方位对比Spring Cloud Config、Apollo、Nacos、Disconf、Spring Cloud Consul、Spring Cloud Zookeeper等几款Spring Cloud生态的配置服务器，帮助你选择合适的配置服务器。

一、Spring Cloud Config

GitHub地址

https://github.com/spring-cloud/spring-cloud-config ，Star数1178，官方组件，社区较活跃

开源厂商

Pivotal（Spring官方团队）

产品特点

演示环境

暂无

成功案例

N多，目前用Spring Cloud的大多团队都是用的Spring Cloud Config

缺点

二、Apollo

GitHub地址

https://github.com/ctripcorp/apollo ，Star数11169，社区很活跃

开源厂商

携程

产品特点

成功案例

携程、网易蜂巢、中国平安等，更多公司详见https://github.com/ctripcorp/apollo

演示环境



账号/密码：apollo/admin

缺点

暂未发现

三、Nacos

GitHub地址

https://github.com/alibaba/nacos ，Star数3820，社区非常活跃

开源厂商

阿里巴巴

产品特点

成功案例

阿里巴巴、虎牙直播、工商银行软件开发中心、爱奇艺等，更多公司详见https://github.com/alibaba/nacos/issues/273

演示环境

http://console.nacos.io/nacos/index.html

缺点

暂未发现明显缺点

四、Disconf

GitHub地址

https://github.com/knightliao/disconf ，Start数4505，社区活跃度一般

开源厂商

原百度员工，现在蚂蚁金服

产品特点

成功案例

百度、滴滴出行、顺丰、网易等，更多公司详见https://github.com/knightliao/disconf

缺点

最新的版本发布于两年前，有点久了。

五、Spring Cloud Consul

GitHub地址

https://github.com/spring-cloud/spring-cloud-consul ，Star数493，官方组件，社区较活跃

开源厂商

Pivotal（Spring官方团队）

产品特点

成功案例

暂未发现

演示环境

暂无

缺点

六、Spring Cloud Zookeeper

GitHub地址

https://github.com/spring-cloud/spring-cloud-zookeeper ，Star数330，官方组件，社区较活跃

开源厂商

Pivotal（Spring官方团队）

产品特点

演示环境

暂无

成功案例

暂未发现

缺点

其他

如果使用的是Spring Cloud Kubernetes，或者将Spring Cloud应用部署在Kubernetes环境中，还可以选择ConfigMap，这种方式就笔者了解，业界这么玩的还不多，暂时不分析了。已经将Spring Cloud Kubernetes列入博客19年更新名单中了，敬请期待。

结论

微服务架构中的组件有哪些？

在正式学习如何搭建微服务架构之前，我们先来了解一下微服务架构中涉及的一些常见组件名称及其作用。

·服务注册中心：注册系统中所有服务的地方。

服务注册：服务提供方将自己调用地址注册到服务注册中心，让服务调用方能够方便地找到自己。

·服务发现：服务调用方从服务注册中心找到自己需要调用服务的地址。

·负载均衡：服务提供方一般以多实例的形式提供服务，使用负载均衡能够让服务调用方连接到合适的服务节点。

·服务容错：通过断路器（也称熔断器）等一系列的服务保护机制，保证服务调用者在调用异常服务时快速地返回结果，避免大量的同步等待。

·服务网关：也称为API网关，是服务调用的唯一入口，可以在这个组件中实现用户鉴权、动态路由、灰度发布、负载限流等功能。

分布式配置中心：将本地化的配置信息（properties、yml、yaml等）注册到配置中心，实现程序包在开发、测试、生产环境的无差别性，方便程序包的迁移。 关于微服务网关组件对比和微服务网关技术选型的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 微服务网关组件对比的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于微服务网关技术选型、微服务网关组件对比的信息别忘了在本站进行查找喔。

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