Java微服务 进程间通信

进程间通信

目录

• 进程间通信
  • 同步调用
  • 异步调用
    • 实现方式

同步调用

同步调用比较简单，一致性强，但是容易出调用问题，出现单点故障，因为之间相互依赖，比如RPC必须要依赖的模块上线可用，己方才能调用，性能体验上也会差些，特别是调用层次多的时候。同步调用现在主要有两种：REST 和RPC

- REST(JAX-RS,SpringBoot）：Representational State Transfer“表述性状态转移”--->解决方案： SpringBoot+Spring Cloud
- RPC(Thift，Dubbo) ：Remote Procedure Call）—远程过程调用  ----> 解决方案：Dubbo+Zookeeper

• REST 一般基于 HTTP，更容易实现，更容易被接受，服务端实现技术也更灵活些，各个语言都能支持，同时能跨客户端，对客户端没有特殊的要求，只要封装了 HTTP 的 SDK（比如HttpClient） 就能调用，所以相对使用的广一些。
• RPC 传输协议更高效，安全更可控，特别在一个公司内部，如果有统一个的开发规范和统一的服务框架时，他的开发效率优势更明显些。

对外访问用REST，因为REST使用的是http，在外网访问中有防火墙，网络中只有字符串能够穿透防火墙，而REST使用String字符串即JSON来传数据。

RPC一般使用jetty，对内速度更快，虽然更复杂，但在内部使用起来就如同本地访问一样:比如REST调用user对象是，先请求rest：String json=/users/list获得字符串，然后本地new一个user.setId(json.getId)。而RPC则是直接User user= new RPCUser(),这个new的过程是在远程，其实本地new也就是在本地过程调用

异步调用

异步消息的方式在分布式系统中有特别广泛的应用，他既能减低调用服务之间的耦合，又能成为调用之间的缓冲，确保消息积压不会冲垮被调用方，同时能保证调用方的服务体验，继续干自己该干的活，不至于被后台性能拖慢。

不过需要付出的代价是一致性的减弱，需要接受数据最终一致性（即当调用之后可能不会立即看到返回：一致性减弱，但在之后调用的数据必须一致：最终数据一致）；还有就是后台服务一般要实现 幂等性（幂等性：请求多少次结果都是一致的），因为消息送出于性能的考虑一般会有重复（保证消息的被收到且仅收到一次对性能是很大的考验）；最后就是必须引入一个独立的 Broke

实现方式

实现就是使用消息队列，具体就是一种设计模式，生产者/消费者模式，这也就是为什么最后要引入一个独立的broker代理服务器

Kafka：无broker，速度快，不考虑数据的一致性，数据可以丢失，主要用于日志

Notify：

MessageQueue：

本博客为Swagger-Ranger的笔记分享，文章会持续更新

文中源码地址： https://github.com/Swagger-Ranger

欢迎交流指正，如有侵权请联系作者确认删除： liufei32@outlook.com