RPC编程：RPC概述和架构演变

一：引言

1：本系列文章的目标

1. RPC的架构理解

2. 设计RPC的核心技术难点
   通信+协议+序列化方式+方便调用

3. 多种序列化方式（Hession、Thirft、Prototype)
   掌握这些常用的序列化方式，JSON和JDK自己的序列化方式，都算。

4. 多种RPC解决方案（HessionRPC,Grpc)
   一整套通信+协议+序列化方式+方便调用的解决方案，对既有技术的掌握，HessionRPC的RPC是使用的Hession的序列化方案，这种方案是在Dubbo广泛使用的，但是有点过时了。

5. 注册中心，熔断，限流等设计思想
   RPC最核心的过程，为了当前的RPC原始的解决方案增加了新的功能，在我们的微服务领域见怪不怪了，此时RPC已经不单单是RPC，已经往SOA架构过度。

6. 自研RPC

2：RPC的概念

RPC是远程调用（Remote Procedure Call)的缩写形式，是一种跨进程（JVM)的方法调用形式。是目前在Java分布式，微服务体系中，重要的一种通信方式。

Java体系中的进程就是指的JVM，在Java体系中的跨进程，我们可以简单的理解为跨虚拟机之间的访问。

二：架构的演变过程

1：单体架构

1)：概念

也叫做单体应用:就是系统中所有的功能(代码)合在了一起。并且生成一个jar或者war。部署在一个tomcat中(JVM一个进程)

首页门户和后台管理系统在同一个web服务当中：

2)：特点

一个jar，一个war包含所有子系统，在一个服务中。

3)：优缺点

随着互联网的发展，客户群体和访问量的增加，很多问题暴露了出来：

1：热点问题 (某个子系统访问量大，导致其他子系统的访问出现问题)
2：扩展性差，新资源的分配力度不精确(门户系统访问量，增加机器，增加服务器tomcat。但是新增的资源，不能精确给到门户)
:3：模块(子系统)合度高、相互影响(修改某一个子系统的代码，产生了问题，影响其他的子系统)
4：维护部署成本高(某次发布，只更新了后台管理的(订单模块)，但是因为是单体架构，所以会发布整个系统。
5：技术栈受限，必须使用相同的编程语言开发不同的子系统。

2：单体架构水平扩展

1)：水平拓展的含义

LB是我们的负载均衡器

2)：水平拓展的意义

解决不了单体架构的问题，但是可以解决单体架构在单个服务计算机资源特别是内存、CPU、网络连接数遇到瓶颈时的问题。

3：垂直架构

1)：概念

把一个单体架构的应用，按照子系统进行了划分，每个子系统都独立部署在自己的tomcat中。多个子系统共享数据库等存储资源

2)：如何操作

门户和后台管理系统一人一个jar包，当前分割粒度是基于子系统进行分割（还没有达到模块的粒度）

3)：优缺点

1：把一个单体架构的应用，按照子系统进行了划分，每个子系统都独立部署在自己的tomcat(JVM 进程)中。多个子系统共享数据库等存储资源.
2：垂直架构做水平扩展。
3：有限的解决了单体架构的部分问题。
热点问题 (子系统级别的热点问题解决了，但是模块的热点问题没有解决)。
扩展性差 (子系统级别，增加机器，资源分配 相对精确)
技术栈也不要求统一语言 (门户 PHP,后台管理 Java)

4：RPC架构

1：跨进程调用是走HTTP还是TCP？

都可以，各有利弊。这里解释一下，Http底层也是TCP但是做了封装，Http是端连协议，及时是Http1.1也是有限长连接，时长上比Tcp协议短多了。

2：优缺点比较