【微服务架构】Spring Cloud入门概念讲解

一、单体架构VS微服务架构

1.1 单体应用

单体架构的优点

单体应用的缺点

1.2 微服务“定义”

微服务的特性

微服务的缺点

微服务的适用场景

二、微服务常见概念与核心模块

三、Spring Cloud 工作流程

一、单体架构VS微服务架构

1.1 单体应用

一个归档包（如war包）包含所有功能的应用程序通常称为单体应用，而架构单体应用的方法论（指采用单体应用架构的一种设计和开发理念），就是单体应用架构。

单体应用架构图：

单体架构的优点

架构简单：如图所示...
开发、测试、部署方便：将项目的所有模块结合在一起导成一个war或者jar包，再进行部署即可。

单体应用的缺点

复杂性高： 如果我的项目高达50个模块，而代码量又高。在后续的更新迭代中如果要修复一些bug或者增添功能可能会出现不必要的麻烦，还要考虑是否会影响之前写的代码
部署慢，频率低： 我们一般项目的启动就要5分钟，所以部署慢，从而导致频率低。应为我们应用很大，往往只能做全量的部署，而全量的部署所有修改代码都会更新掉，这样上线的风险就会很高，一旦哪个功能出现了问题就可能要回归所有的代码，最终导致项目部署的频率低。（一般隔一、两哥月才部署一次😥）
扩展能力受限： 如图，比如这个用户模块如果它是一个cpu密集的模块，我的项目服务器遇到了瓶颈，那我还能把这个项目换个更好的服务器进行部署。同理，比如这个内容模块是一个io密集的模块，我需要更大的内存，那我就要把这个项目放到更大内存的服务器，我无法对单个模块作为扩展。
阻碍技术创新： 比如目前这个项目用到的技术栈是spring mvc，如果我要用到更的web框架（web flask）那简直就是一个灾难，那我改掉整个项目的代码（所有的模块都在一块）

总结：单体架构对一些简单的项目架构是比较适行的，但面对一些比较庞大的项目当单体架构的缺点就比较明显，这时候就需要根据项目业务流程复杂难度合理构建项目。

1.2 微服务“定义”

由于单体应用的各种缺点，在2014年的时候出现了一个大佬Martin Fowler（马丁·福勒）提出的微服务概念，从此微服务走向的世界的顶流。

截止到目前微服务并没有一个完全的定义，可能大家理解的微服务都不完全一样，下面是我对微服务的理解：

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

微服务的特性

每个微服务可独立运行在自己的进程里： 这意味着每个服务都有自己的Tomcat
一系列独立运行的微服务共同构建起整个系统： 每个微服务都能够独立的运行
每个服务为独立的业务开发，一个微服务只关注某个特定的功能，例如订单管理、用户管理等：微服务被认可最重要的点⭐
可使用不同的语言与数据存储技术(契合项目情况和团队实力) ;
微服务之间通过轻量的通信机制进行通信，例如通过RESTAPI进行调用;
全自动的部署机制： 这个自动化的前提是你能够把自动化的东西都自动化掉，比如自动化的构建、测试、部署...

微服务的缺点

运维要求高： 在单体应用程序中我们只要运营一个jar包，而微服务需要运行若干个应用，所以运维的成本要高。
分布式固有的复杂性： 微服务的本质其实就是一个分布式应用，而分布式的应用要考虑就很多人，比如网络延迟、分布式事务、锁等等...
重复劳动： 举一个例子：在serviceA中写一个功能，而serviceB同样也有这样的功能。这时聪明的你就想到了，可以将该功能导成jar包供这两个模块引用。可要考虑的是微服务是支持不同语言技术开发的，如果serviceA用的是Java，而sericeB用的是php，java的功能能用在php里面吗？所以还是会存在一些重复劳动的。

微服务的适用场景

大型、复杂的项目： 如果你的应用用单体架构就能搞定，那是不需要微服务的，杀鸡无需宰牛刀的。
有快速迭代的需求： 如果应用三五个月才需要上线发布一次，需求的变更也不是很多，那就没必要用微服务，用单体架构就可行。
访问压力大： 微服务有一个很大的好处就是去中心化，微服务把业务和数据都拆开了，这样更适用于一些数据访问量大的项目，数据的吞吐会好很多。

二、微服务常见概念与核心模块

Spring Cloud 是一个基于 Spring Boot 实现的云应用开发工具，它提供了一套微服务解决方案，包括服务治理、配置管理、消息总线、负载均衡、断路器、数据监控等功能。下面是一些 Spring Cloud 的核心模块：

服务治理（Eureka）： Eureka 是 Netflix 开源的一款提供服务注册和发现的产品，它提供了完整的 Service Registry 和 Service Discovery 实现。服务注册中心是微服务架构中的重要组成部分，主要用于实现微服务的自动化注册和发现。

基于REST（一种软件架构风格，一种针对网络应用的设计和开发方式，可以降低开发的复杂性，提高系统的可伸缩性）的服务。主要以AWS云服务为支撑，提供服务发现并实现负载均衡和故障转移。

· 管理各种服务功能包括服务的注册、发现、熔断、负载、降级等，比如dubbo admin后台的各种功能。有了服务中心后，任何一个服务都不能直接去相互调用，必须通过注册中心来调用。

· 服务端提供服务注册，当客户端服务启动的时候，会主动向服务端进行注册，服务端会存储所有已经注册服务节点信息。服务端会管理这些节点信息，并且会将异常的节点移除服务列表。
负载均衡（Ribbon）： Ribbon 是 Netflix 发布的云中间层服务调用工具，它提供了一套完整的配置项，包括连接超时、重试、重试算法等。Ribbon 已经默认整合了服务发现组件 Eureka，为我们的服务提供了客户端负载均衡的功能。
声明式服务调用（Feign）： Feign 是一个声明式的 Web Service 客户端，它使得编写 Web Service 客户端变得更简单。在Spring体系中，只要是通过调用接口来进行某个操作的，应该都是使用了动态代理技术，比如MyBatis中通过接口对应到对应的XML中的SQL。

在Spring解析的时候，核心有2个步骤：

· 通过接口来动态注册Bean

· 对接口方法进行动态代理，比如Feign就是解析@GetMapping 这类注解将其转为对应的Http Get请求。
配置管理（Spring Cloud Config）： Spring Cloud Config 提供了服务器端和客户端的支持，用于外部化配置在分布式系统中的实现。配置服务器存储实际的配置内容，而客户端则负责从服务器获取并使用配置。

引入spring cloud config后，我们的外部配置文件就可以集中放置在一个git仓库里，再新建一个config server，用来管理所有的配置文件，维护的时候需要更改配置时，只需要在本地更改后，推送到远程仓库，所有的服务实例都可以通过config server来获取配置文件，这时每个服务实例就相当于配置服务的客户端config client,为了保证系统的稳定，配置服务端config server可以进行集群部署。
断路器（Hystrix）： 在微服务架构中，根据业务来拆分成一个个的服务，服务与服务之间可以相互调用（RPC），在Spring Cloud可以用RestTemplate+Ribbon和Feign来调用。为了保证其高可用，单个服务通常会集群部署。由于网络原因或者自身的原因，服务并不能保证100%可用，如果单个服务出现问题，调用这个服务就会出现线程阻塞，此时若有大量的请求涌入，Servlet容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。Netflix开源了Hystrix组件，实现了断路器模式，SpringCloud对这一组件进行了整合。
服务网关（Zuul）： Zuul 是 Netflix 提供的一个基于 JVM 路由和服务端负载均衡器，主要用于动态路由、监控、弹性和安全性。

zuul的核心是一系列的filters, 其作用可以类比Servlet框架Filter。

Zuul的主要功能是路由和过滤器。是各种服务的统一入口，同时还会用来提供监控、授权、安全、调度等等；可以通过扩展ZuulFilter，在执行方法之前，做各种检查工作。