2021年Java中高级面试必备知识点总结
在这个部分总结了2019年到目前为止Java常见面试问题，取其面试核心编写成这份文档笔记，从中分析面试官的心理，摸清面试官的“套路”，可以说搞定90%以上的Java中高级面试没一点难度。
本节总结的内容涵盖了：消息队列、Redis缓存、分库分表、读写分离、设计高并发系统、分布式系统、高可用系统、SpringCloud微服务架构等一系列互联网主流高级技术的知识点。
目录：
（上述只是一个整体目录大纲，每个点里面都有如下所示的详细内容，从面试问题——分析面试官心理——剖析面试题——完美解答的一个过程）
部分内容：
对于每一个做技术的来说，学习是不能停止的，小编把2019年到目前为止Java的核心知识提炼出来了，无论你现在是处于什么阶段，如你所见，这份文档的内容无论是对于你找面试工作还是提升技术广度深度都是完美的。
不想被后浪淘汰的话，赶紧搞起来吧，高清完整版一共是888页，需要的话可以点赞+关注
什么组织适合使用微服务？
微服务带了种种优点，种种弊端，那么什么组织适合使用微服务？
墨菲定律（设计系统）和康威定律（系统划分）
康威定律，是一个五十多年前就被提出来的微服务概念。在康威的这篇文章中，最有名的一句话就是：
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967)
中文直译大概的意思就是：设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构。看看下面的图片（来源于互联网，侵删），再想想Apple的产品、微软的产品设计，就能形象生动的理解这句话。
康威定律
感兴趣的各位可以研究一下
架构演化
架构是不断演化出来的，微服务也是这样，当从各大科技公司，规模大到一定程度，完全需要演化成更进一步管理的技术架构体系。
康威定律
（字差，勿嫌）
传统的团队，都是面向过程化的，产品想完了去找策划，策划完了找开发，接着顺着一步一步找。我们做技术都是为了产品的，一旦过程出来了什么问题，回溯寻找问题会非常耗时。
康威定律
（字差，勿嫌）
使用了微服务架构体系，团队组织方式需要转变成跨职能团队，即每个团队都有产品专家，策划专家，开发专家，运维专家，他们使用API方式发布他们的功能，而平台使用他们的功能发布产品
DevOps
devops
微服务技术架构体系
下面我分享一下大部分公司都使用的微服务技术架构体系。
康威定律
（图差，勿嫌）
服务发现
主流的服务发现，分为三种
康威定律
第一种，开发人员开发了程序以后，会找运维配一个域名，服务的话通过dns就能找到我们对应的服务
缺点是，由于服务没有负载均衡功能，对负载均衡服务，可能会有相当大的性能问题。
康威定律
第二种，是目前普遍的做法。可以参考我上篇博客分析的zuul网关，每一个服务都通过服务端内置的功能注册到注册中心，服务消费者不断轮询注册中心发现对应的服务，使用内置负载均衡调用服务。
缺点是，对多语言环境不是很好，你需要单独给消费者的客户端开发服务发现和负载均衡功能。当然了，这个方法通常都是用在spring cloud上的。
康威定律
第三种，是将客户端和负载均衡放在同一个主机，而不是同一个进程内。
这种方法相对第一种第二种方法来说，改善了他们的缺点，但是会极大增加运维成本。
网关
微服务的网关是什么？
我们可以联系生活实际想一下。每一个大的公司，都会有一偏属于自己的建筑区，而这建筑区内，都有不少的门卫。如果有外来人员进入公司，会先和门卫打好招呼，才能进去。
将生活实际联系到微服务上，就不难理解网关的意思了。
网关有什么用
康威定律
-
反向路由：很多时候，公司不想让外部人员看到我们公司的内部，就需要网关来进行反向路由。即将外部请求转换成内部具体服务条用
-
安全认证：网络中会有很多恶意访问，譬如爬虫，譬如黑客攻击，网关维护安全功能。
-
限流熔断：参考我学好分布式zookepper的博客，当请求很多服务不堪重负，会让我们的服务自动关闭，导致不能用服务。限流熔断可以有效的避免这类问题
-
日志监控：所有的外面的请求都会经过网关，这样我们就可以使用网关来记录日志信息
-
灰度发布，蓝绿部署。是指能够平滑过渡的一种发布方式。在其上可以进行A/B testing，即让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。
开源网关Zuul架构
zuul架构
zuul网关核心其实是一个servlet，所有请求都会经过zuul servlet传到zuulFilter Runner，然后分发到三种过滤器。
先说说架构图左半部分，分别是使用Groovy实现的前置路由过滤器，路由过滤器，后置路由过滤器。
一般请求都会先经过前置路由过滤器 处理，一般的自定义java封装逻辑也会在这里实现。
路由过滤器 ，实现的是找到对应的微服务进行调用。
调用完了，响应回来，会经过后置路由过滤器 ，通过后置路由过滤器我们可以封装日志审计的处理。
可以说zuul网关最大的特色就是它三层过滤器。
架构图右半部分，是zuul网关设计的自定义过滤器加载机制。网关内部会有生产者消费者模型，自动的将过滤器脚本发布到zuul网关读取加载运行。
配置中心
以前，开发人员把配置文件放在开发文件里面，这样会有很多隐患。譬如，配置规范不同，无法追溯配置人员。一旦需要大规模改动配置，改动时间会很长，无法追溯配置人员，从而影响整个产品，后果是我们承担不起的。
因此就有配置中心这个喽~
现在的开源中心有_百度配置中心_ Disconf，spring cloud config，Apollo，今天重点说说现在应用质量不错的配置中心阿波罗。
携程开源的Apollo
开源地址???：https://github.com/ctripcorp/apollo
康威定律
apollo的配置中心规模比较大，本地应用会有响应的配置中心客户端，可以定时同步配置中心里的配置。如果配置中心怠机，会使用缓存来进行配置。
通讯方式
关于通讯方式，一般市面也就是两种远程调用方式，我整理了一个表格：
|
| RPC | REST |
| — | — | — |
| 耦合性 | 强耦合 | 松散耦合 |
| 消息协议 | TCP | HTTP |
| 通讯协议 | 二进制 | 文本XML，Json |
| 性能 | 高 | 低于RPC |
| 接口契约IDL | thrift,protobuf,IdL | Swagger |
| 客户端 | 强类型客户端，一般自动生成 | 一般HTTP可访问，生成强类型客户端，多语言支持好 |
| 案例 | Dubbo，Dubbox,motan,tars,grpc,thrift | spring boot,tax-rs,dropwizard |
| 开发者友好 | 客户端比较方面，二进制消息不能读 | 可读消息 |
| 对外开放 | 一般需要转成REST/文本协议 | 可直接对外开发 |
监控预警
监控预警对于微服务很重要，一个可靠的监控预警体系对微服务运行至关重要。一般监控分为如下层次：
康威定律
从基础设施到用户端，层层有监控，全方位，多角度，每一个层面都很重要。总体来说，微服务可分5个监控点：日志监控 ，Metrics监控 ，健康检查 ，调用链检查 ，告警系统
监控架构
下面的图是大部分公司的一种监控架构图。每一个服务都有一个agent，agent收集到关键信息，会传到一些_MQ_中，为了解耦。同时将日志传入_ELK_，将_Metrics_传入_InfluxDB_时间序列库。而像_nagios_，可以定期向agent发起信息检查微服务。
康威定律
调用链监控APM
很多公司都有调用链监控，就譬如阿里有鹰眼监控，点评的_Cat_，大部分调用链监控（没错，我指的Zipkin）架构是这样的???
康威定律
当请求进入Web容器的时候，会经过创建Tracer，连接spans（模拟潜在的分布式工作的延迟，该模块还包含在系统网络间传递跟踪上下文信息的工具包，如通过http headers）。Spans有一个上下文，其中包含tracer标识符，将其放在表示分布式操作的树的正确位置。当我们把图中的各种span放到后端的时候，我们的服务调用链会动态的生成调用链。
下面是一些市场上用的比较多的调用链监控：
1、Pinpoint github地址：GitHub - naver/pinpoint: Pinpoint is an open source APM (Application Performance Management) tool for large-scale distributed systems written in Java. 对java领域的性能分析有兴趣的朋友都应该看看这个开源项目，这个是一个韩国团队开源出来的，通过JavaAgent的机制来做字节码代码植入，实现加入traceid和抓取性能数据的目的。NewRelic、Oneapm之类的工具在java平台上的性能分析也是类似的机制。
2、SkyWalking github地址：wu-sheng/sky-walking 这是国内一位叫吴晟的兄弟开源的，也是一个对JAVA分布式应用程序集群的业务运行情况进行追踪、告警和分析的系统，在github上也有400多颗星了。功能相对pinpoint还是稍弱一些，插件还没那么丰富，不过也很难得了。
3、Zipkin 官网：OpenZipkin · A distributed tracing system github地址：GitHub - openzipkin/zipkin: Zipkin is a distributed tracing system 这个是twitter开源出来的，也是参考Dapper的体系来做的。
Zipkin的java应用端是通过一个叫Brave的组件来实现对应用内部的性能分析数据采集。Brave的github地址：github.com/openzipkin/… 这个组件通过实现一系列的java拦截器，来做到对http/servlet请求、数据库访问的调用过程跟踪。然后通过在spring之类的配置文件里加入这些拦截器，完成对java应用的性能数据采集。
4、CAT github地址：GitHub - dianping/cat: Central Application Tracking 这个是大众点评开源出来的，实现的功能也还是蛮丰富的，国内也有一些公司在用了。不过他实现跟踪的手段，是要在代码里硬编码写一些“埋点”，也就是侵入式的。这样做有利有弊，好处是可以在自己需要的地方加埋点，比较有针对性；坏处是必须改动现有系统，很多开发团队不愿意。
5、Xhprof/Xhgui 这两个工具的组合，是针对PHP应用提供APM能力的工具，也是非侵入式的。Xhprof github地址：GitHub - preinheimer/xhprof: XHGUI is a GUI for the XHProf PHP extension, using a database backend, and pretty graphs to make it easy to use and interpret. Xhgui github地址：GitHub - perftools/xhgui: A graphical interface for XHProf data built on MongoDB 我对PHP不熟，不过网上介绍这两个工具的资料还是蛮多的。
康威定律
熔断、隔离、限流、降级
最后
分布式技术专题+面试解析+相关的手写和学习的笔记pdf
还有更多Java笔记分享如下：
/img_convert/8ca9ff0c1a8711cdd12b3941971f3538.png)康威定律
熔断、隔离、限流、降级
最后
分布式技术专题+面试解析+相关的手写和学习的笔记pdf
还有更多Java笔记分享如下：
[外链图片转存中…(img-t7I1EcBb-1715242065270)]
893
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
