算是新开了一个 Spring Cloud 的坑，本文来源于姚半仙的《Spring Cloud 微服务项目实战》课程，大部分文字内容基于该课程，我的工作可能就是梳理归纳和拓展，希望尽快搞懂相对来说较为简单的 Spring Cloud Alibaba 微服务框架，感兴趣的同学也欢迎讨论~

成都创新互联是一家集网站建设,云龙企业网站建设,云龙品牌网站建设,网站定制,云龙网站建设报价,网络营销,网络优化,云龙网站推广为一体的创新建站企业，帮助传统企业提升企业形象加强企业竞争力。可充分满足这一群体相比中小企业更为丰富、高端、多元的互联网需求。同时我们时刻保持专业、时尚、前沿，时刻以成就客户成长自我，坚持不断学习、思考、沉淀、净化自己，让我们为更多的企业打造出实用型网站。

目录

1 微服务简单介绍

2 微服务的演进

2.1 单体应用的落寞

2.2 微服务架构崛起

2.3 优势和保护措施

3 Spring Cloud 介绍

3.1 Spring Cloud 起源

3.2 组件库更迭

3.3 全家桶组件库

3.4 全家桶组件库

---

1 微服务简单介绍

简单来说，微服务可概括为“三大功能，两大特性”。

三大功能是指微服务核心组件的功能维度，由浅入深层次递进；而两大特性是构建在每个服务组件之上的高可用性和高可扩展性。

服务间通信：服务治理、负载均衡、服务间调用；

服务容错和异常排查：流量整形、降级熔断、调用链追踪；

分布式能力建设：微服务网关、分布式事务、消息驱动、分布式配置中心。

从微服务组件的功能维度来讲，服务间通信是最基础的功能特性，这个功能模块是最适合作为初学者学习微服务技术的切入点。当我们构建起基础的通信能力之后，接下来就要考虑如何构建服务容错能力，提高服务调用的稳定性了。在这之后，我们就可以从全局的角度构建一些分布式支持特性。这样，你就有了一条难度平缓上升的学习曲线，再也不会从入门到放弃了。

除了功能特性以外，在学习每个微服务组件的时候，我们还会从高可用性和可扩展性两个维度来做扩展。高可用性是系统设计的第一要素，它就像人的健康一样。健康好比数字 1，能赚多少钱都是后面的 0 来决定，甭管你多能赚钱，没有了健康一切归零。系统设计也一样，你的系统功能再厉害，都要构建在可用性之上才能发挥作用。所以，我们还需要了解各个微服务组件是如何保证高可用性的。

说到可扩展性，这就要考验你对框架原理的理解了。授人以鱼不如授人以渔，学会用一个组件顶多算是吃到了鱼，而学会“魔改”组件才算是会钓鱼。所以，了解组件的底层原理，学会如何基于开源项目的扩展点实现一些定制功能，才能真正用好微服务技术。

2 微服务的演进

从实践领域来看，不夸张地说，国内 Java 系的一二线中大厂，已全面拥抱微服务，谷歌搜索指数显示，自 2014 年起，微服务的搜索热度一路上升，如今各大厂甚至基于本公司研发了适配微服务框架的组件，这不就得卷起来了么~

2.1 单体应用的落寞

在互联网技术发展的早期阶段，大家采用“单体应用”的方式来构建网络系统。

以 Java 单体应用为例，首先将业务逻辑打包在一起，做成一个 WAR 包部署到 Tomcat、JBoss 之类的容器中，对外提供服务。业务上了一定规模之后，再通过集群化水平扩展的方式，将单体应用部署到一个集群中，承接更大的用户访问量。然而，随着业务复杂度的进一步提升，单体应用在生产力和高可用性层面就面临了巨大的挑战。

当时如果参与一个大型单体项目的开发，可能开发测试团队不止100人，所有人的代码都将提交到一个主干分支，每次 merge 代码都要面对各种代码冲突，开发过程中耗费了大量的沟通成本，研发效率非常低下，完全无法达到“快速迭代”的目的。

2.2 微服务架构崛起

微服务相当于把单体应用拆分成数个微服务项目，体现了“分而治之”的思想~

微服务架构其实是在 SOA（面向服务架构）之上做的进一步扩展。在一线实践中，通过领域建模等理论将一个大型应用拆分成了更细粒度且边界清晰的服务模块。而且，每个微服务都能被独立测试、独立部署，并借助 Docker 和 CI/CD（持续集成环境）完成快速上线，不必像单体应用一样经历繁琐的 release 流程和漫长的发布窗口。

每个微服务就像一个“麻雀虽小、五脏俱全”的小王国，它拥有独立的代码库和数据库 Schema，通常由一个小规模的微服务技术团队全权负责，这个团队汇聚了产品、技术、架构等人员，采用 Scrum 之类的敏捷开发流程做快速迭代。基于此，微服务具备了“独立演进”能力。

2.3 优势和保护措施

“微服务”架构可可以说解决了单体应用的诸多痛点，具备以下几个天然优势：

• 快速迭代及回滚：细粒度的可独立部署的小型服务，再加上敏捷开发模式的加持，可以让你对产品功能实现快速迭代。如果迭代过程中发现线上 Bug，也可以在最短的时间内做线上回滚，并且不会影响到其他应用的正常发布。
• 资源利用率提高：可以将硬件等资源定向分配给需要用到资源的微服务，实现差异化的资源利用。大厂的微服务体系会统计每个服务集群的线上压力水位，应用弹性计算技术在各个服务之间调配计算资源。
• 大幅降低协作成本：代码库、数据库、编译打包从“共享”变为了“独享”，微服务团队也保持了小规模特战队的模式，进一步降低了组内组外的沟通协作成本。

相比前牵一发而动全身的单体应用来说，我们也可以通过很多技术手段对微服务施加个性化的保护措施，比如弹性机房水位调拨、流量整形、熔断降级。

• 弹性机房水位调拨：弹性机房实现了计算资源的自动分配，这种弹性伸缩能力必须建立在微服务化的基础上。它可以根据每个微服务的重要程度（核心服务 vs 边缘业务）以及当前承接的用户访问压力，动态地将计算资源（如虚机、云存储）分配给需要资源的服务。
• 流量整形：根据每个微服务承载能力的不同，控制外部流量抵达服务的速率。“限流”其实只是流量整形的一个场景，大型微服务的流量整形有很多种方式，比如匀速排队、流量预热、削峰填谷等等。
• 熔断降级：在流量高峰的时候，我们可以对边缘服务做人工降级，把计算资源腾挪给核心应用，降低核心服务的访问压力。除了人工降级以外，我们还可以为每个服务设置自动降级和熔断指标，比如当调用失败率达到某个阈值之后，开启自动降级措施，降低对下游业务的访问压力。

我们只有把应用微服务化之后，才能更好地使用上面这些技术手段对业务系统做精细力度的保护，从而实现高可用的目标。

如此，我们已经对于微服务架构有了更深一步的认识。当然，任何事物都有其两面性，微服务不光有好的一面，也有很多问题等着我们去解决。比如集群环境下的服务治理、数据一致性、以及高并发场景下的服务容错等等。不过，这也是本专栏存在的意义，之后会一一讲解如何使用 Spring Cloud 组件并将其一一攻破。

3 Spring Cloud 介绍

Spring Cloud 是主流的微服务框架之一，本章节将详细讲解 Spring Cloud 的发展历史，并介绍 Netflix 和 Alibaba 两大核心组件库，以及 Spring Cloud 的版本更新策略，以达到对于Spring Cloud 框架有了一个全面的认识。

3.1 Spring Cloud 起源

Spring Cloud 由 Spring 开源社区主导孵化，是专门为了解决微服务架构难题而诞生的一款微“微服务全家桶”框架。而且除了 Spring 开源社区的研发力量以外，它还吸纳了很多业界一线互联网大厂的开源组件为己用，将这些经过大厂真实业务锤炼的组件孵化成为了 Spring Cloud 组件的一部分。

以下是 Spring 社区发布的一张简化的架构图：

在上面这幅图中，我们可以看到有几个 Spring Boot Apps 的应用集群，这就是经过拆分后的微服务。Spring Cloud 和 Spring Boot 达成了一种默契的配合：Spring Boot 主内，通过自动装配和各种开箱即用的特性，搞定了数据层访问、RESTful 接口、日志组件、内置容器等等基础功能，让开发人员不费吹灰之力就可以搭建起一个应用；Spring Cloud 主外，在应用集群之外提供了各种分布式系统的支持特性，帮助你轻松实现负载均衡、熔断降级、配置管理等诸多微服务领域的功能。

到这里，相信你已经可以理解 Spring Boot 和 Spring Cloud 的侧重点，以及 Spring Cloud 的功能定位。那么接下来将介绍下 Spring Cloud 内部都有哪些重要组件~

3.2 组件库更迭

在我们开始了解 Spring Cloud 组件库之前，我得先介绍在 Spring Cloud 历史上举足轻重的两家公司 Netflix 和 Alibaba，以及它们的恩怨情仇。这两家公司分别为开源社区贡献了 Spring Cloud Netflix 组件库和 Spring Cloud Alibaba 组件库。

Netflix 俗称“奈飞”，作为流媒体巨头，它靠着自己强大的技术实力，开发沉淀了一系列优秀的组件，如 Eureka 服务注册中心、Ribbon 负载均衡器、Hystrix 服务容错组件等，不过 Netflix 对于部分组件开源计划的搁置和停止维护，导致Spring 社区不得不开始思考替代方案，于是在后续的新版本中走向了“去 Netflix 化”。

Spring Cloud Alibaba 是由 Alibaba 贡献的组件库，随着阿里在开源路线上的持续投入，近几年阿里系在开源领域的声音非常响亮。Spring Cloud Alibaba 凝聚了阿里系在电商领域超高并发经验的重量级组件，保持了旺盛的更新活力，成为了 Spring Cloud 社区的一股新生代力量，逐渐取代了旧王 Netflix 的江湖地位。Spring Cloud Alibaba 组件秉承了“大而全”的特点，就像一个大中台应用一般包罗万象，在功能特性的丰富程度上做到了应有尽有。

3.3 全家桶组件库

下图将 Spring Cloud 中的核心组件库根据功能点做了分类，让你对每个特性功能的可选组件一目了然，其中红色加粗的，是本项目要集成的组件：

上面表格中列出的是业务开发过程中的常用功能性组件，除了这些以外，Spring Cloud 官方还提供了很多可扩展组件，比如用来支持构建集群的 Spring Cloud Cluster、提供安全特性支持的 Spring Cloud Security、云原生的流处理数据管道 Spring Cloud Data Flow 等等，参考官方文档：Spring Cloud

3.4 全家桶组件库

大部分开源项目以数字版本进行更新迭代，Spring Cloud 在诞生之初就别出心裁使用了字母序列，以字母 A 开头，按顺序使用字母表中的字母标识重大迭代发布的大版本号。

以下表格包含了 Spring Cloud 编年史各个版本的代号以及 Release 版的发布时间，感受一下 Spring Cloud 的更新节奏：

看得出，Spring Cloud 自 2015 年发布之始就保持了极其旺盛的生命力，早期版本每半年就有一个大的版本号迭代，即便发展至今，也保持着几乎一年一升版的快速更新节奏。正是由于开源社区的持续输出，以及像 Alibaba 这类大型公司的助力，才有了今天微服务领域最为完善的 Spring Cloud 全家桶组件库。

在大版本发布之前，还要经历很多小版本的迭代，接下来了解一下 Spring Cloud 的小版本更新策略。如果你不清楚这里面的门道，很容易就会误用非稳定版本：

• SNAPSHOT 版本：正在开发中的快照版本，例如 2021.0.0-SNAPSHOT，快照版代表当前分支最新的代码进度，也是更新最为频繁的小版本类型，不推荐在线上正式环境使用；
• Milestone 版本：在大版本正式发布前的里程碑版本，例如 2021.0.0-M1，M1 代表当前大版本的第一个里程碑版本，M2 代表第二个迭代里程碑，以此类推。在正式版本发布之前要经历多个里程碑的迭代，像 Spring Cloud Finchley 版足足经历了 9 个 M 版本之后，才过渡到了 RC 版。同样地，不推荐你在正式项目中使用 Milestone 版本；
• Release Candidate 版本：这就是我们俗称的 RC 版，例如 2021.0.0-RC1。当一个版本迭代到 RC 版的时候，意味着离正式发布已经不远了。但是你要注意，RC 版是发布前的候选版本，走到这一步通常已经没有新的功能开发，RC 主要目的是开放出来让大家试用并尽量修复严重 Bug。
• Release 版：稳定的正式发布版，比如 2020.0.1。你可以在自己的线上业务中放心使用 Release 稳定版。

为求稳定，使用 Release 版就好~

---

总结

大家如果有疑问都可以评论提出，有不足之处请大家批评指正，希望能多结识这方面的朋友，共同学习、共同进步。

你是否还在寻找稳定的海外服务器提供商？创新互联www.cdcxhl.cn海外机房具备T级流量清洗系统配攻击溯源，准确流量调度确保服务器高可用性，企业级服务器适合批量采购，新人活动首月15元起，快前往官网查看详情吧

文章名称：【Java开发】SpringCloud01：微服务前提精要-创新互联
URL分享：http://kswjz.com/article/cegghj.html