诗酒趁年华

BPF 最初代表 Berkeley Packet Filter，但现在 eBPF（扩展 BPF）可以做的不仅仅是数据包过滤，这个首字母缩略词就不再有意义了。eBPF 现在被认为是一个独立的术语，不代表任何东西。在 Linux 源代码中，术语 BPF 仍然存在，而在工具和文档中，术语 BPF 和 eBPF 通常可以互换使用。原始 BPF 有时被称为 cBPF（经典 BPF），以区别于 eBPF。eBPF是一项源于Linux内核的革命性技术，它能够在诸如操作系统内核这样的特权环境下运行沙盒程序。

在基于Strongswan搭建IPsec站点到站点VPN的实际运维中，当遇到两侧流量选择器（Traffic Selector）定义的数据流无法互通时，常规的排障手段是通过Wireshark抓包分析。命令直接获取安全关联（SA）的状态信息，包括SPI值、加密算法和密钥等核心参数，配合Wireshark的ESP预共享密钥配置即可实现报文解密。这边，我将详细介绍方案二的方法，该方案的优势在于无需修改代码或额外组件，通过日志中的。编辑strongswan.conf文件。这样就可以看到解密的报文了，完美~

我们经常会在我们后端服务前加一层代理去做负载均衡或认证，比较有名的就是apisix。但是，这样会出现一些问题，比如说后端服务无法获取到客户真实的ip，显示的都是代理的ip，对于业务展示会有问题。

将接口类型定义放在与使用者更近的地方，可以使代码更加清晰和易于理解。使用者可以直接看到接口类型定义，了解接口类型的作用和使用方法。但注意：这并非是绝对的规则。

容器生态系统，包括核心技术，平台技术和支持技术。容器核心技术，包括容器规范，容器runtime，容器管理工具，容器定义工具，容器OS，Registries。容器核心技术使得容器能够在单个host上运行，容器平台技术能够让容器作为集群在分布式环境中运行。容器编排引擎就是docker swarm 和 k8s，容器管理平台就是rancher。容器对外提供的技术能力，包括容器网络，服务发现，监控，数据管理，日志管理，安全。虚拟机提供整台机器（服务器）的虚拟化。虚拟机模拟物理机的硬件组件，例如 CPU、内存、网络接口

4.2 范畴结构：将事物分为几类，逐一说明。例如：“我们分析一下三个群体的社会声望：公务员阶层、私营企业主、农民工。4.3 评价结构：将一个事物或观点的正反两面分别来谈。一般先讨论正面。例如：“让我们分析一下运动对身体的影响。首先，适量运动对身体的好处有……；其次，不恰当运动也会损害健康……。4.4 时间结构：按照事物发展的顺序排列，一般按照时间先后顺序。例如:"让我们回顾一下中国的文字发展：首先，结绳记事阶段……；其次，甲骨文阶段……；再次……”

最近在某客上学习了一下郭东白老师的架构课，郭东白老师是原来阿里P10，是云计算和国际化电商平台领域的资深专家，他完整讲述了自身作为架构师该如何设计架构，以及对架构师的一些思考。整个囫囵吞枣般看完，好似虚竹一般，虽获得无崖子70年功力，但如何打出妙招，少侠我还多需努力。

现如今我们有大量的框架套用，几天就能开发出一个产品，但这些如同批量生产的“口水歌”一般，慢慢就会被用户遗忘，软件开发者最终交付物不应该是产品，而应该是用户满意度。写代码不难，难的是idea，是那些具有创意的产品。

在 Makefile 中我们要定义一系列的变量，变量一般都是字符串，这个有点像C语言中的宏，当 Makefile 被执行时，其中的变量都会被扩展到相应的引用位置上。

inotify-tools是由Red Hat开发的一款Linux文件系统监控工具，该工具高效率、细粒度、异步地对用户空间文件进行安全、高性能的监控，而在linux中一切皆文件，这就意味着你可以对设备，网络，CPU等等都可以进行监控，并做一定的action。inotify-tools内包含的so文件可以直接被复用在自己的项目工程中，或者直接使用工具内编译好的进程，inotifywait和inotifywatch进行文件监控，监控粒度非常细甚至软连接//被监控项目或者被监控目录中的条目被访问过。

1. 关注 gartner，hype，cycle。上面有各种产品和技术方向的。2. 挑几个感兴趣的火热的领域，比如网络安全的SASE，SDWAN。3. 继续查gartner SASE。4. 在油管和官网上查找相关技术资料。，找到第一象限或感兴趣的厂商。

中国互联网发展状况统计报告》指出，截至2020年6月，我国网民规模已经达到9.40亿，较2020年3月年增长3625万，除了如此庞大的用户基数，如今人们接入互联网的方式也越来越多样，小到智能手表，手机，大到笔记本，汽车，这也意味着实际使用互联网服务的entry point正以亿级的增长速率膨胀。也就是基于如此规模急剧扩大的环境下，服务厂商开始面临着两大压力，一个是更大的并发访问压力，一个是海量数据存储的压力。高并发问题是各大平台必须解决的问题之一，它关系着平台可以承担多大的用户量以及能否提供可靠的服务。

做产品开发时，我们经常跌落在一种无法打破的轮回中。我们经常说，产品上线最重要，可以未来再重构代码， 但是结果大家都知道，产品上线以后重构工作就再没人提起了。首先，线上跑的好好的，动出问题怎么办？其次，后面有无数的新需求不断涌来，工程师应对这些新功能已经捉襟见肘，还要花很大一部分精力对现有系统的修修补补。所以， 重构的时候永远不会再有了。我们拆了东墙补西墙，循环往复，劳心劳神，互相扯皮，提桶跑路。是什么原因导致这样的？