目录
Eureka：服务注册中心，基于REST服务的分布式中间件，主要用于服务管理。
Hystrix：熔断器，容错管理工具，旨在通过熔断机制控制服务和第三方库的节点,从而对延迟和故障提供更强大的容错能力。
Ribbon：云端负载均衡，支持多种负载均衡策略，可以配合服务发现和断路器使用，在客户端实现负载均衡。
Feign：一个REST客户端，基于Ribbon和Hystrix的声明式服务调用组件。
Zuul：服务网关，为微服务集群提供代理，过滤，路由等功能。
认识架构
1.单体架构
一个典型的单体应用就是将所有业务场景的表示层、业务逻辑层和数据访问层放在一个工程中，最终经过编译、打包，部署在一台服务器上。以一个进存销系统的单体应用为例，架构如下图所示。
单体架构的缺点：
单体应用中，随着业务越来越复杂，应用需要增加的功能越来越多，单体应用的代码量越来越大，代码可读性、可维护性和扩展性会下降。同时，单体应用带来的隐患会比较多，由于系统的庞大以及关联较多，应用中的任何一个Bug都有可能导致整个系统宕机。
2.SOA架构
SOA架构是一个面向服务的架构，它是一个组件模型。 SOA架构将应用程序的不同功能单元（称为服务）进行拆分，并通过在这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以使用一种统一和通用的方式进行交互
SOA架构将原来的单体架构按照功能细分为不同的子系统， SOA架构的进存销系统如下图所示。
一个完整的项目会分为多个模块，数据库也会有主库与从库两种，并且主库与从库是数据同步的。
SOA架构的缺点：
SOA一般使用某种集中式管理，比如会有审查委员会、主架构师或架构委员会等部门来严格定义每个系统组件应当做什么，如何执行。相同类型的功能可能会在多个组件中分别定义和记录，每个组件使用的语言或者工具集可以是统一的，也可以不是。在SOA架构中，系统和服务的界定比较模糊，而且服务的接口协议不固定，种类繁多，不利于系统维护。
3.微服务架构
什么是微服务架构?
微服务架构是一种将单应用程序作为一套小型服务开发的方法，每种应用程序都在其自己的进程中运行，并与轻量级机制（通常是HTTP资源的API）进行通信。这些服务是围绕业务功能构建的，可以通过全自动部署机制进行独立部署。服务的集中化管理是最少的，它们可以使用不同的编程语言编写程序、使用不同的存储计算存储数据数据。
微服务架构的进销存系统如下图所示
微服务架构有哪些优点?
微服务架构中每个服务都有自己的独立的数据库，数据库之间没有任何联系，这样的好处是，随着业务的不断扩张，服务与服务不需要提供数据库集成，而是提供API接口相互调用。数据库的独立使系统维护简单，性能提高，迁移方便。一个典型的微服务系统，各个服务的数据库可能都不同，每个服务所使用的数据存储技术可以根据业务需求来选择。 微服务是直接通过HTTP协议进行通信的，也可以采用消息队列来通信，如RabbitMQ，Kafka等进行通信，通过采用不同的编程语言，使用不同的存储技术，自动化部署减少人为控制，降低出错概率。
1.微服务的自动化部署
微服务架构中，系统会被拆分为若干个微服务，每个微服务又是一个独立的运行程序。单体架构中的应用程序只需要部署一次，而微服务架构中有多少服务就需要部署多少次。随着服务数量的增加，部署的难度就会增加。业务的粒度划分的越细，微服务的数量就越多。因此就出现了自动化部署工具，例如Docker容器自动化部署技术方便了微服务项目下各模块在服务器上的部署。
2.服务集中化管理
微服务系统是按照业务单元来划分的，服务数量越多，管理起来越复杂。在这里微服务提供了集中化管理组件Config，这样可以在Config配置文件中统一配置，很大程度方便了人们对项目的集中化管理。
3.支持熔断机制
雪崩效应： 在讲熔断机制之前，我们先来了解一下“雪崩” 效应。 微服务架构就是分布式的，在分布式系统中，服务之间是相互依赖的，如果一个服务出现了故障或者网络延迟，在高并发的情况下，会导致线程阻塞，在很短的时间内该服务的线程资源会消耗殆尽，最终使得该服务不可用，这就是“雪崩”效应 。
熔断机制： 熔断机制是应对雪崩效应的一种微服务链路保护机制。我们在各种场景下都会接触到熔断这两个字。高压电路中，如果某个地方的电压过高，熔断器就会熔断，对电路进行保护。股票交易中，如果股票指数过高，也会采用熔断机制，暂停股票的交易。同样，在微服务架构中，熔断机制也是起着类似的作用。当一条链路的某个微服务不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回错误的响应信息。当检测到该节点微服务调用响应正常后，恢复调用链路。
Spring Cloud概述
Spring Cloud是一个基于Spring Boot实现的微服务开发架构，它利用Spring Boot的开发便利性巧妙地简化了分布式系统的开发。例如配置管理、服务发现、断路器、智能路由、控制总线等操作，都可以使用Spring Boot开发风格做到一键启动和部署。可以说，Spring Cloud将Spring Boot风格进行再封装，屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。
Spring Cloud微服务架构的特点
1.组件丰富，功能齐全
Spring Cloud拥有Spring的强大后盾，框架的源码也是开源的，开发者不断完善Spring Cloud下的组件，其中包括Spring Cloud Eureka注册发现中心，主要负责完成微服务架构中的服务治理功能；Spring Cloud Config分布式配置中心，可以实现动态修改配置文件；Spring Cloud Hystrix熔断器，通过熔断机制控制服务和第三方库的节点，从而对延迟和故障提供更强大的容错能力，这些组件基本包括了日常开发的各个方面。
2.开箱即用，快速启动
Spring Cloud基于Spring Boot开发的，Spring Boot具有快速构建Spring应用、直接嵌入服务器、自动化配置的优点，Spring Cloud继承了Spring Boot快速构建和自动化配置的优点，有开箱即用，快速启动的特点。
3.模块部署方便，项目维护难度降低
Spring Cloud采用模块化开发，按照项目功能，将项目拆分为不同的模块，每个模块独立开发运行，模块之间不会互相影响。模块开发完成后，每个模块部署时可以使用Docker自动化部署，使得项目部署更加方便。维护时只需要维护具体的模块，不需要改动其他模块的代码，从而降低模块后期维护的成本。
4.项目扩展性和稳定性较好
基于Spring Cloud的微服务架构中，每个模块基本都是一个Spring Boot项目，它们都有独立的数据库，模块下的功能是横向开发的，如果需要扩展新的功能，可以新建该功能对应的独立数据库以及新的模块，不需要在之前的模块上修改，项目扩展更方便，项目稳定性更好。
5.具有容错处理机制
实际开发中会因为网络连接失败、超时、服务器硬件故障等原因导致其中某个模块无法正常运行，导致整个项目发生异常，所以容错机制变得尤为重要。在Spring Cloud中提供了Hystrix组件，该组件专门用于处理容错，从而能保证某个模块出错后有其他备用模块或者善后处理。
Spring Cloud微服务架构的常用组件及模块
Spring Cloud是一系列框架的有序集合，为开发人员构建微服务架构提供了完整的解决方案，它利用Spring Boot开发的便利性巧妙地简化了分布式系统基础设施的开发，如服务注册发现、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。
Spring Cloud Netflix：
Eureka：服务注册中心，基于REST服务的分布式中间件，主要用于服务管理。
Hystrix：熔断器，容错管理工具，旨在通过熔断机制控制服务和第三方库的节点,从而对延迟和故障提供更强大的容错能力。
Ribbon：云端负载均衡，支持多种负载均衡策略，可以配合服务发现和断路器使用，在客户端实现负载均衡。
Feign：一个REST客户端，基于Ribbon和Hystrix的声明式服务调用组件。
Zuul：服务网关，为微服务集群提供代理，过滤，路由等功能。
Spring Cloud Config：
配置管理工具包，负责把配置放到远程服务器，集中化管理集群配置，目前支持本地存储、Git以及Subversion
Spring Cloud Bus：
事件、消息总线，用于在集群（例如配置变化事件）中传播状态变化，可与Spring Cloud Config联合实现热部署。
Spring Cloud Sleuth：
服务追踪框架，可以与Zipkin、Apache Htrace和ELK等数据分析，服务跟踪系统进行整合，为服务跟踪、解决问题提供了便利。
基于Spring Cloud的微服务架构图
Spring Cloud版本号
Spring Cloud在Spring团队和世界各国程序员一年多的努力下，其版本以及各个组件的版本已经大致有7个，Spring Cloud版本号并不是熟悉的数字版本号，而是一个名称代号，这些代号据说是根据伦敦地铁命名的，分别是Angel、Brixton、Camden、Dalston、Edgware、Finchley 、 Greenwich，其中Angel版本是第一个Release版本，Greenwich是目前最新的稳定版本。
Spring Cloud的版本名称，通常是由“版本号+小版本名称”组成的。这样设计的目的是为了更好地管理每个Spring Cloud子项目的清单，避免自己的版本号与子项目的版本号混淆。例如，Finchley M1版本中，Finchley代表的是版本号，M1是小版本名称。
在Spring Cloud的版本中，每个版本里面包含很多小版本，这些小版本使用不同的标识符号来表示版本的状态，常见的版本标识号具体如下：
SNAPSHOT：快照版本，可能会被修改。
M：MileStone的简称，M1表示第一个里程碑版本，一般同时标注PRE，表示预览版本。
SR：Service Release的简称，表示正式版本。如果正式版有多个，使用数字标识不同的正式版本，例如SR1表示第一个正式版本，同时一般会标注GA：（GenerallyAvailable），表示稳定版本。
注：Spring Cloud各个版本之间的组件变化不会很大，只有一些细节略有不同，例如配置项名称、新版本增加的新配置方式等。日常开发选择组件版本时最好根据Spring Cloud版本查询对应组件，否则很有可能会导致版本不匹配。也就是说，选择Spring Cloud版本与各个组件版本时要以兼容为第一要务。
Spring Cloud和Spring Boot都发布了多个版本，选择这些版本时需要考虑兼容性。Spring Cloud与Spring Boot版本的匹配关系，如下表所示
| Spring Cloud版本 | Spring Boot版本 |
| Greenwich版本 | 兼容Spring Boot2.1.x |
| Finchley版本 | 兼容Spring Boot2.0.x |
| Dalston和Edgware版本 | 兼容Spring Boot2.5.x |
| Camden版本 | 兼容Spring Boot2.4.x |
| Brixton版本 | 兼容Spring Boot2.3.x |
| Angel版本 | 兼容Spring Boot2.2.x |
5231
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
