分布式架构的基本介绍

目录

• 1、分布式系统中的相关概念
  • 1.1、衡量网站的性能指标
  • 1.2、集群和分布式
• 2、架构演进
  • 2.1、单体应用架构（单机单体架构、集群单体架构）
  • 2.2、垂直架构（拆分成多个单体架构）
  • 2.3、分布式架构（重复模块抽取为公共服务）
  • 2.4、SOA架构（调度中心）
  • 2.5、微服务架构
• 3、分布式和微服务架构的区别
• 4、框架
  • 4.1、Dubbo
  • 4.2、Spring Cloud
  • 4.3、微服务框架对比
• 5、RPC协议
  • 5.1、常见的RPC协议
  • 5.2、RPC协议和Dubbo、HTTP协议的关系
  • 5.3、RESTful API和 RPC 协议
• 6、序列化和反序列化

 

---

1、分布式系统中的相关概念

1.1、衡量网站的性能指标

• 响应时间：指执行一个请求从开始到最后收到响应数据所花费的总体时间。
• 并发数：指系统同时能处理的请求数量。
  • 并发连接数：指的是客户端向服务器发起请求，并建立了TCP连接。每秒钟服务器连接的总TCP数量
  • 请求数：也称为QPS(Query Per Second) 指每秒多少请求
  • 并发用户数：单位时间内有多少用户
• 吞吐量：指单位时间内系统能处理的请求数量。
  • QPS：Query Per Second 每秒查询数。
  • TPS：Transactions Per Second 每秒事务数。
  • 一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。
  • 一个页面的一次访问，只会形成一个TPS；但一次页面请求，可能产生多次对服务器的请求，就会有多个QPS

 

1.2、集群和分布式

• 集群：可以简单理解为多节点、同模块。
• 分布式（Distributed）：分布式是指将任务、数据、服务等分散到多台计算机上进行处理，而不是单纯依赖于一台计算机。它的目标是提高系统的性能、可靠性、可扩展性和容错性。可以简单理解为，分布式就是通过多个节点（计算机）共同协作来完成一个整体任务。（简单理解就是多节点、多模块）

 

2、架构演进

随着互联网的发展，互联网企业的业务也在不断的飞速发展，进而导致系统的架构也在不断的发生着变化。总体来说，系统的架构大致经历了：单体应用架构—>垂直应用架构—>分布式架构—>SOA架构—>微服务架构的演变。

 

2.1、单体应用架构（单机单体架构、集群单体架构）

在企业发展的初期，一般公司的网站流量都比较小，只需要一个应用，将所有的功能代码打包成一个服务，部署到服务器上就能支撑公司的业务。这样也能够减少开发、部署和维护的成本。比如，大家都很熟悉的电商系统，里面涉及的业务主要有：用户管理、商品管理、订单管理、支付管理、库存管理、物流管理等等模块，初期我们会将所有模块写到一个Web项目中，然后统一部署到一个Web服务器中。

优点： 简单：开发部署都很方便，小型项目首选

缺点： 项目启动慢 可靠性差 可伸缩性差 扩展性和可维护性差 性能低

 

2.2、垂直架构（拆分成多个单体架构）

垂直架构是指将单体架构中的多个模块拆分为多个独立的项目，形成多个独立的单体架构。

垂直架构根据业务属性将一个大的单体应用拆分成多个模块或子系统，子系统之间没有直接关联。 垂直架构相较于单体架构而言，进行了部分解耦，但是不够彻底，在各个子系统相互依赖的代码和模块中，存在模块功能重复开发和重复代码拷贝的情况。

垂直架构存在的问题： 重复功能太多。

 

 

2.3、分布式架构（重复模块抽取为公共服务）

将系统演变为垂直应用架构之后，当垂直应用越来越多时，重复编写的业务代码就会越来越多。此时，我们需要将重复的代码抽象出来，形成统一的服务，供其他系统或者业务模块调用，这就是分布式架构。

分布式架构是指在垂直架构的基础上，将公共业务模块抽取出来，作为独立的服务，供其他调用者消费，以实现服务的共享和重用。

这种架构的优点如下：

1. 将重复的业务代码抽象出来，形成公共的访问服务，提高了代码的复用性。
2. 可以有针对性地对系统和服务进行性能优化，以提升整体的访问性能。

这种架构的缺点如下：

1. 服务之间直接调用，服务提供方地址等信息一旦产生变更，所有消费方都需要变更。
2. 系统之间的调用关系变得复杂，系统之间的依赖关系变得复杂，系统维护成本高。

在分布式架构中，我们会将系统整体拆分为服务层和表现层。服务层封装了具体的业务逻辑供表现层调用，表现层则负责处理与页面的交互操作。分布式系统架构如下图示例：

RPC：Remote Procedure Call 远程过程调用。有非常多的协议和技术来都实现了RPC的过程。比如：HTTP REST风格，Java RMI规范、WebService SOAP协议、Hession等等。

 

 

2.4、SOA架构（调度中心）

在分布式架构下，当部署的服务越来越多时，重复的代码就会变得越来越多，不利于代码的复用和系统维护。为此，我们需要增加一个统一的调度中心对集群进行实时管理，这就是SOA（Service-Oriented Architecture，面向服务的架构）架构。

这种架构的优点是通过注册中心解决了各个服务之间服务依赖和调用关系的自动注册与发现。

这种架构的缺点：服务之间的依赖与调用关系复杂，增加了测试和运维的成本。

 

2.5、微服务架构

微服务架构是在SOA架构的基础上进行进一步的扩展和拆分。在微服务架构下，一个大的项目拆分为一个个小的可独立部署的微服务，每个微服务都有自己的数据库。微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用，这些小应用之间通过服务完成交互和集成。

微服务架构特征：

• 单一职责：微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责，避免重复业务开发
• 面向服务：微服务对外暴露业务接口
• 自治：团队独立、技术独立、数据独立、部署独立
• 隔离性强：服务调用做好隔离、容错、降级，避免出现级联问题

优点：服务彻底拆分，各服务独立打包、独立部署和独立升级。每个微服务负责的业务比较清晰，利于后期扩展和维护。微服务之间可以采用REST和RPC协议进行通信。

缺点：架构非常复杂，运维、监控、部署难度提高。开发的成本比较高。涉及到各服务的容错性问题。涉及到数据的一致性问题。涉及到分布式事务问题

 

 

3、分布式和微服务架构的区别

总的来说，分布式主要是有多个服务器，而微服务主要注重服务的拆分，微服务并不一定是部署在多个服务器上，也可能只是在一个服务器上（基本很少见）。即分布式是多节点多模块，而微服务有可能是单节点多模块，但通常也是多节点多模块的。

分布式服务顾名思义服务是分散部署在不同的机器上的，一个服务可能负责几个功能，是一种面向SOA架构的，服务之间也是通过rpc来交互或者是webservice来交互的。

微服务与分布式的细微差别是，微服务的应用不一定是分散在多个服务器上也可以是同一个服务器。

分布式服务架构强调的是服务化以及服务的分散化，而微服务则更强调服务拆分的专业化和精细分工。分布式也可以理解为属于微服务，但可能服务拆分没那么细致，而微服务架构通常也是分布式的架构。

 

4、框架

Dubbo 是 SOA 时代的产物，SpringCloud 是微服务时代的产物。

 

4.1、Dubbo

Dubbo框架是由阿里巴巴开发的开源式的分布式服务化治理框架，它会通过RPC请求方式访问。Dubbo是在阿里巴巴的电商平台中逐渐探索演进所形成的，经历过复杂业务的高并发挑战。

 

4.2、Spring Cloud

Spring Cloud不是一个单独框架，它是一整个系列的框架合计，它是基于HTTP（s）的RETS服务构建服务体系的。Spring Cloud能够帮助架构师构建一整套完整的微服务架构技术生态链。

SpringCloud是目前国内使用最广泛的微服务框架。官网地址：https://spring.io/projects/spring-cloud。 SpringCloud集成了各种微服务功能组件，并基于SpringBoot实现了这些组件的自动装配，从而提供了良好的开箱即用体验：

springcloud 与 springboot的版本兼容关系：

 

4.3、微服务框架对比

 

5、RPC协议

RPC（Remote Procedure Call）是一种进程间通信方式，简单地说就是能使应用像调用本地方法一样的调用远程的过程或服务，可以应用在分布式服务、分布式计算、远程服务调用等许多场景。

 

5.1、常见的RPC协议

1）Dubbo 协议

• 简介：阿里巴巴开源的高性能、轻量级的 Java RPC 框架 Dubbo 所使用的默认协议。
• 特点
  • 高效的网络传输：基于 TCP 协议，采用单一长连接和 NIO 异步通讯方式，减少了频繁建立和断开连接的开销，提升了系统的并发处理能力，适用于高并发、小数据量的服务调用场景。
  • 丰富的服务治理功能：支持服务注册与发现、负载均衡、集群容错等功能，方便构建复杂的分布式系统。
  • 高度可扩展：支持多种协议（如 Dubbo 协议、HTTP 协议等）、多种序列化方式和多种集群容错策略，可以根据实际需求进行灵活配置。
• 应用场景：主要用于 Java 语言构建的分布式系统，特别是大型互联网企业的微服务架构中。

2）Tars 协议

• 简介：腾讯开源的高性能 RPC 框架 Tars 所使用的协议，提供了服务开发、部署、监控等一站式解决方案。
• 特点
  • 高性能：采用高效的网络传输和序列化协议，具备良好的性能表现，能够处理高并发的服务调用。
  • 自动化运维：框架提供了丰富的运维工具，支持服务的自动部署、监控、扩容等功能，降低了运维成本。
  • 多语言支持：支持多种编程语言，方便不同技术栈的团队进行开发。
• 应用场景：适用于大型互联网企业的分布式系统，特别是对性能和运维管理有较高要求的场景，如游戏、社交等领域的后端服务。

3）gRPC

• 简介：由 Google 开源的高性能、通用的 RPC 框架，基于 HTTP/2 协议标准设计，使用 Protocol Buffers 作为接口描述语言。
• 特点
  • 高性能：HTTP/2 的二进制分帧、多路复用等特性，使得数据传输更高效，减少了网络延迟。
  • 多语言支持：支持多种主流编程语言，如 Java、Python、Go、C++ 等，方便不同技术栈的服务间通信。
  • 强类型接口定义：使用 Protocol Buffers 定义服务接口和消息结构，保证了接口的规范性和一致性，同时生成的代码具有高效的序列化和反序列化能力。
• 应用场景：适用于对性能要求高、跨语言的分布式系统，如微服务架构中的服务间通信，云原生应用等。

 

5.2、RPC协议和Dubbo、HTTP协议的关系

1）RPC 协议与 Dubbo 的关系：dubbo协议是RPC协议的具体实现

• RPC 是抽象概念和技术范畴：RPC 是一种允许程序调用位于不同地址空间（通常是不同计算机）中过程或方法的技术，它提供了一种机制，让调用者可以像调用本地方法一样调用远程方法，屏蔽了底层网络通信、数据传输等复杂细节。RPC 是一个广泛的概念，涵盖了各种实现方式和协议。
• Dubbo 协议是具体实现：Dubbo 协议是 Apache Dubbo 框架所使用的默认协议，它是为了满足分布式系统中服务之间高效通信而设计的具体 RPC 协议。Dubbo 协议在实现 RPC 功能的基础上，结合了 Dubbo 框架的特点和需求，进行了针对性的优化和扩展

 

2）RPC 协议与 HTTP 协议的关系：两者有明显区别，没太大关系

• HTTP 协议可作为 RPC 的传输层协议：RPC 需要一种方式在网络中传输请求和响应数据，HTTP 协议可以充当这个传输层协议。基于 HTTP 协议的 RPC 实现具有良好的跨平台和跨语言特性，因为 HTTP 协议是一种通用的网络协议，几乎所有的编程语言和平台都支持。例如 JSON - RPC 就是一种基于 HTTP 协议的轻量级 RPC 协议，它使用 JSON 格式来编码请求和响应数据，简单易用，适合快速开发和集成。
• RPC 对 HTTP 协议的扩展：虽然 HTTP 协议提供了基本的请求 - 响应机制，但在一些复杂的分布式系统中，可能需要更多的功能，如服务发现、负载均衡、容错等。RPC 协议在使用 HTTP 作为传输层的基础上，会对这些功能进行扩展。例如，一些基于 HTTP 的 RPC 框架会在 HTTP 请求头中添加额外的元数据来实现服务发现和负载均衡等功能。

 

3）Dubbo 与 HTTP 协议的关系：两者有明显区别，没太大关系

• Dubbo 框架支持 HTTP 协议：Dubbo 框架除了默认的 Dubbo 协议外，还支持 HTTP 协议。当使用 HTTP 协议时，Dubbo 服务可以更好地与其他遵循 HTTP 协议的系统进行交互，或者部署在一些需要通过防火墙的环境中。例如，当 Dubbo 服务需要与前端的 Web 应用进行交互时，使用 HTTP 协议可以方便地实现数据传输。
• 应用场景和性能特点不同：Dubbo 协议基于 TCP 协议，采用单一长连接和 NIO 异步通讯，在高并发、小数据量的服务调用场景中性能表现较好；而 HTTP 协议是一种无状态的协议，基于请求 - 响应模型，更适合于对跨平台、跨语言和兼容性要求较高的场景。在实际应用中，可以根据具体的业务需求选择使用 Dubbo 协议还是 HTTP 协议。

 

5.3、RESTful API和 RPC 协议

RESTful API 和 RPC（远程过程调用）协议都是用于实现不同软件系统之间通信的技术手段，但它们在多个方面存在差异。两者有明显区别，没太大关系。

• RESTful API：基于 HTTP 协议，利用 HTTP 的状态码、请求头和响应头来传递额外的信息。例如，使用 200 状态码表示请求成功，404 状态码表示资源不存在；通过Content - Type头指定响应数据的格式。
• RPC 协议：可以基于多种传输协议，如 TCP、UDP 或 HTTP。不同的 RPC 协议有自己的规范和消息格式，例如 gRPC 基于 HTTP/2 协议，定义了自己的请求和响应消息结构。

 

6、序列化和反序列化

• 什么是序列化？序列化就是将数据结构或对象转换成二进制串的过程，也就是编码的过程
• 什么是反序列化？将在序列化过程中所生成的二进制串转换成数据结构或对象的过程
• 为什么需要序列化？转换为二进制串才好进行网络传输嘛
• 为什么需要反序列化？将二进制串转换成对象才好进行后续处理嘛