讨论在C/S结构下的一些跨进程，还有跨机器，跨平台通信方法

[aqbeyond]

如题，如果系统需要将各模块的通讯功能封装成一个组件或者服务，然后提供接口供其他模块调用来进行通信。
模块是跨进程的，可能还是跨机器，跨平台。现在希望有一些比较成熟的方案或者开源软件参考一下。
也考虑过socket，这个需要建立连接，在性能上有待考虑。还有命名管道，没在具体项目中操作过，听说读写缓存有限制。
望了解的一起交流交流。

[aqbeyond]

引用 2 楼 wanghui0380 的回复:

无需纠结，你上面贴的都只是基础手段，你知道就好 因为现代架构里面，那些不是代码技术，而是架构选型。 你需要找的资料不是你上面的连接，而是“分布式”，“RPC”，“分布流”，“微服务”，“分布式EventBus”

我描述的不太清楚。 其实只是希望在一套软件系统中实现，PC机都是直连的情况。然后软件的模块之间能够高效通信，类似window的SendMessage那种效果。

[wanghui0380]

一套软件系-------------------------------------------
PC机都是直连------------------------------------
然后软件的模块之间能够高效通信----------------------
类似window的SendMessage那种效果----------------------


呵呵，难道别人的微服务就是N套软件系，PC机都不直连，模块都不通讯，不能SendMessage？？？

分布式微服务本来就你这种设计标准的，只是你觉着你第一个连接的那叫技术，别人写的不是技术。这是纯程序员的毛病，他就觉着二进制的NX，拖控件的就是垃圾。其实过个5年，他就会把垃圾当宝贝了。因为托控件的底层机制，比你自己玩5年要成熟的多。

比如MVVM，15年前微软就实现了，当时你们都觉着是垃圾，现在java用了，安卓用了，js也用了，好么成香饽饽了，他抱着这些当宝贝，而后骂微软连js都不如！

说白了，实际上最近40年计算机代码计算并没有本质上改变，那怕现在最NX的人工智能，用的算法，普遍上都是1940-1970这个年代的算法，只是被重新封装的更容易应用而已，所以你一定要觉着1940的算法才是技术也无可厚非，只是我们做应用会用2010后的工具，而不是自己做1940算法实现

[wanghui0380]

https://www.cnblogs.com/gaopang/articles/7379802.html
比如这个orlearns的简单例子，就是两个模块的通讯，总共不到70行代码，我们姑且不管他底层是什么，他达到你的目的没有？

[wanghui0380]

在比如这个akka.net
https://www.cnblogs.com/richieyang/p/4945905.html

在比如grpc

https://www.cnblogs.com/linezero/p/grpc.html

在比如：Kafka.net
https://www.cnblogs.com/Wulex/p/5619425.html

其实不必拘泥与什么管道，什么socket，什么邮件槽，因为我们可以知道，甚至可以自己从头做，但是根本没有必要-----底层我们可以自己非常精通，但是项目上我们则不必非抱着“不用管道就能体系技术”这种态度，我们只是需要在这些别人已经大规模成熟应用的架构上选择一款适合自己用的，并且自己绝对有能力用的就行

[以专业开发人员为伍]

直接提出你的设计、代码，然后贴出问题比较好。如果你只是想看看别人贴出来的代码供你抄的成分有多少，这类问题不太符合论坛的原则。

[以专业开发人员为伍]

你提出了“跨进程、跨机器、跨平台”，其实我觉得还可以继续提出“跨星球”通讯，然后人家就给了一个方向。实际上你提出的问题直接决定了回答的内容的。可惜你又说你并不想“跨机器、跨平台”了，这就是把人家的好心技术解答都给当成你的烟灰和空气了。

[以专业开发人员为伍]

当然了，分布式系统其实它主要的作用是完成集群管理控制的作用，是相比于基础的通讯、牺牲了高并发通讯效率的（尽管各种框架宣称性能很难搞）。比如说微软的有些系统是用来作为异构的（比如说 java 等等）应用程序仍然与 .net 程序共同组成多进程微服务集群的，有些系统（例如orleans）则是专门为了 .net 程序而提供类似 Erlang 那样的紧凑的高效封闭专为 .net 异步Task机制优化了的协程管理平台。从通讯角度上说，这些都比较沉重。这些的目的其实为了集群管理平台。

[aqbeyond]

摘了些连接供参考： http://mingrui-521.blog.163.com/blog/static/117015380201186102428705/

[wanghui0380]

无需纠结，你上面贴的都只是基础手段，你知道就好

因为现代架构里面，那些不是代码技术，而是架构选型。

你需要找的资料不是你上面的连接，而是“分布式”，“RPC”，“分布流”，“微服务”，“分布式EventBus”

[wanghui0380]

微软其实自己也有，不过不异构，比如wcf，rerouting这类，俺们自己用可以，一旦和异构化架构玩了，就折腾了

当然微软目前也出了feric，orlearns这些东西，不过目前来说敢吃螃蟹的不多

[wanghui0380]

fabric：
https://azure.microsoft.com/zh-cn/services/service-fabric/
orlearns：
http://dotnet.github.io/orleans/

[threenewbee]

wcf, windows fabric

[aqbeyond]

引用 8 楼 wanghui0380 的回复:

在比如这个akka.net https://www.cnblogs.com/richieyang/p/4945905.html 在比如grpc https://www.cnblogs.com/linezero/p/grpc.html 在比如：Kafka.net https://www.cnblogs.com/Wulex/p/5619425.html 其实不必拘泥与什么管道，什么socket，什么邮件槽，因为我们可以知道，甚至可以自己从头做，但是根本没有必要-----底层我们可以自己非常精通，但是项目上我们则不必非抱着“不用管道就能体系技术”这种态度，我们只是需要在这些别人已经大规模成熟应用的架构上选择一款适合自己用的，并且自己绝对有能力用的就行

谢谢支持。因为没有接触过这些，所以学习一下先。

[aqbeyond]

引用 11 楼 sp1234 的回复:

当然了，分布式系统其实它主要的作用是完成集群管理控制的作用，是相比于基础的通讯、牺牲了高并发通讯效率的（尽管各种框架宣称性能很难搞）。比如说微软的有些系统是用来作为异构的（比如说 java 等等）应用程序仍然与 .net 程序共同组成多进程微服务集群的，有些系统（例如orleans）则是专门为了 .net 程序而提供类似 Erlang 那样的紧凑的高效封闭专为 .net 异步Task机制优化了的协程管理平台。从通讯角度上说，这些都比较沉重。这些的目的其实为了集群管理平台。

你说的对。因为只是设备软件的使用，这边不考虑高并发的case，不是互联网那个方向的，更不要提集群了。 现在就希望了解切合的方案或者已有的容易集成稳定的软件组件。 先屡屡wanghui0380提供的内容。。。

[正怒月神]

我看楼主说的这个 是
微服务

[江湖评谈]

你搞.net 开源少得很


转java 开源一坨一坨的，你用不完。


还有 Socket性能是绝对没有问题的。有问题也是你的问题。