springcloud中文网,springcloud中文官网

SpringCloud简介

SpringCloud是基于SpringBoot基础之上开发的微服务框架，SpringCloud是一套目前非常完整的微服务解决方案框架，其内容包含服务治理、注册中心、配置管理、断路器、智能路由、微代理、控制总线、全局锁、分布式会话等。

SpringCloud包含众多的子项目

SpringCloud config 分布式配置中心

SpringCloud netflix 核心组件：

Eureka:服务治理 注册中心

Hystrix:服务保护框架

Ribbon:客户端负载均衡器

Feign：基于ribbon和hystrix的声明式服务调用组件

Zuul: 网关组件,提供智能路由、访问过滤等功能。

上海每特教育科技有限公司|苏州特每信息科技有限公司版权所有

SpringCloud中文翻译：

Java工程师以后发展路径是什么？

最近有些网友问我如何自学 Java 后端，还有些是想从别的方向想转过来，但都不太了解 Java 后端究竟需要学什么，究竟要从哪里学起，哪些是主流的 Java 后端技术等等，导致想学，但又很迷茫，不知从何下手。我就以过来人的经历，写在这篇博客里，不一定都对，但都是我根据自己的经历总结出来的，供你们的参考。

Java 基础

Java 是一门纯粹的面向对象的编程语言，所以除了基础语法之外，必须得弄懂它的 oop 特性：封装、继承、多态。此外还有泛型、反射的特性，很多框架的技术都依赖它，比如 Spring 核心的 Ioc 和 AOP，都用到了反射，而且 Java 自身的动态代理也是利用反射实现的，这里我特意写了一篇?Java动态代理原理分析。此外还有 Java 一些标准库也是非常常见，比如集合、I/O、并发，几乎在 Web 开发中无处不在，也是面试经常会被问到的，所以在自学 Java 后端之前，不妨先打好这些基础，另外还有 Java8 的一些新特性，也要重点关注，比如 Lambda 表达式、集合的 Stream 流操作、全新的 Date API 等等，关于新特性，我也写了几篇关于这方面的博客，请自行找吧，就不贴出来了。

关于书籍推荐，我是不建议初学者一开始就拿着「Java 编程思想」啃的，因为当初我就是那个当天下午决定自学 Java，晚上就抱着这本书啃的人，说实话，我当时真的不懂它在说啥，因为我没有一点的面向对象语言编程的基础，而这本书又写得太博大精深了，在当时的我来说，完全是天书，但是我认为它仍然是 Java 界的圣经，每读一次都有所收获。我在这里推荐你们一开始先看「Java 核心技术」，这本书讲得比较通俗易懂，初学者比较能接受。

关于视频推荐，我当初就是听某客的毕向东老师讲的 Java 基础教程，毕老师讲的实在是太生动有趣了，不知不觉把我带进 Java 的坑里无法自拔，有时候我会听他视频时笑出声来，也许是我那段自学阶段最有趣的时刻了。

数据库

关于 sql 方面：SQL 教程、MySQL 教程

我是了解了一些基础语法之后，就直接跟着视频的老师做一些表操作实战练习了，比如单表查询、多表查询等。我建议学 sql 切勿眼高手低，需多加练习，不要只看懂了就行，因为工作中写得一手简练的 sql 是非常重要的。在这里我说下我在项目一直秉承着 sql 语句是能避免多表查询就避免多表查询，能够分开多条语句就分开多条语句，因为这里涉及到多表查询性能和数据库扩展的问题。

关于 JDBC 方面：JDBC 教程、?JDBC 获取连接对象源码分析

你需要弄懂 JDBC API 的用法，其实它只是一组规范接口，所有数据库驱动只要实现了 JDBC，那么我们就可以通过标准的 API 调用相应的驱动，完全不用知道驱动是怎么实现的，这就是面向接口编程的好处。而且对于 JDBC 我是直接看视频去理解的，跟着视频做了一个基于 Apache Dbutils 工具做了一个具有事务性的小工具，我特意用思维导图总结了一下：

Web 基础

曾经开源中国创始人红薯写了一篇文章「初学 Java Web 开发，请远离各种框架，从 Servlet 开发」，我觉得他说的太对了，在如今 Java 开发中，很多开发者只知道怎么使用框架，但根本不懂 Web 的一些知识点，其实框架很多，但都基本是一个套路，所以在你学习任何框架前，请把 Web 基础打好，把 Web 基础打好了，看框架真的是如鱼得水。

关于 Http 协议，这篇文章就写得很清楚：Http协议

关于 Web 基础这方面数据推荐，我当时是看的是「Tomcat 与 Java Web 开发技术详解」，很详细地讲解了整个 Java Web 开发的技术知识点，但现在看来，我觉得里面讲的有一些技术确实有点老旧了，不过可以了解一下 Java Web 开发的历史也是不错的。所以在 Web 基础这方面我都是看某客的崔老师讲的「超全面 Java Web 视频教程」，讲得很详细很生动，还有实战项目！

关于 JSP，你只要了解它其实就是一个 Servlet 就行了，关于它的一些标签用法，我认为可以直接忽略，因为现在互联网几乎没哪间公司还用 JSP，除了一些老旧的项目。现在都是流行前后端分离，单页应用，后端只做 API 接口的时代了，所以时间宝贵，把这些时间重点放在 Servlet 规范上面吧。

关于 Tomcat，它是一个 Web 容器，我们写的后端项目都要部署到Web容器才能运行，它其实是一个遵循 Http，通过 Socket 通信与客户端进行交互的服务端程序：Tomcat结构及处理请求过程

Web 主流框架

Java Web 框架多如牛毛，等你有一定经验了，你也可以写一个 Web 框架，网上很多说 Spring、Struts2、Hibernate 是 Java 三架马车，我只想说，那是很久远的事情了，我严重不推荐 Struts2、Hibernate，相信我，一开始只需要上手 Spring、SpringMVC、Mybatis 就可以了，特别是 Spring 框架，其实 Spring 家族的框架都是很不错的。

但是提醒一点就是，千万不要沉迷于各种框架不能自拔，以会多种用法而沾沾自喜，导致知其然而不知其所以然。

Spring其核心思想就是 IOC 和 AOP：

谈谈对 Spring IOC 的理解

Spring 面向切面编程

SpringMVC 它的思想是全部请求统一用一个 Servlet 去做请求转发与控制，这个 Servlet 叫 DispatcherServlet：

SpringMVC 初始化过程

SpringMVC 处理请求过程

Mybatis 它可实现动态拼装 sql，避免了几乎所有的 JDBC 代码和手动设置参数以及获取结果集：

mybatis 入门教程

Mybatis 深入浅出系列

Web 框架进阶

使用了 SSM 框架后，你会觉得框架也不过这么回事，如果你对 Spring 有过大概了解，你也会产生想写一个「山寨版」Spring 的心思了，一个轻量级 Web 框架主要具备以下功能：

可读取用户自定义配置文件，并以此来初始化框架；

具备 Bean 容器，管理项目的类的对象生命周期；

具备依赖注入，降低类之间的耦合性；

具备 AOP 功能，使项目可进行横向编程，可不改变原有代码的情况增加业务逻辑；

具备 MVC 框架模式。

其实除了 SSM 之外，Web 框架可谓是百家齐放，其中以 Spring 全家桶最为耀眼，在这里我极力推荐两个 Spring 家族框架：SpringBoot 和 SpringCloud。

SpringBoot 弥补了 Spring 配置上的缺点，再也不用为繁杂的 xml 费劲精力了，堪称是 Java 后端开发的颠覆者，推荐书籍「Java EE 开发的颠覆者：SpringBoot实战」

SpringBoot 构建 web 项目

SpringBoot 自动化配置源码分析

自定义 SpringBoot Starter

spring-boot-starter-tutorial

SpringCloud 是一个微服务架构，能够将项目按照业务分成一个个微服务，每个微服务都可独立部署，服务之间互相协调。当一个项目越来越大时，随之而来的是越来越难以维护，此时将项目拆分成若干个微服务、单独维护、单独部署，也可以降低项目不同业务间的耦合度。推荐书籍「Spring Cloud 与 Docker 微服务架构实战」，这本书将 Docker 与微服务完美地结合在一起，堪称完美！

Spring Cloud 中文官网

史上最简单的 Spring Cloud 教程

我写的有关于 Spring Cloud 的博客：

SpringCloud微服务架构之服务注册与发现

SpringCloud微服务架构之服务消费者

SpringCloud微服务架构之断路器

SpringCloud微服务架构之服务网关

其它技术

Redis：一个高性能的 key-value 数据库，当有并发量很高的请求时，将数据缓存在 Redis 中，将提高服务器的响应性能，大大减轻数据库的压力。

redis 中文官网

redis 教程

Git：世界上最先进的分布式版本控制系统，建议所有初学者从命令行开始使用 Git！关注 stormzhang 公众号「googdev」，回复「github」，即可免费获取一份 GitHub 教程电子书，我觉得写得很不错。

Git 官网

最全 Git 教程

Git 的一些常用命令

Maven：一个用于构建项目的工具，将项目间的依赖通过 xml 完美地组织到一起，可通过编译插件将项目编译成字节码文件。还有类似的 Gradle 也是不错的选择。

maven 的 pom.xml 文件详解

Linux：至少要求常用的命令会用，能够在 linux 环境下部署项目。

Linux 命令大全

最全的 SSH 连接远程终端教程

Docker：简直是项目部署神器啊，来不及解释了，看我 Docker 系列博客，开启 Docker 之旅吧！推荐书籍「Docker 技术入门与实战」，中国首部 Docker 著作！

Docker 实战（一）

Docker 实战（二）

Docker 实战（三）

docker-deploy-tutorial

开发工具

工欲善其事，必先利其器，以下是我推荐的一些开发工具：

Intellij IDEA：Java 开发最好的 IDE，这个是公认的，我一开始是用 Eclipse 的，后来用了 Intellij IDEA，才发现 Eclipse 就是一坨屎，所以我以过来人劝你们不要使用 Eclipse，直接 Intellij IDEA！

IntelliJ IDEA 使用教程

Iterm2：macOS 最好用的终端！

Iterm2 使用指南

Chrome：人生苦短，请用 Chrome，来不及解释了，快上车！

Postman：很好用的一个接口调试工具。

微服务框架之Spring Cloud简介

在了解 Spring Cloud 之前先了解一下微服务架构需要考量的核心关键点，如下图：

对于以上等核心关键点的处理，不需要我们重复造车轮， Spring Cloud 已经帮我们集成了，它使用 Spring Boot 风格将一些比较成熟的微服务框架组合起来，屏蔽掉了复杂的配置和实现原理，为快速构建微服务架构的应用提供了一套基础设施工具和开发支持。

Spring Cloud 所提供的核心功能包含：

Spring Cloud架构图

Spring Cloud子项目

Spring Cloud 旗下的子项目大致可以分为两类：

如下：

1. Spring Cloud 与 Spring Boot

Spring Boot 可以说是微服务架构的核心技术之一。通过在 Spring Boot 应用中添加 Spring MVC 依赖，就可以快速实现基于 REST 架构的服务接口，并且可以提供对 HTTP 标准动作的支持。而且 Spring Boot 默认提供 JackJson 序列化支持，可以让服务接口输入、输出支持 JSON 等。因此，当使用 Spring Cloud 进行微服务架构开发时，使用 Spring Boot 是一条必经之路。

2. Spring Cloud 与服务治理( Eureka )

服务治理是 Spring Cloud 的核心，在实现上其提供了两个选择，即 Consul 和 Netflix 的 Eureka 。

Eureka 提供了服务注册中心、服务发现客户端，以及注册服务的 UI 界面应用。

在 Eureka 的实现中，节点之间相互平等，有部分注册中心“挂掉”也不会对整个应用造成影响，即使集群只剩一个节点存活，也可以正常地治理服务。即使所有服务注册节点都宕机， Eureka 客户端中所缓存的服务实例列表信息，也可让服务消费者能够正常工作，从而保障微服务之间互相调用的健壮性和应用的弹性。

3. Spring Cloud 与客户端负载均衡( Ribbon )

Ribbon 默认与 Eureak 进行无缝整合，当客户端启动的时候，从 Eureka 服务器中获取一份服务注册列表并维护在本地，当服务消费者需要调用服务时， Ribbon 就会根据负载均衡策略选择一个合适的服务提供者实例并进行访问。

Spring Cloud 通过集成 Netflix 的 Feign 项目，为开发者提供了声明式服务调用，从而简化了微服务之间的调用处理方式。并且默认 Feign 项目集成了 Ribbon ，使得声明式调用也支持客户端负载均衡功能。

4. Spring Cloud 与微服务容错、降级( Hystrix )

为了给微服务架构提供更大的弹性，在 Spring Cloud 中，通过集成 Netflix 下子项目 Hystrix ，通过所提供的 @HystrixCommand 注解可以轻松为我们所开发的微服务提供容错、回退、降级等功能。此外， Hystrix 也默认集成到 Feign 子项目中。

Hystrix 是根据“断路器”模式而创建。当 Hystrix 监控到某服务单元发生故障之后，就会进入服务熔断处理，并向调用方返回一个符合预期的服务降级处理（ fallback ），而不是长时间的等待或者抛出调用异常，从而保障服务调用方的线程不会被长时间、不必要地占用，避免故障在应用中的蔓延造成的雪崩效应。

而 Hystrix 的仪表盘项目（ Dashboard ）可以监控各个服务调用所消耗的时间、请求数、成功率等，通过这种近乎实时的监控和告警，可以及时发现系统中潜在问题并进行处理。

5. Spring Cloud 与服务网关( Zuul )

Spring Cloud 通过集成 Netflix 中的 Zuul 实现 API 服务网关功能，提供对请求的路由和过滤两个功能

路由功能负责将外部请求转发到具体的微服务实例上，是实现外部访问统一入口的基础。

过滤器功能则负责对请求的处理过程进行干预，是实现请求校验、服务聚合等功能的基础。

通过 Zuul ，可以将细粒度的服务组合起来提供一个粗粒度的服务，所有请求都导入一个统一的入口，对外整个服务只需要暴露一个 API 接口，屏蔽了服务端的实现细节。通过 Zuul 的反向代理功能，可以实现路由寻址，将请求转发到后端的粗粒度服务上，并做一些通用的逻辑处理。此外， Zuul 默认会与 Eureka 服务器进行整合，自动从 Eureka 服务器中获取所有注册的服务并进行路由映射，实现 API 服务网关自动配置。

6. Spring Cloud 与消息中间件( Stream )

Spring Cloud 为简化基于消息的开发，提供了 Stream 子项目，通过建立消息应用抽象层，构建了消息收发、分组消费和消息分片等功能处理，将业务应用中的消息收发与具体消息中间件进行解耦，使微服务应用开发中可以非常方便地与 Kafka 和 RabbitMQ 等消息中间件进行集成。

Spring Cloud Bus 基于 Stream 进行扩展，可以作为微服务之间的事件、消息总线，用于服务集群中状态变化的传播。

比如 Spring Cloud Config 借助 Bus ，可以实现配置的动态刷新处理。

7. Spring Cloud 与分布式配置中心( Config )

针对微服务架构下的配置文件管理需求， Spring Cloud 提供了一个 Config 子项目。 Spring Cloud Config 具有中心化、版本控制、支持动态更新和语言独立等特性。

在 Config 子项目中将微服务应用分为两种角色：配置服务器（ Config Server ）和配置客户端（ Config Client ）。使用配置服务器集中地管理所有配置属性文件，配置服务中心可以将配置属性文件存储到 Git 、 SVN 等具有版本管理仓库中，也可以存放在文件系统中。默认采用 Git 的方式进行存储，因此可以很容易地对配置文件进行修改，并实现版本控制。

8. Spring Cloud 与微服务链路追踪( Sleuth )

Spring Cloud 中的 Sleuth 子项目为开发者提供了微服务之间调用的链路追踪。

Sleuth 核心思想就是通过一个全局的 ID 将分布在各微服务服务节点上的请求处理串联起来，还原了调用关系，并借助数据埋点，实现对微服务调用链路上的性能数据的采集。

因此，通过 Sleuth 可以很清楚地了解到一个用户请求经过了哪些服务、每个服务处理花费了多长时间，从而可以对用户的请求进行分析。此外，通过将采集的数据发送给 Zipkin 进行存储、统计和分析，从而可以实现可视化的分析和展示，帮助开发者对微服务实施优化处理。

9. Spring Cloud 与微服务安全( Security )

Spring Cloud Security 为我们提供了一个认证和鉴权的安全框架，实现了资源授权、令牌管理等功能，同时结合 Zuul 可以将认证信息在微服务调用过程中直接传递，简化了我们进行安全管控的开发。

Spring Cloud Security 默认支持 OAuth 2.0 认证协议，因此单点登录也可以非常容易实现，并且 OAuth2.0 所生成的令牌可以使用 JWT 的方式，进一步简化了微服务中的安全管理。

10. Spring Cloud 的其他子项目

spring cloud和dubbo哪个会被淘汰？

个人觉的两者都不会被淘汰，但是在未来分布式微服务解决方案中或者架构中，springCloud会占主导地位。

springCloud：

1.springCloud提供了完成的分布式解决方案，基础解决方案以及组件比较健全，而且最近几年围绕springCloud边缘服务组件越来越多，例如：nacos。

2.springCloud是基于springboot的，spring的使用部署太方便了。

dubbo：

1.dubbo更多解决的是服务间的调用，也就是服务通讯协议rpc，也会是dubbo没有完整的分布式解决方案基础设施。例如：注册中心需要借助Zookeper，链路追踪：zipkin。

要说Dubbo，算是Spring Cloud的一个子集好了,大致相当于Spring Cloud里的 Eureka + Feign + 1/2Hystrix另外

现在大公司也在慢慢想springCloud服务过度，还有面试中文springCloud问题越来阅读，dubbo越来越少。

dubbo生态圈没有spring cloud好，会被先淘汰掉。现有架构都会优先选择Spring cloud，毕竟使用起来更简单一点。

微服务现在是一阵风而已，实际来说，很多系统不适用，综合算下来，微服务成本比原来大多了。不是所有系统都是互联网，都是弹缩性很强。有的系统就是固定数据量，稳定运行，可能几个大一点服务器就足够了。

真正需要微服务的不会像现在看到的那么多。

慢慢沉淀，估计会把一些不需要的改回去，套壳的改回去。

如果简化方式，感觉dubbo这种轻便的有优势，开发运维都简单。或者替代品也是轻便为主。

剩的可能真的需要微服务，一般都是中等规模以上的，或者巨头，一般都有自己的内部框架。这种用也得全套完善的。

它们都淘汰也是早晚的事[捂脸]毕竟是java闭源。随着service mesh的兴起，isito的落地并于k8s的无缝融合，一切像基础设施下沉[呲牙]

事实上，很多系统根本就没必要用什么所谓微服务。目前过度设计已经泛滥，明明是一个用户数量有限，功能并不复杂的系统，也要套用所谓的微服务架构，或者要大搞所谓中台，既浪费时间，又浪费金钱，最后系统运维还比较复杂，需要持续投入运维。

以服务调用的方式，固然可以有更好的复用性，也可以解耦复杂系统。但实际上，我认为微服务也仅仅是组件化的一种实现方式。对于组件化，广义的讲，有多种实现方式：

第一种，最原始的方式就是以静态函数库或者包的形式存在。这种形式优点是开发方式简单，调用效率高，数据以参数方式进行传递，但耦合度也高，底层组件函数一旦发生变化，则需要重新编译整个工程。通常对于不经常发生变化的基础函数库，可以用这种形式进行开发，形成所谓的公共函数库，供大家使用。

第二种，称之为动态函数库，在windows环境下以dll形式存在，linux环境下以so形式存在。动态函数库相对于静态函数库，优势在于可以在运行时动态加载，可以在不用重新启动整个应用的情况下进行更新。缺点是动态函数不能共享原应用程序的存储空间，导致动态函数调用有时需要传递大量参数，导致一些不便。动态函数库也具有一定耦合度，函数名和参数必须严格按照约定调用，否则会报错。在早期单体架构下，动态函数库还是有大量使用的。

第三种，就是目前所谓的微服务架构了。微服务事实上也是可以看作是一种函数调用方式，提供基于RPC和restful远程调用方式。调用时需要传递调用的服务名称及数据报文。这种方式耦合度自然是比较低一些的，但是调用效率肯定低于函数调用方式，主要是数据传输和报文解析方面消耗的时间。此外还需要考虑通讯流量控制，超时机制，服务寻址，服务可用性等方面的问题。因而降低耦合度，事实上是以增加了系统的整体复杂度和降低调用效率为代价的。个人认为不应该过度解耦，或者仅仅强调可复用性。要知道，任何事情都是有代价的，必须要充分评估这种代价是否值得。

第四种，就更进一步，即以独立的系统存在，该系统具有独立性和完备性，可以不过于依赖其他外部系统独立运行，对外部以服务或api的形式进行交互。例如，单点登录系统，信贷系统，核心系统等。

因而，在系统架构设计和建设过程中，必须认真进行评估，不应该过分侧重于某一方面特性的实现，否则就是过犹不及，最后导致整体出现问题。

个人认为，目前大部分所谓基于微服务的中台系统就是陷入了过于强调解耦的误区，导致过度的解耦设计，而忽略了由此带来的弊端，最后陷入了泥潭。

分层是计算机科学永恒的主题，service mesh是微服务的未来，这样看来这两个以后都会被取代，只有spring boot能够继续存活。

这是两个作用和使用场景不同的框架，目前的情况来看都不会被淘汰。

springcloud用于微服务，dubbo用于服务治理，各有各的适用场景。

在国外springcloud使用的多，在国内dubbo使用的多。

springcloud由国外的spring团队开发维护，热度和可靠性不用多说，dubbo由国内的阿里巴巴开发，现交由Apache孵化器，可靠性也很高。

Spring cloud是当前主流的微服务架构，轻便，插件式的设计理念很赢得当前开发及企业的青睐，在很多方面优于dubbo的架构设计，我认为dubbo最终会被淘汰，但短时间内不会，因为很多金融机构之前很多系统用的是dubbo架构，金融机构在短时间内考虑系统和业务的稳定性不会立刻就更新换代

dubbo

对内rpc，对外http，dubbo效率比httpclient高很多

Spring Cloud

本文中我们主要介绍微服务开发框架——Spring Cloud。尽管Spring Cloud带有"Cloud"的字样，但它并不是云计算解决方案，而是Spring Boot的基础上构建的，用于快速构建分布式系统的通用模式的工具集。

Spring Cloud有以下特点:

由上图可知，Spring Cloud是以 英文单词+SR+数字 的形式命名版本号的。那么英文单词和SR分别表示什么呢？

因为Spring Cloud是一个综合项目，它包含很多子项目。由于子项目也维护着自己的版本号，Spring Cloud采用了这种命名方式，从而避免与子项目的版本混淆。其中英文单词如Edware是伦敦某地铁站名，它们按照字母顺序发行，可以将其理解为主版本的演进。SR表示"Service Release"，一般表示Bug修复。

版本兼容性如下

版本内容

可参考官方文档：

我的上一篇博客(微服务理论篇)中谈到，对单体应用进行服务拆分得到各个微服务，而这些服务又是相互独立的，那么我们如何知道各个微服务的健康状态、如何知道某个微服务的存在呢？由此、一个拥有服务发现的框架显得尤为重要。这也就是Eureka诞生的原因。

综上，Eureka通过心跳检查、客户端缓存等机制，确保了系统的高可用性、灵活性和可伸缩性。

通过使用Eureka已经实现了微服务的注册与发现。启动各个微服务时，Eureka Client会把自己的网络信息注册到Eureka Server上。似乎一切更美好了一些。然而，这样的架构依然有一些问题，如负载均衡。一般来说，各个微服务都会部署多个实例。那么服务消费者要如何将请求分摊到多个服务提供实例上呢？

如果服务提供者相应非常慢，那么消费者对提供者的请求就会被强制等待，知道提供者响应或超时。在高负载场景下，如果不作任何处理，此类问题可能会导致服务消费者的资源耗竭甚至整个系统崩溃。

微服务架构的应用系统通常包含多个服务层。微服务之间通过网络进行通信，从而支撑起整个应用系统，因此，微服务之间难免存在依赖关系。而这种由于"基础服务故障"导致"级联故障"的现象称为雪崩效应。

如图所示，A最为服务提供者（基础服务），B为A的服务消费者，C和D是B的服务消费者。当A不可用引起了B的不可用，并将不可用像滚雪球一样放大到C和D时，雪崩效应就形成了。

那么Hystrix是如何容错的呢？

以下对该图做个简单讲解：

Zuul作为微服务架构中的微服务网关。微服务架构经过前几个组件的组合，已经有了基本的雏形了，那么我们为什么还要使用微服务网关呢？我们可以想象，一般情况下我们一个业务并不是只调用一个接口就可以完成一个业务需求。

如果让客户端直接与各个微服务通信，会有以下问题：

如图，微服务网关封装了应用程序的内部结构，客户端只须跟网关交互，而无须直接调用特定微服务接口。同时，还有以下优点：

为什么要同一管理微服务配置？

对于传统的单体应用，常常使用配置文件管理所有配置。例如一个Spring Boot 项目开发的单体应用，可以将配置内容放到application.yml文件中。如果需要切换环境，可以设置多个Profile,并在启用应用时指定spring.profile.active={profile}。

而在微服务架构中，微服务的配置管理一般有以下需求：