YourBatman

熟练使用IntelliJ IDEA，是一个高手该有的样子

IntelliJ IDEA的Project和Module详解

20张动图，上下动的那种；还有1.2w文字

20岁已不再年轻，却又风华正茂

Date的七宗罪

跨时区转换，你会了吗？

送你，收好，不谢

2万字，呕心沥血收藏

20张图，看完不会，就来砍我

做得巧，自然做得好

Date日期、JSR 310日期、数字、百分数、钱币格式化大一统

2020很艰难，2021更艰难（文末阳光普照奖）

收藏此文，JDK的格式化体系就全部搞定了

框架设计复杂度，暴露给使用者的话你就输了

再见了Netflix，你好Spring Cloud

指引着你和我，穿过拥挤的人潮

Converter、ConverterFactory、GenericConverter

篇幅不短，内容很全

文末附：Spring主要版本发布时间。Spring前身：interface21

UI重新设计，debug调试器的增强是最爱

你的字符串，有很多话要说

万字长文解释此次升级，因为未来已来

普通家庭马化腾，不知妻美刘强东；悔创阿里杰克马，北大还行撒贝宁；

想当团队中最靓的仔？来本文看看

5.x主版的最后一个功能分支，官方建议你赶紧升级

天下苦Spring Cloud版本命名久矣

1024，撸起袖子继续干

你发任你发，我用Java8。

了解核心组件，就算站稳脚跟

面向规范接口编程，爽到飞起

Jackson安全漏洞：CVE-2020-24616

声明式校验，契约编程，助你写出更简洁、更健壮的代码

掌握Bean Validation，能很大程度减少你写重复、垃圾代码

按位与、或、非、异或、左移、右移、无符号右移

别只会一股脑的String -> POJO了，Jackson优雅灵活的树模型你值得拥有

简单数据绑定 vs 完全数据绑定 vs 泛型类型绑定

一件事情本身的复杂度并不会凭空消失，而是从一个地方转移到另外一个地方

IntelliJ IDEA 20岁了，献礼它的第二个大版本（含之前版本破解）

写：遵循规范；读：兼容并包

你，还学得动吗？

多少钱算财务自由？如何才能财务自由，教你三种实用方式

底层原理，jackson-core核心模块JsonGenerator流式API高效写JSON

关于JSON库，我只用世界最好的

你为何用Fastjson？你为何仍在用Fastjson？

来自硅谷大佬，对依赖注入Dependency Injection的很简约易懂的解释

技术选型，不少技术从业的朋友容易进一些误区，而这些误区大多俗话是某种技术开发思维定势在作

IDEA踩坑系列提一篇：助你减少排雷时间，聚焦于写代码吧

Spring依赖注入static静态成员（属性、方法），这里的坑谁用谁知道

static关键字提升配置类的优先级，带你领略为何Spring Boot搞出那么多静态内部类

一个static关键字在Spring的使用，竟能写出一个专栏

Spring Boot刚发布了2.3.0版本，好基友Spring Cloud还没跟上

Spring配置类专栏的总结篇，绘制流程图，适合需快速掌握的白嫖党

Spring配置类专栏研究得最深的一篇，不为别的，只为涨薪

95%的coder只停留在应用，你愿意当那5%吗？本文就是这个个B格的文章

Spring配置的Full模式和Lite模式如何区分？本文用源码塞给你

Spring配置类的Lite模式和Full模式，一锅全端走

来自一个大龄程序员的坎坷职业生涯：作者万字自述

一方面了解了A哥的“创作背景”；另一方面，当然也是最主要的便是我们已经初步了解了`Spring Cloud Context`工程，并且对它的`spring.factories`文件做了介绍，从中是能窥探出SC的核心组成“元素”的。天若有情天亦老，人间正道是沧桑。接下来会进入到“枯燥乏味”的修行当中，坚持下来的都是英雄。准备深入去了解Spring Cloud，`BootstrapApplicationListener`无疑是它的第一入口，然而在这之前，我们依旧需要扫除一些“障碍”。

你对Spring Framework的了解程度决定了你对Spring Boot的了解程度，你对Spring Boot的了解程度决定了你对Spring Cloud的了解程度。了解我文章的小伙伴应该知道，到目前为止A哥还几乎没有写过`Spring Boot/Spring Cloud`的文章，虽然写了不少关于`Spring Framework`的内容，但仍旧被不少小伙伴认为与时代脱节。都什么年代了，谁还会直接使用Spring Framework呢？是的没毛病

关于Spring Boot最主要的类的生命周期，此篇文章值得收藏

本文是个纯代码示例的手工活，是对前两篇文章一个很好的总结。了解A哥的风格是清楚的：理论先行，代码示例跟上加固。我们从小学就知道学习需要**多看、多想、多做(多实现)**，代码更是如此。在现在信息大爆炸时代，大多数人对“多看”做的都挺好，但是殊不知：**看和做往往是有一道银河的距离的**。所以A哥在此顺道呼吁一句：敲代码一定要多动手多动手多动手，否则你很容易只会纸上谈兵，也就容易离它渐行渐远。既然你看到了本系列文章，那么A哥就管生管养喽，本文将手把手的教你，如何纯手工控制的把Ribbon和Eureka整合

上篇文章A哥给大家介绍了Ribbon和Eureka的整合工程的部分内容，建立在你已经对Eureka比较熟悉的基础上，从中定能窥探出它的好处以及关键整合点。不过A哥想说，上篇文章的介绍只是开胃小菜，本文介绍内容才是重中之重。

`Ribbon`作为客户端负载均衡器，有一个必要的基础条件就获取到`ServerList`服务器列表，以及后续的动态更新服务列表。通过前面学习知道，服务列表它可以来自**任何地方**，比如默认实现`ConfigurationBasedServerList`它表示服务列表可以来自于配置（文件）。实际生产中，我们不可能把ServerList地址写死在配置里，实际的方式是把**Ribbon同注册中心整合**从而从注册中心里获取到列表，并且动态的去sync服务列表。服务注册中心有多种，本文将讲述它和自家产品Eu

Netflix OSS是由Netflix公司主导开发的一套代码框架/库，目的是用于解决大规模集群的分布式系统的一连串问题，如：服务发现、负载均衡、熔断降级、限流、网关等等。对于当代的Java开发者来说，`Netflix OSS`似乎已经成为了云端开发/微服务开发解决方案的代名词。**有些人把Spring Cloud和Netflix画了等号，这虽然是不对的，但足矣见得`Netflix OSS`它在微服务解决方案中的地位**。时至今日的2020年，虽说旗下众多工程已经进入到停更维护状态，但因为它悠久的历

上篇文章主要介绍了`Archaius`和`Spring Cloud`的整合工程`spring-cloud-starter-netflix-archaius`的内容，本文将继续，会将站在**实用的角度**，深度分析`ArchaiusAutoConfiguration`该自动配置类到底做了哪些事，以及最后给出具体代码示例来体会一把Spring环境抽象`Enviroment`和`Archaius`整合的效果。你可带着疑问阅读本文：为何Ribbon、Hystrix明明是使用`Archaius`管理自己的配置，而

顺序：意思是依次而不乱。顺序在生活的方方面面都显得尤为重要，自然的它对**程序执行**来说也是至关重要的。有了顺序的保证，我们就能对“结果”做出预期，作为coder的我们对应的也就更能“掌控”自己所写代码，心里也就更加踏实。顺序固然重要，但是不乏有些场景它是不需要顺序保证的。**一般来说**：无序的效率会比顺序高，毕竟保证顺序是需要花费资源的（人力、物理、时间...）。本文将主要讨论**Spring在实例化Bean时的顺序性**，以及我们如何才能“控制”这种顺序呢？

调整配置的顺序，如是而已

Archaius是一个配置管理库，其重点是来自多个配置存储的动态属性。它包括一组用于Netflix的Java配置管理API。它主要实现为`Apache Commons Configuration`库的扩展。提供的主要功能有：1. 动态、类型属性2. 高吞吐量和线程安全的配置操作3. 一个轮询框架，允许用户获取对配置源的属性更改4. ...5. 对于愿意使用**基于约定的**属性文件位置的应用程序(以及大多数web应用程序)，提供开箱即用的**复合配置**（这是强大功能之一），对于符合配置官网给了一

回想一下，在本系列第一篇文章就有提到过，Eureka它是使用轻量级DI框架：谷歌的Guice来管理其依赖的。通过前面这么多篇文章的学习，有理想相信亲们已经了解了Eureka几乎每个组件的作用以及**它们的依赖关系**。即使如此，但若现在要你构件其一个**完整可用**的Eureka Client客户端，你觉得呢？相信拿到这个“题目”的感觉和我是一样的：我去，这也太麻烦了吧，组件这么多，框架依赖关系还一层一层的错综复杂，难点并不是因为它困难，而是很麻烦。是的，这是每一个稍大型软件均会遇见的难题：类/组件多了

上坡的路都是累的设置难受的，要控制好自己的情绪。–> 返回专栏总目录 <–代码下载地址：https://github.com/f641385712/netflix-learning目录前言正文详解String#intern()源码(native代码)参阅代码示例总结前言继上篇文章分享了Eureka内置的一个小工具RateLimiter限流器后，本文继续分享其另外一个实用小...

关于**基于令牌桶**的限流器实现，我想最出名的当属Google开源项目Guava中的`RateLimiter`了吧，它具有非常强大的功能特点，使用也非常的方便。但本文介绍的不是Google家族的`RateLimiter`，而是Eureka自己实现的一个工具`RateLimiter`，它虽然功能没Google的那么强大，但实现了最为核心的功能，所以还是值得学习和使用的。

关于`DiscoveryClient`这一个类的解析竟然已经到了第8篇了，经过了前7篇高密度的讲述，主体内容其实已经基本完成了，但正所谓“革命尚未统一”，就差本文临门一脚。接下来将会把其余下内容：接口方法的实现进行讲述清楚便算大功告成，并且对其最为重要的`shutdown()`方法进行一个详细的介绍。本文内容简单易懂，`shutdown()`方法实用性较强，相信会是一段颇为愉快的“旅程”。

本文接着上篇文章的讲解，继续深入`DiscoveryClient`初始化阶段剩下的两个步骤：`register()`注册当前实例和`initScheduledTasks()`初始化调度任务。

在通过前面几篇文章介绍`DiscoveryClient`后，对它的核心内容已经有了较为深入的理解，此刻你基本可以放心的对自己说：对Eureka（client端）已经了解到了7、8成了。但作为一个有态度、有追求的程序员，我们可以更优秀。本文将结合前几篇所述内容作为铺垫，深入挖掘`DiscoveryClient`初始化过程中几个大步骤的细节，进入精雕细琢阶段，包括它对“众多”任务的组织和启动，掌握其要领方得安心。

DiscoveryClient中有两个非常重要的内部类：`HeartbeatThread`和`CacheRefreshThread`，他俩是调度任务中真正干活的两个**任务类**，因此单摘出来放在一起讲述一把，防止迷路。另外，前面有篇文章专门介绍了实例复制器`InstanceInfoReplicator`，它也用于周期性对当前实例进行注册。那么你是否疑问：它和`HeartbeatThread`有什么区别和联系呢？本文也会进行对比

继上篇文章介绍了对注册表的全量获取后，本文来到注册表获取的主菜：Delta增量获取。增量操作并不少见，在MySql、Redis等里都有所体现，它一种轻量级方式实现，好处不言而喻。如果说全量获取是初级程序员，那么增量获取怎么也算高工了。增量获取属于精细化操作，它需要考虑的因素众多，因此处理起来也就会复杂一些。

Eureka属于c-s的设计模式，Client端本地需要维护一份注册表信息，因此它需要周期性的去远程Server端获取，这种获取注册表的方式有两种：**全量获取和增量获取**。全量获取：顾名思义，**大而全**是它的特点，通信上属于一种相对较重的操作。增量获取：每次仅获取**发生了变化的数据**，通信轻量，但缺点是落地逻辑复杂，需要client + server端共同协作实现。本文将先重点介绍全量获取的实现。

千呼万唤始出来。自从官方在2020-01-20发布了其**2020年的Roadmap**，我便持续关注着、期待着它“新10年”的首个版本的发布，这不就在**昨天(2020-04-09)**发布了其“新10年”的首个版本：`IntelliJ IDEA 2020.1`。按照国际惯例，作为大版本号的升级，一般都会“搞点事情”，而事实确实如此（包括了支持中文哦）。

主要介绍了`DiscoveryClient`的成员属性，达30+个之多。我们发现其成员属性中，绝大多数否是final修饰，也就是说他们大多均得在`DiscoveryClient`初始化阶段完成赋值，由此你也能感受到它初始化的“压力”。确实，`DiscoveryClient`的初始化阶段是它，**甚至是整个Eureka Client**最为重要的逻辑片段之一，属于掌握Eureka一定、必须精通的知识点。在上文已经了解了它的成员属性以及含义后，本文在其基础上继续深入，深入讲解`DiscoveryClient

说到`DiscoveryClient`，很多小伙伴对它望而却步。那么从此篇开始，**正式**进入Eureka Client端最深水区内容，同时它也是最难啃的一块骨头：`DiscoveryClient`。由于本类过于庞大且复杂，我会分拆为多篇文章逐步讲解，势必要达到完全掌握的目的。了解一个类，就从它的**成员属性**开始吧。本文将对`DiscoveryClient`的众多成员属性做详尽解释，相信通过本文你也能大概了解到它的全貌了。

上篇文章介绍了`DiscoveryClient`服务注册时使用到的一个小工具`InstanceInfoReplicator`，其实它也属于前置知识。本文继续此部分的内容，为详细了解Eureka Client端最重要API `DiscoveryClient`做好铺陈。这么做的目的是想说：直接面对一个庞然大物是有“恐惧”的，然而流行框架的优点是它一般都具有良好的“模块化”设计，因此我们便可针对每个相对较小的模块逐个击破之，最后再知识整合即可。

`DiscoveryClient`作为服务发现客户端，提供服务注册功能是其核心能力之一。在进行Register服务注册的时候，最终目的就是把本实例`InstanceInfo`发送给Eureka Server服务端。看似比较简单，但想作成一个产品级的功能还是有众多因素需要考虑的：周期性执行、数据准确性、自动执行、手动触发、并发、限流等，这些因素均可能影响着注册上去数据的准确性，因此有必要考虑在内。为了集中解决这些小问题，Eureka提供了一个为服务注册小工具：`InstanceInfoReplicator

`Eureka`作为一个注册中心，核心功能可概括为两个：服务注册和服务发现/服务查找。它属于C-S架构，服务注册属于Server端提供的能力，而服务查找它贯穿于服务端及客户端均有，它们的公用抽象接口是`LookupService`。本文以及接下来几篇文章会讲解客户端对服务查找的实现：通过请求服务端获取注册列表，提供给服务使用。

上篇文章介绍了使用`EurekaHttpClients`可以快速创建`ClusterResolver`集群解析器，但是相关方法均为私有的，并不可直接访问（`newBootstrapResolver()`除外）。主要原因是Eureka并不希望你直接访问它（也没这种必要），这些方法仅为构建一个`EurekaHttpClient`实例来提供支持即可，这便是本文内容。本文将结合具体的实例代码，全面介绍`EurekaHttpClients`的使用方式。

前面用多篇文章详细介绍了远程通信模块中`EurekaHttpClient`的实现，含Low-Level以及Top-Level的各种实现。那么面对这么多的底层or高层实现，如何快速组合得到一个最终可用的、具有产品级功能的远程通信Client客户端呢？Eureka为了简化这个操作，提供了`EurekaHttpClients`工具对常用典型场景做了快速处理，这边是将下来要讲解的主要内容。

上篇文章从源码处了解到了`RetryableEurekaHttpClient`的工作原理，作为`EurekaHttpClient`高级别实现中最重要的一个，本文将用代码来演示它的使用，达到巩固理解以及能够深入了解Eureka内部机制的目的。另外一个重点是介绍它的`transport.retryableClientQuarantineRefreshPercentage`这个配置项，因为有一句话叫：只要了解了此配置项，肯定就了解了`RetryableEurekaHttpClient`。

接着上文的节奏，本文来到`EurekaHttpClient`的top-level实现中最后一个，也是最为重要的一个实现：`RetryableEurekaHttpClient`，它用于保证Client端的高可用。如果你了解了Hystrix、Ribbon、Hystrix等组件你会发现，它们都会有涉及到重试的相关知识点。因为业内基本有这么一个共识：只要涉及到远程通信必有Retry重试，而作为C-S模式的实现，`Eureka`更是不例外。

前面已有几篇文章介绍了`EurekaHttpClient`接口以及其Low-Level实现：`JerseyApplicationClient`。对于底层实现非常的干脆利落，无异于直接使用HC发送请求，正常情况下可以work得很好，但是缺乏容错性等一些产品及特性如“重试”等。本文将介绍`EurekaHttpClient`的Top-Level部分，它**在Low-Level部分的基础上**包裹上一些产品及的功能，以能提高容错性，达到高可用的目的。实际生产中不可能直接使用Low-Level的实现，而是使用经过

接着上文的内容，本文继续介绍另外一个非常重要的包装器模式的`ClusterResolver`实现类：`AsyncResolver`。字面意思：它是一个异步解析器，但其实却又不是传统意义上的异步的意思，那到底意寓如何，本文将作出解释说明。关于`ClusterResolver`已经持续用了好几篇文章，本文是它的最后一篇。`ClusterResolver`对理解高可用集群的搭建非常重要，因此若你近期想尝试Eureka的高可用建设，需要深入了解一波。

前两篇对`ClusterResolver`以及其几个**独立子类**进行了讲解，本文继续。从本文起将介绍其**装饰者模式**的几个子类，它的最大特点是：可以装饰任意一个`ClusterResolver`解析器，在其基础上包装/扩展上对应功能。装饰者模式有个非常显著的特点：它对目标进行“包裹”，并且可以可以一层一层的一直包裹下去。本文主要介绍`ZoneAffinityClusterResolver`：它在目标解析器上面增加了区域感知的能力。

本文继续上文的内容，介绍`ClusterResolver`的其它实现如：本地集群解析器`ApplicationsResolver`。

注册中心是在微服务体系中是最重要的基础设施之一，对高可用的要求是极高的。比如`Eureka`在生产上肯定是集群式部署，要求高一点的甚至还会采取多区域(region)、多可用区(zone)进行混合部署。那么既然Eureka Server端部署如此“复杂”，Client端如何“配合”呢？这边是本文要介绍的集群解析器`ClusterResolver`它的作用。

上篇文章介绍了Eureka一个迷人小工具`TimedSupervisorTask`：它是Eureka进行周期性任务调度如心跳、缓存刷新的基础。本文继续介绍它另外一个小工具`EndpointUtils`，不同于`TimedSupervisorTask`它是一个传统的工具类：提供一些静态方法来处理和`Eureka`端点`EurekaEndpoint`相关的工作。本工具类提供（从配置文件里）解析出`DiscoveryClient`使用的`ServiceUrl`的工具方法，这些处理规则对你了解**Eureka是

本文介绍Eureka里一个设计巧妙、代码简洁的迷人小工具类：`TimedSupervisorTask`。它是一个固定间隔的周期性任务（因为它自己实现了`Runnable`接口），一旦遇到**timeout超时**就会将下一次任务的执行时间**翻倍**，如果继续超时就继续翻倍，直到达到设定的上限为止（达到上限后就是固定时间间隔了），周而复始。因为它实现简单，但达到的效果却很好，被广泛运用在Eureka的各种定时任务里，因此本文予以介绍学习。

本文进行JavaSE基础内容：Executor执行器体系的整体介绍。该文是整体框架介绍，并非局限于某一个使用的细节。由于我不止一次的被咨询说`ExecutorService`和`ScheduledExecutorService`什么区别和联系，以及`ThreadPoolExecutor`和`ThreadPoolTaskExecutor`有什么不一样之类的问题，因此决定写此文科普一下。本文内容不深，但比较全，因此我相信绝对是你值得阅读的一篇文章（即使你可能已经工作了5年+）。

本文接着上文的内容，主要解答上文留下的疑问：既然不能使用`InetAddress#getLocalHost()`直接去获取到本机的IP地址，那么如何破呢？本文将介绍的是一种通用的获取本机IP地址的解决方案，也就是所谓的“正确姿势”。

Java具有较好的网络编程模型/库，其中非常重要的一个API便是`InetAddress`。在在`java.net`网络编程中中有许多类都使用到了`InetAddress`，包括`ServerSocket，Socket，DatagramSocket`等等。你要进行网络编程就得有IP地址、域名、主机等要素，而一个`InetAddress`里就保存着IP地址，同时还**可能**包含主机名，并且它提供了主机名 - IP地址**互转**的方法（比简单的域名解析还牛有木有），本来主要就介绍它看看能够怎么玩。

在此之前，我对于网络通讯上的一些基础概念总是含糊其辞，感觉自己知道都又道不出个所以然，总之就是不成体系难以有个整体的把握。因此有了本文，目的是对一些平时颇为关注的网络概念进行总结，描绘出它们的关系，借此也希望能去扫清你的一些障碍，给小伙伴们分享一波。

通过前两篇文章一步一步介绍了如何构建出一个`JerseyApplicationClient`实例来完成服务注册、服务下线等功能。而上文讲到了使用Eureka提供的`EurekaJerseyClient`通过Builder模式去构建已经比较方便了，但是仍旧存在一个小问题：无法摆脱`Jersey`关键字的感知，自然底层上也就无法摆脱对Jersey库的强依赖。即使你并不需要使用Jersey的API来做事，但使用时你却**明显的知道**你实际就是在用Jersey来干活，似乎有点欲盖弥彰。这种“强耦合”很明显是制

上篇文章介绍了Eureka底层通信模块中的默认基于Jersey实现：`JerseyApplicationClient`，文末指出我们一般并不会通过构造器去**直接**构造出它的实例来完成请求的发送。本文将结合代码示例的方式进一步讲述为何不建议手动构建的原因，以及逐步引导出“规范”的使用方式。