前言
为了实现基于微服务开发的产品，或者说为了将单体应用重构为微服务架构时，将面临着众多技术框架的选择。大公司往往会有专门的部门或团队来负责自主研发自己的框架，以满足产品的需要，但是对于一般的中小型企业，选择合适的开源框架就显得更接地气了。本章将简单介绍微服务中一些常用的开源技术框架，希望能够为大家在进行技术选型、调研时提供一些思路方向。
笔者面试过很多程序员，一提及微服务，就会具体说道Spring Boot、Spring Cloud，然后就是“背诵”各种具体的用法和配置文件。并不是说这样不对，但我们更希望知道的是这些技术框架的原理，为什么选择它，它与其他类似框架又有何不同呢。
至于一个技术框架该怎么用，它适用于什么场景，笔者建议可以直接阅读官方或对应的github上的文档，有需要时还可以阅读下关注点的源码，这样对正确的理解它，是很有必要的，毕竟官方发布的东西是相对权威的，其他地方的资料或许存在片面性，对大家的使用、理解存在一定的误导。(这只是笔者对大家在技术选型时，查阅资料的一些建议)
微服务架构中常提及到的主要技术框架选型如下表所示：
| 类型 | 框架 |
|---|---|
| 服务治理 | Dubbo、Spring Cloud |
| API网关/服务代理 | Zuul、traefik、OpenResty、Kong、Orange、Ngninx |
| 服务注册发现 | Zookeeper、Eureka、Consul、etcd |
| 配置中心 | Spring Cloud Config、Apollo |
| 链路追踪、监控 | Zipkin、CAT |
服务治理
Dubbo
Dubbo是一款高性能、轻量级的开源JAVA RPC框架,它提供了三大核心能力：面向接口的远程方法调用、智能容错和负载均衡、以及服务自动注册和发现，很容易和Spring框架无缝集成。
Dubbo逻辑架构如下图所示：
- Provider：暴露服务的提供方，可以通过jar或者容器的方式启动服务。
- Consumer：调用远程服务的服务消费方。
- Registry：服务注册中心和发现中心。
- Monitor：统计服务和调用次数，调用时间监控中心。（dubbo的控制台页面中可以显示，目前只有一个简单版本）
- Container：服务运行的容器。
在现有的微服务架构下，Dubbo只能说是一个服务治理框架，或者说是一个RPC框架，是以接口为粒度，一个接口类就就是一个服务。如果直接用Dubbo来实现微服务架构，还缺少以下几个功能：
- 分布式配置：可以使用Spring Cloud Config、Apollo等来实现。
- 链路追踪：可以使用Zipkin、CAT等来实现。
- 批量任务：可以使用当当网开源的Elastic-Job来实现。
Spring Cloud
Spring Cloud是目前最主流的微服务架构落地首选方案之一，是基于Spring Boot实现的开源框架，是一个全家桶，是微服务的整体技术栈。
它为服务注册发现、动态路由、负载均衡、配置管理、消息总线、熔断器、分布式链路追踪、大数据操作等提供了简单的实现，让我们可以更简洁的使用它。
正如我们前面说过的，微服务是可以独立部署、水平扩展、独立访问的服务单元，而Spring Cloud就是这些微服务的“大管家”，采用了微服务这种架构之后，项目的数量会非常多，调用链路复杂，从而管理成了很大的问题，而Spring Cloud框架恰恰提供了各种组件用于管理和治理微服务。理所应当的，就成了大家首选框架了。
Spring Cloud的整体架构如下图所示，提供一站式的微服务架构解决方案。
使用Spring Cloud来构建微服务架构可以省去你整合各家技术的成本，Spring Cloud为我们构建微服务架构提供了一站式的解决方案，就好比当初Spring诞生是为解决EJB企业应用开发的众多问题而提供的一站式轻量级企业应用开发解决方案一样，随着使用Spring Cloud的产品数量增加，Spring Cloud在微服务架构中已一统江湖。
API网关、服务代理
Zuul
Zuul作为Spring Cloud中的核心组件之一，充当API网关的重要角色，所有请求都可以通过Zuul达到后端的应用程序、服务。Zuul提供了动态路由、监控、弹性负载和安全等特性，其核心是一系列的Filter，其作用类似于Servlet框架中的Filter，或者AOP。
Zuul底层利用各种Filter实现了如下功能：
- 动态路由：根据需要将请求动态路由到后端集群。
- 身份认证和安全性：识别每个需要认证的资源，拒绝不符合要求的请求，如：鉴权。
- 统计监测：在服务边界追踪并统计数据，提供精确的统计监测视图。
- 压力测试：逐渐增加对集群的流量以了解其性能。
- 负载卸载：预先为每种类型的请求分配容量，当请求超过容量时自动丢弃。
- 静态资源处理：直接在边界返回某些响应。
基于上述这些功能特性，使得Zuul作为API网关的不二之选。
Zuul的逻辑架构如下图所示:
Zuul的过滤器之间是不直接通信的，而是通过一个RequestContext的类来进行数据传统，RequestContext继承ConcurrentHashMap，使用ThreadLocal变量来记录每个Request需要传递的数据。
Zuul的过滤器是由Groovy来实现的，这些过滤器文件被存放在Zuul Server的特定目录下，Zuul会定期轮询这些目录，修改过的过滤器会动态加载到Zuul Server中，以便过滤请求使用。
Zuul的大部分功能都是通过过滤器来实现的，其中定义了4种标准的过滤器类型(pre、route、post、error)，以满足应用于请求的不同阶段。
(如果想更清晰深入的了解Zuul，可以参考上图的Zuul逻辑架构图，并结合Zuul源码深入研究下。)
traefik
在了解traefik之前，不妨先看看它的整体架构图，如下所示：
从上图不难看出，traefik充当了HTTP反向代理的角色，使得发布的服务变得轻松有趣。在微服务中，实质上是一个为了让部署微服务变得更加便捷而诞生的HTTP反向代理、负载均衡工具。，它支持多种后台 (Docker, Swarm, Kubernetes, Marathon, Mesos, Consul, Etcd, Zookeeper, BoltDB, Rest API, file…) 来自动化、动态的应用它的配置文件设置。
除了众多功能之外，traefik的与众不同之处还在于它会自动发现适合您服务的配置。无需维护和同步单独的配置文件,一切都会自动，实时地进行（无需重新启动，不会中断连接）。使用traefik后，你可以将更多的精力、时间花费在开发和部署上面，而不是在配置和维护其工作状态上。
特性：
- 高性能
- 无需安装其他依赖，通过Go语言编写的单一可执行文件
- 支持Restful API接口
- 多种后台支持：Docker, Swarm, Kubernetes, Marathon, Mesos, Consul, Etcd
- 后台监控, 可以监听后台变化进而自动化应用新的配置文件设置
- 配置文件热更新。（无需重启）
- 正常结束http连接
- 后端断路器
- 轮询，rebalancer 负载均衡
- Rest Metrics
- 支持最小化官方docker镜像
- 后台支持SSL
- 前台支持SSL（包括SNI）
- 清爽的AngularJS前端页面
- 支持Websocket
- 支持HTTP/2
- 网络错误重试
- 支持Let’s Encrypt (自动更新HTTPS证书)
- 高可用集群模式
未完，更新中……
参考资料：
1.http://dubbo.apache.org/zh-cn/
2.https://my.oschina.net/bigdataer/blog/1859971?from=timeline
3.https://github.com/Netflix/zuul/wiki
4.https://traefik.cn/
欢迎微信扫码下面二维码，关注微信公众号【程序猿技术大咖】，进行更多交流学习！
转载：https://blog.csdn.net/xcbeyond/article/details/102511891