SpringCloud系列微服务与分布式核心知识

Posted 2021-10-02 一宿君

微服务与分布式核心知识

• 1、SOA与微服务的关系
• 2、常见微服务架构
• • 2.1、SpringCloud
  • 2.2、ServiceComb
  • 2.3、ZeroC ICE
• 3、微服务中的相关概念
• • 3.1、服务注册与发现
  • 3.2、负载均衡
  • 3.3、熔断
  • 3.4、链路追踪
  • 3.5、API网关
• 4、分布式核心知识
• • 4.1、分布式中的远程调用
  • • 4.1.1、RESTful接口
    • • 资源（Resources）
      • 表现层（Representation）
      • 状态转化（State Transfer）
    • 4.1.2、RPC协议
    • 4.1.3、RESTful与RPC的区别与联系
  • 4.2、分布式中的CAP原理

1、SOA与微服务的关系

可以先了解下分布式与微服务系列（一）、软件架构的演化过程
SOA（Service Oriented Architecture） 面向服务的架构：它是一种设计方法，其中包含多个服务，服务之间通过相互依赖最终提供一系列的功能。一个服务通常以独立的形式存在于操作系统进程中，各个服务之间通过网络来调用。

**微服务架构：**其实和SOA架构类似，微服务是在SOA架构上做了升华，微服务架构强调的衣蛾重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分成多个可以独立开发的、设计、运行的小应用。这些小应用之间通过服务调用完成交互和集成。

SOA架构与微服务的异同点对比：

功能	SOA	微服务
组件大小	大块业务逻辑	单独任务或小块业务逻辑
耦合	通常松耦合	总是松耦合
公司架构	任何类型	小型、专注于功能交叉团队
管理	着重中央管理	着重分散管理
目标	确保应用能够交互操作	执行新功能、快速拓展开发团队

2、常见微服务架构

2.1、SpringCloud

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

2.2、ServiceComb

Apache ServiceComb是业界第一个Apache微服务顶级项目，是一个开源微服务解决方案，致力于帮助企业、用户和开发者将企业应用轻松微服务化，并实现对微服务应用的高效运维管理。其提供一站式开源微服务解决方案，融合SDK框架级，0侵入ServiceMech场景并支持多语言。

2.3、ZeroC ICE

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

3、微服务中的相关概念

3.1、服务注册与发现

• 服务注册

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

• 服务发现

  服务实例请求注册中心获取所依赖的服务信息。服务实例通过注册中心，获取到注册到其中的服务实例信息，通过这些信息去请求它们提供的服务。

3.2、负载均衡

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

3.3、熔断

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

3.4、链路追踪

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

3.5、API网关

随着微服务的不断增多，不同的微服务一般会有不同的网络地址，而外部的客户端可能需要调动多个服务的接口才能完成一个业务需求，如果让客户端直接与各个微服务进行通信，可能会出现以下情况：

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

针对这些问题，API网关顺势而生。

API网关字面意思是将所有API调用统一接入到API网关层，由网关层统一接入和管理。一个网关的基本功能有：统一接入、安全防护、协议适配、流量管控、长短连接支持、容错能力、有了网关之后，各个API服务提供团队可以专注于自己的业务逻辑处理，而API网关更专注于安全、流量、路由等问题。

4、分布式核心知识

4.1、分布式中的远程调用

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

4.1.1、RESTful接口

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

资源（Resources）

所谓“资源”，就是网络上的一个实体，或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌手、一种服务、一首歌曲、一种服务，总之就是一个具体的实在。你可以用一个URL（统一资源定位符）指向它，每种资源对应一个特定的URL。要获取这个资源，访问它的URL就可以，因此URL就成了每一个资源的地址或独一无二的识别符。REST的名称“表现层状态转化”中，省略了主语。“表现层”其实指的是“资源”（REsources）的“表现层”。

表现层（Representation）

资源是一种信息实体，它可以有多中外在表现形式。我们把"资源"具体呈现出来的形式，叫做它的“表现层”（Representation）。比如，文本可以用txt格式表现，也可以用html格式、XML格式、JSON格式表现，甚至可以采用二进制格式；图片可以用JPG格式表现，也可以用PNG格式表现。URL只代表资源的实体，不代表它的形式。严格地说，有些网址最后的“.html”后缀名是不必要的，因为这个后缀名表示格式。属于“表现层”范畴，而URL应该只代表“资源”的位置。

状态转化（State Transfer）

访问一个网站，就代表客户端和服务器端的一个互动过程。在这个过程中，势必涉及到数据和状态的变化。互联网通信协议HTTP协议，是一个无状态协议。这就意味着，所有的状态都保存再服务器端。因此如果客户端想要操作服务器，必须通过某种手段，让服务器端发生“状态变化”（State Transfer）。客户端用到的手段、只能是HTTP协议。具体来说，就是HTTP协议里面，四个表示操作方式的动词，GET、POST、PUT、DELETE。
它们分别对应四种基本操作：

• GET用来获取资源
• POST用来新建资源（也可以用来更新资源）
• PUT用来更新资源
• DELETE用来删除资源

综上所述，可以将RESTful架构总结为如下几方面：

• 每一个URL代表一种资源
• 客户端和服务器之间，传递这种资源的某种表现层
• 客户端通过四个HTTP动词，对服务器资源进行操作，实现“表现层状态转化”

4.1.2、RPC协议

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

RPC工作原理图（底层基于socket）：

4.1.3、RESTful与RPC的区别与联系

比较项	RESTful	RPC
通讯协议	HTTP	一般使用TCP
性能	略低	较高
灵活度	高	低
应用	微服务架构	SOA架构

总结：

• HTTP相对更规范，更标准，更通用，无论哪种语言都支持http协议。如果你是对外开放的API接口，eg：开放平台，外部的编程语言多种多样，你无法拒绝对每种语言的支持，现在的开源中间件，基本最先支持的几个协议都包含RESTful。
• PRC框架作为架构微服务化的组件，它能大大降低微服务话的成本，提高调用方与服务提供方的研发效率，屏蔽跨进程调用函数（服务）的各类复杂细节。让调用方感觉就像调用本地函数一样调用远程服务端函数、让服务提供方感觉就像实现一个本地函数一样来实现服务。

4.2、分布式中的CAP原理

现如今，对应多数大型互联网应用，分布式系统（distributed system）正变得越来越重要。分布式系统的最大难点，就是各个节点的状态如何同步。CAP定理是这方面的基本定理，也是理解分布式系统的起点。

CAP理论由Eric Brewer在ACM研讨会上提出，而后CAP被奉为分布式领域的重要理论。分布式系统的CAP理论，首先把分布式系统中的三个特性进行了如下归纳：

• Consistency（一致性）：

  所有节点数据一致更新，所有数据的变化都是同步的。

• Availability（可用性）：

  在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。

• Partition tolerance（分区容忍性）：

  某个节点的故障，并不影响整个系统的运行，是否可以将数据存放到多个地方。

通过学习CAP理论，我们得知任何分布式系统只可同时满足两点，没法三者兼顾，既然一个分布式系统无法同时满足一致性、可用性、分区容错性三个特点，素有我们就需要抛弃一样：

解释说明：

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