• Provider：暴露服务的提供方，可以通过jar或者容器的方式启动服务。
• Consumer：调用远程服务的服务消费方。
• Registry：服务注册中心和发现中心。
• Monitor：统计服务和调用次数，调用时间监控中心。（dubbo的控制台页面中可以显示，目前只有一个简单版本）
• Container：服务运行的容器。

Dubbo特点：

• 远程通讯: 提供对多种基于长连接的NIO框架抽象封装（非阻塞I/O的通信方式，Mina/Netty/Grizzly），包括多种线程模型，序列化（Hessian2/ProtoBuf），以及“请求-响应”模式的信息交换方式。
• 集群容错: 提供基于接口方法的透明远程过程调用（RPC），包括多协议支持（自定义RPC协议），以及软负载均衡（Random/RoundRobin），失败容错（Failover/Failback），地址路由，动态配置等集群支持。
• 自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。

在现有的微服务架构下，Dubbo只能说是一个服务治理框架，或者说是一个RPC框架，是以接口为粒度，一个接口类就就是一个服务。如果直接用Dubbo来实现微服务架构，还缺少以下几个功能：

• 分布式配置：可以使用Spring Cloud Config、Apollo等来实现。
• 链路追踪：可以使用Zipkin、CAT等来实现。
• 批量任务：可以使用当当 开源的Elastic-Job来实现。

2.Spring Cloud

Spring Cloud是目前最主流的微服务架构落地首选方案之一，是基于Spring Boot实现的开源框架，是一个全家桶，是微服务的整体技术栈。

Spring Boot是Spring 的一套快速配置脚手架，使用默认大于配置的理念，用于快速开发单个微服务。

它为服务注册发现、动态路由、负载均衡、配置管理、消息总线、熔断器、分布式链路追踪、大数据操作等提供了简单的实现，让我们可以更简洁的使用它。

正如我们前面说过的，微服务是可以独立部署、水平扩展、独立访问的服务单元，而Spring Cloud就是这些微服务的“大管家”，采用了微服务这种架构之后，项目的数量会非常多，调用链路复杂，从而管理成了很大的问题，而Spring Cloud框架恰恰提供了各种组件用于管理和治理微服务。理所应当的，就成了大家首选框架了。

Spring Cloud的整体架构如下图所示，提供一站式的微服务架构解决方案。

3.对比、总结

通过上表对比，很容易发现Spring Cloud拥有很多的项目模块，包含了微服务系统的方方面面。Dubbo是一个非常优秀的服务治理和服务调用框架，但缺少很多功能模块，例如 关、链路追踪等。在项目模块上，Spring Cloud占据着更大的优势。对比并不是否定谁，推崇谁，只是说明在不同场景下，有利优劣，需客观来看。

如果仅关注于服务治理的这个层面，Dubbo其实还优于Spring Cloud很多：

• 支持多种序列化协议，如Hessian、HTTP、WebService。
• Dobbo Admin后台管理功能强大，提供了路由规则、动态配置、访问控制、权重调节、均衡负载等功能。
• 阿里最近重启维护，成为Apache孵化项目。
• Dubbo使用RPC协议效率更高，在极端压力测试下，Dubbo的效率会高于Spring Cloud效率一倍多。

如果对效率有极高的要求建议使用Dubbo，相对比RPC的效率会比Restful高很多，如果选择微服务架构去重构整个技术体系，那么 Spring Cloud是当仁不让之选，它可以说是目前最好的微服务框架没有之一，并且可以断言，将来Dubbo可以很好的整合到Spring Cloud中。

五、API 关

API 关作为微服务中所有服务的唯一入口，免得业界各类成熟的技术框架组件，在进行技术选型时，需要特别考虑是否拥有以下特性：

• 高可用： 关是对外的唯一关口，必须保证 7 * 24小时可用，持续提供稳定可靠的服务。
• 高性能：所有的请求都会经过 关，它承受的压力是巨大的，所以必须保证它具备良好的性能，以应对高并发请求。
• 安全性： 关必须能够防止外部的恶意访问，确保内部各个微服务的安全。
• 扩展性： 关是一个处理非业务功能的绝佳场所，必须能够提供流量管控、协议转发、日志监控等服务，同时能够为以后对非业务功能的扩展提供良好的兼容性。

1.Zuul

Zuul作为Spring Cloud中的核心组件之一，充当API 关的重要角色，所有请求都可以通过Zuul达到后端的应用程序、服务。Zuul提供了动态路由、监控、弹性负载和安全等特性，其核心是一系列的Filter，其作用类似于Servlet框架中的Filter，或者AOP。

Zuul底层利用各种Filter实现了如下功能：

• 动态路由：根据需要将请求动态路由到后端集群。
• 身份认证和安全性：识别每个需要认证的资源，拒绝不符合要求的请求，如：鉴权。
• 统计监测：在服务边界追踪并统计数据，提供精确的统计监测视图。
• 压力测试：逐渐增加对集群的流量以了解其性能。
• 负载卸载：预先为每种类型的请求分配容量，当请求超过容量时自动丢弃。
• 静态资源处理：直接在边界返回某些响应。

基于上述这些功能特性，使得Zuul作为API 关的不二之选。

Zuul的逻辑架构如下图所示:

从上图不难看出，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证书)
• 高可用集群模式

3.OpenResty

OpenResty是一个基于Nginx与Lua的高性能Web平台，其内部集成了大量精良的Lua库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理超高并发、扩展性极高的动态Web应用、Web服务和动态 关。

OpenResty通过汇聚各种设计精良的Nginx模块（主要由OpenResty团队自主开发），从而将Nginx有效地变成一个强大的通用Web应用平台。这样，Web 开发人员和系统工程师可以使用Lua脚本语言调动 Nginx支持的各种C以及Lua模块，快速构造出足以胜任10K乃至 1000K以上单机并发连接的高性能Web应用系统。

OpenResty的目标是让你的Web服务直接跑在Nginx服务内部，充分利用Nginx的非阻塞I/O模型，不仅仅对HTTP客户端请求,甚至于对远程后端诸如MySQL、PostgreSQL、Memcached以及Redis等都进行一致的高性能响应。

4.Kong

Kong是一个在Nginx中运行的Lua应用程序，并且可以通过lua-nginx模块实现，Kong不是用这个模块编译Nginx，而是与OpenResty一起发布，OpenResty已经包含了lua-nginx-module，OpenResty不是 Nginx的分支，而是一组扩展功能的模块。

是一个Api Gateway，通过插件的形式提供负载均衡，日志记录，身份验证，速率限制，转换等功能。可以很轻松扩展功能，模块化，可以运行在任何基础设施上。

它的核心是实现数据库抽象，路由和插件管理，插件可以存在于单独的代码库中，并且可以在几行代码中注入到请求生命周期的任何位置。很方便地为路由和服务提供各种插件， 关所需要的基本特性，Kong都如数支持：

• 云原生：与平台无关，Kong可以从裸机运行到Kubernetes。
• 动态路由：Kong的背后是OpenResty+Lua，所以从OpenResty继承了动态路由的特性。
• 熔断
• 健康检查
• 日志：可以记录通过Kong的HTTP，TCP，UDP请求和响应。
• 鉴权：权限控制，IP黑白名单，同样是OpenResty的特性。
• SSL: 可以为基础服务或API设置特定的SSL证书。
• 监控：Kong提供了实时监控插件。
• 认证：如数支持HMAC, JWT, Basic, OAuth2.0等常用协议。
• 限流
• REST API：通过Rest API进行配置管理，从繁琐的配置文件中解放。
• 可用性: 天然支持分布式。
• 高性能: 背靠非阻塞通信的nginx，性能自不用说。
• 插件机制: 提供众多开箱即用的插件，且有易于扩展的自定义插件接口，用户可以使用Lua自行开发插件。

上面这些特性中，反复提及了Kong背后的OpenResty，实际上，使用 Kong之后，Nginx可以完全摒弃，因为Kong的功能是Nginx的父集。

5.对比、总结

综上对比，从开源 区活跃度和学习成本来看，无疑是Zuul和Traefik较好；从成熟度来看，较好的是Kong、Traefik；从性能角度来看，Kong要比其他几个领先一些，从架构优势的扩展性来看，Kong丰富的插件，而Zuul是完全需要自研各类Filter，但Zuul由于与Spring Cloud深度集成，使用度也很高。

六、服务注册与发现

服务注册与发现，是一个古老的话题，当应用开始脱离单机运行和访问时，服务注册与发现就诞生了。目前的 络架构是每个主机都有一个独立的IP地址，那么服务发现基本上都是通过某种方式获取到服务所部署的IP地址。DNS协议是最早将一个 络名称翻译为 络IP的协议，在最初的架构选型中，DNS+LVS+Nginx基本可以满足所有的RESTful服务的发现，此时服务的IP列表通常配置在Nginx或者LVS。后来出现了RPC服务，服务的上下线更加频繁，人们开始寻求一种能够支持动态上下线并且推送IP列表变化的注册中心框架或组件。

现如今，各类服务注册与发现的框架、组件很多(Zookeeper、Eureka、Consul、etcd等)，在选择上更是眼花缭乱。在服务注册与发现的技术选型上，我觉得我们应该还是有一定遵循原则和关注要点的。通常可从以下几个方面出发，进行重点关注、抉择。

• 数据一致性
• 负载均衡
• 健康检查
• 性能与容量
• 易用性
• 集群扩展性
• 用户扩展性

七、配置中心

在微服务架构中，服务的数量以及配置信息的日益增多，比如各种服务器参数配置、各种数据库访问参数配置、各种环境下配置信息的不同、配置信息修改之后实时生效等等，传统的配置文件方式或者将配置信息存放于数据库中的方式已无法满足开发人员对配置管理的要求，如：

• 安全性：配置跟随源代码保存在代码库中，容易造成配置泄漏。
• 时效性：修改配置，需要重启服务才能生效。
• 局限性：无法支持动态调整：例如日志开关、功能开关。

在微服务架构中，使用配置中心之前，上述的问题或麻烦，你肯定也会遇到过，所以，是否引入配置中心，取决于你是否有下面的需求：

• 配置集中化统一管理
• 配置实时生效

一般完善的配置中心，都会从以下两个方面设计出发，以发挥配置中心的作用。

1）配置实时生效

传统的静态配置方式要想修改某个配置只能修改之后重新发布应用，要实现动态性，可以选择使用数据库，通过定时轮询访问数据库来感知配置的变化。轮询频率低感知配置变化的延时就长，轮询频率高，感知配置变化的延时就短，但比较损耗性能，需要在实时性和性能之间做折中。配置中心专门针对这个业务场景，兼顾实时性和一致性来管理动态配置。

2）配置管理流程

配置的权限管控、灰度发布、版本管理、格式检验和安全配置等一系列的配置管理相关的特性也是配置中心不可获取的一部分。(这也算是配置中心的高级特性作用)

1.Spring Cloud Config

Spring Cloud Config作为Spring Cloud中的一个组件，其功能开放，可开发性强，常是各类配置中心自我研发的基石。

从Spring Cloud Config的源码(spring-cloud-config-server)中，可以看出目前支持本地存储、Git仓库存储、SVN仓库存储、数据库存储方式，其他存储方式可参考源码自行实现即可。

3.Nacos

Nacos是一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。这正是Nacos官方给出的定义：

an easy-to-use dynamic service discovery, configuration and service management platform for building cloud native applications.

核心功能：

• 动态配置服务：
  动态配置服务让您能够以中心化、外部化和动态化的方式管理所有环境的配置。动态配置消除了配置变更时重新部署应用和服务的需要。配置中心化管理让实现无状态服务更简单，也让按需弹性扩展服务更容易。
• 服务发现及管理：
  动态服务发现对以服务为中心的（例如微服务和云原生）应用架构方式非常关键。Nacos支持DNS-Based和RPC-Based（Dubbo、gRPC）模式的服务发现。Nacos也提供实时健康检查，以防止将请求发往不健康的主机或服务实例。借助Nacos，您可以更容易地为您的服务实现断路器。
• 动态DNS服务：
  通过支持权重路由，动态DNS服务能让您轻松实现中间层负载均衡、更灵活的路由策略、流量控制以及简单数据中心内 的简单DNS解析服务。动态DNS服务还能让您更容易地实现以DNS协议为基础的服务发现，以消除耦合到厂商私有服务发现API上的风险。

Nacos部署需要Nacos Service和MySQL：

• Nacos Service：对外提供服务，支持配置管理和服务发现。
• MySQL：提供Nacos的数据持久化存储。

单机模式下，Nacos可以使用嵌入式数据库部署一个节点，就能启动。如果对MySQL比较熟悉，想要了解整体数据流向，可以安装MySQL提供给Nacos数据持久化服务。生产环境使用Nacos，Nacos服务需要至少部署三个节点，再加上MySQL主备。

4.对比、总结

整体来看，Nacos的部署结构比较简单，运维成本较低。Apollo部署组件较多，运维成本比Nacos高。Spring Cloud Config易于定制化二次开发，生产高可用的成本最高。

总的来说，Apollo和Nacos相对于Spring Cloud Config的生态支持更广，在配置管理流程上做的更好。Apollo相对于Nacos在配置管理做的更加全面，不过使用起来也要麻烦一些。Nacos使用起来相对比较简洁，在对性能要求比较高的大规模场景更适合。

未完，更新中……

参考资料：
1.http://dubbo.apache.org/zh-cn/
2.https://my.oschina.net/bigdataer/blog/1859971om=timeline
3.https://github.com/Netflix/zuul/wiki
4.https://traefik.cn/
5.http://openresty.org/cn/
6.https://www.cnblogs.com/duanxz/p/9776316.html
7.https://yq.aliyun.com/articles/698930m_content=g_1000053369
8.https://blog.csdn.net/weixin_44337261/article/details/89426925
9.https://github.com/ctripcorp/apollo/wiki
10.https://nacos.io/zh-cn/

文章知识点与官方知识档案匹配，可进一步学习相关知识云原生入门技能树首页概览8829 人正在系统学习中