基于 Python 自建分布式高并发 RPC 服务

RPC（Remote Procedure Call）服务，也即远程过程调用，在互联网企业技术架构中占据了举足轻重的地位，尤其在当下微服务化逐步成为大中型分布式系统架构的主流背景下，RPC 更扮演了重要角色。

Google 开源了 gRPC，Facebook 开源了 Thrift，Twitter 开源了 Finagle，百度开源了 bRPC，腾讯开源了 Tars，阿里开源了 Dubbo 和 HSF，新浪开源了 Motan 等，一线互联网大厂们纷纷亮出自己研制的 RPC 框架武器，在解决分布式高并发业务问题的同时，也向外界展示自己的技术实力。

互联网公司百花齐放，貌似高深复杂的 RPC 框架解决了哪些业务难题？其技术含量究竟高在哪里？后端开发者该如何深入掌握 RPC 开发？这些都是本小册想要解读的问题。

分布式高并发服务是只有高手才能涉足的领域

虽然大部分后端开发者在日常开发中都会隐式或显式的使用 RPC，但对初级开发者来说 RPC 总是略显神秘而有距离，而即便有多年 RPC 使用经验的程序员，也可能依然对 RPC 背后的原理不甚了解，难以精通，遇到复杂问题时难免误用。

RPC 本身理论繁杂，涉及的技术栈和工具也比较多，能将理论落实到代码层面，并结合业务实际情况，避开各种坑，最终实现性能和工程上的极致优化，这对后端开发者来说是一个极大的挑战。

而对 RPC 服务开发原理的认知水平，也正是区分后端高级开发者和普通开发者的重要参考标准之一。在分布式高并发服务领域，只有高手才能担当重任，在业务工程领域有创新建树。

程序员的成长层级

作为一名资深面试官，身边不少工程师会经常问我如何判断一个程序员的技术水平，如何区分他是高级的资深的，还是普通的一般的。

我相信每个面试官都有自己的一套判断标准和参考答案，但通常最重要的一个评判依据是：

• 高级程序员在技术选择的自由度上往往更大，他们不只会用，而且还知道为什么要这么用，能不能不这么用，有没有更好的办法。
• 初级程序员只会搬砖，看到别人怎么写我就怎么写，缺乏自主思考的能力。

初级程序员之所以创新能力不足，根本原因在于没有系统深入的掌握技术背后的基础原理，无法进行有效思考，所谓“浮沙之上，难筑高台”。只有在深入理解技术原理之后，工程能力才可能突飞猛进提升。

不想造轮子的程序员成为不了技术专家

软件工程领域有一句很经典的名言「不要重复造轮子」，这句话旨在指导软件工程以低成本高效开发。不过它也有适用范围，因为程序员平时学习使用的所有开源框架和编程语言，本质上都是「新轮子」。

如果全世界的程序员都完全信奉这句名言，那今天就只有一种编程语言，一种 Web框架，这样的世界是令人难以想象的。从这个角度看，不断造「新轮子、好轮子」才是计算机科学的演进历史，也构建了现代软件工程的基石。

虽然大多数新轮子最终不会被很多人使用，但是「造轮子」无疑是深入理解技术原理的最佳方法。不会造轮子的同学永远只能停在技术表层，难以进行有创造性的工作。在造轮子的初级阶段，确实应该避免将自己的轮子直接应用在公司业务系统中带来维护成本问题，但是到了高级阶段，造轮子的能力就是开发者的核心竞争力，而轮子也将成为公司之间差异化竞争的重要资本。

也可以说，要想成为中大型互联网公司的高级工程师或技术专家，必须具备通过造轮子开发出更好工具的实战能力。

本小册的一个核心目的，就是通过实战模块教大家打造一个属于自己的小轮子 —— RPC 服务小框架，带领大家体验这种深度学习方法的价值。这里也引用理论物理大师费曼先生的名言与诸位同学共勉。

注：理查德·费曼——美国理论物理学家，量子电动力学创始人之一，纳米技术之父。

为什么会有这本小册？

这是我在技术写作领域完成的第一本 主题小册。内容不多，却浓缩了这十年来工作学习修来的精华。十年前，我跟大多数人一样，从校园毕业来到人山人海的帝都，从基础的业务做起，慢慢积累提升，从技术小白逐步成长为技术专家。

期间也曾经历过职业发展迷茫期，在技术上一度缺乏自信，也缺少过来人方向性的指引，在从初、中级开发者向高级开发者跃迁这个阶段，走得尤其艰难。

这也是我写这本小册的初衷，希望能给像曾经的我一样面临同样挑战的朋友们提供一些帮助和指引，尤其是具有一定稀缺性的知识。“授人以鱼不若授人以渔”，“磨刀不误砍柴工”。