如何设置网站描述淮南餐饮网站建设

当前位置： 首页 > news >正文

如何设置网站描述,淮南餐饮网站建设,房产信息查询官网,做封面图什么网站dubbo简介 Apache Dubbo是一款高性能、轻量级的开源 Java RPC 框架#xff0c;它提供了三大核心能力#xff1a; 面向接口的远程方法调用#xff1b; 可靠、智能的容错和负载均衡#xff1b; 服务自动注册和发现能力。 简单地说#xff0c; Dubbo 是一个分布式服务框架它提供了三大核心能力 面向接口的远程方法调用 可靠、智能的容错和负载均衡 服务自动注册和发现能力。 简单地说 Dubbo 是一个分布式服务框架致力于提供高性能、透明化的 RPC 远程服务调用方案以及服务治理方案以帮助我们解决微服务架构落地时的问题。 Dubbo 是由阿里开源后来加入了 Apache 基金会。目前dubbo最新版本3.0常用版本为2.7.x。 dubbo架构 节点角色 Provider: 暴露服务的服务提供方 Consumer: 调用远程服务的服务消费者 Registry: 服务注册与发现的注册中心 Monitor: 统计服务的调用次数和调用时间的监控中心 Container: 服务运行容器 什么是长连接 在解释长连接之前 先看看什么是短连接。短连接分为3个步骤建立连接 - 数据传输 - 断开连接。每次的网络请求都需要会经历连接和断开事件。 长连接的指建立socket连接后不管是否使用都保持连接。经历的阶段一般为建立连接 - 数据传输 - 保持连接 - 数据传输 - ….. -关闭连接。Http请求可以通过设置connection:keep-alive设置且http1.1默认使用长连接的形式。长连接一般用于操作频繁点对点的及时通讯。如果每次tcp连接都要经历三次握手建立连接会比较耗时。基于长连接的形式处理速度会快很多。 dubbo核心组件 service业务层。包括业务代码的接口与实现即开发者实现的业务代码 config配置层。主要围绕ServiceConfig和ReferenceConfig两个实现类展开初始化配置信息。可以理解为该层管理个整个dubbo的配置。 proxy服务代理层。在dubbo中无论是生产者还是消费者框架都会生成一个代理类整个过程对上层是透明的。 registry注册层。负责dubbo框架的服务注册与发现。 cluster集群容错层。该层主要负责远程调用失败时的容错策略。选择具体调用节点时的负载均衡策略特殊调用路径的路由策略。 monitor监控层。这一层主要负责监控统计调用次数和调用时间。 protocol远程调用层。封装RPC调用具体过程protocol是invoker暴露和引用的主功能入口它负责管理invoker的整个生命周期。invoker是dubbo的核心模型框架中所有其他模型都向它靠拢或者转换成它它代表一个可执行体。允许向它发起invoker调用它可能是一个本地的接口实现也可能是一个远程的实现还可能是一个集群实现。 exchange信息交换层。建立request-response模型封装请求响应模式如把同步请求转换为异步请求。 transport网络传输层。把网络传输抽象为统一的接口如Mina和Netty虽然接口不一样但是Dubbo在它们上面又封装了统一的接口用户也可以根据其扩展接口添加更多的网络传输方式。 serialize序列化层。如果数据要通过网络进行发送则需要先做序列化变成二进制流。序列化层负责管理整个框架网络传输时的序列化和反序列化工作。 dubbo配置 dubbo支持多种配置方式有基于文件的如: 基于XML配置、基于properties文件配置。有基于api的配置、基于注解的配置、基于环境变量的配置以及基于动态配置中心的配置。 基于XML配置 上面的xml是典型的provider和consumer的xml配置。 : 服务配置用于暴露一个服务定于服务的元信息一个服务可以用多个协议暴露一个服务也可以注册到多个注册中心。 : 引用配置用户创建一个远程服务代理一个引用可以指向多个注册中心。 : 协议配置用户配置提供服务的协议信息协议由提供方指定消费方被动接受。 : 应用配置用于配置当前应用信息不管该应用是提供者还是消费者。 : 注册中心配置用于配置连接注册中心相关信息。 : 监控中心信息用户配置连接监控中心相关信息可选。 : 提供方配置当ProtocolConfig和ServiceConfig某属性没有配置时可选。 : 消费方配置当ReferenceConfig某属性没有配置时采用此缺省值可选。 : 方法配置用户ServiceConfig和ReferenceConfig指定方法及的配置信息。 : 参数配置用于指定方法参数配置。 不同粒度配置的覆盖关系 覆盖关系有两个基本原则 方法级优先接口级次之全局配置再次之。 如果级别一样则消费者优先提供方次之。 以timeout为例下图展示了配置的覆盖关系其中服务提供方配置通过URL经由注册中心传递给消费方。 建议: 由服务提供方设置超时因为一个方法需要执行多长时间服务提供者更清楚如果一个消费方同时引用多个服务就不需要关系每个服务的超时设置。理论上ReferenceConfig中除了interface这一项其它所有配置都可以缺省不配置框架会自动使用ConsumerConfigServiceConfigProviderConfig等提供的缺省配置。 基于properties属性文件配置 dubbo可以自动加载classpath跟目录下的dubbo.properties同样也可以使用jvm参数来指定路径: -Dubbo.properties.filexxx.properties。 # provider dubbo.application.iddemo-provider dubbo.application.namedemo-provider dubbo.registry.addresszookeeper://localhost:2181 dubbo.protocol.namedubbo # consumer dubbo.application.iddemo-consumer dubbo.application.namedemo-consumer dubbo.registry.addresszookeeper://localhost:2181 dubbo.protocol.namedubbo dubbo.consumer.loadbalanceroundrobin 和xml的配置相比dubbo.application.namedemo-provider相当于dubbo.registry.addresszookeeper://localhost:2181相当于。 优先级 优先级从高到低 jvm -D 参数: 当启动时可以轻易地重写配置比如改变了dubbo协议的端口。 xml: xml中的当前配置会重写dubbo.properties文件中的配置。 properties: 默认配置仅仅作用于以上两者没有配置时。 基于注解的配置 dubbo 2.6.3及以上版本支持以注解的方式完成配置。 使用EnableDubbo注解指定spring扫描指定包路径下的dubbo服务EnableDubbo(scanBasePackages  com.xxx) public class DubboProviderApplication { public static void main(String[] args) { SpringApplication.run(DubboProviderApplication.class, args); System.out.println(start finished); } } 使用 org.apache.dubbo.config.annotatio包下的 Service 注解暴露一个dubbo服务 Service(provider demoService, version 1.0.0, timeout 3000)public class DemoServiceImpl implements DemoService {Overridepublic void demo() {System.out.println(hello dubbo);}} 为了不和 org.springframework.stereotyp 包下的 Service 注解产生冲突在dubbo2.7.7版本及以后org.apache.dubbo.config.annotation 包下的 Service 注解被标注为已废弃改用DubboService替代。 使用 org.apache.dubbo.config.annotatio 包下的 Reference 注解引用dubbo服务 RestControllerpublic class DemoController {Reference(interfaceClass DemoService.class, loadbalance consistenthash)private DemoService demoService;} 在dubbo2.7.7版本及以后org.apache.dubbo.config.annotation 包下的 Reference 注解被标注为已废弃改用DubboReference替代。 其它几种不常用配置方式 在实际开发中常用的配置方式一般以xml,properties以及注解的方式进行dubbo配置。 api的配置形式 dubbo的api属性和配置项是一一对应的那ApplicationConfig为例: ApplicationConfig applicationConfig new ApplicationConfig(); applicationConfig.setName(demo-provider); api配置的方式不建议使用因为需要通过大量的编码来完成配置而且ReferenceConfig实例很重它内部封装了和注册中心的连接以及服务提供者的连接还涉及到连接信息的缓存如果不进行缓存可能造成内存和连接的泄漏。api的使用范围一般是OpenAPIESBTestMock等系统集成。实际开发场景建议使用xml的配置方式。 其对应的是。 使用配置中心 可以使用业界比较成熟的分布式配置中心如 Apollo、Nacos等。在内容上和dubbo.properties无差别。默认配置中心的优先级高于本地配置。 环境变量加载 dubbo2.7.3版本及以后dubbo会自动从约定的key中读取配置并将配置以K-V的形式写入到URL中。支持的key有以下两个: dubbo.labels: 指定一些配置到URL中的键值对通常通过java -D或系统变量指定 # jvm-Ddubbo.labelstag1value1;tag2value2# 环境变量DUBBO_LABELStag1value1;tag2value2 最终会生成的URL会包含tag1、tag2两个key: dubbo://xxx?tag1value2tag2value2 duubbo.env.keys: 指定环境变量key值dubbo会尝试从环境变量加载每个key值 # JVM-Ddubbo.env.keys DUBBO_TAG1, DUBBO_TAG2# 环境变量DUBBO_ENV_KEYS DUBBO_TAG1, DUBBO_TAG2 最终生成的 URL 会包含 DUBBO_TAG1、DUBBO_TAG2 两个 key: dubbo://xxx?DUBBO_TAG1value1DUBBO_TAG2value2 配置加载流程 dubbo的配置读取总体上遵循了以下几个原则: dubbo支持了多层级的配置并按预先优先级自动实现配置间的覆盖最终所有配置汇总到数据总线URL后驱动后续的服务暴露、引用等流程。 ApplicationConfig、ServiceConfig、ReferenceConfig 可以被理解为配置来源的一种是直接面向用户编程的配置采集方式。 配置格式以properties为主在配置内容上以遵循path-based的命名规范。 配置来源 首先从Dubbo支持的配置来源说起默认有四种配置来源 JVM System Properties-D 参数 Externalized Configuration外部化配置 ServiceConfig、ReferenceConfig 等编程接口采集的配置 本地配置文件 dubbo.properties 覆盖关系 下图展示了配置覆盖关系的优先级从上到下优先级依次降低: 常用配置示例 启动时检查 Dubbo默认设置checktrue在启动时检查服务是否可用不可用时会抛异常阻止spring的初始化这样做的好处在于上线时能及早的发现问题。但是如果在测试环境某些服务不关系或者出现循环依赖必须有一方先启动可以设置checkfalse来关闭检查。 另外如spring容器是懒加载的或者是通过api编程延迟引用服务请关闭check否则服务临时不可用时会抛异常拿到null引用如果设置checkfalse总是会返回引用当服务恢复时能自动连上。 # 关闭某个服务的启动时检查 (没有提供者时报错) # 关闭所有服务的启动时检查 (没有提供者时报错) # 关闭注册中心启动时检查 (注册订阅失败时报错) dubbo.registry.checkfalse前面两个都是指订阅成功但提供者列表是否为空是否报错如果注册订阅失败时也允许启动需使用此选项将在后台定时重试。 dubbo.consumer.checkfalse是设置 check 的缺省值如果配置中有显式的声明如不会受影响。 dubbo.reference.checkfalse强制改变所有 reference 的 check 值就算配置中有声明也会被覆盖。 集群容错 dubbo提供一下集中集群容错实现用户也可以使用dubbo的spi机制对其进行扩展。 Failover cluster: duboo缺省配置。失败自动切换当出现失败重试其它服务器。通常用于读操作但重试会带来更长的延迟。可以通过retries2来设置重试次数(不包含第一次)。 Broadcast cluster: 广播调用。广播调用所有提供者逐个调用任意一台报错则报错。通常用于通知服务提供者更新缓存或者日志等本地资源信息。 ForKing cluster: 并行调用。只要一个成功即返回结果。通常用于实时性较高的读操作。但需要浪费很多服务资源可以通过forks2来设置最大并行数。 Failback cluster: 失败自动回复。后台记录失败请求定时重发。通常用于消息通知等操作。 Failsafe cluster: 失败安全。发生异常直接忽略。通常用于写入审计日志等操作。 Failfast cluster: 快速失败。只发起一次请求失败立即报错。通常使用非幂等行的写操作比如新增记录。 负载均衡 在集群负载均衡配置上dubbo提供了多种策略缺省为random随机调用。也可以使用dubbo的spi机制对其进行扩展。 random loadbalance 随机按权重设置随机概率。 在一个截面上碰撞的概率高但调用量越大分布越均匀而且按概率使用权重后也比较均匀有利于动态调整提供者权重。 roundRobin loadbalance 轮询按公约后的权重设置轮询比率。 存在慢的提供者累积请求的问题比如第二台机器很慢但没挂当请求调到第二台时就卡在那久而久之所有请求都卡在调到第二台上。 LeastActive LoadBalance 最少活跃调用数相同活跃数的随机活跃数指调用前后计数差。 使慢的提供者收到更少请求因为越慢的提供者的调用前后计数差会越大。 ConsistentHash LoadBalance 一致性 Hash相同参数的请求总是发到同一提供者。 当某一台提供者挂时原本发往该提供者的请求基于虚拟节点平摊到其它提供者不会引起剧烈变动。 算法参见http://en.wikipedia.org/wiki/Consistent_hashing 缺省只对第一个参数 Hash如果要修改请配置 缺省用 160 份虚拟节点如果要修改请配置 线程模型 dubbo提供了不同的派发策略和不同的线程池配置来应对不同的事件处理请求。 如果事件处理的逻辑能迅速完成并不会发起新的IO的请求比如只是在内存中几个标识则直接在IO线程上处理更快因为减少了线程池调度。 如果事件处理逻辑较慢或者需要发起新的IO请求比如查询数据库则必须派发到线程池否则IO线程阻塞将导致不能接受其它请求。 如果使用IO线程处理事件又在事件处理过程中发起新的IO请求比如在连接事件中发起登录事件会报”可能引发死锁“异常但不会真的死锁。 我们可以通过以下方式配置dubbo的线程模型: dispatcher all: 表示所有事件都派发到线程池包括请求、响应、连接、断开、心跳等。 direct: 所有消息都不派发到线程池全部在IO线程上执行。 message: 只有请求响应事件派发到线程池其它连接、断开、心跳等消息直接在IO线程上执行。 execution: 只有请求消息派发到线程池不包含响应事件。响应事件和其它连接断开心跳等事件直接在IO线程上执行。 connection: 在IO线程上将连接断开事件放入队列有序逐个执行其它消息派发到线程池。 threadpool fixed: 固定大小线程池启动时创建好不关闭一直持有。(缺省配置) cache: 缓存线程池空闲一分钟自动删除需要时重建。 limited: 可伸缩线程池但池中的线程数只会增长但不会收缩。只增长不收缩的目的是为了避免收缩时突然来了大流量引起性能问题。 eager: 优先创建Worker线程池。在任务数量大于corePoolSize但是小于maximumPoolSize时优先创建Woker来处理任务。当任务数量大于maximumPoolSize时将任务放入阻塞队列中。阻塞队列充满时抛出RejectExecutionException。 直连提供者 在开发及测试环境下经常需要绕过注册中心只测试指定服务提供者这时候可能需要点对点直连点对点直连方式将以服务接口为单位忽略注册中心的提供者列表A接口配置点对点不影响B接口从注册中心获取列表。 服务分组 使用服务分组区分服务接口的不同的实现。当一个接口有多种实现可以用group区分。 事件通知 在调用之前、调用之后、出现异常时会出发oninvoke、onreturn、onthrow三个事件可以配置当事件发生时通知那个类的哪个方法。 Service(value notify) public class NotifyImpl implements Notify { public Map ret new HashMap(); public Map errors new HashMap(); Override public void onreturn(String msg, Integer id) { System.out.println(onreturn msg); ret.put(id, msg); } Override public void onthrow(Throwable t, Integer id) { errors.put(id, t); } } asnyc表示结果是否立即返回默认为falseonreturn表示是否需要回调。 优雅停机 dubbo是通过jdk的shutdownhook来完成优雅停机的所有如果用户使用 kill -9 pid 等强制关闭指令是不会执行优雅停机的。只能通过kill pid时才会执行。 原理 服务提供方 停止时先标记为不接收新请求新请求过来时直接报错让客户端重试其它机器。 然后检测线程池中的线程是否正在执行如果有等到所有线程执行完成除非超时则强制关闭。 服务消费方 停止时不再发起新的调用请求所有新的调用在客户端即报错。 然后检测有没有请求的响应还没有返回等待响应返回除非超时则强制关闭。 设置优雅停机超时时间缺省默认时间是10s如果超时则强制关闭。 dubbo.service.shutdown.wait10000 更多配置实例请看 dubbo官方文档 dubbo推荐用法 在provider端尽量多的配置consumer端属性 作为服务提供方比服务消费方更清楚服务的性能参数如调用的超时时间、合理的重试次数等。 在provider端配置后consumer端不配置则会使用provider端的配置即provider端配置可以作为consumer端的缺省值。否则的话consumer端会使用consumer的全局设置这对provider是不可控的并且往往是合理的。 建议在provider端配置的consumer端属性有: ①:timeout: 方法调用的超时时间 ②:retries: 失败重试次数缺省是2 ③:loadbalance: 负载均衡算法缺省是随机random。还可以配置轮询roundrobin、leastactive、consistenhash等。 ④:actives: 消费者端的最大并发调用限制即当consumer对一个服务的并发调用到上限后新调用会阻塞知道超时在方法上配置 dubbo:method 则对该方法进行并发限制。在接口配置 dubbo:service则针对该服务进行并发限制。 在provider端配置合理的provider端属性 建议在provider端配置的provider端属性有: ①:threads: 服务线程大小 ②:executes: 一个服务提供者并行执行请求上限即当provider对一个服务的并发调用达到上限后新调用会阻塞此时consumer可能会超时在方法上配置 dubbo:method 则对该方法进行并发限制。在接口配置 dubbo:service则针对该服务进行并发限制。 配置dubbo缓存文件 配置dubbo缓存文件的作用在于: 缓存文件会缓存注册中心列表和服务提供者列表应用在启动过程中若注册中心不可用应用会从缓存文件读取服务提供者列表进一步保证应用的可靠性。 注意: 可以根据需要调整缓存文件的路径保证这个文件不会在发布过成功中被清除掉。 如果有多个应用进程注意不要共用同一个文件避免内容被覆盖。 监控配置 ②: 使用dubbo admin监控注册中心上的服务提供方。 ③:服务提供方可使用dubbo的telnet或shell监控项。例如监控服务提供者端口状态: echo status|nc -i 1 20880|grep OK |wc -l。20880为服务端口。 ④: 服务消费方可通过将服务强制转型为EchoService并调用\(echo()测试该服务的提供者是否可用。 public String echo() {EchoService echoService (EchoService) demoService;return (String) echoService.\)echo(ok);} 推荐使用xml配置而非dubbo.properties文件配置 从上面的配置加载流程可知dubbo.properties文件的优先级 以上学习内容均从dubbo官方文档整理摘录。