|
9 | 9 | **为什么要 RPC ?** 因为,两个不同的服务器上的服务提供的方法不在一个内存空间,所以,需要通过网络编程才能传递方法调用所需要的参数。并且,方法调用的结果也需要通过网络编程来接收。但是,如果我们自己手动网络编程来实现这个调用过程的话工作量是非常大的,因为,我们需要考虑底层传输方式(TCP还是UDP)、序列化方式等等方面。
|
10 | 10 |
|
11 | 11 |
|
12 |
| -**RPC 能帮助我们做什么呢? ** 简单来说,通过 RPC 可以帮助我们调用远程计算机上某个服务的方法,这个过程就像调用本地方法一样简单。并且!我们不需要了解底层网络编程的具体细节。 |
| 12 | +**RPC 能帮助我们做什么呢?** 简单来说,通过 RPC 可以帮助我们调用远程计算机上某个服务的方法,这个过程就像调用本地方法一样简单。并且!我们不需要了解底层网络编程的具体细节。 |
13 | 13 |
|
14 | 14 |
|
15 | 15 | 举个例子:两个不同的服务 A、B 部署在两台不同的机器上,服务 A 如果想要调用服务 B 中的某个方法的话就可以通过 RPC 来做。
|
|
52 | 52 |
|
53 | 53 | 
|
54 | 54 |
|
55 |
| -[Apache Dubbo](https://github.com/apache/incubator-dubbo) (incubating) |ˈdʌbəʊ| 是一款高性能、轻量级的开源 Java RPC 框架。 |
| 55 | +[Apache Dubbo](https://github.com/apache/dubbo) |ˈdʌbəʊ| 是一款高性能、轻量级的开源 Java RPC 框架。 |
56 | 56 |
|
57 | 57 | 根据 [Dubbo 官方文档](https://dubbo.apache.org/zh/)的介绍,Dubbo 提供了六大核心能力
|
58 | 58 |
|
@@ -85,7 +85,7 @@ Dubbo 是由阿里开源,后来加入了 Apache 。正式由于 Dubbo 的出
|
85 | 85 |
|
86 | 86 | 不过,Dubbo 的出现让上述问题得到了解决。**Dubbo 帮助我们解决了什么问题呢?**
|
87 | 87 |
|
88 |
| -1. **负载均衡** : 同一个服务部署在不同的机器时该调用那一台机器上的服务。 |
| 88 | +1. **负载均衡** : 同一个服务部署在不同的机器时该调用哪一台机器上的服务。 |
89 | 89 | 2. **服务调用链路生成** : 随着系统的发展,服务越来越多,服务间依赖关系变得错踪复杂,甚至分不清哪个应用要在哪个应用之前启动,架构师都不能完整的描述应用的架构关系。Dubbo 可以为我们解决服务之间互相是如何调用的。
|
90 | 90 | 3. **服务访问压力以及时长统计、资源调度和治理** :基于访问压力实时管理集群容量,提高集群利用率。
|
91 | 91 | 4. ......
|
@@ -186,7 +186,7 @@ public class XxxLoadBalance implements LoadBalance {
|
186 | 186 | }
|
187 | 187 | ```
|
188 | 188 |
|
189 |
| -我们将这个是实现类的路径写入到`resources` 目录下的 `META-INF/dubbo/org.apache.dubbo.rpc.cluster.LoadBalance`文件中即可。 |
| 189 | +我们将这个实现类的路径写入到`resources` 目录下的 `META-INF/dubbo/org.apache.dubbo.rpc.cluster.LoadBalance`文件中即可。 |
190 | 190 |
|
191 | 191 | ```java
|
192 | 192 | src
|
@@ -229,7 +229,7 @@ Dubbo 采用 微内核(Microkernel) + 插件(Plugin) 模式,简单来
|
229 | 229 |
|
230 | 230 | 正是因为Dubbo基于微内核架构,才使得我们可以随心所欲替换Dubbo的功能点。比如你觉得Dubbo 的序列化模块实现的不满足自己要求,没关系啊!你自己实现一个序列化模块就好了啊!
|
231 | 231 |
|
232 |
| -通常情况下,微核心都会采用 Factory、IoC、OSGi 等方式管理插件生命周期。Dubbo 不想依赖 Spring 等 IoC 容器,也不想自已造一个小的 IoC 容器(过度设计),因此采用了一种最简单的 Factory 方式管理插件 :**JDK 标准的 SPI 扩展机制** (`java.util.ServiceLoader`)。 |
| 232 | +通常情况下,微核心都会采用 Factory、IoC、OSGi 等方式管理插件生命周期。Dubbo 不想依赖 Spring 等 IoC 容器,也不想自己造一个小的 IoC 容器(过度设计),因此采用了一种最简单的 Factory 方式管理插件 :**JDK 标准的 SPI 扩展机制** (`java.util.ServiceLoader`)。 |
233 | 233 |
|
234 | 234 | ### 关于Dubbo架构的一些自测小问题
|
235 | 235 |
|
@@ -299,7 +299,7 @@ public abstract class AbstractLoadBalance implements LoadBalance {
|
299 | 299 |
|
300 | 300 | ` RandomLoadBalance` 具体的实现原理非常简单,假如有两个提供相同服务的服务器 S1,S2,S1的权重为7,S2的权重为3。
|
301 | 301 |
|
302 |
| -我们把这些权重值分布在坐标区间会得到:S1->[0, 7) ,S2->(7, 10]。我们生成[0, 10) 之间的随机数,随机数落到对应的区间,我们就选择对应的服务器来处理请求。 |
| 302 | +我们把这些权重值分布在坐标区间会得到:S1->[0, 7) ,S2->[7, 10)。我们生成[0, 10) 之间的随机数,随机数落到对应的区间,我们就选择对应的服务器来处理请求。 |
303 | 303 |
|
304 | 304 | 
|
305 | 305 |
|
|
0 commit comments