idea-settings.zip

idea.vmoptions

data-settings.zip

datagrip.vmoptions

     之前给同事解释 RPC，由于紧张，语言没有组织好，解释得很乱，现在重新组织一下语言之后书面化记录下来。

     RPC 的全称是远程过程调用（Remote Produce Call），本质上应该将其看作是一种编程范式，这种编程范式，规定了这样的一件事情：RPC 方案应该能够让我们像调用本地方法一样，去调用远程的一个函数，它可以帮助开发人员屏蔽底层的通讯细节，从而专注于业务开发。RPC 是分布式应用系统的核心解决方案之一。

     RPC 描述的是这样的一种，在分布式场景下的编程范式，实际上和网络协议是没有强关联的关系——既不是对立或并列，也不是包含与被包含的关系。分布式应用开发必然牵涉到多台机器之间的通讯，RPC 客户端调用远程过程，也必须基于某种网络通讯协议，因此才和网络协议扯上关系。

     可是为什么有了 http 之类的应用层通讯协议，RPC 框架往往还会自己去实现一套通讯协议，例如 Dubbo 默认实现的 dubbo 通讯协议，Sofa RPC 实现的 bolt 通讯协议。这是因为 http 通讯是无状态的，这意味着 http 通讯的参与方之间是短连接的，每次通讯都需要重新握手与挥手，这在性能上是一种很大的损失。RPC 框架基于 TCP 协议重新设计的通讯协议，能够定制更加精简的报文结构和更加简单的通信次序，往往还会被设计成长连接的，因此具有更高的性能。但是大多数的 RPC 框架其实都支持多种通讯协议，例如 Sofa RPC 除了支持内置的 bolt 协议，还支持 http、hession2 等。

     我们在理解 Dubbo 的时候，不能只将其简单理解为一个 RPC 通讯框架——通过为应用层动态生成 RPC 的网络通讯代理，使网络通讯细节对业务开发人员透明化，这仅仅只是 dubbo 的数据面作为一款通讯工具最基本的功能而已，在过去几年，Dubbo 早就发展成一个完善的微服务开发框架，拥有完善的服务治理能力。

     给同事解释 RPC 的背景是如下图 mPaaS 中，手机客户端与移动网关之间的 RPC 通讯方式（图中的步骤 7）：

     我问了蚂蚁负责 mPaaS 的开发同学，对方提醒我网关后管生成并向客户端分发的 SDK，实际上就包含了网络通讯代理，只不过这种场景下的 RPC 通讯方式，采用的通讯协议是 http。因此 mPaaS 能够提供“让我们像调用本地方法一样，去调用远程的一个函数”的编程体验，却并不能为了我带来 RPC 框架直接基于 TPC 协议实现的通讯协议的性能提升。

     以前有人好奇进了余胜军的学生群（没交费的群，他还有付费学员群），余胜军也在里面。余胜军很少说话，他说过网上冒充他的人很多，知乎那个账号不是他本人。就根据那人在群里对余胜军的观察，觉得这个年轻人至少有脑子，课程水平确实比较初级，也有一些错误，但作为生意人，这个年轻人一点都不差。

     余胜军能为人所熟知，靠的是包装人设，他的人设是家境贫寒，其貌不扬，初中文凭，不喜欢上学也不再上学，早早混社会，然后靠自己努力逆袭。这个人设的前五个短语就是广大中国人的人设，非常接地气。大多数跟他一样出身的中国人，最迷恋的一套成长故事就是，一个看起来屌丝中的屌丝，在学校一无是处，最后混社会混出一片天地。他们的上学经历很失败，他们也对学校充满敌意，他们一点都不敬佩学习好的人，而是疯狂跪舔余胜军这种学习一塌糊涂但在社会上混得有一定成就的人。余胜军正好给他们立了这样一个故事主人公，并且还立住了，所以他们对余胜军才推崇备至。

     至于余胜军那些比较张狂的宣传方式，比如 xx 全网第一，xx 之父之类的，这同样契合他那些粉丝，越是底层出身的人，越是出于自卑而形成的张狂，什么 xx 一哥，xx 一姐，都是这类人给自己网上贴的标签。余胜军这种张狂都是为了迎合他的粉丝，他混这么多年社会，不可能不知道这会找骂。你觉得 java 之父很傻逼，他的粉丝可不觉得，你不是他的受众群体，他只要维护好自己的受众群体就足够了。

     余胜军的课程确实有一些值得商榷的地方，比如课程内容的错误和不规范的地方，但我不认为这是什么特别不能接受的。现在整个社会就已经浮躁急功近利，劣币驱逐良币的现象大范围存在。这些底层人受社会影响，并不想一步一个脚印踏实走出来，这个社会也不给扎扎实实做事的人生存空间，他们想的就是尽快暴富或者生活好起来。余胜军的课程的定位就是给这类人一个机会，本来他的受众群体文化程度就不高，讲一些简单易懂的内容他们也容易上手。课程的错误内容可以通过以后的工作中学习来弥补，当然也许工作单位的技术水平可能还不如余胜军的课呢，我在某些大企业就切实感受到了这一点。

     其实可以拿余胜军和某个拍农村片的网红导演做个对比，俩人其实是一路人，都是靠立底层出身的人设，做一些接地气的事情，通过炒作蹿红。那些网红导演拍的片子纯粹奶头乐，看之前就是傻逼的人看了之后继续傻逼。顺便说一下，那些短视频里拿着玩具枪射这个射那个的老头老太太，每天的演出酬劳一个人几千块，这是我考证过的，你们手机上看到的农村大爷大妈，可能比你厂里的工头都有钱。我觉得余胜军比起那些网红导演，做的事情有积极意义，起码教会了底层人一些技能，让他们有自食其力的可能。

Apache Dubbo3 源码深入解读

2017年美团技术年货

2018年美团技术年货-后端

2018年美团技术年货-测试

2018年美团技术年货-系统

2018年美团技术年货-运维

2019年美团技术年货

2020年美团技术年货

2021年美团技术年货

2022年美团技术年货

2023年美团技术年货

2024年美团技术年货

     在握手式国密通讯的机制中，正常逻辑如流程一所示：

     上述流程中，服务端来判断 token 是否有效，如果失效会告知客户端，客户端需重新握手协商工作秘钥，并重发请求三。 屹通认为重发是一种性能浪费，于是做了如下流程二的“优化”：

     这里可能存在如下问题：

     服务端在反馈了握手请求之后重新 ntp 或者客户端手动修改时间导致客户端与服务端的时间戳不一致的问题；

     服务端意外删除缓存起来的 token 对应的工作秘钥，但是客户端并不知道。

     总结起来，是这么一回事：

     客户端跟服务端通信之前，应该跟服务端协商一些信息，接下来的通信，客户端将依赖于协商的这些信息（实际上就是工作秘钥）进行。但是为了安全性，这些信息是会周期性更换的。正常情况下，应该是客户端走某次与服务器通讯的过程中，由服务端告知客户端这些信息失效了，然后触发重新协商的过程，协商完毕，重新建立上次中断的请求。

     协商的信息中，服务端会返回一些辅助类字段，例如时间戳。然后屹通，根据这个时间戳，在客户端的网络框架去自行计算协商信息的有效期，而不是根据服务端的实际反馈。理由是多了一次业务请求，性能上由浪费。

     重试重发，在各种各样的场景中（例如 JOB 调度，RPC 请求），都是非常常规的做法，并不是非要避免。并且现在，功能都不对了（例如客户端由于网络分区或者用户手动修改手机时间，会导致本地时间戳和服务端时间戳不一致），空谈性能，有什么用。