架构图

整理架构图

架构图的细节

在 RPC 整个链路中，需要的元素有 Provider、Consumer，以及注册中心（中间 Zookeeper 是作为注册中心来使用的）。整个注册过程如下：

Provider 会把一长串 URL（dubbo://xxx 的字符串）写入到 Zookeeper 里面某个节点里面去。
Consumer 的注册也是类似，会写到 Zookeeper 里面某个节点（Consumer 写入的原因，是因为 OPS 服务治理的时候需要实时的消费者数据）。//消费者也要注册。因为治理服务需要实时的节点数据集合。
Consumer 发起一个订阅，订阅相关的服务。
当某个服务的 Provider 列表有变化的时候，Zookeeper 会将对应的变化通知到订阅过这个服务的 Consumer 列表。//注册中心是主动通知消费者生产者集合发生变化。即图里的第4步

容器的作用

监控器的作用

注册中心的本质作用

本质是存储了关于节点的路由信息。

服务消费者-每次是调用同一个服务器(服务提供者)吗？

不是。

首先，我们得清楚需要不需要是同一个服务器？rpc框架的目的本来就是实现集群避免单点的目的，所以各个服务是平等的，且最好是不带数据的，那样的话，就随机选一个服务器。总结，dubbo/zookeeper本身只负责服务器(服务提供者)的负载均衡，但是不负责服务器状态的维护。

如果服务器有状态维护，怎么办？那么应用层就要解决这个问题。具体怎么解决？还是一样，hash算法：1.简单一点就是hash-求余数 2.复杂一点就是hash-一致性hash算法。

代码-OrderCheckTaskApi

/**
 * 检查是否掉单
 * 
 */
public interface ICheckBankOrderService {
	/**
	 * 检查掉单订单结果
	 * 
	 * @param orderId
	 *            :用于dubbo分布式一致性hash算法，将每次相同订单号分配到相同服务器进行处理
	 * @param order
	 *            :需要查询的未知结果订单对象
	 */
	public void checkOrderResult(String orderId, Order order);

}

什么是服务治理

服务治理包括什么，具体是治理什么东西？

本质上，可以用一句话概括，就是服务器(服务提供者)的路由。具体来说，可以从不同方面、角度、维度拉来说。比如：

1.服务的粒度控制 //是按单个服务，还是按整个应用。还可以按tag。
2.服务的权重控制 //权重高的优先提供服务
3.服务的降级、限流(服务访问流量控制) //其实本质上也是降低权重，或者干脆停止服务，或者不给哪个/些消费者提供服务
4.服务的灰度发布 //就是先上线一部分服务，没问题再全面上线

服务治理和管理控制台console的关系？

服务治理是服务治理，管理控制台是管理控制台，服务治理是要干什么事情，console是提供一个界面。说白了，就是在console进行服务助理。

console可以做什么？

1.查询服务 //按不同维护，比如服务名字、ip等查询服务。这个是最常用的
2.治理服务 //从不同维度对服务进行配置和管理
3.测试服务 //测试服务是否能够被正常消费

如何动态生产服务和消费服务？

什么叫动态？以及为什么要动态？

即如何不停止服务再重启服务，说白了，就是不停机，如何动态添加服务和消费服务。

为什么要动态呢？因为如果服务集群数量非常多的话，假设是单个服务是1000个服务的集群，那么修改一个服务，再上线更新所有的1000个服务，那将会是一场灾难。所以对于那种大型的巨大应用，就有必要自动化上线更新服务。

服务提供者如何动态注册新的服务

需要动态处理两个问题
1.配置文件
新的配置

2.代码jar
新的代码

服务消费者如何动态发现新的服务

其实本质上就是动态读取配置文件，步骤如下：
1.修改配置文件
2.定时任务定时读取配置文件，如果发现新的服务，就动态从注册中心订阅。

工作使用

支付系统
因为服务拆的比较细，每个服务的数量是多节点，但是是个位数，所以采用依次重启的方式。

可能消费者不止一个，那么所有消费者都要重启。

参考

www.cnblogs.com/huangtao192…

dubbo-深入细节

架构图