珠海网站制作推广,ai做的比较好的网站,摄影网站有哪些?,微商平台都有哪些摘要#xff1a; Cloud Native 应用架构随着云技术的发展受到业界特别重视和关注#xff0c;尤其是 CNCF#xff08;Cloud Native Computing Foundation#xff09;项目蓬勃发展之际。Dubbo 作为服务治理的标志性项目#xff0c;自然紧跟业界的潮流#xff0c;拥抱技术的…摘要 Cloud Native 应用架构随着云技术的发展受到业界特别重视和关注尤其是 CNCFCloud Native Computing Foundation项目蓬勃发展之际。Dubbo 作为服务治理的标志性项目自然紧跟业界的潮流拥抱技术的变化。 Dubbo Cloud Native 实践与思考Dubbo Cloud Native 实践与思考分享简介自我介绍主要议程Cloud Native 基础设施服务发现Service Discovery 如何选择EurekaConsulZookeeper负载均衡服务网关分布式配置服务熔断链路跟踪服务监控Cloud Native 架构选型CNCF 架构体系Spring Cloud 架构体系Dubbo 架构体系Dubbo Cloud Native 准备Dubbo 注解驱动Annotation-DrivenDubboComponentScan 服务端示例DubboComponentScan 客户端示例Dubbo 外部化配置Externalized Configuration现场演示环节Dubbo 整合 Hystrix 示例Dubbo 客户端实现Dubbo 服务端实现测试客户端 REST 服务参考资源分享简介Cloud Native 应用架构随着云技术的发展受到业界特别重视和关注尤其是 CNCFCloud Native Computing Foundation项目蓬勃发展之际。Dubbo 作为服务治理的标志性项目自然紧跟业界的潮流拥抱技术的变化。本次分享的议题包括介绍 Apache 孵化项目Dubbo Spring Boot Project 以及汇报 Dubbo 与 Cloud Native 整合过程中的一些实践与思考如适配 Spring Cloud 、服务发现、服务网关、服务跟踪以及监控等。注为了读者的阅读方便和习惯本文字稿将在演讲内容的基础上做出适当的调整。自我介绍马昕曦小马哥阿里巴巴中间件技术专家十余年 Java EE 从业经验Dubbo 维护者、架构师以及微服务布道师。目前主要负责阿里巴巴集团微服务技术实施、架构衍进、基础设施构建等。重点关注云计算、微服务以及软件架构等领域。通过 SUN JavaSCJP、SCWCD、SCBCD以及 Oracle OCA 等的认证。主要议程今天我非常荣幸地与大家一起讨论关于 Dubbo Cloud Native 相关议题本次议题紧扣“实践与思考“两个关键字主要的议程包括Cloud Native 基础设施Cloud Native 架构选型Dubbo Cloud Native 准备Cloud Native 基础设施关于 Cloud Native 的定义不同的云平台可能给出的内容存在差异。此处我向大家介绍目前最热门的 CNCF 的定义”CNCF Cloud Native Definition v1.0“ 中的描述Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.相对于其他学术流派CNCF 的 Cloud Native 定义更为具体偏向于软件技术。这一点我们从文中的一些关键字能够明显地体会到如关键字 Containers容器、service meshes、”microservices微服务“等。通常开发人员较为关注的 Cloud Native 基础设施为“服务发现”、“负载均衡”、“服务网关”、“分布式配置”、“服务熔断”以及“跟踪监控”如图所示由于 PPT 格式的限制此处我将“链路跟踪”与“服务监控” 并陈为“跟踪监控”。接下来我们进入“服务发现”的讨论。服务发现Service Discovery 随着微服务架构MSA受到不同规模企业的青睐服务治理的实施逐渐被提上基础设施改造的议程。尽管这些概念在 SOA 时代已经提出然而引起业界广泛关注应归功于微服务。服务发现Service Discovery 作为服务治理的核心特性通常也将服务注册Service Registration一并讨论。无论是服务发现还是服务注册在具体落地实施时它们必须面对技术选型的问题。在座的各位包括我大多数是 Java 程序员自然关心 Java 的技术方案。目前Java 社区最为津津乐道的方案莫过于 Spring Cloud搭配 Netflix OSS 组件 Eureka帮助 Spring Boot 应用快速搭建服务发现体系。其中Eureka Server 作为注册中心服务器Spring Boot 应用整合 Eureka Client 向 Eureka Server 注册。实际上Spring Cloud 除了整合 Netflix Eureka 作为服务发现之外还提供了 Apache Zookeeper 和 HachiCorp Consul 的实现所以这三种方案出现在当前页面其中还包括 Redis 和 Apache Curator前者是 Dubbo 的服务发现实现方案之一然而小马哥并不建议使用 Redis 作为注册中心还是保持它缓存中间件的单纯性较好。而 Curator 作为 Zookeeper Java 客户端类库它不但可用在 Dubbo而且其扩展项目 Curator Service Discovery 也是 Spring Cloud 整合 Zookeeper 作为服务发现的关键基础设施。或许大家思考以上方案应该如何选型的问题。如何选择Eureka当服务发现选型时Netflix Eureka 或许是在开发人员脑海中复现的首选方案。然而 Eureka 在阿里大规模实践时它的表现并不理想当 Eureka 客户端服务实例数量达到一定时Eureka Server 时常会出现服务不可用的情况主要的问题集中在更新Update机制、复制Replication机制以及内存型存储。由于时间的关系此处我不加详细说明部分答案在 Eureka Wiki Eureka 2.0 Motivations 中也有描述Why Eureka 2.0?Only support homogenous client viewsOnly supports scheduled updatesReplication algorithm limits scalability注以上具体内容在分享现场并没有具体提及此处特意为读者补充。以上问题 Netflix 早在 2015 年已意识到然而 Eureka 2.0 的发布遥遥无期。后来我托朋友联系上了 Netflix 的工程师咨询他们关于 Eureka 1 在自身生产环境的使用情况。他们的回复是部分场景在使用。这样的答复值得玩味再细问其覆盖比重对方三缄其口。这不得不让我对 Eureka 的成熟度产生了质疑所以我不建议大家在数以千计的应用实例场景中使用。ConsulConsul 同样作为 Spring Cloud 服务中心基于 GO 语言开发其数据一致性采用 Raft 算法低内存集群支持。曾一度成为我理想的替换 Eureka 的方案不过本人并不具备 Consul 的大规模运用为此还特意请教永辉云创的架构师翟永超《Spring Cloud 微服务实战》的作者。他告知 Consul 表现不错并在跨 DC数据中心方面也比较稳定他的答复让我增强了 Consul 的信心稍显遗憾的是其 Consul 应用节点略少。后来我听说 B 站的哥们自研服务发现中间件 discovery他们应该也对 Consul 做过调研和评估他们的看法是Github 开源地址https://github.com/Bilibili/discovery/discovery 在 B 站 K8S 上的使用情况综合两家公司的评估尽管没有经过本人实际操作并且两者没有提供具体的数据指标然而在一定程度上说明 Consul 作为注册中心的实例节点规模大概在 2k 以内。换言之它比较适合中小型企业。ZookeeperZookeeper 即可是 Spring Cloud 注册中心又能作为 Dubbo 注册中心与 Eureka 不同它属于 CP 分布式策略而后者属于 AP。两者的共同点在于均属于内存型注册中心在大规模集群场景也会遇到 Eureka 类似的问题。不过从运维的角度相较于 Eureka 而言熟悉 Zookeeper 运维朋友更多。在生态性方面Zookeeper 周边的生态更丰富如 Zookeeper C API尽管 Eureka 提供了语言无关性的 REST 接口。同时Zookeeper 还从当配置服务器的角色降低了学习的成本。综上结论我推荐使用 Zookeeper 作为服务发现基础设施无论您选择 Dubbo 方案还是使用 Spring Cloud。尽管它在大规模集群时也出现 Zookeeper 间歇性卡顿等问题。负载均衡负载均衡是第二个重要 Cloud Native 基础设施熟悉 Spring Cloud 的朋友一定对右侧的蝴蝶结有印象它就是 Netflix OSS 负载均衡组件 Ribbon框架层面提供了多种负载均衡规则如随机 - RandomRule轮循 - RoundRobinRule权重响应时间 - WeightedResponseTimeRuleWeightedResponseTimeRule 之外其他的 Ribbon 负载均衡实现均没有提供权重因子而权重因子对于蓝绿发布、服务预热等方面的帮助是至关重要的。因此权重因子在 Dubbo “随机“、”轮询“ 以及 ”最少活跃调用数“ 负载均衡算法中均体现。以上讨论的两种框架均属于 Java 实现而中间的 Kong 则是更为通用的实现通常它作为 API 服务网关后面我们将继续讨论。可简单地认为它是 Nginx Lua 的扩展负载均衡自然成为不可或缺的特性。其默认的负载均衡算法为具备权重的轮询weighted-round-robin同时一致性 Hash 算法作为可选方案。服务网关谈及服务网关Java 工程师最容易想到的是 Spring Cloud Zuul。Zuul 是 Netflix 基于 Servlet API 开发的 Web 服务代理组件在 Spring Cloud 使用场景中它与 Eureka 和 Ribbon 整合打造具备服务动态更新和负载均衡能力的服务网关。最近随着 Spring Cloud Finchley 的发布Spring Cloud Zuul 的替代方案 Spring Cloud Gateway 孕育而生不过官方的描述还是比较谦虚谨慎并没有一刀切地引导开发人员从 Zuul 迁移到 Gateway 上来API Gateway built on top of the Spring Ecosystem, including: Spring 5, Spring Boot 2 and Project Reactor. Spring Cloud Gateway aims to provide a simple, yet effective way to route to APIs and provide cross cutting concerns to them such as: security, monitoring/metrics, and resiliency.两者不同点在于Zuul 运行在 Servlet 容器中而 Gateway 并不像 Spring WebFlux 能够兼容 Servlet 3.1 运行时而是必须依赖 Netty 的运行时以及整合 Reactive 框架 Reactor实现异步非阻塞网关。由于近期对于 Spring 5 WebFlux 能够大幅提升应用性能的观点甚嚣尘上实际上没有任何直接性能基准测试证明 WebFlux 能够加快程序执行速度或许大家认为我的观点与主流格格不入可是我要告诉大家的是这个问题我在同事间验证过很多次大多数情况Reactive 并不没有提升性能。就连 Spring 官方也承认这个观点1.1.7. Performance vs scalePerformance has many characteristics and meanings. Reactive and non-blocking generally do not make applications run faster. They can, in some cases, for example if using the WebClient to execute remote calls in parallel. On the whole it requires more work to do things the non-blocking way and that can increase slightly the required processing time.资源地址https://docs.spring.io/spring/docs/5.0.7.RELEASE/spring-framework-reference/web-reactive.html#webflux-performance同时这里提供一篇 Spring 5 WebFlux: Performance tests 的文章在结尾部分给出了结论作者坦言在速度上没有明显的提升甚至从结果来看速度稍微更糟糕No improvement in speed was observed with our reactive apps (the Gatling results are even slightly worse).以上测试工程和结论是由开源项目 JHipster 的工程师给出具备一定的客观性和可信度。资源地址https://blog.ippon.tech/spring-5-webflux-performance-tests/换言之基于 Reactor 开发的 Gateway 在性能可能并没有明显的提升。因此Zuul 和 Gateway 的性能对比则演变为 Servlet 容器和 Netty Web 容器的比较感兴趣的朋友可以去网上寻找一些比较数据两者的性能在伯仲间。当然我和在座的各位一样对 Java 的实现方案自然是情有独钟。然而我想说的是身为 Java 工程师眼中难免有 Java但是眼中不要只有 Java。Nginx 作为当年著名 “C10K” 问题的解决方案无论从连接数量还是资源消耗方面均优于 Java 实现。作为技术人应该具有更为宽广的胸怀接纳非我族类的气魄该放手的时候就放手。Nginx 作为服务网关不失为一种好的方案然而它的动态性略为不足需要结合 Lua 脚本辅助完成因此OpenResty 和 Kong 这类方案脱颖而出。如果就 HTTP API 网关而言个人认为 Kong 的方案更佳因为它提供完整的解决方案包括前面讨论的负载均衡权重、服务熔断以及服务发现等特性。类似的特性在 CNCF 项目 Envoy 也有体现它是另一种高性能代理的方案提供服务发现、健康和负载均衡。在协议上天然支持 HTTP 和 HTTP/2而通讯协议支持 gRPC建议大家予以高度关注。值得一提的是HTTP API 网关通常需要支持 sidecar换言之支撑网关服务的基础设施必须提供服务发现的能力就功能性而言Zuul 和 Gateway 自身并不具备这样的特性需要搭配 Eureka 这样组件它们更像服务路由器的角色。分布式配置左边和中间的四种技术均为 Spring Cloud 分布式配置的底层存储其中 Git 为版本式配置而 JDBC 是从 Spring Cloud Edgware 版本开始支持提供更为通用和动态的配置源。这里我们又见到 Zookeeper 的声影从简化运维的角度可以利用 Zookeeper 即承担服务发现也作为分布式配置的基础设施。而最右边的 etcd 是最近非常火的 Kubernetes 分布式配置的 key-value 存储提供快速、简单、安全和可高的解决方案。服务熔断服务熔断也非常让开发人员联想到 Spring Cloud Hystrix 技术不过 Hystrix 并非与 Spring Cloud 强耦合当然 Dubbo 也能结合 Netflix Hystrix 框架提供服务熔断的能力后面部分将介绍 Dubbo 与 Hystrix 整合提升 Dubbo 服务熔断的能力。确切地说Dubbo 所提供的能力是集群容错包括 Failover 等模式。 Kong 也天然地支持服务熔断的能力所以它作为 API 网关的特性是全面的。链路跟踪以上链路跟踪的基础设施从左至右分别为 Zipkin、OpenTracing 以及 Jaeger三者的灵感均来自于 Google 论文 Dapper。相对而言Java 程序员可能更为熟悉 Zipkin因为它是 Spring Cloud Sleuth 首选方案提供客户端上报以及服务端聚合和 Dashboard 等功能。而 OpenTracing 和 Jaeger 是 CNCF 孵化项目前者属于开放的标准提供多语言的适配实现后者则由 Uber优步公司开发并开源的链路跟踪项目功能上与 Zipkin 类似不过它基于 GO 语言开发同时也提供 Java 客户端。OpenTracing 官网http://opentracing.io/jaeger 官网https://www.jaegertracing.io/服务监控服务监控与链路跟踪有所区别主要用于监控应用系统或业务的指标数据可能是健康阈值如 CPU 或 内存使用率也可以是业务指标如最近一小时的用户登录量。通常采用 Metrics 方式暴露可使用客户端推送或服务端拉取的方式传输 Metrics 信息到数据中心。通常 Metrics 数据与时间是存在对应关系因此基本上采用时序型数据库来存储如图中的 OpenTSDB。通常Java 微服务应用会选择 Spring Boot 框架作为基础设施如我之前设计的监控架构就采用了 Spring Boot OpenTSDB 后端存储基于 HBase。当时 Spring Boot Actuator Metrics 仅为简单的 Key Value 形式自然 OpenTSDB 是理想的选择。随着 Spring Boot 2.0 开始支持 Micrometer 之后使得 Spring Boot 的应用能够整合更多的 Micrometer 适配方案其中名气较大的就是图中间的 Prometheus它同样也是 CNCF 的孵化项目。当然服务监控不只是 Metrics 方式我所知道国内不少的公司采用了日志收集的方案并搭配 ELKElasticsearch, Logstash, Kibana 架构减少运维成本。假设您没有使用该方案或者仅使用了 Elasticsearch 的话无论哪种方案图形化界面的监控是必不可少的因此我推荐 Grafana该项目能够支持多种数据源包括前文提到的 OpenTSDB、Prometheus 以及 ElasticSearch 等。由此从数据采集、上报、聚合以及展示的特性上这些基础设施帮助 Cloud Native 应用构建服务监控的闭环。本议程介绍了一些 Cloud Native 技术设施接下里我们继续讨论 Cloud Native 架构选型。Cloud Native 架构选型CNCF 架构体系CNCF 体系作为目前最热门的架构选型之一基本上围绕着 Kubernetes 为中心而构建。个人认为Java 业界和 CNCF 体系并没有达成共识如服务网关CNCF 主打 Envoy而 Java 主要的方案为 Zuul 和 Spring Cloud Gateway。因此个人建议是密切的关注 CNCF 的发展不过个别孵化项目可以先行如 Prometheus 和 Jaeger 等。 至于 CNCF 与 Java 生态的整合和落地还得有待时日。Spring Cloud 架构体系实际上这个图片并非 Spring Cloud 组件架构而是将其整合在 Pivotal Cloud Foundry (PCF) 架构中。基本上Spring Cloud 功能组件均有所体现包括 Eureka、Hystrix、Ribbon 等。不过值得注意的是Spring Cloud Stream 是一套较为完整和抽象的流式编程框架屏蔽了底层传输介质不仅是消息服务如 Kafka、RabbitMQ 等。除此之外其他的组件可圈可点如 Eureka 在大规模运用中的卡顿问题、Ribbon 缺少权重、Zuul 连接数限制和资源消耗、服务调用受限于 Feign REST 协议限制等。如果在小规模场景使用以上限制或问题不明显可以说 Spring Cloud 完全能够适任。不过差不多两年前我曾在不同的公开场合讲过”Spring Boot 易学难精Spring Cloud 能用但不成熟“。当时很多人觉得我“离经叛道”然而这句话并非空穴来风是我这几年来 Java 微服务架构实施的心得。这两年来深受 Spring Cloud “折磨”的小伙伴逐渐觉醒慢慢地开始回到 Dubbo 等技术方案。如 Martin Fowler 在为“微服务”下定义时提到通讯协议要用轻量级的 REST。假设微服务要做到服务无关的话那么 Web Services 协议也是可以尽管它看起来比较重不过 Web Services 的结构化和强类型可以省去不少的运行时校验逻辑。在我看来微服务更大程度应该体现在服务粒度上诚如 Netflix 前架构师 Adrian Cockcroft 说言“Fine grain SOA”微服务就是细粒度的 SOA就这一点而言比较容易地和业界达成共识。当我们把 Martin 的话视如圭臬时我们是否要思考它是否经得起工程检验。这里我没有兴趣贬低他人来抬高自己Dubbo从而引导让大家放弃 Spring Cloud而是我们需要给 Spring Cloud 时间包括未来 Dubbo 也会向 Spring Cloud 靠拢并整合。在阿里的内部基于 Nacos马上开源的项目和 Apache RocketMQ实现了 Spring Cloud Service Discovery、Config 以及 Stream 等整合和适配一旦时机成熟可能会开源与大家共建。既然谈到了 Dubbo下面我们再来讨论 Dubbo 的架构体系。Dubbo 架构体系编程模型方面不但支持传统的 Spring XML 配合方式已经实现注解驱动以及外部化配置并且全面支持最新的 Spring Boot 2.0在不久的未来大家会看到 Dubbo 与 Spring Cloud 的整合使开发人员无缝地衔接已有的 Spring Cloud 应用。Dubbo Spring Boot 项目地址https://github.com/apache/incubator-dubbo-spring-boot-project注册中心方面Dubbo 将整合 Eureka、etcd 以及 Consul 基础设施深度与业界热门方案整合。熔断机制方面Dubbo 会在近期发布 Hystrix 整合实现将编程友好性做得最大化。通讯协议方面Dubbo 将会支持 gRPC、Thrift 等热门通讯协议。至于序列化协议自然首先考虑的是 Protobuf因其高层 gRPC 搭配 HTTP/2 快成或已经成为下一代通讯协议的事实标准使得任何人无法忽视它们的存在。当然其他协议也会陆续支持。其他方面我这里就不一一介绍总之现在 Dubbo 已不再只是一个单一的 PRC 框架而是要拥抱业界形成完整的生态体系与业界形成最大公约数。Dubbo Cloud Native 准备在 Dubbo 架构体系时我们曾提到编程模型的变化。从 Dubbo 2.5.8 开始注解驱动和外部化配置均已得到支持。同时Dubbo 已经合并 Dubbox 代码Java JAX-RS 标准得到了支持目前业界事实的 REST 标准 Spring Web MVC 正在同步开发。Reactive 的支持也在同步进行小马哥还得友好地提醒一下各位对于 Reactive 的期望不应该过分的关注性能的提升。Dubbo 注解驱动Annotation-Driven在 Dubbo 2.5.7 之前的版本 Dubbo 提供了两个核心注解 Service 以及 Reference分别用于Dubbo 服务提供和 Dubbo 服务引用。其中Service 作为 XML 元素 dubbo:service 的替代注解与 Spring Framework org.springframework.stereotype.Service 类似用于服务提供方 Dubbo 服务暴露。与之相对应的 Reference则是替代dubbo:reference 元素类似于 Spring 中的 Autowired。2.5.7 之前的Dubbo与早期的 Spring Framework 2.5 存在类似的不足即注解支持不够充分。注解需要和 XML 配置文件配合使用如下所示?xml version1.0 encodingUTF-8? beans xmlns:xsihttp://www.w3.org/2001/XMLSchema-instancexmlns:dubbohttp://code.alibabatech.com/schema/dubboxmlnshttp://www.springframework.org/schema/beansxsi:schemaLocationhttp://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsdhttp://code.alibabatech.com/schema/dubbo http://code.alibabatech.com/schema/dubbo/dubbo.xsddubbo:application nameannotation-provider/dubbo:registry address127.0.0.1:4548/dubbo:annotation packagecom.alibaba.dubbo.config.spring.annotation.provider//beans不仅如此当时的版本存在“ Service Bean 不支持 Spring AOP” 以及 “Reference 不支持字段继承性” 等问题。从 2.5.7 开始Dubbo 开始引入组件扫描 Annotation DubboComponentScan借鉴了 Spring Boot 1.3 引入的 ServletComponentScan。在职责上DubboComponentScan 相对于 Spring Boot ServletComponentScan 更为繁重原因在于处理 Dubbo Service 类暴露 Dubbo 服务外还有帮助 Spring Bean Reference字段或者方法注入 Dubbo 服务代理。在场景上Spring Framework ComponentScan 组件扫描逻辑更为复杂。而在 DubboComponentScan只需关注 Service 和 Reference 处理。注更多 Dubbo 注解驱动的详情请参考《Dubbo 注解驱动Annotation-Driven》DubboComponentScan 服务端示例假设服务提供方和服务消费分均依赖服务接口DemoService:package com.alibaba.dubbo.demo;public interface DemoService {String sayHello(String name);}服务提供方实现DemoService - AnnotationDemoService同时标注 Dubbo Service package com.alibaba.dubbo.demo.provider;import com.alibaba.dubbo.config.annotation.Service; import com.alibaba.dubbo.demo.DemoService;/*** Annotation {link DemoService} 实现** author a hrefmailto:mercyblitzgmail.comMercy/a*/ Service public class AnnotationDemoService implements DemoService {Overridepublic String sayHello(String name) {return Hello , name;}}服务端 Configuration Classpackage com.alibaba.dubbo.demo.config;import com.alibaba.dubbo.config.ApplicationConfig; import com.alibaba.dubbo.config.ProtocolConfig; import com.alibaba.dubbo.config.RegistryConfig; import com.alibaba.dubbo.config.spring.context.annotation.DubboComponentScan; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration;/*** 服务提供方配置** author a hrefmailto:mercyblitzgmail.comMercy/a*/ Configuration DubboComponentScan(com.alibaba.dubbo.demo.provider) // 扫描 Dubbo 组件 public class ProviderConfiguration {/*** 当前应用配置*/Bean(dubbo-annotation-provider)public ApplicationConfig applicationConfig() {ApplicationConfig applicationConfig new ApplicationConfig();applicationConfig.setName(dubbo-annotation-provider);return applicationConfig;}/*** 当前连接注册中心配置*/Bean(my-registry)public RegistryConfig registryConfig() {RegistryConfig registryConfig new RegistryConfig();registryConfig.setAddress(N/A);return registryConfig;}/*** 当前连接注册中心配置*/Bean(dubbo)public ProtocolConfig protocolConfig() {ProtocolConfig protocolConfig new ProtocolConfig();protocolConfig.setName(dubbo);protocolConfig.setPort(12345);return protocolConfig;} }服务提供方引导类package com.alibaba.dubbo.demo.bootstrap;import com.alibaba.dubbo.demo.DemoService; import com.alibaba.dubbo.demo.config.ProviderConfiguration; import org.springframework.context.annotation.AnnotationConfigApplicationContext;/*** 服务提供方引导类** author a hrefmailto:mercyblitzgmail.comMercy/a*/ public class ProviderBootstrap {public static void main(String[] args) {// 创建 Annotation 配置上下文AnnotationConfigApplicationContext context new AnnotationConfigApplicationContext();// 注册配置 Beancontext.register(ProviderConfiguration.class);// 启动上下文context.refresh();// 获取 DemoService BeanDemoService demoService context.getBean(DemoService.class);// 执行 sayHello 方法String message demoService.sayHello(World);// 控制台输出信息System.out.println(message);}}DubboComponentScan 客户端示例消费服务 DemoServicepackage com.alibaba.dubbo.demo.consumer;import com.alibaba.dubbo.config.annotation.Reference; import com.alibaba.dubbo.demo.DemoService;/*** Annotation 驱动 {link DemoService} 消费方** author a hrefmailto:mercyblitzgmail.comMercy/a*/ public class AnnotationDemoServiceConsumer {Reference(url dubbo://127.0.0.1:12345)private DemoService demoService;public String doSayHell(String name) {return demoService.sayHello(name);} }消费端 Configuration Class与服务提供方配置类似服务消费方也许 Dubbo 相关配置 Bean - ConsumerConfigurationpackage com.alibaba.dubbo.demo.config;import com.alibaba.dubbo.config.ApplicationConfig; import com.alibaba.dubbo.config.RegistryConfig; import com.alibaba.dubbo.config.spring.context.annotation.DubboComponentScan; import com.alibaba.dubbo.demo.consumer.AnnotationDemoServiceConsumer; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration;/*** 服务消费方配置** author a hrefmailto:mercyblitzgmail.comMercy/a*/ Configuration DubboComponentScan public class ConsumerConfiguration {/*** 当前应用配置*/Beanpublic ApplicationConfig applicationConfig() {ApplicationConfig applicationConfig new ApplicationConfig();applicationConfig.setName(dubbo-annotation-consumer);return applicationConfig;}/*** 当前连接注册中心配置*/Beanpublic RegistryConfig registryConfig() {RegistryConfig registryConfig new RegistryConfig();registryConfig.setAddress(N/A);return registryConfig;}/*** 注册 AnnotationDemoServiceConsumerDubboComponentScan 将处理其中 Reference 字段。* 如果 AnnotationDemoServiceConsumer 非 Spring Bean 的话* 即使 DubboComponentScan 指定 package 也不会进行处理与 Spring Autowired 同理*/Beanpublic AnnotationDemoServiceConsumer annotationDemoServiceConsumer() {return new AnnotationDemoServiceConsumer();}}服务消费方引导类package com.alibaba.dubbo.demo.bootstrap;import com.alibaba.dubbo.demo.config.ConsumerConfiguration; import com.alibaba.dubbo.demo.config.ProviderConfiguration; import com.alibaba.dubbo.demo.consumer.AnnotationDemoServiceConsumer; import org.springframework.context.ApplicationContext; import org.springframework.context.annotation.AnnotationConfigApplicationContext;/*** 服务消费端引导类** author a hrefmailto:mercyblitzgmail.comMercy/a*/ public class ConsumerBootstrap {public static void main(String[] args) {// 启动服务提供方上下文startProviderContext();// 启动并且返回服务消费方上下文ApplicationContext consumerContext startConsumerContext();// 获取 AnnotationDemoServiceConsumer BeanAnnotationDemoServiceConsumer consumer consumerContext.getBean(AnnotationDemoServiceConsumer.class);// 执行 doSayHello 方法String message consumer.doSayHello(World);// 输出执行结果System.out.println(message);}/*** 启动并且返回服务消费方上下文** return AnnotationConfigApplicationContext*/private static ApplicationContext startConsumerContext() {// 创建服务消费方 Annotation 配置上下文AnnotationConfigApplicationContext consumerContext new AnnotationConfigApplicationContext();// 注册服务消费方配置 BeanconsumerContext.register(ConsumerConfiguration.class);// 启动服务消费方上下文consumerContext.refresh();// 返回服务消费方 Annotation 配置上下文return consumerContext;}/*** 启动服务提供方上下文*/private static void startProviderContext() {// 创建 Annotation 配置上下文AnnotationConfigApplicationContext providerContext new AnnotationConfigApplicationContext();// 注册配置 BeanproviderContext.register(ProviderConfiguration.class);// 启动服务提供方上下文providerContext.refresh();}}Dubbo 外部化配置Externalized Configuration在Dubbo 注解驱动例子中无论是服务提供方还是服务消费方均需要转配相关配置Bean Beanpublic ApplicationConfig applicationConfig() {ApplicationConfig applicationConfig new ApplicationConfig();applicationConfig.setName(dubbo-annotation-consumer);return applicationConfig;}虽然实现类似于ProviderConfiguration 和 ConsumerConfiguration 这样的 Spring ConfigurationBean 成本并不高不过通过 Java Code 的方式定义配置 Bean或多或少是一种 Hard Code硬编码的行为缺少弹性。尽管在 Spring 应用中可以通过 Value 或者 Environment 的方式获取外部配置其代码简洁性以及类型转换灵活性存在明显的不足。因此Spring Boot 提出了外部化配置External Configuration的感念即通过程序以外的配置源动态地绑定指定类型。随着 Spring Boot / Spring Cloud 应用的流行开发人员逐渐地接受并且使用 Spring Boot 外部化配置External Configuration即通过 application.properties 或者 bootstrap.properties 装配配置 Bean。下列表格记录了 Dubbo 内置配置类配置类标签用途解释ProtocolConfigdubbo:protocol/协议配置用于配置提供服务的协议信息协议由提供方指定消费方被动接受ApplicationConfigdubbo:application/应用配置用于配置当前应用信息不管该应用是提供者还是消费者ModuleConfigdubbo:module/模块配置用于配置当前模块信息可选RegistryConfigdubbo:registry/注册中心配置用于配置连接注册中心相关信息MonitorConfigdubbo:monitor/监控中心配置用于配置连接监控中心相关信息可选ProviderConfigdubbo:provider/提供方配置当 ProtocolConfig 和 ServiceConfig 某属性没有配置时采用此缺省值可选ConsumerConfigdubbo:consumer/消费方配置当 ReferenceConfig 某属性没有配置时采用此缺省值可选MethodConfigdubbo:method/方法配置用于 ServiceConfig 和 ReferenceConfig 指定方法级的配置信息ArgumentConfigdubbo:argument/参数配置用于指定方法参数配置通过申明对应的 Spring 扩展标签在 Spring 应用上下文中将自动生成相应的配置 Bean。在 Dubbo 官方用户手册的“属性配置”章节中dubbo.properties 配置属性能够映射到 ApplicationConfig 、ProtocolConfig 以及 RegistryConfig 的字段。从某种意义上来说dubbo.properties也是 Dubbo 的外部化配置。注更多外部化配置的详情请参考《Dubbo 外部化配置Externalized Configuration》现场演示环节本环境为分享后部分现在编码 演示环境当前文字仅提供代码实现。Dubbo 整合 Hystrix 示例本示例出现在分享议程的代码演示将其放置此处方便阅读理解Dubbo 客户端实现实现 HystrixCommandpublic class ResultHystrixCommand extends HystrixCommandResult {private final Invoker? invoker;private final Invocation invocation;public ResultHystrixCommand(Invoker? invoker, Invocation invocation) {super(HystrixCommandGroupKey.Factory.asKey(ResultHystrixCommand),100); // 设置超时时间// 关联 Dubbo Invoker 和 Invocationthis.invoker invoker;this.invocation invocation;}Overrideprotected Result run() throws Exception {// 远程方法调用执行return invoker.invoke(invocation);} }当目标方法执行时间超过 100 ms 时触发熔断并抛出 new UnsupportedOperationException(No fallback available.)。Dubbo Filter 整合 ResultHystrixCommandActivate(group Constants.CONSUMER, value hystrix) // 命名当前 Filter 为 hystrix public class HystrixFilter implements Filter {Overridepublic Result invoke(Invoker? invoker, Invocation invocation) throws RpcException {return new ResultHystrixCommand(invoker, invocation).execute();} }创建并配置 Filter SPI 配置文件在相对于 ClassPath 资源 META-INF/dubbo/ 下创建 com.alibaba.dubbo.rpc.Filter并配置如下hystrixcom.alibaba.boot.dubbo.demo.consumer.filter.HystrixFilter配置 Reference filter 属性RestController public class DemoConsumerController {Reference(version ${demo.service.version},application ${dubbo.application.id},url dubbo://localhost:12345,filter hystrix // 指向 HystrixFilter 实现)private DemoService demoService;RequestMapping(/sayHello)public String sayHello(RequestParam String name) {return demoService.sayHello(name);}}Dubbo 服务端实现服务提供者实现Service(version ${demo.service.version},application ${dubbo.application.id},protocol dubbo,registry ${dubbo.registry.id} ) public class DefaultDemoService implements DemoService {private final Random random new Random();public String sayHello(String name) {hold();return Say : Hello, name (from Spring Boot);}private void hold() { // 随机等待 200 ms当时间超过 100 ms 时触发客户端熔断long time random.nextInt(200);System.out.println(To hold time ms!);try {Thread.sleep(time);} catch (InterruptedException e) {Thread.currentThread().interrupt();}}}测试客户端 REST 服务依次启动服务端 和客户端 Spring Boot 应用执行 curl 命令mercyblitz$ curl http://localhost:8080/sayHello?nameHello测试结果{timestamp:2018-06-23T01:33:58.6820000,status:500,error:Internal Server Error,message:ResultHystrixCommand timed-out and no fallback available.,path:/sayHello}运行结果说明服务端方法执行超过 100 ms引起客户端熔断。原文链接本文为云栖社区原创内容未经允许不得转载。