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

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

前文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 中该如何配置呢？

Kubernetes 中， 容器总是以 Pod（容器组）的方式进行调度与运行。因此对 Pod 的理解与掌握是学习 Kubernetes 的基础。

最近一次移动端Vue应用的上线，导致某些用户使用某些功能时出现问题，经主动清空缓存后恢复。有时候清空微信应用的存储空间缓存仍不能解决问题，此时安卓机可借助微信TBS调试工具 http://debugx5.qq.com （微信中打开页面，勾选最下面四个选项清除缓存），但该工具目前只支持安卓手机，苹果机就比较麻烦了。为了找到问题的本质，从根本上避免问题，最近浏览了一些文章，其中有一篇对浏览器缓存的分析及在Nginx中对应的处理策略总结的比较好，这里分享给大家。

上篇文章（限流算法与Guava RateLimiter解析）对常用的限流算法及Google Guava基于令牌桶算法的实现RateLimiter进行了介绍。RateLimiter通过线程锁控制同步，只适用于单机应用，在分布式环境下，虽然有像阿里Sentinel的限流开源框架，但对于一些小型应用来说未免过重，但限流的需求在小型项目中也是存在的，比如获取手机验证码的控制，对资源消耗较大操作的访问频率控制等。本文介绍最近写的一个基于RateLimiter，适用于分布式环境下的限流实现，并使用spring-boot-starter的形式发布，比较轻量级且“开箱即用”。

在分布式系统中，应对高并发访问时，缓存、限流、降级是保护系统正常运行的常用方法。当请求量突发暴涨时，如果不加以限制访问，则可能导致整个系统崩溃，服务不可用。同时有一些业务场景，比如短信验证码，或者其它第三方API调用，也需要提供必要的访问限制支持。还有一些资源消耗过大的请求，比如数据导出等（参考 记一次线上Java服务CPU 100%处理过程 ），也有限制访问频率的需求。

分布式锁是在分布式环境下（多个JVM进程）控制多个客户端对某一资源的同步访问的一种实现，与之相对应的是线程锁，线程锁控制的是同一个JVM进程内多个线程之间的同步。分布式锁的一般实现方法是在应用服务器之外通过一个共享的存储服务器存储锁资源，同一时刻只有一个客户端能占有锁资源来完成。通常有基于Zookeeper，Redis，或数据库三种实现形式。本文介绍基于Redis的实现方案。