微软比 google 早发明 20 年的 RPC 远程调用，然而现在市面上几乎全是 gRPC 的天下！

[tool2d]

最近在研究 Google 的 gRPC ，几乎都成为大半个云行业标准了。很好奇微软有没有类似替代品，一查还真有。

早在 1995 年，微软就出了一本书，叫<Microsoft RPC programming guide>，那时候微软 RPC 编程体系已经很成熟了，但是没有开源！

正式开源，是在 2005 年，也就是十年后，发布了 DCE/RPC 的标准。可惜那时候完全没掀起什么风浪，当时那个时间节点，大家很难把开源和 M$联系起来。

微软用的是 IDL 语法，和 COM 大同小异，也支持跨语言调用。我自己在虚拟机上编译了一下，用 wireshark 抓了一下 TCP 的远程调用包，搭建很顺利。

感叹技术做的早 20 年也没用，生不逢时啊。

[pengtdyd]

行业里面有一句话：跟着微软混，三天饿九顿。

吃技术饭，远离微软。

[402124773]

微软起个大早，赶个晚集的事情非常多

[ospider]

xmlhttprequest 还是微软第一个加的呢，你上次用 ie 是什么时候了？

[opengps]

及时不对比微软，谷歌也确实是很多东西都在靠开源等方式占领了主流市场，比如搜索，比如浏览器，比如谷歌地图

[tool2d]

@ospider 我觉得最主要还是早期微软把 linux 当成竞争对手，没有做针对 linux 版本的开源和优化。光 windows 上的 rpc 没人来用啊，服务器很多都是 linux 的。

现在微软终于想通了，vscode 都是全平台发布。早就应该打不过就加入。

[tool2d]

@opengps 其实 google 的 gRPC 也没那么好用，和 http2 强绑定，偏要买一送一，所以我才找找有没有什么替代品。

但奈何不了 gRPC 几乎成为了行业标准，只能硬着头皮用起来。

[wetalk]

@402124773 移动互联网，塞班系统~~

[chawuchiren]

@402124773 2015 年微软发布了一个展望未来的视频，不知道它自己能抓住几个实现

[seakingii]

@402124773
"微软起个大早，赶个晚集的事情非常多"

有道理 ,不少技术在我看来其实思想还是可以的,但是微软就是自己都坚持不下去,也推广不起来.
比如 Windows Mobile , WPF 的 MVVM, 远程调用还有个技术叫 WCF

[lesismal]

gRPC 的设计其实挺一般的。基于 HTTP2.0 ，解决不了 4 层线头阻塞，对于 RPC 这种应用场景，集群内多是内网、用 HTTP2.0 是浪费不如直接 TCP 省去加密。streaming 也不是什么优秀玩意，只是相当于在 request and response 基础上前进半步。唯一优点就是多语言。

[ospider]

@tool2d 是的，鲍尔默的路子是走不通的，自己搞一套再优雅也没用，别人只会把你的注意抄过来另起炉灶。gRPC 真的非常一般，尤其是我最常用的 python 客户端更是坑爹，自己起个循环搞乱了好多东西。我现在倾向于用 thrift 或者直接 http2+simdjson.

[dexterzzz]

当年的 RPC 是和 IBM,Oracle 竞争.
WCF,BizTalk,在 ERP,CRM 领域用

[BwNVlwSq]

不要跟着微软混😂

[wanguorui123]

以前用的最多的是 WebService

[cassyfar]

@lesismal multiplexing 了解下

[swulling]

@lesismal

1. 即使是内网环境，所有的流量也应该加密，哪怕是 TCP 也应该套 SSL 。不搞这个你连等保都过不了。

2. 线头阻塞是个啥玩意，说的是 HOL blocking ？这个一般不是翻译为队头阻塞么。

这里有点矛盾，因为 TCP 的队头阻塞是在丢包率比较高的网络中才有较大的影响，如果不丢包也就没什么阻塞一说了，而你之前论证不需要 SSL 说是内网环境，内网的丢包率通常是非常低的。

另外 TCP 的问题和 gRPC 有啥关系，你换其他 TCP 上的 RPC 实现不是一样的问题么。连解决方法，比如 multiplexing 都是一样的，别的 RPC 能用，gRPC 也能用。

当然你可以换基于 UDP 的 RPC 实现，gRPC 社区我看也在做基于 QUIC 也就是 HTTP3 作为传输层的工作。

[mxT52CRuqR6o5]

想做行业标准的话，不搞开放，那就是成心不想好好做
现在的微软在开放方面做的事情真的好多了

[ysc3839]

微软这个 RPC 主要是给 Windows 用的，印象中并没有做成一个跨平台的库，自然不会流行

[agagega]

在「起个大早，赶个晚集」这件事上，你有没有听过一家叫 IBM 的公司……

[pipilu]

你们听说过 WPF ，WCF 吗

[nicebird]

因为不好用啊，com 都死了。

[dobelee]

吃饭还得跟 Google 混。
Ads 、Youtube 、Android 、Golang 、Chrome 、gRPC 、TensorFlow...

浓眉大眼的巨婴不靠谱...

[leeg810312]

感觉这楼里包括 OP 在内很多技术人都还是活在微软是靠卖 Windows 赚大钱的年代，Windows 只占微软业务总量一个零头都多少年了

[lesismal]

@cassyfar 先了解下为什么 Google 搞 QUIC 并被采纳作为 HTTP3.0

> 1. 即使是内网环境，所有的流量也应该加密，哪怕是 TCP 也应该套 SSL 。不搞这个你连等保都过不了。

那这么说吧，很多家其他大厂的 RPC ，是没用 TLS 的。是不是这些大厂就做错了？不是每种服务都要等保流程的，否则安妮这个所有流量都要加密的说法，是不是数据库、redis 这些基础设施都要 TLS ？但实际情况是多数这种内网基础设施都没用 TLS 连接、只是 4 层 TCP 而已，否则性能直接掉一块。
也不是哪个东西用的多就一定它是对的、别人是不好的。就像 windows 比 macos 用户多多了但微软被喷那么多，就像 HTTP1.x 目前仍然是互联网主要流量，2.0 搞这么多年也没普及反倒是委员会老爷们在 2.0 没普及的情况下直接跨过去投票点赞支持 3.0 了，为啥？因为 1.x/2.0 都是垃圾啊！
GRPC 用的最多，一是谷歌背书，二是数量占据多数的中小厂商不具备自研这种基础设施的能力，你看看大厂基础设施，几乎都有自己的轮子，为啥 GRPC 不一统江湖了？先看看性能测试数据？先区分下不同场景加密的必要性？

> 2. 线头阻塞是个啥玩意，说的是 HOL blocking ？这个一般不是翻译为队头阻塞么。

一个概念多种叫法没什么奇怪的，”队头“更偏学术一点的用词、“线头”更形象化偏口语一点而已，这里也有线头：
https://baike.baidu.com/item/%E7%BA%BF%E5%A4%B4%E9%98%BB%E5%A1%9E/1462441

也可能是年纪大一点的我们那个年代叫线头的多一些。另外有些东西是约定俗成，比如“粘包”这种错误定义，但其实提到它大家也知道是啥意思，所以约定俗成了也就不要纠结字眼

> 这里有点矛盾，因为 TCP 的队头阻塞是在丢包率比较高的网络中才有较大的影响，如果不丢包也就没什么阻塞一说了，而你之前论证不需要 SSL 说是内网环境，内网的丢包率通常是非常低的

我不是理论论证，而是就实时论事，比如你如果担心内网流量被抓包，那为什么不先担心下为什么被入侵了提权了，被入侵了难道不比被抓包更严重更可怕吗？别人有更多方法搞事情可都是比抓内网包省事多了。最常见的部署挖矿代码、勒索病毒、登入你的数据库、篡改你的服务挂马之类的，但很少听说别人都入侵了然后还靠抓包这种费时费力拐弯抹角的方式搞事情的。当然，性能不是主要需求的，内网加 TLS 也完全没问题。
还有就是自己的工作实践、以及行业实际情况，你可以随便看看各大厂相关的开源项目，RPC 不用 TLS 的场景多了去了。


> 另外 TCP 的问题和 gRPC 有啥关系，你换其他 TCP 上的 RPC 实现不是一样的问题么。连解决方法，比如 multiplexing 都是一样的，别的 RPC 能用，gRPC 也能用。

同样的，你先了解下为什么 Google 搞 QUIC 并被采纳作为 HTTP3.0

> 当然你可以换基于 UDP 的 RPC 实现，gRPC 社区我看也在做基于 QUIC 也就是 HTTP3 作为传输层的工作。

这里你自己都说了社区有在做基于 QUIC ，和上面一样，为什么不继续用 2.0 ？同样的，你先研究明白为什么 2.0 解决不了 4 层的线头阻塞就明白了。我提示一下：mutiplexing 解决不了是因为它是 7 层的策略，而 TCP 线头阻塞是 4 层，你 multiplexing 是基于别人 4 层实现的，4 层自己先堵车了，7 层动都动不了、怎么解决。。

这方面文章很多，随便找下认真看看就懂了，我就不展开说了