Dubbo

概要： Dubbo 快速入门 Dubbo 常规配置说明 一、Dubbo 快速入门 Dubbo核心功能解释 dubbo 阿里开源的一个SOA服务治理框架，从目前来看把它称作是一个RPC远程调用框架更为贴切。单从RPC框架来说，功能较完善，支持多种传输和序列化方案。所以想必大家已经知道他的核心功能了：就是远程调用。 快速演示Dubbo的远程调用 实现步骤 [ ] 创建服务端项目 [ ] 引入dubbo 依赖 [ ] 编写服务端代码 [ ] 创建客户端项目 [ ] 引入dubbo 依赖 [ ] 编写客户端调用代码 dubbo 引入： <dependency> <groupId>com.alibaba</groupId> <artifactId>dubbo</artifactId> <version>2.6.2</version> </dependency> dubbo 默认依懒： 客户端代码： static String remoteUrl = "dubbo://127.0.0.1:12345/tuling.dubbo.server.UserService"; // 构建远程服务对象 public UserService buildRemoteService(String remoteUrl) { ApplicationConfig application = new

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 前言   随着瓜子业务的不断发展，系统规模在逐渐扩大，目前在瓜子的私有云上已经运行着数百个 Dubbo 应用，上千个 Dubbo 实例。瓜子各部门业务迅速发展，版本没有来得及统一，各个部门都有自己的用法。随着第二机房的建设，Dubbo 版本统一的需求变得越发迫切。几个月前，公司发生了一次与 Dubbo 相关的生产事故，成为了公司 基于社区 Dubbo 2.7.3 版本升级的诱因。   接下来，我会从这次线上事故开始，讲讲我们这段时间所做的 Dubbo 版本升级的历程以及我们规划的 Dubbo 后续多机房的方案。 一、Ephermal节点未及时删除导致provider不能恢复注册的问题修复 事故背景   在生产环境，瓜子内部各业务线共用一套zookeeper集群作为dubbo的注册中心。2019年9月份，机房的一台交换机发生故障，导致zookeeper集群出现了几分钟的网络波动。在zookeeper集群恢复后，正常情况下dubbo的provider应该会很快重新注册到zookeeper上，但有一小部分的provider很长一段时间没有重新注册到zookeeper上，直到手动重启应用后才恢复注册。 排查过程   首先，我们统计了出现这种现象的dubbo服务的版本分布情况，发现在大多数的dubbo版本中都存在这种问题

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 序 本文主要研究一下dubbo的ClassLoaderFilter ClassLoaderFilter dubbo-2.7.2/dubbo-rpc/dubbo-rpc-api/src/main/java/org/apache/dubbo/rpc/filter/ClassLoaderFilter.java @Activate(group = CommonConstants.PROVIDER, order = -30000) public class ClassLoaderFilter implements Filter { @Override public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException { ClassLoader ocl = Thread.currentThread().getContextClassLoader(); Thread.currentThread().setContextClassLoader(invoker.getInterface().getClassLoader()); try { return invoker.invoke(invocation); } finally

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 原文地址 1、搭建zookeeper集群环境 这个在上上上个文章中已经详细描述了 点击查看 2、通过dubbo-admin（dubbo后台管理系统） 查看dubbo 提供者和消费者等 dubbo-admin-2.5.3.war 点击下载就好 下载完毕之后找一个tomcat 将该war包解压缩，然后修改里面的 \tomcat7-dubbo\webapps\ROOT\WEB-INF\dubbo.properties 修改 dubbo.registry.address=zookeeper://192.168.1.211:2181?backup=192.168.1.212:2181,192.168.1.213:2181 其他的不用修改，然后直接启动tomcat就好了。由于我tomcat设定的端口是80 并且我讲dubbo-admin 放到了ROOT下，所以我直接在浏览器中录入localhost就可以访问了。 用户名root 密码root（刚才在那个配置文件夹中的password 就是这个root 用户的密码） 进入之后可以在里面各种点点看一下。 3、咱们直接上源码来解释： 点击查看下载 下载完毕之后，主要说一下provider 和consumer 关于dubbo.xml的配置文件 provider： <!--

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> docker pull chenchuxin/dubbo-admin:latest docker run -d \ -p 18080:8080 \ -e dubbo.registry.address=zookeeper://192.168.30.137:2181 \ -e dubbo.admin.root.password=root \ -e dubbo.admin.guest.password=guest \ --name dubbo-admin chenchuxin/dubbo-admin 运行成功后，稍等一下，访问 ip:port 即可。 默认账号密码是 管理员： root ： root 游客： guest ： guest 来源： oschina 链接： https://my.oschina.net/fufangchun/blog/3154303

转眼已经2020，距离微服务这个词落地已经过去好多年！（我记得2017年就听过这个词）。然而今天我想想什么是微服务，其实并没有一个很好的定义。为什么这样说，按照微服务的定义： 微服务架构就是将一个庞大的业务系统按照业务模块拆分成若干个独立的子系统，每个子系统都是一个独立的应用，它是一种将应用构建成一系列按业务领域划分模块的，小的自治服务的软件架构方式，倡导将复杂的单体应用拆分成若干个功能单一、松偶合的服务，这样可以降低开发难度、增强扩展性、便于敏捷开发，及持续集成与交付活动。 根据这个定义，不难看出其实就是对复杂的业务系统统一做逻辑拆分，保持逻辑上的独立。那么逻辑上独立就是一个服务这样做真的是好吗，如何界定：小、独，还有要做一个事情，完成单一的业务，单一的功能要拆分出来，为了独立而独立会不会导致拆的过细？不同人有不同的见解，我们今天一起探讨微服务的过去和未来。 微服务缘起 在没有微服务之前，我们最早的架构模式就是 MVC 模式，把业务逻辑分为：表示层，业务逻辑层，数据访问层。MVC模式随着大前端的发展，从一开始的前后端不分离，到现在的前后端分离逐渐演进。这种演进好的一点是剥离了不同开发语言的开发环境和部署环境，使得开发较为便利，部署更直接。然而问题是：这种模式仍然是单体应用模式，如果有一个改动需要上线，你不得不因为这个改动去考虑更多

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 分布式架构的演进 系统架构演化历程-初始阶段架构 初始阶段 的小型系统 应用程序、数据库、文件等所有的资源都在一台服务器上通俗称为LAMP 特征： 应用程序、数据库、文件等所有的资源都在一台服务器上。 描述： 通常服务器操作系统使用linux，应用程序使用PHP开发，然后部署在Apache上，数据库使用Mysql，汇集各种免费开源软件以及一台廉价服务器就可以开始系统的发展之路了。 系统架构演化历程-应用服务和数据服务分离 好景不长，发现随着系统访问量的再度增加，webserver机器的压力在高峰期会上升到比较高，这个时候开始考虑增加一台webserver 特征： 应用程序、数据库、文件分别部署在独立的资源上。 描述： 数据量增加，单台服务器性能及存储空间不足，需要将应用和数据分离，并发处理能力和数据存储空间得到了很大改善。 系统架构演化历程-使用缓存改善性能 特征： 数据库中访问较集中的一小部分数据存储在缓存服务器中，减少数据库的访问次数，降低数据库的访问压力。 描述： 系统访问特点遵循二八定律，即80%的业务访问集中在20%的数据上。 缓存分为本地缓存和远程分布式缓存，本地缓存访问速度更快但缓存数据量有限，同时存在与应用程序争用内存的情况。 系统架构演化历程-使用应用服务器集群 在做完分库分表这些工作后

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 序 转眼之间2019年就要过去了，又是到了写总结的时候了。 盘点 去年定了要深入研究流式计算及系统架构，现在看来，流式计算只粗略看了点flink，系统架构方面貌似也没有太多的长进，文章也写的越来越像流水账了，感觉有点惭愧。 展望 新的一年在新技术方面要研究容器化，在基础方面也得巩固一下linux、network等，最后在架构领域方面也要有新的长进。 文章导航 flink 聊聊flink的window操作 聊聊flink的Tumbling Window 聊聊flink的Sliding Window 聊聊flink的Session Window 聊聊flink的Global Window 聊聊flink的Triggers 聊聊flink的Evictors 聊聊flink的Allowed Lateness 聊聊flink的consecutive windowed operations 聊聊flink DataStream的join操作 聊聊flink KeyedStream的intervalJoin操作 聊聊flink DataStream的window coGroup操作 聊聊flink DataStream的connect操作 聊聊flink DataStream的split操作 聊聊flink

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 在上篇在讲解RegistryDirectory的时候，dubbo管理员可以通过dubbo-admin管理系统在线上修改dubbo服务提供者的参数，最终将存储在注册中心的configurators catalog，然后通知RegistryDirectory更新服务提供者的URL中相关属性，按照最新的配置，重新创建Invoker并销毁原来的Invoker。 有关官方文档关于动态改变配置(override协议）的详细描述如下： dubbo-admin 管理后台，界面如下： 当Dubbo管理人员在上述界面，选择配置后点击保存，会构建override:// url存入到注册中心(configurators) catalog下，此时基于注册中心发现服务提供者的监听器(RegistryDirectory)会收到回调(notify)方法，接下来我们再来看一下RegistryDirectory#notify方法。 RegistryDirectory#notify public synchronized void notify(List<url> urls) { // @1 List<url> invokerUrls = new ArrayList<url>(); List<url> routerUrls = new

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 平日里，都是看别人的文章，虽开公众号写了不少，但像样的不多。年末了，年终总结也没来得及写，为了输出点像样的东西，立刻就着手这个系列。<span style="color:orangered;">一个键一个字母的敲，边敲边写，文章还在持续更新中，直至完整。</span>相信通过这个系列的系统练习，能有一个大跨步的提升。 专栏简介（是什么？） 结合SpringCloud、SpringCloudAlibaba、Dubbo等开源套件，基于某商场停车业务需求，进行微服务开发实战，力争通过一个案例的实操，掌握微服务架构中常用的技能点，轻松入门。 为什么要写这个专栏（为什么？） 微服务近两年的火热，也将很多公司的架构慢慢转向微服务，但要直接上手微服务，还需要能过实操演练，不断提升，才能在工作中游刃有余。 网络上相关资源很多，但大多散乱无章，不成体系，不利于系统性掌握，无法一步步的深入其中，更不能深刻掌握各个组件在项目中实际融合情况。 虽然也有一些案例，但缺少相关的文档细节描述，对初学者而言，仅靠阅读代码，难免会一知半解。于是，我就琢磨写一个贴合实际场景的小例子，业务无须很复杂，能将这一套技术体系串连起来，自己可以跟着动手实操，通过一步一步的上手，加深对技术栈的理解。 通过本专栏要达成什么目标（到哪里去？）