权限管理是每个项目必备的功能，只是各自要求的复杂程度不同，简单的项目可能一个 Filter 或 Interceptor 就解决了，复杂一点的就可能会引入安全框架，如 Shiro， Spring Security 等。
其中 Spring Security 因其涉及的流程、类过多，看起来比较复杂难懂而被诟病。但如果能捋清其中的关键环节、关键类，Spring Security 其实也没有传说中那么复杂。本文结合脚手架框架的权限管理实现（jboost-auth 模块），对 Spring Security 的认证、授权机制进行深入分析。

接上一篇 写一个自己的脚手架——基础组件篇，本篇为基于基础组件搭建的单体应用框架介绍。单体应用框架提供常见的一些基础通用功能实现，目前主要为权限管理，提供前后端分离的后端 Spring Boot 项目与前端 Vue 项目。

本项目还在持续完善中。

现在很多 Web 项目，包括普通的前后端分离项目，微服务项目，都基于 Spring Boot 搭建，项目中一般需要包含一些通用的特性或功能，如统一异常处理、切面日志功能、权限管理功能等。写一个自己的脚手架，对一些基本规范、基础功能进行沉淀，基于此可只需要关注业务实现，提高开发效率。

目前整个脚手架包含三部分：

1. 基础组件：对单个项目（服务）的一些基本特性、功能等进行封装，便于复用，或达到常说的“开箱即用”
2. Spring Boot 单体项目脚手架：基于基础组件，提供常见的一些基础通用功能实现的单体项目框架，如权限管理，提供前后端分离的后端 Spring Boot 项目与前端 Vue 项目
3. Spring Cloud（包含 Spring Cloud Alibaba）微服务项目框架：基于基础组件，提供微服务框架的基础组件与功能实现，如网关（Spring Cloud Gateway），服务注册中心与配置管理（Nacos），服务限流降级（Sentinel），统一权限管理（Spring Security Oauth2）等。

本项目还在持续完善中，本篇为基础组件介绍。

使用 Spring Cloud Config 我们可以实现配置的集中化管理，但 Spring Cloud Config 如果要实现配置的动态更新， 则需要借助 Spring Cloud Bus（参考 Spring Cloud（八）：使用Spring Cloud Bus来实现配置动态更新）。 Nacos 不仅可作为服务注册中心，同时还可以作为配置的集中化管理中心，且其自身默认就支持动态更新，集成非常方便。

服务注册中心是微服务的核心组件之一，目前常见的服务注册中心包括Eureka（参考：Spring Cloud（一）：服务注册中心Eureka），Zookeeper，Consul，CoreDNS，及 Nacos。

在以前的文章中，曾经提过“技术人员的价值，不在于你能写出多么优美的代码，也不在于你能设计出一个多么大而全的高屋建瓴的架构，而在于你实实在在的解决问题的能力，在于你使用技术手段服务于业务的能力”。

最近一段时间，因工作中遇到一些现象，让我重又想起这句话，并且试图思考如何来提高解决问题的能力，有没有一种方法论的手段或者技术性的框架来实践？

前文Kubernetes笔记（七）：K8s中的日志采集实践——log-pilot介绍我们对 k8s 集群中常用日志采集模式及阿里开源的 log-pilot 进行了介绍，本文介绍如何使 log-pilot 适配 ELK 7.x 及如何将 log-pilot 部署到 k8s 集群中进行日志采集。

日志是应用服务运行过程中的一个关键环节，借助日志，我们可以排查定位问题，也可以借助集中化的日志管理平台（如ELK）来做一些必要的数据统计分析与监控告警。在 K8s 环境中，容器的日志有可能是通过 STDOUT/STDERR 输出（对于标准输出，前面 Docker笔记（十三）：容器日志采集实践 有相关介绍可参考），并且一般也推荐将日志写到标准输出，但是也有一些特殊的场景，应用直接将日志写在容器内部的日志文件。对于容器的标准输出日志来说，Docker Engine 本身就提供了一个很好的日志采集能力，但是对于容器内部的文件日志采集，现在却并没有一个很好的工具能够去动态发现采集。因为在分布式的容器集群中，容器随着 Pod 调度被动态创建或删除，我们无法像虚拟机环境那样事先配置好日志采集路径等信息，目前的采集工具都是需要我们事先手动配置好日志采集方式和路径等信息，它无法自动感知到容器的生命周期变化或者动态漂移（一个 Pod 挂了，可能是在另一个节点上启动一个新的 Pod），无法进行动态的配置。因此，在 K8s 中进行日志采集将变得更为复杂。

Pod（容器组）是 Kubernetes 中最小的调度单元，可以通过 yaml 定义文件直接创建一个 Pod。但 Pod 本身并不具备自我恢复（self-healing）功能。如果一个 Pod 所在的节点出现故障，或者调度程序自身出现问题，以及节点资源不够或节点进入维护而驱逐 Pod 时，Pod 将被删除，且不能自我恢复。

因此，Kubernetes 中我们一般不直接创建 Pod， 而是通过 Controller（控制器）来管理 Pod。

Kubernetes Ingress 可将集群内部的 Service 通过 HTTP/HTTPS 的方式暴露供外部访问，并通过路径匹配规则定义服务的路由。但是 Ingress 对 TCP/UDP 的服务却支持的不那么好。如果我们服务中有使用 Websocket 或 Socket， 需要暴露给外部访问，在 Kubernetes 中该如何配置呢？