| dubbo | 您所在的位置：网站首页 › postman传参list › dubbo |
|
Overview Architecture Provider: 暴露服务的服务提供方。Consumer: 调用远程服务的服务消费方。Registry: 服务注册与发现的注册中心。Monitor: 统计服务的调用次调和调用时间的监控中心。Container: 服务运行容器。 Relations 0. 服务容器负责启动，加载，运行服务提供者。 1. 服务提供者在启动时，向注册中心注册自己提供的服务。 2. 服务消费者在启动时，向注册中心订阅自己所需的服务。 3. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。 4. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。 5. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。 6. 注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外 7. 注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者 8. 注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表 Invoker Procedures !important 0. 这里的Invoker是Provider的一个可调用Service的抽象，Invoker封装了Provider地址及Service接口信息。 1. Directory代表多个Invoker，可以把它看成List，但与List不同的是，它的值可能是动态变化的，比如注册中心推送变更。 2. Cluster将Directory中的多个Invoker伪装成一个Invoker，对上层透明，伪装过程包含了容错逻辑，调用失败后，重试另一个。 3. Router负责从多个Invoker中按路由规则选出子集，比如读写分离，应用隔离等。 4. LoadBalance负责从多个Invoker中选出具体的一个用于本次调用，选的过程包含了负载均衡算法，调用失败后，需要重选。 Configuration Prorioty Service方法级优先，接口级次之，全局配置再次之。 如果级别一样，则消费方优先，提供方次之。 BasicJVM启动-D参数优先，这样可以使用户在部署和启动时进行参数重写，比如在启动时需改变协议的端口。 XML次之，如果在XML中有配置，则dubbo.properties中的相应配置项无效。 Properties最后，相当于缺省值，只有XML没有配置时，dubbo.properties的相应配置项才会生效，通常用于共享公共配置，比如应用名。 Features Check on Start Dubbo缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻止Spring初始化完成，以便上线时，能及早发现问题，默认check=true。 #如果你的Spring容器是懒加载的，或者通过API编程延迟引用服务，请关闭check，否则服务临时不可用时， #会抛出异常，拿到null引用，如果check=false，总是会返回引用，当服务恢复时，能自动连上。 可以通过check="false"关闭检查，比如，测试时，有些服务不关心，或者出现了循环依赖，必须有一方先启动。 Fault Tolerance Failover Cluster # DEFAULT 失败自动切换，当出现失败，重试其它服务器。(缺省) 通常用于读操作，但重试会带来更长延迟。 可通过retries="2"来设置重试次数(不含第一次)。 Failfast Cluster 快速失败，只发起一次调用，失败立即报错。 通常用于非幂等性的写操作，比如新增记录。 Failsafe Cluster 失败安全，出现异常时，直接忽略。 通常用于写入审计日志等操作。 Failback Cluster 失败自动恢复，后台记录失败请求，定时重发。 通常用于消息通知操作。 Forking Cluster 并行调用多个服务器，只要一个成功即返回。 通常用于实时性要求较高的读操作，但需要浪费更多服务资源。 可通过forks="2"来设置最大并行数。 Broadcast Cluster 广播调用所有提供者，逐个调用，任意一台报错则报错。(2.1.0开始支持) 通常用于通知所有提供者更新缓存或日志等本地资源信息。important 默认使用Failover，我们的系统使用这种方式，其实应该限定最大重试次数，比如两次（因为一般一台失败，其他的也会失败） #set max retry time 2 OR: OR： Load Balancingimportant 基于软负载均衡算法 Random LoadBalance 随机，按权重设置随机概率。 在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。 RoundRobin LoadBalance 轮循，按公约后的权重设置轮循比率。 存在慢的提供者累积请求问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。 LeastActive LoadBalance 最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。 使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。 ConsistentHash LoadBalance 一致性Hash，相同参数的请求总是发到同一提供者。 当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。 算法参见：http://en.wikipedia.org/wiki/Consistent_hashing。 缺省只对第一个参数Hash，如果要修改，请配置 缺省用160份虚拟节点，如果要修改，请配置 Thread Model事件处理线程说明 0. 如果事件处理的逻辑能迅速完成，并且不会发起新的IO请求，比如只是在内存中记个标识，则直接在IO线程上处理更快，因为减少了线程池调度。 1. 但如果事件处理逻辑较慢，或者需要发起新的IO请求，比如需要查询数据库，则必须派发到线程池，否则IO线程阻塞，将导致不能接收其它请求。 2. 如果用IO线程处理事件，又在事件处理过程中发起新的IO请求，比如在连接事件中发起登录请求，会报“可能引发死锁”异常，但不会真死锁。Dispatcher #all default 0. all 所有消息都派发到线程池，包括请求，响应，连接事件，断开事件，心跳等。 1. direct 所有消息都不派发到线程池，全部在IO线程上直接执行。 2. message 只有请求响应消息派发到线程池，其它连接断开事件，心跳等消息，直接在IO线程上执行。 3. execution 只请求消息派发到线程池，不含响应，响应和其它连接断开事件，心跳等消息，直接在IO线程上执行。 4. connection 在IO线程上，将连接断开事件放入队列，有序逐个执行，其它消息派发到线程池。ThreadPool #fixed default 0. fixed 固定大小线程池，启动时建立线程，不关闭，一直持有。(缺省) 1. cached 缓存线程池，空闲一分钟自动删除，需要时重建。 2. limited 可伸缩线程池，但池中的线程数只会增长不会收缩。(为避免收缩时突然来了大流量引起的性能问题)。E.G 参数说明 iothread epoll模型，所以是CPU核数+1 threads int 可选 100 性能调优 服务线程池大小(固定大小) 2.0.5以上版本 iothreads int 可选 cpu个数+1 性能调优 io线程池大小(固定大小) 2.0.5以上版本 Multi-protocol不同服务在性能上适用不同协议进行传输，比如大数据用短连接协议，小数据大并发用长连接协议。 我们系统使用dubbo协议，基于长连接的协议（传输大小有限制）。如果是大文件可以使用RMI Multi-Registry,Multi-Group,Multi-Version，Group-Aggregation见手册，不过Group-Aggregation倒是很有意思 "com.xxx.MenuService" group="*"> JSR303 based validation #interface javax.validation validation-api 1.0.0.GA #implement org.hibernate hibernate-validator 4.2.0.FinalE.G Cache结果缓存，用于加速热门数据的访问速度，Dubbo提供声明式缓存，以减少用户加缓存的工作量。 "com.callback.CallbackService" ref="callbackService" connections="1" callbacks="1000"> consumer: |
| CopyRight 2018-2019 实验室设备网 版权所有 |