【概念】神马是分布式?

本文探讨了系统架构随互联网发展所经历的演变,从单体应用到分布式SOA和微服务架构,比较了RESTful和RPC协议的特点,以及分布式系统中的CAP原理。重点讲解了远程调用、序列化和协议选择,以及微服务架构如何降低开发成本和运维难度。
摘要由CSDN通过智能技术生成
SueWakeup​​​​​

                                                      个人主页:SueWakeup

                                                      系列专栏:学习Java框架

                                                      个性签名:保留赤子之心也许是种幸运吧 

 

本文封面由 凯楠📷 友情赞助播出!

 目录

前言

1. 系统架构的演变

2. SOA 与微服务的关系

3. 分布式核心知识

3.1 分布式中的远程调用

RESTful 接口

总结:什么是 RESTful 架构?

RPC 协议

RPC 协议的优点

RESTful 和 RPC 的区别与联系

3.2 分布式中的 CAP 原理

分布式系统(distributed system)的难点

注:手机端浏览本文章可能会出现 “目录”无法有效展示的情况,请谅解,点击侧栏目录进行跳转  


前言

        随着互联网的发展,网站应用的规模不断扩大,常规的应用架构已无法应对,分布式服务架构以及微服务架构势在必行,必需一个治理系统确保架构有条不紊的演进。

在阅读本文前,推荐阅读【计算机网络】什么是http?


1. 系统架构的演变

架构描述优点缺点
单体应用架构

将所有的功能模块打包到一起

并放在一个 web 容器中运行

  • 所有的功能集成在一个项目工程中
  • 项目架构简单,前期开发成本低,周期短,小型项目的首选
  • 全部功能集成在一个工程中,对于大型项目不易开发、扩展及维护
  • 系统性能扩展只能通过扩展集群结点,成本高、有瓶颈
垂直应用架构将应用拆成互不相干的几个应用
  • 项目架构简单,前期开发成本低,周期短,小型项目的首选
  • 通过垂直拆分,原来的单体项目不至于无线扩大
  • 不同的项目可采用不同的技术
  • 全部功能集成在一个工程中,对于大型项目不易开发、扩展及维护
  • 系统性能扩展只能通过扩展集群结点,成本高、有瓶颈
分布式 SOA 架构

根据需求,进行分布式部署、组合和使用

一个服务以独立的形式存在于操作系统进程中

  • 抽取公共的功能为服务,提高开发效率
  • 对不同的服务进行集群化部署解决系统压力
  • 基于 ESB / DUBBO 减少系统耦合
  • 抽取服务的粒度较大
  • 服务提供方与调用方耦合度较高
微服务架构在 SOA 上做升华,强调 “业务需要的彻底的组件化和服务化” ,原有的单个业务系统拆分成多个可以独立开发、设计、运行的小应用
  • 通过服务的原子化拆分,以及微服务的独立打包、部署和升级,小团队的交付周期将缩短,运维成本也将大幅度下降
  • 微服务遵循单一原则。采用 Restful 等轻量协议传输
  • 微服务过多,服务治理成本高,不利于系统维护
  • 分布式系统开发的技术成本高(容错、分布式事务等)
服务网格化引入一个独立的网络层,实现服务之间的通信、发现、负载均衡等功能
  • 服务之间的通信更加透明,无需关注底层通信细节
  • 提供统一的安全性和监控机制,能够收集服务之间的通信数据
  • 可以根据需求动态地扩展和调整服务之间的通信配置
  • 增加系统的复杂性,需要投入更多精力和资源管理服务网格
  • 引入额外的网络通信会带来一定的性能开销

2. SOA 与微服务的关系

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

3. 分布式核心知识

3.1 分布式中的远程调用

存在多个服务之间存远程调用的需求

远程调用通常包含两个部分:序列化和通信协议

目前常见的序列化协议包括:json、xml、hession、protobuf、thrift、text、bytes等

目前主流的远程调用技术:基于 HTTP 的 RESTful接口、基于 TCP 的 RPC 协议


RESTful 接口

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

资源(Resources):网络上的一个实体或一个具体信息,可以用 URI (统一资源定位符)指向它,每种资源对应一个特定的 URI

表现层(Representation):将 “资源” 具体呈现的形式称为 “表现层”。

比如,文本可以用 txt 格式表现,也可以用 HTML 格式、XML 格式、JSON 格式、“二进制”格式表现。

状态转化(State Transfer):在访问一个网站时,需要客户端和服务器进行互动,在这个过程中,如果客户端需要操作服务器上,必需通过 HTTP 协议,让服务器端发送 “状态转化”。

比如,通过 GET 获取资源、POST 新建或更新资源、PUT 更新资源、DELETE 删除资源。

总结:什么是 RESTful 架构?
  • 每一个 URI 代表一种资源
  • 客户端和服务器之间,传递这种资源的某种表现层
  • 客户端通过 GET、POST、PUT、DELETE 对服务器端资源进行操作,实现 “表现层状态转化”

RPC 协议

Remote Procedure Call 的缩写,一种进程间的通信方式。允许像调用本地服务一样调用远程服务。

主要目标:让远程服务调用更简单、透明。

角色:负责屏蔽底层的传输方式(TPC 或 UDP)、序列化方式(XML / JSON / 二进制)和通信细节。

RPC 协议的优点
  • 微服务架构的基础组件,大大降低架构微服务化的成本,提供调用方与服务提供方的研发效率
  • 屏蔽跨进行调用函数(服务)的各类复杂细节

RESTful 和 RPC 的区别与联系

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

3.2 分布式中的 CAP 原理

分布式系统(distributed system)的难点

各个结点的状态同步。CAP 定理是这方面的基本定理,也是理解分布式系统的起点。

Consistency(一致性):数据一致更新,所有数据的变化都是同步的

Availability(可用性):在集群中一部分节点故障后,集群整体是否还能响应客户端

Partition tolerance(分区容错性):某个节点的故障,并不影响整个系统的允许

选择描述
CA

加强一致性和可用性

传统的关系型数据库的选择

AP

追求分区容错性和可用性

分布式系统设计、非关系型数据库系统的选择

CP

追求一致性和分区容错性

基本不会选择,网络问题会让整个系统瘫痪

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值