SpingCloud踩坑记（一）SpringCloud是何物？

本文链接：https://blog.csdn.net/HuiShouDeZaiLai/article/details/103885985

由来

单体架构及存在不足

在软件设计中，经常提及和使用经典的3层模型，即表示层、业务逻辑层和数据访问层。

虽然在软件设计中划分了经典的3层模型，但是对业务场景没有划分。一个典型的单体应用就是将所有的业务场景的表示层、业务逻辑层和数据访问层放在一个工程中，最终经过编译、打包，部署在一台服务器上。例如典型的J2EE工程，它是将表示层的JSP、业务逻辑层的Service、Controller和数据访问层的Dao，打成war包，部署在Tomcat、Jetty或者其他Servlet容器中运行。

在一个小型应用的初始阶段，访问量较小，应用只需要一台服务器就能够部署所有的资源，例如将应用程序、数据库、文件资源、缓存资源等部署在同一台服务器上。如下图所示

2019121401

这样的做法在前期应用业务比较简单，并发量不大时并不会有多大问题。但是随着业务越来越复杂，用户量越来越多时，对服务的性能也要求越高。这时很多公司常规的做法是将单体应用进行集群部署，并增加负载均衡服务器（例如Nginx 等〉。另外，还需要增加集群部署的缓存服务器和文件服务器，并将数据库读写分离，以应对用户量的增加而带来的高并发访问量。如下图所示

2019121402

这种架构虽然有一定的处理并发能力和应对一定复杂的业务需求，改善了系统的性能，但是还是会存在以下几点不足：

复杂高。业务复杂时，代码量较大且可读性和可维护性很差，代码难以被修改和重构。
可持续交付能力差。构建和部署耗时较长，并出现BUG时难于定位，排查困难。并且代码变更时无法预知影响范围需要全量测试，风险较大并耗时较长。
系统伸缩性较差。单体系统只能整体横向扩展，无法分模块垂直扩展。IO密集型模块和CPU密集型模块无法独立升级和扩展。
可靠性差。一个BUG可能导致整个服务无法使用。
阻碍技术创新。受技术栈限制，团队成员必须使用同一框架和语言，升级和变革技术框架变得困难。

微服务的诞生

微服务的诞生并非偶然，它是在互联网高速发展、技术变化日新月异以及传统架构无法适应快速变化等多重因素共同推动下诞生的产物。

如果还按照以前传统开发模式，开发一个大而全的系统已经很难满足市场对技术的需求。这时候分而治之的思想被提了出来，于是我们从单体架构发展到分布式架构，又从分布式架构发展到 SOA 架构，服务不断地被拆分和分解，粒度也越来越小，直到微服务架构的诞生。

当服务越来越小的时候，必然会面临其它很多问题，比如服务之间的调用更加频繁，服务的偶尔不可用变成常态。面对这些挑战，我们必须需要重新来构建一套技术来支持微服务架构。这套技术需要具备高可用、请求重试、熔断、容错、调用过程可监控等特性，当解决了这些问题后，微服务应运而生。

什么是微服务

2014 年 3 月，Martin Fowler 写的一篇文章《Microservices》以更加通俗易懂的形式为大家定义了什么是微服务架构。
原文内容如下

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这样轻量的机制来相互通信。这些服务围绕业务功能进行构建，并能通过全自动的部署机制来进行独立部署。这些微服务可以使用不同的语言来编写，并且可以使用不同的数据存储技术。对这些微服务我们仅做最低限度的集中管理。

从这句话来理解，可以总结微服务有以下特点。

按小型服务来开发独立的应用系统（根据业务或者模块进行代码分离成独立应用）
服务之间采用HTTP资源API方式进行相互通讯
服务通过自动化部署机制独立部署（通过使用Docker部署+Jenkins构建+kubernetes管理Docker）
可以使用不同编程语言
可用使用不同的存储技术
服务低限度的集中制管理（使用Zookeeper、Consul、Eureka等方式）
分布式系统（可部署同个服务器上也可部署在不同服务器，不同机房，不同地区。通过网络协议来交换）

微服务的优缺点

相对于单体服务来说，微服务具备很多优势，主要体现在以下方面

复杂度可控：在将应用分解的同时，规避了原本复杂度无止境的积累。每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。由于体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率；
独立部署：由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。当某个微服务发生变更时，无需编译、部署整个应用。由微服务组成的应用相当于具备一系列可并行的发布流程，使得发布更加高效，同时降低对生产环境所造成的风险，最终缩短应用交付周期；
技术选型灵活：微服务架构下，技术选型是去中心化的。每个团队可以根据自身服务的需求和行业发展的现状，自由选择最适合的技术栈。由于每个微服务相对简单，故需要对技术栈进行升级时所面临的风险就较低，甚至完全重构一个微服务也是可行的；
容错：当某一组件发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。在微服务架构下，故障会被隔离在单个服务中。若设计良好，其他服务可通过重试、平稳退化等机制实现应用层面的容错；
扩展：单块架构应用也可以实现横向扩展，就是将整个应用完整复制到不同的节点。当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独立进行扩展。

凡事都有两面性，微服务主要的不足体现在如下方面

微服务的复杂度（学习成本提高，服务之间可能存在相互依赖）
分布式事务（不同服务之间调用保证数据调用一致）
服务的划分（服务拆分困难，拆分的边界难以确定）
服务的部署（服务变多部署难度增加）

SpringCloud

介绍

Spring Cloud 诞生时，正处于微服务概念在慢慢酝酿中。Spring Cloud 的研发融合了微服务架构的理念，实现了在 Java 领域内微服务架构落地的技术支撑，结合着 Spring Boot 相关特性，提供了基础组件一键式启动和部署能力，极大地简化了微服务架构的技术落地。

Spring Cloud为开发人员提供了工具，可以快速构建分布式系统中的一些常见模式（例如，配置管理，服务发现，断路器，智能路由，微代理，控制总线，一次性令牌，全局锁，领导选举，分布式会话，群集状态）。分布式系统的协调导致样板式样，并且使用Spring Cloud开发人员可以快速站起来实现这些样板的服务和应用程序。它们可以在任何分布式环境中正常工作，包括开发人员自己的笔记本电脑，裸机数据中心以及Cloud Foundry等托管平台。

特征

Spring Cloud致力于为典型的用例和扩展机制提供良好的开箱即用体验，以涵盖其他用例。

分布式/版本化配置
服务注册和发现
路由
服务到服务的通话
负载均衡
断路器
全局锁
领导选举和集群状态
分布式消息传递

常用组件

服务注册和发现组件 Eureka

利用 Eureka 组件可以很轻松地实现服务的注册和发现的功能。 Eureka 组件提供了服务的健
康监测，以及界面友好的 UI 。通过 Eureka 组件提供的 UI, Eureka 组件可以让开发人员随时了
解服务单元的运行情况。另外 Spring Cloud 也支持 Consul Zookeeper ，用于注册和发现服务

熔断组件 Hystrix

Hystrix 熔断组件，它除了一些些基本的熔断器功能外，还能够实现服务降级、服
务限流的功能。另外 Hystrix 提供了熔断器的健康监测，以及熔断器健康数据的 API 口。
Hystrix Dashboard 组件提供了单个服务熔断器的健康状态数据的界面展示功能 Hystrix
Turbine 组件提供了多个服务的熔断器的健康状态数据的界面展示功能

负载均衡组件 Ribbon

Ribbon 是个负载均衡组件，它通常和 Eureka Zuul RestTemplate Feign 配合使用。
Ribbon与Zuul配合，很容易做到负载均衡，将请求根据负载均衡策略分配到不同的服务,
Ribbon、RestTemplate、Feign配合，在消费服务时能够做到负载均衡。

路由网关 Zuul

路由网关 Zuul 有智能路由和过滤的功能。内部服务的 API 接口通过 Zuul 网关统对外暴露，
内部服务的 API 接口不直接暴露，防止了内部服务敏感信息对外暴露。在默认的情况下， Zuul和Ribbon 相结合，能够做到负载均衡智能路由。 Zuul 过滤功能是通过拦截请求来实现的可以
些用户的角色和权限进行判断，起到安全验证的作用同时也可以用于输山实时的请求曰志。

上述的4个组件都来自于 Netflix 公司称为 Spring Cloud Netflix。

Spring Cloud Config

Spring Cloud Config 组件提供了配置文件统管理的功能。 Spring Cloud Config Server
端和 Client Server 端读取本地仓库或者远程仓库的配置文件，所有的 Client Server
取配置信息，从而达到配置文件统管理的目的。通常情况下， Spring Cloud Config Spring
Cloud Bus 互配合刷新指定 Client 或所 Client 配置文件。

Spring Cloud Security

Spring Cloud Security 是对 Spring Security 组件的封装 Spring Cloud Security 向服务单元
提供了用户验证和权限认证。一般来说，单独在微服务系统中使用 Spring Cloud Security 是很
少见的，般它会配合 Spring Security 0Auth2 组件起使用，通过搭建授权服务，验证 Token
或者 JWT 这种形式对整个微服务系统进行安全验证。