From ff239076529b8052f37206aac265cdbc9e22c954 Mon Sep 17 00:00:00 2001 From: gao peng <1110@forex.com.cn> Date: Tue, 12 Nov 2019 15:15:49 +0800 Subject: [PATCH 1/2] =?UTF-8?q?=E4=BF=AE=E6=94=B9=E9=94=99=E5=88=AB?= =?UTF-8?q?=E5=AD=97?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/system-design/data-communication/summary.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/system-design/data-communication/summary.md b/docs/system-design/data-communication/summary.md index 7840d844..209df6b6 100644 --- a/docs/system-design/data-communication/summary.md +++ b/docs/system-design/data-communication/summary.md @@ -44,7 +44,7 @@ **消息中间件，也可以叫做中央消息队列或者是消息队列（区别于本地消息队列，本地消息队列指的是JVM内的队列实现）**，是一种独立的队列系统，消息中间件经常用来解决内部服务之间的 **异步调用问题** 。请求服务方把请求队列放到队列中即可返回，然后等待服务提供方去队列中获取请求进行处理，之后通过回调等机制把结果返回给请求服务方。 -异步调用只是消息中间件一个非常常见的应用场景。此外，常用的消息队列应用场景还偷如下几个： +异步调用只是消息中间件一个非常常见的应用场景。此外，常用的消息队列应用场景还有如下几个： - **解耦 ：** 一个业务的非核心流程需要依赖其他系统，但结果并不重要，有通知即可。 - **最终一致性 ：** 指的是两个系统的状态保持一致，可以有一定的延迟，只要最终达到一致性即可。经常用在解决分布式事务上。 - **广播 ：** 消息队列最基本的功能。生产者只负责生产消息，订阅者接收消息。 From 52302c51702e405fb6d87fbc52e14474f7442e1f Mon Sep 17 00:00:00 2001 From: gao peng <1110@forex.com.cn> Date: Tue, 12 Nov 2019 16:51:57 +0800 Subject: [PATCH 2/2] =?UTF-8?q?=E6=96=87=E7=AB=A0=E5=86=85=E5=AE=B9?= =?UTF-8?q?=E4=BC=98=E5=8C=96?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/system-design/data-communication/why-use-rpc.md | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/docs/system-design/data-communication/why-use-rpc.md b/docs/system-design/data-communication/why-use-rpc.md index c6358f35..f4443ddd 100644 --- a/docs/system-design/data-communication/why-use-rpc.md +++ b/docs/system-design/data-communication/why-use-rpc.md @@ -74,13 +74,17 @@ Server: Apache 0.84 ``` -**使用自定义 TCP 协议进行传输就会避免上面这个问题，极大地减轻了传输数据的开销。**这也就是为什么通常会采用自定义 TCP 协议的 RPC 来进行进行服务调用的真正原因。初次之外，成熟的 RPC 框架还提供好了“服务自动注册与发现”、"智能负载均衡"、“可视化的服务治理和运维”、“运行期流量调度”等等功能，这些也算是选择 RPC 进行服务注册和发现的一方面原因吧！ +**使用自定义 TCP 协议进行传输就会避免上面这个问题，极大地减轻了传输数据的开销。** +这也就是为什么通常会采用自定义 TCP 协议的 RPC +来进行进行服务调用的真正原因。除此之外，成熟的 RPC +框架还提供好了“服务自动注册与发现”、"智能负载均衡"、“可视化的服务治理和运维”、“运行期流量调度”等等功能，这些也算是选择 +RPC 进行服务注册和发现的一方面原因吧！ **相关阅读：** - http://www.ruanyifeng.com/blog/2016/08/http.html （HTTP 协议入门- 阮一峰） -###一个常见的错误观点 +### 一个常见的错误观点 很多文章中还会提到说 HTTP 协议相较于自定义 TCP 报文协议，增加的开销在于连接的建立与断开，但是这个观点已经被否认，下面截取自知乎中一个回答，原回答地址：https://www.zhihu.com/question/41609070/answer/191965937。 @@ -88,7 +92,9 @@ Server: Apache 0.84 ### 题外话 -初次之外，还需要注意的一点是 Spring Cloud Netflix 并没有使用 RPC 框架来进行不同服务之间的调用，而是使用 HTTP 协议进行调用的，速度虽然不比 RPC ,但是使用 HTTP 协议也会带来其他很多好处（这一点，可以自行查阅相关资料了解）。 +除此之外，还需要注意的一点是 Spring Cloud Netflix 并没有使用 RPC +框架来进行不同服务之间的调用，而是使用 HTTP 协议进行调用的，速度虽然不比 RPC +,但是使用 HTTP 协议也会带来其他很多好处（这一点，可以自行查阅相关资料了解）。