引言

一直比较关注斗鱼， 之前曾写过一篇斗鱼已公开的运维技术和架构分析。
最近新看到一篇“斗鱼直播平台后端 RPC 架构浅析”。RPC 应该属于 SOA 层。
关于 RPC 相关概念和框架，没有怎么接触过，现在重新了解下。

RPC 简介

RPC 是指远程过程调用，也就是说两台服务器 A/B，一个应用部署在 A 服务器上，想要调用 B 服务器上应用提供的函数/方法，
由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义和传达调用的数据。

比如说，一个方法可能是这样定义的：
Employee getEmployeeByName(String fullName)

1. 首先，要解决通讯的问题，主要是通过在客户端和服务器之间建立 TCP 连接，远程过程调用的所有交换的数据都在这个连接里传输。
连接可以是按需连接，调用结束后就断掉，也可以是长连接，多个远程过程调用共享同一个连接。

2. 要解决寻址的问题，也就是说，A 服务器上的应用怎么告诉底层的 RPC 框架，
如何连接到 B 服务器（如主机或 IP 地址）以及特定的端口，
方法的名称名称是什么，这样才能完成调用。比如基于 Web 服务协议栈的 RPC，
就要提供一个 endpoint URI，或者是从 UDDI 服务上查找。
如果是 RMI 调用的话，还需要一个 RMI Registry 来注册服务的地址。

3. 当 A 服务器上的应用发起远程过程调用时，方法的参数需要通过底层的网络协议如 TCP 传递到 B 服务器，
由于网络协议是基于二进制的，内存中的参数的值要序列化成二进制的形式，也就是序列化（Serialize）或编组（marshal），
通过寻址和传输将序列化的二进制发送给 B 服务器。

4. B 服务器收到请求后，需要对参数进行反序列化（序列化的逆操作），恢复为内存中的表达方式，
然后找到对应的方法（寻址的一部分）进行本地调用，然后得到返回值。

5. 返回值还要发送回服务器 A 上的应用，也要经过序列化的方式发送，
服务器 A 接到后，再反序列化，恢复为内存中的表达方式，交给 A 服务器上的应用。


为什么需要 RPC 呢？就是无法在一个进程内，甚至一个计算机内通过本地调用的方式完成的需求，
比如不同的系统间的通讯，甚至不同的组织间的通讯。
由于计算能力需要横向扩展，需要在多台机器组成的集群上部署应用，

RPC 的协议有很多，比如最早的 CORBA，Java RMI，Web Service 的 RPC 风格，Hessian，Thrift，甚至 Rest API。

上面是用比较通俗的语言解释了 RPC 相关概念。
这里的一篇远程过程调用(RPC)详解写的非常详细，需要看看。

Ref

远程过程调用(RPC)详解
谁能用通俗的语言解释一下什么是 RPC 框架？
“斗鱼直播平台后端 RPC 架构浅析”

引言

好久没有更新博客了，春节休息了一段时间，然后是一个新业务上线会比之前忙一些。
这 2 天突然想对现在的工作上遇到的一些技术问题进行一个回顾总结。

关于工作上遇到的一些技术问题的回顾总结

1. 要在大量机器上快速分发大的软件包
2. Salt 结合 GitLab 做自动化更新，实现简单的 CI/CD

其实，这些技术问题在克服后，也不像一开始那么难，难点我感觉是在调研实施和维护的过程和判断决策。
首先是要了解痛点和需求，前期要调研（参考业界现有成熟方案）测试好，理解技术方案原理及架构，
然后更重要，同时我感觉更难的一点是如何在现有生产环境实施，因为生产环境和测试环境不同，
很多软件的默认参数我们需要真正深入理解它之后，然后根据实际情况做修改，
这就要求我们必须更加深刻理解所用的技术。 然后还有一点是，一个系统架构部署好后就不是完事了，实际上后期还要把它用起来，用好它， 而不只是实现最开始的需求，这就像互联网开发中的迭代开发一样。

3. 业务上，新游戏对接时，第三方游戏研发公司没有大规模线上运维经验。

这个对接比较耗费时间和精力。这种的情况下需要我们游戏业务的运维从项目开发初期就介入并一直跟进， 评估程序架构的可运维性，引导推进研发改进程序架构，以满足我们的成熟的游戏运维标准及规范， 这是为了以后大规模游戏服务器可以高效运维。 （上面的问题看起来是流程及标准规范的问题。但我们还可以用技术来实现流程化和标准化，减少过多的人为参与）

4. 实施一些项目时，运维标准化没做好，导致项目实施效率很慢，引入了额外的工作量。

引言

最近对自己的状态及目标有些迷茫，以前的计划搁浅了，很多事没有继续，
这几天重新开始看了《把时间当作朋友》，结合自己的情况，有了新认识，摘录相关语句。

《把时间当作朋友》读书笔记

以下记录读书笔记（不定期更新）。

• 5 到 10 年时间定义一个属于自己的人生方向，为之奋斗，为之坚持，不停歇地努力上 10 年 20 年。
• 时间只与那些努力的人做朋友。
• 所有的学生提问都源于所有人的共有的弱点：懒惰。

Ref

把时间当作朋友

网卡 offload 简介

现在，越来越多的网卡设备支持 offload 特性，来提升网络收/发性能。
offload 是将本来该操作系统进行的一些数据包处理（如分片、重组等）放到网卡硬件中去做， 降低系统 CPU 消耗的同时，提高处理的性能。

网卡 offload 包括 LSO/LRO、GSO/GRO、TSO/UFO 等。

LSO/LRO 简介

分别对应到发送和接收两个方向，全称是 Large Segment Offload 和 Large Receive Offload。

首先来看 LSO。我们知道计算机网络上传输的数据基本单位是离散的网包，
既然是网包，就有大小限制，这个限制就是 MTU（Maximum Transmission Unit）的大小，一般是 1518 字节。

比如我们想发送很多数据出去，经过 OS 协议栈的时候，会自动帮你拆分成几个不超过 MTU 的网包。
然而，这个拆分是比较费计算资源的（比如很多时候还要计算分别的 checksum），
由 CPU 来做的话，往往会造成使用率过高。
那可不可以把这些简单重复的操作 offload 到网卡上呢？

于是就有了 LSO，在发送数据超过 MTU 限制的时候（太容易发生了），
OS 只需要提交一次传输请求给网卡，网卡会自动的把数据拿过来，
然后进行切，并封包发出，发出的网包不超过 MTU 限制。

接下来看 LRO，当网卡收到很多碎片包的时候，LRO 可以辅助自动组合成一段较大的数据，一次性提交给 OS 处理。

一般的，LSO 和 LRO 主要面向 TCP 报文。

GSO/GRO 简介

Generic Segmentation Offload 和 Generic Receive Offload，
分别比 LSO 和 LRO 更通用，自动检测网卡支持特性，支持分包则直接发给网卡，否则先分包后发给网卡。
新的驱动一般用 GSO/GRO。

TSO/UFO 简介

TCP Segmentation Offload 和 UDP fragmentation offload，分别对应 TCP 报文和 UDP 报文。

很典型的，TCP 协议中就考虑了分片存在的情况，往往是切分 TCP 的数据包，叫做 TSO。
而一般的情况，则称为 LSO 或者 GSO。

对于其他不支持切片的协议例如 UDP，则只能进行 IP 层上的切片。

可以通过ethtool -k eth0命令来查看网卡设备各个选项的当前状态，注意输出中各种 offload 选项的状态。

Ref

网络虚拟化中的 offload 技术：LSO/LRO、GSO/GRO、TSO/UFO、VXLAN
理解 Linux 网络栈（3）：QEMU/KVM + VxLAN 环境下的 Segmentation Offloading 技术（发送端）
OpenStack 的 Neutron:禁用 GRO:TSO、UFO、GSO、LRO、GRO 和 RSS介绍 2
网卡 TSO/GSO/LRO/GRO 简要介绍
GSO/TSO/GRO 等对 VirtIO 虚机的网络性能影响分析(by quqi99)
使用 LVS，关闭网卡 LRO/GRO 功能　

引言

之前我这边在生产环境中使用 Murder 软件的 BT 上传下载的方式来实现大文件的快速分发。
这属于 BT 软件的应用。最近重新看了下 BT 协议的分析与实现，现在重新了解下 BT 协议原理。

BitTorrent 原理简述

与传统客户端/服务器网络通信模式不同，对等方到对等方（P2P）通信模式在近年来越来越流行起来。
在 P2P 模式中，服务和资源分布化，资源不集中存储在某些设备上，而是分散存储在运行 P2P 程序的设备上，
每一个对等方都可以为其他对等方提供服务。
BitTorrent（中文全称比特流，简称 BT）是一个网络文件传输协议，是能够实现点对点文件分享的技术。
在大多数人感觉中与 P2P 成了对等的一组概念，而它也将 P2P 技术发展到了近乎完美的地步。
研究 BitTorrent 协议对我们深入把握 P2P 技术，了解 Interent 网络发展的未来走向有很大的意义。

BitTorrent 协议是架构于 TCP/IP 协议之上的一个 P2P 文件传输协议，处于 TCP/IP 结构的应用层。
BitTorrent 协议本身也包含了很多具体的内容协议和扩展协议，并在不断扩充中。
如果有多个下载者并发的下载同一个文件，则每个下载者也同时为其它下载者上传文件，
这样，文件源可以支持大量的用户进行下载，而只带来适当的负载的增长。

BitTorrent 协议把提供下载的文件虚拟分成大小相等的块，块大小必须为 2k 的整数次方
（由于是虚拟分块，硬盘上并不产生各个块文件），并把每个块的索引信息和 Hash 验证码
写入 .torrent 文件（即种子文件，也简称为“种子”）中，作为被下载文件的“索引”。 
下载者要下载文件内容，需要先得到相应的 .torrent 文件，然后使用 BT 客户端软件进行下载。 

下载时，BT 客户端首先解析 .torrent 文件得到 Tracker 地址，然后连接 Tracker 服务器。
Tracker 服务器回应下载者的请求，提供下载者其他下载者（包括发布者）的 IP。
或者，BT客户端也可解析 .torrent 文件得到 nodes 路由表，然后连接路由表中的有效节点，
由网络节点提供下载者其他下载者的 IP。

下载者再连接其他下载者，根据 .torrent 文件，两者分别对方告知自己已经有的块，
然后交换对方没有的数据。此时不需要其他服务器参或者其他网络节点的参与，
分散了单个线路上的数据流量，因此减轻了服务器负担。
下载者每得到一个块，需要算出下载块的 Hash 验证码与 .torrent 文件中的对比，
如果一样则说明块正确，不一样则需要重新下载这个块。

因此，下载的人越多，提供的带宽也越多，种子也会越来越多，下载速度就越快。

从 BT 客户端角度考虑，下载原理分为以下几步：

一．根据 BitTorrent 协议，文件发布者会根据要发布的文件生成提供一个 .torrent 文件。
客户端可从 Web 服务器上下载种子文件，并从中得到 Tracker 服务器 URL 和 DHT 网络 nodes 等信息。

二．根据 Tracker URL 与 Tracker 服务器建立连接，并从服务器上得到 Peers 信息。
或者根据 nodes 与 DHT 网络中节点通信，并从节点上得到 Peers 信息。

三．根据 Peers 信息与一个 Peer 建立连接，依据 Peer wire 协议完成握手，
并从 Peer 端下载数据文件。同时监听 Peer 的连接，并给 Peer 上传数据文件。

依据得到 Peers 信息的途径的不同，可分为使用 Tracker 服务器和使用 Trackerless DHT 网络两种方式。

基于 HTTP 的 Tracker 协议，
基于 UDP 的 Trackerless 协议，
基于 TCP 的 Peer wire 协议。

Ref

BitTorrent 协议分析与实现