Dubbo

一、分布式简介 1、架构简介 现在的互联网，几乎常见的复杂系统都会使用分布式架构，如果在不清楚概念之前，刚接触分布式架构这个名词会感觉十分的高大上，其实在对比单服务，集群服务之后，你就会发现本质上都是一样的。 絮叨一句 ：所谓Java架构师，基本就是看被单服务，集群，分布式不断暴打的频率，架构师因为被虐频率高，自然做出来的系统架构坑少，新手不能做架构的原因，所以你该懂的。 言归正传，分布式架构对于Java开发来说基本算是分水岭，能不能从开发层面跳出来，就看你工作个三五年之后，对分布式系统理解到什么程度。单服务应用，基于单服务做集群化部署，这种操作运维可以自行搭建环境，所以基本对能力要求不算高。但是如何设计出弹性、配置化、分布化、高性能、高容错、安全的分布式系统，的确是一件很有挑战的事情。 2、集群和分布式 首先需要理清楚单服务，集群，分布式这几种不同架构的区别。 单服务和集群 一张图，你品，你细品： 业务体量小，所有服务和应用部署在一台服务上，节省成本，这是单服务结构。当业务量逐渐增大，把一台服务进行水平扩展，做一个服务群，每台服务称为集群的一个节点，到这就是集群服务。集群服务要面对的一个问题就是：请求分配，自然需要一个调度组件来均衡服务器压力，这也被称为负载均衡。 补刀一句 ：做到集群模式的应用，在程序员面试的时候已经会被拿来做高格调的自吹自擂了，其实单服务和集群的本质区别就是

现在疫情已经好转很多，相信现在很多朋友都已经复工了，但也有很多人都面临失业或想要跳槽的情况，不管那种情况金三已经过去了，银四已经过半了， 你将作何准备迎接这个找工作季节呢？ 倘若你打算在现在换工作的话，那样做为1个Java工程师，应当怎样使用一个月的时间，迅速的为即将来临的招聘面试开展充足的准备呢？ 站在面试官的角度： 给大伙儿深入分析了平日互联网企业是怎样多方位的考察1个候选人的。 小结下去，面试官调查候选人的时候首要是从技术广度、技术深度、基本功底、系统设计、项目经验好多个角度来开展的。 这么本文我们就对于每一大块内容，主要的来讲一下调查的许多点。更关键的，是对于调查的那些点，怎样来迅速的做好准备。 一、技术广度 技术广度，说白了，你做为1个及格的工程师在开发设计1个系统，进行某些实际的技术任务的时候，必定是要采用到许多的技术的， 并且对于那些技术还必须熟练掌握有些十分普遍，各类不一样的系统或者都会涉及的一些技术构架/技术方案。 举例说明： 1个互联网企业的较为关键的系统，首要毫无疑问会采用分布式服务框架 例如：dubbo/spring cloud，那样都可以将系统拆分成分布式的架构，换句话说如今很流行的讲法是微服务架构，那样一个人负责一个服务并且是一个子系统。 紧接着这一系统很可能为了支撑某些独特的技术性情景会采用别的各类技术。

刚刚签下拼多多不久，目前已经入职了一段时间，适应下来感觉还不错，现在才想起是不是要分享一波面经。实际上在拼多多之前我是很想进BAT一线大厂的，毕竟大部分的程序员心里都有大厂梦。但是，阿里的面试让我的心是凉了半截，比较打击人。具体是一个什么情况，看下面的面经和总结吧！ 含泪面试阿里P6凉凉，最终拿下PDD主力研发岗（面试题+复习笔记） 01 含泪面试阿里P6凉凉（3轮技术面挂） 面试阿里之前是非常有信心的，听闻阿里不在乎学历，不少在职员工都是大专出身，所以作为普通本科毕业的我才有这份勇气，下了这个决心。面试前两面时，还算是顺利，所以早早就在窃喜，原以为能够顺利拿下offer，但在第三面居然被吊打，不得不叹服：不愧是第一的互联网公司。（以下附面试题） 自我介绍+项目介绍 项目中你相比于别人的优势在哪里，就是你用了别人没有的东西。 看你提到了连接池，druid连接池。 常见排序算法 TCP三次握手，四次挥手。 数据库引擎对比，索引 看你搞ACM，你给我讲个简单的数据结构 怎么保证多线程操作的原子性。 深入问了乐观锁，悲观锁及其实现。 zookeeper锁，数据库隔离级别。 docker隔离部署问题。 taobao查询排序要考虑那些因素？ 你觉得你的能力大概在什么方面？ 你是如何进行学习的？ 画一个软件的执行流程。 有没有写过开发文档。 Java怎么加载类。 Linux常用命令。 MVC

　　我们知道，微服务不是独立的存在，否则就不需要微服务这个架构了，那么当发起一次请求，如何知道这次请求的轨迹，或者说遇到响应缓慢、 请求出错的情况，我们该如何定位呢？这就涉及到APM(Application Performance Management)组件了，主流的选型有Zipkin、Pinpoint、Jaeger、 Skywalking，我在VehicleAdmin项目中试用了Dubbo+Zipkin组合，但发现当服务既是生产者又是消费者时有不兼容问题，于是我在此做了个Dubbo+ Skywalking的演示版本，仅供参考。 原创文章，谢绝一切形式转载，违者必究！ 准备 ： Idea2019.03/Gradle6.0.1/Maven3.6.3/JDK11.0.4/Lombok0.28/SpringBoot2.2.4RELEASE/mybatisPlus3.3.0/Soul2.1.2/Dubbo2.7.5/Druid1.2.21/ Zookeeper3.5.5/Mysql8.0.11/Redis5.0.5/Skywalking7.0.0 难度 ： 新手 --战士--老兵--大师 目标 ： Skywalking做微服务链路监控 步骤 ： 为了遇见各种问题，同时保持时效性，我尽量使用最新的软件版本。 源码地址：https://github.com/xiexiaobiao

在RPC框架中，粘包和拆包问题是必须解决一个问题，因为RPC框架中，各个微服务相互之间都是维系了一个TCP长连接，比如dubbo就是一个全双工的长连接。由于微服务往对方发送信息的时候，所有的请求都是使用的同一个连接，这样就会产生粘包和拆包的问题。本文首先会对粘包和拆包问题进行描述，然后介绍其常用的解决方案，最后会对Netty提供的几种解决方案进行讲解。这里说明一下，由于oschina将“jie ma qi”认定为敏感文字，因而本文统一使用“解码一器”表示该含义 1. 粘包和拆包 产生粘包和拆包问题的主要原因是，操作系统在发送TCP数据的时候，底层会有一个缓冲区，例如1024个字节大小，如果一次请求发送的数据量比较小，没达到缓冲区大小，TCP则会将多个请求合并为同一个请求进行发送，这就形成了粘包问题；如果一次请求发送的数据量比较大，超过了缓冲区大小，TCP就会将其拆分为多次发送，这就是拆包，也就是将一个大的包拆分为多个小包进行发送。如下图展示了粘包和拆包的一个示意图： image.png 上图中演示了粘包和拆包的三种情况： A和B两个包都刚好满足TCP缓冲区的大小，或者说其等待时间已经达到TCP等待时长，从而还是使用两个独立的包进行发送； A和B两次请求间隔时间内较短，并且数据包较小，因而合并为同一个包发送给服务端； B包比较大，因而将其拆分为两个包B_1和B_2进行发送

前言: 最近不知道为啥老是听到有人说裸辞裸辞，裸辞需要勇气啊，特别是现在这种环境下，跳槽可是难上加难，个人是不建议裸辞的，除非你对自己有信心能快速的找到下一家更适合你的公司，还有就是口袋里有钱，像我这种没钱的，裸辞是不可能裸辞的，这辈子都不可能裸辞的，还是好好学习，不打无准备的仗会来的靠谱些。所以今天给大家分享近千道面试题，希望大家都能准备充分，顺利拿下offer。 面试题 不会做的不要着急，文末有答案分享 MyBatis 面试题 什么是 Mybatis？ Mybaits 的优点： MyBatis 框架的缺点： MyBatis 框架适用场合： MyBatis 与 Hibernate 有哪些不同？ #{}和${}的区别是什么？ 当实体类中的属性名和表中的字段名不一样 ，怎么办 ？ 模糊查询 like 语句该怎么写? 通常一个 Xml 映射文件，都会写一个 Dao 接口与之对应，请问，这个 Dao 接口的工作原理是什么？Dao 接口里的方法，参数不同时，方法能重载吗？ Mybatis 是如何进行分页的？分页插件的原理是什么？ Mybatis是如何将sql执行结果封装为目标对象并返回的？都有哪些映射形式？ 如何执行批量插入? 如何获取自动生成的(主)键值? 在 mapper 中如何传递多个参数? Mybatis 动态 sql 有什么用？执行原理？有哪些动态 sql？ Xml 映射文件中

因为涉及到springmvc、mybatis的集成，为了使项目编码更简洁易用，这边将基础的BASE进行封装，其中包括：BaseBean、BaseDao、BaseService、CRUD的基础封装、分页组件的封装、mybatis的mapper的基础封装，各种数据源支持的封装等。 1. BaseEntity基础封装，代码如下： /** * Entity基础封装 */ public abstract class BaseEntity<T> implements Serializable { private static final long serialVersionUID = 1234567890987654321L; /** * 实体编号（唯一标识） */ protected String id; /** * 当前实体分页对象 */ protected Page<T> page; /** * 是否插入新纪录 */ protected boolean isNewRecord = false; public BaseEntity() { } public BaseEntity(String id) { this(); this.id = id; } public String getId() { return id; } public void setId(String id) {

zookeeper是一个开源的分布式协调框架：数据发布订阅，负载均衡，集群，master选举。 原子性：要么同时成功，要么同是失败（分布式事务） 单一视图：无论客户端连接到哪个服务器，所看到的模型都是一样的 可靠性：一旦服务器端提交了一个事务并且获得了服务器端返回成功的标识，那么这个事务所引起的服务器端的变更会一直保留 实时性：近实时性 zookeeper不是用来存储数据的，通通过监控数据状态的变化，达到基于数据的集群管理。 会话状态： NOT_CONNECTED CONNECTING CONNECTED CLOSED 数据模型-->树形结构 最小的数据单元为ZNODE zab协议：客户端发了一个事务请求给到了leader，而leader发送给各个follower以后，并且收到了ack，leader已经commit，在准备ack给各个follower节点commit的时候，leader挂了，怎么处理。 1）选举新的leader（zxid的最大值） 2）同步给其他的follower watcher： eventyType None 客户端和服务端成功建立会话 NodeCreated 节点创建 NodeDeleted 节点删除 NodeDataChanged 数据变更，数据内容 NodeChildrenChanged 子节点发生变更：子节点删除新增的时候才会触发，变更不会触发

Dubbo 通过注册中心在分布式环境中实现服务的注册与发现，而注册中心通常采用 ZooKeeper，研究注册中心相关源码绕不开 ZooKeeper，所以学习了 ZooKeeper 的基本概念以及相关 API 操作。 ZooKeeper 相关概念 session 客户端与服务端采用 TCP 长连接，服务端在为客户端创建 Session 会分配一个唯一 sessionId。在 Session timeout 时间内，客户端可以向服务端发送请求以及接受 watcher 事件通知。 数据结构 Zookeeper 将所有数据存储在内存中，数据模型是一棵树（Znode Tree)，由斜杠（/）的进行分割的路径，就是一个Znode，例如/foo/path1。 Znode Znode 将会保存数据内容以及相关属性信息。在 Znode 中使用 Stat 数据结保存相关属性信息。Stat 属性中有三种版本信息，分别为 version：当前节点版本信息，cversion:当前节点子节点版本，aversion 当前节点的 ACL 版本。每次发生改动，版本数值将会单调递增。 更新，删除 Znode 可以传入版本数值，如果版本数值不对，将会导致删除/更新失败，这个特性类似于 CAS 操作。 Znode 有以下几种类型： 永久节点 一旦创建，将会一直存在，除非手动删除。dubbo 目录节点为永久节点。 临时节点

Dubbo工具——dubbo-monitor监控平台的发布和使用 1）下载 https://github.com/alibaba/dubbo/archive/dubbo-2.5.8.zip 2）编译 cmd中进入解压后的目录,然后运行mvn install。然后到E:\incubator-dubbo-dubbo-2.5.8\dubbo-simple\dubbo-monitor-simple\target目录下复制出dubbo-monitor-simple-2.5.8-assembly.tar.gz到e:/，然后解压该文件，得到如下目录： bin目录存放启动、关闭等命令。 conf配置文件。 lib依赖包。 配置 1）dubbo-monitor端配置 2）provider端配置 <!-- 添加监控中心 --> <dubbo:monitor protocol="registry"/> consumer端配置 <!-- 添加监控中心 --> <dubbo:monitor protocol="registry"/> 这样，在 provider、consumer运行的时候，通过该标签，会到注册中心找到dubbo-monitor这个服务。 4）启动dubbo-monitor之前dubbo-admin中的服务列表 运行测试 1）启动和关闭 到dubbo-monitor-home/bin