7.微服务框架基本知识_微服务架构基础理论知识-优快云博客

本文链接：https://blog.youkuaiyun.com/m0_57901956/article/details/130587744

微服务架构基本知识

1.微服务架构发展历程

企业应用程序通常由三个主要部分构建:1）客户端用户界面(由运行在用户机器上的浏览器中的 HTML 页面和 javascript 组成)、2）数据库(由插入到公共(通常是关系)数据库管理系统中的许多表组成)和3）服务器端应用程序。

服务器端应用程序将处理 HTTP 请求、执行域逻辑、从数据库检索和更新数据，并选择和填充要发送到浏览器的 HTML 视图。

单体架构

一个典型的单体架构应用就是将一个应用中所有的功能都打包在一个 WAR 文件中，并部署在应用服务器（如 Tomcat）中运行，如图所示。

比如你看下图的，服务端应用程序就是是一个整体——一个逻辑可执行文件[2]。对系统的任何更改都涉及构建和部署服务器端应用程序

的新版本。

垂直应用架构

当访问量逐渐增大，单一应用适应能力越来越弱，将应用拆成互不相干的几个应用，以提升效率。（没有太多复用的思想

SOA结构

当垂直应用越来越多，应用之间交互不可避免，将核心业务（核心的公共功能）抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。

微服务

当强调“业务组件化和服务化”时，原有的单个业务系统被拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。

2.微服务

什么是微服务架构？

微服务是一个小的、松耦合的分布式服务，可以把各个分布式的服务看做是不同职责的组件，或者上升为不同的系统来统一管理。相当于把复杂的业务系统分解、分离成不同职责的分布式系统。

更详细的说：

简单地说，微服务是系统架构上的一种设计风格，它的主旨是将一个原本独立的系统拆分成多个小型服务，这些小型服务都在各自独立的进程中运行，服务之间通过基于 HTTP 的 RESTful API（轻量级通信）进行通信协作；

被拆分后的每一个小型服务都围绕着系统中的某一项业务功能进行构建，并且每个服务都是一个独立的项目，可以进行独立的测试、开发和部署等；由于各个独立的服务之间使用的是基于 HTTP 的 JSON 作为数据通信协作的基础，所以这些微服务可以使用不同的语言来开发

微服务 VS SOA

服务粒度：

微服务中服务的粒度更小，每个服务都尽可能实现单一职责（业务），并且通常有自己的数据存储，可以独立部署和测试。

SOA中服务的粒度相对较大，服务通常涉及多个业务功能或跨越多个应用程序。
数据库的使用

微服务中每个服务通常有独立的数据库，可以独立部署、测试。

SOA的服务可能使用共享的数据存储，但也可以使用独立的数据存储。
关注点不同：

微服务架构更注重服务的拆分、独立性和自治性。在微服务架构中，服务的复用通常是通过将不同的、专注于某个业务的小原子服务组合成为复杂的聚合服务在一起来实现（因为服务间是轻量级传输协议，很好组合）。通过各个小服务间的组合来对这些小服务的组件来实现不断复用。

SOA强调服务的集成和共享。可以将不同的服务组合在一起来形成更复杂的服务。SOA架构中的公共服务是被设计为可重用的，并且在整个组织中广泛使用。通过共享公共服务，可以实现复用，并且可以更好地管理和控制服务的变化。

微服务架构的特点

小型化

微服务架构的突出之处就是小型化应用设计、最显著的特点就是应用程序变小了，以小为美。小型化的方式，使每个程序只负责完成一定范围内的业务功能，可以更加专一地做好一件事情。这是我们日常解决复杂问题的常用手法，即“大事化小，小事化无”。
自治化

每个微服务都是一个独立的应用，独立使用数据库，独立部署，独立运行。这种独立性符合高内聚松搞合的设计原则。在微服务开发和维护过程中，每个微服务都是独立自治的，一个服务的更新和迭代不会依赖于其他服务，同时也可以尽可能做到不对其他服务造成影响，或者可以将这种影响降到最小。
扁平化

去中心化的扁平化管理，可以更加自由地发挥每一个微服务的优势。但是这种自由并不是随意的混搭和组合，而是使用智能化的服务治理，让更多的微服务在发挥个性优势的同时，处在一种杂而不乱的有序可控的范围之内。
轻量级

设计微服务小型化的特点，就是轻量级设计方法的最好体现。这种轻量级的设计同样体现在微服务的通信设计之中。微服务之间的常用通方式有两种，一种是使用轻 REST 协议进行API 式的同步通信，另一种是使用轻量的异步消息通信

渐进式设计

一个产品从成型到成熟是要经历多个过程的，这个过程是渐进式设计的。由于微服务小型而独立的特点，使得微服务设计可以以业务驱动的方式进行快速迭代，从而不断修正和调整，使产品趋于成熟。所以，微服务非常适合敏捷开发。

微服务优点

复杂性可控

在将应用分解的同时，规避了原本复杂度无止境的积累。每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。由于体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。
独立部署

由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。当某个微服务发生变更时无需对整个应用编译、部署。由微服务组成的应用相当于具备一系列可并行的发布流程，使得发布更加高效，同时降低对生产环境所造成的风险，最终缩短应用交付周期。
技术选型灵活

微服务架构下，每个团队可以根据自身服务的需求和行业发展的现状，自由选择最适合的技术栈。由于每个微服务相对简单，所以需要对技术栈进行升级时所面临的风险就较低，甚至完全重构一个微服务也是可行的。
容错

当某一组件发生故障时，在单一进程的传统架构下，故障很有可能使应用全局性的不可用。在微服务架构下，故障会被隔离在单个服务中。若设计良好，其他服务可通过重试、平稳退化等机制实现应用层面的容错。
扩展

当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独立进行扩展。

3.CAP原理

微服务说到底还是一种分布式系统。而布式系统的最大难点，就是各个节点的状态如何同步。CAP 定理是这方面的基本定理，也是理解分布式系统的起点。

CAP：分布式系统中的三个特征：

Consistency（一致性）：数据一致更新，所有数据的变化都是同步的；
Availability（可用性）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求 ；
Partition tolerance（分区容忍性）：当节点之间故障（发生网络分区）时，系统仍然能够正常运行，即：每个节点（包括出现分区故障无法和别的节点通信的节点）可以继续向客户端提供服务，而不受其他节点故障或分区的影响。分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。

CAP定理中的可用性A和分区容忍性P都是容错性质，但是它们关注的是不同的方面。

可用性指的是，即使系统的某部分节点出现故障，系统的某些部分仍然可以提供服务，而客户端无需等待或重新发送请求，依然能够获得相应的响应。可用性是衡量系统对外提供服务的能力，通常是通过系统的SLA（服务水平协议）来衡量。

而分区容忍性指的是，当系统发生网络分区故障（即系统中的节点之间无法相互通信）时，系统仍然能够正常工作，各节点仍能对外服务。也就是说，即使系统中的某些部分无法通信，其他部分（也包括出现分区故障的节点）仍然可以正常工作。分区容忍性是衡量系统内部运行的能力，即系统是否能够在节点间发生故障或网络问题时，仍然能够保持运行并提供服务。

总的来说，可用性和分区容忍性都是容错性质，但它们关注的方面不同：可用性关注的是系统对外提供服务的能力，而分区容忍性关注的是系统内部运行的能力（但也不能这么说，只有保持了系统内的分区容忍性，才能对外满足一致性和可用性）

CAP原理

CAP理论：

CAP理论指出任何分布式系统只可同时满足二点，没法三者兼顾。既然一个分布式系统无法同时满足一致性、可用性、分区容错性三个特点，需要抛弃其中一个。

分布式系统大部分选择AP：

在一个分布式系统当中，分区容忍性和可用性是最基本的需求，所以在分布是系统中，最当关注的就是可用性和容忍性，通过补偿的机制寻求数据的一致性。也就是说，选择AP！【但实际上，分布式系统本质上是要P：分区可用性】

不同系统的CAP选择：

CA 放弃分区容错性P，加强一致性和可用性

其实就是传统的关系型数据库的选择
AP 放弃一致性C，追求分区容错性和可用性

这是很多分布式系统设计时的选择，例如很多NoSQL系统就是如此
CP 放弃可用性A，追求一致性和分区容错性

基本不会选择，整个系统不可用，对客户端都无法服务，用都用不了啦，那系统还存在干啥！

总结：

分布式系统，为了在某个节点不可用（与其他节点网络分区了而不可用）的情况下，整个服务（所有节点，包括与其他节点无法通信的出现分区故障的节点）对外（对客户端）还是可用的，这正是满足P（分区容错性）。如果提供的服务不满足P，那么这的系统就不是分布式系统，所以，在分布式系统中，P（分布容错性）总是成立的，那么A（可用性）和C（一致性）就不能同时满足，分布式系统只能是AP或者CP。

4.RestTemplate

1）引入知识：序列化和通信协议

微服务间接口调用的两方面内容。序列化是将对象或数据结构转换为字节流或者字符流的过程，以便在网络上传输或者持久化到本地磁盘等。比如：json、xml、hession、protobuf、thrift、text、bytes等

通信协议是网络通信中的一种约定，可以确保不同的系统能够正确地交换数据。比如：http,etc

2）REST

Representational State Transfer表现层状态转换。 REST是一种软件架构风格，或者说是一种规范，其强调HTTP应当以资源为中心，并且规范了URI的风格；规范了HTTP请求动作（GET/PUT/POST/DELETE/HEAD/OPTIONS）的使用，具有对应的语义。

符合或兼容于这种架构风格（简称为 REST 或 RESTful）的网络服务，允许客户端发出以统一资源标识符url的方式访问和操作网络资源的请求。其核心理念是将每个资源（Resource）都映射到唯一的URL地址，并且对这些资源进行简单的操作（GET、POST、PUT、DELETE等）。

要点：

REST是设计风格而不是标准
资源是由URI来指定。
对资源的操作包括获取、创建、修改和删除，这些操作正好对应HTTP协议提供的GET、POST、PUT和DELETE方法。
通过操作资源的表现形式来操作资源。
资源的表现形式 “资源"是一种信息实体，它可以有多种外在表现形式。把"资源"具体呈现出来的形式比如 json，xml，image,txt 等等叫做它的"表现层/表现形式”。

几个核心概念：

资源（Resource）：

在REST中，资源可以简单的理解为URI（因为所有资源都一一对应一个URL），表示一个网络实体。比如，/users/1/name，对应id=1的用户的属性name。既然资源是URI，就会具有以下特征：名词，代表一个资源；它对应唯一的一个资源，是资源的地址。
表现（Representation）：

是资源呈现出来的形式，比如上述URI返回的HTML或JSON，包括HTTP Header等；
REST是一个无状态的架构模式，因为在任何时候都可以由客户端发出请求到服务端，最终返回自己想要的数据，当前请求不会受到上次请求的影响。也就是说，服务端将内部资源发布REST服务，客户端通过URL来定位这些资源并通过HTTP协议极其方法来访问它们。
例如：

REST操作(状态转移)

一般资源操作只有查询，更新，新增，删除，即CRUD操作，依次对应HTTP协议中的四类请求：GET,PUT,POST,DELETE.

从上图可以看出请求路径相同但请求方式不同，所代表的业务操作也不同，例如，/advertiser/1这个请求，带有GET、PUT、DELETE三种不同的请求方式，对应三种不同的业务操作。
返回内容

对于删除、新增、更新等操作，通常是返回操作是否成功的标识；如果失败，需要返回错误代码和消息，方便客户端做进一步处理。如果是查询操作，通常包含实体或者实体列表。
返回格式

常见的格式包括XML/JSON/HTML。

白话来说（省流版）：

每一个 URI 代表一种资源；
客户端和服务器之间，传递资源的某种表现形式比如 json，xml，image,txt 等等；
客户端通过特定的 HTTP 动词，对服务器端资源进行操作，实现"表现层状态转化"。

4）rest API

RESTful API 经常也被叫做 REST API，它是基于 REST 构建的、关于如何构建 Web 应用程序的API架构规则。**RESTful API 可以让你看到 URL+Http Method 就知道这个 URL 是干什么的，让你看到了 HTTP 状态码（status code）就知道请求结果如何。**如：

GET    /classes：列出所有班级
POST   /classes：新建一个班级

5）RestTemplate

RestTemplate是Spring Framework提供的一个基于RESTful风格的HTTP客户端，用于简化其与RESTful Web服务端的交互。通过RestTemplate，我们可以发送HTTP请求（GET，POST，PUT，DELETE等），并且可以接收HTTP响应。在Spring Boot中，RestTemplate被广泛应用于编写基于RESTful API的微服务应用程序。

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-GF7eiFnG-1683633802651)(C:\Users\wyf\AppData\Roaming\Typora\typora-user-images\image-20230505201140158.png)]$

RestTemplate 主要方法

使用RestTemplate

RestTemplate初始化配置，在服务消费端，创建Cinfig包，并创建RestTemplate类

@Component
public class RestTemplate{    
    @Bean    
     public RestTemplate restTemplate(){        
         return new RestTemplate();    
     }
}

GET请求

客户端通过HTTP请求调用服务端的API，并接收服务端返回的HTTP响应。使用RestTemplate可以实现客户端调用RESTful服务的功能，这符合RESTful服务架构风格的设计原则。

在服务端定义服务提供者，创建Controller类：

@RestController
public class ProviderHelloController {
    @GetMapping("/provider/hello")
    public String sayHello(String name) {
        return "hello " + name + " !";
    }
}

在消费端定义消费者，创建Controller类

@RestController
public class UserHelloController {
   String host;
   int port;
   @Autowired
    RestTemplate restTemplate;
    String url = "http://" + host + ":" + port + "/provider/hello?name={1} ";

这两个例子是一个基于REST风格的Web服务的例子，其中ProviderHelloController是服务端，UserHelloController是客户端。服务端提供了一个名为"/provider/hello"的API，当客户端向该API发送一个GET请求时，服务端将返回一条问候信息，该信息包括客户端提供的参数name。这里的资源是问候信息，它的表现形式可以是字符串，JSON等。

在UserHelloController中，我们使用了RestTemplate，这是Spring提供的用于在客户端进行HTTP访问的模板工具。在构造URL时，我们使用了服务端提供的API地址，并将客户端提供的name作为参数传递给服务端。这样，客户端就可以通过HTTP协议调用服务端提供的API获取相应的资源。

5.微服务技术栈

微服务体系架构

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Ua2ZU7n6-1683633802653)(C:\Users\wyf\AppData\Roaming\Typora\typora-user-images\image-20230506214757348.png)]$

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NzXVugoB-1683633802653)(C:\Users\wyf\AppData\Roaming\Typora\typora-user-images\image-20230506220825769.png)]$

接入层：也可以叫负载均衡层，把外部的流量引入到系统中来。一般负载均衡软件有nginx，lvs，还有各大云服务厂商自己的负载均衡服务。（服务治理）
网关层：内部接口的一些认证、安全、鉴权、过滤、限流等服务，一般处于这一层。这一层把内部的服务接口做一层安全隔离，保护内部服务，同时也可以实现一些其他需求（包括微服务容错），这一层在微服务架构中是很重要的一层。
业务服务层：【1】基础服务：原子级别的服务。根据业务特点又可以分为核心基础服务、公共服务、中间层服务等。【2】聚合服务：把下面细粒度的基础服务再进一步封装、关联（微服务通信），组合成新的服务，供上层调用。这一层可以实现多变的需求。
支撑服务层：（服务的治理）。微服务能够成功实施落地，这一层的配套设施是非常重要。微服务不是把上面的业务服务写完就完事了，在服务治理的过程中需要很多配套设置支持。这一层包括注册服务中心，配置中心，监控报警服务，日志聚合服务，调用链监控几大服务，后台服务涉及的服务有消息队列，定时任务，数据访问等内容。
平台服务层：这一层是实施业务弹性治理的关键。集群的资源调度：扩展和减少。业务量上来时，可以弹性增加资源。在微服务建设过程中，可能会遇到一些突发事件。比如微博明星热点事件，会导致访问量暴增，这就需要能实时增加服务资源应对这种突发情况，热点过后，又要减少资源。镜像管理和发布系统配合使用可以应对出现的这种情况。所以很多团队后面会引入docker+k8s，容器，镜像管理，容器服务编排。此外，基于CI/CD的DevOps也是构建在这一层能力。
基础设施层：这个是最底层的基础设施，网络，存储，硬盘等部分。laas 这个概念就是针对这一层

总的来说,接入层和网关层负责系统边界,平台服务层和基础设施层负责资源,业务服务层和支撑服务层实现业务功能。各层相互配合,才能实现微服务架构。

微服务架构技术栈

服务注册、发现

和单体(Monolithic)架构不同，微服务架构是由一系列职责单一的细粒度服务构成的分布式网状结构，服务之间通过轻量机制进行通信，来组成聚合服务来服务消费者。这时候必然引入一个服务注册发现问题，也就是说服务提供方要注册并通告自己的服务地址，服务的调用方要能发现目标服务，才能实现服务之间的通信。
负载均衡

1）集中式负载均衡

在服务消费者和服务提供者之间有一个独立的LB（负载均衡），LB通常是专门的硬件设备如F5，或者基于软件如LVS，HAproxy等实现

（1）单点问题

（2）所有服务调用流量都经过LB，当服务数量和调用量大的时候，LB容易成为瓶颈。

（3）LB在服务消费方和服务提供方之间增加了一跳(hop)，有一定额外的性能开销。

2）主机独立LB

部署较复杂，环节多，出错调试排查问题不方便。

3）进程内LB

进程内LB方案是一种分布式方案，LB和服务发现能力被分散到每一个服务消费者的进程内部，同时服务消费方和服务提供方之间是直接调用，没有额外开销，性能比较好
服务网关

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-sBn669uq-1683633802654)(C:\Users\wyf\AppData\Roaming\Typora\typora-user-images\image-20230506225821956.png)]$
服务容错

单服务异常导致雪崩：一个服务的故障使得依赖它的服务出现雪崩式的故障。所以需要容错

方案：电路熔断器模式

该模式的原理类似于家里的电路熔断器，如果家里的电路发生短路，熔断器能够主动熔断电路，以避免灾难性损失。在分布式系统中应用电路熔断器模式后，当目标服务慢或者大量超时，调用方能够主动熔断，以防止服务被进一步拖垮；如果情况又好转了，电路又能自动恢复，这就是所谓的弹性容错，系统有自恢复能力。上图是一个典型的具备弹性恢复能力的电路保护器状态图，正常状态下，电路处于关闭状态(Closed)，如果调用持续出错或者超时，电路被打开进入熔断状态(Open)，后续一段时间内的所有调用都会被拒绝(Fail Fast)，一段时间以后，保护器会尝试进入半熔断状态(Half-Open)，允许少量请求进来尝试，如果调用仍然失败，则回到熔断状态，如果调用成功，则回到电路闭合状态。
配置管理