1. 软市首页
  2. 行业观察

springcloud学习-Eureka、Eureka高可用集群、Ribbon客户端负载均衡策略

• 行业观察

SpringCloud|Spring Cloud Alibaba全套完整版框架开发教程-微服务项目实战【大牛亲授Spring Cloud Alibaba】

视频链接：https://www.bilibili.com/video/BV1or4y1F7Qa

p1~p18视频笔记

视频导读

接下来要学习两个课程，第一个是一站式微服务解决方案Spring Cloud Netflix，另外一个课程是一站式微服务解决方案Spring Cloud Alibaba。

Spring Cloud Netflix和Spring Cloud Alibaba都是微服务解决方案。

那么这里分成两个课程进行讲解，

做了一个分类。

它们之间有什么关系呢，那么这里有一张图可以看一下它的关系。

Spring生态下是有几十个项目的。

那么Spring生态下就包含了像Spring Boot、Spring框架（Spring Framework）、Spring Cloud…

Spring Cloud即微服务的开发框架。

那么Spring Cloud 当中包含了哪些内容呢/p>

Spring Cloud 当中包含了有Spring Cloud Netflix，Spring Cloud Netflix当中又包含了一些Netflix公司开源的一些组件，所以这个我们称之为Spring Cloud Netflix，Spring Cloud Netflix当中有包含Eureka、Hystrix、Hystrix Dashboard、Hystrix Turbine、Ribbon、Feign、Zuul。

另外一个即Spring Cloud Alibaba。Spring Cloud Alibaba开源的一些组件有Nacos Discovery、Nacos Config、Sentinel、RocketMQ、Seata、Dubbo Spring Cloud。都是用来进行微服务开发的。

所以当前课程分成两个部分来进行讲解。

  • Spring生态（https://spring.io）

    • Spring Web Services

    • Spring Web Flow

    • Spring Vault

    • Spring Statemachine

    • Spring Shell

    • Spring Roo

    • Spring Mobile

    • Spring LDAP

    • Spring for Apache Kafka

    • Spring Framework

    • Spring Cloud

      • Spring Cloud Netflix
        • Eureka
        • Hystrix
        • Hystrix Dashboard
        • Hystrix Turbine
        • Ribbon
        • Feign
        • Zuul
      • Spring Cloud Alibaba
        • 开源组件
          • Nacos Discovery
          • Nacos Config
          • Sentinel
          • RocketMQ
          • Seata
          • Dubbo Spring Cloud
        • 商业化组件
          • ANS
          • ACM
          • OSS
          • SMS
          • SchedulerX
      • Spring Cloud Azure
      • Spring Cloud for Amazon Web Services
      • Spring Cloud Bus
      • Spring Cloud CLI
      • Spring Cloud for Cloud Foundry
      • Spring Cloud – Cloud Foundry Service Broker
      • Spring Cloud Cluster
      • Spring Cloud Commons
      • Spring Cloud Config

    • Spring Data

    • Spring Cloud Data Flow

    • Spring Security

    • Spring Session

    • Spring Integration

    • Spring HATEOAS

    • …

第一个课程即Spring Cloud Netflix。

一站式微服务解决方案Spring Cloud Netflix

那么在这个课程当中会讲解哪些内容呢/p>

以下为大纲1~21点即为Spring Cloud Netflix课程。

这当中不光包括Netflix公司的一些开源组件，实际上还包含了一些别的东西，比如说Spring Cloud Config配置中心（用途、使用、加解密）、Spring Cloud Config配置中心（自动刷新、高可用、安全认证），再比如说Spring Cloud Sleuth分布式链路跟踪、Spring Cloud Sleuth整合Zipkin分布式链路跟踪，再比如说Spring Cloud 集成携程Apollo分布式配置中心也都包含在这当中。

这是第一个课程Spring Cloud Netflix，那么具体的课程详情就会逐一进行讲解。

  1. 分布式与微服务架构的理论梳理。
  2. 什么是Spring Cloud/li>
  3. Spring Cloud的整体架构（与Dubbo比较）
  4. 服务消费者Controller直连调用服务提供者Controller（http协议的restful）
  5. Spring Cloud的注册中心Eureka
  6. Spring Cloud Eureka与Zookeeper比较
  7. Spring Cloud Eureka高可用集群
  8. Spring Cloud Eureka自我保护机制
  9. Spring Cloud Ribbon 负载均衡
  10. Spring Cloud Feign声明式服务调用（与Dubbo接口层比较）
  11. Spring Cloud Hystrix服务熔断降级、服务限流
  12. Spring Cloud Hystrix DashBoard仪表盘监控
  13. Spring Cloud Hystrix Turbine聚合监控
  14. Spring Cloud Zuul网关（路由、过滤、异常、降级）
  15. Spring Cloud Config配置中心（用途、使用、加解密）
  16. Spring Cloud Config配置中心（自动刷新、高可用、安全认证）
  17. Spring Cloud Sleuth分布式链路跟踪
  18. Spring Cloud Sleuth整合Zipkin分布式链路跟踪
  19. Spring Cloud Stream消息驱动框架
  20. Spring Cloud 微服务安全机制
  21. Spring Cloud 集成携程Apollo分布式配置中心

第二个课程即Spring Cloud Alibaba。

那么这个课程当中我们会讲解哪些内容呢/p>

也列出了一个大纲。总共有58点。具体详细内容在后面也会进行详细的展开。

那么在这58点当中同样也不仅仅只包含了Spring Cloud Alibaba的开源组件，还包含了其他的内容，比如说Spring Cloud Stream，再比如说SkyWalking分布式链路跟踪，再比如说Spring Cloud Gateway网关等等，都是另外的一些内容。

一站式微服务解决方案 Spring Cloud Alibaba

  1. Spring家族开源项目梳理
  2. Spring Cloud下的开源项目梳理
  3. Spring Cloud Alibaba下的开源及商业项目梳理
  4. 微服务的基础模型：服务消费者-注册中心-服务提供者
  5. What is Nacos/li>
  6. Nacos的运行环境部署（Java写的，SpringBoot项目）
  7. Nacos的后台web管控台
  8. Nacos作为注册中心注册服务
  9. Nacos作为注册中心发现/订阅服务
  10. 服务消费者负载均衡调用服务提供者（ribbon）restTemplate、feign（openfeign）
  11. Nacos宕机时服务消费者缓存注册中心信息
  12. Nacos作为配置中心存储项目各种配置
  13. Nacos作为配置中心支持自动配置刷新（不需要重启应用）
  14. Nacos配置中心DataId+Group+Properties/yaml+配置内容（比较灵活）
  15. Nacos配置中心多环境配置（profile）即 s p r i n g . a p p l i c a t i o n . n a m e ? {spring.application.name}- spring.application.name?{profile}.${file-extension:properties}
  16. Nacos服务配置数据模型（命名空间、Group、Data Id）
  17. Nacos 数据持久化（mysql）
  18. Nacos集群部署（nginx）
  19. 主要调用方式：restTemplate、feign、ribbon（Spring Cloud）
  20. 流量控制Sentinel（流控、降级、热点、系统、授权规则）
  21. Sentinel DashBoard通信原理（与微服务通信）
  22. Sentinel 对应用保护的三种方式
  23. Sentinel整合RestTemplate流控熔断
  24. Sentinel整合Feign流控熔断
  25. Sentinel规则持久化（默认、pull模式、push模式）
  26. Spring Cloud Gateway网关（核心概念、如何工作、路由、谓词11个、过滤器31个）
  27. Spring Cloud Gateway自定义谓词
  28. Spring Cloud Gateway谓词不匹配404处理
  29. Spring Cloud Gateway自定义路由过滤器
  30. Spring Cloud Gateway全局过滤器（默认自动配置，无需单独配置）
  31. Spring Cloud Gateway集成ribbon复杂均衡
  32. Spring Cloud Gateway集成Sentinel
  33. Spring Cloud Gateway集成Sentinel规则持久化（文件、nacos）
  34. Spring Cloud Gateway内部流程源码分析
  35. Spring Cloud Gateway跨域CORS
  36. SkyWalking分布式链路跟踪
  37. SkyWalking主要功能特性和整体架构
  38. SkyWalking环境搭建部署
  39. SkyWalking Agent跟踪微服务
  40. IDEA中使用SkyWalking Agent跟踪运行的程序
  41. SkyWalking告警和回调处理
  42. SkyWalking持久化道elasticsearch
  43. SkyWalking跨多个微服务跟踪
  44. 自定义SkyWalking链路跟踪
  45. SkyWalking集成日志框架logback
  46. SkyWalking ui页面功能
  47. SkyWalking集群
  48. 什么是分布式事务
  49. What is Seata/li>
  50. Seata TC Server运行环境部署
  51. AT事务模型-单体应用多数据源应用
  52. AT事务模型-微服务应用
  53. AT事务模式工作机制
  54. Seata TC Server集群部署
  55. TCC事务模式执行机制
  56. 基于SpringBoot单体应用的TCC事务
  57. 基于Spring Cloud Alibaba的TCC分布式事务
  58. Spring Cloud Stream

分布式与微服务的那些高大上的理论梳理

微服务专题-一站式微服务架构Spring Cloud

接下来进行的专题是微服务专题。

微服务专题当中的第二个内容：一站式微服务架构Spring Cloud。这样一个微服务的解决方案叫Spring Cloud。

开始学习这样一个内容。

首先做一个简单了解：

接触过Spring Cloud、会使用Spring Cloud的、或者在公司的项目当中使用到过的打个1；

从未接触过的打个0；

接下来是重新开始学习这个内容，以后公司开发可能都会采用这种模式；

一点理论概念的梳理（也很重要）

在讲解之前先进行一点理论的梳理。虽然是理论但是也是非常重要的内容。稍微梳理下理论。

在系统架构与设计的实践中，从宏观上可以总结为三个阶段；（也就是系统架构经历了三个阶段）

第一个阶段即为传统、集中式的架构。比较早的时候，就一个项目，不管是在什么平台，做什么项目，就建一个工程，然后一帮程序员在其中进行开发，可能在这当中功能也很多，但是就只有一个项目，也就是在eclipse或者是idea当中就建立一个工程（单体应用），部署的时候就部署一个项目即可，有可能会部署到两到三台服务器，即集群的形式，但是其项目本身只有一个。

后续就发展成分布式架构。分布式架构就是拆分了。子项目之间相互调用共同对外提供服务。分布式架构有很多项目的原因在于由原来的一个项目根据不同的功能或者原因拆分成了很多个项目。整体的功能不是一个war包就可以完成的，而是多个war包一起去完成这个功能。

发展到第三个概念就是微服务架构。

最近几年来流行的一个概念叫做微服务架构。微服务架构实质上也属于分布式架构。可以认为是分布式架构的2.0版本，就相当于在这当中做了升级一样。

微服务架构在分布式架构的基础上做了升级，衍生、升华了一下。

集中式架构：就是把所有的功能、模块都集中到一个项目中，部署在一台服务器上，从而对外提供服务（单体架构、单体服务、单体应用）

直白一点：就是只有一个项目，只有一个war；

分布式架构：就是把所有的功能、模块拆分成不同的子项目，部署在多台不同的服务器上，这些子项目相互协作共同对外提供服务。

直白一点：就是有很多项目，有很多war包，这些项目相互协作完成需要的功能，不是一个war能完成的，一个war包完成不了。

比如：

Shop项目（电商平台）：单体应用

Shop项目：拆分–>（user-center[用户中心]，order-center[订单中心]，trade-center[交易中心]…）分布式应用

微服务架构：分布式强调系统的拆分，微服务也是强调系统的拆分，微服务架构属于分布式架构的范畴。

并且到目前为止，微服务并没有一个统一的标准的定义，那么微服务究竟是什么/p>

微服务一词源于Martin Fowler（马丁·福勒）的名为Microsevices的博文，

可以在他的官方博客上找到这篇文章：

https://www.martinfowler.com/articles/microservices.html

中文翻译版本：

https://www.martinfowler.cn/articles/microservices.html

Martin Fowler国外知名的一名软件开发人员。

后面很多关于微服务的一些概念理念都基本上是以该文章作为基础参考。同时这篇文章国内有人将它翻译成为了中文。

了解即可。了解微服务的思想以及理念。

微服务

——讨论这个新架构风格名词的定义

原文[英]：http://martinfowler.com/articles/microservices.html

翻译[中]：http://martinfowler.cn/articles/microservices.html

摘要：

【微服务】这个词在过去的几年中传播开来，它用来描述一种将软件设计成一系列独立部署服务的特定方式。尽管目前尚没有对这种架构风格的明确定义，但是围绕组织结构、业务能力、自动化部署、终结点的智能化程度，编程语言和数据的去中心化控制这几个方面，这种架构风格有着某些共同的特征。

目录

  1. 微服务架构的特征
    1. 通过服务实现组件化
    2. 围绕业务能力组织
    3. 是产品而不是项目
    4. 智能终结点和哑管道
    5. 去中心化的管理
    6. 去中心化的数据管理
    7. 基础架构自动化
    8. 为容错设计
    9. 演进式设计
  2. 微服务是未来吗/li>

May 18，2016

詹姆斯·里维斯（James Lewis）

詹姆斯·里维斯是ThoughtWorks公司的首席顾问，并且是公司技术咨询委员会的成员。

詹姆斯对于使用相互协作的小服务来构建应用程序的兴趣源自他整合大规模企业系统的背景。

他使用微服务构建了大量系统，并且几年来一直都是正在兴起的微服务社区的积极参与者。

马丁·福勒（Martin Fowler）

martin@martinfowler.com(but if you do email me please read my FAQ first.)

马丁·福勒是一名作家，演讲者，还是软件开发领域的大嘴巴。

他一直苦苦思索如何组件化软件系统这一问题，听到了许多站不住脚的声称已解决这个问题的言论，但是却很少听到能令他满意的观点。

他希望微服务能够达到它的支持者对它的早期期望。

相关标签：

  • MICROSERVICES（微服务）
  • POPULAR（流行的）
  • APPLICATION ARCHITECTURE（应用程序架构）
  • WEB SERVICES（WEB 服务）

“微服务”

——在软件架构拥挤的街道出现的有一个新词。

尽管我们习惯性地投以这类事物轻蔑的一瞥，但是这个小小的词却描述了一种被发现越来越具有吸引力的软件架构风格。

在过去的几年中，我们已经看到了许多个项目使用了这种风格，目前为止这些项目的结果都是积极的，以至于对我的许多同事而言这已称为构建企业应用的默认风格。

然而，令人沮丧的是，没有大量的信息明确指出微服务是什么以及我们如何实现它。

简而言之，微服务架构风格[1]是以一组小服务来开发单个因供应程序的方法，每一个服务运行在自己独立的进程中并且使用轻量的方法通信，通常是一个HTTP API接口，这些服务围绕相关业务范围构建并且由全自动化部署机器独立部署。

这些服务只需要最低限度的管理，可以用不同的编程语言去编写并且使用不同的数据存储技术。

原站点边栏

我的微服务资源向导提供了有关微服务的文章，视频，书籍和播客的链接。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-XOAufOeW-1621472077289)(C:UsersASUSAppDataRoamingTyporatypora-user-imagesimage-20210511171340500.png)]

若要解释清楚微服务风格，将它与单块风格（一个单块应用程序作为单个单元构建）对比将会很有帮助。

企业应用程序通常由三个主要部分组成：一个客户端用户界面（由运行在用户机器上的浏览器中的HTML页面和JavaScript代码组合成），一个数据库（由多个插入到一种常见的，通常是关系型数据库管理系统中的数据表组合成），以及一个服务端应用程序。

这个服务端应用程序将会处理HTTP请求，执行领域逻辑，从数据库获取和更新数据，并且选择和填充发送给浏览器的HTML视图。

这个服务器端的应用程序就是单块——一个单一的可执行的逻辑[2]。

任何对这个系统的改动都需要重新构建和部署一个服务器端应用程序的新版本。

很自然地，这样的单块服务器是构建这样一个系统的一种方式。

处理一条请求的所有逻辑都在一个单一的进程中运行，这允许你使用编程语言的基本功能将应用程序拆分成类、函数和命名空间。

更谨慎的做法是，你可以在一个开发者的笔记本上运行和测试多个应用程序，并且使用一个部署管道来确保改动都被正确的测试并且部署到了生产环境中。

你可以通过在一个负载均衡器后运行多个实例的方式来横向缩放这个单块应用。

单块应用可以被成功运用，但是渐渐地人们对蛋快应用感到不满——尤其是当越来越多的应用程序被部署到云端。

任何改动都会牵一发动全身——哪怕是对应用程序一个小地方的改变都需要整个单块应用被重新构建和部署。

随着时间的推移通常会很难保持一个良好的模块结构使得控制变更仅影响模块内部变得越加困难。

如要实现缩放，需要缩放整个应用程序而不是应用程序的某一部分，这要求更多的资源。

一个单体应用将它所有的功能放到一个单一的进程…

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-AKRhMkUi-1621472077296)(C:UsersASUSAppDataRoamingTyporatypora-user-imagesimage-20210511172552174.png)]

…并且通过在多台服务器上运行单块应用的副本来实现缩放

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-3ffk4PES-1621472077300)(C:UsersASUSAppDataRoamingTyporatypora-user-imagesimage-20210511172614147.png)]

一个微服务架构将每一个功能放到独立的服务中…

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-2JASfnEg-1621472077302)(C:UsersASUSAppDataRoamingTyporatypora-user-imagesimage-20210511172655628.png)]

…并且通过跨服务器分发这些服务来实现缩放，按需创建副本

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-iHDCtqjX-1621472077304)(C:UsersASUSAppDataRoamingTyporatypora-user-imagesimage-20210511172833929.png)]

以上为：单块架构和微服务架构的对比

这些不满催生了微服务架构风格：以一组服务来构建应用程序，除了使得服务能够被独立部署和缩放，每一个服务还提供了一个稳定的模块边界，甚至允许不同的服务使用不同的编程语言编写。

每个服务也可以由不同的团队来管理。

我们不想宣称微服务架构风格是新生的或者创新的，它的起源至少可以追溯到Unix的设计原则。

但是我们真的认为考虑使用微服务架构的人还不够多【Martin初次写作本文时才是2014年3月，随后的情况是微服务概念甚嚣尘上，以至于Martin又写了一篇《使用微服务的预备条件》来“降温”——译者著】，如果他们使用微服务架构的话，许多软件开发宫锁能够做得更好。

原站点脚注

[1] 2011年五月在威尼斯附近的一个软件架构师的工作室“微服务”这个词被用来形容大多数与会者近期正在探索的被视为通用的架构风格的架构。

在2012年的五月，同一支工作小组决定使用“微服务”这个词作为这种架构风格最合适的叫法。

在2012年3月克拉科夫市举办的“33rd Degree”技术大会上，James（本文作者之一）在其“Microservices – Java，the Unix Way”演讲中以案例的形式介绍了这些微服务的观点，在同一时间，Fred George也表达了相同观点。

Netflix公司的drian Cockcroft，将这种方法描述为“细粒度的SOA”，并且同本文中所提到的——Joe Walnes， Dan North，Evan Botcher and Graham Tackley这些人一样已经在web领域开展了实战。

[2] 单块这个词在Unix社区已经被使用了一段时间了。它出现在《UNIX编程艺术（The Art of UNIX Programming）》这本书中，用来形容过于巨大的系统。

微服务架构的特征

我们不能够说微服务有着一个正式地定义，但是我们可以尝试着描述那些被标上“微服务”标签架构的共同特征。

尽管可以列出共同特征，但并非所有的微服务架构都具备所有的特征，但是我们猜想绝大多数的微服务架构都显现出多数特征。

尽管我们两位作者已经成为微服务这个相当松散的社区的活跃成员，但我们的意愿是视图描述我们在自己和我们所指的团队中所了解的情况。

特别要指出，我们不会给出教条式的微服务的定义。

通过服务实现组件化

自软件工程诞生伊始，人们就有着通过将软件模块组合在一起来构建系统的愿望，就如同我们在现实生活中看到的事务被制造的方式。

在过去的几十年里，我们在公共组件库方面取得了长足的进展，这些大量的公共组件库已经成为多数编程语言平台的一部分。

当我们讨论组件时，我们首先得回答“什么是组件”。

我们的定义是：一个组件就是一个可以被独立替换和升级的软件单元。

微服务架构也会使用软件库，但是用来实现软件组件化的主要方式是将软件拆分成服务。

我们将被连接到一个程序并且通过内存函数调用的组件称为库，而服务确是进程外加载的组件，它通过例如web服务请求或者远程过程调用的方式通信。（各种OO语言程序中服务又是另一个概念了[3]）

选择使用服务作为组件（而不是库）的一个主要原因是服务是可以独立部署的。

假设你有一个包含多个库的应用程序[4]跑在一个单一的进程里，对任何单一组件的变更都将导致整个应用程序的重新部署。

但是如果这个应用程序被分解成多个服务，那么你可以期望对单一服务的多项变更只需要重新部署那个服务。

这不是绝对的，某些变更可能会改变服务接口从而导致某些内容协商问题，但是微服务架构的目的就是要通过明确的服务边界和演进设计的服务契约来最小化这些变更。

使用服务作为组件的另一个好处是更加明确的组件接口。

许多语言在定义明确的公共接口方面表现得不好。

通常它只有一些文档来描述如何组织客户端破坏组件的封装，这将导致组件间过渡的耦合。

服务通过使用明确的远程调用方法轻松地避免了这个问题。

Using services like this does have downsides.

Remote calls are more expensice than in-process calls,

and thus remote APIs need to be coarser-grained,

which is often more awkward to use.

If you need to change the allocation of responsiblities between components,

such movements of behavior are harder to do when you’re crossing process boundaries.

像这样使用服务也会带来副作用。

远程调用比起进程内调用要昂贵得多，因此远程API需要是粗粒度的，这通常更加不便于使用。

At a first approximation,

we can observe that services map to runtime processes,

but that is only a first approximation.

A service may consist of multiple processes that will always be developed and deployed together,

such as an application process and a database that’s only use by that service.

原站点脚注

[3] 许多面向对象的设计者，包括我们自己，使用“服务”这个词来描述领域驱动设计中没有与实体绑定的执行一个重要业务过程的对象。

这与我们在此篇文章中探讨的“服务”是不同的概念。

糟糕的是“服务”这个词有着两个意思，并且我们不得不忍受多义【事实上正是因为“聚义”，人类的语言才得到长足的发展——译者】。

[4] 我们将一个应用程序看做由代码、功能集合以及架构组成的社会结构。

围绕业务能力组织

是产品而不是项目

智能终结点和哑管道

去中心化的管理

去中心化的数据管理

基础架构自动化

为容错设计

演进式设计

微服务是未来吗/p>

翻译： 一丘 翻译日志：

以上为微服务最早的来源。

简单地说，微服务是系统架构上的一种设计风格，它的主旨是将一个原本独立的系统拆分成多个小型服务，这些小型服务都在各自独立的进程中运行，服务之间通过基于HTTP的RESTful API进行通信协作；（HTTP协议，RESTful 风格；在Dubbo当中是通过dubbo协议调用，将其称之为RPC，当然在微服务中基于HTTP的RESTful API进行通信协作也可以称之为RPC，RPC是一个整体的概念，仅仅是实现的方式不一致而已；那么微服务当中的RPC即基于HTTP协议的RESTful风格这种项目之间的调用；RESTful风格调用即简单理解就是Controller调用Controller，即一个SpringBoot的项目当中写有一个Controller，这个Controller可以调用另外一个Controller，那么另外一个Controller就相当于是服务的接口；RESTful API[controller –> 调用 controller]底层走HTTP协议）

被拆分后的每一个小型服务都专注于完成系统中某一项业务功能，职责单一，并且每个服务都是一个独立的项目，可以进行独立的测试、开发和部署等；（与其他项目无关，不影响其他项目，比如说一个用户服务，那么该服务只进行专注于用户的注册登录，其他功能都不专注，就专注于这一个功能，职责比较单一，如果需要注册登录功能，那么这个时候就调用该用户服务的注册登录接口，去通过RESTful API进行调用）

由于各个独立的服务之间使用的是基于HTTP的JSON作为数据通信协作的基础，所以这些微服务也可以使用不同的语言来开发；

（微服务没有一个统一，是一个概念，一种思想）

比如说在PHP开发时，或者用Python或者其他什么语言开发时，也可以使用微服务这种理念，两个项目之间通过JSON来进行数据交互。因为RESTful风格用户两个接口之间，在它们进行交互的时候就是通过JSON。

一个Controller A返回一个JSON，另外一个Controller B调用另外一个Controller C拿Controller A返回的JSON数据，Controller C拿到JSON数据之后再进行业务逻辑处理。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-IXcd1bZc-1621472077305)(C:UsersASUSAppDataRoamingTyporatypora-user-imagesimage-20210511220413196.png)]

客户端有PC端、手机端、还有H5等，它们在进行数据获取过程中会经过一个api网关服务（网关后续会有讲解到，微服务当中有很多的相关组件），再走到相关的产品服务、订单服务、用户服务…；

微服务和原来的分布式服务，架构是非常相似的，可能分布式服务也是进行拆分，比如说产品服务、订单服务、用户服务…，然后每一个服务下面都是属于该服务的数据库这种模式，它本身和分布式服务架构差不多。

微服务和分布式服务有什么区别/p>

比如：项目里面有User模块（用户模块）和Order模块（订单模块），但是User模块和Order模块并没有直接关系（微服务职责比较单一，每一个模块只专注该模块本身自己的事情），仅仅只是一些数据需要交互，那么就可以把这2个模块单独分开来（单独拆分，做两个微服务），当User需要调用Order的时候，Order是一个服务方（服务提供方），但是Order需要调用User的时候，User又是服务方了（User服务/Order服务既可以是消费方也可以是服务提供方），所以，他们并不在乎谁是服务方谁是调用方，它们都是2个独立的服务，这就是微服务的概念；（经过拆分之后，两个服务User服务和Order服务可以相互进行调用，两者都可以作为消费方或者服务方）

经典面试：分布式和微服务有什么区别/h4>

相同部分：

分布式，就是将巨大的一个系统（项目）划分为多个模块，这一点和微服务是一样的，都是要把系统进行拆分，部署到不同机器上，因为一台机器可能承受不了这么大的访问压力，或者说要支撑这么大的访问压力需要采购一台性能超级好的服务器，其财务成本非常高，有这些预算完全可以采购很多台普通的服务器了，分布式系统各个模块通过接口进行数据交互，其实分布式也是一种微服务，因为都是把模块拆分变为独立的单元，提供接口来调用，那么它们本质的区别是什么/p>

（微服务与分布式确实很相似，都是进行服务的拆分；它们之间有相同点也有不同点）

不同部分：

它们的本质的区别体现在“目标”上，何为目标，就是你采用分布式架构或者微服务架构，你最终是为了什么，要达到什么目的/p>

分布式架构的目标是什么/p>

就是访问量很大，一台机器承受不了，或者是成本问题，不得不使用多台机器来完成服务的部署。（分布式架构将服务拆分是为了用一些普通的机器来进行部署项目/服务）

而微服务的目标是什么/p>

只是让各个模块拆分开来，不会被互相影响，比如模块的升级或者出现BUG或者是重构等等都不要影响到其他模块（因为微服务模块它比较职责单一，粒度比较细化职责单一，关注的是服务之间影响的程度），微服务它是可以在一台机器上部署（即拆分了多个微服务，但是多个微服务可以在一台机器上部署，分布式也是可以在一台机器上进行部署的）；

从这个上面来说，分布式和微服务它们之间的不同点在于它们追求的目标不一样；分布式进行拆分缘故在于原来是一个单体应用，由于单体应用部署在一台机器上，在该机器上时，客户端在进行访问请求时，所有的功能都落在一台机器上，那么就有可能会造成这台机器的压力比较大，所以这个时候就会将这台机器上的该单体应用中的某些服务进行拆分出来放到其他的机器上去进行部署，这样就对该原来的机器或者某一台机器起到了一个分摊压力的作用；这是分布式架构追求的目标；

而微服务架构追求的目标即为，每个被拆分出来的微服务职责单一，它们之间的影响是最小化的，相互之间影响很小，依赖也很小，不会一个项目/服务A的改造升级重构对另外一个项目/服务B的影响度是很小很小的。

即这两者追求的目标不一样，这也是微服务和分布式之间的一个区别。从宏观上来说这两者没有什么很大的区别，都是为了拆分。

但是：分布式也是微服务的一种，微服务也属于分布式；

（它们两者之间你中有我，我中有你，但是它们的目标不一致，也是它们的区别）

面试：微服务与Spring-Cloud的关系或区别/h4>

微服务只是一种项目的架构方式、架构理念，或者说是一种概念，就如同我们的MVC架构一样，那么Spring Cloud便是对这种架构方式的技术落地实现。

面试：微服务一定要使用Spring Cloud吗/h4>

讲微服务时，可能首先想到的就是Spring Cloud。可能直接就对号入座是Spring Cloud，那么微服务不能直接说就是Spring Cloud。

微服务只是一种项目的架构方式、架构理念，所有任何技术都可以实现这种架构理念，只是微服务架构里面有很多问题需要我们去解决，比如：负载均衡，服务的注册与发现，服务调用，服务路由，服务熔断等等一系列问题，如果你自己从0开始实现微服务的架构理念，那头发都掉光了，所以Spring Cloud帮我们做了这些事情，Spring Cloud将处理这些问题的技术全部打包好了，我们只需要开箱即用。

微服务不光是Spring Cloud，还有其他技术也可以解决做微服务的功能，只是Spring Cloud是一整套的方案，帮我们解决了一系列的问题，这样的话我们进行开发就非常方便了，即很多的微服务问题都提供了有技术方案，不用自己去折腾。

What is Spring Cloud

官网：https://spring.io/projects/spring-cloud

版本：Greenwich SR3

出自官方：

微服务有很多个问题需要进行解决，Spring Cloud下由多个子项目进行构成。

目前看到Spring Cloud下的组件有：

  • Spring Cloud
    • Spring Cloud Azure
    • Spring Cloud Alibaba
    • Spring Cloud for Amazon Web Services
    • Spring Cloud Bus
    • Spring Cloud Circuit Breaker
    • Spring Cloud CLI
    • Spring Cloud for Cloud Foundry
    • Spring Cloud – Cloud Foundry Service Broker
    • Spring Cloud Cluster
    • Spring Cloud Commons
    • Spring Cloud Config
    • Spring Cloud Connectors
    • Spring Cloud Consul
    • Spring Cloud Contract
    • Spring Cloud Function
    • Spring Cloud Gateway
    • Spring Cloud GCP
    • Spring Cloud Kubernetes
    • Spring Cloud Netflix
    • Spring Cloud Open Service Broker
    • Spring Cloud OpenFeign
    • Spring Cloud Pipelines
    • Spring Cloud Schema Registry
    • Spring Cloud Security
    • Spring Cloud Skipper
    • Spring Cloud Sleuth
    • Spring Cloud Stream
    • Spring Cloud Stream App Starters
    • Spring Cloud Stream Applications
    • Spring Cloud Task
    • Spring Cloud Task App Starters
    • Spring Cloud Vault
    • Spring Cloud Zookeeper
    • Spring Cloud App Broker

当前稳定版本Greenwich SR3

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-aYdPnXWs-1621472089835)(C:UsersASUSAppDataRoamingTyporatypora-user-imagesimage-20210511225849002.png)]

在国内，版本之间的称呼：

Greenwich SR3称之为G版；

Hoxton RC1称之为H版；

Finchley SR4称之为F版；

或者还有A版、B版、D版；

它是从A~Z这个顺序去进行发布的版本，看首字母。

下一个版本的字母会比上一个版本的字母大。

当下去看版本：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-aYqVnFbr-1621472089836)(C:UsersASUSAppDataRoamingTyporatypora-user-imagesimage-20210511230003975.png)]

Spring Cloud特性

Spring Cloud为分布式系统开发的 典型应用场景 提供良好的 开箱即用的功能。

比如：

分布式/版本化配置

服务注册和发现

路由

服务与服务间的调用

负载均衡

断路器

全局锁

领导选举与集群状态

分布式消息传递

由于要解决不止是以上的问题，Spring Cloud下提供了很多的组件来进行解决相关问题。

Spring Cloud下的主要项目

  • Spring Cloud Config
  • S

    来源：Fengshana

    声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！

上一篇 2021年4月18日
下一篇 2021年4月18日

相关推荐

首页
软件超市
企服市场
会员中心