SpringCloud（1）生态与简绍

一：微服务架构简绍学习目标

1.技术架构的演变，怎么一步步到微服务的；2.什么是微服务，优点与缺点  ；3.SOA（面向服务）与MicroServices（微服务）的区别 ；4.Dubbo 与Spring Cloud  ；5.微服务的设计原则（a：AKF拆分原则，前后端分离原则，无状态服务，Restful通信风格）

二：架构演变

1.单一应用架构

当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。

此时，用于简化增删改查工作量的 数据访问框架(ORM) 是关键。

缺点：随着应用功能的增多，代码量越来越大，越来越难维护，那怎么解决代码一体化的问题？

2.垂直应用架构

当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效

率。

此时，用于加速前端页面开发的 Web框架(MVC) 是关键。

缺点：垂直架构中相同逻辑代码需要不断的复制，不能复用。每个垂直模块都相当于一个独立的系统。

3.RPC分布式服务架构

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的

服务中心，使前端应用能更快速的响应多变的市场需求。

此时，用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。

缺点：服务越来越多，需要管理每个服务的地址，调用关系错综复杂，难以理清依赖关系，服务状态难以

管理，无法根据服务情况动态管理。

4.SOA流动计算架构

资源的调度，负载均衡，动态服务创建，服务治理

当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压

力实时管理集群容量，提高集群利用率。

此时，用于提高机器利用率的 资源调度和治理中心(SOA) 是关键。

缺点：服务间会有依赖关系，一旦某个环节出错会影响较大，服务关系复杂，运维、测试部署困难，不符

合DevOps思想。

5.微服务架构：

单一职责：微服务中每一个服务都对应唯一的业务能力，做到单一职责

微：微服务的服务拆分粒度很小，例如一个用户管理就可以作为一个服务。每个服务虽小，但“五脏俱

全”。

面向服务：面向服务是说每个服务都要对外暴露服务接口API。并不关心服务的技术实现，做到与平台和语言无

关，也不限定用什么技术实现，只要提供 Rest 的接口即可。

自治：自治是说服务间互相独立，互不干扰

团队独立：每个服务都是一个独立的开发团队，人数不能过多。

技术独立：因为是面向服务，提供 Rest 接口，使用什么技术没有别人干涉。

前后端分离：采用前后端分离开发，提供统一 Rest 接口，后端不用再为 PC、移动端开发不同接口。

数据库分离：每个服务都使用自己的数据源

部署独立，服务间虽然有调用，但要做到服务重启不影响其它服务。有利于持续集成和持续交付。每

个服务都是独立的组件，可复用，可替换，降低耦合，易维护 Docker 部署服务

 

三：什么是微服务

      简而言之，微服务架构风格是一种将单个应用程序作为一套小型服务开发的方法，每种应用程序都在自己

的进程中运行，并与轻量级机制（通常是HTTP资源API）进行通信。 这些服务是围绕业务功能构建的，可以通

过全自动部署机制独立部署。 这些服务的集中管理最少，可以用不同的编程语言编写，并使用不同的数据存储

技术。

    微服务就是将一个单体架构的应用按业务划分为一个个的独立运行的程序即服务，它们之间通过 HTTP 协议进行

通信（也可以采用消息队列来通信，如 RabbitMQ，Kafaka 等），可以采用不同的编程语言，使用不同的存储技

术，自动化部署（如 Jenkins）减少人为控制，降低出错概率。服务数量越多，管理起来越复杂，因此采用集中化管

理。例如 Eureka，Zookeeper 等都是比较常见的服务集中化管理框架。

微服务是一种架构风格。一个大型的复杂软件应用，由一个或多个微服务组成。系统中的各个微服务可被独立部

署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好的完成该任务。

 

优点：

测试容易   可伸缩性强   可靠性强   跨语言    协同开发     方便系统迭代

缺点：运维成本高，部署项目多    接口兼容版本问题     分布式系统的复杂性     分布式事务

四：SOA与MIcroServices（微服务）的区别

      面向服务架构（SOA）是一种用于设计软件的伟大原则。在 SOA 中，所有组件都是独立自主的，并能为其他组

件提供服务。大体上，SOA与微服务架构是非常相像的。那么它们之间的区别到底是什么呢？微服务是细粒度的 SOA

组件。换句话说，某单个 SOA 组件可以被拆成多个微服务，而这些微服务通过分工协作，可以提供与原 SOA 组件相

同级别的功能。

     微服务是细粒度的SOA组件，它们是关注点更窄的轻量级服务。微服务推崇执行的标准（例如HTTP）是人们广

泛了解并共同使用的。我们可以通过选择合适的语言或工具来构建某个组件（微服务），除了技术栈与服务规模之

外，在SOA与微服务之间还有一个更大的区别：领域模型。在一个基于微服务的软件中，每个微服务应该在本地存储

自身管理的数据，并将领域模型分别隔离到单个服务中。而在面向 SOA 的软件中，数据往往存储在单个大型的数据

库中，服务之间会共享领域模型。

SOA                                                                            微服务架构
应用程序服务的可重用性的最大化                                       专注于解耦
系统性的改变需要修改整体                                                系统性的改变是创建一个新的服务
DevOps和持续交付正在变得流行，但还不是主流                 强烈关注DevOps和持续交付
专注于业务功能重用                                                         更重视“上下文边界”的概念
通信使用企业服务总线ESB（Enterprise Service Bus）   对于通信而言，使用较少精细和简单的消息系统
支持多种消息协议                                                     使用轻量级协议，例如HTTP，REST或ThriftAPI
对部署到它的所有服务使用通用平台                             应用程序服务器不是真的被使用，通常使用云平台
容器（如Docker）的使用不太受欢迎                                容器在微服务方面效果很好
SOA服务共享数据存储                                                   每个微服务可以有一个独立的数据存储
共同的治理和标准                                                           轻松的治理，更加关注团队协作和选择自由

一句话总结：微服务是 SOA 发展出来的产物，它是一种比较现代化的细粒度的 SOA 实现方式。

四：Dubbo与Spring Cloud的区别

Spring全家桶

Dubbo很多国内的企业还在用，可以支持RestFul风格的API，调用远程API像调用本地API一样，同时其基于接口的方式增加了服务间的耦合。

总结

Dubbo 由于是二进制的传输，占用带宽会更少

SpringCloud 是 http 协议传输，带宽会比较多，同时使用 http 协议一般会使用 JSON 报文，消耗会更大

Dubbo 的开发难度较大，原因是 Dubbo 的 jar 包依赖问题很多大型工程无法解决

SpringCloud 的接口协议约定比较自由且松散，需要有强有力的行政措施来限制接口无序升级

Dubbo 的注册中心可以选择 ZooKeeper Redis Nacos 等多种，SpringCloud 的注册中心可以用 Eureka Consul

等

从系统结构简易程序：SpringCloud 的系统结构更简单、“注册 + SpringMvc = SpringCloud”，而 Dubbo 各种

复杂的 url，protocol，register，invocation，dubbofifilter，dubboSPI，dubbo序列化......

从性能：Dubbo 的网络消耗小于 SpringCloud，但是在国内 95% 的公司内，网络消耗不是什么太大问题，如

果真的成了问题，通过压缩、二进制、高速缓存、分段降级等方法，很容易解决。

 

五：微服务设计原则

1.AKF 拆分原则

业界对于可扩展的系统架构设计有一个朴素的理念，就是：通过加机器可以解决容量和可用性问题（如果一台不

行就两台）。

用个段子描述就是：世界上没有什么事是一顿烧烤解决不了的，如果有，那就两顿。

这一理念在“云计算”概念疯狂流行的今天。得到了广泛的认可。对于一个规模迅速增长的系统而言。容量和性能

问题当然是首当其冲的。但是随着时间的向前，系统规模的增长，除了面对性能与容量的问题外，还需要面对功能与

模块数量上增长带来的系统复杂性问题。以及业务变化带来的提供差异化服务问题。而许多系统在架构设计时并未充

分考虑到这些问题，导致系统的重构成为常态。从而影响业务交付能力，还浪费人力财力。对此《The Art of

Scalability》一书提出了一个更加系统的可扩展模型——AKF 可扩展立方。这个立方体中沿着三个坐标轴设置分别为

X，Y，Z。

         一个叫 AKF 的公司的技术专家抽象总结的应用扩展的三个维度。理论上按照这三个扩展模式，可以将一个

单体系统，进行无限扩展。

X 轴：指的是水平复制，很好理解，就是讲单体系统多运行几个实例，成为集群加负载均衡的模式。

Z 轴：是基于类似的数据分区，比如一个互联网打车应用突然火了，用户量激增，集群模式撑不住了，那就按照

用户请求的地区进行数据分区，北京、上海、四川等多建几个集群。

Y 轴：就是我们所说的微服务的拆分模式，就是基于不同的业务拆分。

场景说明：比如打车应用，一个集群撑不住时，分了多个集群，后来用户激增还是不够用，经过分析发现

是乘客和车主访问量很大，就将打车应用拆成了三个，分别为乘客服务、车主服务、支付服务。三个服务的业

务特点各不相同，独立维护，各自都可以再次按需扩展。

 

2.前后端分离原则

前后端技术分离，可以由各自的专家来对各自的领域进行优化，这样前端的用户体验优化效果更好。

前后端分离模式下，前后端交互界面更清晰，就剩下了接口模型，后端的接口简洁明了，更容易维护。

前端多渠道集成场景更容易实现，后端服务无需变更，采用统一的数据和模型，可以支持多个前端：例如：微

信 h5 前端、PC 前端、安卓前端、IOS 前端。

 

3.无状态服务

（无状态就是请把温度调到27度，有状态就是+1与-1）

对于无状态服务，首先说一下什么是状态：如果一个数据需要被多个服务共享，才能完成一笔交易，那么这个数

据被称为状态。进而依赖这个“状态”数据的服务被称为有状态服务，反之称为无状态服务。那么这个无状态服务原则

并不是说在微服务架构里就不允许存在状态，表达的真实意思是要把有状态的业务服务改变为无状态的计算类服务，

那么状态数据也就相应的迁移到对应的“有状态数据服务”中。场景说明：例如我们以前在本地内存中建立的数据缓

存、Session 缓存，到现在的微服务架构中就应该把这些数据迁移到分布式缓存中存储，让业务服务变成一个无状态

的计算节点。迁移后，就可以做到按需动态伸缩，微服务应用在运行时动态增删节点，就不再需要考虑缓存数据如何

同步的问题。

也就是对同一个 url 请求没有上下文关系。举个生活中的例子：

比如空调遥控器，你按上下调整温度时，空调温度设定值会变化，遥控器信号到空调是单向传输。现在空

调显示温度 20 度，遥控器 20 度。如果遥控器与空调之间是有状态的，假设你离开空调接收范围调整了遥控器

温度，变成 19，那回到范围内你按一次升高一度，基于原先温度状态，遥控器给空调发送一个“提高1度”的指

令，就会出现遥控器提高到 20，而空调变成21。如果要空间与空调之前是无状态的，假设你离开空调接收范

围调整了遥控器温度，变成 19，那回到范围内你按一次升高一度，遥控器给空调发送一个“设定温度值20”，这

样两者最终还是相同的值。

 

4.RestFul通信风格

返回的是json数据（其实RestFul就是通过RestFul风格来设计Url路径来进行微服务的开发）

基于“无状态通信原则”，在这里我们直接推荐一个实践优选的 Restful 通信风格 ，因为他有很多好处：

无状态协议 HTTP，具备先天优势，扩展能力很强。例如需要安全加密时，有现成的成熟方案 HTTPS 可用。

JSON 报文序列化，轻量简单，人与机器均可读，学习成本低，搜索引擎友好。

语言无关，各大热门语言都提供成熟的 Restful API 框架，相对其他的一些 RPC 框架生态更完善。

 

六：什么是SpringCloud（学习目标）

1.概念的定义，2.SpringCloud第一代   3.版本说明（单词与数字的区别，定义规则，发布计划，子项目版本说明）  4.SpringCloud第二代

1.概念定义

Spring Cloud 是一个服务治理平台，提供了一些服务框架。包含了：服务注册与发现、配置中心、消息中心 、

负载均衡、数据监控等等。

Spring Cloud 是一个微服务框架，相比 Dubbo 等 RPC 框架，Spring Cloud 提供了全套的分布式系统解决方

案。

Spring Cloud 对微服务基础框架 Netflflix 的多个开源组件进行了封装，同时又实现了和云端平台以及 Spring

Boot 框架的集成。

Spring Cloud 是一个基于 Spring Boot 实现的云应用开发工具，它为开发中的配置管理、服务发现、断路器、

智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等操作提供了一种简单的开发方式。

Spring Cloud 为开发者提供了快速构建分布式系统的工具，开发者可以快速的启动服务或构建应用、同时能够

快速和云平台资源进行对接。微服务是可以独立部署、水平扩展、独立访问（或者有独立的数据库）的服务单元，

Spring Cloud 就是这些微服务的大管家，采用了微服务这种架构之后，项目的数量会非常多，Spring Cloud 做为大

管家需要管理好这些微服务，自然需要很多小弟来帮忙。

SpringCloud第一代

SpringCloud第二代

七：SpringCloud Netflix 第一代

      Netflflix是一家美国公司，在美国、加拿大提供互联网随选流媒体播放，定制DVD、蓝光光碟在线出租业

务。该公司成立于1997年，总部位于加利福尼亚州洛斯盖图，1999年开始订阅服务。2009年，该公司可提供

多达10万部DVD电影，并有1千万的订户。2007年2月25日，Netflflix宣布已经售出第10亿份DVD。HIS一份报

告中表示，2011年Netflflix网络电影销量占据美国用户在线电影总销量的45%。

 

     针对多种 Netflflix 组件提供的开发工具包，其中包括 Eureka、Hystrix、Ribbon、Zuul、Archaius 等。

Netflix Eureka ：一个基于 Rest 服务的服务治理组件，包括服务注册中心、服务注册与服务发现机制的实

现，实现了云端负载均衡和中间层服务器的故障转移。

Netflix Hystrix ：容错管理工具，实现断路器模式，通过控制服务的节点，从而对延迟和故障提供更强大的

容错能力。

Netflix Ribbon ：客户端负载均衡的服务调用组件。

Netflix Feign ：基于 Ribbon 和 Hystrix 的声明式服务调用组件。

Netflix Zuul ：微服务网关，提供动态路由，访问过滤等服务。

Netflix Archaius ：配置管理 API，包含一系列配置管理 API，提供动态类型化属性、线程安全配置操作、轮

询框架、回调机制等功能。

 

八：SpringCloud Alibaba第二代

①：SpringCloudNetflix的配置中心是Archaius，我们一般也用SpringCloudConfig来当配置中心（这个是SpringCloud的配置中心）

Alibaba用的就是Nacos来当配置中心

②：服务注册 SpringCloudNetflix用的是Eureka， SpringCloudAlibaba用的是Nacos

Spring Cloud Alibaba 致力于提供微服务开发的一站式解决方案。此项目包含开发分布式应用微服务的必需组

件，方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。

依托 Spring Cloud Alibaba，只需要添加一些注解和少量配置，就可以将 Spring Cloud 应用接入阿里微服务解

决方案，通过阿里中间件来迅速搭建分布式应用系统。

Nacos ：阿里巴巴开源产品，一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。

Sentinel ：面向分布式服务架构的轻量级流量控制产品，把流量作为切入点，从流量控制、熔断降级、系统负

载保护等多个维度保护服务的稳定性。

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

阅服务。

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

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

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

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

安全、低成本、高可靠的云存储服务。您可以在任何应用、任何时间、任何地点存储和访问任意类型的数据。

Alibaba Cloud SchedulerX ：阿里中间件团队开发的一款分布式任务调度产品，提供秒级、精准、高可靠、

高可用的定时（基于 Cron 表达式）任务调度服务。

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

达通道。

九：SpringCloud常用的组件

常用组件

Spring Cloud Netflix Eureka ：服务注册中心。

Spring Cloud Netflix Ribbon ：客户端负载均衡。

Spring Cloud Netflix Hystrix ：服务容错保护。

Spring Cloud Netflix Feign ：声明式服务调用。

Spring Cloud OpenFeign(可替代 Feign) ：OpenFeign 是 Spring Cloud 在 Feign 的基础上支持了 Spring

MVC 的注解，如 @RequesMapping等等。OpenFeign 的 @FeignClient 可以解析 SpringMVC 的

@RequestMapping 注解下的接口，并通过动态代理的方式产生实现类，实现类中做负载均衡并调用其他服

务。

Spring Cloud Netflix Zuul ：API 网关服务，过滤、安全、监控、限流、路由。

Spring Cloud Gateway(可替代 Zuul) ：Spring Cloud Gateway 是 Spring 官方基于 Spring 5.0，Spring

Boot 2.0 和 Project Reactor 等技术开发的网关，Spring Cloud Gateway 旨在为微服务架构提供一种简单而有

效的统一的 API 路由管理方式。Spring Cloud Gateway 作为 Spring Cloud 生态系中的网关，目标是替代

Netflflix Zuul，其不仅提供统一的路由方式，并且基于 Filter 链的方式提供了网关基本的功能，例如：安全，监

控/埋点，和限流等。

Spring Cloud Config ：分布式配置中心。配置管理工具，支持使用 Git 存储配置内容，支持应用配置的外部

化存储，支持客户端配置信息刷新、加解密配置内容等。

Spring Cloud Bus ：事件、消息总线，用于在集群（例如，配置变化事件）中传播状态变化，可与 Spring

Cloud Confifig 联合实现热部署。

Spring Cloud Stream ：消息驱动微服务。

Spring Cloud Sleuth ：分布式服务跟踪。

Spring Cloud Alibaba ：阿里巴巴结合自身微服务实践，开源的微服务全家桶。在 Spring Cloud 项目中孵

化，很可能成为Spring Cloud 第二代的标准实现。

虽然 Eureka，Hystrix 等不再继续开发或维护，但是目前来说不影响使用，

 

十：SpringCloud为什么版本号用的是单词而不用数字

这样设计的目的是为了更好的管理每个 Spring Cloud 的子项目的清单。避免总版本号与子项目的版本号混淆。

例如：Spring Cloud 2.2.0.RELEASE 的 Spring Cloud Netflflix 2.2.2.RELEASE 如果使用这种方式会让开发者混淆

版本

 

十一：SpringCloud的版本定义和发布详细

定义规则

采用伦敦的地铁站名称来作为版本号的命名，根据首字母排序，字母顺序靠后的版本号越大。

Spring 官方详细的版本查看接口：https://start.spring.io/actuator/info

发布计划

子项目版本说明

例如：Spring Cloud Alibaba 2.1.0.RELEASE

2：主版本号。当功能模块有较大更新或者整体架构发生变化时，主版本号会更新。

1：次版本号。次版本表示只是局部的一些变动。

0：修改版本号。一般是 bug 的修复或者是小的变动。

RELEASE：希腊字母版本号。标注当前版本的软件处于哪个开发阶段

 

希腊字母版本说明

Base：设计阶段。只有相应的设计没有具体的功能实现。

Alpha：软件的初级版本。存在较多的 bug。

Bate：表示相对 Alpha 有了很大的进步，消除了严重的 bug，还存在一些潜在的 bug。

Gamma：是 Beta 版做过一些修改，成为正式发布的候选版本（Release Candidate）

Release：该版本表示最终版。