Dubbo

后端架构师图鉴 作者：星晴（当地小有名气，小到只有自己知道的杰伦粉） 忽略：我准备从博客园（ https://www.cnblogs.com/pingping-joe/ ）转移到公众号了！！！ 从2017年开始写博客到现在，经历了几家公司，碰到不少有趣的人，人也成长不少，褪去幼稚的面孔，只剩下越发后移的发际线；一路坎坷，唯一还在坚持的就只剩下写博客了，虽然不知道为什么坚持，但是感觉还不错。 今天第一天发公众号推文，作为搞java的，还是给大家准备了架构师的学习路线。当然如果大家都知道，可以忽略。 架构师学习路线大致分为五个部分： 互联网运维 Git，Maven，Gradle，jenkins，linux 框架源码分析 Spring , Mybatis 并发编程 并发包 性能调优 JVM调优，Mysql调优，Nginx调优，Tomcat调优 分布式框架 分布式服务治理：Dubbo, Zookeeper, SpringCloud-Alibaba,SpringCloud-NetFliex 分布式消息：RocketMq, RabbitMq, Kafka 分布式数据缓存：Redis 分布式数据存储：Sharding-sphere 分布式通信：Netty 分布式搜索引擎：ELK 如果想要完整的学习路线，请关注公众号，并且回复【1】，谢谢支持 本文分享自微信公众号 - 喜欢奶茶的星晴（code

前言 说来话长，从18年下半年开始，就有了离职的念头。但由于18年年初时答应项目经理要再待一年，所以强压下心头的邪念，坚持着一直做到年底。这期间身兼各种工作-提数、排查线上问题、给各个省公司的人答疑解惑、与其他部门联系沟通、做公司一个内部配置平台的前端页面的开发，唯一做的很少的就是后台开发，咳咳，实在汗颜。干了几个月后发现状况不对，急需提升自己的开发水平，于是开始看起JVM原理(第二遍看)、Spring源码、mybatis源码，顺便了解了不少mysql相关的知识，像不同引擎对应的索引结构、事务隔离级别、B+树等。就在不断地自我膨胀与自我怀疑中，满怀期待又惴惴不安地迎来了这一波面试。 面试过程 整个的面试过程满是曲折。从春节假期开始到二月底结束，持续的时间不长，一共也就面了五家。春节假期前是支付宝负责保险模块的部门，春节假之后是OYO酒店，再然后是平安健康险、河马，最后面的是G7物联网。 年前面的支付宝这次面试纯粹是个意外，还没投简历就不知为何被猎头找上了，联系了阿里，答应着春节之后会安排电话面试。没成想阿里的办事效率奇高，当天下午就给我打来电话要求电话面试一波。没啥好推拖的，我就硬着头皮开始了我人生中第一次的阿里面试，问的东西现在看来也能答个七七八八，但当时由于刚从工作中解放出来，很多基础的知识点没有复习基本只剩一点印象，面试时心跳加快，面红耳赤，在我们北方零下好几度的乡村里

dubbo功能非常完善，很多时候我们不需要重复造轮子，下面列举一些 你不一定知道，但是很好用 的功能； 直连Provider 在开发及测试环境下，可能需要绕过注册中心，只测试指定服务提供者，这时候可能需要点对点直连，点对点直连模式，将以服务接口为单位，忽略注册中心的提供者列表，A 接口配置点对点，不影响 B 接口从注册中心获取列表（说明：官方只建议开发&测试环境使用该功能），用法如下，url指定的地址就是直连地址： <dubbo:reference id= "demoService" interface = "com.alibaba.dubbo.demo.DemoService" version= "1.0.0" url= "dubbo://172.18.1.205:20888/" /> 多版本 当一个接口实现，出现不兼容升级时，可以用版本号过渡，版本号不同的服务相互间不引用，用法如下： <dubbo:service interface = "com.alibaba.dubbo.demo.DemoService" ref= "demoService" version= "1.0.0" /> 利用dubbo该特性，我们能够实现一些功能的灰度发布，实现步骤如下： 接口旧的实现定义version="1.0.0"，接口新的实现version="2.0.0"

简介： Java 的世界里，大家广泛使用的一个高性能网络通信框架 netty，很多 RPC 框架都是基于 netty 来实现的。在 golang 的世界里，getty 也是一个类似 netty 的高性能网络通信库。getty 最初由 dubbogo 项目负责人于雨开发，作为底层通信库在 dubbo-go 中使用。随着 dubbo-go 捐献给 apache 基金会，在社区小伙伴的共同努力下，getty 也最终进入到 apache 这个大家庭，并改名 dubbo-getty 。 作者 | 刘晓敏 于雨 一、简介 Java 的世界里，大家广泛使用的一个高性能网络通信框架 netty，很多 RPC 框架都是基于 netty 来实现的。在 golang 的世界里， getty 也是一个类似 netty 的高性能网络通信库。getty 最初由 dubbogo 项目负责人于雨开发，作为底层通信库在 dubbo-go 中使用。随着 dubbo-go 捐献给 apache 基金会，在社区小伙伴的共同努力下，getty 也最终进入到 apache 这个大家庭，并改名 dubbo-getty 。 18 年的时候，我在公司里实践微服务，当时遇到最大的问题就是分布式事务问题。同年，阿里在社区开源他们的分布式事务解决方案，我也很快关注到这个项目，起初还叫 fescar，后来更名 seata

小编这里可是有Java面试题参考答案的哟，需要各位小伙伴下来逐一学习！ 开场白 简单的介绍一下自己的工作经历与职责，在校或者工作中主要的工作内容，主要负责的内容；（你的信息一清二白的写在简历上，能答出来的最好写在上面，模棱两可不是很清楚的最好不要写，否则会被问的很尴尬） 介绍下自己最满意的，有技术亮点的项目或平台，重点介绍下自己负责那部分的技术细节；（主要对自己做过的事情是否有清晰的描述） Java基础 什么是字符串常量池？ String为什么是不可变的？ String s = new String("xyz");究竟产生了几个对象，从JVM角度谈谈？ String拼接字符串效率低，你知道原因吗？ 你真的了解String的常见API吗？ Java中的subString()真的会引起内存泄露么？ 浅析Java中的final关键字？ 浅析Java中的static关键字？ 你对Java中的volatile关键字了解多少？ i++是线程安全的吗？如何解决线程安全性？ 从字节码角度深度解析 i++ 和 ++i 线程安全性原理？ 请谈谈什么是CAS？ 从源码角度看看ArrayList的实现原理？ 手写LinkedList的实现，彻底搞清楚什么是链表？ Java中方法参数的传递规则？ Java中throw和throws的区别是什么？ 重载和重写的区别？ 手写ArrayList的实现

一、将war包丢进webapps 　　这是最简单粗暴的方式：将web工程打成war，丢进tomcat/webapps目录即可，tomcat会自动解压。 无需修改任何配置文件即可完成部署。 　　这里我准备了tomcat8.5.43与dubbo控制台的war包来做测试。 　　 　　①启动tomcat 　　②将war丢进webapps目录，tomcat会自动解压该war包。 　　 　　浏览器直接访问： localhost:8080/dubbo-admin-2.5.10 ，说明我们的war包部署成功！（ 访问路径为war包的名称 ） 二、配置Server.xml部署Web工程 　　修改配置文件无需我们打war，这样方便开发，结合 IDEA自动部署WEB工程至远程服务器（学习笔记） 可以实现快速开发。 　　编辑server.xml 　　 　　　添加如下：<Context docBase="D:\test\dubbo-admin-2.5.10" path="/test" reloadable="false" />（ 访问路径为path内容 ） 　　　 　　通过浏览器访问： localhost:8080/test 　　 三、添加xml方式部署Wweb工程 　　 在D:\test\apache-tomcat-8.5.43\conf\Catalina\localhost：添加testA.xml 　　

微服务化的基石——持续集成 转载： 刘超 http://dockone.io/article/3660 一、持续集成对于微服务的意义：拆之前要先解决合的问题 在很多微服务化的文章中，很少会把持续集成放在第一篇，因为大多数的文章都会将如何拆的问题，例如拆的粒度，拆的时机，拆的方式。 为什么需要拆呢？因为这是人类处理问题的本质方式：将一个大的复杂问题，变成很多个小问题解决。 所以当一个系统复杂到一定程度，当维护一个系统的人数多到一定程度，解决问题的难度和沟通成本大大提高，因而需要拆成很多个工程，拆成很多个团队，分而治之。 然而当每个子团队将子问题解决了，整个系统的问题就解决了么？你可以想象你将一辆整车拆成零件，然后再组装起来的过程，你就可以想象拆虽然不容易，合则更难，需要各种标准，各种流水线，才能将零件组装称为车。 我们先来回顾一下拆的过程。 最初的应用大多数是一个单体应用 一个Java后端，后面跟一个数据库，基本上就搞定了。 随着系统复杂度的增加，首先Java程序需要做的是纵向的拆分。 首先最外面是一个负载均衡，接着是接入的nginx，做不同服务的路由。 不同的服务拆成独立的进程，独立部署，每个服务使用自己的数据库和缓存，解决数据库和缓存的单点瓶颈。 数据库使用一主多从的模式，进行读写分离，主要针对读多写少的场景。 为了承载更多的请求，设置缓存层

前言： 在小企业或者一些小项目中，当网站流量很小时，只需一个应用，便能将所有功能都部署在一起，以减少部署节点和成本。但当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率，也就是我们常说的MVC垂直应用架构。可是当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。 此时，用于提高业务复用及整合的分布式服务框架(RPC) 是关键，Dubbo就在这种情况下应运而生。 由于本文不是重点介绍Dubbo和zookeeper的技术文章，如果想深入学习原理，请移步官网。 Dubbo官网：http: //dubbo.apache.org/ Zookeeper官网：http: //zookeeper.apache.org/ Dubbo建议使用Zookeeper作为服务的注册中心，本文作者在公司中也是使用Zookeeper，所以在偏向应用层面给大家介绍如何安装配置Zookeeper，为后续Dubbo的使用实例做铺垫。 废话了这么多，现在来介绍如何在Centos7上安装配置Zookeeper。 1、cd到/usr/local文件夹下，创建 /usr/local/zookeeper 文件夹： mkdir zookeeper 2、进入到 /usr/local

点击上方“ 程序员小灰 ”，选择“置顶公众号” 有趣有内涵的文章第一时间送达！ 本文转载自公众号 刘超的通俗云计算 一、持续集成对于微服务的意义：拆之前要先解决合的问题 在很多微服务化的文章中，很少会把持续集成放在第一篇，因为大多数的文章都会将如何拆的问题，例如拆的粒度，拆的时机，拆的方式。 为什么需要拆呢？因为这是人类处理问题的本质方式：将一个大的复杂问题，变成很多个小问题解决。 所以当一个系统复杂到一定程度，当维护一个系统的人数多到一定程度，解决问题的难度和沟通成本大大提高，因而需要拆成很多个工程，拆成很多个团队，分而治之。 然而当每个子团队将子问题解决了，整个系统的问题就解决了么？你可以想象你将一辆整车拆成零件，然后再组装起来的过程，你就可以想象拆虽然不容易，合则更难，需要各种标准，各种流水线，才能将零件组装称为车。 我们先来回顾一下拆的过程。 最初的应用大多数是一个单体应用 一个Java后端，后面跟一个数据库，基本上就搞定了。 随着系统复杂度的增加，首先Java程序需要做的是纵向的拆分。 首先最外面是一个负载均衡，接着是接入的nginx，做不同服务的路由。 不同的服务拆成独立的进程，独立部署，每个服务使用自己的数据库和缓存，解决数据库和缓存的单点瓶颈。 数据库使用一主多从的模式，进行读写分离，主要针对读多写少的场景。 为了承载更多的请求，设置缓存层

集群容错 容错主要是指服务出现了非业务异常之后采取的一些弥补措施，注意我这里讲的是非业务异常，因为业务异常出现的绝大多数情况都是代码异常，所以及时采取了重试等逻辑还是会出现一样的业务异常（代码出问题了，锅当然要自己背喽）。 Dubbo中对于容错的处理主要集中在Cluster中，Cluster包装了底层调用的Invoker并且在Cluster自己本层做了一些出现异常之后的处理。 对于Dubbo的容错主要是有两层。第一层是mock，第二层是用户配置的容错策略。对于集群容错的包装逻辑入口就在于RegistryProtocol的doRefer()方法最后的cluster.join(directory)，该方法返回了集群包装过后的invoker，这里的cluser其实就是MockClusterWrapper（至于为什么能确定是MockClusterInvoker，就需要大家去理解一下Dubbo的SPI机制了），下面一起来看一下MockClusterInvoke的具体内容： //真正起作用的是MockClusterInvoker public <T> Invoker<T> join(Directory<T> directory) throws RpcException { //因为cluster下面之后一层包装，所以这里的this.cluser就是默认的FialoverCluster