RPC框架

恩勹
116 阅读8分钟

基本概念

1.本地函数调用

2.远程函数调用

网上商城---->支付服务-->返回网上商城

RPC解决的问题

  1. 函数映射（找到函数通过Id）
  2. 数据转换成字节流（参数转换成字节流给服务端）（编解码）
  3. 网络传输（如何高效稳定传输）（通讯协议+网络传输TCP/UDP）
编解码：

语言特定的格式

将内存对象编码为字节序列，例如Java有java.io.Seriualizable

文本格式

JSON、XML、CSV文本格式

二进制编码

跨语言和高性能等优点，Thrift的BinaryProtocol，Protobuf等

RPC概念

好处：

  1. 单一职责，有利于分工协作和运维开发
  2. 可扩展性强，资源使用率更优
  3. 故障隔离，服务的整体可靠性更强

弊端

  1. 宕机，如何处理
  2. 调用过程网络异常，如何解决
  3. 服务突增，如何处理

1、互联网应用架构演进

随着互联网的发展，用户群体逐渐扩大，网站的流量成倍增⻓，常规的单体架构已无法满足请求压力和业务的快速迭代，架构的变化势在必行。下面我们就以拉勾网的架构演进为例，从最开始的单体架构分析，一步步的到现在的微服务架构。

淘宝:LAMP，Linux、Apache、MySQL、PHP

1.1、单体应用架构

在诞生之初，企业的用户量、数据量规模都比较小，项目所有的功能模块都放在一个工程中编码、 编译、打包并且部署在一个Tomcat容器中的架构模式就是单体应用架构，这样的架构既简单实用、便于维护，成本又低，成为了那个时代的主流架构方式。

优点:

  • 高效开发:项目前期开发节奏快，团队成员少的时候能够快速迭代
  • 架构简单:MVC架构，只需要借助IDE开发、调试即可
  • 易于测试:只需要通过单元测试或者浏览器完成
  • 易于部署:打包成单一可执行的jar或者打成war包放到容器内启动

单体架构的应用比较容易部署、测试，在项目的初期，单体应用可以很好地运行。然而，随着需求的不断增加， 越来越多的人加入开发团队，代码库也在飞速地膨胀。慢慢地，单体应用变得越来越臃肿，可维护性、灵活性逐渐降低，维护成本越来越高。

缺点:

  • 可靠性差: 某个应用Bug，例如死循环、内存溢出等，可能会导致整个应用的崩溃
  • 复杂性高: 以一个百万行级别的单体应用为例，整个项目包含的模块多、模块的边界模糊、 依赖关系不清晰、 代码质量参差不齐、 混乱地堆砌在一起。使得整个项目非常复杂。
  • 扩展能力受限: 单体应用只能作为一个整体进行扩展，无法根据业务模块的需要进行伸缩。例如，应用中有的模块是计算密集型的，它需要强劲的CPU; 有的模块则是IO密集型的，需要更大的内存。 由于这些模块部署在一起，不得不在硬件的选择上做出妥协。

业务量上涨之后，单体应用架构进一步丰富变化，比如应用集群部署、使用Nginx进行负载均衡、增加缓存服务器、增加文件服务器、数据库集群并做读写分离等，通过以上措施增强应对高并发的能力、应对一定的复杂业务场景，但依然属于单体应用架构。

1.2、垂直应用架构

为了避免上面提到的那些问题，开始做模块的垂直划分，做垂直划分的原则是基于企业现有的业务 特性来做，核心目标标第一个是为了业务之间互不影响，第二个是在研发团队的壮大后为了提高效率， 减少组件之间的依赖。

优点:

  • 系统拆分实现了流量分担，解决了并发问题
  • 可以针对不同模块进行优化
  • 方便水平扩展，负载均衡，容错率提高
  • 系统间相互独立，互不影响，新的业务迭代时更加高效

缺点:

  • 服务之间相互调用，如果某个服务的端口或者ip地址发生改变，调用的系统得手动改变
  • 搭建集群之后，实现负载均衡比较复杂，如:内网负载，在迁移机器时会影响调用方的路由，导致线上故障
  • 服务之间调用方式不统一，基于httpclient、 webservice ，接口协议不统一
  • 服务监控不到位:除了依靠端口、进程的监控，调用的成功率、失败率、总耗时等等这些监控指标是没有的

1.3、SOA应用架构

在做了垂直划分以后，模块随之增多，维护的成本在也变高，一些通用的业务和模块重复的越来越 多，为了解决上面提到的接口协议不统一、服务无法监控、服务的负载均衡，引入了阿里巴巴开源的Dubbo ，一款高性能、轻量级的开源Java RPC框架，可以和Spring框架无缝集成。它提供了三大核心能力:面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。

SOA (Service-Oriented Architecture)，即面向服务的架构。根据实际业务，把系统拆分成合适的、独立部署的模块，模块之间相互独立(通过Webservice/Dubbo等技术进行通信)。

优点: 分布式、松耦合、扩展灵活、可重用。

缺点: 服务抽取粒度较大、服务调用方和提供方耦合度较高(接口耦合度)

1.4、微服务应用架构

微服务架构可以说是SOA架构的一种拓展，这种架构模式下它拆分粒度更小、服务更独立。把应用拆分成为一个个微小的服务，不同的服务可以使用不同的开发语言和存储，服务之间往往通过Restful等轻量级通信。微服务架构关键在于微小、独立、轻量级通信。

微服务是在 SOA 上做的升华粒度更加细致，微服务架构强调的一个重点是业务需要彻底的组件化和服务化

微服务架构和SOA架构相似又不同

微服务架构和SOA架构很明显的一个区别就是服务拆分粒度的不同，但是对于拉勾的架构发展来说，我们所看到的SOA阶段其实服务拆分粒度相对来说已经比较细了(超前哦!)，所以上述企业 SOA 到企业微服务，从服务拆分上来说变化并不大，只是引入了相对完整的新一代Spring Cloud微服务技术。自然，上述我们看到的都是架构演变的阶段结果，每一个阶段其实都经历了很多变化，企业的服务拆分其实也是走过了从粗到细，并非绝对的一步到位。

举个拉勾案例来说明SOA和微服务拆分粒度不同

我们在SOA架构的初期，“简历投递模块”和“人才搜索模块”都有简历内容展示的需求，只不过说可能略有区别，一开始在两个模块中各维护了一套简历查询和展示的代码; 后期我们将服务更细粒度拆分，拆分出简历基础服务，那么不同模块调用这个基础服务即可。

2、微服务架构体现的思想及优缺点

微服务架构设计的核心思想就是 “微” ，拆分的粒度相对比较小，这样的话单一职责、开发的耦合度就会降低、微小的功能可以独立部署扩展、灵活性强，升级改造影响范围小。

微服务架构的优点: 微服务架构和微服务

  • 微服务很小，便于特定业务功能的聚焦
  • 微服务很小，每个微服务都可以被一个小团队单独实施(开发、测试、部署上线、运维)，团队合作一定程度解耦，便于实施敏捷开发
  • 微服务很小，便于重用和模块之间的组装
  • 微服务很独立，那么不同的微服务可以使用不同的语言开发，松耦合
  • 微服务架构下，我们更容易引入新技术

微服务架构的缺点

  • 微服务架构下，分布式复杂难以管理，当服务数量增加，管理将越加复杂;
  • 微服务架构下，分布式链路跟踪难等;
avatar
文章
阅读
粉丝