很多人是不写单元测试的，无非因为性价比太低。但我始终以为，真实原因是打开方式不正确，如果花功夫系统研究一下，或许会不一样。

这不就来了，现希望相对系统第了解单元测试的理论、常用工具、实施方法。伴随会产生系列文章。初预备三部分：

• 理论：介绍单元测试需要关注的内容，从设计上如何考虑
• 工具：介绍Spring Test、JUnit、Assert、Mock技术，相关库的使用
• 实践：基于以上两个部分的学习，重构当前的一个项目，记录过程中考虑的点。并最终给出结论。

此篇为首！

这是Linux系列第二篇文章，本来觉得Shell写完就OK了。但仔细一梳理发现对很多Linux要么是一知半解，要么是忘了。既然如此，还是遇到什么就回顾什么吧。本文试图解决以下问题

• Linux如何做用户管理
• 用户和权限的关系
• 一个用户安装软件后，其它用户能否使用，这是如何决定的？
• 与此相关的命令的使用方式

shell常用，却从未引起重视，用到啥就查啥，甚至语法都不记得。在这样一次次的”现查“中，浪费了大量的时间。索性花上一个周末的时间，相对系统第学学它，毕竟它也不复杂。

本文没有太多内容，正文是一张图。

我到B站随便找了个视频，就它，看了下，收获颇丰。算是系统梳理吧，整个思维导图，助记。

前面介绍过Kubernetes的结构组成，其中API Server用于与外界的交互，我们常用的命令行工具kubectl、UI工具lens、云服务商提供的WebUI，最终都是通过Restfule API的形式，走HTTP协议，到达API Server。此时就带来权限控制问题。

本文试图清晰明白的讲述LDAP是什么、应用场景、使用方法。

开篇照例一波吐槽。LDAP这个名字大家不会陌生，即所谓轻量级目录访问协议。无论博客还是论坛，网上对它的讲解太多了，但在我看来，都不得要领。它们中的大多数都仅介绍了冰山一角，还不注明资料来源。想来，作者很可能也不知道这些知识从哪里来的，这篇文章看看、那篇文章参考一下，东拼西凑，再看看库的API，写写代码，然后…it works!!!，再然后就没有然后了吧🤔。

本文试图从协议本身出发，尽量做到系统化。就算读者看了这篇文章还是不能掌握，也可以自己翻看协议文档解决问题。毕竟一手资料才是最可靠的。

OpenID Connect 1.0是建立在OAuth 2.0上的一个身份验证机制，它允许客户端通过授权服务对用户进行认证并获取简单的用户信息。

前置知识：读者需要了解OAuth2.0的授权码模式和隐藏模式两种工作流程，要了解JWT、JWE、JWS等概念。这在我的前两篇文章都有详细讲解

本文深入OAuth2.0协议，以及基于其上的OpenID Connect身份认证协议。前者解决授权第三方服务访问资源的问题；后者解决身份认证的问题。主要资料来源是官方协议手册：RFC6749、OpenID Connect Specification。

当然还有更多其它说的好的第三方资源，比如阮一峰这个，它的优点是只针对协议讲解，没有举那些无助于理解的复杂例子。

本文介绍JWT组成原理及适用范围。

我有一个树莓派3B，1G内存版本，以前用来当做linux主机，随便玩一玩，谢谢python，点个灯。但最近我想搭建一个Kubernetes集群，用来学习，不过集群诶，怎么能只有一台机器呢？于是在咸鱼上又购买了两台树莓派4B，一台4GB内存，一台2GB内存。为什么想用树莓派呢？一来因为还算OK的云服务器贵得离谱，对个人来说实在不划算，二来树莓派可玩性比较高。

然而搭建过程几经波折，浪费了大量的时间，想来，最主要的问题有两个：cgroup的开启失败和墙的问题。

截止目前，我们已经写了四篇关于Spring源码解析的文章，但它们只关注了Spring和SpringBoot的启动流程，并没有回答我们日常使用中的核心问题——自动配置的实现原理，本文进行探索

卷只是一个概念，和Docker中的卷是一个意思，可以理解为一个存储挂载点，将pod内部的文件系统与pod外部的文件系统挂载起来，以便pod数据的持久化。

与Docker不同的是，Kubernetes支持非常多种类型的卷（超过二十种）

卷是pod容器的组成部分，并非K8S中的顶级资源，其生命周期和pod一致。可以在pod的文件系统的任何位置挂在卷。如下两张图展示了同一个pod中存在多个容器时，在有卷和没有卷时的区别，可以看到在没有卷时，由于三个容器的文件系统分离，因此都各自操作自己的目录，即使他们在功能上是重复的；有卷时，将同一个卷挂在到两个容器的文件系统中，让他们共享这一块存储，既节省空间，也省去了从一个容器向另一个容器中复制的步骤。

在Spring源码剖析的前三篇文章，我们介绍了ApplicationContext、Bean相关内容、BeanPostProcessor的内容；但从普遍反馈和自己事后阅读的体验来看，文章过长，没有重点，条理并不是特别清楚。想必是写作方式出了问题，最突出的莫过于流水账式写法，虽然写作的目的并不一定是写出好的文章，而是主要服务自己，但时间一长，自己也是个普通的读者，同样会看不大懂。

因此，写作方法是需要变更了：要突出条理和重点，如需大段源码讲解，可在文章最后增加源码解析一节，读者可选读。也就是说，长度还是那么长，但可读性增强了很多。

本文介绍Dockerfile中主要命令的用途

本文目的是让读者对namespace和cgroup有具象的认识，并不会深入。当然，由于笔者Linux知识有限，也无法深入。

“容器是一个与宿主机系统共享内核但与操作系统中的其它进程资源隔离的执行环境”，这是理解容器技术的核心。这句话可以翻译的更直白一点：容器是一个环境，该环境内运行的进程和操作系统中的其它进程是一样的，享受同样的硬件资源，唯一的差别是，该环境内的进程看不到其它进程的存在，操作也不会相互影响，即所谓的隔离；多个容器的运行，就是在各自的隔离环境中运行各自的进程。

BeanPostProcessor是Spring中参与Bean生命周期定制非常重要的一个手段，上文分析过，其执行有两个时机

• 一前：Bean自动注入之后，自定义初始化方法调用前
• 一后：自定义方法调用之后

Spring中很多重要的特性利用了BeanPostProcessor达成，毕竟，算来算去，Spring中整个Bean的生命周期已经足够复杂了，如果每加一个功能就要在生命周期上做文章，只会增加复杂度，而BeanPostProcessor则是Spring提供的一种扩展方式。与其相对的，一般用户用的可能较少的BeanFactoryPostProcessor是针对整个容器初始化完成后提供定制化功能的扩展，我们也要观察一下。观察的主要内容是主要实现类及其作用。