1 基本概念
1.1 本地函数的调用
以上步骤只是为了说明原理。事实上编译器经常会做优化，对于参数和返回值少的情况会直接将其存放在寄存器，而不需要压栈弹栈的过程，甚至都不需要调用call，而直接做inline操作
1.2 远程函数调用
网上商城和支付服务是两个不同的微服务。
函数映射
我们怎么告诉支付服务我们要调用付款这个函数，而不是退款或者充值呢？在本地调用中，函数体是直接通过函数指针来指定的，我们调用哪个方法，编译器就自动帮我们调用它相应的函数指针。但是在远程调用中，函数指针是不行的，因为两个进程的地址空间是完全不一样的。所以函数都有自己的一个ID，在做 RPC的时候要附上这个 ID，还得有个 ID 和函数的对照关系表，通过 ID找到对应的函数并执行。
客户端怎么把参数值传给远程的函数呢？ 在本地调用中，我们只需要把参数压到栈里，然后让函数自己去栈里读就行。但是在远程过程调用时，客户端跟服务端是不同的进程，不能通过内存来传递参数。这时候就需要客户端把参数先转成一个字节流，传给服务端后，再把字节流转成自己能读取的格式。
远程调用往往用在网络上，如何保证在网络上高效稳定地传输数据？
1.3 RPC概念模型
1.4 一次完整的RPC过程
- IDL
- 生成代码
- 编解码
- 通信协议
- 网络传输
双方依赖同一份IDL
GenCode: 生成代码
相比本地函数调用，远程调用的话我们不知道对方有哪些方法，以及参数长什么样，所以需要有一种方式来描述或者说声明我有哪些方法，方法的参数都是什么样子的，这样的话大家就能按照这个来调用，这个描述文件就是 IDL 文件。
刚才我们提到服务双方是通过约定的规范进行远程调用，双方都依赖同一份IDL文件，需要通过工具来生成对应的生成文件，具体调用的时候用户代码需要依赖生成代码，所以可以把用户代码和生成代码看做一个整体。
编码只是解决了跨语言的数据交换格式，但是如何通讯呢？需要制定通讯协议，以及数据如何传输？我的网络模型如何呢？那就是这里的 transfer 要做的事情。
1.5 RPC的好处
单一职责，开发（采用不同的语言）、部署以及运维（上线独立）都是独立的
可扩展性强，例如压力过大的时候可以独立扩充资源，底层基础服务可以复用（比如个人信息、地理位置信息），节省资源。例如双十一，购物和直播的压力比较大，这种时候可以单独针对这shopping和live这两个模板进行资源的扩充。
某个模块发生故障，不会影响整体的可靠性,某个服务发生故障，并不会导致所有的服务全部gg
1.6 RPC带来的问题
A服务调用B服务，B服务发生异常或者宕机
RPC框架有好处也有坏处，这些坏处将由RPC框架来解决
小结
2 分层设计
2.1 以Apache Thrift为例
2.2 编解码层
Generated Code 里面封装了编解码的逻辑
2.3 编解码层-生成代码
依靠同一份IDL文件生成不同言语的代码。
2.4 编解码层-数据格式
语言特定编码格式：这种编码形式好处是非常方便，可以用很少的额外代码实现内存对象的保存与恢复，这类编码通常与特定的编程语言深度绑定，其他语言很难读取这种数据。如果以这类编码存储或传输数据，那你就和这门语言绑死在一起了。安全和兼容性也是问题
文本格式：文本格式具有人类可读性，数字的编码多有歧义之处，比如XML和CSV不能区分数字和字符串，JSON虽然区分字符串和数字，但是不区分整数和浮点数，而且不能指定精度，处理大量数据时，这个问题更严重了（可以自己设计JSON格式）；没有强制模型约束，实际操作中往往只能采用文档方式来进行约定，这可能会给调试带来一些不便。 由于JSON在一些语言中的序列化和反序列化需要采用反射机制，所以在性能比较差；
二进制编码：实现可以有很多种，TLV 编码 和 Varint 编码（常用），将数据转换成二进制流 BinaryProtocol使用的是TLV编码
2.5 编解码层-二进制编码
TLV编码
这里我们可以看到他的第一个byte是类型，主要用来表示是string还是int还是list等等。这里不写key的字符串了，比如上面的userName，favoriteNumber等等，取而代之的是一个field tag的东西，这个会设置成1,2,3和上面的schema中key字符串前面的数字，也就是用这里来取代了具体的key值，从而减小的总体的大小，这里打包后压缩到 59个字节
TLV编码结构简单清晰，并且扩展性较好，但是由于增加了Type和Length两个冗余信息，有额外的内存开销，特别是在大部分字段都是基本类型的情况下有不小的空间浪费。
增加了type和length两个描述信息
TLV编码是有提升空间的，考虑一下怎么提升？
2.6 编解码层-选型
通用性： 通用性有两个层面的意义：
第一、技术层面，序列化协议是否支持跨平台、跨语言。如果不支持，在技术层面上的通用性就大大降低了。
第二、流行程度，序列化和反序列化需要多方参与，很少人使用的协议往往意味着昂贵的学习成本；另一方面，流行度低的协议，往往缺乏稳定而成熟的跨语言、跨平台的公共包。
兼容性： 移动互联时代，业务系统需求的更新周期变得更快，新的需求不断涌现，而老的系统还是需要继续维护。如果序列化协议具有良好的可扩展性，支持自动增加新的业务字段，而不影响老的服务，这将大大提供系统的灵活度。
性能： 第一、空间开销（Verbosity）， 序列化需要在原有的数据上加上描述字段，以为反序列化解析之用。如果序列化过程引入的额外开销过高，可能会导致过大的网络，磁盘等各方面的压力。对于海量分布式存储系统，数据量往往以TB为单位，巨大的的额外空间开销意味着高昂的成本。
第二、时间开销（Complexity），复杂的序列化协议会导致较长的解析时间，这可能会使得序列化和反序列化阶段成为整个系统的瓶颈。
读取编解码方式
3 关键指标
稳定性
保障策略
熔断： 一个服务 A 调用服务 B 时，服务 B 的业务逻辑又调用了服务 C，而这时服务 C 响应超时了，由于服务 B 依赖服务 C，C 超时直接导致 B 的业务逻辑一直等待，而这个时候服务 A 继续频繁地调用服务 B，服务 B 就可能会因为堆积大量的请求而导致服务宕机，由此就导致了服务雪崩的问题。熔断策略会保护调用端。
限流： 当调用端发送请求过来时，服务端在执行业务逻辑之前先执行检查限流逻辑，如果发现访问量过大并且超出了限流条件，就让服务端直接降级处理或者返回给调用方一个限流异常
超时： 当下游的服务因为某种原因响应过慢，下游服务主动停掉一些不太重要的业务，释放出服务器资源，避免浪费资源
从某种程度上讲超时、限流和熔断也是一种服务降级的手段
请求成功率
负载均衡和重试都可以增加请求的成功率
最左侧的图每一层的节点请求进来之前都会负载均衡
注意，因为重试有放大故障的风险，首先，重试会加大直接下游的负载。如下图，假设 A 服务调用 B 服务，重试次数设置为 r（包括首次请求），当 B 高负载时很可能调用不成功，这时 A 调用失败重试 B ，B 服务的被调用量快速增大，最坏情况下可能放大到 r 倍，不仅不能请求成功，还可能导致 B 的负载继续升高，甚至直接打挂。
防止重试风暴，限制单点重试和限制链路重试
长尾请求
明显高于平均请求实践
PCT99 前百分之九九的请求值
左边是Backup Request示意图
t3 就是pct99的值 最终只花费了t4的时间。
注册中间件
框架是怎么实现这些稳定性策略的呢，就是通过注册中间件
有的叫做middleware 有的叫做interceptor
Kitex Client 和 Server 的创建接口均采用 Option 模式，提供了极大的灵活性，很方便就能注入这些稳定性策略
易用性
Kitex 使用 Suite 来打包自定义的功能，提供「一键配置基础依赖」的体验
Suite提供熔断、限流、降级等基础的功能。
扩展性
Option: 可选参数
一次请求发起首先会经过治理层面，治理相关的逻辑被封装在middleware中，这些middleware会被构造成一个有序调用链逐个执行，比如服务发现、路由、负载均衡、超时控制等，mw执行后就会进入到remote 模块，完成与远端的通信。
可观测性
除了传统的 Log、Metric、Tracing 三件套之外，对于框架来说可能还不够，还有些框架自身状态需要暴露出来，例如当前的环境变量、配置、Client/Server初始化参数、缓存信息等
Metric: 监控，指标监控 Tracing: 链路追踪，往往携带一个链路Id, 标识链路的唯一性。
高性能
这里分两个维度，高性能意味着高吞吐和低延迟，两者都很重要，甚至大部分场景下低延迟更重要。
多路复用可以大大减少了连接带来的资源消耗，并且提升了服务端性能，我们的测试中服务端吞吐可提升30%。
连接多路复用 调用端向服务端的一个节点发送请求，并发场景下，如果是非连接多路复用，每个请求都会持有一个连接，直到请求结束连接才会被关闭或者放入连接池复用，并发量与连接数是对等的关系。而使用连接多路复用，所有请求都可以在一个连接上完成，大家可以明显看到连接资源利用上的差异
- PingPong：客户端发起一个请求后会等待一个响应才可以进行下一次请求
- Oneway：客户端发起一个请求后不等待一个响应
- Streaming：客户端发起一个或多个请求 , 等待一个或多个响应
高性能的编码协议：例如前文的TLV编码协议其实是有进一步优化的空间的，可与选择一些比其更高效的编码协议。
高性能的网络库：例如netpoll 是比go net性能更高的。
小结
命令行工具：如代码生成器
4 企业实践
夸一下 Kitex
企业内部大范围使用 go 语言进行开发，而 kitex 是内部多年最佳实践沉淀出来的一个高性能高可扩展性的 go RPC 框架，在内部有几万个微服务在使用，在去年也开源了回馈给了社区，并且收获了 4K stars，欢迎大家体验和积极地提 issue 和 PR
关于整个 Kitex，接下来我会从以下几个方面进行介绍：......
更多的是给大家一个技术视野的拓展，大家可能听不太懂也没有关系，更主要的相比一些课本理论知识，给大家分享大型互联网公司内部的一些实践经验
整体架构
endpoint:节点 rpcInfo: 请求时需要携带的数据，例如IP地址
tool:
- selfupdate:框架会自动更新最新的代码生成器
acl:访问权限控制
core是它的的主干逻辑，定义了框架的层次结构、接口，还有接口的默认实现，如中间蓝色部分所示，最上面client和server是对用户暴露的，client/server option的配置都是在这两个package中提供的，还有client/server的初始化，在第二节介绍kitex_gen生成代码时，大家应该注意到里面有client.go和server.go，虽然我们在初始化client时调用的是kitex_gen中的方法，其实大家看下kitex_gen下service package代码就知道，里面是对这里的 client/server的封装。
client/server下面的是框架治理层面的功能模块和交互元信息，remote是与对端交互的模块，包括编解码和网络通信。
右边绿色的byted是对字节内部的扩展，集成了内部的二方库还有与字节相关的非通用的实现，在第二节高级特性中关于如何扩展kitex里有介绍过，byted部分是在生成代码中初始化client和server时通过suite集成进来的，这样实现的好处是与字节的内部特性解耦，方便后续开源拆分。
左边的tool则是与生成代码相关的实现，我们的生成代码工具就是编译这个包得到的，里面包括idl解析、校验、代码生成、插件支持、自更新等，未来生成代码逻辑还会做一些拆分，便于给用户提供更友好的扩展
自研网络库
背景
go net无法感知连接的状态,连接池中可能存在失效的连接，影响连接池的复用，每个连接就是一个goroutine。
- Go Net 使用 Epoll ET ，Netpoll 使用 LT。
- Netpoll 在大包场景下会占用更多的内存。
- Go Net 只有一个 Epoll 事件循环（因为 ET 模式被唤醒的少，且事件循环内无需负责读写，所以干的活少），而 Netpoll 允许有多个事件循环（循环内需要负责读写，干的活多，读写越重，越需要开更多 Loops）。
- Go Net 一个连接一个 Goroutine，Netpoll 连接数和 Goroutine 数量没有关系，和请求数有一定关系，但是有 Gopool 重用。
- Go Net 不支持 Zero Copy，甚至于如果用户想要实现 BufferdConnection 这类缓存读取，还会产生二次拷贝。Netpoll 支持管理一个 Buffer 池直接交给用户，且上层用户可以不使用 Read(p []byte) 接口而使用特定零拷贝读取接口对 Buffer 进行管理，实现零拷贝能力的传递。
netpoll
1. go net 无法检测连接对端关闭（无法感知连接状态）
1. 在使用长连接池时，池中存在失效连接，严重影响了连接池的使用和效率。
2. 希望通过引入 epoll 主动监听机制，感知连接状态。
2. go net 缺乏对协程数量的管理
1. Kite 采取一个连接一个 goroutine 模式，由于连接利用率低，服务存在较多无用的 goroutine，占用调度开销，影响性能。
2. 希望建立协程池，提升性能。
netpoll基于epoll，同时采用Reactor模型，对于服务端则是主从Reactor模型，如右图所示：服务端的主reactor 用于接受调用端的连接，然后将建立好的连接注册到某个从Reactor上，从Reactor负责监听连接上的读写事件，然后将读写事件分发到协程池里进行处理。
3. 为了提升性能，引入了 Nocopy Buffer，向上层提供 NoCopy 的调用接口，编解码层面零拷贝
扩展性设计
支持多协议也支持自定义协议扩展
kitex支持多协议的并且也是可扩展的，交互方式上前面已经说过支持ping-pong、streaming、oneway
编解码支持thrift、Protobuf
应用层协议支持TTHeader、Http2、也支持裸的thrift协议
传输层目前支持TCP，未来考虑支持UDP、kernel-bypass的RDMA
如右图所示，框架内部不强依赖任何协议和网络模块，可以基于接口扩展，在传输层上则可以集成其他库进行扩展。
目前集成的有自研的Netpoll，基于netpoll实现的http2库，用于mesh场景通过共享内存高效通信的shm-ipc，以后也可以增加对RDMA支持的扩展
性能优化
网络库优化
编解码优化
序列化和反序列的性能优化从大的方面来看可以从时间和空间两个维度进行优化。从兼容已有的 Binary 协议来看，空间上的优化似乎不太可行，只能从时间维度进行优化，包括下面的几点：...
代码生成 code-gen 的优点是库开发者实现起来相对简单，缺点是增加业务代码的维护成本和局限性。
JIT编译（just-in-time compilation）狭义来说是当某段代码即将第一次被执行时进行编译，因而叫“即时编译”。
即时编译 JIT 则将编译过程移到了程序的加载（或首次解析）阶段，可以一次性编译生成对应的 codec 并高效执行，目前公司内部正在尝试，压测数据表明性能收益还是挺不错的，目的是不损失性能的前提下，减轻用户的维护负担生成代码的负担。
Codegen在Client端和Server端依赖于同一份IDL文件，IDL会不停的变更，这需要在多端重复的去生成代码，jit将代码生成移动到程序加载阶段，减少了程序员的维护代码的负担（没有Jit需要维护多端，而且需要保证依赖于同一份IDL的服务都能被通知到）
合并部署
微服务过微小，造成资源浪费
IPC:进程间通信。Interprocess Communication
Internal Repo只适用于公司的内部环境。
小结
课程小结
补充
十个弹珠，有一个是坏的，重量不一样，请问要怎么找出来？
提示：比较三次
