Java Spring Cloud：（一）Spring Cloud 简介
Spring Cloud 简介
1.微服务简介
1.1 什么是微服务？
- 微服务的概念最早是在 2014 年由 Martin Fowler 和 James Lewis 共同提出，他们定义了微服务是由单一应用程序构成的小服务，拥有自己的进程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用 HTTP API 通讯。同时，服务会使用最小规模的集中管理 （例如 Docker）技术，服务可以用不同的编程语言与数据库等。
- 简单举例：看军事新闻的朋友应该都知道，一艘航空母舰作战能力虽然很强，但是弱点太明显，就是防御能力太差，单艘的航空母舰很少单独行动，通常航空母舰战斗群才是主要军事力量，你可以把单艘航母理解为的单体应用（防御差，机动性不好），把航母战斗群（调度复杂，维护费用高）理解为微服务。
1.2 为什么使用微服务？
1.2.1 单体应用特点
- 大部分的开发者经历和开发过单体应用，无论是传统的 Servlet + JSP，还是 SSM，还是现在的 SpringBoot，它们都是单体应用，那么长期陪伴我们的单体应用有什么弊端？我们是面临了什么问题，导致我们要抛弃单体应用转向微服务架构？主要原因如下：
- 部署成本高（无论是修改 1 行代码，还是 10 行代码，都要全量替换）
- 改动影响大，风险高（不论代码改动多小，成本都相同）。
- 因为成本高，风险高，所以导致部署频率低（无法快速交付客户需求）。
- 无法满足快速扩容，弹性伸缩，无法适应云环境特性等问题。
1.2.2 微服务特点
- 微服务架构的特点：针对特定服务发布，影响小，风险小，成本低；频繁发布版本，快速交付需求；低成本扩容，弹性伸缩，适应云环境。
- 我们知道一个朴素的理念，没有任何事物是完美的，任何东西都有两面性，有得必有失，那么在选择微服务在解决了快速响应和弹性伸缩的问题同时，它又给我们带来了什么问题？简单总结如下：
- 分布式系统的复杂性
- 部署，测试和监控的成本问题
- 分布式事务和 CAP 的相关问题
- 系统应用由原来的单体变成几十到几百个不同的工程，会所产生例如包括服务间的依赖，服务如何拆封，内部接口规范，数据传递等等问题，尤其是服务拆分，需要团队熟悉业务流程，懂得取舍，要保证拆分的粒度服务既符合“高内聚，低耦合”的基本原则，还要兼顾业务的发展以及公司的愿景，要还要说服团队成员为之努力，并且积极投入，在多方中间取得平衡。
- 对于分布式系统，部署，测试和监控都需要大量的中间件来支撑，而且中间件本身也要维护，原先单体应用很简单的事务问题 ，转到分布式环境就变得很复杂，分布式事务是采用简单的重试+补偿机制，还是采用二阶段提交协议等强一致性方法来解决，就要取决对业务场景的熟悉加上反复的权衡了，相同问题还包括对 CAP 模型的权衡，总之微服务对团队整体的技术栈水平整体要求更高。
1.3 应用架构变迁图
2.Spring Cloud 简介
- Spring Cloud 是 Spring 旗下的一个*项目。
- Spring Cloud 是一个服务治理平台，提供了一些服务框架。包含了：服务注册与发现、配置中心、消息中心 、负载均衡、数据监控等等。
- Spring Cloud 是一系列框架的有序集合。它利用 Spring Boot 的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用 Spring Boot 的开发风格做到一键启动和部署。Spring Cloud 并没有重复制造*，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过 Spring Boot 风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。
- Spring Cloud 是一个微服务框架，相比 RPC/SOA 框架而言，Spring Cloud 提供的全套的分布式系统解决方案。
- Spring Cloud 对 Netflix 的多个微服务基础框架开源组件进行了封装，同时又实现了和云端平台以及和 Spring Boot 开发框架的集成。
- Spring Cloud 为微服务架构开发涉及的配置管理，服务治理，熔断机制，智能路由，微代理，控制总线，一次性 token，全局一致性锁，leader 选举，分布式 session，集群状态管理等操作提供了一种简单的开发方式。
- Spring Cloud 为开发者提供了快速构建分布式系统的工具，开发者可以快速的启动服务或构建应用、同时能够快速和云平台资源进行对接。
2.1 Netflix 简介
- Netflix(Nasdaq NFLX) 成立于 1997 年，是一家在线影片租赁提供商，主要提供 Netflix 超大数量的 DVD 并免费递送，总部位于美国加利福尼亚州洛斯盖图
- Netflix 经过几年的开源实践，推出最新开源改革计划，打造了全新的 Netflix 开源门户，并且会继续开源更多好项目，增加 Netflix 项目开源透明度。
- 互联网流媒体播放商 Netflix 在几年前就开始创建自己的开源门户 Netflix Open Source (别名 NetflixOSS，http://netflix.github.io/) 了，他们并不知道这会如何发展；也不知道开源贡献者是否会使用，改进或者是忽略；更没想到的是就这样拥有了公司的社区，开发者会给予反馈，一些中间供应商会把这些开源软件集成到他们的解决方案中。
- 到了今天，Netflix 拥有上百个开源软件，从基础设施平台到大数据工具，再到自动化部署软件。随着时间的发展，OSS 网站也由于越来越多的组件而变得越来越复杂。现在，Netflix 还会继续开源更多的软件。
- Netflix 发布在 Github 中的项目库地址
3.Spring Cloud 框架结构
4.Spring Cloud 和 Dubbo 的对比
- Spring Cloud 和 Dubbo 都是微服务开发框架。不是新的技术就一定是好的技术。Dubbo 优势在于开发简单，效率高。Spring Cloud 优势在于功能全面且可靠性高。
| 对比内容 | Dubbo | Spring Cloud |
|---|---|---|
| 出身 | 阿里系 核心框架是服务化治理 | Spring 社区 核心框架是 Netflix 开源微 服务架构群体 |
| 文档 | 集中，健全，中文 | 较多，内容大部分是英本版 |
| 性能 | Dubbo 的性能大约是 Spring Cloud 的 2~3 倍 | |
| 服务注册中心 | zookeeper | Spring Cloud Netflix Eureka |
| 服务调用方式 | RPC | REST API |
| 服务网关 | 无 | Spring Cloud Netflix Zuul |
| 断路由 | 集群容错 | Spring Cloud Netflix Hystrix |
| 分布式配置 | 无 | Spring Cloud Config |
| 服务跟踪 | 无, monitor | Spring Cloud Sleuth |
| 消息总线 | 无 | Spring Cloud Bus |
| 数据流 | 无 | Spring Cloud Stream |
| 批量任务 | 无 | Spring Cloud Task |
5.Spring Cloud 版本号说明
5.1 常见版本号说明
- 开发中，使用的框架版本，最好是 RELEASE 版本或 Final 版本。
- 常见版本号格式为： x.y.z.stage
- x - 数字格式主版本号，当功能模块有较大更新或者整体架构发生变化时，主版本号会更新。
- y - 数字格式次版本号，次版本表示只是局部的一些变动。
- z - 数字格式修正版本号，一般是 bug 的修复或者是小的变动。
- stage - 希腊字母版本号，也称为阶段版本号。用于标注当前版本的软件处于哪个开发阶段。常用的阶段版本包括：BASE、ALPHA、BATE、RELEASE/FINAL。
- BASE - 设计阶段。只有相应的设计没有具体的功能实现。
- ALPHA - 软件的初级版本。存在较多的 bug。
- BATE - 表示相对 ALPHA 有了很大的进步，消除了严重的 bug，还存在一些潜在的 bug。
- RELEASE/FINAL - 该版本表示最终版，即正式发布版本。
5.2 Spring Cloud 版本号说明
- Spring Cloud 是一个包含若干子框架的框架集合体，是一个完整的微服务框架体系，如果使用场景版本号来进行标记，容易混淆主框架版本和子框架版本标记。所以 Spring Cloud 使用一种全新的版本号来对主框架进行版本标记，而子框架的版本标记大多还是使用常用版本号标记的
- Spring Cloud 版本格式如： 版本号命名.stage
- 版本号命名：Spring Cloud 主框架版本号是使用英国伦敦地铁站名称来进行标记的，并根据地铁站名称的首字母的英文自然升序排列来识别版本的递增。如：Angle、Brixton、Camden、Dalston、Edgware、Finchley 等。后续版本提升会继续根据首字母升序排列。
- stage：阶段版本号。常用的阶段版本包括：BUILD-XXX[SNAPSHOT]、GA、PRE(M1、M2 等)、RC、SR。
- BUILD-XXX[SNAPSHOT] - 开发版本、一般是开发团队内部使用
- GA - 稳定版，内部开发到一定阶段了，各个模块集成后，经过全面测试发现没有问题，可对外发行了。这个时候叫 GA(General Availability)。基本上可以使用了。没有严重的 BUG 问题，但是有未测出的 BUG 隐患。不推荐商业使用
- PRE - 里程碑版，由于 GA 还不属于公开发行版，里面还有些功能不完善或者 bug，于是就有了 milestone（里程碑版）。milestone 版主要修复了一些 bug。一个 GA 后，一般会有多个里程本版。例如 M1 M2 M3…。不推荐商业使用。
- RC - 候选发布版，从 BUILD 后到 GA 在到 M 基本上系统就算定型了，这个时候系统就进入 Release Candidate（候选发布版）。该阶段的软件类似于最终发行前的一个观察期，该期间只对一些发现的等级高的 bug 进行修复。发布 RC1 RC2 等版本。可以考虑 RC 版本。
- SR - 正式发布版，公开正式发布。正式发布版一般也有多个发布，例如 SR1 SR2 SR3 等等，一般是用来修复大 bug 或者优化。最好使用 SR 版本。
- 本次说明过程使用的版本是：Greenwich.SR4。当前版本中内部使用的 SpringBoot 是 2.2.x.RELEASE 版本