微服务架构下的核心话题 (三)：微服务架构的技术选型

前期回顾：
微服务架构下的核心话题 (一)：微服务架构下各种项目的顺势崛起
微服务架构下的核心话题 (二)：微服务架构的设计原则和核心话题

1、前言

为了实现基于微服务开发的产品，或者说为了将单体应用重构为微服务架构时，将面临着众多技术框架的选择。大公司每每会有专门的部门或团队来负责自主研发本身的框架，以知足产品的须要，可是对于通常的中小型企业，选择合适的开源框架就显得更接地气了。本章将简单介绍微服务中，在技术选型时须要注意哪些原则，一些经常使用的开源技术框架，但愿可以为你们在进行技术选型、调研时提供一些思路方向。

笔者面试过不少程序员，一说起微服务，就会具体说道Spring Boot、Spring Cloud，而后就是“背诵”各类具体的用法和配置文件。并非说这样不对，但咱们更但愿知道的是这些技术框架的原理，为何选择它，它与其余相似框架又有何不一样呢。

至于一个技术框架该怎么用，它适用于什么场景，笔者建议能够直接阅读官方或对应的github上的文档，有须要时还能够阅读下关注点的源码，这样对正确的理解它，是颇有必要的，毕竟官方发布的东西是相对权威的，其余地方的资料或许存在片面性，对你们的使用、理解存在必定的误导。(这只是笔者对你们在技术选型时，查阅资料的一些建议)

2、选型原则

在软件开发领域，几乎天天都有新的技术框架诞生、更新，一些新的概念更是层出不穷，技术选型时，不免让人无从抉择。 对于技术选型，我我的有如下几点建议：

1.有需求，再引入

在微服务架构中，各种组件/技术不少不少，但并不意味着全部的都应该引入你的项目，假若单纯为了覆盖全技术栈或组件而所有引入，这将是一种很不明智的选择。后续将会成为你项目的累赘，让你苦不堪言。

只要你记住这六个字：“有需求，再引入”，就OK了。伴随着项目体系架构的完善、功能的健全，当有某方面的需求时，在逐步考虑是否引入某些技术组件。

2.选择最熟悉、使用最多的技术

“一个新项目里最好不要使用超过30%的新技术”，我以为这句话是有必定道理的。对于你彻底不知道、不了解的技术，你是没法预估、掌控在使用过程当中会出现的任何风险，一旦出现问题，短期内解决不了，你将会变得很难堪。

在这里不是说拒绝使用、接触新技术，新技术是值得你们去追捧、了解、学习，一些新技术在很大程度上能给咱们带来史无前例的利处，解决其余技术框架解决不了的问题。这里所说的“新技术”，是指没有通过充分的考察、技术验证、存在种种疑惑的技术，而是一味的拿来主义，这样的风险可想而知。

确保选择的技术，是业界使用最多的、被你们承认的技术，即便出现了问题，也能应对自如。至少在团队内部小范围是很是承认的。

3.强大社区支撑的技术

GitHub上star的数量是一个重要指标，同时参考近年来代码、文档、issues等更新频率，各大技术博客是否有相关技术分享记载，这些都是可以说明该技术是否活跃、受欢迎程度、使用人群多少等。

拥有强大社区支持的技术，在选型后，假若使用出现疑问、问题、bug等，可以有地方可提、可修复、可深究探讨，毕竟如今的技术社区都是足够开放的。

慎选我的开源的技术框架、组件等，里面到底有多少坑，没几我的能说清楚的，何况说不定哪天就不复存在了呢。

4.从业务、项目规模出发

任何技术的出发点都是为最终业务而服务的，不一样业务、不一样项目规模，对技术的要求指标都是不一样的。处于初创期的业务，选型的基准是相对灵活，毕竟业务相对简单，支撑业务不是很大，只要够用、开发效率足够高就好。处于复杂业务而重构的项目，选型就需谨慎，每每伴随着一些复杂需求诞生、规模大小的不肯定性，不得不考虑选型技术可能伴随着一些小修小补或者螺旋式上升的重构，则需选型便于适配、切换、替换，耦合度低的技术。

正由于技术选型和业务相关，咱们可以观察到一些很明显的现象：新技术每每被早期创业团队或大公司的新兴业务使用；中大型公司的核心业务则更倾向于用一些稳定了几年的技术；一个公司若是长期使用一种技术，就会倾向于一直使用下去，甚至连版本都不更新的使用下去。

学会从业务端思考。首先咱们须要充分地理解业务，理解用户需求，理解当下须要解决的首要问题，以及可能的风险有哪些，再将目标进行分解，进行具体的技术选型、模型设计、架构设计。

5.先验证后使用

对于未经验证的新技术、新理念的引入必定要慎重，必定要在全方位的验证事后，再大规模的使用，最终肯定选型。新技术、新理念的出现，天然有它的诱惑，慎重并不表明保守，技术老是在不断前进，拥抱变化自己没有问题，可是引入不成熟的技术看似能带来短时间的收益，可是它的风险或者是后期的成本可能远远大于收益。

验证后，才有说服力，用着更放心。

3、技术选型

每种技术架构都有其优缺点,存在即合理,不一样的业务场景使用不一样的应用架构，技术框架，不必定说最新的架构、技术就是最适合你的。

微服务架构中常说起到的主要技术框架选型以下表所示，本文后面将基于此展开说明对比。

类型	框架
服务治理	Dubbo、Spring Cloud
API网关	Zuul、traefik、OpenResty、Kong
服务注册与发现	Zookeeper、Eureka、Consul、etcd
配置中心	Spring Cloud Config、Apollo、Nacos
链路追踪、监控	Zipkin、CAT

4、服务治理

1.Dubbo

Dubbo是一款高性能、轻量级的开源JAVA RPC框架，以及SOA服务治理方案。简单的说，Dubbo就是个服务框架，说白了就是个远程服务调用的分布式框架。它提供了三大核心能力：面向接口的远程方法调用、智能容错和负载均衡、以及服务自动注册和发现，很容易和Spring框架无缝集成。

Dubbo逻辑架构以下图所示：

• 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的总体架构以下图所示，提供一站式的微服务架构解决方案。

使用Spring Cloud来构建微服务架构能够省去你整合各家技术的成本，Spring Cloud为咱们构建微服务架构提供了一站式的解决方案，就比如当初Spring诞生是为解决EJB企业应用开发的众多问题而提供的一站式轻量级企业应用开发解决方案同样，随着使用Spring Cloud的产品数量增长，Spring Cloud在微服务架构中已一统江湖。

下面是Spring Cloud的完整技术栈，看完你就知道它为啥会在微服务架构中一统江湖了。

3.对比、总结

	Dubbo	Spring Cloud
功能/专一点	专一于RPC和服务治理	微服务架构生态、技术栈
通讯协议	RPC(远程方法调用)协议	REST/HTTP（已有组件支持gRPC协议）
服务注册与发现	Zookeeper(CP)	Eureka(AP)
负载均衡	软负载均衡（Random/RoundRobin）	Ribbon
容错机制	有	有
熔断机制	无	Hystrix
配置中心	依赖外部组件，如：Nacos	Spring Cloud Config
网关	无	zuul,Gateway
服务监控	Dubbo + Monitor	Hystrix + Turbine、Spring Boot Admin（SBA）
链路监控	无	Sleuth + Zipkin
多语言支持	只支持Java	REST支持多语言
社区活跃	高(依靠阿里)	高(依靠Spring)
消息总线	无	Spring Cloud Bus
数据流	无	Spring Cloud Stream
批量任务	无	Spring Cloud Task
……	……	……

经过上表对比，很容易发现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中。

5、API网关

API网关做为微服务中全部服务的惟一入口，省得业界各种成熟的技术框架组件，在进行技术选型时，须要特别考虑是否拥有如下特性：

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

1.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源码深刻研究下。)

2.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证书)
• 高可用集群模式

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	OpenResty	Kong
功能/用途	Spring Cloud中的核心组件之一，充当API网关的角色	支持动态配置的HTTP反向代理和负载均衡器	基于Nginx与Lua的高性能Web平台，服务代理/网关	企业级API管理
学习成本	简单	简单	适中	适中
社区	开源、活跃	开源	开源	开源/企业版
扩展性	可扩展，本身实现Filter	可扩展，本身实现	可扩展，插件	可扩展， 插件
服务发现	动态	动态	动态	动态
通讯协议	Restful	http,https,grpc,websocket	http,https,websocket	http,https,websocket
限流	支持	不支持	支持	支持
熔断	支持	支持	-	-
健康检查	支持	不支持	支持	支持

综上对比，从开源社区活跃度和学习成原本看，无疑是Zuul和Traefik较好；从成熟度来看，较好的是Kong、Traefik；从性能角度来看，Kong要比其余几个领先一些，从架构优点的扩展性来看，Kong丰富的插件，而Zuul是彻底须要自研各种Filter，但Zuul因为与Spring Cloud深度集成，使用度也很高。

6、服务注册与发现

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

现现在，各种服务注册与发现的框架、组件不少(Zookeeper、Eureka、Consul、etcd等)，在选择上更是眼花缭乱。在服务注册与发现的技术选型上，我以为咱们应该仍是有必定遵循原则和关注要点的。一般可从如下几个方面出发，进行重点关注、抉择。

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

7、配置中心

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

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

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

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

通常完善的配置中心，都会从如下两个方面设计出发，以发挥配置中心的做用。

1）配置实时生效

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

2）配置管理流程

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

1.Spring Cloud Config

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

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

以Git存储方式为例说明，Spring Cloud Config包含config-server、Git和Spring Cloud Bus三大组件：

• config-server提供给客户端获取配置。
• Git用于存储和修改配置。
• Spring Cloud Bus通知客户端配置变动。

本地测试模式下，Spring Cloud Bus和config-server须要部署一个节点，Git使用GitHub就能够。在生产环境中，Spring Cloud Config，config-server须要部署至少两个节点。Spring Cloud Bus若是使用RabbitMQ，普通集群模式至少须要两个节点。

Git服务若是使用GitHub就不用考虑高可用问题，若是考虑到安全性要自建Git私有仓库，总体的成本比较高。Web服务能够部署多节点支持高可用，因为Git有数据的一致性问题，能够经过如下的方式来支持高可用：

• Git+Keepalived冷备模式，当主Git挂了能够立刻切到备Git。
• Git多节点部署，存储使用网络文件系统或者经过DRBD实现多个Git节点的数据同步。

2.Apollo

Apollo（阿波罗）是携程框架部门研发的分布式配置中心，可以集中化管理应用不一样环境、不一样集群的配置，配置修改后可以实时推送到应用端，而且具有规范的权限、流程治理等特性，适用于微服务配置管理场景。

Apollo分为MySQL，Config Service，Admin Service，Portal四个模块：

• MySQL：存储Apollo元数据和用户配置数据。
• Config Service：提供配置的读取、推送等功能，客户端请求都是落到Config Service上。
• Admin Service：提供配置的修改、发布等功能，Portal操做的服务就是Admin Service。
• Portal：提供给用户配置管理界面。

本地测试Config Service，Admin Service，Portal三个模块能够合并一块儿部署，MySQL单独安装并建立须要的表结构。在生产环境使用Apollo，Portal能够两个节点单独部署，稳定性要求没那么高的话，Config Service和Admin Service能够部署在一块儿，数据库支持主备容灾。

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易于定制化二次开发，生产高可用的成本最高。

	Spring Cloud Config	Apollo	Nacos
开源时间	2014.9	2016.5	2018.6
实时生效(推送)	基于Spring Cloud Bus完成	基于HTTP轮询(1s内)	基于HTTP轮询(1s内)
版本管理	支持(Git、SVN)	支持	支持
配置回滚	支持(Git、SVN)	支持	支持
灰度发布	支持	支持	待支持
权限管理	支持	支持	待支持
集群	支持	支持	支持
多环境	支持	支持	支持
监听查询	支持	支持	支持
多语言	只支持Java	Java、Go、C++、Python、PHP	Java、Python、Nodejs
单机部署	Config-Server + Git + Spring Cloud Bus(实时更新推送)	Apollo-quickstart + MySQL	Nacos单节点
分布式部署	Config-Server(2) + Git + MQ (部署复杂)	Config(2) + Admin(2) + Portal(2) + MySQL (部署复杂)	Nacos(3) + MySQL(部署简单)
配置格式校验	不支持	支持	支持
通讯协议	HTTP、AMQP	HTTP	HTTP
数据一致性	Git保证数据一致性	数据库模拟消息队列，Apollo定时读取	HTTP异步通知

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

未完，更新中……

参考资料：
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/
5.http://openresty.org/cn/
6.https://www.cnblogs.com/duanxz/p/9776316.html
7.https://yq.aliyun.com/articles/698930?utm_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/

欢迎微信扫码下面二维码，关注微信公众号【程序猿技术大咖】，进行更多交流学习！