Dubbo

原文链接： https://copyfuture.com/blogs-details/20200629181409555v24mc4magq748ni 最近发现dubbo消费端一直报下面这样的error日志 06 - 17 15 : 56 : 50.749 ERROR default - [ orSendTimer - thread - 1 ] c . alibaba . dubbo . monitor . dubbo . DubboMonitor : [ DUBBO ] Unexpected error occur at send statistic , cause : No provider available from registry * . * . * . * : 端口 for service com . alibaba . dubbo . monitor . MonitorService on consumer 172. * . * .124 use dubbo version 2.8 .3 , please check status of providers ( disabled , not registered or in blacklist ) . , dubbo version : 2.8 .3 , current host : 172. * . * .124

摘要: 阿里巴巴前架构师对于微服务毫无保留的分享，360 度无死角剖析微服务 微服务是当前软件架构领域非常热门的词汇，在社区中也有很多热烈的讨论。因此，在 OSC 第 130 期高手问答 中，我们策划的主题是“究竟什么才是微服务”，并邀请了 黄勇 作为高手嘉宾。 黄勇 ，现任特赞公司 CTO，曾任阿里巴巴公司系统架构师。对微服务架构与大数据技术有深入研究，具有丰富的网站架构设计经验与项目管理经验，擅长敏捷开发模式。国内开源软件推动者之一，活跃于“开源中国”社区网站，Smart 开源框架创始人，图书《架构探险：从零开始写Java Web框架》、《轻量级微服务架构（上册）》作者。热爱技术交流，乐于分享自己的工作经验与生活感悟。 微服务是近年来备受关注的话题，它的出现让我们想起了十年前的 SOA（Service-Oriented Architecture，面向服务架构），但它比传统的 SOA 更容易理解，也更容易实践，它将“面向服务”的思想做得更加彻底。 尤其是当国外的一些知名技术公司成功实践了微服务以后，这股热潮就吹遍了国内的大街小巷，我们也看到很多的项目使用了微服务，但实际上依然有不少朋友对于微服务有着不少疑惑。 因此本篇文章，会介绍与微服务架构相关的一些基础概念、适用场景以及如何解决在实践中遇到的问题等内容。 一、与微服务相关的一些基本概念 我以前做过微服务，基本框架是

不少单位已经开始复工了，跳槽季已经开始。虽说大多数互联网企业，像腾讯、字节跳动等，都已经开通远程面试环节，而且薪资有走高的趋势。但据目前看，面试难度大了许多，甚至有朋友面试后怀疑：自己真的落伍了？ 比如，面试高级开发岗位时，面试官不仅考察基础能力，更会重点考察高并发、分布式等架构相关的技术背后的思考逻辑，比如：微服务，负载均衡，Redis，RPC等。（今年 Java 面试到底聚焦在知识点？文末扫码获取） 但这些技术包含了 N 多优化、N 多细节，对于一些 coding 的朋友，由于接触不到一线实战架构设计，想必并不是很了解。 刚好，趁着这段时间，整理了一套 “ 微服务+分布式 ” 的视频干货，讲解很透彻。今天分享给大家。这份资料 尤其适合 以下人群： 1.没有用过微服务技术，只会用传统的 SSM 框架 2.用过 Spring Cloud、Dubbo等技术，但是只限于使用，遇到问题基本无法解决 3.从来没有系统学习微服务、分布式架构，觉得架构设计是遥不可及的 4.对于微服务、分布式技术有所了解，但尚没有设计高可用高并发的实践经历 学完这份视频你将获得哪些收获？ 理解当下最火热的微服务架构原理及其开源框架； 触及一线大厂所配备的微服务核心技术内幕知识； 对照自己掌握知识点进行查漏补缺，帮助扫除知识盲区、重构知识体系。 视频围绕“ 如何设计高可用高并发的微服务架构？ ”的主题

最近，O’Reilly 公布了一份关于企业微服务市场现状的数据调研。报告显示，在访问了全球 1,502 名软件工程师、系统和技术架构师、工程师以及决策者后，有 77％ 的组织反馈采用了微服务，其中 92％ 的组织成功使用了微服务。 如果以这份报告为依据，微服务在企业的普及率已接近八成。看起来，企业对微服务的兴趣可能已经接近顶峰。 云原生的基础设施从设计上保证了它是微服务部署的最佳平台，但是也对现有的微服务框架带来了新的挑战 ，在云原生大行其道的今天： 我们对微服务还应该继续投入精力关注吗？ 云原生和微服务之间的关系是什么？ 随着 Serviece Mesh 等技术的不断成熟，微服务的体系和思想会产生怎样的演化？ Spring Cloud、Dubbo 还会继续作为微服务开发框架的继续流行下去吗？ 容器、Kubernetes、ServiceMesh、Serverless 这些云原生时代的主角，会如何助力下一代微服务架构为业务发展赋能？ 这些问题值得每一位技术从业人员去思考，并发现由此带来的企业数字化转型升级新挑战、新机遇。也许有同学会说：“上个阶段微服务架构的问题都还没解决，又来了个‘云原生时代的微服务’，我这从哪儿开始学起啊？” 来，从这儿开始！ 2020 云原生微服务大会 为推动云原生下的微服务技术发展和实践交流，由阿里云主办的首届“云原生微服务大会”将于 2020 年 8 月

为了方便大家理解我把之前方案的图片复制过来了，如下： 上图的方案存在一个问题，就是我们今天文章要聊的内容。 这个问题就是当 MQ Consumer 收到消息后，就直接发布 Event 了，如果是同步的，没有问题。如果某个 EventListener 中处理失败了，那么这条消息将不会 ACK。 如果是异步发布 Event 的场景，发布完消息马上就 ACK 了。就算某个 EventListener 中处理失败了，MQ 也感知不到，不会进行消息的重新投递，这就是存在的问题。 解决方案 方案一 既然消息已经 ACK 了，那就不利用 MQ 的重试功能了，使用方自己重试是不是也可以呢？ 可肯定是可以的，内部处理是否成功肯定是可以知道的，如果处理失败了可以默认重试，或者有一定策略的重试。实在不行还可以落库，保存记录。 这样的问题在于太烦了呀，每个使用的地方都要去做这件事情，而且对于未来接手你代码的程序小哥哥来说，这很有可能让小哥哥头发慢慢脱落啊。。。。 脱落不要紧，关键他还不知道要做这个处理，说不定哪天就背锅了，惨兮兮。。。。 方案二 要保证消息和业务处理的一致性，就不能立马进行 ACK 操作。而是要等业务处理完成后再决定是否要 ACK。 如果有处理失败的就不应该 ACK，这样就能复用 MQ 的重试机制了。 分析下来，这就是一个典型的异步转同步的场景。像 Dubbo 中也有这个场景

金融行业正在流淌着一股去IOE，去集中化的IT架构转型洪流。我有幸参与到这股洪流中，见证这一重大变革。以下是我对这股洪流的一些思考和想法。 1.当前主流金融的IT架构 众所周知，目前大部分金融机构的IT架构还是以“IOE”的IBM大小型机，Oracle数据库，EMC存储为基础的集中式架构。这种架构有以下优点： 成熟度高 可靠性高 可用性高 这些产品目前承载着世界上众多金融行业的核心系统，而这些产品的厂家在这个领域有几十年的积累，产品的成熟度，可靠性，可用性可见一斑。 不过这种架构也有三大缺点： 第一个就是成本高。硬件，软件，服务都价格不菲。这些费用在金融机构躺着赚钱的时代还是可以接受的，但是在现在以及未来瞬息万变的时代，金融机构的经营形势会越发趋紧，那么这一块IT架构支出就会成为金融机构的负担。 第二个就是IOE的东西都是黑盒，其核心科技就像一个迷。万一再来一个类似“棱镜门”，“华为门”的“IOE门”，金融IT架构的处境可想而知。虽说可能性不大，但是不怕一万就怕万一。所以，自主可控才不会受制于人。 第三个就是可扩展性较差。这种架构无法做到快速，无限制的扩展。之前也提到，未来是瞬息万变的时代，消费模式会从工厂生产什么，消费者消费什么的模式转变到消费者海量碎片化需求主导的模式。那么IT架构需要能支持随时扩展以便适应业务的快速发展。 2.新金融的IT架构 为了避免集中式架构的三大缺点

从毕业到现在已经快4年啦，一直在Java的WEB开发行业混迹。我不是牛人，但是自我感觉还算是个合格的程序员，有必要写下自己将近4年来的经历，给自我以提示，给刚入行的朋友提供点参考。 貌似这一点适应的行业最广，但是我可以很肯定的说：当你从事web开发一年后，重新找工作时，才会真实的感受到这句话。 工作第一年，往往是什么都充满新鲜感，什么都学习，冲劲十足的一年；WEB行业知识更新特别快，今天一个框架的新版本，明天又是另一个新框架，有时往往根据项目的需要来不断学习新东西；所有，很多时候感觉，自己用过的东西真多呀！但是真正深入研究的东西却不多。 面试，是跳槽后第一个需要面对的问题；而且不同公司面试的着重点不同；但是却有一个共同点：Java基础是必考的。工作第一年，可能问你String对象创建的理解，常用的框架是什么等等；工作第二年，就问你Java内存分配机制是什么，类是如何加载的等等；第三年，就问你常用的设计模式是什么，你在工作中充当什么角色，怎么独立完成一个模块等等； 可以看出------这是一个典型的程序员的成长过程： 使用Java---->深入理解Java积累经验------>独立设计分析能力------>独当一面的多面手！ 因此，必须学习： 列举一些技术 比如对集合类，并发包，IO/NIO，JVM，内存模型，泛型，异常，反射，等有深入了解，最好是看过源码了解底层的设计

序 本文主要研究一下dubbo-go的availableCluster NewAvailableCluster dubbo-go-v1.4.2/cluster/cluster_impl/available_cluster.go type availableCluster struct{} const available = "available" func init() { extension.SetCluster(available, NewAvailableCluster) } // NewAvailableCluster ... func NewAvailableCluster() cluster.Cluster { return &availableCluster{} } NewAvailableCluster方法实例化availableCluster Join dubbo-go-v1.4.2/cluster/cluster_impl/available_cluster.go func (cluser *availableCluster) Join(directory cluster.Directory) protocol.Invoker { return NewAvailableClusterInvoker(directory) }

目前的dubbo已支持和springboot集成，还是之前的 例子 ，这次我们通过springboot容器来实现。借此了解一下基于springboot容器启动的dubbo的配置及使用。 1. 准备工作 创建一个Maven空项目，作为项目的父工程，此工程的子项目基于Spring Boot 2.0.5 实现 在父工程的pom.xml引入之后要创建的子工程 < modules > < module > gmall-interface </ module > < module > user-service-provider </ module > < module > order-service-consumer </ module > </ modules > 可以提前看一下工程结构 下面分别来实现子工程：（子工程的实现方式都是在gmall工程下新建Module） 2. 公共API 项目中共用的接口和POJO类，代码和之前一样，这里不再展开 3. 服务提供者 工程结构如下 引入依赖 <!-- 引入公共API,以实现其接口 --> < dependency > < groupId > com.zang </ groupId > < artifactId > gmall-interface </ artifactId > < version > 1.0-SNAPSHOT </ version

趣图 产品经理设计体验/用户实际体验 ↓ ↓ ↓ 分享几个珍藏已久的 IDEA 的「骚技巧」，助你快速完成代码。 还等什么？赶紧上车吧...... 前进/后退 我们使用浏览器的过程，可以点击后退查看之前的浏览记录。在 IDEA 也有同样的功能，当我们编辑代码时，点击查看了调用类实现逻辑，然后可以使用后退快捷键，快速回到刚才待编辑的代码处。 有后退，当然也有前进啦~ 前进/后退快捷键如下： Windows:Ctrl + Alt + Left/Right（方向键） Mac: ⌘ + ⌥ + ← / →(方向键) 示意图如下： 查看历史记录 还是以浏览器为例，当我们已经点击很多网页，这时想查看之前看过一个网页，使用后退就会很费劲，需要一个个回退过去查找。这种情况下，直接从历史记录查看将会变得很高效。 同样的，IDEA 也提供类似的功能查看历史文件,并且在弹出窗口内可以使用关键键快速查找。 快捷键如下： Windows：ctrl + E Mac：⌘ +E 另外 IDEA 中还有可以查看最近修改代码的位置，直接点击快速跳转。 快捷键如下： Windows：ctrl + shift + E Mac：⌘ + ⇧ +E 小技巧 讲到这里，建议大家设置一个选项，限制标签页（Edit Tabs）数量。 默认情况下， Tab Limit 为 10，标签页只能打开 10 个，对于会按照打开顺序关闭。