二、Spring Cloud

2.1、什么是SpringCloud

SpringCloud是一个含概多个子项目的开发工具集,集合了众多的开源框架,他利用了Spring Boot开发的便利性实现了很多功能,如服务注册,服务注册发现,负载均衡等.SpringCloud在整合过程中主要是针对Netflix(奈飞)开源组件的封装.SpringCloud的出现真正的简化了分布式架构的开发。

NetFlix 是美国的一个在线视频网站,微服务业的翘楚,他是公认的大规模生产级微服务的杰出实践者,NetFlix的开源组件已经在他大规模分布式微服务环境中经过多年的生产实战验证,因此Spring Cloud中很多组件都是基于NetFlix组件的封装。

2.2、核心组件

eurekaserver、consul、nacos：服务注册中心组件。

rabbion & openfeign：服务负载均衡 和 服务调用组件。

hystrix & hystrix dashboard：服务断路器和服务监控组件。

zuul、gateway：服务网关组件。

config：统一配置中心组件。

bus：消息总线组件。

2.3、版本命名

SpringCloud是一个由众多独立子项目组成的大型综合项目，原则每个子项目上有不同的发布节奏,都维护自己发布版本号。为了更好的管理springcloud的版本,通过一个资源清单BOM(Bill of Materials),为避免与子项目的发布号混淆，所以没有采用版本号的方式，而是通过命名的方式。这些名字是按字母顺序排列的。如伦敦地铁站的名称（“天使”是第一个版本，“布里斯顿”是第二个版本,"卡姆登"是第三个版本）。当单个项目的点发布累积到一个临界量，或者其中一个项目中有一个关键缺陷需要每个人都可以使用时，发布序列将推出名称以“.SRX”结尾的“服务发布”，其中“X”是一个数字。

伦敦地铁站的名字大致有如下：Angel、Brixton、Camden、Dalston、Edgware、Finchley、Greenwich、Hoxton。

2.4、版本选择

由于SpringCloud的版本是必须和SpringBoot的版本对应的，所以必须要根据SpringCloud版本来选择SpringBoot的版本。

三、SpringCloud Alibaba

3.1、简介

Spring Cloud Alibaba是Spring Cloud下的一个子项目，Spring Cloud Alibaba为分布式应用程序开发提供了一站式解决方案，它包含开发分布式应用程序所需的所有组件，使您可以轻松地使用Spring Cloud开发应用程序，使用Spring Cloud Alibaba，您只需要添加一些注解和少量配置即可将Spring Cloud应用程序连接到Alibaba的分布式解决方案，并使用Alibaba中间件构建分布式应用程序系统。Spring Cloud Alibaba 是阿里巴巴开源中间件跟 Spring Cloud 体系的融合。

3.2、主要功能

流量控制和服务降级：默认支持 WebServlet、WebFlux， OpenFeign、RestTemplate、Spring Cloud、Gateway， Zuul， Dubbo 和 RocketMQ 限流降级功能的接入，可以在运行时通过控制台实时修改限流降级规则，还支持查看限流降级 Metrics 监控。

服务注册和发现：实例可以在Alibaba Nacos上注册，客户可以使用Spring管理的bean发现实例，通过Spring Cloud Netflix支持Ribbon客户端负载均衡器。

分布式配置管理：支持分布式系统中的外部化配置，配置更改时自动刷新。

消息驱动能力：基于 Spring Cloud Stream 为微服务应用构建消息驱动能力。

消息总线：使用Spring Cloud Bus RocketMQ链接分布式系统的节点。

分布式事务：使用 @GlobalTransactional 注解， 高效并且对业务零侵入地解决分布式事务问题。

Dubbo RPC：通过Apache Dubbo RPC扩展Spring Cloud服务到服务调用的通信协议。

分布式任务调度：提供秒级、精准、高可靠、高可用的定时（基于 Cron 表达式）任务调度服务。同时提供分布式的任务执行模型，如网格任务。网格任务支持海量子任务均匀分配到所有Worker（schedulerx-client）上执行。

3.3、组件

Sentinel：把流量作为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。

Nacos：一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。

RocketMQ：一款开源的分布式消息系统，基于高可用分布式集群技术，提供低延时的、高可靠的消息发布与订阅服务。

Dubbo：Apache Dubbo 是一款高性能 Java RPC 框架。

Seata：阿里巴巴开源产品，一个易于使用的高性能微服务分布式事务解决方案。

Alibaba Cloud ACM：一款在分布式架构环境中对应用配置进行集中管理和推送的应用配置中心产品。

Alibaba Cloud OSS: 阿里云对象存储服务（Object Storage Service，简称 OSS），是阿里云提供的海量、安全、低成本、高可靠的云存储服务。您可以在任何应用、任何时间、任何地点存储和访问任意类型的数据。

Alibaba Cloud SchedulerX: 阿里中间件团队开发的一款分布式任务调度产品，提供秒级、精准、高可靠、高可用的定时（基于 Cron 表达式）任务调度服务。

Alibaba Cloud SMS: 覆盖全球的短信服务，友好、高效、智能的互联化通讯能力，帮助企业迅速搭建客户触达通道。

四、微服务项目搭建

4.1、技术选型

持久层：SpingData Jpa

数据库: MySQL5.7

技术栈：SpringCloud Alibaba 技术栈

4.2、模块设计

我们搭建一个微服务的项目，但是只有简单的代码，没有任何业务逻辑。

shop-parent 父工程

shop-product-api：商品微服务api ，用于存放商品实体。

shop-product-server：商品微服务，他的1端口是808x。

shop-order-api 订单微服务api，用于存放订单实体。

shop-order-server 订单微服务，他的端口是808x。

4.3、微服务的调用

;在微服务架构中，最常见的场景就是微服务之间的相互调用。我们以电商系统中常见的用户下单为例来演示微服务的调用：客户向订单微服务发起一个下单的请求，在进行保存订单之前需要调用商品微服务查询商品的信息。

我们一般把服务的主动调用方称为服务消费者，把服务的被调用方称为服务提供者。

4.4、创建父工程

创建一个maven工程，然后在pom.xml文件中添加下面内容

4.5、创建商品服务

4.5.1、书写Shop-product-api的依赖

创建Shop-product-api项目，然后在pom.xml文件中添加下面内容

4.5.2、创建实体

4.5.3、书写Shop-product-server的依赖

4.5.4、编写application.yml

4.5.5、创建数据库

由于我们使用的是JPA，所以我们需要创建数据库，但是不需要创建表，因为JPA会在对应的数据库中自动创建表。

4.5.6、创建DAO接口

4.5.7、创建Service接口及其实现类

4.5.8、书写Controller

4.5.9、加入测试数据

我们在启动项目的时候，可以发现表已经默认帮我们自动创建好了，我们需要导入测试数据。

4.5.10、测试

4.6、创建订单微服务

4.6.1、书写Shop-order-api的依赖

4.6.2、创建订单实体

4.6.3、创建shop-order-server项目

在pom.xml中添加依赖。

4.6.4、编写application.yml

4.6.5、编写Service及其实现类

我们写的Service接口及其实现类不具备任何的业务逻辑，仅仅只是为了测试而用。

4.6.6、创建Controller

4.7、服务之间如何进行调用

假设我们在订单的服务里面需要调用到商品服务，先查询出id为1的商品，然后再查询出他的订单，这个1时候就涉及到服务之间的调用问题了。 服务之间的1调用本质上是通过Java代码去发起一个Http请求，我们可以使用RestTemplate来进行调用。

4.7.1、在shop-order-server的启动类中添加注解

我们既然需要RestTemplate类，就需要将RestTemplate类注入到容器中。

4.7.2、修改Controller代码

这样我们就完成了服务之间的互相调用。

4.8、存在的问题

虽然我们已经可以实现微服务之间的调用。但是我们把服务提供者的网络地址（ip，端口）等硬编码到了代码中，这种做法存在许多问题：

一旦服务提供者地址变化，就需要手工修改代码。

一旦是多个服务提供者，无法实现负载均衡功能。

一旦服务变得越来越多，人工维护调用关系困难。

那么应该怎么解决呢?这时候就需要通过注册中心动态的实现服务治理。

什么是微服务

提到微服务不得不提Martin Fowler在2014年3月25日发表的文章 Microservices，里面给出了微服务的定义。后续国内所有关于微服务的介绍都是基于这篇文章的翻译，或加上自己的理解而成。其中最重要的一段如下：

In short, the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

翻译过来就是：微服务这种架构风格就是把一组小服务演化成为一个单一的应用的一种方法。每个应用都运行在自己的进程中，并通过轻量级的机制保持通信，就像HTTP这样的API。这些服务要基于业务场景，并使用自动化部署工具进行独立的发布。可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语言来编写服务，也可以使用不同的数据存储。

如何实现微服务

相对于单体式架构的简单粗暴，微服务架构将应用打散，形成多个微服务进行独立开发、测试、部署与运维。虽然从管理与逻辑上更符合业务需要，但微服务架构也带来了诸多急需解决的核心问题：

1. 如何发现新服务节点以及检查服务节点的状态？

2. 如何发现服务及负载均衡如何实现？

3. 服务间如何进行消息通信？

4. 如何对使用者暴露服务 API？

5. 如何集中管理众多服务节点的配置文件？

6. 如何收集服务节点的日志并统一管理？

7. 如何实现服务间调用链路追踪？

8. 如何对系统进行链路保护，避免微服务雪崩？

可以发现，上述这些问题并不是针对某种语言或某种技术的，任何软件厂商要构建微服务架构就必须面对这些问题，要么独立开发要么将已有多种技术整合形成整体解决方案。好在经过多年沉淀，业内已经有了标准答案，下图清晰的说明微服务架构需要的标准组件。

API网关： 封装了系统内部架构，为每个客户端提供一个定制的 API。在微服务架构中，服务网关的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。

注册中心： 微服务架构体系中最核心的技术组件，它起到新服务节点的注册与状态维护的作用。诸如 Dubbo、Spring Cloud 等主流的微服务框架都基于 Zookeeper、Eureka 等分布式系统协调工具构建了服务注册中心。

服务路由： 通过注册中心构建了一个多服务的集群化环境中，当客户端请求到达集群，如何确定由哪一台服务器进行请求响应呢？这就是服务路由问题。

服务通信： 在微服务定义中阐述服务间通信采用轻量级协议，通常是 HTTP RESTful 风格。但因 RESTful 风格过于灵活，必须加以约束，通常在应用时对其进行上层封装，例如在 Spring Cloud 中就提供了 Feign 和 RestTemplate 两种技术屏蔽底层实现 RESTful 通信细节。

服务保护： 对于分布式环境中的服务而言，服务在自身失败引发生错误的同时，还会因为依赖其他服务而导致失败。除了比较容易想到和实现的超时、重试和异步解耦等手段之外，我们需要考虑针对各种场景的容错机制。

链路跟踪：一个复杂的业务流程可能需要连续调用多个微服务，我们需要记录一个完整业务逻辑涉及的每一个微服务的运行状态，再通过可视化链路图展现，帮助软件工程师在系统出错时分析解决问题，常见的解决方案有Zipkin，SkyWalking。

统一日志管理： 微服务架构默认将应用日志分散保存在每一个微服务节点上，当系统进行用户行为分析、数据统计时必须收集所有节点日志数据，非常不方便。这时候我们需要一个独立的日志平台，收集所有节点的日志数据并可方便对其进行汇总分析，常见的解决方案有ELK，EFK。

配置中心： 在微服务架构中，考虑到服务数量和配置信息的分散性，一般都需要引入配置中心的设计思想和相关工具。通过部署配置中心服务器，将原本分散的配置文件从应用中剥离，集中转存到配置中心。一般配置中心会提供 UI 界面，可以方便快捷的实现大规模集群的配置调整。

为什么选择SpringCloud

首先，Spring Cloud 具备一个天生的优势，因为它是 Spring 家庭的一员，而 Spring 在 Java EE 开发领域的强大地位，给 Spring Cloud 起到很好的推动作用。同时，Spring Cloud 所基于的 Spring Boot，已经成为 Java EE 领域中最流行的开发框架，用来简化 Spring 应用程序的框架搭建和开发过程。

其次，技术组件的完备性是我们选择 Spring Cloud 的主要原因。Spring Cloud 中包含了开发一个完整的微服务系统所需的几乎所有技术组件，包括服务注册和发现、API 网关、配置中心、消息处理、负载均衡、熔断器、数据监控等常见技术组件都可以基于 Spring Boot 快速集成到业务系统中。

以下为SpringCloud 中常用的技术组件

为什么选择SpringCloud alibaba

首先， SpringCloud中的技术组件是集众家之长，如注册中心 Eureka，Zuul等都是依赖于Netflix的，这也导致它受制于第三方厂商。如Zuul宣布停止维护，Spring机构便不得不寻找替代品或自研；Eureka2.x 闭源不允许使用；

其次，Springcloud作为国外产品引入到国内后出现了水土不服，如SpringCloud Config默认将文件存在Github上，且没有维护界面，国内软件公司很少会同意这么做。比如我们部门就是使用了Apollo配置中心替代了原生的SpringCloud Config。

Spring Cloud Alibaba是国产的微服务开发一站式解决方案，与原有 Spring Cloud 兼容的同时对微服务生态进行扩展，通过添加少量的配置注解，便可实现更符合国情的微服务架构，当前Spring Cloud Alibaba已经是直接隶属于 Spring Cloud 的子项目。官网是：https://spring.io/projects/spring-cloud-alibaba#overview

Spring Cloud Alibaba 对服务注册、配置中心与负载均衡功能都整合进 Nacos，有图形化界面，简化了微服务架构的复杂度，出问题的概率也会降低。原有的服务保护组件也调整为 Sentinel，相较Hystrix功能更强大，使用也更加友好。同时还支持了对Dubbo的调用，而且还有Seata用于支持分布式事务。

我们知道spring cloud可以用来开发微服务，但是应该很少有人真正知道Spring Cloud是什么。

官方的解释是：spring cloud提供了一些可以让开发者快速构建分布式应用的工具，这些服务可以很好的工作在任何分布式环境下。

既然提供的是一些快速构建微服务应用的工具，那么我们需要了解微服务开发过程中需要解决哪些问题？

1. 服务注册发现

2. 远程服务调用

3. 负载均衡

4. 断路器

5. 分布式消息

6. 配置中心

7. 链路监控

所以，spring cloud提供了一些解决这类问题的工具，比如服务注册提供了Eureka/Consoul/zookeeper；远程调用基于RestTemplate针对http协议调用的封装；负载均衡采用Ribbon、断路器采用hystrix；分布式消息基于kafka、rabbitMQ；配置中心基于config;链路监控基于sleuth.

但是，从这些组件中，我们发现了一些问题，这些组件并不是spring提供的啊，比如eureka、ribbon、hystrix是netflix开源的。而kafka、zookeeper是一些独立的组件，和spring似乎没有关系。没错，这就是spring团队的强大之处，他们很少重复早轮子，而是他们利用别人造好的轮子来进行封装使得用户在使用的时候更加方便。

举个简单例子，比如最早spring只提供了IOC和AOP的核心功能，而像ORM框架、缓存、MVC框架，spring只是提供了一种兼容以及支持，所以当时大家说spring是万能胶，可以把各种各样的框架整合进来。

当然，spring也会对一些市面上做得不好的技术进行替代，比如struts2.，我记得当时公司使struts2经常出现各种漏洞，所以spring mvc才被创造出来并且很快代替了struts。成为现在的主流框架。

所以，对于spring cloud来说也是如此，spring cloud并不是一个框架，因为Spring Cloud的核心并没有实现服务注册、熔断、配置中心等功能，它提供了一个标准规范。而Spring Cloud Netflix才是spring Cloud规范的一种实现。

常见的服务组件

融合在每个微服务中、依赖其它组件并为其提供服务。

Ribbon，客户端负载均衡，特性有区域亲和、重试机制。

Hystrix，客户端容错保护，特性有服务降级、服务熔断、请求缓存、请求合并、依赖隔离。

Feign，声明式服务调用，本质上就是Ribbon+Hystrix

Stream，消息驱动，有Sink、Source、Processor三种通道，特性有订阅发布、消费组、消息分区。

Bus，消息总线，配合Config仓库修改的一种Stream实现，

Sleuth，分布式服务追踪，需要搞清楚TraceID和SpanID以及抽样，如何与ELK整合。

独自启动不需要依赖其它组件，单枪匹马都能干。

Eureka，服务注册中心，特性有失效剔除、服务保护。

Dashboard，Hystrix仪表盘，监控集群模式和单点模式，其中集群模式需要收集器Turbine配合。

Zuul，API服务网关，功能有路由分发和过滤。

Config，分布式配置中心，支持本地仓库、SVN、Git、Jar包内配置等模式

Spring Cloud生态的构建

Spring Cloud的生态是基于spring boot这个微框架来构建的，所以spring cloud可以说是基于spring boot来对其他框架进行整合，那么什么是spring boot或者为什么要基于spring boot来整合呢？

首先，spring boot并不是一个新的技术，它是基于spring框架下对于“约定由于配置(Convention Over Configuration)”理念下的产物，主要是帮助开发人员更容易更快速的创建独立运行和产品级别的基于spring框架的应用。为什么说springboot是微框架呢？如果大家玩过springboot，那应该很有体会，我们只需要非常少的配置就可以快速构建一个web项目。

而spring boot中并没有新的技术，如果大家对spring框架比较熟悉，那么在学习springboot的时候会更加容易。

围绕springboot构建的spring cloud生态下，目前有两类的比较或的实现，一个是基于netflix、另一个是基于alibaba。

Spring Cloud Alibaba的相关资料

前面一个阶段，我们讲完了Spring Cloud Alibaba生态中的Dubbo组件，当然，我们没有基于spring cloud project的形式来讲解，而是基于组件的形式形式来讲，原因是spring cloud本质上就是对各个组件的集成。

目前Spring Cloud Alibaba这个生态中，已经有相对成熟的体系

1. Dubbo 用于实现高性能Java RPC 通信

2. Nacos 服务注册发现、配置管理、服务管理

3. Sentinel 流量控制、熔断降级、系统负载保护

4. RocketMQ 分布式消息系统，提供低延时的、高可靠的消息发布与订阅服务

5. Seata 高性能微服务分布式事务解决方案

6. Alibaba Cloud OSS 阿里云对象存储服务（Object Storage Service，简称 OSS），是阿里云提供的海量、安全、低成本、高可靠的云存储服务。

7. Alibaba Cloud SchedulerX 阿里中间件团队开发的一款分布式任务调度产品，支持周期性的任务与固定时间点触发任务。

8. Alibaba Cloud SMS 覆盖全球的短信服务，友好、高效、智能的互联化通讯能力，帮助企业迅速搭建客户触达通道。

在2019年8月1号，spring-cloud-alibaba发布了第一个毕业版本（从孵化器仓库毕业），发布了V2.1.0.RELEASE版本， 目前最新的的版本是2.2.1.RELEASE，2.2.x 版本适用于 Spring Boot 2.2.x

另外，相比于Spring Cloud Netflix 生态，到2020年，archaus/hystrix/ribbon/zuul/turbine等starter都会进入维护模式，进入维护模式意味着spring cloud团队不会再向这些模块中添加新的功能，但是仍然会修复安全问题和一些block级别的bug。只是没有新的功能迭代了，spring cloud netflix仍然可以继续使用。

文章链接->spring-cloud-netflix-projects-entering-maintenance-mode

进入维护模式的最根本原因还是Netflix对于zuul、ribbon等项目维护投入比较少、所以spring cloud 会在greenwich中把这些项目都进入到维护模式。

当然，这些组件会有相应功能的其他组件代理，有些还在孵化中。有些已经毕业了，比如alibaba这套标准

微服务的整体架构

文章配图

Spring Cloud Alibaba

提起微服务，不得不提 Spring Cloud 全家桶系列，SpringCloud 是若干个框架的集合，包括 spring-cloud-config、spring-cloud-bus 等近 20 个子项目，提供了服务治理、服务网关、智能路由、负载均衡、断路器、监控跟踪、分布式消息队列、配置管理等领域的解决方案。

Spring Cloud 通过 Spring Boot 风格的封装，屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、容易部署的分布式系统开发工具包。

Spring Cloud 一样，Spring Cloud Alibaba 也是一套微服务解决方案，包含开发分布式应用微服务的必需组件，方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。

依托 Spring Cloud Alibaba，您只需要添加一些注解和少量配置，就可以将 Spring Cloud 应用接入阿里微服务解决方案，通过阿里中间件来迅速搭建分布式应用系统。

Spring Cloud Alibaba中包含的组件

阿里开源组件

Nacos：一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。

Sentinel：把流量作为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。

RocketMQ：开源的分布式消息系统，基于高可用分布式集群技术，提供低延时的、高可靠的消息发布与订阅服务。

Dubbo：这个就不用多说了，在国内应用非常广泛的一款高性能 Java RPC 框架。

Seata：阿里巴巴开源产品，一个易于使用的高性能微服务分布式事务解决方案。

Arthas：开源的Java动态追踪工具，基于字节码增强技术，功能非常强大。

阿里商业化组件

作为一家商业公司，阿里巴巴推出 Spring Cloud Alibaba，很大程度上市希望通过抢占开发者生态，来帮助推广自家的云产品。所以在开源社区，夹带了不少私货，这部分组件我在阿里工作时都曾经使用过，整体易用性和稳定性还是很高的。

Alibaba Cloud ACM：一款在分布式架构环境中对应用配置进行集中管理和推送的应用配置中心产品。

Alibaba Cloud OSS：阿里云对象存储服务（Object Storage Service，简称 OSS），是阿里云提供的云存储服务。

Alibaba Cloud SchedulerX：阿里中间件团队开发的一款分布式任务调度产品，提供秒级、精准的定时（基于 Cron 表达式）任务调度服务。

Nacos服务注册中心

Nacos提供了统一配置管理、服务发现与注册。 其中服务注册和发现的功能，相当于dubbo里面使用到的zookeeper、 或者spring cloud里面应用到的consoul以及eureka。

服务发现和服务健康监测

Nacos提供了基于RPC的服务发现，服务提供者可以将自身的服务通过原生API或者openApi来实现服务的注册，服务消费者可以使用API或者Http来查找和发现服务

同时，Nacos提供了对服务的实时监控检查，当发现服务不可用时，可以实现对服务的动态下线从而阻止服务消费者向不健康的服务发送请求。

配置管理

传统的配置管理，是基于项目中的配置文件来实现，当出现配置文件变更时需要重新部署，而动态配置中心可以将配置进行统一的管理，是的配置变得更加灵活以及高效。

动态配置中心可以实现路由规则的动态配置、限流规则的动态配置、动态数据源、开关、动态UI等场景

国内比较有名的开源配置中心: Aollo / diamond / disconf

Nacos的整体架构

Nacos的整体架构还是比较清晰的，我们可以从下面这个官方提供的架构图进行简单分析。

文章配图

云原生

云原生从字面意思上来看可以分成云和原生两个部分。

云是和本地相对的，传统的应用必须跑在本地服务器上，现在流行的应用都跑在云端，云包含了IaaS,、PaaS和SaaS。

原生就是土生土长的意思，我们在开始设计应用的时候就考虑到应用将来是运行云环境里面的，要充分利用云资源的优点，比如云服务的弹性和分布式优势。

文章配图

版权声明：本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 Mic带你学架构！如果本篇文章对您有帮助，还请帮忙点个关注和赞，您的坚持是我不断创作的动力。

什么是nacos

Nacos 是阿里巴巴的开源的项目，全称 Naming Configuration Service ，专注于服务发现和配置管理领域

Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理

官网地址

nacos总体概况

nacos架构

为什么要用nacos

与eureka对比

服务配置中心对比

相比与Eureka

(1)Nacos具备服务优雅上下线和流量管理（API+后台管理页面），而Eureka的后台页面仅供展示，需要使用api操作上下线且不具备流量管理功能。

(2)从部署来看，Nacos整合了注册中心、配置中心功能，把原来两套集群整合成一套，简化了部署维护

(3)从长远来看，Eureka开源工作已停止，后续不再有更新和维护，而Nacos在以后的版本会支持SpringCLoud+Kubernetes的组合，填补 2 者的鸿沟，在两套体系下可以采用同一套服务发现和配置管理的解决方案，这将大大的简化使用和维护的成本。同时来说,Nacos 计划实现 Service Mesh，是未来微服务的趋势

(4)从伸缩性和扩展性来看Nacos支持跨注册中心同步，而Eureka不支持，且在伸缩扩容方面，Nacos比Eureka更优（nacos支持大数量级的集群）。

(5)Nacos具有分组隔离功能，一套Nacos集群可以支撑多项目、多环境。

相比于apollo

(1) Nacos部署简化，Nacos整合了注册中心、配置中心功能，且部署相比apollo简单，方便管理和监控。

(2) apollo容器化较困难，Nacos有官网的镜像可以直接部署，总体来说，Nacos比apollo更符合KISS原则

(3)性能方面，Nacos读写tps比apollo稍强一些

启动nacos

你可以通过源码和发行包两种方式来获取 Nacos

从 Github 上下载源码方式

git clone https://github.com/alibaba/nacos.git
cd nacos/
mvn -Prelease-nacos -Dmaven.test.skip=true clean install -U  
ls -al distribution/target/

// change the $version to your actual pathcd distribution/target/nacos-server-$version/nacos/bin

下载编译后压缩包方式

您可以从 最新稳定版本 下载 nacos-server-$version.zip 包。

 unzip nacos-server-$version.zip 或者 tar -xvf nacos-server-$version.tar.gz  cd nacos/bin

启动服务器

Linux/Unix/Mac 启动命令(standalone代表着单机模式运行，非集群模式):

sh startup.sh -m standalone

Windows 启动命令：

cmd startup.cmd

或者直接运行startup.cmd文件

默认账号密码都是 nacos

nacos 默认是用的内置数据库

Spring cloud作为当下主流的微服务框架，让我们实现微服务架构简单快捷，Spring cloud中各个组件在微服务架构中扮演的角色如下图所示，黑线表示注释说明，蓝线由A指向B，表示B从A处获取服务。

Spring cloud组成的微服务架构图  

由上图所示微服务架构大致由上图的逻辑结构组成，其包括各种微服务、注册发现、服务网关、熔断器、统一配置、跟踪服务等。下面说说Spring cloud中的组件分别充当其中的什么角色。

Fegin(接口调用)：微服务之间通过Rest接口通讯，Spring Cloud提供Feign框架来支持Rest的调用，Feign使得不同进程的Rest接口调用得以用优雅的方式进行，这种优雅表现得就像同一个进程调用一样。

Netflix eureka(注册发现)：微服务模式下，一个大的Web应用通常都被拆分为很多比较小的web应用(服务)，这个时候就需要有一个地方保存这些服务的相关信息，才能让各个小的应用彼此知道对方，这个时候就需要在注册中心进行注册。每个应用启动时向配置的注册中心注册自己的信息（ip地址，端口号, 服务名称等信息），注册中心将他们保存起来，服务间相互调用的时候，通过服务名称就可以到注册中心找到对应的服务信息，从而进行通讯。注册与发现服务为微服务之间的调用带来了方便，解决了硬编码的问题。服务间只通过对方的服务id，而无需知道其ip和端口即可以获取对方方服务。

Ribbon(负载均衡)：Ribbon是Netflix发布的负载均衡器，它有助于控制HTTP和TCP客户端的行为。为Ribbon，配置服务提供者的地址列表后，Ribbon就可基于某种负载均衡算法，自动地帮助服务消费者去请求。Ribbon默认为我们提供了很多的负载均衡算法，例如轮询、随机等。当然，我们也可为Ribbon实现自定义的负载均衡算法。在SpringCloud中，当Ribbon与Eureka配合使用时，Ribbon可自动从EurekaServer获取服务提供者的地址列表，并基于负载均衡算法，请求其中一个服务提供者的实例（为了服务的可靠性，一个微服务可能部署多个实例）。

Hystrix(熔断器)：当服务提供者响应非常缓慢，那么消费者对提供者的请求就会被强制等待，直到提供者响应或超时。在高负载场景下，如果不做任何处理，此类问题可能会导致服务消费者的资源耗竭甚至整个系统的崩溃（雪崩效应）。Hystrix正是为了防止此类问题发生。Hystrix是由Netflix开源的一个延迟和容错库，用于隔离访问远程系统、服务或者第三方库，防止级联失败，从而提升系统的可用性与容错性。Hystrix主要通过以下几点实现延迟和容错。

包裹请求：使用HystrixCommand（或HystrixObservableCommand）包裹对依赖的调用逻辑，每个命令在独立线程中执行。这使用了设计模式中的“命令模式”。

跳闸机制：当某服务的错误率超过一定阈值时，Hystrix可以自动或者手动跳闸，停止请求该服务一段时间。

资源隔离：Hystrix为每个依赖都维护了一个小型的线程池（或者信号量）。如果该线程池已满，发往该依赖的请求就被立即拒绝，而不是排队等候，从而加速失败判定。

监控：Hystrix可以近乎实时地监控运行指标和配置的变化，例如成功、失败、超时和被拒绝的请求等。

回退机制：当请求失败、超时、被拒绝，或当断路器打开时，执行回退逻辑。回退逻辑可由开发人员指定。

Zuul(微服务网关) ：不同的微服务一般会有不同的网络地址，而外部客户端可能需要调用多个服务的接口才能完成一个业务需求。例如一个电影购票的手机APP，可能调用多个微服务的接口才能完成一次购票的业务流程，如果让客户端直接与各个微服务通信，会有以下的问题：

客户端会多次请求不同的微服务，增加了客户端的复杂性。

存在跨域请求，在一定场景下处理相对复杂。

认证复杂，每个服务都需要独立认证。

难以重构，随着项目的迭代，可能需要重新划分微服务。例如，可能将多个服务合并成一个或者将一个服务拆分成多个。如果客户端直接与微服务通信，那么重构将很难实施。

某些微服务可能使用了对防火墙/浏览器不友好的协议，直接访问时会有一定的困难。

以上问题可借助微服务网关解决。微服务网关是介于客户端和服务器端之间的中间层，所有的外部请求都会先经过微服务网关。使用微服务网关后，微服务网关将封装应用程序的内部结构，客户端只用跟网关交互，而无须直接调用特定微服务的接口。这样，开发就可以得到简化。不仅如此，使用微服务网关还有以下优点：

易于监控。可在微服务网关收集监控数据并将其推送到外部系统进行分析。

易于认证。可在微服务网关上进行认证，然后再将请求转发到后端的微服务，而无须在每个微服务中进行认证。

减少了客户端与各个微服务之间的交互次数。

Spring cloud bus（ 统一配置服务）：对于传统的单体应用，常使用配置文件管理所有配置。例如一个SpringBoot开发的单体应用，可将配置内容放在application.yml文件中。如果需要切换环境，可设置多个Profile，并在启动应用时指定spring.profiles.active={profile}。然而，在微服务架构中，微服务的配置管理一般有以下需求：

集中管理配置。一个使用微服务架构的应用系统可能会包含成百上千个微服务，因此集中管理配置是非常有必要的。

不同环境，不同配置。例如，数据源配置在不同的环境（开发、测试、预发布、生产等）中是不同的。

运行期间可动态调整。例如，可根据各个微服务的负载情况，动态调整数据源连接池大小或熔断阈值，并且在调整配置时不停止微服务。

配置修改后可自动更新。如配置内容发生变化，微服务能够自动更新配置。综上所述，对于微服务架构而言，一个通用的配置管理机制是必不可少的，常见做法是使用配置服务器管理配置。Spring cloud bus利用Git或SVN等管理配置、采用Kafka或者RabbitMQ等消息总线通知所有应用，从而实现配置的自动更新并且刷新所有微服务实例的配置。

Sleuth+ZipKin(跟踪服务)：Sleuth和Zipkin结合使用可以通过图形化的界面查看微服务请求的延迟情况以及各个微服务的依赖情况。需要注意的是Spring boot2及以上不在支持Zipkin的自定义，需要到官方网站下载ZipKin相关的jar包。

另外需要提一点的是Spring boot actuator，提供了很多监控端点如/actuator/info、/actuator/health、/acutator/refresh等，可以查看微服务的信息、健康状况、刷新配置等。

作者：SimpleEasy
链接：https://www.jianshu.com/p/84d2824980fe
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。