微服务基础知识

的的小白

已于 2024-08-20 21:20:50 修改

阅读量745

点赞数 23

文章标签：微服务架构云原生

于 2024-08-20 20:22:46 首次发布

本文链接：https://blog.csdn.net/m0_64481525/article/details/141366251

版权

2.3.1 SpringCloud中的核⼼组件

一、微服务基础知识

1.1 系统架构的演变

随着互联⽹的发展，⽹站应⽤的规模不断扩⼤，常规的应⽤架构已⽆法应对，分布式服务架构以及微服务架构势在必⾏，必需⼀个治理系统确保架构有条不紊的演进。

1.1.1 单体应⽤架构

Web应⽤程序发展的早期，⼤部分web⼯程(包含前端⻚⾯,web层代码,service层代码,dao层代码)是将所有的功能模块,打包到⼀起并放在⼀个web容器中运⾏。

⽐如搭建⼀个电商系统：客户下订单，商品展示，⽤户管理。这种将所有功能都部署在⼀个web容器中运⾏的系统就叫做单体架构。

优点：

所有的功能集成在⼀个项⽬⼯程中
项⽬架构简单，前期开发成本低，周期短，⼩型项⽬的⾸选。

缺点：

全部功能集成在⼀个⼯程中，对于⼤型项⽬不易开发、扩展及维护。
系统性能扩展只能通过扩展集群结点，成本⾼、有瓶颈。
技术栈受限。

1.1.2 垂直应⽤架构

当访问量逐渐增⼤，单⼀应⽤增加机器带来的加速度越来越⼩，将应⽤拆成互不相⼲的⼏个应⽤，以提升效率。

优点：

项⽬架构简单，前期开发成本低，周期短，⼩型项⽬的⾸选。
通过垂直拆分，原来的单体项⽬不⾄于⽆限扩⼤
不同的项⽬可采⽤不同的技术。

缺点：

全部功能集成在⼀个⼯程中，对于⼤型项⽬不易开发、扩展及维护。
系统性能扩展只能通过扩展集群结点，成本⾼、有瓶颈。

1.1.3 分布式SOA架构

1.1.3.1 什么是SOA

SOA 全称为 Service-Oriented Architecture，即⾯向服务的架构。它可以根据需求通过⽹络对松散耦合的粗粒度应⽤组件(服务)进⾏分布式部署、组合和使⽤。⼀个服务通常以独⽴的形式存在于操作系统进程中。

站在功能的⻆度，把业务逻辑抽象成可复⽤、可组装的服务，通过服务的编排实现业务的快速再⽣，⽬的：把原先固有的业务功能转变为通⽤的业务服务，实现业务逻辑的快速复⽤。

1.1.3.2 SOA架构

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

优点：

抽取公共的功能为服务,提⾼开发效率
对不同的服务进⾏集群化部署解决系统压⼒
基于ESB/DUBBO减少系统耦合

缺点：

抽取服务的粒度较⼤
服务提供⽅与调⽤⽅接⼝耦合度较⾼

1.1.4 微服务架构

优点：

通过服务的原⼦化拆分，以及微服务的独⽴打包、部署和升级，⼩团队的交付周期将缩短，运维成本也将⼤幅度下降
微服务遵循单⼀原则。微服务之间采⽤Restful等轻量协议传输。

缺点：

微服务过多，服务治理成本⾼，不利于系统维护。
分布式系统开发的技术成本⾼（容错、分布式事务等）。

1.1.5 SOA与微服务的关系

SOA（ Service Oriented Architecture ）“⾯向服务的架构”:他是⼀种设计⽅法，其中包含多个服务，服务之间通过相互依赖最终提供⼀系列的功能。⼀个服务通常以独⽴的形式存在与操作系统进程中。各个服务之间通过⽹络调⽤。

微服务架构:其实和SOA 架构类似,微服务是在SOA上做的升华，微服务架构强调的⼀个重点是“业务需要彻底的组件化和服务化” ，原有的单个业务系统会拆分为多个可以独⽴开发、设计、运⾏的⼩应⽤。这些⼩应⽤之间通过服务完成交互和集成。

总结：单体应⽤架构--->垂直应⽤架构--->分布式架构--->SOA架构--->微服务架构，当然还有悄然兴起的Service Mesh(服务⽹格化)。

1.2 分布式核心知识

1.2.1 分布式中的远程调⽤

在微服务架构中，通常存在多个服务之间的远程调⽤的需求。远程调⽤通常包含两个部分：序列化和通信协议。常⻅的序列化协议包括json、xml、 hession、 protobuf、thrift、text、 bytes等，⽬前主流的远程调⽤技术有基于HTTP的RESTful接⼝以及基于TCP的RPC协议。

（ 1 ）RESTful接口

REST，即Representational State Transfer的缩写，如果⼀个架构符合REST原则，就称它为RESTful架构。

资源（Resources ）

所谓"资源" ，就是⽹络上的⼀个实体，或者说是⽹络上的⼀个具体信息。它可以是⼀段⽂本、⼀张图⽚、⼀⾸歌曲、⼀种服务，总之就是⼀个具体的实在。你可以⽤⼀个URI（统⼀资源定位符）指向它，每种资源对应⼀个特定的URI。要获取这个资源，访问它的URI就可以，因此URI就成了每⼀个资源的地址或独⼀⽆⼆的识别符。 REST的名称"表现层状态转化"中，省略了主语。 "表现层"其实指的是"资源"（ Resources）的 "表现层"。

表现层（Representation）

"资源"是⼀种信息实体，它可以有多种外在表现形式。我们把"资源"具体呈现出来的形式，叫做它的"表现层"（Representation）。⽐如，⽂本可以⽤txt格式表现，也可以⽤HTML格式、XML格式、JSON格式表现，甚⾄可以采⽤⼆进制格式；图⽚可以⽤JPG格式表现，也可以⽤PNG格式表现。 URI只代表资源的实体，不代表它的形式。严格地说，有些⽹址最后的".html"后缀名是不必要的，因为这个后缀名表示格式，属于"表现层"范畴，⽽URI应该只代表"资源"的位置。

状态转化（State Transfer ）

访问⼀个⽹站，就代表了客户端和服务器的⼀个互动过程。在这个过程中，势必涉及到数据和状态的变化。互联⽹通信协议HTTP协议，是⼀个⽆状态协议。这意味着，所有的状态都保存在服务器端。因此，如果客户端想要操作服务器，必须通过某种⼿段，让服务器端发⽣"状态转化"（ State Transfer ）。客户端⽤到的⼿段，只能是HTTP协议。具体来说，就是HTTP协议⾥⾯，四个表示操作⽅式的动词： GET、 POST、 PUT、 DELETE。它们分别对应四种基本操作：GET⽤来获取资源，POST⽤来新建资源（也可以⽤于更新资源），PUT⽤来更新资源，DELETE⽤来删除资源。

综合上⾯的解释，我们总结⼀下什么是RESTful架构：

每⼀个URI代表⼀种资源；
客户端和服务器之间，传递这种资源的某种表现层；
客户端通过四个HTTP动词，对服务器端资源进⾏操作，实现"表现层状态转化"。

（ 2 ）RPC协议

RPC（ Remote Procedure Call ）⼀种进程间通信⽅式。允许像调⽤本地服务⼀样调⽤远程服务。 RPC框架的主要⽬标就是让远程服务调⽤更简单、透明。 RPC框架负责屏蔽底层的传输⽅式（TCP或者 UDP）、序列化⽅式（XML/JSON/⼆进制）和通信细节。开发⼈员在使⽤的时候只需要了解谁在什么位置提供了什么样的远程服务接⼝即可，并不需要关⼼底层通信细节和调⽤过程。

（ 3）区别与联系

⽐较项	RESTful	RPC
通讯协议	HTTP	⼀般使⽤TCP
性能	略低	较⾼
灵活度	⾼	低
应⽤	微服务架构	SOA架构

1、 HTTP相对更规范，更标准，更通⽤，⽆论哪种语⾔都⽀持http协议。如果你是对外开放API，例如开放平台，外部的编程语⾔多种多样，你⽆法拒绝对每种语⾔的⽀持，现在开源中间件，基本最先⽀持的⼏个协议都包含RESTful。

2、 RPC 框架作为架构微服务化的基础组件，它能⼤⼤降低架构微服务化的成本，提⾼调⽤⽅与服务提供⽅的研发效率，屏蔽跨进程调⽤函数（服务）的各类复杂细节。让调⽤⽅感觉就像调⽤本地函数⼀样调⽤远端函数、让服务提供⽅感觉就像实现⼀个本地函数⼀样来实现服务。

1.2.2 分布式中的CAP原理

现如今，对于多数⼤型互联⽹应⽤，分布式系统（distributed system）正变得越来越重要。分布式系统的最⼤难点，就是各个节点的状态如何同步。 CAP 定理是这⽅⾯的基本定理，也是理解分布式系统的起点。 CAP理论由 Eric Brewer 在ACM研讨会上提出，⽽后CAP被奉为分布式领域的重要理论。分布式系统的 CAP理论，⾸先把分布式系统中的三个特性进⾏了如下归纳：

Consistency（⼀致性）：数据⼀致更新，所有数据的变化都是同步的
Availability（可⽤性）：在集群中⼀部分节点故障后，集群整体是否还能响应客户端的读写请求
Partition tolerance（分区容忍性）：某个节点的故障，并不影响整个系统的运⾏

通过学习CAP理论，我们得知任何分布式系统只可同时满⾜⼆点，没法三者兼顾，既然⼀个分布式系统⽆法同时满⾜⼀致性、可⽤性、分区容错性三个特点，所以我们就需要抛弃⼀样：

选择	说明
CA	放弃分区容错性，加强⼀致性和可⽤性，其实就是传统的关系型数据库的选择
AP	放弃⼀致性（这⾥说的⼀致性是强⼀致性），追求分区容错性和可⽤性，这是很多分布式系统设计时的选择，例如很多NoSQL系统就是如此
CP	放弃可⽤性，追求⼀致性和分区容错性，基本不会选择，⽹络问题会直接让整个系统不可⽤

1.3 常⻅微服务框架

1.3.1 SpringCloud

Spring Cloud是⼀系列框架的有序集合。它利⽤Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中⼼、消息总线、负载均衡、断路器、数据监控等，都可以⽤ Spring Boot的开发⻛格做到⼀键启动和部署。 Spring Cloud并没有重复制造轮⼦，它只是将⽬前各家公司开发的⽐较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot⻛格进⾏再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了⼀套简单易懂、易部署和易维护的分布式系统开发⼯具包。

1.3.2 ServiceComb

Apache ServiceComb是业界第⼀个Apache微服务顶级项⽬，是⼀个开源微服务解决⽅案,致⼒于帮助企业、⽤户和开发者将企业应⽤轻松微服务化上云，并实现对微服务应⽤的⾼效运维管理。其提供⼀站式开源微服务解决⽅案，融合SDK框架级、 0侵⼊ServiceMesh场景并⽀持多语⾔。

1.3.3 ZeroC ICE

ZeroC IceGrid是ZeroC公司的杰作，继承了CORBA的⾎统，是新⼀代的⾯向对象的分布式系统中间件。作为⼀种微服务架构，它基于RPC框架发展⽽来，具有良好的性能与分布式能⼒。

2 SpringCloud概述

2.1 微服务中的相关概念

2.1.1 服务注册与发现

服务注册：服务实例将⾃身服务信息注册到注册中⼼。这部分服务信息包括服务所在主机IP和提供服务的Port ，以及暴露服务⾃身状态以及访问协议等信息。

服务实例的信息，通过这些信息去请求它们提供的服务。

2.1.2 负载均衡

负载均衡是⾼可⽤⽹络基础架构的关键组件，通常⽤于将⼯作负载分布到多个服务器来提⾼⽹站、应⽤、数据库或其他服务的性能和可靠性。

2.1.3 熔断

熔断这⼀概念来源于电⼦⼯程中的断路器（Circuit Breaker）。在互联⽹系统中，当下游服务因访问压⼒过⼤⽽响应变慢或失败，上游服务为了保护系统整体的可⽤性，可以暂时切断对下游服务的调⽤。这种牺牲局部，保全整体的措施就叫做熔断。

2.1.4 链路追踪

随着微服务架构的流⾏，服务按照不同的维度进⾏拆分，⼀次请求往往需要涉及到多个服务。互联⽹应⽤构建在不同的软件模块集上，这些软件模块，有可能是由不同的团队开发、可能使⽤不同的编程语⾔来实现、有可能布在了⼏千台服务器，横跨多个不同的数据中⼼。因此，就需要对⼀次请求涉及的多个服务链路进⾏⽇志记录，性能监控即链路追踪

2.1.5 API⽹关

随着微服务的不断增多，不同的微服务⼀般会有不同的⽹络地址，⽽外部客户端可能需要调⽤多个服务的接⼝才能完成⼀个业务需求，如果让客户端直接与各个微服务通信可能出现：

客户端需要调⽤不同的url地址，增加难度
再⼀定的场景下，存在跨域请求的问题
每个微服务都需要进⾏单独的身份认证

针对这些问题，API⽹关顺势⽽⽣。

API⽹关直⾯意思是将所有API调⽤统⼀接⼊到API⽹关层，由⽹关层统⼀接⼊和输出。⼀个⽹关的基本功能有：统⼀接⼊、安全防护、协议适配、流量管控、⻓短链接⽀持、容错能⼒。有了⽹关之后，各个 API服务提供团队可以专注于⾃⼰的的业务逻辑处理，⽽API⽹关更专注于安全、流量、路由等问题。

2.2 SpringCloud的介绍

Spring Cloud是⼀系列框架的有序集合。它利⽤Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中⼼、消息总线、负载均衡、断路器、数据监控等，都可以⽤ Spring Boot的开发⻛格做到⼀键启动和部署。 Spring Cloud并没有重复制造轮⼦，它只是将⽬前各家公司开发的⽐较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot⻛格进⾏再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了⼀套简单易懂、易部署和易维护的分布式系统开发⼯具包。

2.3 SpringCloud的架构

2.3.1 SpringCloud中的核⼼组件

Spring Cloud的本质是在 Spring Boot 的基础上，增加了⼀堆微服务相关的规范，并对应⽤上下⽂进⾏了功能增强。既然 Spring Cloud 是规范，那么就需要去实现，⽬前Spring Cloud 规范已有 Spring官⽅，Spring Cloud Netflix ，Spring Cloud Alibaba等实现。通过组件化的⽅式，Spring Cloud将这些实现整合到⼀起构成全家桶式的微服务技术栈。

Spring Cloud Netflix组件