from: https://stackoverflow.com/questions/43956072/how-to-read-multiple-config-file-from-spring-cloud-config-server 一个Client需要从Config Server读取多个配置的解决方案。 通常是 ，虽然也会有些问题（见第二个answer，但主体这样就能应对大多数场景了。但经过测试，很多common的property，是不需要加profile信息的，这样可能并不需要完全对name和profile做排列组合，但这也会使得所有的env用同一份配置），加载顺序为从前到后，后面的覆盖前面的 How to read multiple config file from Spring Cloud Config Server Spring cloud config server supports reading property files with name ${spring.application.name}.properties. However I have 2 properties files in my application. Can I get the config server to read both these properties files? 4 Answers Rename your properties files […]

概述 在微服务间使用Feign进行远程调用时需要在 header 中添加信息，那么 springcloud open feign 如何设置 header 呢？有5种方式可以设置请求头信息: 在@RequestMapping注解里添加headers属性 在方法参数前面添加@RequestHeader注解 在方法或者类上添加@Headers的注解 在方法参数前面添加@HeaderMap注解 实现RequestInterceptor接口 示例说明 由于Feign是完全支持Spring MVC注解的, 所以推荐使用前两种Feign设置header的方式, 即: Spring MVC中使用注解设置header. 在@RequestMapping注解里添加headers属性 在application.yml中配置 app.secret: appSecretVal 编写feignClient @PostMapping(value = “/book/api”, headers = {“Content-Type=application/json;charset=UTF-8”,                                             […]

转自：大佬的专栏 这篇文章介绍下微服务中的一个重要角色：网关，对于网关如何选择，这里选择了Spring cloud Gateway。 文章目录如下： 为什么需要网关？ 传统的单体架构中只有一个服务开放给客户端调用，但是微服务架构中是将一个系统拆分成多个微服务，那么作为客户端如何去调用这些微服务呢？如果没有网关的存在，只能在本地记录每个微服务的调用地址。 无网关的微服务架构往往存在以下问题： 客户端多次请求不同的微服务，增加客户端代码或配置编写的复杂性。 认证复杂，每个服务都需要独立认证。 存在跨域请求，在一定场景下处理相对复杂。 网关的基本功能？ 网关是所有微服务的门户，路由转发仅仅是最基本的功能，除此之外还有其他的一些功能，比如：认证、鉴权、熔断、限流、日志监控等等……… “ 以上这些应用场景会在后续的文章详细介绍，不是今天的重点。 ” 为什么选择Spring cloud Gateway？ 在1.x版本中都是采用的Zuul网关；但在2.x版本中，zuul的升级一直跳票，Spring Cloud最后自己研发了一个网关替代Zuul，那就是Spring Cloud Gateway。 肯定选择亲儿子Spring Cloud Gateway，它的很多思想都是借鉴zuul，所谓青出于蓝而胜于蓝，功能和性能肯定是优于zuul，不然Spring Cloud 为嘛要发布它？ 重要的一点原因： “ Spring Cloud Gateway 基于Spring Boot 2.x、Spring WebFlux和[Project Reactor构建。 ” 对于Spring Boot 的整合方便兼容性以及性能方面不必担心。 Spring Cloud Gateway几个必知的术语？ 路由（route）：gateway的基本构建模块。它由ID、目标URI、断言集合和过滤器集合组成。如果聚合断言结果为真，则匹配到该路由。 断言（Predicate ）：参照Java8的新特性Predicate，允许开发人员匹配HTTP请求中的任何内容，比如头或参数。 过滤器（filter）：可以在返回请求之前或之后修改请求和响应的内容。 网关如何搭建？ 为什么要放这张图？ “ 一定要按照上图中的版本进行适配，否则会出现意想不到的BUG……….. ” 新建cloud-gateway9023，添加如下依赖： […]

转自：大佬的专栏，并做了部分调整 前言 这篇文章主要介绍一些目前主流的几种分布式解决方案以及阿里开源的一站式分布式解决方案Seata。 文章目录如下： 什么是分布式事务？ 分布式对应的是单体架构，互联网早起单体架构是非常流行的，好像是一个家族企业，大家在一个家里劳作，单体架构如下图： 但是随着业务的复杂度提高，大家族人手不够，此时不得不招人，这样逐渐演变出了分布式服务，互相协作，每个服务负责不同的业务，架构如下图： 因此需要服务与服务之间的远程协作才能完成事务，这种分布式系统环境下由不同的服务之间通过网络远程协作完成事务称之为分布式事务，例如用户注册送积分 事务、创建订单减库存事务，银行转账事务等都是分布式事务。 典型的场景就是微服务架构 微服务之间通过远程调用完成事务操作。比如：订单微服务和库存微服务，下单的同时订单微服务请求库存微服务减库存。简言之：跨JVM进程产生分布式事务。 什么是CAP原则？ CAP 理论/定理 起源于 2000年，由加州大学伯克利分校的Eric Brewer教授在分布式计算原理研讨会（PODC）上提出，因此 CAP定理又被称作 布鲁尔定理（Brewer’s theorem） 2年后，麻省理工学院的Seth Gilbert和Nancy Lynch 发表了布鲁尔猜想的证明，CAP理论正式成为分布式领域的定理。 CAP原则又叫CAP定理，同时又被称作布鲁尔定理（Brewer’s theorem），指的是在一个分布式系统中，不可能同时满足以下三点。 一致性（Consistency） 指强一致性，在写操作完成后开始的任何读操作都必须返回该值，或者后续写操作的结果。 也就是说，在一致性系统中，一旦客户端将值写入任何一台服务器并获得响应，那么之后client从其他任何服务器读取的都是刚写入的数据 一致性保证了不管向哪台服务器写入数据，其他的服务器能实时同步数据 可用性（Availability） 可用性（高可用）是指：每次向未崩溃的节点发送请求，总能保证收到响应数据（允许不是最新数据） 分区容忍性（Partition tolerance） 分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务，也就是说，服务器A和B发送给对方的任何消息都是可以放弃的，也就是说A和B可能因为各种意外情况，导致无法成功进行同步，分布式系统要能容忍这种情况。除非整个网络环境都发生了故障。 一个分布式系统里面，节点组成的网络本来应该是连通的。然而可能因为一些故障，使得有些节点之间不连通了，整个网络就分成了几块区域。数据就散布在了这些不连通的区域中。这就叫分区。 当你一个数据项只在一个节点中保存，那么分区出现后，和这个节点不连通的部分就访问不到这个数据了。这时分区就是无法容忍的。 提高分区容忍性的办法就是一个数据项复制到多个节点上，那么出现分区之后，这一数据项就可能分布到各个区里。容忍性就提高了。 然而，要把数据复制到多个节点，就会带来一致性的问题，就是多个节点上面的数据可能是不一致的。要保证一致，每次写操作就都要等待全部节点写成功，而这等待又会带来可用性的问题。 总的来说就是，数据存在的节点越多，分区容忍性越高，但要复制更新的数据就越多，一致性就越难保证。为了保证一致性，更新所有节点数据所需要的时间就越长，可用性就会降低。 为什么只能在A和C之间做出取舍？ 分布式系统中，必须满足 CAP 中的 P，此时只能在 C/A 之间作出取舍。 如果选择了CA，舍弃了P，说白了就是一个单体架构。 一致性有几种分类？ CAP理论告诉我们只能在C、A之间选择，在分布式事务的最终解决方案中一般选择牺牲一致性来获取可用性和分区容错性。 这里的 “牺牲一致性” 并不是完全放弃数据的一致性，而是放弃强一致性而换取弱一致性。 一致性可以分为以下三种： 强一致性 弱一致性 最终一致性 强一致性 系统中的某个数据被成功更新后，后续任何对该数据的读取操作都将得到更新后的值。 也称为：原子一致性（Atomic […]

转自：大佬的专栏 1、前言 这篇文章介绍一下阿里开源的流量防卫兵Sentinel，一款非常优秀的开源项目，经过近10年的双十一的考验，非常成熟的一款产品。 但开源的Sentinel尚存在许多的问题，完整的体验还是需要使用阿里的Sentinel产品（未开源），这里不再多说。 文章目录如下： 2、什么是sentinel？ sentinel顾名思义：卫兵；在Redis中叫做哨兵，用于监控主从切换，但是在微服务中叫做流量防卫兵。 Sentinel 以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。 Sentinel 具有以下特征: 丰富的应用场景：Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。 完备的实时监控：Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机器秒级数据，甚至 500 台以下规模的集群的汇总运行情况。 广泛的开源生态：Sentinel 提供开箱即用的与其它开源框架/库的整合模块，例如与 Spring Cloud、Apache Dubbo、gRPC、Quarkus 的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入 Sentinel。同时 Sentinel 提供 Java/Go/C++ 等多语言的原生实现。 完善的 SPI 扩展机制：Sentinel 提供简单易用、完善的 SPI 扩展接口。您可以通过实现扩展接口来快速地定制逻辑。例如定制规则管理、适配动态数据源等。 Sentinel 的主要特性如下图： Sentinel 分为两个部分: 核心库（Java 客户端）不依赖任何框架/库，能够运行于所有 Java 运行时环境，同时对 Dubbo / Spring Cloud 等框架也有较好的支持。 控制台（Dashboard）基于 Spring Boot 开发，打包后可以直接运行，不需要额外的 Tomcat 等应用容器。 […]

转自：大佬的专栏 1、前言 微服务的注册中心目前主流的有以下五种： Zookeeper Eureka Consul Nacos Kubernetes 那么实际开发中到底如何选择呢？这是一个值得深入研究的事情，别着急，今天就带大家深入了解一下这五种注册中心以及如何选型的问题。 2、为什么需要注册中心？ 随着单体应用拆分，首当面临的第一份挑战就是服务实例的数量较多，并且服务自身对外暴露的访问地址也具有动态性。可能因为服务扩容、服务的失败和更新等因素，导致服务实例的运行时状态经常变化，如下图: 商品详情需要调用营销、订单、库存三个服务，存在问题有： 营销、订单、库存这三个服务的地址都可能动态的发生改变，单存只使用配置的形式需要频繁的变更，如果是写到配置文件里面还需要重启系统，这对生产来说太不友好了; 服务是集群部署的形式调用方负载均衡如何去实现； 解决第一个问题办法就是用我们用伟人说过一句话，没有什么是加一个中间层解决不了的，这个中间层就是我们的注册中心。 解决第二问题就是关于负载均衡的实现，这个需要结合我们中间层老大哥来实现。 3、如何实现一个注册中心？ 对于如何实现注册中心这个问题，首先将服务之间是如何交互的模型抽象出来，我们结合实际的案例来说明这个问题，以商品服务为例： 当我们搜索商品的时候商品服务就是提供者； 当我们查询商品详情的时候即服务的提供者又是服务的消费者，消费是订单、库存等服务；由此我们需要引入的三个角色就是:中间层(注册中心)、生产者、消费者，如下图: 整体的执行流程如下: 在服务启动时，服务提供者通过内部的注册中心客户端应用自动将自身服务注册到注册中心，包含主机地址、服务名称等等信息； 在服务启动或者发生变更的时候，服务消费者的注册中心客户端程序则可以从注册中心中获取那些已经注册的服务实例信息或者移除已下线的服务； 上图还多一个设计缓存本地路由，缓存本地路由是为了提高服务路由的效率和容错性，服务消费者可以配备缓存机制以加速服务路由。更重要的是，当服务注册中心不可用时，服务消费者可以利用本地缓存路由实现对现有服务的可靠调用。 在整个执行的过程中，其中有点有一点是比较难的，就是服务消费者如何及时知道服务的生产者如何及时变更的，这个问题也是经典的生产者消费者的问题，解决的方式有两种: 发布-订阅模式：服务消费者能够实时监控服务更新状态，通常采用监听器以及回调机制，经典的案例就是Zookeeper； 主动拉取策略：服务的消费者定期调用注册中心提供的服务获取接口获取最新的服务列表并更新本地缓存,经典案例就是Eureka； 对于如何选择这两种方式，其实还有一个数据一致性问题可以聊聊，比如选择定时器肯定就抛弃了一致性，最求的是最终一致，这里就不深入展开了，另外你可能还会说服务的移除等等这些功能都没介绍，在我看来那只是一个附加功能，注册中心重点还是在于服务注册和发现，其他都是锦上添花罢了。 4、如何解决负载均衡的问题？ 负载均衡的实现有两种方式: 服务端的负载均衡； 客户端的负载均衡; 对于实现的方案来说本质上是差不多的，只是说承接的载体不一样，一个是服务端，一个客户端，如下图: 服务端的负载均衡，给服务提供者更强的流量控制权，但是无法满足不同的消费者希望使用不同负载均衡策略的需求。 客户端的负载均衡则提供了这种灵活性，并对用户扩展提供更加友好的支持。但是客户端负载均衡策略如果配置不当，可能会导致服务提供者出现热点，或者压根就拿不到任何服务提供者。 服务端负载均衡典型的代表就是Nginx，客户端负载均衡典型代表是Ribbon，每种方式都有经典的代表，我们都是可以深入学习的。 常见的负载均衡器的算法的实现，常见的算法有以下六种: 1、轮询法 将请求按顺序轮流地分配到后端服务器上，它均衡地对待后端的每一台服务器，而不关心服务器实际的连接数和当前的系统负载。 2、随机法 通过系统的随机算法，根据后端服务器的列表大小值来随机选取其中的一台服务器进行访问。由概率统计理论可以得知，随着客户端调用服务端的次数增多；其实际效果越来越接近于平均分配调用量到后端的每一台服务器，也就是轮询的结果。 3、哈希算法 哈希的思想是根据获取客户端的IP地址，通过哈希函数计算得到的一个数值，用该数值对服务器列表的大小进行取模运算，得到的结果便是客服端要访问服务器的序号。采用源地址哈希法进行负载均衡，同一IP地址的客户端，当后端服务器列表不变时，它每次都会映射到同一台后端服务器进行访问。 4、加权轮询法 不同的后端服务器可能机器的配置和当前系统的负载并不相同，因此它们的抗压能力也不相同。给配置高、负载低的机器配置更高的权重，让其处理更多的请；而配置低、负载高的机器，给其分配较低的权重，降低其系统负载，加权轮询能很好地处理这一问题，并将请求顺序且按照权重分配到后端。 5.加权随机法 与加权轮询法一样，加权随机法也根据后端机器的配置，系统的负载分配不同的权重。不同的是，它是按照权重随机请求后端服务器，而非顺序。 6.最小连接数法 最小连接数算法比较灵活和智能，由于后端服务器的配置不尽相同，对于请求的处理有快有慢，它是根据后端服务器当前的连接情况，动态地选取其中当前 积压连接数最少的一台服务器来处理当前的请求，尽可能地提高后端服务的利用效率，将负责合理地分流到每一台服务器。 5、注册中心如何选型？ 现在注册中心的选择也是五花八门，现阶段比较流行有以下几种: 在介绍这个之前大家有些需要了解的知识有CAP、Paxos、Raft算法这里我就不进行过多介绍了。开始介绍以上5种实现注册中心的方式。 1、Zookeeper 这个说起来有点意思的是官方并没有说他是一个注册中心，但是国内Dubbo场景下很多都是使用Zookeeper来完成了注册中心的功能。 […]

转自：大佬的专栏 今天这篇文章将从10个维度介绍一下配置中心的选型问题，为什么要写这篇文章呢？是因为： 工作所需，要做一款好用的开源产品，去试用提供相似功能的开源产品是必要的环节，以找出优势，弥补不足； 用户所需，对于提供相似功能的产品进行选型对比，是引入某个开源项目必须要做的事，如果有一份参考，那么势必能提供一些帮助；（建议：即便有一份可参考的材料，技术选型的工作仍需要亲力亲为，实际的业务场景和资源配置才是技术选型最重要的依据）； 微服务配置中心是一个微服务组件，而不是一个大的框架，选型成本较小，客观对比时不易走偏； 本文将从产品功能、使用体验、实施过程和性能4个纬度进行对比，所有素材均来源于该开源项目的官网或GitHub项目页。 如果您对微服务配置中心的功能不是很了解，可以看下以下的背景介绍，若比较熟悉可以直接跳过。 1、为什么需要配置中心 1、配置实时生效 传统的静态配置方式要想修改某个配置只能修改之后重新发布应用，要实现动态性，可以选择使用数据库，通过定时轮询访问数据库来感知配置的变化。轮询频率低感知配置变化的延时就长，轮询频率高，感知配置变化的延时就短，但比较损耗性能，需要在实时性和性能之间做折中。配置中心专门针对这个业务场景，兼顾实时性和一致性来管理动态配置。 2、配置管理流程 配置的权限管控、灰度发布、版本管理、格式检验和安全配置等一系列的配置管理相关的特性也是配置中心不可获取的一部分。 2、开源配置中心基本介绍 目前市面上用的比较多的配置中心有：（按开源时间排序） Disconf 2014年7月百度开源的配置管理中心，同样具备配置的管理能力，不过目前已经不维护了，最近的一次提交是两年前了。 Spring Cloud Config 2014年9月开源，Spring Cloud 生态组件，可以和Spring Cloud体系无缝整合。 Apollo 2016年5月，携程开源的配置管理中心，具备规范的权限、流程治理等特性。 Nacos 2018年6月，阿里开源的配置中心，也可以做DNS和RPC的服务发现。 3、配置中心核心概念的对比 由于Disconf不再维护，下面对比一下Spring Cloud Config、Apollo和Nacos。Spring Cloud Config、Apollo和Nacos在配置管理领域的概念基本相同，但是也存在一些不同的点，使用配置的过程中会涉及到一些比较重要的概念。 1、应用 应用是客户端系统的基本单位，Spring Cloud Config 将应用名称和对应Git中的文件名称关联起来了，这样可以起到多个应用配置相互隔离的作用。Apollo的配置都是在某个应用下面的（除了公共配置），也起到了多个应用配置相互隔离的作用。Nacos的应用概念比较弱，只有一个用于区分配置的额外属性，不过可以使用 Group 来做应用字段，可以起到隔离作用。 2、集群 不同的环境可以搭建不同的集群，这样可以起到物理隔离的作用，Spring Cloud Config、Apollo、Nacos都支持多个集群。 3、 Label Profile & 环境 & 命名空间 Spring Cloud Config可以使用Label和Profile来做逻辑隔离，Label指远程仓库的分支，Profile类似Maven Profile可以区分环境，比如{application}-{profile}.properties。 […]

转：自专栏 1、前言 前面介绍了Spring Cloud 中的灵魂摆渡者Nacos，和它的前辈们相比不仅仅功能强大，而且部署非常简单。 今天介绍一款服务调用的组件：OpenFeign，同样是一款超越先辈（Ribbon、Feign）的狠角色。 文章目录如下： 2、Feign是什么？ Feign也是一个狠角色，Feign旨在使得Java Http客户端变得更容易。 Feign集成了Ribbon、RestTemplate实现了负载均衡的执行Http调用，只不过对原有的方式（Ribbon+RestTemplate）进行了封装，开发者不必手动使用RestTemplate调服务，而是定义一个接口，在这个接口中标注一个注解即可完成服务调用，这样更加符合面向接口编程的宗旨，简化了开发。 但遗憾的是Feign现在停止迭代了，当然现在也是有不少企业在用。 有想要学习Feign的读者可以上spring Cloud官网学习，这里也不再详细介绍了，不是今天的重点。 3、openFeign是什么？ 前面介绍过停止迭代的Feign，简单点来说：OpenFeign是springcloud在Feign的基础上支持了SpringMVC的注解，如@RequestMapping等等。OpenFeign的@FeignClient可以解析SpringMVC的@RequestMapping注解下的接口，并通过动态代理的方式产生实现类，实现类中做负载均衡并调用其他服务。 官网地址：https://docs.spring.io/spring-cloud-openfeign/docs/2.2.10.BUILD-SNAPSHOT/reference/html 4、Feign和openFeign有什么区别？ Feign openFiegn Feign是SpringCloud组件中一个轻量级RESTful的HTTP服务客户端，Feign内置了Ribbon，用来做客户端负载均衡，去调用服务注册中心的服务。Feign的使用方式是：使用Feign的注解定义接口，调用这个接口，就可以调用服务注册中心的服务 OpenFeign 是SpringCloud在Feign的基础上支持了SpringMVC的注解，如@RequestMapping等。OpenFeign 的@FeignClient可以解析SpringMVC的@RequestMapping注解下的接口，并通过动态代理的方式产生实现类，实现类中做负载均衡并调用其他服务。 5、环境准备 本篇文章Spring Cloud版本、JDK环境、项目环境均和上一篇Nacos的环境相同 注册中心就不再使用Eureka了，直接使用Nacos作为注册和配置中心，有不会的可以查看Nacos文章。 本篇文章搭建的项目结构如下图： 注册中心使用Nacos，创建个微服务，分别为服务提供者Produce，服务消费者Consumer。 6、创建服务提供者 既然是微服务之间的相互调用，那么一定会有服务提供者了，创建openFeign-provider9005，注册进入Nacos中，配置如下： 注意：此处的spring.application.name指定的名称将会在openFeign接口调用中使用。 7、创建服务消费者 新建一个模块openFeign-consumer9006作为消费者服务，步骤如下。 1、添加依赖 除了Nacos的注册中心的依赖，还要添加openFeign的依赖，如下： 2、添加注解@EnableFeignClients开启openFeign功能 老套路了，在Spring boot 主启动类上添加一个注解@EnableFeignClients，开启openFeign功能，如下： 3、新建openFeign接口 新建一个openFeign接口，使用@FeignClient注解标注，如下： 注意：该注解@FeignClient中的value属性指定了服务提供者在nacos注册中心的服务名。 4、新建一个Controller调试 新建一个controller用来调试接口，直接调用openFeign的接口，如下： 好了，至此一个openFeign的微服务就搭建好了，并未实现具体的功能，下面一点点实现。 8、openFeign如何传参？ 开发中接口传参的方式有很多，但是在openFeign中的传参是有一定规则的，下面详细介绍。 1、传递JSON数据 这个也是接口开发中常用的传参规则，在Spring Boot 中通过@RequestBody标识入参。 provider接口中JSON传参方法如下： consumer中openFeign接口中传参代码如下： […]

转：Spring Cloud 专栏 前言 Nacos是阿里巴巴开源的服务注册中心以及配置中心，致力于给开发者提供一款便捷、简单上手的开源框架。 Nacos究竟有什么惊人的地方呢？看下图： 从上图不难看出阿里巴巴的野心，一个Nacos干掉了Spring Cloud的三大组件，分别是注册中心Eureka、服务配置Config，服务总线Bus。 本文目录结构如下图： 为什么Nacos这么受欢迎？ Nacos官方文档的介绍中有这么一句话，如下： Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。Nacos 是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。 什么意思呢？不着急，有对比才有伤害。 Eureka、Config这两个组件相信大家都用过，有什么感受？ 当然，这两个组件给我最直观的感受就是繁琐，原因如下： 无论是Eureka还是Config都必须自己搭建个服务 英文界面不是那么友好 用过Nacos的开发者都说很爽，不用自己搭建服务，阿里给你准备好了服务，只需要启动即可；界面中英文都有，很适合初学者。 当然最重要的原因就是以上组件很可能面临停更、比如Eureka已经停更了，谁知道后面其他的组件会不会如此呢？ 如何自学呢？ 对于初学者当然是官方文档了，下面作者列出了Nacos相关的官方文档： https://nacos.io/zh-cn/docs/what-is-nacos.html（中英文兼备） https://spring-cloud-alibaba-group.github.io/github-pages/hoxton/en-us/index.html（英文） https://github.com/alibaba/nacos（Nacos项目仓库） 本文版本说明 基于Maven构建的微服务项目，各个组件版本如下： JDK1.8+ Spring Boot-2.2.2.RELEASE SpringCloud-Hoxton.SR3 SpringCloud Alibaba-2.2.1.RELEASE 注意：Spring Boot、Spring Cloud、Spring Cloud Alibaba的版本可不是随便选择的，官网明确规定了各个版本的适配：https://github.com/alibaba/spring-cloud-alibaba/wiki，如下图： 不同版本的Alibaba也对应了不同组件的版本，如下图： 一定要完全按照文档给出的版本来选择，不然会出现意想不到的BUG，那岂不是鸡鸡…. 作者使用的是分模块的聚合项目演示，其中dependencyManagement依赖如下，对应着上文提到的版本： 注意：如果你的版本的不是和作者一样，请一定严格按照官方文档给的版本进行适配，否则会有意想不到的BUG…. 启动Nacos服务 根据上面作者选择的Spring Cloud Alibaba的版本，对应的Nacos版本是1.2.1，直接去GitHub(https://github.com/alibaba/nacos/tags)下载对应的版本即可，可以选择windows或者Linux，如下图： 下载完成之后直接解压即可，从它的目录结构和文件名称一看这就是一个Spring Boot 项目。 进入/bin目录，有两个脚本，如下： startup.cmd：windows平台的启动脚本 startup.sh：Linux平台的启动脚本 […]