【SpringCloud系列】Spring Cloud - 简介

Spring Cloud - 简介

一、前言

1.1 、微服务出现前的单体应用架构

一个归档包（可以是JAR、WAR、EAR或其它归档格式）包含所有功能的应用程序，通常称为单体应用。
而架构单体应用的方法论，就是单体应用架构。单体应用是将所有功能模块放在一个单一进程中，并且通过在不同的服务器上面复制这个单体进行扩展。

1.2、单体应用架构的优缺点

• 优点

  • 便于共享：单个归档文件包含所有功能，便于在团队之间以及不同的部署阶段之间共享。
  • 易于测试：单体应用一旦部署，所有的服务或特性就都可以使用了，这简化了测试过程，因为没有额外的依赖，每项测试都可以在部署完成后立刻开始。
  • 易于部署：只需将单个归档文件复制到单个目录下。

• 缺点

  • 复杂性高：由于是单个归档文件，所以整个项目文件包含的模块非常多，导致模块的边界模糊、依赖关系不清晰、代码的质量参差不齐，混乱的堆在一起，使得整个项目非常复杂。以致每次修改代码，都非常小心，可能添加一个简单的功能，或者修改一个Bug都会带来隐藏的缺陷。
  • 技术债务：随着时间的推移、需求的变更和技术人员的更替，会逐渐形成应用程序的技术债务，并且越积越多。
  • 扩展能力受限：单体应用只能作为一个整体进行扩展，无法根据业务模块的需要进行伸缩。
  • 部署频率低：随着代码的增多，构建和部署的时间也会相应增加。每次功能的变更与迭代，都会导致整个应用需要重新部署，使得部署的影响大，风险高，从而使得单体应用的上线部署频率下降。
  • 可靠性差：如果其中某个功能出现死循环、OOM等，都会造成整个应用崩溃。
  • 阻碍技术创新：对于单体应用来说，技术是在开发之前经过慎重评估后选定的，每个团队成员都必须使用相同的开发语言、持久化存储及消息系统。

1.3、微服务

2014年Martin Fowler（马丁福勒）提出微服务架构设计理念，全文可见自博客链接。其中有个段落：

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

简单翻译就是：微服务架构风格是将一个单一应用程序开发为一组小型服务的方式，每个服务运行在自己的进程中，服务间通讯采用轻量级通讯机制（通常用HTTP资源API），这些服务围绕业务能力构建并可通过全自动部署机制独立部署。这些服务共用一个小型的集中式管理，服务可用不同的语言开发，使用不同的数据存储技术。

1.4、微服务优点与缺点

• 优点
  • 易于开发和维护：一个微服务只会关注一个特定的业务功能，所以业务清晰、代码量较少。开发和维护单个微服务相对简单。
  • 单个微服务启动较快
  • 局部修改容易部署：单体应用只要有修改，就得重新部署整个应用。微服务解决了这样的问题。一般来说，对某个微服务进行修改，只需要重新部署这个服务即可。
  • 技术栈不受限制：在微服务架构中，可以结合项目业务及团队的特点，合理的选择技术栈。
  • 按需伸缩：可根据需求，实现细粒度的扩展。
• 缺点及挑战
  • 运维要求高：更多的服务意味着要投入更多的运维。
  • 分布式固有的复杂性：使用微服务构建的是分布式系统。对于一个分布式系统，系统容错、网络延迟、分布式事务等都会带来巨大的问题。
  • 接口调整成本高：微服务之间通过接口进行通信。如果修改某一个微服务的API，可能所有用到这个接口的微服务都需要进行调整。
  • 重复劳动：很多服务可能都会有使用到相同的功能，而这些功能并没有达到分解为一个微服务的程度的时候，需要每个服务都去开发这一功能，从而导致代码重复。
  • 可测试性的挑战：在动态环境中，服务间的交互会产生非常微妙的行为，难以进行可视化及全面的测试。

1.5、微服务设计原则

• 单一职责原则：指一个单元只应关注整个系统功能中单独、有界限的一部分。
• 服务自治原则：每个微服务应具备独立的业务能力、依赖与运行环境，应该与其他服务高度解耦。
• 轻量级通信机制：微服务间应该通过轻量级的通信机制进行交互。例如使用REST协议等。
• 微服务粒度：合理划分粒度，而不是一味地把服务做小。

1.6、常见的微服务框架

• SpringCloud（本文主题）
• Dubbo
• gRPC
• …

二、SpringCloud

2.1、版本说明

SpringCloud 是个综合项目，包含了很多子项目，由于子项目也维护着自己的版本，为了避免与子项目的版本混淆，SpringCloud采用不同的版本命名方式，按照伦敦地址站字母顺序进行发行版本。

详细可见SpringCloud版本。

Release Train	Boot Version
Hoxton	2.2.x
Greenwich	2.1.x
Finchley	2.0.x
Edgware	1.5.x
Dalston	1.5.x

Greenwich builds and works with Spring Boot 2.1.x, and is not expected to work with Spring Boot 1.5.x.

The Dalston release train will reach end-of-life in December 2018. Edgware will follow the end-of-life cycle of Spring Boot 1.5.x. The Dalston and Edgware release trains build on Spring Boot 1.5.x, and are not expected to work with Spring Boot 2.0.x.

The Camden release train was marked end-of-life. The Camden release train builds on Spring Boot 1.4.x, but is also tested with 1.5.x.

The Brixton and Angel release trains were marked end-of-life (EOL) in July 2017. The Brixton release train builds on Spring Boot 1.3.x, but is also tested with 1.4.x. The Angel release train builds on Spring Boot 1.2.x, and is incompatible in some areas with Spring Boot 1.3.x. Brixton builds on Spring Boot 1.3.x and is similarly incompatible with 1.2.x. Some libraries and most apps built on Angel will run fine on Brixton, but changes will be required anywhere that the OAuth2 features from spring-cloud-security 1.0.x are used (they were mostly moved to Spring Boot in 1.3.0).

也可以访问https://start.spring.io/actuator/info，查看SpringCloud与SpringBoot的版本兼容性。

不过最近 Spring Cloud 的版本貌似修改了版本命名方式，由YYYY.MINOR.MICRO的形式进行命名。详见Blog。

本文章通篇使用的 Spring Boot 版本为2.3.0.RELEASE, 而 Spring Cloud 版本为Hoxton.SR4。

2.2、SpringCloud组成

• 服务注册与发现：服务提供方将己方调用地址注册到服务注册中心，让服务调用方能够方便地找到自己；服务调用方从服务注册中心找到自己需要调用的服务地址。例如：Eureka、Zookeeper、Consul（官网）、Nacos等。
• 服务调用：常见的服务调用方式有Ribbon、OpenFeign（前身 Feign）。
• 负载均衡：服务提供方一般会以多实例的形式提供服务，负载均衡功能能够让服务调用方连接到合适的服务节点，并且，服务节点选择的过程对服务调用方来说是透明的。
• 服务网关：服务网关是服务调用的唯一入口，可用在该组件中实现用户鉴权、动态路由、灰度发布、负载限流等功能。例如：Zuul、Gateway、Kong（官网）、Soul（国产网关Gitee）等。
• 配置中心：将本地化的配置信息注册到配置中心，实现服务包在开发、测试、生产环境中的无差别性、方便程序包的迁移。例如除了 SpringCloud 自带的 Config 配置中心，还有Alibaba的 Nacos 配置中心，以及携程的 Apollo（Github）等。
• 集成框架：微服务组件都以职责单一的程序包对外提供服务，集成框架以配置的形式将所有微服务组件集成到统一的界面框架下，让用户能够在统一的界面中使用系统。
• 链路监控：记录完成一次请求的先后衔接和调用关系，并将这种串行或并行的调用关系展示出来，从而在系统出错时，能够方便找到出错点。例如：Sleuth，Zikpin、Skywalking（官网）、PinPoint（GitHub）等。
• 支撑平台：系统微服务化后，各个业务模块经过拆分变得更加细化，系统的部署、运维、监控等都比单体应用架构更加复杂，则需要将大部分的工作自动化，比如 Docker、Kubernetes 等。
• 断路器/熔断器：微服务间不可避免地发生相互调用，但是没有一个系统能够保证自身运行的绝对正确，很可能面临依赖服务失效的问题，因此在该情况下，断路器能够对延迟和失败提供强大的容错能力，从而为服务间调用提供保护和控制。例如常见的 Hystrix ，Sentinel 。
• 消息组件：服务间的通讯事件（刷新配置）。例如常见的 Stream 和 Bus 、Nacos。
• 健康检查：Actuator端点。
• …

微信公众号：Java知识集训