2024 年，生活因为远行和热爱而显得格外丰富多彩。这一年，不仅踏足了梦寐以求的远方，也在多样的经历中感受了心灵的震撼与满足。

远方的呼唤：大西北与河西走廊

今年国庆节，我终于实现了多年来的一个愿望——亲自走一趟大西北，穿越河西走廊。这片土地承载了中华历史上无数的辉煌与故事。从纪录片《河西走廊》到书籍的描绘，我一直深深向往那里，终于在这个秋天用自己的双脚踏上了这片神秘又壮丽的大地。

行程从兰州开始，途经武威、金昌、张掖，再到敦煌和青海——每一步都带来了深深的文化震撼。

祁连山：中华民族的精神家园

这次旅行中，最让我感触深刻的，是巍峨的祁连山。作为横亘河西走廊的重要山脉，它不仅是自然的奇观，更是中华民族历史与文化的丰碑，见证了无数影响深远的事件。

这里是河西走廊的生命之源，滋养着无数的绿洲与生灵。从霍去病“饮马翰海，封狼居胥，西规大河，列郡祁连”，到隋炀帝西巡祁连，穿越隘险山路，风雪晦暝中感受大山的雄奇；再到唐代玄奘取经途中仰望祁连的巍峨，吐蕃东扩、西夏拓疆，以及成吉思汗策马征战，祁连山始终作为中华民族历史舞台的背景，书写着不朽的篇章。

不仅如此，祁连山的存在也是一种精神的象征。这座山脉不仅塑造了河西走廊的地理格局，也见证了民族的融合与交流。它所承载的，不仅是大漠孤烟、长河落日的苍凉之美，还有历朝历代开疆拓土的壮志豪情。

站在祁连山脚下，仰望连绵不绝的山脉，历史的厚重感扑面而来。那些耳熟能详的名字和故事仿佛不再遥远，它们就在这片土地上真实地发生过。祁连山不仅是一个地理存在，更是中华民族共同的精神家园，永远耸立于我们的文化记忆和历史深处。

这一次，我终于亲自走进了祁连山，用眼睛去感受它的雄伟，用心去聆听它的故事，用手触摸它的脉络，并带回了一瓶土作为纪念。这是一次难忘的文化与自然的交融，一种对中华历史与精神家园的深刻敬意。

张掖：塞上江南与历史的交汇

如果说祁连山是河西走廊的脊梁，那么张掖便是它的灵魂。这座位于祁连山北麓的古城，自汉朝设郡以来便成为东西文化的交汇点。作为河西四郡之一，张掖不仅有着“塞上江南”的美誉，更是一座承载着厚重历史的传奇之城。

张掖的历史如同一幅绵延不绝的画卷：

这里是匈奴、月氏、柔然、突厥、吐蕃、蒙古等几十个民族曾经的繁衍生息之地，苍凉的黄沙百丈与铁马冰河的金戈声交织在这片土地上；这里也是想象与现实交汇的地方，周穆王与西王母的瑶池会面、老子骑青牛入流沙的奇幻传说都深深植根于张掖的文化记忆；而《西游记》中那些熟悉的名字——黑河、弱水、流沙河、通天河——也源于张掖及其周边的真实地貌。

从霍去病策马西征，到张骞出使西域带回丝绸之路的起点；从隋炀帝在此召见西域各国使臣，到成吉思汗的铁蹄踏碎西夏的繁华旧梦；从肃王的藩邸迎来裕固新民族，到左宗棠栽下的杨柳与千年不倒的胡杨在此扎根。张掖的历史是东西文化交流、南北民族交融的缩影。

当我踏入张掖时，脑海中浮现的是丝绸之路上驼铃声声、胡杨下长河落日的景象，那种历史的厚重感和文化的积淀让我心生敬畏。张掖的地标不仅仅是广为人知的丹霞地貌，它更是一座时间之城，连接过去与现在的桥梁，让我在旅行中重新认识了中华文明的深远意义。

敦煌：丝绸之路的璀璨明珠

敦煌，这座大漠深处的璀璨明珠，是我此次旅途中最震撼人心的文化与历史盛宴。作为丝绸之路上的重要节点，敦煌不仅承载着东西方文明交融的辉煌，也以其无与伦比的艺术成就留名千古。

当我踏入莫高窟 时，眼前那些绚丽的壁画和精美的雕塑，仿佛带我穿越千年时光。窟内的一砖一石、一笔一画，无不记录着丝路商旅的繁荣、佛教文化的兴盛与中西文化的碰撞。从九色鹿王的传奇故事，到飞天飘舞的优雅姿态，每一幅画作都栩栩如生，诉说着千年不朽的信仰与艺术。此刻我才真正体会到了余秋雨在《文化苦旅》一书中所著的一段话：

“如果仅仅为了听佛教故事，那么它多姿的神貌和色泽就显得有点浪费。如果仅仅为了学绘画技法，那么它就吸引不了那么多普通的游客。如果仅仅为了历史和文化，那么它至多只能成为厚厚著述中的插图。它似乎还要深得多，复杂得多，也神奇得多。

它是一种聚会，一种感召。它把人性神化，付诸造型，又用造型引发人性，于是，它成了民族心底一种彩色的梦幻，一种圣洁的沈淀，一种永久的向往。

它是一种聚会，一种感召。它把人性神化，付诸造型，又用造型引发人性，于是，它成了民族心底一种彩色的梦幻，一种圣洁的沈淀，一种永久的向往。

它是一种仪式，一种超越宗教的宗教。佛教理义已被美的火焰蒸馏，剩下了仪式应有的玄秘、洁净和高超。只要是知闻它的人，都会以一生来投奔这种仪式，接受它的洗礼和熏陶。”

离开了莫高窟后，我去观看了盛名在外的《乐动敦煌》表演。这场演出以现代科技和传统文化结合的形式，将敦煌壁画中的飞天、乐舞、驼铃商旅等元素生动地搬上舞台，伴随着绚丽的光影和悠扬的古乐，我仿佛置身于千年前的丝绸之路，感受敦煌在历史长河中的璀璨辉煌。

接着，又走进了敦煌另一处著名的自然奇观——鸣沙山与月牙泉。这里是沙漠的柔情，也是自然的奇迹。漫步在金色的沙丘之上，细腻的沙粒在脚下滑动，耳边仿佛能听到风吹沙鸣的声音。在月牙泉旁，我看到了大漠深处那一抹柔情。清澈的泉水如一轮弯月镶嵌在沙漠之中，泉水四周环绕着一片绿洲，这种生命与荒凉并存的景象令人感慨万分：”这里是大自然的艺术，既是严酷的，又是诗意的。“

夜幕降临，敦煌的另一面展现出独特的魅力。漫步于沙洲夜市，我完全被琳琅满目的手工艺品吸引，忍不住挑选了许多精美的纪念品。最让我喜欢的是一块手绘的壁画泥板，工艺与莫高窟的壁画相同，每一道线条都透露着敦煌特有的艺术风格；还有一只小巧精致的手绘鼻烟壶，水墨绘有花鸟山石，枝上疏花秀蕊，一只麻雀俏立枝头，鸣叫顾盼，灵动而细腻，这不禁让我联想起了宋徽宗的《梅花绣眼图》于是将其带走。每一件纪念品都仿佛带着这座古城的灵魂，让人难以拒绝。

这一晚的敦煌，不仅让我沉浸在历史与艺术的余韵中，更让我感受到这座城市在新时代焕发的独特魅力。它的每一处角落、每一个细节，都深深打动着我，让我为这片土地的过去与现在而感到震撼与自豪。

青海：跨越山脉，感受自然的壮美与宁静

从敦煌出发，我继续向南，越过阳关，横跨阿尔金山脉，进入了青海省。在这片高原大地上，辽阔的风景和纯净的自然气息同样让我深深震撼。从海西州一路前行，途经海南、海北，见证了高原上最动人的自然画卷。

• 翡翠湖：
  翡翠湖的色彩让人仿佛置身画中。湖水因矿物质的丰富而呈现出层次分明的翡翠绿与碧蓝色，每一汪水潭都像一颗宝石镶嵌在戈壁滩上。在这里，我被那种大自然调色盘般的惊艳深深吸引，感叹它的鬼斧神工。

  
  
  

• 茶卡盐湖：
  被誉为“天空之镜”的茶卡盐湖，是我此行中最梦幻的地方。站在湖面上，天与地仿佛融为一体，脚下是闪烁着阳光的盐晶，倒映着蓝天和云朵，仿佛走进了另一个世界。那种宁静与纯粹，让人忘却了一切喧嚣，只想静静感受这份高原独有的清凉与广阔。
  
  

• 黑马河与青海湖：
  沿着黑马河一路行进，我终于抵达了青海湖。这片中国最大的咸水湖像一块湛蓝的宝石镶嵌在高原上，环绕四周的雪山和草原相映成趣，呈现出一种难以言喻的壮美。在青海湖边，我看到牧民的帐篷点缀在草地上，牦牛悠闲地吃草，湖面在阳光下泛着粼粼波光。日出时，金色的光芒洒满湖面，整个天地仿佛被一种神圣的力量笼罩，那一刻，我真正感受到了宁静与和谐的极致。
  
  
  
  

这一路穿越了青海的海西、海南、海北三州，亲历了高原湖泊的纯净与壮丽。高山、湖泊、戈壁、草原，它们共同交织，形成了一幅幅瑰丽的自然画卷。每一处景点，都让我切身体会到这片土地的辽阔与神秘。跨过阿尔金山脉，仿佛也跨越了一条时光的分界线，从苍凉的敦煌走向了高原的纯粹，这种对自然的敬畏与热爱，将成为我旅途中最珍贵的记忆之一。

一路 2800 公里，虽然大部分时间都在路上，但路边的风景也同样辽阔壮丽：戈壁、山川、湖泊、草地、雪原，像极了一场泰拉瑞亚游戏——如梦、似幻。

重庆：山城之美与火锅之魅

此外，今年还去了重庆。从南山一望无际的山川，到长江两岸的繁华都市，重庆以其独特的地理优势和人文底蕴，吸引着无数游客和文人墨客。山水之间，蕴藏着独特的韵味与风情。

理小路：阿坝的秋色

今年的秋天，我还去了阿坝。那里的秋色如诗如画，漫山遍野的金黄与绚丽，还有雪山与阳光。

热爱的现场：音乐与斯诺克

这一年里，我还参与了几场令人难忘的现场活动，让热爱从屏幕跳脱到现实。

• 凤凰传奇演唱会：
  这是我看过气氛最强的一场演唱会，从《最炫民族风》到《月亮之上》，每一首歌都将全场带入欢呼与共鸣的高潮。站在人群之中，跟着旋律合唱、呐喊，仿佛回到了最单纯的青春岁月，快乐得毫无保留。这种感觉，只有在现场才能真正体会。
  
  

• 武侯斯诺克明星邀请赛：
  作为一名斯诺克球迷，这场邀请赛绝对是今年的另一大亮点。第一次如此近距离地看到喜欢的球员——丁俊晖、奥沙利文和特鲁姆普，他们的球技依然精湛，但作为邀请赛，比赛少了几分常规赛事中那种拼搏到底的紧张感，尤其是奥沙利文很快就结束了比赛，令人稍显遗憾。不过能够亲眼见到这些世界冠军，已经足够让我感到满足和兴奋。

生活的新篇章

这一年最重要的事件莫过于结婚了。和另一半一起走进婚姻的殿堂，在亲朋好友的见证下开启了人生的新阶段。这是一段忙碌、幸福和感动交织的旅程，达成了一个重要成就。

2024 年，我在开源领域的足迹扎实且精彩。这一年，不仅用代码推动了项目的发展，也在技术提升和社区协作中深刻感受到了开源精神的魅力。我参与和推动了多个开源项目，同时还担任了开源之夏活动的导师，带领新人顺利完成了项目结项，收获了技术和合作的双重成长。

2024 年，我在开源领域留下了充满成就感的一年。这一年，除了参与多个开源社区的贡献，我也在 Halo 项目的发展中扮演了重要角色，为其引入了诸多新特性与改进，推动项目从 2.12 版本发布到 2.20 版本，让这个开源博客系统变得更加强大和灵活。

贡献总览

• GitHub 贡献：全年累计 1919 次，活跃天数达到 252 天，平均每天改动 186 行代码，展现了持续的开发热情。
• Pull Requests：提交 308 个 Pull Requests，涵盖功能开发、性能优化、bug 修复等内容。
• PR Review：参与 586 次代码评审，与全球开发者共同推进代码质量提升。
• 全年编码时间：累计编码 956 小时，日均编码 3 小时 46 分钟，专注度排名前 3% 的开发者。
• 开源之夏导师：首次担任 开源之夏活动导师，带领新人完成项目结项。这不仅让我体验到传承的意义，也收获了指导新人开发的责任感与成就感。

Halo 项目：推动核心功能进化

这一年，我在 Halo 项目中投入了大量精力，为其新增了众多关键特性，并持续优化系统性能，助力从 2.12 到 2.20 大版本的发布。这些特性极大地提升了系统的安全性、可用性与灵活性：

1. 自定义模型索引机制

   优化查询效率与内存占用，为大数据量场景提供更优的解决方案。#5121

2. 登录安全改进

   • 新增用户密码修改后，踢除所有已登录会话的功能，提升账户安全性。#5757
   • 新增设备管理功能，可查看并移除已登录的设备，增强对账号的掌控力。#6100
   • 增加保持登录会话的机制，优化用户登录体验。#5929
   • 引入基于持久化 Token 的 RememberMe 机制，增强安全性与灵活性。#6131

3. 内容管理优化

   • 分类支持设置统一的渲染模板，提供更灵活的展示方式。#6106
   • 新增独立分类选项，用于控制子分类下的文章显示，提升内容管理的灵活性。#6083
   • 支持为分类设置隐藏选项，优化前端展示的精确度。#6116

4. 附件与响应式图片支持

   • 图片附件支持生成多尺寸图片，并支持文章内的响应式图片显示，提升性能与用户体验。#6454
   • 本地存储策略新增单文件大小与类型限制功能，提升文件管理能力。#6390

这一系列新增功能和优化，让 Halo 的用户体验和安全性显著提升，也为开发者提供了更高效、易用的开发工具链。我还提交了大量修复和性能优化的 Pull Requests，这些改进在细节处让系统更加稳定和流畅。

参与全球开源社区

除了 Halo 项目，我还积极参与多个知名开源项目，拓展了技术视野和社区协作经验：

• spring-framework：提交 2 个 issue，其中一个问题已经被接受处于内部讨论中，另一个则还没有回复。
• r2dbc-h2：提交 1 个 issue，虽然该项目活跃度不高，但我依然坚持为社区提供改进建议。
• java-design-patterns：贡献了 1 个 PR，完善 Async Method Invocation 设计模式代码，为开发者提供了更清晰的参考。
• pf4j：提交了一个 bug 反馈 issue，官方团队迅速修复问题，充分体现了开源社区的协作精神。

背景

在当前的 Halo 系统中，附件管理功能虽然支持多种存储策略（如本地存储和通过插件扩展的 S3 协议存储），但缺乏缩略图生成功能。这导致在管理端上传大尺寸图片时，页面加载速度显著降低。

具体来说，在管理后台的附件管理界面中，由于图片文件往往较大，浏览器需要加载原始尺寸的图片，这会导致页面加载时间过长，影响管理效率。同样地，在主题端，图片加载缓慢也会显著影响用户体验，尤其是在网络状况不佳或访问量较大的情况下，这种问题会更加突出。

为了提升图片加载性能，缩略图功能显得尤为重要。缩略图不仅可以显著减少管理端加载图片的时间，还可以让主题端在展示图片时，根据不同设备和网络情况加载合适尺寸的图片，提升整体访问速度和用户体验。因此，引入一个灵活且可扩展的缩略图生成机制，支持不同存储策略下的缩略图生成与管理，成为当前 Halo 系统优化的关键。

已有需求

用户和开发者对于附件管理的需求日益增加，尤其是在高效管理和展示图片资源方面。以下是系统中已经存在的一些需求，这些需求促使我们考虑引入缩略图功能：

1. 附件展示问题: 在管理后台中，图片仅有原图的访问地址，这导致图片列表加载时非常缓慢，影响页面流畅度 ​ (halo-dev/halo#3167)
2. 渲染性能问题: 多个 issue 提到在附件库中，加载大量大图会导致页面卡顿，甚至出现浏览器崩溃的情况，这凸显了对缩略图的迫切需求 ​ (halo-dev/halo#3830)​ (halo-dev/halo#2387)
3. 用户体验问题: 当用户上传过大的图片时，访问附件库和前端页面时加载速度缓慢，影响了整体用户体验 ​ (halo-dev/halo#5196)

由于 Halo 中缺乏缩略图功能，导致在管理和展示图片时出现性能瓶颈。为了解决这个问题，Halo 被迫进行了一些功能上的调整：

• 使用 CSS3 硬件加速：通过利用 CSS3 的硬件加速特性，优化了附件库中图片的渲染性能，试图减轻大尺寸图片带来的加载压力。(halo-dev/halo#3831)
• 调整默认排版模式：为了减少界面渲染的负担，附件管理界面的默认排版模式从缩略图视图调整为列表模式，以减少页面加载时间。(halo-dev/console#827)

这些调整在一定程度上缓解了由于缺少缩略图功能而带来的在附件管理上的性能问题，但它们并不能根本上解决问题。因此，缩略图功能的引入仍然是满足当前系统需求的关键所在。

目标

本 RFC 的主要目标是在 Halo 博客平台中引入一个灵活且可扩展的缩略图生成功能，以解决目前由于缺乏缩略图功能而导致的性能问题和用户体验下降。具体目标如下：

1. 提升系统性能：

   • 通过生成和使用缩略图，减少管理端和主题端加载大尺寸图片时的网络带宽占用和页面渲染时间，从而显著提升系统的整体性能。

2. 优化用户体验：

   • 在主题端使用缩略图替代原始图片，以加快页面加载速度，提升用户浏览体验，减少因图片加载慢而导致的页面卡顿或延迟问题。

3. 支持多样化的存储策略：

   • 为不同的存储策略（如本地存储、S3 协议等）提供灵活的缩略图生成和调用机制。针对本地存储，系统将自动生成并存储缩略图；针对支持参数化缩略图生成的云存储，允许实现者根据配置动态生成缩略图 URL。

4. 提供可扩展的开发接口：

   • 设计并实现一个扩展点，使开发者能够根据具体的存储需求和策略自定义缩略图生成逻辑。通过这个扩展点，开发者可以轻松地集成自定义的缩略图生成插件，以满足不同的业务需求。

5. 提高管理效率：

   • 在管理后台，使用缩略图替代大尺寸图片，提升附件管理界面的加载和操作速度，使管理者能够更高效地浏览和处理附件资源。

6. 保持兼容性与灵活性：

   • 在引入缩略图功能的同时，确保与现有的附件管理和存储机制保持兼容，并为未来的功能扩展预留灵活性。

通过实现这些目标，Halo 博客平台将能够更好地应对当前和未来的需求，不仅提升性能和用户体验，还为开发者提供更强大的扩展能力。

非目标

本 RFC 的目标是引入和实现缩略图生成功能，以提升系统性能和用户体验，但以下内容不在本 RFC 的范围之内：

1. 不涉及图像内容的分析与处理：

   • 本功能不包含任何图像内容分析（如图像识别、分类）或处理（如滤镜应用、图像增强）的功能。缩略图功能仅限于生成和管理不同尺寸的图像缩略图。

2. 不改变现有的存储策略实现：

   • 本 RFC 并不涉及对现有存储策略（如本地存储、S3 协议扩展）的底层逻辑和实现方式进行修改。缩略图功能将以插件或扩展点的形式集成到现有系统中。

3. 不提供图片的格式转换：

   • 本功能不会提供图片格式的转换功能，所有缩略图将使用与原图相同的格式进行生成和存储，避免涉及到图片格式的兼容性问题。

4. 不影响现有的附件管理功能：

   • 引入缩略图功能不会影响现有的附件上传、下载、删除等基本功能。这些功能将保持不变，并与缩略图功能兼容。

方案

实现方案分为两大部分：缩略图生成和缩略图的使用。下面将分别介绍这两部分的设计和实现。

缩略图生成

在缩略图生成方面，有以下几个关键问题需要解决：

1. 缩略图尺寸的设计：如何定义和选择合适的缩略图尺寸，以满足不同场景的需求。
2. 缩略图生成策略：如何根据原始图片生成不同尺寸的缩略图，以保证图片质量和加载速度。
3. 缩略图存储策略：如何将生成的缩略图存储在系统中，并与原始图片关联。
4. 缩略图生成的性能优化：如何通过缓存和预生成等方式，提升缩略图生成的性能和效率。
5. 缩略图生成的扩展性：如何设计和实现一个可扩展的缩略图生成机制，以支持不同的存储策略和需求。

考虑到使用方式和性能优化等因素，我们选择使用固定尺寸的缩略图，而非由具体宽度动态生成。这种设计有以下优势：

• 性能优化：使用预定义的固定尺寸缩略图，可以减少缩略图滥用的计算和生成压力，在满足图片加载速度的同时，可以减小缩略图的数量和对资源的消耗。
• 一致性和可控性：固定尺寸的缩略图可以保证图片展示的一致性和布局稳定性，过定义固定的缩略图尺寸，开发者可以更好地控制图片在不同场景中的展示效果。这样可以避免动态生成的图片尺寸不一致，导致页面布局问题或视觉不统一。
• 缓存利用：固定尺寸的缩略图更容易被浏览器和 CDN 缓存，有助于加快图片加载速度，并减少对服务器的重复请求。

缩略图尺寸设计

基于以上考虑，我们为系统预定义了以下几种常见的缩略图尺寸：

• Small (S)：宽度 400px
• Medium (M)：宽度 800px
• Large (L)：宽度 1200px
• Extra Large (XL)：宽度 1600px

定义枚举类型以便扩展点接口中使用：

public enum ThumbnailSize {
    S(400),
    M(800),
    L(1200),
    XL(1600);

    private final int width;

    ThumbnailSize(int width) {
        this.width = width;
    }

    public int getWidth() {
        return width;
    }
}

自定义模型设计

为了将图片与缩略图关联同时避免重复生成，需要定义一个自定义模型类，用于存储图片的 URL 和缩略图的 URL 之间的映射关系：

apiVersion: storage.halo.run/v1alpha1
kind: Thumbnail
metadata:
  name: thumbnail-1
spec:
  imageSignature: e99a18c428cb38d5f260853678922e03
  imageUri: /path/to/original.jpg
  size: L
  thumbnailUri: /path/to/thumbnail-L.jpg

基于 imageUri 生成的 MD5 签名，然后为 imageSignature 和 size 建立组合索引，一方面可以显著提高查询性能，同时也可以减少索引的大小。

indexSpec.add(new IndexSpec()
   .setName(Thumbnail.ID_INDEX)
   .setIndexFunc(simpleAttribute(Thumbnail.class, Thumbnail::idIndexFunc))
);

public static String idIndexFunc(Thumbnail thumbnail) {
   return idIndexFunc(thumbnail.getSpec().getImageSignature(),
      thumbnail.getSpec().getSize().name());
}

public static String idIndexFunc(String imageHash, String size) {
   return imageHash + "-" + size;
}

扩展点接口设计

为了保证缩略图功能的灵活性，我们设计了一个扩展点接口，使开发者能够根据不同的存储策略自定义缩略图生成逻辑。
例如，OSS 可能提供了根据参数生成缩略图的 API，可以避免在 Halo 生成：

public interface ThumbnailProvider extends ExtensionPoint {

   /**
    * 根据给定的图片 URL 和尺寸生成缩略图 URL。
    * @param context 缩略图上下文，包含图片 URL 和尺寸等信息
    * @return 缩略图 URL
    */
   Mono<String> generate(ThumbnailContext context);

   /**
    * 根据给定的图片 URL 删除对应的缩略图文件
    * @param imageUrl 原图片的 URL
    */
   Mono<Void> delete(String imageUrl);

    /**
     * 判断当前提供者是否支持给定的图片 URL。
     *
     * @param imageUrl 图片的 URL
     * @return 如果支持，返回 true；否则返回 false
     */
   Mono<Boolean> supports(ThumbnailContext context);

   @Data
   @Builder
   public static class ThumbnailContext {
      private final String imageUrl;
      private final ThumbnailSize size;
   }
}

系统将提供一个默认的 ThumbnailProvider 实现，针对本地存储生成缩略图。对于其他存储策略（如 S3 协议的 OSS），开发者可以通过插件实现该接口，动态生成和返回缩略图 URL。
如果找不到合适的 ThumbnailProvider 实现，则不生成缩略图，避免因为用户本来就不需要缩略图而浪费资源。

缩略图会在首次使用时调用 generate 方法生成链接，然后将其记录到 Thumbnail 自定义模型中，而这个链接对应的缩略图是否已经生成取决于实现者，可能在 generate 方法调用时就已经生成，也可能是缩略图 URL 被访问时生成。

当附件被删除时，会调用 delete 方法删除对应的缩略图文件，以避免无用的缩略图占用存储空间。

本地存储缩略图生成

对于本地存储，我们将提供一个默认的 ThumbnailProvider 实现，用于生成和存储缩略图。具体实现如下：

1. 根据参数给定的图片 URL 和尺寸，生成缩略图 URL，但不生成缩略图文件。
2. 将生成的缩略图 URL 和原始图片 URL 以及存储路径等信息保存到自定义模型中。
3. 通过 Reconciler 监听资源变化，为其生成缩略图文件。
4. 当缩略图 URL 被访问时，根据缩略图 URL 查询关联的缩略图资源并在查询到时检查缩略图文件是否存在，如果不存在则生成缩略图文件，否则返回 404。

本地存储的自定义模型设计

自定义模型设计如下:

apiVersion: storage.halo.run/v1alpha1
kind: LocalThumbnail
metadata:
  name: local-thumbnail-1
spec:
  imageSignature: e99a18c428cb38d5f260853678922e03
  imageUri: /path/to/original.jpg
  thumbnailUri: /path/to/thumbnail-L.jpg
  thumbSignature: e99a18c428cb38d5f260853678922e03
  filePath: /attachments/thumbnails/2024/w1200/2024-08-09.jpg
  size: L

索引设计如下:

schemeManager.register(LocalThumbnail.class, indexSpec -> {
   indexSpec.add(new IndexSpec()
         .setName("spec.imageSignature")
         .setIndexFunc(simpleAttribute(LocalThumbnail.class,
            thumbnail -> thumbnail.getSpec().getImageSignature())
         ));
   indexSpec.add(new IndexSpec()
         .setName("spec.thumbSignature")
         .setUnique(true)
         .setIndexFunc(simpleAttribute(LocalThumbnail.class,
            thumbnail -> thumbnail.getSpec().getThumbSignature())
         ));
});

定义 LocalThumbnailEndpoint 用于提供缩略图 URL 的访问，本地存储策略的图片缩略图规则为：

• Endpoint: /upload/thumbnails/{year}/w{size}/{image-name}
• 存储路径: attachments/thumbnails/{year}/w{size}/{image-name}

示例：

• Endpoint: /upload/thumbnails/2024/w1200/2022-01-01.jpg
• 存储路径: attachments/thumbnails/2024/w1200/2022-01-01.jpg

缩略图生成库选择

在库的选择上，Thumbnailator 和 imgscalr 是最常用的两个缩略图生成库，简单易用且高效。

我们选择使用 imgscalr 作为 Halo 的缩略图生成库，主要基于以下考虑：

• 性能优化： imgscalr 对性能进行了较好的优化，尤其适合处理大量图像或要求较高图像处理速度的场景。
• 高质量的图像处理： imgscalr 提供了多种图像处理模式，可以在性能和图像质量之间找到平衡。

示例代码：

private final URL imageUrl;
private final ThumbnailSize size;
private final Path storePath;

public Mono<Void> generate() {
   return Mono.fromRunnable(() -> {
      String formatName = getFormatName(imageUrl);
      try {
            var img = ImageIO.read(imageUrl);
            BufferedImage thumbnail = Scalr.resize(img, size.getWidth());
            var thumbnailFile = getThumbnailFile(formatName);
            ImageIO.write(thumbnail, formatName, thumbnailFile);
      } catch (IOException e) {
            throw Exceptions.propagate(e);
      }
   });
}

private static String getFormatName(URL input) {
   try {
      return doGetFormatName(input);
   } catch (IOException e) {
      // 获取不到图片格式时，返回 jpg
      return "jpg";
   }
}

private static String doGetFormatName(URL input) throws IOException {
   try (var inputStream = input.openStream();
         ImageInputStream imageStream = ImageIO.createImageInputStream(inputStream)) {
      Iterator<ImageReader> readers = ImageIO.getImageReaders(imageStream);
      if (!readers.hasNext()) {
            throw new IOException("No ImageReader found for the image.");
      }
      ImageReader reader = readers.next();
      return reader.getFormatName().toLowerCase();
   } catch (IOException e) {
      throw new IIOException("Can't get input stream from URL!", e);
   }
}

缩略图使用

主题端

在主题端展示图片时，开发者可以利用 srcset 来实现响应式图片加载。通过在 srcset 属性中定义多个尺寸的图片 URL，浏览器会根据设备的屏幕分辨率和窗口大小，自动选择最合适的图片加载。

选择使用 srcset 的原因包括：

• 响应式设计：srcset 能够根据不同设备的分辨率和屏幕大小，自动选择最佳的图片尺寸。这种机制确保了在高分辨率设备上显示高质量图片的同时，也能够在低分辨率设备上节省带宽。

• 提升加载性能：通过为图片提供多个尺寸的缩略图，浏览器可以选择最适合当前视窗的图片进行加载，从而减少不必要的带宽使用，提升页面加载速度，改善用户体验。

• 简单集成：srcset 的使用非常直观，并且已经得到了主流浏览器的广泛支持。通过在图片标签中定义不同尺寸的图片 URL，开发者可以很容易地利用这个功能。

开发者可以通过定义缩略图的不同尺寸，在 srcset 中实现自动选择最适合的图片。例如：

<img
  th:src="${imageUri}"
  th:srcset="|
      ${thumbnail.gen(imageUri, 's')} 400w,
      ${thumbnail.gen(imageUri, 'm')} 800w,
      ${thumbnail.gen(imageUri, 'l')} 1200w,
      ${thumbnail.gen(imageUri, 'xl')} 1600w
   |"
  sizes="(max-width: 1600px) 100vw, 1600px"
  alt="Example Image"
/>

通过调用 thumbnail.gen(imageUri, size) 方法，开发者可以简便地生成缩略图 URL，并将其应用在 srcset 中，实现图片的响应式加载。

文章内容中的图片

可以考虑同时使用以下两种方式支持:

1. 通过实现 ReactivePostContentHandler 扩展点，然后在 handle 方法中获取文章的 HTML 内容并解析 img 标签的 src 属性得到图片 URL，再根据图片 URL 生成缩略图 URL
   设置到 srcset 属性中，设置 srcset 属性前需要先判断是否已经存在 srcset 属性，如果存在则不再设置，避免覆盖开发者自定义的 srcset 属性。
2. 富文本编辑器中插入图片时，自动为图片设置 srcset 属性，以便在文章发布时自动加载缩略图。

管理端

在管理端，通过获取 Attachment 的 status 中保存的 thumbnails 使用。该值是由 AttachmentReconciler 监听附件的变化，当 permalink 被生成后，生成缩略图 URL 并填充到 status 中。

// when permalink is generated
if (AttachmentUtils.isImage(attachment)) {
   populateThumbnails(permalink, status);
}

void populateThumbnails(String permalink, AttachmentStatus status) {
   var imageUri = URI.create(permalink);
   Flux.fromArray(ThumbnailSize.values())
      .flatMap(size -> thumbnailService.generate(imageUri, size)
            .map(thumbUri -> Map.entry(size.name(), thumbUri.toString()))
      )
      .collectMap(Map.Entry::getKey, Map.Entry::getValue)
      .doOnNext(status::setThumbnails)
      .block();
}

总结

通过以上详细的实现方案设计，Halo 的缩略图功能将具备高度的灵活性和可扩展性，能够满足不同存储策略下的需求，并显著提升系统的性能和用户体验。
开发者在实现和使用该功能时，将能够享受更简洁的代码风格和更优雅的集成方式。

功能实现见 PR #6454

每次踏上回乡的路，我心中总有一种难以言喻的情感。故乡，那片孕育我成长的土地，依然静静地躺在那儿，似乎未曾改变。 然而，每次回到家乡，我都能感受到微妙的变化：曾经喧闹的街道变得冷清，熟悉的邻里变得陌生。家乡没有恶待我，然而我却一次次选择离开，追求更广阔的天地。

从四年级开始，我便离开家乡住校。最初的离别总是伴随着对回家的盼望。那时每次回家，都像是久别重逢的节日，充满了喜悦与期待。然而，十多年过去了，在一次次的回家与离开的过程中，我渐渐明白，故乡已不再是记忆中的样子。每当我回到家乡，看见爷爷奶奶渐渐苍老的身影，我心中不禁涌起一种莫名的酸楚。这些变化无不在提醒我，时间在无情地流逝，而归期却越来越难以觅得。

离家十多年，我踏上征途，是为了生存，也是为了更好地回到故乡。然而，随着时间的推移，我愈发觉得故乡已是回不去了。每年回家，对家里的一切都越来越陌生，找不到东西的存放位置。家乡的变化和发展，让儿时玩耍的地方早已面目全非。家乡的山有的被推平了，有的树木和植被愈发茂密，儿时的小路也已消失无踪。那些捉过鱼的小溪干涸了，爬过的果树也已年老枯死，放过牛的草地也被改成了河道或农田，记忆中的美好景象都已不复存在。

鲁迅在《故乡》中，也描述了类似的感受。他回到故乡时，看到儿时的好友闰土已变成一个满脸沧桑的中年人。记忆中的闰土，那个快乐自由的少年，如今已被生活的重担压弯了腰。鲁迅笔下的故乡，在他离开多年后，已经物是人非。闰土的变化让他深感时间的无情和故乡的沉寂。这种割裂的感受让我深刻体会到，追梦的路上，不仅有对未来的向往，还有对故乡的怀念和无奈的告别。

每当我踏入都市的喧嚣，面对充满挑战与机遇的生活，我都能感受到自己的成长。而回到家乡，那种静止的感觉让我无法忽视。尽管内心对故乡充满眷恋，但现实的无奈让我不得不一次次地离开。

时间是无情的，对每个人都是公平的。每次回家，我都能清晰地看到父母额头上增添的皱纹，发间多了几缕白发。他们的衰老提醒着我，时间在悄无声息地流逝。同学聚会时，我们谈论着各自的生活，曾经的玩伴如今已走上不同的道路，这种变化无时无刻不在提醒我时间的无情。

在这无情的时间洪流中，亲情却显得格外温暖。父母每天忙碌的身影，对我的关心和牵挂，让我感受到无比的温暖。他们日常生活中的爱与关怀，是我在外打拼的最大动力。时间无情，但亲情的温暖总能给我力量，让我在追求梦想的路上不再孤单。

虽然家乡有着无数的美好，但我深知，那并不是我的归宿。我不愿再种一辈子地，我渴望追求更多的精神自由和个人梦想。每一次的离开，都是一次自我的突破和成长。

通过鲁迅的《故乡》，我逐渐明白，个人的追求和梦想是多么重要。家乡的美好无法满足我的精神需求，只有不断追求，才能找到真正属于自己的生活方式。正如鲁迅所写：“在我的心里早已有了一个新的‘故乡’，它在那里，它在每一个人的心里。”

我承认，自己对衰老充满恐惧，但并不畏惧死亡。衰老带来的不仅是身体的变化，还有精神上的煎熬。我希望在有限的时间里，尽可能延长快乐的时光，过上自己满意的生活。

《故乡》中，少年闰土的影像和如今的变化让我意识到时间的无情，但也让我更加珍惜现在的时光。对我来说，美好生活不仅仅是物质上的满足，更是精神上的富足。我希望能够在有限的时间里，尽可能地追求自己的梦想，过上充实而有意义的生活。

人的一生，还需要求得些什么呢？
在追求梦想的过程中，我逐渐领悟到，最珍贵的往往是那些最简单的幸福。每当繁忙的都市生活让我感到疲惫不堪时，我总是会想起故乡的宁静和温暖。

我希望父母健康，自己无病无灾，能够平安度日。这种简单的生活愿望，蕴含着对平凡而持久幸福的渴望。同时，我也希望能够多看看世界，多了解人生，追求爱与自由。生活不需要太复杂，只要能在有限的时间里体验到美好，就已经足够了。

在追求梦想的路上，我希望能够找到平衡点，让自己和家人都能过上幸福的生活。正如鲁迅在《故乡》中所言：“我想，这就是我永远的‘故乡’了。”那份对故乡的眷恋与对美好事物的追求，都是我心中最真实的情感，让生活变得更加丰富和有意义。

前言

Halo 是一个强大易用的开源建站工具，配合上丰富的主题和插件，帮助用户快速搭建个人博客、企业站点、知识库、文档站等多种类型的网站。具备可插拔架构、主题套用、富文本编辑器等多重特性，支持用户根据自己的喜好选择不同类型的插件及主题模板来定制化自己的站点功能及外观。让内容创作和发布更加便捷生动。

截至今日，Halo 已经在 GitHub 上拥有 32.5 k+ Star，Docker Hub 获得了超过 220 万次下载，并拥有一百多名社区贡献者。

背景介绍

在 Halo 2.16 版本中，我为 Halo 添加了一个记住我（Remember Me）的功能，用户可以选择在登录时勾选 "Remember Me"，这样下次访问时就不需要重新登录。

该功能是通过以下方式生成 Token，并将其作为 cookie 发送回客户端：

 username + ":" + expiryTime + ":" + algorithmName + ":"
   + algorithmHex(username + ":" + expiryTime + ":" + password + ":" + key)

这样实现的优点在于无需在后端存储 Token 就可以进行验证，并且用户密码的更改会自动使 Token 失效而无需做任何额外的处理。然而，它的主要缺点是缺乏管理能力，例如无法手动撤销 Token。

在 2.17 之前由于没有需要手动撤销 Token 的需求，因此这个实现是足够的。但是在 2.17 中，我引入了设备管理功能，基于原有的 RememberMe Token 机制，撤销设备的登录状态时无法撤销勾选了 RememberMe 的设备登录状态，因为会自动登录，因此需要一个可管理的 RememberMe Token 机制。

基于这样的原因，决定采用了持久化 Token 的方式，并通过随机生成 TokenValue 的方法来提高安全性，而不将用户名和密码直接签名在 Token 中。实现机制采用 Barry Jaspan 提出的改进的持久登录 Cookie 最佳实践。

基于签名 Token 的实现

在原有的 Token 机制中，用户勾选 "Remember Me" 后，系统会生成一个包含用户名和 Token 的 cookie。服务器端不需要存储 Token，只需在用户访问时验证 Token 的有效性即可。系统会解密 Token 并验证用户名和密码是否匹配，若匹配则设置登录状态。

实现方式和原理

关键代码如下：

autoLogin 方法会在用户访问且没有登录的状态下执行一次，用于尝试自动登录。

1. 首先从 ServerWebExchange 中获取名为 remember-me 的 Cookie 的值，这件事由 RememberMeCookieResolver 完成。
2. 如果没有获取到 Cookie，则返回一个空的 Mono，表示没有自动登录。
3. 如果获取到了 Cookie，则解码 Cookie 的值，获取到 cookieTokens，然后调用 processAutoLoginCookie 方法进行处理。cookieTokens 由以下部分组成，使用 : 分隔：
   • 用户名
   • 过期时间
   • 算法名称
   • 签名 algorithmHex(username + ":" + expiryTime + ":" + password + ":" + key)

public Mono<Authentication> autoLogin(ServerWebExchange exchange) {
    var rememberMeCookie = rememberMeCookieResolver.resolveRememberMeCookie(exchange);
    if (rememberMeCookie == null) {
        return Mono.empty();
    }
    log.debug("Remember-me cookie detected");
    return Mono.defer(
            () -> {
                String[] cookieTokens = decodeCookie(rememberMeCookie.getValue());
                return processAutoLoginCookie(cookieTokens, exchange);
            })
        .flatMap(user -> {
            this.userDetailsChecker.check(user);
            log.debug("Remember-me cookie accepted");
            return createSuccessfulAuthentication(exchange, user);
        })
        .onErrorResume(ex -> handleError(exchange, ex));
}

protected String[] decodeCookie(String cookieValue) throws InvalidCookieException {
    int paddingCount = 4 - (cookieValue.length() % 4);
    if (paddingCount < 4) {
        char[] padding = new char[paddingCount];
        Arrays.fill(padding, '=');
        cookieValue += new String(padding);
    }
    String cookieAsPlainText;
    try {
        cookieAsPlainText = new String(Base64.getDecoder().decode(cookieValue.getBytes()));
    } catch (IllegalArgumentException ex) {
        throw new InvalidCookieException(
            "Cookie token was not Base64 encoded; value was '" + cookieValue + "'");
    }
    String[] tokens = StringUtils.delimitedListToStringArray(cookieAsPlainText, DELIMITER);
    for (int i = 0; i < tokens.length; i++) {
        tokens[i] = URLDecoder.decode(tokens[i], StandardCharsets.UTF_8);
    }
    return tokens;
}

需要注意的是 Cookie 的值是经过 Base64 编码的，但是 Cookie 值不允许出现 =，因此在编码时会移除 =，而解码时需要补全 =，补全机制根据 Base64 编码后的长度必须是 4 的倍数不足的部分用 = 补全的特点作为依据。

得到 cookieTokens 后调用 processAutoLoginCookie 方法进行自动登录的校验和处理逻辑。

1. 首先校验 cookieTokens 的长度是否为 4，不是则抛出异常。
2. 校验 cookieTokens 的第二个元素的过期时间是否在当前时间之后，不是则抛出异常。
3. 获取 cookieTokens 的第一个元素作为用户名，根据用户名从数据库中获取用户信息, 如果用户不存在则抛出异常。
4. 从 cookieTokens 中获取算法名称和签名，根据用户名、过期时间、密码和密钥计算签名，如果生成的签名与 cookieTokens 中的签名不一致则抛出异常。
5. 最终返回 UserDetails 由 createSuccessfulAuthentication 方法创建 Authentication。

protected Mono<UserDetails> processAutoLoginCookie(String[] cookieTokens,
    ServerWebExchange exchange) {
    if (!isValidCookieTokensLength(cookieTokens)) {
        throw new InvalidCookieException(
            "Cookie token did not contain 3 or 4 tokens, but contained '" + Arrays.asList(
                cookieTokens) + "'");
    }

    long tokenExpiryTime = getTokenExpiryTime(cookieTokens);
    if (isTokenExpired(tokenExpiryTime)) {
        throw new InvalidCookieException(
            "Cookie token[1] has expired (expired on '" + new Date(tokenExpiryTime)
                + "'; current time is '" + new Date() + "')");
    }

    // Check the user exists. Defer lookup until after expiry time checked, to
    // possibly avoid expensive database call.
    return getUserDetailsService().findByUsername(cookieTokens[0])
        .switchIfEmpty(Mono.error(new UsernameNotFoundException("User '" + cookieTokens[0]
            + "' not found")))
        .flatMap(userDetails -> {
            // Check signature of token matches remaining details. Must do this after user
            // lookup, as we need the DAO-derived password. If efficiency was a major issue,
            // just add in a UserCache implementation, but recall that this method is usually
            // only called once per HttpSession - if the token is valid, it will cause
            // SecurityContextHolder population, whilst if invalid, will cause the cookie to
            // be cancelled.
            String actualTokenSignature;
            String actualAlgorithm = DEFAULT_ALGORITHM;
            // If the cookie value contains the algorithm, we use that algorithm to check the
            // signature
            if (cookieTokens.length == 4) {
                actualTokenSignature = cookieTokens[3];
                actualAlgorithm = cookieTokens[2];
            } else {
                actualTokenSignature = cookieTokens[2];
            }
            return makeTokenSignature(tokenExpiryTime, userDetails.getUsername(),
                userDetails.getPassword(), actualAlgorithm)
                .doOnNext(expectedTokenSignature -> {
                    if (!equals(expectedTokenSignature, actualTokenSignature)) {
                        throw new InvalidCookieException(
                            "Cookie contained signature '" + actualTokenSignature
                                + "' but expected '"
                                + expectedTokenSignature + "'");
                    }
                })
                .thenReturn(userDetails);
        });
}

protected Mono<String> makeTokenSignature(long tokenExpiryTime, String username, String password, String algorithm) {
    return getKey()
        .handle((key, sink) -> {
            String data = username + ":" + tokenExpiryTime + ":" + password + ":" + key;
            try {
                MessageDigest digest = MessageDigest.getInstance(algorithm);
                sink.next(new String(Hex.encode(digest.digest(data.getBytes()))));
            } catch (NoSuchAlgorithmException ex) {
                sink.error(
                    new IllegalStateException("No " + algorithm + " algorithm available!"));
            }
        });
}

private long getTokenExpiryTime(String[] cookieTokens) {
    try {
        return Long.parseLong(cookieTokens[1]);
    } catch (NumberFormatException nfe) {
        throw new InvalidCookieException(
            "Cookie token[1] did not contain a valid number (contained '" + cookieTokens[1]
                + "')");
    }
}

protected long calculateExpireTime(ServerWebExchange exchange,
  Authentication authentication) {
  var tokenLifetime = rememberMeCookieResolver.getCookieMaxAge().toSeconds();
  return Instant.now().plusSeconds(tokenLifetime).toEpochMilli();
}

详情请查看 GitHub Halo PR #6131

问题：

1. 难以管理：Token 只能通过过期失效，无法手动让其失效，导致难以实现精细化的设备管理。
2. 安全隐患：一旦 Token 被盗，攻击者可以持续访问直到 Token 过期，而用户可能未察觉到账户被盗用。

新的持久化 Token 机制

Barry Jaspan 提出的持久化 Token 机制改进了上述不足，其核心思想是通过 "系列标识符" 和 "Token" 的组合来实现更安全和可管理的持久化登录机制。

实现方式和原理

登录时生成系列标识符和 Token：

• 用户成功登录并勾选 "Remember Me" 后，系统会生成一个包含用户名、系列标识符（series）和 Token 的 cookie。
• 系列标识符和 Token 都是随机生成且难以猜测的字符串，服务器会将这三个元素存储在数据库中。

以下是持久化 Token 的自定义模型设计：

apiVersion: security.halo.run/v1alpha1
kind: RememberMeToken
metadata:
  name: token-TrpNE
  creationTimestamp: 2024-07-08T10:00:41.796765067Z
spec:
  username: guqing
  series: 12dFjDr4Ugspgk0oMugxap==
  tokenValue: tF269aPzYCnQmKL/rX5uJo==
  lastUsed: 2024-07-08T10:01:45.520Z

series 作为唯一标识符，用于查询 tokenValue。

验证过程：

• 当用户携带该 cookie 访问时，系统会比对用户名、series 和 tokenValue。
• 若匹配，用户通过验证，旧 Token 被移除并生成一个新的 Token，更新数据库和 cookie。
• 若系列标识符(series)匹配但 Token 不匹配，系统假定发生了盗用行为，用户所有的持久化登录会被注销，并提示安全警告。
• 若用户名和系列标识符都不匹配，忽略该 cookie。

Token 的生成和验证：
基于持久化 Token 的机制，Cookie 的值由 series 和 tokenValue 组成，并使用 : 分隔后进行 Base64 编码。

setCookie(new String[] {token.getSeries(), token.getTokenValue()}, exchange);

void setCookie(String[] cookieTokens, ServerWebExchange exchange) {
  String cookieValue = encodeCookie(cookieTokens);
  rememberMeCookieResolver.setRememberMeCookie(exchange, cookieValue);
}

因此，在验证时需要解码 Cookie 的值，获取 series 和 tokenValue，然后根据 series 从数据库中获取 tokenValue 进行比对。

protected Mono<UserDetails> processAutoLoginCookie(String[] cookieTokens,
    ServerWebExchange exchange) {
    if (cookieTokens.length != 2) {
        throw new InvalidCookieException(
            "Cookie token did not contain " + 2 + " tokens, but contained '"
                + Arrays.asList(cookieTokens) + "'");
    }
    String presentedSeries = cookieTokens[0];
    String presentedToken = cookieTokens[1];
    return this.tokenRepository.getTokenForSeries(presentedSeries)
        // No series match, so we can't authenticate using this cookie
        .switchIfEmpty(Mono.error(new RememberMeAuthenticationException(
            "No persistent token found for series id: " + presentedSeries))
        )
        .flatMap(token -> {
            // We have a match for this user/series combination
            if (!presentedToken.equals(token.getTokenValue())) {
                // Token doesn't match series value. Delete all logins for this user and throw
                // an exception to warn them.
                return this.tokenRepository.removeUserTokens(token.getUsername())
                    .then(Mono.error(new CookieTheftException(
                        "Invalid remember-me token (Series/token) mismatch. Implies previous "
                            + "cookie theft"
                            + " attack.")));
            }

            if (isTokenExpired(token)) {
                return Mono.error(
                    new RememberMeAuthenticationException("Remember-me login has expired"));
            }

            // Token also matches, so login is valid. Update the token value, keeping the
            // *same* series number.
            log.debug("Refreshing persistent login token for user '{}', series '{}'",
                token.getUsername(), token.getSeries());
            var newToken = new PersistentRememberMeToken(token.getUsername(), token.getSeries(),
                generateTokenData(), new Date());
            return Mono.just(newToken);
        })
        .flatMap(newToken -> updateToken(newToken)
            .doOnSuccess(unused -> addCookie(newToken, exchange))
            .onErrorMap(ex -> {
                log.error("Failed to update token: ", ex);
                return new RememberMeAuthenticationException(
                    "Autologin failed due to data access problem");
            })
            .then(getUserDetailsService().findByUsername(newToken.getUsername()))
        );
}

protected String generateSeriesData() {
    byte[] newSeries = new byte[this.seriesLength];
    this.random.nextBytes(newSeries);
    return new String(Base64.getEncoder().encode(newSeries));
}

protected String generateTokenData() {
    byte[] newToken = new byte[this.tokenLength];
    this.random.nextBytes(newToken);
    return new String(Base64.getEncoder().encode(newToken));
}

关于上述实现的具体细节参考 GitHub Halo PR #6131

遇到的问题:

经过使用后发现，部分用户反馈记住我功能失效的问题，经过排查发现是由于每次使用后都会更新 Token，但这个更新的过程中可能由于并发问题或者用户关闭浏览器导致 Cookie 的值未被写入浏览器导致用户下次访问时无法自动登录，并且判定为盗用行为。因此不再每次使用后都更新 Token，只更新最后使用时间。
参考 GitHub Halo PR #6329

新机制的优点

1. 提升安全性：

   • 可以直观的查看 Token 最后用于登录的时间，并且可以随时可以撤销 Token。
   • 引入系列标识符，有效检测并应对 cookie 盗用行为。

2. 改进用户体验：

   • 用户无需频繁重新登录，持久化登录体验更流畅。
   • 支持设备管理，用户可以查看和管理所有登录设备，提高透明度和控制力。

结论

通过这次重构，Halo 不仅增强了系统的安全性和可靠性，还大幅提升了用户体验，进一步巩固了其作为开源建站工具的竞争力。这一改进将为广大用户带来更加安全和便捷的使用体验。

同时，这次重构也让我更加深入理解了持久化 Token 的机制，对于后续的系统设计和开发工作也有了更多的启发和借鉴，功能的完善和优化是一个不断迭代的过程，不会在一开始就完美，就像本次重构一样，只有真正适合当前使用场景的实现方式才是最好的，过度设计和不必要的复杂性只会增加系统的维护成本，当实现方式不再适用时，及时调整和优化才是最重要的。

随着 2023 年的落幕，回首这一年，依旧是一段不平凡的开源旅程。在 GitHub 的宇宙中，我以一名 Java 软件工程师的身份，不断探索和创造，将我的代码和热情贡献给了多个令人敬畏的项目。

追求卓越：不断增长的数字

今年，我在 GitHub 上的贡献：

• 提出了 86 个 Issues：我不仅解决问题，也提出问题，促进了项目的进步。
• 提交了 174 个 Pull Requests：每一次提交都是我对代码质量的承诺。
• 825 次 Code Reviews：我认真审视每一行代码，确保其达到我认为的最高标准。
• 383 次 Commits：这些提交见证了我的坚持和项目的进步。
• 274 个贡献活跃日：几乎每天都有我的身影，我的热情在代码中焕发光芒。
• 最长连续贡献 25 天：这段时间，我全身心投入开源项目，享受着编码带来的乐趣。

主要偏重于对于 halo 主仓库 的贡献，我为其贡献了 ~43k 行代码。
去年在 GitHub 的贡献包括 49,000 行代码添加和16,000 行代码删除。这不仅展示了我对开源的热情，更是我对提升项目质量和持续推动项目发展的坚定承诺的体现。

时间与热情的投入

在这一年中，我共计投入了 1012 小时 编写代码，平均每天 3 小时 49 分钟。这个数字背后，是我对技术的热爱和对开源精神的执着。特别是，在 Java 语言上，我投入了 676 小时 52 分钟，这些时间里，我不断学习、实践并优化我的技术。

创新与合作：新的开始和伙伴关系

在这一年里，我新创建并完成了 10 个代码仓库，包括:

• plugin-docsme：Docsme 插件为 Halo 提供项目文档管理功能，支持多文档项目、多语言、多版本。
• halo-gradle-plugin：一个 Gradle 插件，为 Halo 插件开发的工具链，用于提升 Halo 插件开发的体验和流程。
• willow-mde：是一款漂亮、现代且可定制的  Halo  的 Markdown 编辑器插件。使用 Ink MDE、Vue.js、Typescript 以及  CodeMirror  构建。
• plugin-oauth2: 适用于 Halo 2.x 的 OAuth2 第三方登录插件。
• ghu-events-moments：定时同步 GitHub 的 User public events 为 Halo 的瞬间用于在自己博客展示在 GitHub 上的贡献活动。
• plugin-links: Halo 2.x 的链接管理插件，用于为网站提供友情链接管理和展示功能。
• plugin-sitemap：Halo 2.x 的站点 Sitemap 生成插件，便于搜索引擎抓取网站数据，优化 SEO。
• halo-plugin-colorless：实现让 Halo 主题都展示为灰白效果，一个展示如何扩展 Halo 主题端的示例项目。
• telegram-bot-halo：Telegram 机器人，用于快捷发送瞬间到自己的博客。

等，每一个都是我探索新领域和技术的见证。

此外，我还参与了多个项目的贡献，包括:

• halo-dev/halo: 强大易用的开源建站工具。
• plugin-moments：适用于 Halo 2.x 的瞬间插件，可以用来管理和发布杂记和心情。
• guqing-higan：适用于 Halo 2.x 的一款简洁而不失优雅的博客主题。
• plugin-backup：Halo 2.x 的增强备份插件，针对原有备份功能进行增强，可实现定时备份，同步备份至远端存储，为数据保驾护航。
• plugin-bytemd：为 Halo 2.x 集成 ByteMD 编辑器，提供 Markdown 编辑功能。
• plugin-katex：为 Halo 2.x 默认编辑器和文章渲染提供 KaTeX 支持。
• plugin-lightgallery：Halo 2.x 的插件，集成 lightgallery.js，支持在内容页面放大显示图片
• plugin-comment-widget：通用的 Halo 2.x 评论组件插件。
• plugin-migrate：支持多种平台的数据迁移 Halo 的 Halo 2.x 插件。
• awesome-halo：与 Halo 相关的周边生态资源列表。
• halo-plugin-webhook：为 Halo 2.0 提供 Webhook 支持，该插件允许用户在特定事件发生时（如文章发布、更新等）发送通知到指定的 Webhook URL。
• plugin-app-store-server: Halo 应用市场。

等。这些贡献经历不仅丰富了我的技术栈，也让我结识了来自世界各地的优秀开发者，共同推动了开源项目的发展。

展望未来

回顾这一年的旅程，我为我的成长和所取得的成就感到自豪。在即将到来的一年里，我期待着踏上新的旅程，继续我的开源贡献，与全球的开发者们一起，共同推动技术的边界。

曾经，在那些灿烂星光似的年华里，我们怀揣着改变世界的梦想。每一颗心中，都燃烧着对未知的向往，对平凡的轻视。在我们的眼中，父母、前辈们的生活仿佛是一潭死水，我们誓言，绝不会步他们的后尘。

我们渴望的，是一段非凡的旅程，一个非比寻常的人生。我们勇往直前，心怀理想，却不知理想的路途如此坎坷。岁月如沙，悄然从指间溜走，每一次跌倒，每一次心灵的创伤，都在无声地教会我们生活的残酷和现实的重量。

年轻的激情渐被现实磨平，那些曾经雄心勃勃的梦想，似乎也在悄然退色。我们开始意识到，自己也许并不比别人更特别。工作的压力、灵鑫的空虚、生活的磨难……这一切像巨石般压在胸口，让人喘不过气来。那个曾经振翅高飞的自我，现在似乎只能在现实的桎梏中，过着那种“普通”的人生。

无人愿意承认自己的平凡，无人愿意面对失败的人生。但不论我们如何抗拒，时间总会悄然改变我们。那些年少轻狂的梦想，仿佛已被封存于记忆的最深处。

然而，即使我们最终都成为了曾经不愿成为的“大人”，那份对美好生活的向往，仍旧藏在心底。也许，真正的成长，不是放弃理想，而是在理想与现实之间，找到了属于自己的平衡。

我们的每一步，虽不再轻盈，却更加坚定。我们学会了在平凡中寻找意义，在琐碎中发现快乐。生活，不再是一场盲目的追逐，而是成为了一种内心的安宁和自我实现。

如此，我们继续行走在人生的道路上，带着曾经的梦想，面向未来的无限可能。

背景

在 Halo 系统中，具有用户协作属性，如当用户发布文章后被访客评论而访客希望在作者回复评论时被提醒以此完成进一步互动，而在没有通知功能的情况下无法满足诸如以下描述的使用场景：

1. 访客只能在评论后一段时间内访问被评论的文章查看是否被回复。
2. Halo 的用户注册功能无法让用户验证邮箱地址让恶意注册变的更容易。

在这些场景下，为了让用户收到通知或验证消息以及管理和处理这些通知，我们需要设计一个通知功能，以实现根据用户的订阅和偏好推送通知并管理通知。

已有需求

• 访客评论文章后希望收到被回复的通知，而文章作者也希望收到文章被评论的通知。
• 用户注册功能希望验证注册者填写的邮箱实现一个邮箱只能注册一个账号，防止占用别人邮箱，在一定程度上减少恶意注册问题。
• 关于应用市场插件，管理员希望在用户下单后能收到新订单通知。
• 付费订阅插件场景，希望给付费订阅用户推送付费文章的浏览链接。

目标

设计一个通知功能，可以根据以下目标，实现订阅和推送通知：

• 支持扩展多种通知方式，例如邮件、短信、Slack 等。
• 支持通知条件并可扩展，例如 Halo 有新文章发布事件如果用户订阅了新文章发布事件但付费订阅插件决定了此文章只有付费用户才可收到通知、按照付费等级不同决定是否发送新文章通知给对应用户等需要通过实现通知条件的扩展点来满足对应需求。
• 支持定制化选项，例如是否开启通知、通知时段等。
• 支持通知流程，例如通知的发送、接收、查看、标记等。
• 通知内容支持多语言。
• 事件类型可扩展，插件可能需要定义自己的事件以通知到订阅事件的用户，如应用市场插件。

非目标

• Halo 只会实现站内消息和邮件通知，更多通知方式需要插件去扩展。
• 定时通知、通知频率或摘要通知功能属于非必要功能，可由插件去扩展。
• 多语言支持，目前只会支持中文和英文两种，更多语言支持不是此阶段的目标。
• 可定制的通知模板：通知默认模板由事件定义者提供，如需修改可考虑使用特定的 Notifier 去适配事件。

方案

为了实现上述目标，我们设计了以下方案：

通知数据模型

通知事件类别和事件

首先通过定义事件来声明此通知事件包含的数据和发送此事件时默认使用的模板。

ReasonType 是一个自定义模型，用于定义事件类别，一个事件类别由多个事件表示。

apiVersion: notification.halo.run/v1alpha1
kind: ReasonType
metadata:
  name: comment
spec:
  displayName: "Comment Received"
  description: "The user has received a comment on an post."
  properties:
    - name: postName
      type: string
      description: "The name of the post."
      optional: false
    - name: postTitle
      type: string
      optional: true
    - name: commenter
      type: string
      description: "The email address of the user who has left the comment."
      optional: false
    - name: comment
      type: string
      description: "The content of the comment."
      optional: false

Reason 是一个自定义模型，用于定义通知原因，它属于 ReasonType 的实例。

当有事件触发时，创建 Reason 资源来触发通知，如当文章收到一个新评论时：

apiVersion: notification.halo.run/v1alpha1
kind: Reason
metadata:
  name: comment-axgu
spec:
  # a name of ReasonType
  reasonType: comment
  author: 'guqing'
  subject:
    apiVersion: 'content.halo.run/v1alpha1'
    kind: Post
    name: 'post-axgu'
    title: 'Hello World'
    url: 'https://guqing.xyz/archives/1'
  attributes:
    postName: "post-fadp"
    commenter: "guqing"
    comment: "Hello! This is your first notification."

Subscription

Subscription 自定义模型，定义了特定事件时与要被通知的订阅者之间的关系, 其中 subscriber 表示订阅者用户, unsubscribeToken 表示退订时的身份验证 token, reason 订阅者感兴趣的事件。

用户可以通过 Subscription 来订阅自己感兴趣的事件，当事件触发时会收到通知：

apiVersion: notification.halo.run/v1alpha1
kind: Subscription
metadata:
  name: user-a-sub
spec:
  subscriber:
    name: guqing
  unsubscribeToken: xxxxxxxxxxxx
  reason:
    reasonType: new-comment-on-post
    subject:
      apiVersion: content.halo.run/v1alpha1
      kind: Post
      name: 'post-axgu'

订阅退订链接 API 规则：
/apis/api.notification.halo.run/v1alpha1/subscriptions/{name}/unsubscribe?token={unsubscribeToken}。

用户通知偏好设置

通过在用户偏好设置的 ConfigMap 中存储一个 notification key 用于保存事件类型与通知方式的关系设置，当用户订阅了如 ‘new-comment-on-post’ 事件时会获取对应的通知方式来给用户发送通知。

apiVersion: v1alpha1
kind: ConfigMap
metadata:
  name: user-preferences-guqing
data:
  notification: |
    {
      reasonTypeNotification: {
        'new-comment-on-post': {
          enabled: true,
          notifiers: [
            email-notifier,
            sms-notifier
          ]
        },
        new-post: {
          enabled: true,
          notifiers: [
            email-notifier,
            webhook-router-notifier
          ]
        }
      },
    }

Notification 站内通知

当用户订阅到事件后会创建 Notification, 它与通知方式（notifier）无关，recipient 为用户名，类似站内通知，如用户 guqing 订阅了评论事件那么当监听到评论事件时会创建一条记录可以在个人中心的通知列表看到一条通知消息。

apiVersion: notification.halo.run/v1alpha1
kind: Notification
metadata:
  name: notification-abc
spec:
  # username
  recipient: "guqing"
  reason: 'comment-axgu'
  title: 'notification-title'
  content: 'notification-body'
  unread: true
  lastReadAt: '2023-08-04T17:01:45Z'

个人中心通知自定义 APIs:

1. 获取个人中心获取用户通知列表的 APIs 规则：
   GET /apis/api.console.halo.run/v1alpha1/userspaces/{username}/notifications
2. 将通知标记为已读：PUT /apis/api.console.halo.run/v1alpha1/userspaces/{username}/notifications/mark-as-read
3. 批量将通知标记为已读：PUT /apis/api.console.halo.run/v1alpha1/userspaces/{username}/notifications/mark-specified-as-read

通知模板

NotificationTemplate 自定义模型用于定义事件的通知模板，当事件触发时会根据事件的通知模板来渲染通知内容。
它通过定义 reasonSelector 来引用事件类别，当事件触发时会根据用户的语言偏好和触发事件的类别来选择一个最佳的通知模板。
选择通知模板的规则为：

1. 根据用户设置的语言，选择从通知模板中定义的 spec.reasonSelector.language 的值从更具体到不太具体的顺序（例如，gl_ES 的值将比 gl 的值具有更高的优先级）。
2. 当通过语言成功匹配到模板时，匹配到的结果可能不止一个，如 language 为 zh_CN 的模板有三个那么会根据 NotificationTemplate 的 metadata.creationTimestamp 字段来选择一个最新的模板。

这样的规则有助于用户可以个性化定制某些事件的模板内容。

模板语法使用 ThymeleafEngine 渲染，纯文本模板使用 textual 模板模式，语法参考: usingthymeleaf.html#textual-syntax

HTML 则使用标准表达式语法在标签属性中取值，语法参考：standard-expression-syntax

在通知中心渲染模板时会在 ReasonAttributes 中提供额外属性包括：

• siteTitle: 站点标题
• siteSubtitle: 站点副标题
• siteLogo: 站点 LOGO
• subscriber: 订阅者的用户名
• unsubscribeUrl: 退订链接，用于取消订阅

因此，任何模板都可以使用这几个属性，但事件定义者需要注意避免使用这些保留属性。

apiVersion: notification.halo.run/v1alpha1
kind: NotificationTemplate
metadata:
  name: template-new-comment-on-post
spec:
  reasonSelector:
    reasonType: new-comment-on-post
    language: zh_CN
  template:
    title: "你的文章 [(${postTitle})] 收到了一条新评论"
    body: |
      [(${commenter})] 评论了你的文章 [(${postTitle})]，内容如下：
      [(${comment})]

通知器声明及扩展

NotifierDescriptor 自定义模型用于声明通知器，通过它来描述通知器的名称、描述和关联的 ExtensionDefinition 名称，让用户可以在用户界面知道通知器是什么以及它可以做什么,
还让 NotificationCenter 知道如何加载通知器和准备通知器需要的设置以发送通知。

apiVersion: notification.halo.run/v1alpha1 
kind: NotifierDescriptor
metadata:
  name: email-notifier
spec:
  displayName: '邮件通知器'
  description: '支持通过邮件的方式发送通知。'
  notifierExtName: '通知对应的扩展名称'
  senderSettingRef:
    name: 'email-notifier'
    group: 'sender'
  receiverSettingRef:
    name: 'email-notifier'
    group: 'receiver'

通知器声明了 senderSettingRef 和 receiverSettingRef 后，对应用户端可以通过以下 APIs 获取和保存配置：

管理员获取和保存通知器发送配置的 APIs:

1. 获取通知器发送方配置：GET /apis/api.console.halo.run/v1alpha1/notifiers/{name}/senderConfig
2. 保存通知器发送方配置：POST /apis/api.console.halo.run/v1alpha1/notifiers/{name}/senderConfig

个人中心用户获取和保存对应通知器接收消息配置的 APIs:

1. 获取通知器接收消息配置：GET /apis/api.console.halo.run/v1alpha1/notifiers/{name}/receiverConfig
2. 获取通知器接收消息配置：POST /apis/api.console.halo.run/v1alpha1/notifiers/{name}/receiverConfig

通知器扩展点用于实现发送通知的方式：

public interface ReactiveNotifier extends ExtensionPoint {

    /**
     * Notify user.
     *
     * @param context notification context must not be null
     */
    Mono<Void> notify(NotificationContext context);
}

@Data
public class NotificationContext {
    private Message message;

    private ObjectNode receiverConfig;

    private ObjectNode senderConfig;

    @Data
    static class Message {
      private MessagePayload payload;

      private Subject subject;

      private String recipient;

      private Instant timestamp;
    }

    @Data
    public static class Subject {
      private String apiVersion;
      private String kind;
      private String name;
      private String title;
      private String url;
    }

    @Data
    static class MessagePayload {
      private String title;

      private String body;

      private ReasonAttributes attributes;
    }
}

通知数据结构交互图

通知功能 UI 设计

通知模块功能

• 发送通知：当触发通知事件时，系统会根据 subscriber 的偏好设置获取到事件对应的通知方式再根据偏好设置自动发送通知。
• 接收通知：用户可以选择接收通知的方式，例如邮件、短信、自定义路由通知等。
• 查看通知：用户可以在 Halo 中查看所有的通知，包括已读和未读的通知。
• 标记通知：用户可以标记通知为已读或未读状态，以便更好地管理和处理通知。

通知管理列表条件筛选

我们支持以下通知条件筛选策略：

• 按事件类型：列出特定类型的事件通知，例如新文章，新评论、状态更新等。
• 按已读状态：根据通知是否已读列出，方便用户查看未读通知。
• 按关键词：列出通知中包含特定关键词的事件通知，例如包含用户名称、标题等关键词的通知。
• 按时间：列出在特定时间段内发生的事件通知，例如最近一周、最近一个月等时间段内的通知。

定制化选项

如果后续有足够的使用场景，可以考虑支持以下定制化选项：

• 通知时间段：用户可以设置通知的时间段，例如只在工作时间内推送通知。
• 通知频率：用户可以设置通知的频率，例如每天、每周、每月等。
• 摘要通知：用户可以设置接收每周摘要，总结一周内的通知合并为一条通知并通过如邮件等方式接收。

结论

通过以上方案和实现，我们设计了一个通知功能，可以根据用户的需求和偏好，自动筛选和推送通知。同时，为了支持更多的事件类型、通知方式和通知条件筛选策略，系统具有良好的可扩展性。

前言

前段时间在 Halo 的 应用市场 中遇到希望主题和插件的封面图背景色为封面图主色的问题，于是乎需要根据封面图提取主色就想到使用 K-Means 算法来提取。

在图像处理中，图像是由像素点构成的，每个像素点都有一个颜色值，颜色值通常由 RGB 三个分量组成。因此，我们可以将图像看作是一个由颜色值构成的点云，每个点代表一个像素点。

为了更好地理解，我们可以将图像的颜色值可视化为一个 Scatter 3D 图。在 Scatter 3D 图中，每个点的坐标由 RGB 三个分量组成，点的颜色与其坐标对应的颜色值相同。

图像的颜色值量化

以下面的图片为例

它的色值分布为如下的图像

从上述 RGB 3D Scatter Plot 图如果将相似的颜色值归为一类可以看出图像大概有三种主色调蓝色、绿色和粉色：

如果我们从三簇中各选一个中心，如以 A、B、C三点表示 A(50, 150, 200)、B(240, 150, 200)、C(50, 100, 50) 并将每个数据点分配到最近的中心所在的簇中这个过程称之为聚类而这个中心称之为聚类中心，这样就可以得到 K 个以聚类中心为坐标的主色值。而 K-Means 算法是一种常用的聚类算法，它的基本思想就是将数据集分成 K 个簇，每个簇的中心点称为聚类中心，将每个数据点分配到最近的聚类中心所在的簇中。

K-Means 算法的实现过程如下：

1. 初始化聚类中心：随机选择 K 个点作为聚类中心。

2. 分配数据点到最近的聚类中心所在的簇中：对于每个数据点，计算它与每个聚类中心的距离，将它分配到距离最近的聚类中心所在的簇中。

3. 更新聚类中心：对于每个簇，计算它的所有数据点的平均值，将这个平均值作为新的聚类中心。

4. 重复步骤 2 和步骤 3，直到聚类中心不再改变或达到最大迭代次数。

在图像处理中，我们可以将每个像素点的颜色值看作是一个三维向量，使用欧几里得距离计算两个颜色值之间的距离。对于每个像素点，我们将它分配到距离最近的聚类中心所在的簇中，然后将它的颜色值替换为所在簇的聚类中心的颜色值，如 A1(10, 140, 170) 以距离它最近的距离中心 A 的坐标表示即 A1 = A(50, 150, 200)。这样，我们就可以将图像中的颜色值进行量化，将相似的颜色值归为一类。

最后，我们可以根据聚类中心的颜色值，计算每个颜色值在图像中出现的次数，并按出现次数从大到小排序，取前几个颜色作为主要颜色。

<script>
  const img = new Image();
  img.src = "https://guqing-blog.oss-cn-hangzhou.aliyuncs.com/image.jpg";
  img.setAttribute("crossOrigin", "");

  img.onload = function () {
    const canvas = document.createElement("canvas");
    const ctx = canvas.getContext("2d");
    canvas.width = img.width;
    canvas.height = img.height;
    ctx.drawImage(img, 0, 0);

    const imageData = ctx.getImageData(0, 0, canvas.width, canvas.height);
    const data = imageData.data;

    const k = 3; // 聚类数
    const centers = quantize(data, k);
    console.log(centers)

    for (const color of centers) {
      const div = document.createElement("div");
      div.style.width = "50px";
      div.style.height = "50px";
      div.style.backgroundColor = color;
      document.body.appendChild(div);
    }
  };

  function quantize(data, k) {
    // 将颜色值转换为三维向量
    const vectors = [];
    for (let i = 0; i < data.length; i += 4) {
      vectors.push([data[i], data[i + 1], data[i + 2]]);
    }

    // 随机选择 K 个聚类中心
    const centers = [];
    for (let i = 0; i < k; i++) {
      centers.push(vectors[Math.floor(Math.random() * vectors.length)]);
    }

    // 迭代更新聚类中心
    let iterations = 0;
    while (iterations < 100) {
      // 分配数据点到最近的聚类中心所在的簇中
      const clusters = new Array(k).fill().map(() => []);
      for (let i = 0; i < vectors.length; i++) {
        let minDist = Infinity;
        let minIndex = 0;
        for (let j = 0; j < centers.length; j++) {
          const dist = distance(vectors[i], centers[j]);
          if (dist < minDist) {
            minDist = dist;
            minIndex = j;
          }
        }
        clusters[minIndex].push(vectors[i]);
      }

      // 更新聚类中心
      let converged = true;
      for (let i = 0; i < centers.length; i++) {
        const cluster = clusters[i];
        if (cluster.length > 0) {
          const newCenter = cluster
            .reduce((acc, cur) => [
              acc[0] + cur[0],
              acc[1] + cur[1],
              acc[2] + cur[2],
            ])
            .map((val) => val / cluster.length);
          if (!equal(centers[i], newCenter)) {
            centers[i] = newCenter;
            converged = false;
          }
        }
      }

      if (converged) {
        break;
      }

      iterations++;
    }

    // 将每个像素点的颜色值替换为所在簇的聚类中心的颜色值
    for (let i = 0; i < data.length; i += 4) {
      const vector = [data[i], data[i + 1], data[i + 2]];
      let minDist = Infinity;
      let minIndex = 0;
      for (let j = 0; j < centers.length; j++) {
        const dist = distance(vector, centers[j]);
        if (dist < minDist) {
          minDist = dist;
          minIndex = j;
        }
      }
      const center = centers[minIndex];
      data[i] = center[0];
      data[i + 1] = center[1];
      data[i + 2] = center[2];
    }

    // 计算每个颜色值在图像中出现的次数，并按出现次数从大到小排序
    const counts = {};
    for (let i = 0; i < data.length; i += 4) {
      const color = `rgb(${data[i]}, ${data[i + 1]}, ${data[i + 2]})`;
      counts[color] = counts[color] ? counts[color] + 1 : 1;
    }
    const sortedColors = Object.keys(counts).sort(
      (a, b) => counts[b] - counts[a]
    );

    // 取前 k 个颜色作为主要颜色
    return sortedColors.slice(0, k);
  }

  function distance(a, b) {
    return Math.sqrt(
      (a[0] - b[0]) ** 2 + (a[1] - b[1]) ** 2 + (a[2] - b[2]) ** 2
    );
  }

  function equal(a, b) {
    return a[0] === b[0] && a[1] === b[1] && a[2] === b[2];
  }
</script>

自动选取 K 值

在实际应用中，我们可能不知道应该选择多少个聚类中心，即 K 值。一种常用的方法是使用 Gap 统计量法，它的基本思想是比较聚类结果与随机数据集的聚类结果之间的差异，选择使差异最大的 K 值。

Gap 统计量法的实现过程如下：

1. 对原始数据集进行 K-Means 聚类，得到聚类结果。

2. 生成 B 个随机数据集，对每个随机数据集进行 K-Means 聚类，得到聚类结果。

3. 计算聚类结果与随机数据集聚类结果之间的差异，使用 Gap 统计量表示。

4. 选择使 Gap 统计量最大的 K 值。

下面是使用 JavaScript 实现 Gap 统计量法的示例代码：

function gap(data, maxK) {
  const gaps = [];
  for (let k = 1; k <= maxK; k++) {
    const quantized = quantize(data, k);
    const gap = logWk(quantized) - logWk(randomData(data.length));
    gaps.push(gap);
  }
  const maxGap = Math.max(...gaps);
  return gaps.findIndex((gap) => gap === maxGap) + 1;
}

function logWk(quantized) {
  const counts = {};
  for (let i = 0; i < quantized.length; i++) {
    counts[quantized[i]] = counts[quantized[i]] ? counts[quantized[i]] + 1 : 1;
  }
  const n = quantized.length;
  const k = Object.keys(counts).length;
  const wk = Object.values(counts).reduce((acc, cur) => acc + cur * Math.log(cur / n), 0);
  return Math.log(n) + wk / n;
}

function randomData(n) {
  const data = new Uint8ClampedArray(n * 4);
  for (let i = 0; i < data.length; i++) {
    data[i] = Math.floor(Math.random() * 256);
  }
  return data;
}

使用：

const k = gap(data, 10)
// const k = 3; // 聚类数
const centers = quantize(data, k);

好吧，挺麻烦的，最终直接将封面图再作为背景图添加 backdrop-filter 来实现了 🤐。

附录

Python 绘制图片 Scatter 3D：

import matplotlib.pyplot as plt
import numpy as np

from mpl_toolkits.mplot3d import Axes3D

def visualize_rgb(image_path):
    image = plt.imread(image_path)
    height, width, _ = image.shape

    # Reshape the image array to a 2D array of pixels
    pixels = np.reshape(image, (height * width, 3))

    # Extract RGB values
    red = pixels[:, 0]
    green = pixels[:, 1]
    blue = pixels[:, 2]

    # Create 3D scatter plot
    fig = plt.figure()
    ax = fig.add_subplot(111, projection='3d')
    ax.scatter(red, green, blue, c=pixels/255, alpha=0.3)

    ax.set_xlabel('Red')
    ax.set_ylabel('Green')
    ax.set_zlabel('Blue')
    ax.set_title('RGB 3D Scatter Plot')

    plt.show()

# 调用函数并传入图像路径
visualize_rgb('image.jpg')

Halo 社区例会 五月的全新议题「和 guqing 一起开发插件」将基于 plugin-repos 插件为用户演示如何从零开始创建一个 Halo 插件。

本次例会是「和 guqing 一起开发插件」系列的第一期。开场环节，会议主持人 guqing 介绍了 Halo 插件开发的基本概念和开发环境。你也可以查阅官方文档中的 「插件开发」 篇目来获取更详尽的信息。

随后，guqing 以将 GitHub 的个人仓库信息同步到 Halo 的自定义模型中为例，展示了在 Halo 中创建插件、运行插件的整体过程。在此期间，涉及了插件生命周期、如何使用自定义模型、自定义模型对象的生命周期介绍、如何使用自动生成的 API、如何创建自定义 API 等演示说明，并初步实现了以下功能：
通过 GitHub API 获取个人仓库信息；

• 创建自定义模型 Repository；
• 将 GitHub 仓库信息通过自定义 API 存储到 Repository 模型中；
• 通过 Repository 的自定义模型 API 列出数据；

参会人员对演示内容进行了提问和讨论，并提出了一些开发中的问题和建议，如：

• 开发体验有待优化，可以考虑在用户界面提供 Devtools 相关功能，仅在插件开发时用于对用户界面的自动刷新和插件热重载。
• 针对 plugin-repos 示例插件，提出了可以定义一个自定义模型用于存储仓库数据源用于同步数据。

下期预告

下期例会中，我们将继续围绕 plugin-repos 插件开发进行分享和探讨。预计实现的功能：

• 使用一个新的自定义模型来存储仓库源，以便同步上游仓库数据；
• 通过 Reconciler 来 watch 仓库源并定期同步；
• 自定义主题模板页和路由展示仓库信息。

如果你也对 Halo 插件开发抱有兴趣、或对 plugin-repos 插件本身持有改进想法或实现建议，欢迎你在该系列会议进行的同时就参与到协作开发中来，在实践中理解 Halo、熟悉 Halo、成为 Halo 的贡献者。想想下次例会中，大家围绕你的创意或代码展开的讨论会如何。

感谢与会者的发言，同时感谢所有人的参与和聆听。下期再会咯～

如果你对插件主题开发有任何灵感，欢迎加入 Halo 特别兴趣小组 参与贡献。如果你在开发过程中遇到问题，Halo 项目组成员乐意为你提供解答和帮助。你可以通过 论坛 和我们取得联系。
Halo 社区例会将持续聚焦于大家最最关注的话题领域。这个无界沟通的场所，我们期待通过每一次的畅谈，解决你的疑问、了解你的需求、一起探讨 Halo 的未来与诸多可能。最后，能够对想要参与社区贡献的你给予便利和帮助，同时也提供一个成员互助的契机。

三月四日，我来到了无锡市鼋头渚风景区游览了一番，太湖，这个千年古湖，如今依旧，它那澄澈的湖水、美丽的风景、壮阔的历史，让每一个到此游玩的人为之倾倒。

夕阳西下，天地渐昏，太湖波光粼粼，宛如水晶镶嵌，一片昏黄中透着淡淡的蓝色，犹如温柔而又坚韧的女子。微风拂过太湖仙岛，树影斑驳，湖面上泛起点点涟漪，波光如丝，恍若仙境。岸边的樱花树在晚风中轻轻摇曳，洒下淡淡的花瓣，让整个太湖的景色更加柔和浪漫。

此刻，我置身于太湖仙岛湖边的看台，眼前是夕阳西下，远处湖面上还有几只海鸥在飞翔，一点点黑色的身影在天空中流转。

突然，一缕鱼肚白透过了树梢，绕过了山丘，直到我的脚下。夕阳的余辉如此美丽，它在湖面上泛起了一片金色的光芒，而我则不禁陷入了对太湖的美丽深深的迷恋之中。

沉醉在太湖之中，仿佛时间已经停滞，仿佛历史已经倒流:

我与那些文人雅士置身一地，胸怀壮志，品茶赏景，追求浪漫，看白居易写下”水天向晚碧沉沉，树影霞光重叠深“，与他”烟渚云帆“，飘舟太湖、澄波皓月.

真可谓“余尝登君山而见识何谓江山如画，余尝过长江而领略何谓横无际涯，故略知山水之乐也”。

由于之前从 Oh My Zsh 切换到 Fish shell 后一直在用 Terlar prompt，用了一段时间后还是发现 Oh My Zsh 又改回来了，但是看习惯了 Terlar prompt，所以 DIY 了一个适用于 Oh My Zsh 的主题。

它分为两行，第一行显示用户名、路径、git还有时间等，第二行为输入。
特性：

• 箭头符号在命令正常执行时显示为 user color，输入执行错误后显示红色
• 目录提示符只会显示当前所在目录名，上级目录只显示首字母
• 在一个 Git 仓库时会显示分支名称和工作区状态，当工作区 clean 时分支名为绿色，dirty 时分支名为红色，还有勾、叉、星等具体的状态提示符
  

使用方式：

1. cd ~/.oh-my-zsh/custom/themes
2. 下载一下文件到此目录
3. vim ~/.zshrc 然后修改ZSH_THEME的值为ZSH_THEME="guqing"
4. source ~/.zshrc 就完成啦🥳

模板仓库：https://github.com/halo-dev/plugin-starter

前期准备：

1. 使用此仓库作为模版创建仓库
2. 克隆新创建好的仓库到本地

使用模板仓库开发友情链接插件示例：https://github.com/halo-sigs/plugin-links

项目结构介绍

.
├── LICENSE
├── README.md
├── admin-frontend
│   ├── ...
├── build
│   ├── classes
│   ├── libs
│   │   ├── halo-plugin-template-0.0.1-SNAPSHOT-plain.jar
│   ├── resources
├── build.gradle
├── lib
│   └── halo-2.0.0-SNAPSHOT-plain.jar
├── settings.gradle
└── src
    └── main
        ├── java
        │   └── io
        │       └── github
        │           └── guqing
        │               └── template
        │                   ├── Apple.java
        │                   ├── ApplePlugin.java
        │                   └── ApplesController.java
        └── resources
            ├── admin
            │   ├── main.js
            │   └── style.css
            ├── extensions
            │   ├── apple.yaml
            │   ├── reverseProxy.yaml
            │   └── roleTemplate.yaml
            ├── plugin.yaml
            └── static
                ├── ...

对于以上目录树：

• admin-frontend： 插件前端项目目录，为一个 vue 项目；

• build：插件后端构建目录，build/libs 下的 jar 包为最终插件产物；

• lib：为临时的 halo 依赖，为了使用 halo 中提供的类在 build.gradle 中作为编译时依赖引入 compileOnly files("lib/halo-2.0.0-SNAPSHOT-plain.jar")，待 2.0 正式发布会将其发布到 maven 中央仓库，便可通过 gradle 依赖；

• src: 为插件后端源码目录；

• Apple.java 为自定义模型

@GVK(group = "apple.guqing.xyz", kind = "Apple",
    version = "v1alpha1", singular = "apple", plural = "apples")
@Data
@EqualsAndHashCode(callSuper = true)
public class Apple extends AbstractExtension {}

关键在于标注 @GVK 注解和 extends AbstractExtension，当如此定义了一个模型后，插件启动时会根据 @GVK 配置自动生成CRUD的 RESTful API，以此为例子会生成如下APIs

GET /apis/apple.guqing.xyz/v1alpha1/apples

POST /apis/apple.guqing.xyz/v1alpha1/apples

GET /apis/apple.guqing.xyz/v1alpha1/apples/{name}

PUT /apis/apple.guqing.xyz/v1alpha1/apples/{name}

DELETE /apis/apple.guqing.xyz/v1alpha1/apples/{name}

生成规则见：Halo extension RFC

• ApplePlugin.java：插件生命周期入口，它继承 BasePlugin，可以通过getApplicationContext()方法获取到 SchemeManager，然后在 start() 方法中注册自定义模型，这一步必不可少，所有定义的自定义模型都需要在此注册，并在 stop() 生命周期方法中清理资源。

@Override
public void start() {
  schemeManager.register(Apple.class);
}

@Override
public void stop() {
  // TODO 优化取消注册自定义模型的写法
  Scheme scheme = schemeManager.get(Apple.class);
  schemeManager.unregister(scheme);
}

注意：该类不能标注 @Component 等能将其声明为 Spring Bean 的注解

• ApplesController.java：如果根据模型自动生成的 CURD RESTful APIs 无法满足业务需要，可以写常规 Controller 来自定义APIs，示例：

@ApiVersion("v1alpha1")
@RestController
@RequestMapping("colors")
public class ApplesController {

    @GetMapping
    public Mono<String> hello() {
        return Mono.just("Hello world");
    }
}

插件定义 Controller 必须要标注 @ApiVersion 注解，否则启动时会报错。如果定义了这样的 Controller ，插件启动后会生成如下的 APIs

GET /api/v1alpha1/plugins/apples/colors

生成规则为 /api/{version}/plugins/{plugin-name}/{mapping-in-class}/{mapping-in-method}

其中:

• version：来自 @ApiVersion("v1alpha1") 的 value，详情参考：Halo plugin API composition

• plugin-name：值来自 plugin.yaml 中的 metadata.name 属性

• mapping-in-class：来自标注在类上的 @RequestMapping("colors")

• mapping-in-method：来自标注在方法上的 @GetMapping

插件还允许使用 @Service、@Component 注解将其声明为一个 Spring Bean，便可通过依赖注入使用 Spring Bean，示例：

@Service
public class ColorService {
  public String getColor(String appleName) {
    return "red";
  }
}

@ApiVersion("v1alpha1")
@RestController
@RequestMapping("colors")
public class ApplesController {
	private final ColorService colorService;
  // 构造器注入，当然也同样允许 @Autowired 注入 和 setter 方法注入
  public ApplesController(ColorService colorService) {
    this.colorService = colorService;
  }
}

• resources：目录为插件资源目录

admin 目录下为插件前端打包后的产物存放目录，固定为 main.js 和 style.css 两个文件

extensions 存放自定义模型资源配置

plugin.yaml为插件描述配置

static 为静态资源示例目录

        ├── admin
        │   ├── main.js
        │   └── style.css
        ├── extensions
        │   ├── apple.yaml
        │   ├── reverseProxy.yaml
        │   └── roleTemplate.yaml
        ├── plugin.yaml
        └── static
            ├── image.jpeg
            ├── some.txt
            └── test.html

插件启动时会加载 extensions 目录的 yaml 保存到数据库，apple.yaml 为本项目自定义的模型的数据示例，当启用插件后调用

GET /apis/apple.guqing.xyz/v1alpha1/apples

便可查询到 apple.yaml 中定义的记录

[
  {
    "spec": {
      "varieties": "Fuji",
      "color": "red",
      "size": "middle",
      "producingArea": "China"
    },
    "apiVersion": "apple.guqing.xyz/v1alpha1",
    "kind": "Apple",
    "metadata": {
      "name": "Fuji-apple",
      "labels": {
        "plugin.halo.run/plugin-name": "apples"
      },
      "version": 0,
      "creationTimestamp": "2022-06-24T04:03:22.890741Z"
    }
  }
]

reverseProxy.yaml 为 Halo 中提供的模型，表示反向代理，允许插件配置规则代理到插件目录

apiVersion: plugin.halo.run/v1alpha1
kind: ReverseProxy
metadata:
  name: reverse-proxy-template
rules:
  - path: /static/**
    file:
      directory: static

它表示访问 GET /assets/{plugin-name}/static/** 时代理访问到插件的 resources/static 目录，本插件便可访问到一下静态资源

GET /assets/apples/static/image.jpeg
GET /assets/apples/static/some.txt
GET /assets/apples/static/test.html

roleTemplate.yaml 文件中 kind: Role 表示插件允许提供角色模版，定义格式如下：

apiVersion: v1alpha1
kind: Role
metadata:
  name: a name here
  labels:
    plugin.halo.run/role-template: "true"
  annotations:
    plugin.halo.run/module: "module name"
    plugin.halo.run/alias-name: "display name"
rules:
  # ...

必须带有plugin.halo.run/role-template: "true" labels，表示该角色为角色模版，当用户启用插件后，创建角色或修改角色时会将其列在权限列表位置。

插件如果不提供角色模版除非是超级管理员否则其他账号没有权限访问，因为 Halo 规定 /api 和 /apis 开头的 api 都需要授权才能访问，因此插件不提供角色模版的自定义资源，就无法将其分配给用户。

更多详情参考：Halo security RFC

打包

打包前端项目

1. 到 admin-frontend 目录下执行

pnpm install

2. 开发时执行

pnpm run dev

3. 打包时执行

pnpm run build

构建后端

1. 开发时可以使用 command + F9/ctrl + F9

2. 生产时：点击 gradle 的 build

或者执行

./gradlew -x build

然后只需复制例如build/libs/halo-plugin-template-0.0.1-SNAPSHOT-plain.jar 的 jar 包即可使用

距离我们 2020 年 9 月 24 号发布 1.4.0 已经过去了 545 天了，期间虽然有一些版本更新，但大多数都是 patch 修复版本。终于，在今天正式发布 1.5.0 版本。其中带来了大量的优化更新，下面为大家简单介绍一些亮点功能，详细更新日志可在本文末尾查阅。

版本亮点

文章表拆分

在此版本中，新增了 contents 表专门用于存储文章内容。因为在以前的版本中，当站点有大量文章的时候会出现明显拖慢页面渲染速度的情况，这是因为在之前的版本中，查询文章列表会将内容字段也包含在其中，这就会导致数据越多就会越慢。所以在这个版本中，原本的 posts 表就不再包含 originalContent 和 formatContent 字段，在列表查询的时候也不会包含。需要注意的是，如果你是从 1.4 版本升级的话，目前我们是没有自动清空这两个字段的内容的。当然，你可以手动清空，以获得更好的效果。

性能对比：

• 版本：1.4.17 vs 1.5.0
• 测试数据：文章数 1000，每篇 4000 字符。
• 测试工具：Apache Benchmark
• 测试平台：MacBook Pro M1 Pro
• 测试参数：ab -c 100 -n 10000 http://localhost:8090/

1.4.17：

1.5.0：

注意：此测试可能并不是特别严谨，仅供参考。

文章保存逻辑修改

目前后台已经修改为直接保存编辑器渲染的 html 内容，保证编写时和最终发布结果完全一致。另外，数学公式和 mermaid 图表已经针对此特性做了优化。数学公式仅需在前台引入 katex css 即可。mermaid 图表会被渲染为 svg 并保存，所以无需再引入 mermaid 依赖。

数学公式可以在前台引入：

<link rel="stylesheet" href="https://unpkg.com/katex@0.12.0/dist/katex.min.css" />

目前，我们已经统一使用 @halo-dev/markdown-renderer 进行 Markdown 渲染。

编辑器重构

编辑器编辑区域修改为 Codemirror 编辑器，支持 Markdown 语法高亮，浏览文章会更加方便。

编辑器可以通过快捷键打开图片选择，目前也已经支持多选图片和选择之后直接插入文章。

预览区域支持代码块高亮。

支持更多 Markdown 标记语法。

表格编辑体验优化。众所周知，使用 Markdown 语法编写表格的体验是非常难受的，不仅编写困难，而且格式会非常难以阅读。所以我们使用了一个叫做 mte-kernel 的库来解决这个问题，不仅可以让编辑体验升级，而且会自动格式化表格。

标签支持设置颜色

在这个版本中，我们添加了对标签设置颜色的功能，灵感来自于 GitHub Issues 的标签颜色。这样可以比较直观地区分不同的标签。

文章管理重构

重构了批量操作的逻辑，目前已经不需要提前通过文章状态筛选文章之后才能批量选择。可以任意批量选择之后进行文章状态的批量操作。

文章列表不再展示回收站的文章，改为单独为回收站提供一个入口。

文章设置弹窗进行了重构，改为更直观地显示方式，并且可以在弹窗中进行上下篇的切换。可以非常快速的预览文章设置并进行对文章设置的修改。

附件管理重构

目前支持将鼠标放在附件项即可显示勾选图标，不再需要提前进入批量管理功能。

附件详情也和文章设置一样，修改为弹窗的形式，可以进行上下项的快速切换，方便预览以及进行修改删除等操作。

主题设置重构

主题设置由原来的全屏抽屉形式改为单独的页面。并优化了布局，不再显示主题缩略图，将更多的空间留给设置表单。同时在界面上也展示了主题的相关信息。

版本日志

Breaking changes

• 评论表单中的邮箱地址不再作为必填项。 halo-dev/halo#1535 @jerry-shao
• 重构文章表结构。
  • 提供单独的 contents 表存储文章内容，将不再使用 posts 表中的 originalContent 和 formatContent 字段。 halo-dev/halo#1617 @guqing
  • formatContent 已经废弃，将在下一个大版本中移除。后续使用 content 字段代替。 halo-dev/halo#1617 @guqing
  • 提供 content_patch_logs 表用于存储变更记录。 halo-dev/halo#1617 @guqing
• 后台使用 @halo-dev/admin-api 进行接口请求。 halo-dev/halo-admin#378 @ruibaby @guqing
• 修改后台页面标题后缀，由 Halo Dashboard 改为 Halo。 halo-dev/halo-admin#426 @ruibaby
• 默认后台布局改为左侧菜单布局。 halo-dev/halo-admin#441 @ruibaby
• 重构文章/自定义页面编辑逻辑，改为保存前端渲染内容，放弃后端渲染。 halo-dev/halo-admin#439 halo-dev/halo-admin#440 halo-dev/halo-admin#449 halo-dev/halo#1668 @ruibaby @guqing
• Content API 的评论列表接口不再返回 ipAddress 和 email 字段。 halo-dev/halo#1729 @guqing

Features

• Content API 添加获取所有图库图片分组的接口（PhotoController#listTeams）。 halo-dev/halo#1515 @fuzui
• Content API 添加根据 themeId 获取主题详情和设置的接口。 halo-dev/halo#1660 @guqing
• 图库支持点赞。 halo-dev/halo#1537 @guqing
• 文章标签支持设置颜色。 halo-dev/halo#1566 halo-dev/halo-admin#395 @ruibaby @guqing
• 重构后台文章分类管理，支持排序。 halo-dev/halo#1650 halo-dev/halo#1657 halo-dev/halo-admin#435 @lan-yonghui @ruibaby @guqing
• 文章设置界面支持重新生成别名。 halo-dev/halo-admin#368 @ruibaby
• Admin API 提供批量删除图库图片的接口。 halo-dev/halo#1680 @ruibaby
• Admin API 提供批量更新图库图片的接口。 halo-dev/halo#1679 @ruibaby
• 后台评论管理提供日志评论管理的界面。 halo-dev/halo-admin#480 @ruibaby
• 后台菜单分组支持修改分组名。 halo-dev/halo-admin#499 @ruibaby
• 后台个人资料头像修改支持输入链接。 halo-dev/halo-admin#505 @ruibaby
• 后台待审核评论弹框点击评论支持进入评论管理。 halo-dev/halo-admin#517 @ruibaby
• 支持配置 Redis 缓存。 halo-dev/halo#1751 @luoxmc @guqing

Improvements

• 更新 Logo。 halo-dev/halo-admin#366 @ruibaby
• 重构附件上传的文件命名逻辑，文件作为第一次上传的时候文件名不添加随机字符串。 halo-dev/halo#1500 @guqing
• 优化后台编辑文章时的预览体验，预览文章或临时保存内容不会修改已经发布的内容。 halo-dev/halo#1617 halo-dev/halo-admin#439 @guqing @ruibaby
• 重构后台主题设置界面，提供单独的设置页面，支持展示主题的相关信息。 halo-dev/halo-admin#380 @ruibaby
• 弱化后台登录页面的动画效果。 halo-dev/halo-admin#369 @ruibaby
• 优化后台附件管理列表预览图片样式。 halo-dev/halo-admin#374 halo-dev/halo-admin#382 @623337308 @cetr
• 重构后台附件详情界面，取消原有抽屉的设计，改为弹窗。 halo-dev/halo-admin#375 halo-dev/halo-admin#381 @ruibaby
• 重构后台文章/自定义页面设置界面，取消原有抽屉的设计，改为弹窗。 halo-dev/halo-admin#376 @ruibaby
• 重构后台操作日志列表界面，取消原有抽屉的设计，提供单独的页面。 halo-dev/halo-admin#419 @ruibaby
• 重构后台图片选择弹框组件，支持直接插入到编辑器，支持多选。 halo-dev/halo-admin#420 halo-dev/halo-admin#421 @ruibaby
• 后台文章设置选择标签列表改为根据名称排序。 halo-dev/halo-admin#429 @ruibaby
• 优化后台附件管理中批量操作附件的逻辑。 halo-dev/halo-admin#431 @ruibaby
• 后台使用重构版本的编辑器，编辑区域支持高亮语法，优化数学公式和图表等渲染，优化表格的编辑体验。 halo-dev/halo-admin#447 @ruibaby
• 优化文章加密和分类加密的逻辑。 halo-dev/halo#1678 @guqing
• 优化后台登录页面样式。 halo-dev/halo-admin#456 @ruibaby
• 重构后台文章评论列表弹窗。 halo-dev/halo-admin#463 @ruibaby
• 重构后台图库管理页面，支持批量操作图片以及批量从附件库添加图片。 halo-dev/halo-admin#468 @ruibaby
• 重构后台文章管理页面，文章列表将不再展示回收站状态的文章，提供单独的回收站入口。 halo-dev/halo-admin#475 @ruibaby
• 优化后台文章/自定义页面设置的保存逻辑，提供转为发布/草稿的按钮。保存按钮不再影响到文章状态。 halo-dev/halo-admin#476 @ruibaby
• 优化后台折叠菜单的体验，解决折叠时 Logo 和 菜单动画不同步的问题。 halo-dev/halo-admin#493 @ruibaby
• 缓存后台折叠菜单的状态，刷新页面不再会恢复到初始状态。 halo-dev/halo-admin#493 @ruibaby
• 优化后台判断是否初始化的逻辑，修改为每次页面加载只请求一次，切换路由不再请求。 halo-dev/halo-admin#495 @ruibaby
• 重构后台主题设置保存预览功能。 halo-dev/halo-admin#502 @ruibaby
• 重构日志发布功能，使用 Markdown 编辑器替换 textarea，并支持保存前端渲染的 Markdown 结果。 halo-dev/halo#1739 halo-dev/halo-admin#506 @guqing @ruibaby

Bug Fixes

• 修复修改加密文章或分类时没有清除用户访问权限的问题。 halo-dev/halo#1540 @guqing
• 修复重置密码没有校验密码长度的问题。 halo-dev/halo#1636 halo-dev/halo-admin#403 @ruibaby @guqing
• 修复后台文章设置中无法仅选择父级分类的问题。 halo-dev/halo-admin#367 @ruibaby
• 修复后台菜单管理中移动菜单项到其他分组的时候，导致子菜单丢失的问题。 halo-dev/halo-admin#422 @ruibaby
• 更新默认主题的 submodule 提交，修复模板中部分因为数字中带逗号导致的渲染异常。 halo-dev/halo#1682 @ruibaby
• 修复评论默认头像因为修改了默认类型但 options 接口没有返回字段导致评论头像无法显示的问题。 halo-dev/halo#1692 @lan-yonghui
• 修复使用 leveldb 的情况下，解析错误而没有清空缓存导致无法正常使用系统的问题。 halo-dev/halo#1695 @guqing
• 修复后台在文章编辑页面切换左侧菜单收缩的时候出现的样式异常。 halo-dev/halo-admin#465 @ruibaby
• 修复当前版本如果为 alpha 版本，安装主题无法通过版本验证的问题。 halo-dev/halo#1705 @JohnNiang
• 修复评论部分因为没有添加事务，导致批量删除评论等操作时报错的问题。 halo-dev/halo#1716 @guqing
• 修复后台点击后台 Halo Logo 进入开发者选项过快可能会导致计数为负的问题。 halo-dev/halo-admin#492 @ruibaby
• 修复后台附件列表分页之后，可能会导致无法正常更新图片 dom 导致图片显示为上一页图片的问题。 halo-dev/halo-admin#496 @ruibaby
• 修复后台分类/标签/友情链接修改表单切换修改对象之后没有清除表单验证的问题。 halo-dev/halo-admin#501 halo-dev/halo-admin#503 @Yorksh1re
• 修复当前版本如果为 alpha 版本，安装主题无法通过版本验证的问题。 halo-dev/halo#1747 @JohnNiang

Dependencies

• 升级 Spring Boot 版本。 halo-dev/halo#1635 halo-dev/halo#1677 @ruibaby @JohnNiang
• 升级 Gradle 版本到 7.4。 halo-dev/halo#1697 @guqing
• halo-dev/halo-admin 常规依赖升级。 halo-dev/halo-admin#453 halo-dev/halo-admin#513 @ruibaby
• halo-dev/halo-admin 修改用于切换后台样式的 less 依赖 CDN 为 unpkg。
• 后台更新 @halo-dev/editor 版本。 halo-dev/halo-admin#507 @ruibaby

halo-dev/halo@v1.4.17…v1.5.0

相关信息

• GitHub Release：https://github.com/halo-dev/halo/releases/tag/v1.5.0
• 升级文档：https://docs.halo.run/getting-started/upgrade
• 论坛交流：https://bbs.halo.run/d/2227-halo-150

简介

由于买的国内厂商打折服务器，大部分情况下都无法在同一家厂商买到多台优惠服务器，此时想搭建 K3S 集群就需要走公网，直接通过K3S 的安装方式节点之间无法通信，因此需要使用 WireGuard来组网。

在阅读本篇之前建议你先阅读 WireGuard 的Quickstart来了解它的概念，这将对接下来配置WireGuard十分重要:

https://www.wireguard.com/quickstart/

本篇以两台服务器为例信息如下:

首先会通过 WireGuard为两台机器创建一块虚拟网卡并指定虚拟 ip 形如：

[root@k3s-master ~]# ifconfig wg0
wg0: flags=209<UP,POINTOPOINT,RUNNING,NOARP>  mtu 1420
        inet 192.168.2.1  netmask 255.255.255.255  destination 192.168.2.1
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1000  (UNSPEC)
        RX packets 1764  bytes 441372 (431.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1341  bytes 165156 (161.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

最终信息如下：

+---------------------------------------+          +--------------------------------------------+
|                                       |          |                                            |
| Master    腾讯云  公:42.xxx.xxx.60     |          | Node-1    QingCloud    公：139.xx.xx.46     |
|                                       |          |                                            |
| 内：172.17.16.4    虚拟Ip: 192.168.2.1 |          | 内：10.190.19.38        虚拟IP: 192.168.2.2 |
|                                       |          |                                            |
+---------------------------------------+          +--------------------------------------------+

安装WireGuard

在搭建跨云的 k3s 集群前，需要先把 WireGuard 安装好，WireGuard 对内核有要求，要升级到 5.15.2-1.el7.elrepo.x86_64以上

分别在Master(表示腾讯云的服务器在集群中作为master节点使用)和Node-1（表示QingCloud的服务器在集群中作为工作节点使用）执行如下命令以开启 IP 地址转发：

echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf

echo "net.ipv4.conf.all.proxy_arp = 1" >> /etc/sysctl.conf

sysctl -p /etc/sysctl.conf

对两台服务器修改主机名称

# 腾讯云执行
hostnamectl  set-hostname k3s-master
# QingCloud执行
hostnamectl  set-hostname k3s-node-1

修改 iptables 以允许NAT

对两台服务器都进行如下设置，添加 iptables 规则，允许本机的 NAT 转换，执行前需要将如下的192.168.1.1/24修改为在简介中决定设定的虚拟ip:

iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i wg0 -o wg0 -m conntrack --ctstate NEW -j ACCEPT
iptables -t nat -A POSTROUTING -s 192.168.1.1/24 -o eth0 -j MASQUERADE

释意:

wg0: 为虚拟网卡名称,两台服务器可以都叫wg0

192.168.1.1: 为虚拟 IP 地址段, Master设置为192.168.2.1, Node-1改为192.168.2.2

eth0: 为服务器的物理网卡

升级内核

配置好 iptables 只有升级内核以安装WireGuard，否则安装WireGuard时会出现如下错误:

[#] ip link add wg0 type wireguard
RTNETLINK answers: Operation not supported
Unable to access interface: Protocol not supported
[#] ip link delete dev wg0
Cannot find device "wg0"

在所有节点都执行如下操作：

1. 载入公钥

rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org

2. 升级安装 elrepo

rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-5.el7.elrepo.noarch.rpm

3. 载入 elrepo-kernel元数据

yum --disablerepo=\* --enablerepo=elrepo-kernel repolist

4. 安装最新版本的内核

yum --disablerepo=\* --enablerepo=elrepo-kernel install  kernel-ml.x86_64  -y

5. 删除旧版本工具包

yum remove kernel-tools-libs.x86_64 kernel-tools.x86_64  -y

6. 然后修改默认内核版本，首先查看当前实际启动顺序

grub2-editenv list

7. 查看内核插入顺序

grep "^menuentry" /boot/grub2/grub.cfg | cut -d "'" -f2

8. 设置默认启动, 将CentOS Linux (5.15.2-1.el7.elrepo.x86_64) 7 (Core)改为步骤6中列出的最新内核信息

grub2-set-default 'CentOS Linux (5.15.2-1.el7.elrepo.x86_64) 7 (Core)'

9. 重新创建内核配置

grub2-mkconfig -o /boot/grub2/grub.cfg

10. 重启服务器

reboot

11. 验证当前内核版本

uname -r

安装WireGuard

在两台服务器都需要执行如下操作，安装流程非常简单，CentOS 内核更新到 5.15.2以上版本后，其中就已经包含了 WireGuard 的内核模块，只需要安装 wireguard-tools 包即可

yum install epel-release https://www.elrepo.org/elrepo-release-7.el7.elrepo.noarch.rpm

yum install yum-plugin-elrepo kmod-wireguard wireguard-tools -y

配置 WireGuard

wireguard-tools 包提供了我们所需的工具 wg 和 wg-quick，可以使用它们来分别完成手动部署和自动部署。

先按照官方文档描述的形式，生成Master节点和Node-1节点服务器 用于加密解密的密钥

在Master节点操作

wg genkey | tee privatekey | wg pubkey > publickey

然后在当前目录下就生成了 privatekey 和 publickey 两个文件

注意：

密钥是配置到本机的，而公钥是配置到其它机器里的,结果示例如下：

cat privatekey publickey
EMWcI01iqM4zkb7xfbaaxxxxxxxxDo2GJUA=
0ay8WfGOIHndWklSIVBqrsp5LDWxxxxxxxxxxxxxxQ=

然后编写配置文件，以供 wg-quick 使用

vim /etc/wireguard/wg0.conf

然后写入如下内容

[Interface]
PrivateKey = EMWcI01iqM4zkb7xfbaaxxxxxxxxDo2GJUA=
Address = 192.168.2.1
ListenPort = 5418

[Peer]
PublicKey = Node-1服务器的 publickey后续Node-1生成后再改
EndPoint = 139.xx.xx.46:5418
AllowedIPs = 192.168.2.2/32

在Node-1节点操作

wg genkey | tee privatekey | wg pubkey > publickey

查看结果

[root@k3s-node-1 ~] cat privatekey publickey
QGl72V7FyFokmF15cPGLcLWkOOBV+CHw6KWL+MtUj2o=
b/yQJHLEo1NisJcE3eBewjX+wFBDROQ3njGRQhZpADQ=

然后编写配置文件，以供 wg-quick 使用

vim /etc/wireguard/wg0.conf

然后写入如下内容

[Interface]
PrivateKey = QGl72V7FyFokmF15cPGLcLWkOOBV+CHw6KWL+MtUj2o=
Address = 192.168.2.2
ListenPort = 5418

[Peer]
# PublicKey为Master机器的
PublicKey = 0ay8WfGOIHndWklSIVBqrsp5LDWxxxxxxxxxxxxxxQ=
EndPoint = 42.xxx.xxx.60:5418
AllowedIPs = 192.168.2.1/32

然后到Master机器使用vim /etc/wireguard/wg0.conf编辑Peer下的PublicKey为Node-1的PublicKey

开放端口

到云厂商的防火墙（安全组）规则配置处开放 5418 端口，下行规则，协议为UDP

配置说明

Interface: 小节是属于本机的配置.

Address: 是分配给本机在简介部分约定的虚拟 IP，

ListenPort: 是主机之间通讯使用的端口，是 UDP 协议的。

Peer: 是属于需要通信的服务器的信息，有多少需要通信的主机，就添加多少个 Peer 小节，更多内容参阅WireGuard官网配置。

EndPoint: 由于这里是跨厂商所以这里的EndPoint为服务器的公网 IP 与 WireGuard 监听的 UDP 端口，如果你的机器通过内网也能通信，直接用内网 IP 也可以，当然要注意这个 IP 需要所有加入该局域网的主机都能通信才行。

AllowedIPs: 是指本机发起连接的哪些 IP 应该将流量转发到这个节点，比如给主机 B 分配了内网 IP 192.168.1.2，那么在主机 A 上发送到 192.168.1.2 的数据包，都应该转发到这个 EndPoint 上，它其实起的是一个过滤作用。而且多个 Peer 时，这里配置的 IP 地址不能有冲突。

各个节点生产的 privatekey 和 publickey 分别如下

各个节点配置文件如下:

在Master 节点cat /etc/wireguard/wg0.conf:

[Interface]
PrivateKey = EMWcI01iqM4zkb7xfbaaxxxxxxxxDo2GJUA=
Address = 192.168.2.1
ListenPort = 5418

[Peer]
PublicKey = b/yQJHLEo1NisJcE3eBewjX+wFBDROQ3njGRQhZpADQ=
EndPoint = 139.xx.xx.46:5418
AllowedIPs = 192.168.2.2/32

在Node-1节点cat /etc/wireguard/wg0.conf:

[Interface]
PrivateKey = QGl72V7FyFokmF15cPGLcLWkOOBV+CHw6KWL+MtUj2o=
Address = 192.168.2.2
ListenPort = 5418

[Peer]
PublicKey = 0ay8WfGOIHndWklSIVBqrsp5LDWxxxxxxxxxxxxxxQ=
EndPoint = 42.xxx.xxx.60:5418
AllowedIPs = 192.168.2.1/32

启动 WireGuard

边写好配置文件后，对所有节点执行 wg-quick 工具来创建虚拟网卡

wg-quick up wg0

上面命令中的 wg0 对应的是 /etc/wireguard/wg0.conf 这个配置文件，其自动创建的网卡设备，名字就是 wg0。

创建好虚拟网卡后测试是否连通

例如在 Master 节点ping Node-1的虚拟ip要能 ping 通否则请检查配置是否正确

[root@k3s-master ~]# ping 139.xx.xx.46
PING 139.xx.xx.46 (139.xx.xx.46) 56(84) bytes of data.
64 bytes from 139.xx.xx.46: icmp_seq=1 ttl=50 time=48.8 ms
64 bytes from 139.xx.xx.46: icmp_seq=2 ttl=50 time=45.1 ms
^C
--- 139.xx.xx.46 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 45.119/47.008/48.897/1.889 ms

在Node-1上ping Master亦如是

然后就可以使用 wg 命令来查看通信情况

[root@k3s-master ~]# wg
interface: wg0
  public key: 0ay8WfGOIHndWklSIVBqrsp5LDWxxxxxxxxxxxxxxQ=
  private key: (hidden)
  listening port: 5418

peer: 0f0dn60+tBUfYgzw7rIihKbqxxxxxxxxa6Wo=
  endpoint: 122.xx.xx.155:5418
  allowed ips: 192.168.1.3/32
  latest handshake: 3 minutes, 3 seconds ago
  transfer: 35.40 KiB received, 47.46 KiB sent

自动化配置

系统重启后，WireGuard 创建的网卡设备就会丢失，WireGuard提供了自动化的脚本来解决这件事，在两台服务器都执行如下操作

systemctl enable wg-quick@wg0

使用上述命令生成 systemd 守护脚本，开机会自动运行 up 指令。

配置热重载

wg-quick 并未提供重载相关的指令，但是提供了 strip 指令，可以将 conf 文件转换为 wg 指令可以识别的格式。

wg syncconf wg0 <(wg-quick strip wg0)

即可实现热重载。

完成 WireGuard 的安装配置以后，接下来就可以安装 k3s 的集群了。

安装 K3S 集群

Master 节点安装

export MASTER_EXTERNAL_IP=42.xx.xx.60
export MASTER_VIRTUAL_IP=192.168.2.1

安装 K3S

curl -sfL http://rancher-mirror.cnrancher.com/k3s/k3s-install.sh | INSTALL_K3S_MIRROR=cn sh  -s -  --node-external-ip $MASTER_EXTERNAL_IP --advertise-address $MASTER_EXTERNAL_IP --node-ip $MASTER_VIRTUAL_IP --flannel-iface wg0

参数说明：

• --node-external-ip: 42.xx.xx.60 设置为当前节点的外部 IP
• --advertise-address: 42.xx.xx.12 用于设置 kubectl 工具以及子节点进行通讯使用的地址，可以是 IP，也可以是域名，在创建 apiserver 证书时会将此设置到有效域中。
• --node-ip： 10.20.30.1 上文中约定的的虚拟ip
• --flannel-iface wg0 wg0 是 WireGuard 创建的网卡设备，我需要使用虚拟局域网来进行节点间的通信，所以这里需要指定为 wg0。

由于 WireGuard 的所有流量都是加密传输的，通过它来进行节点间的通信，就已经能够保证通信安全，也就没有必要改用其它的 CNI 驱动，使用默认的就可以了。

在主节点执行上述命令后，一分钟不到就可以看到脚本提示安装完成。通过命令查看下主控端的运行情况

systemctl status k3s

如果运行正常，那么就看看容器的运行状态是否正常

kubectl get pods -A

-A 参数用于查看所有命名空间，如果容器都处于 running 状态，那么安装就成功了，接下来要可以添加被控节点。

Agent 安装

有了上述安装主控的经验，安装 work 节点更加简单，参数需要一定的调整

在Node-1节点 执行

export MASTER_VIRTUAL_IP=192.168.2.1
export NODE_EXTERNAL_IP=139.xx.xx.46
export NODE_VIRTUAL_IP=192.168.2.2
export K3S_TOKEN=K1031c4c705056a0752a09801e99b56cf0f89571b4d678a138a44deb49a0e1d9722::server:5d89600a5330100489c4c3dbcce1dec0

将 K3S_TOKEN 的值改为在Master节点执行/var/lib/rancher/k3s/server/node-token后得到的值

将NODE_EXTERNAL_IP设置为Node-1的公网ip

安装

curl -sfL http://rancher-mirror.cnrancher.com/k3s/k3s-install.sh | INSTALL_K3S_MIRROR=cn K3S_URL=https://$MASTER_VIRTUAL_IP:6443 K3S_TOKEN=$K3S_TOKEN sh -s - --node-external-ip $NODE_EXTERNAL_IP --node-ip $NODE_VIRTUAL_IP --flannel-iface wg0

执行后稍等一会，安装成功后，照例查看服务运行状态

systemctl status k3s-agent

都安装好以后 在 Master 节点检查,可以看到两个节点

kubectl get nodes -o wide 

至此 多云 K3S 集群已经搭建完毕。

参考文档:

[1] cnsre运维博客之搭建 K3S 集群

[2] WireGuard官方文档

[3] Network Address Translation

[4] K3S

[5] struct-net-device

minikube version: v1.16.0

Pod的分类

Pod的分类：

• 自主式Pod： Pod退出了，此类型的Pod不会被创建
• 控制器管理的Pod：在控制器的生命周期里，始终要维持Pod的副本数目

Init容器

init c探测模板

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
    - name: myapp-container
      image: busybox
      command: ["sh", "-c", "echo The app is running! && sleep 3600"]
  initContainers:
    - name: init-myservice
      image: busybox
      # myservice对应svc
      command:
        [
          "sh",
          "-c",
          "until nslookup myservice;do echo waiting for myservice;sleep 2;done;",
        ]
    - name: init-mydb
      image: busybox
      # 解析mydb的主机名与svc有关如果有mydb对应的svc那么k8s内部的dns会将mydb这个svc解析为对应的ip
      command:
        [
          "sh",
          "-c",
          "until nslookup mydb;do echo waiting for mydb;sleep 2;done;",
        ]

创建以下两个svc(service的简称)

myservice

kind: Service
apiVersion: v1
metadata:
  name: myservice
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

mydb

kind: Service
apiVersion: v1
metadata:
  name: mydb
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9377

探针

探针是由kubelet对容器执行的定期诊断，要执行诊断，kubelet调用由容器实现的Handler。有三种类型的处理程序

• ExecAction: 在容器内执行指定命令。如果命令退出时返回码为0则认为诊断成功
• TCPSocketAction: 对指定端口上的容器的IP地址进行TCP检查。如果端口打开，则诊断被认为是成功的。
• HTTPGetAction: 对执行的端口和路径上的容器IP地址执行HTTP Get请求。如果响应的状态码大于的等于200且小于400,则诊断被认为是成功的

每次探针都将获得以下三种结果之一

• 成功: 容器通过了诊断。
• 失败：容器未通过诊断
• 未知：诊断失败，因此不会采取任何行动

探测方案有两种

• LivenessProbe: 指示容器是否正在运行。如果存活探测失败，则kubectl会杀死容器，并且容器将受到其重启策略的影响。如果容器不提供存活探针，则默认状态为Success
• ReadinessProbe: 指示容器是否准备好服务请求。如果探测失败，端点控制器将从与Pod匹配的所有Service的端点中删除该Pod的IP地址。初始延迟之前的就绪状态默认为Failure。如果容器不提供就绪探针，则默认状态为Success

探针就绪检测

ReadinessProbe-httpget

apiVersion: v1
kind: Pod
metadata:
  name: readiness-httpget-pod
  namespace: default
spec:
  containers:
    - name: readiness-httpget-container
      image: nginx:1.19.6
      imagePullPolicy: IfNotPresent
      readinessProbe:
        httpGet:
          port: 80
          path: /index1.html
        initialDelaySeconds: 1
        periodSeconds: 3

生存检测

livenessProbe-exec

apiVersion: v1
kind: Pod
metadata:
  name: liveness-exec-pod
spec:
  containers:
    - name: liveness-exec-container
      image: nginx:1.19.6
      imagePullPolicy: IfNotPresent
      # 启动时创建/temp/live文件经过60s后删除它
      # 在liveness检测时启动1分钟内文件都存在容器正常
      # 1分钟后文件不存在，liveness检测不通过容器就会被k8s杀死,pod里的容器死亡pod就会重启
      command:
        [
          "/bin/sh",
          "-c",
          "touch /tmp/live;sleep 60; rm -rf /tmp/live; sleep 3600;",
        ]
      livenessProbe:
        exec:
          # 测试文件是否存在，如果存在返回值为0表正常
          command: ["test", "-e", "/tmp/live"]
        initialDelaySeconds: 1
        periodSeconds: 3

livenessProbe-httpget

apiVersion: v1
kind: Pod
metadata:
  name: liveness-httpget-pod
spec:
  containers:
    - name: liveness-httpget-container
      image: nginx:1.19.6
      imagePullPolicy: IfNotPresent
      ports:
        - name: http
          containerPort: 80
      livenessProbe:
        httpGet:
          port: http
          path: /index.html
        initialDelaySeconds: 1
        periodSeconds: 3

livenessProbe-tcp

apiVersion: v1
kind: Pod
metadata:
  name: liveness-tcp-pod
spec:
  containers:
    - name: nginx
      image: nginx:1.19.6
      imagePullPolicy: IfNotPresent
      livenessProbe:
        tcpSocket:
          # 监听80端口是否可连接
          port: 80
        timeoutSeconds: 1
        initialDelaySeconds: 5
        periodSeconds: 3

Initc、readiness、liveness可以相互配合使用

启动退出动作

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
    - name: nginx
      image: nginx:1.19.6
      imagePullPolicy: IfNotPresent
      lifecycle:
        # 启动之后
        postStart:
          exec:
            command:
              [
                "/bin/sh",
                "-c",
                "echo Hello from the postStart handler > /usr/share/message.txt",
              ]
        # 停止之前可以料理后事
        preStop:
          exec:
            command: ["/bin/sh", "-c", "echo preStop死前料理后事"]

Status状态有以下几种值

• Pending（挂起）: Pod已被Kubernetes系统接受，但有一个或多个容器镜像尚未创建。等待时间包括调度Pod的时间和通过网络下载镜像的时间

• Running（运行中）：该Pod已经绑定到了一个节点上，Pod中所有的容器都已被创建。至少有一个容器正在运行。或正处于启动或重启状态

• Succeeded（成功）：Pod中的所有容器都被成功终止，并且不会再重启

• Failed（失败）：Pod中的所有容器都已终止了，并且至少有一个容器是因为失败终止。也就是说，容器以非0状态退出或者被系统终止

• Unknown（未知）：因为某些原因无法取得Pod的状态，通常是因为与Pod所在主机通信失败

Replica Sets

ReplicaSet（RS）是Replication Controller（RC）的升级版本。ReplicaSet 和 Replication Controller之间的唯一区别是对选择器的支持。ReplicaSet支持labels user guide中描述的set-based选择器要求， 而Replication Controller仅支持equality-based的选择器要求。

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
spec:
  # 指定rs副本数
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
        - name: nginx
          image: nginx:1.19.6
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 80

RS与Deployment的关联

Deployment

Deployment为Pod和Replica Set（升级版的 Replication Controller）提供声明式更新。

你只需要在 Deployment 中描述您想要的目标状态是什么，Deployment controller 就会帮您将 Pod 和ReplicaSet 的实际状态改变到您的目标状态。您可以定义一个全新的 Deployment 来创建 ReplicaSet 或者删除已有的 Deployment 并创建一个新的来替换。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.18
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 80

执行

# record参数会记录执行过程
kubectl apply -f deployment-demo.yaml --record

Deployment使用申明式定义方法所以用apply创建

查看运行状态

$ kubectl get deployment

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           3m37s

创建Deployment会被创建RS可以通过以下命令验证

$ kubectl get rs

NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-76ccf9dd9d   3         3         3       4m14s

扩容

$ kubectl scale deployment nginx-deployment --replicas=4

更新镜像

$ kubectl set image deployment/nginx-deployment nginx=nginx:1.19

执行过程,会看到多出一个RS

$ kubectl set image deployment/nginx-deployment nginx=nginx:1.19
deployment.apps/nginx-deployment image updated
$ kubectl get deployment
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     1            3           105s
$ kubectl get rs
NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-67dfd6c8f9   3         3         3       111s
nginx-deployment-7cf55fb7bb   1         1         0       14s
$ kubectl get rs
NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-67dfd6c8f9   0         0         0       2m
nginx-deployment-7cf55fb7bb   3         3         3       23

回滚(默认回滚到上一个版本)

$ kubectl rollout undo deployment/nginx-deployment

其他常用命令

# 查看回滚状态
$ kubectl rollout status deployment/nginx-deployment
# 查看回滚历史
$ kubectl rollout history deployment/nginx-deployment
# 回退到指定版本通过--to-reversion指定
$ kubectl rollout undo deployment/nginx-deployment --to-reversion=2
# 暂停deployment的更新
$ kubectl rollout pause deployment/nginx-deployment

DemonSet

apiVersion: apps/v1
kind: DaemonSet
metadata:
  # step1
  name: daemonset-example
  labels:
    app: daemonset-demo
spec:
  selector:
    matchLabels:
      # 与step1保持一致
      name: daemonset-example
  template:
    metadata:
      labels:
        name: daemonset-example
    spec:
      containers:
        - name: nginx
          image: nginx:1.19.6
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 80

Job

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    metadata:
      name: pi
    spec:
      containers:
        - name: pi-container
          image: perl
          # 计算圆周率
          command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never

查看输出日志就能看到2000位的圆周率输出

$ kubectl logs job/pi

CronJob

声明式使用apply创建

创建job的操作应该是幂等的

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  # 分 时 日 月 周
  schedule: "*/1 * * * *"
  jobTemplate:
    # job
    spec:
      template:
        # pod
        spec:
          containers:
            - name: hello
              image: busybox:1.32
              args:
                - /bin/sh
                - -c
                - date;echo Hello from the Kubernetes cluster
          restartPolicy: Never

查看cronjob

$ kubectl get cronjob

SVC

Deployment与SVC绑定演示

创建Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      release: stabel
  template:
    metadata:
      labels:
        app: myapp
        release: stabel
        env: test
    spec:
      containers:
        - name: myapp
          image: wangyanglinux/myapp:v2
          imagePullPolicy: IfNotPresent
          ports:
            - name: http
              containerPort: 80

创建Service

apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  type: ClusterIP
  # 通过标签匹配pod
  selector:
    app: myapp
    release: stabel
  ports:
    - name: http
      port: 80
      targetPort: 80

HeadlessService

有时不需要或不想要负载均衡以及单独的Service IP。遇到这种情况，可以通过指定Cluster IP(spec.clusterIP)的值为None来创建Headless Service。这类Service并不会分配Cluster IP， kube-proxy不会处理他们，而且平台也不会为他们进行负载均衡和路由

apiVersion: v1
kind: Service
metadata:
  name: myapp-headless
  namespace: default
spec:
  selector:
    app: myapp
  clusterIP: "None"
  ports:
    - port: 80
      targetPort: 80

创建svc后查看输出像这样

$ kubectl get svc
NAME             TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
kubernetes       ClusterIP   10.96.0.1       <none>        443/TCP   23h
myapp-headless   ClusterIP   None            <none>        80/TCP    26s

SVC一旦创建成功会写入到coredns中去，写入格式为svc名称.所属名称空间名.集群域名可以获取K8S的dns地址

# 如果访问不到 进入minkube容器内部访问 执行: minikube ssh
$ kubectl get pod -n kube-system -o wide

输出像这样

NAME                               READY   STATUS    RESTARTS   AGE   IP             NODE       NOMINATED NODE   READINESS GATES
coredns-54d67798b7-5trfs           1/1     Running   1          23h   172.17.0.2     minikube   <none>           <none>
etcd-minikube                      1/1     Running   1          23h   192.168.49.2   minikube   <none>           <none>
kube-apiserver-minikube            1/1     Running   1          23h   192.168.49.2   minikube   <none>           <none>
kube-controller-manager-minikube   1/1     Running   1          23h   192.168.49.2   minikube   <none>           <none>
kube-proxy-zm25c                   1/1     Running   1          23h   192.168.49.2   minikube   <none>           <none>
kube-scheduler-minikube            1/1     Running   1          23h   192.168.49.2   minikube   <none>           <none>
storage-provisioner                1/1     Running   2          23h   192.168.49.2   minikube   <none>           <none>

可以看到coredns

# 通过coredns ip进行svc解析
dig -t A myapp-headless.default.svc.cluster.local. @172.17.0.2

输出结果像这样

docker@minikube:~$ dig -t A myapp-headless.default.svc.cluster.local. @172.17.0.2

; <<>> DiG 9.16.1-Ubuntu <<>> -t A myapp-headless.default.svc.cluster.local. @172.17.0.2
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34601
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 1a5ce669b9476b67 (echoed)
;; QUESTION SECTION:
;myapp-headless.default.svc.cluster.local. IN A

;; ANSWER SECTION:
myapp-headless.default.svc.cluster.local. 30 IN	A 172.17.0.5
myapp-headless.default.svc.cluster.local. 30 IN	A 172.17.0.4
myapp-headless.default.svc.cluster.local. 30 IN	A 172.17.0.3

;; Query time: 3 msec
;; SERVER: 172.17.0.2#53(172.17.0.2)
;; WHEN: Wed Jan 20 07:55:14 UTC 2021
;; MSG SIZE  rcvd: 249

NodePort

将服务暴露给外部用户，nodePort的原理在于在node上开了一个端口，将该端口的流量导入到kube-proxy，然后由kube-proxy进一步导给对应的pod

apiVersion: v1
kind: Service
metadata:
  name: myapp
  namespace: default
spec:
  type: NodePort
  selector:
    app: myapp
  ports:
    - name: http
      port: 80
      targetPort: 80

LoadBalancer

LoadBalancer和NodePort其实是同一种方式，区别在于LoadBalancer比NodePort多了一步，就是可以调用cloud provider去创建LB来向节点导流

ExternalName

这种类型的Service通过返回CNAME和它的值，可以将服务映射到externalName字段的内容例如:k8s.guqing.xyz。ExternalName Service是Service的特例，它没有selector,也没有定义任何的端口Endpoint。相反的，对于运行在集群外部的服务，它通过返回该外部服务的别名这种方式提供服务

kind: Service
apiVersion: v1
metadata:
  name: my-service-1
  namespace: default
spec:
  type: ExternalName
  externalName: my.database.example.com

当查询主机my-service.default.svc.cluster.local（格式为:SVC_NAME.NAMESPACE.svc.cluster.local）时，集群的DNS服务将返回一个值 my.database.example.com的CNAME记录。访问这个服务的工作方式和其他相同，唯一不同的是重定向发生在DNS层，而且不会进行代理或转发

创建svc如下

$ kubectl get svc

NAME           TYPE           CLUSTER-IP      EXTERNAL-IP               PORT(S)        AGE
kubernetes     ClusterIP      10.96.0.1       <none>                    443/TCP        3d
my-service-1   ExternalName   <none>          my.database.example.com   <none>         3s

解析过程如下

docker@minikube:~$ dig -t A my-service-1.default.svc.cluster.local. @172.17.0.2

; <<>> DiG 9.16.1-Ubuntu <<>> -t A my-service-1.default.svc.cluster.local. @172.17.0.2
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24122
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 9ba11bfc7ec49fd9 (echoed)
;; QUESTION SECTION:
;my-service-1.default.svc.cluster.local.	IN A

;; ANSWER SECTION:
my-service-1.default.svc.cluster.local.	30 IN CNAME my.database.example.com.

;; Query time: 1007 msec
;; SERVER: 172.17.0.2#53(172.17.0.2)
;; WHEN: Fri Jan 22 08:53:19 UTC 2021
;; MSG SIZE  rcvd: 154

Ingress-Nginx

github地址

Here is a simple example where an Ingress sends all its traffic to one Service:

minikube安装ingress-nginx

$ minikube addons enable ingress

k8s安装参考官网

$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v0.43.0/deploy/static/provider/baremetal/deploy.yaml

验证安装

$ kubectl get pods -n ingress-nginx

Ingress HTTP代理访问

deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-dm
spec:
  replicas: 2
  selector:
    matchLabels:
      name: nginx
  template:
    metadata:
      labels:
        name: nginx
    spec:
      containers:
        - name: nginx
          image: wangyanglinux/myapp:v1
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 80

Service

apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  selector:
    name: nginx
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP

Ingress

官方文档

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-test
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
    - host: www1.guqing.xyz
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: nginx-svc
                port:
                  number: 80

执行过程

$ minikube addons enable ingress
* The 'ingress' addon is enabled

$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v0.43.0/deploy/static/provider/baremetal/deploy.yaml
namespace/ingress-nginx created
serviceaccount/ingress-nginx created
configmap/ingress-nginx-controller created
clusterrole.rbac.authorization.k8s.io/ingress-nginx created
clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx created

$ kubectl get pods -n ingress-nginx
NAME                                        READY   STATUS              RESTARTS   AGE
ingress-nginx-admission-create-58mz2        0/1     ContainerCreating   0          11s
ingress-nginx-admission-patch-s9c2c         0/1     ContainerCreating   0          11s
ingress-nginx-controller-697b57b496-hj9cb   0/1     ContainerCreating   0          12s
# 创建deployment
$ kubectl apply -f deployment.yaml
# 创建svc
$ kubectl apply -f svc.yaml
service/nginx-svc created

$ kubectl get svc
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1        <none>        443/TCP   4m47s
nginx-svc    ClusterIP   10.103.242.217   <none>        80/TCP    2m41s
# 创建ingress
$ kubectl apply -f ingress.yaml

$ kubectl get svc -n ingress-nginx
NAME                                 TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
ingress-nginx-controller             NodePort    10.111.21.135   <none>        80:30793/TCP,443:30261/TCP   7m10s
ingress-nginx-controller-admission   ClusterIP   10.102.127.39   <none>        443/TCP                      7m10s
# 查看访问地址
$ minikube service -n ingress-nginx ingress-nginx-controller --url
http://172.17.0.16:30162
http://172.17.0.16:30747

$ vim /etc/hosts
# 添加记录指向ingress域名
# 172.17.0.16 www1.guqing.xyz

$ curl www1.guqing.xyz
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>

Ingress域名代理访问示例

以下步骤将在K8S提供的Minikube终端下运行 Launch Terminal

minikube version: v1.8.1

结构图示如下：

1. 启动ingress插件

$ minikube addons enable ingress
* The 'ingress' addon is enabled

$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v0.43.0/deploy/static/provider/baremetal/deploy.yaml

namespace/ingress-nginx created
serviceaccount/ingress-nginx created
configmap/ingress-nginx-controller created
clusterrole.rbac.authorization.k8s.io/ingress-nginx created
clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx created
role.rbac.authorization.k8s.io/ingress-nginx created
rolebinding.rbac.authorization.k8s.io/ingress-nginx created
service/ingress-nginx-controller-admission created
service/ingress-nginx-controller created
deployment.apps/ingress-nginx-controller created

2. 创建两个deployment和两个svc分别对应

deployment-svc-1.yaml标签为name=nginx1,容器名nginx1并与svc-1绑定

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment1
spec:
  replicas: 2
  selector:
    matchLabels:
      name: nginx1
  template:
    metadata:
      labels:
        name: nginx1
    spec:
      containers:
        - name: nginx1
          # 使用v1版本
          image: wangyanglinux/myapp:v1
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: svc-1
spec:
  selector:
    name: nginx1
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP

deployment-svc-2.yaml标签为name=nginx2,容器名nginx2并与svc-2绑定

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment2
spec:
  replicas: 2
  selector:
    matchLabels:
      name: nginx2
  template:
    metadata:
      labels:
        name: nginx2
    spec:
      containers:
        - name: nginx2
          # 使用v2版本
          image: wangyanglinux/myapp:v2
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: svc-2
spec:
  selector:
    name: nginx2
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP

创建

$ kubectl apply -f deployment-svc-1.yaml
$ kubectl apply -f deployment-svc-2.yaml

验证是否符合预期

$ kubectl get svc
NAME         TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1     <none>        443/TCP   31m
svc-1        ClusterIP   10.98.45.49   <none>        80/TCP    23m
svc-2        ClusterIP   10.98.55.46   <none>        80/TCP    20m

# 访问svc-1
$ curl 10.98.45.49
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>

# 访问svc-2
$ curl 10.98.55.46
Hello MyApp | Version: v2 | <a href="hostname.html">Pod Name</a>

3. 创建Ingress规则(ingress-rules.yaml),创建ingress-1与svc-1绑定,ingress-2与svc-2绑定

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: ingress-1
spec:
  rules:
    - host: ingress1.guqing.xyz
      http:
        paths:
          - path: /
            backend:
              serviceName: svc-1
              servicePort: 80
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: ingress-2
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
    - host: ingress2.guqing.xyz
      http:
        paths:
          - path: /
            backend:
              serviceName: svc-2
              servicePort: 80

创建

$ kubectl apply -f ingress-rules.yaml

进入到ingress容器中查看nginx配置

$ kubectl get pods -n ingress-nginx
NAME                                        READY   STATUS      RESTARTS   AGE
ingress-nginx-admission-create-fw2r6        0/1     Completed   0          38m
ingress-nginx-admission-patch-rsh8f         0/1     Completed   0          38m
ingress-nginx-controller-697b57b496-r8vpk   1/1     Running     0          38m
$ kubectl exec ingress-nginx-controller-697b57b496-r8vpk -n ingress-nginx -it -- /bin/bash
bash-5.0$ cat /etc/nginx/nginx.conf

此时会看到nginx的配置文件中自动被配置了ingress-rules.yaml中设置的两个host对应的域名

3. 配置hosts文件模拟访问域名

$ kubectl get ingress
NAME        HOSTS                 ADDRESS       PORTS   AGE
ingress-1   ingress1.guqing.xyz   172.17.0.33   80      4m1s
ingress-2   ingress2.guqing.xyz   172.17.0.33   80      4m1s

$ vim /etc/hosts

查看访问端口

$ kubectl get svc -n ingress-nginx
NAME                                 TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
ingress-nginx-controller             NodePort    10.110.79.62    <none>        80:31394/TCP,443:30567/TCP   4m1s
ingress-nginx-controller-admission   ClusterIP   10.110.32.131   <none>        443/TCP                      4m1s

访问

$ curl ingress1.guqing.xyz:31394
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>

$ curl ingress2.guqing.xyz:31394
Hello MyApp | Version: v2 | <a href="hostname.html">Pod Name</a>

Ingress HTTPS代理访问

创建证书及cert存储方式

$ open ssl req -x500 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=nginxsvc/O=nginxsvc"

$ kubectl create secret tls tls-secret --key tls.crt

Ingress配置示例

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: ingress-3
spec:
  tls:
    - hosts:
        - foo.bar.com
      # 与tls指定的名称一致
      secretName: tls-secret
  rules:
    - host: foo.bar.com
      http:
        paths:
          - path: /
            backend:
              serviceName: svc-3
              servicePort: 80

Nginx Basic Auth

$ yum -y install httpd
# 创建文件为auth 用户名为foo
$ htpasswd -c auth foo
$ kubectl create secret generic basic-auth --form-file=auth

创建ingress yaml

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: ingress-with-auth
  annotations:
    nginx.ingress.kubernetes.io/auth-type: basic
    nginx.ingress.kubernetes.io/auth-secret: basic-auth
    nginx.ingress.kubernetes.io/auth-realm: "Authentication Required - foo"
spec:
  rules:
    - host: foo2.bar.com
      http:
        paths:
          - path: /
            backend:
              serviceName: svc-4
              servicePort: 80

Nginx重写

示例

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: ingress-rewrite
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: http://foo.bar.com:31795/hostname.html
spec:
  rules:
    - host: foo3.bar.com
      http:
        paths:
          - path: /
            backend:
              serviceName: svc-5
              servicePort: 80

存储机制

Config Map

ConfigMap功能在Kubernetes1.2版本中引入，许多应用程序会从配置文件、命令行参数或环境变量中读取配置信息。ConfigMap API给我们提供了向容器中注入配置信息的机制，ConfigMap可以被用来保存单个属性，也可以用来保存整个配置文件或者JSON二进制大对象

ConfigMap的创建

1.使用目录创建

$ ls docs/user-guide/configmap/kubectl/
game.properties
ui.properties

$ cat docs/user-guide/config/kubectl/game.properties
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30

$ cat docs/user-guide/configmap/kubectl/ui.properties
color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice

$ kubectl create configmap game-config --from-file=docs/user-guide/configmap/kubectl

--from-file指定在目录下的所有文件都会被用在ConfigMap里面创建一个键值对，键的名称就是文件名，值就是文件内容

$ kubectl get configmap
NAME               DATA   AGE
game-config        2      30s
kube-root-ca.crt   1      7d22h

查看具体信息内容像这样(cm是configmap的简称)

$ kubectl get cm game-config -o yaml
apiVersion: v1
data:
  game.properties: |
    enemies=aliens
    lives=3
    enemies.cheat=true
    enemies.cheat.level=noGoodRotten
    secret.code.passphrase=UUDDLRLRBABAS
    secret.code.allowed=true
    secret.code.lives=30
  ui.properties: |
    color.good=purple
    color.bad=yellow
    allow.textmode=true
    how.nice.to.look=fairlyNice
kind: ConfigMap
metadata:
  creationTimestamp: "2021-01-27T06:57:37Z"
  managedFields:
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:data:
        .: {}
        f:game.properties: {}
        f:ui.properties: {}
    manager: kubectl-create
    operation: Update
    time: "2021-01-27T06:57:37Z"
  name: game-config
  namespace: default
  resourceVersion: "513536"
  uid: 74e9713b-8b5f-4512-a348-8691eb5afaca

2. 使用文件创建

只要指定为一个文件就可以从单个文件中创建ConfigMap

$ kubectl create configmap game-config-2 --from-file=docs/user-guide/configmap/kubectl/game.properties

$ kubectl get configmaps game-config-2 -o yaml

--from-file这个参数可以使用多次，例如可以使用两次分别指定上个示例中两个配置文件，效果就和指定整个目录一样

3.使用字面值创建

使用文字值创建，利用--from-literal参数传递配置信息，该参数可以使用多次，格式如下:

$ kubctl create configmap special-config --from-literal=special.how=very --from-literal=special.type=charm

$ kubectl get configmaps special-config -o yaml

Pod中使用ConfigMap

1.使用ConfigMap来替代环境变量

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  special.how: very
  special.type: charm

apiVersion: v1
kind: ConfigMap
metadata:
  name: env-config
  namespace: default
data:
  log_level: INFO

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: nginx:1.19.6
      command: ["/bin/sh", "-c", "env"]
      env:
        - name: SPECIAL_LEVEL_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config
              key: special.how
        - name: SPECIAL_TYPE_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config
              key: special.type
      envFrom:
        - configMapRef:
            name: env-config
  restartPolicy: Never

查看pod日志效果如下

$ kubectl logs dapi-test-pod
KUBERNETES_SERVICE_PORT=443
KUBERNETES_PORT=tcp://10.96.0.1:443
NGINX_SVC_SERVICE_HOST=10.102.29.151
HOSTNAME=dapi-test-pod
HOME=/root
NGINX_SVC_PORT=tcp://10.102.29.151:80
NGINX_SVC_SERVICE_PORT=80
PKG_RELEASE=1~buster
# special.type=charm
SPECIAL_TYPE_KEY=charm
NGINX_SVC_PORT_80_TCP_ADDR=10.102.29.151
NGINX_SVC_PORT_80_TCP_PORT=80
NGINX_SVC_PORT_80_TCP_PROTO=tcp
KUBERNETES_PORT_443_TCP_ADDR=10.96.0.1
NGINX_VERSION=1.19.6
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
KUBERNETES_PORT_443_TCP_PORT=443
NJS_VERSION=0.5.0
KUBERNETES_PORT_443_TCP_PROTO=tcp
NGINX_SVC_PORT_80_TCP=tcp://10.102.29.151:80
# special.how=very
SPECIAL_LEVEL_KEY=very
# log_level=INFO
log_level=INFO
KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_PORT_443_TCP=tcp://10.96.0.1:443
KUBERNETES_SERVICE_HOST=10.96.0.1
PWD=/

2.用ConfigMap设置命令行参数

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  special.how: very
  special.type: charm

apiVersion: v1
kind: Pod
metadata:
  name: configmap-test-pod
spec:
  containers:
    - name: test-container
      image: nginx:1.19.6
      command:
        ["/bin/sh", "-c", "echo $(SPECIAL_LEVEL_KEY) $(SPECIAL_TYPE_KEY)"]
      env:
        - name: SPECIAL_LEVEL_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config
              key: special.how
        - name: SPECIAL_TYPE_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config
              key: special.type
  restartPolicy: Never

查看日志效果如下

$ kubectl logs configmap-test-pod
very charm

3.通过数据卷插件使用ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  special.how: very
  special.type: charm

在数据卷里面使用这个ConfigMap，有不同的选项。最基本的就是将文件填入数据卷，在这个文件中，键就是文件名，键值就是文件内容

apiVersion: v1
kind: Pod
metadata:
  name: configmap-volume-pod
spec:
  containers:
    - name: test-container
      image: nginx:1.19.6
      command:
        ["/bin/sh", "-c", "ls /etc/config/ && cat /etc/config/special.how"]
      volumeMounts:
        - name: config-volume
          mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        name: special-config
  restartPolicy: Never

查看pod日志如下

$ kubectl logs  configmap-volume-pod
# 两个文件
special.how
special.type
# special.how内容
very

ConfigMap热更新

apiVersion: v1
kind: ConfigMap
metadata:
  name: log-config
  namespace: default
data:
  log_level: INFO
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      run: my-nginx
  template:
    metadata:
      labels:
        run: my-nginx
    spec:
      containers:
        - name: my-nginx
          image: nginx:1.19.6
          ports:
            - containerPort: 80
          volumeMounts:
            - name: config-volume
              mountPath: /etc/config
      volumes:
        - name: config-volume
          configMap:
            name: log-config

创建后查看内容

$ kubectl get pods
NAME                        READY   STATUS      RESTARTS   AGE
my-nginx-854969cf95-fmmp9   1/1     Running     0          23s 
$ kubectl exec my-nginx-854969cf95-fmmp9 -it -- cat /etc/config/log_level
# 结果为INFO
INFO

此时修改ConfigMap

$ kubectl edit configmap log-config

修改log_level的值未DEBUG等待约10s后再次查看环境变量的值

$ kubectl exec my-nginx-854969cf95-fmmp9 -icat /etc/config/log_level
# 值变为了DEBUG
DEBUG

Secret

Secret解决了密码、token、密钥等名干数据的配置问题，而不需要把这些敏感数据暴露到镜像或者Pod Spec中。Secret可以以Volume或者环境变量的方式使用

Secret有三种类型：

• Service Account: 用来访问Kubernetes API, 由Kubernetes自动创建，并且会自动挂载到Pod的/run/secrets/kubernetes.io/serviceaccount目录中
• Opaque： base64编码格式的Secret，用来存储密码、密钥等
• kubernetes.io/dockerconfigjson: 用来存储私有docker registry的认证信息

Service Account

Service Account 用来访问Kubernetes API, 由Kubernetes自动创建，并且会自动挂载到Pod的/run/secrets/kubernetes.io/serviceaccount目录中

Opaque Secret

1. 创建说明

Opaque类型的数据是一个map类型，要求value是base64编码格式

$ echo -n "admin" | base64
YWRtaW4=
$ echo -n "1f2d1e2e67df" | base64
MWYyZDFlMmU2N2Rm

secrets.yaml

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  username: YWRTAW4=
  password: MWYyZDFlMmU2N2Rm

执行过程

$ vim secrets.yaml
# 填充上述 secrets.yaml内容
$ kubectl apply -f secrets.yaml 
secret/mysecret created
$ kubectl get secret
NAME                  TYPE                                  DATA   AGE
default-token-kxgcl   kubernetes.io/service-account-token   3      8d
mysecret              Opaque 

可以看到默认有一个default-token,k8s会为每一个 namepace下创建一个SA(Service Account)用于Pod挂载

2. 使用方式

方式一：将secret挂载到Volume中

apiVersion: v1
kind: Pod
metadata:
  name: secret-test
  labels:
    name: secret-test
spec:
  volumes:
    - name: secrets
      secret:
        secretName: mysecret
  containers:
    - name: db
      image: nginx:1.19.6
      volumeMounts:
        - name: secrets
          mountPath: /etc/secrets
          readOnly: true

执行示例

$ kubectl get pods
NAME                        READY   STATUS      RESTARTS   AGE
secret-test                 1/1     Running     0          6s
$ kubectl exec secret-test -it -- /bin/sh
> ls
password  username
> cat username
admin
> cat password
1f2d1e2e67df

方式二：将Secret导入到环境变量中

apiVersion: apps/v1
kind: Deployment
metadata:
  name: pod-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: pod-deployment
  template:
    metadata:
      labels:
        app: pod-deployment
    spec:
      containers:
        - name: pod-1
          image: nginx:1.19.6
          ports:
            - containerPort: 80
          env:
            - name: TEST_USER
              valueFrom:
                secretKeyRef:
                  name: mysecret
                  key: username
            - name: TEST_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: mysecret
                  key: password

执行示例:

$ kubectl apply -f pod-deployment.yaml
deployment.apps/pod-deployment created
$ kubectl get pods
NAME                             READY   STATUS    RESTARTS   AGE
pod-deployment-6b988699d-ql596   1/1     Running   0          3s
pod-deployment-6b988699d-vwtcw   1/1     Running   0          3s
$ kubectl exec pod-deployment-6b988699d-ql596 -it -- /bin/sh
> echo $TEST_USER
admin
> echo $TEST_PASSWORD
1f2d1e2e67df

kubernetes.io/dockerconfigjson

使用Kubeclt创建docker registry认证的secret

$ kubectl create secret docker-registry myregistrykey --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKERUSER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL

secret "myregistrykey" created

在创建Pod的时候，通过imagePullSecrets来引用刚创建的myregistrykey

apiVersion: v1
kind: Pod
metadata:
  name: foo
spec:
  containers:
    - name: foo
      # 私有镜像
      image: guching/nginx:1.19.6
  imagePullSecrets:
    - name: myregistrykey

使用hub.docker.com仓库示例

$ kubectl create secret docker-registry myregistrykey --docker-username=guching --docker-password=xxx
secret/myregistrykey created
# foo-pod.yaml内容如上
$ kubectl create -f foo-pod.yaml
pod/foo created
$ kubectl get pods -w
NAME                             READY   STATUS              RESTARTS   AGE
foo                              0/1     ContainerCreating   0          3s
# 失败了一次
foo                              0/1     ErrImagePull        0          34s
# 运行成功
foo                              1/1     Running   0          2m36s

Volume

官网文档

容器磁盘上的文件的生命周期是短暂的，这就使得在容器中运行重要应用时会出现一些问题。首先，当容器崩溃时，kubelet会重启它，但是容器中的文件将丢失——容器以干净的状态（镜像最初的状态）重新启动，其次，在Pod中同时运行多个容器时，这些容器之间通常需要共享文件。Kubernetes中的Volume抽象就很好的解决了这些问题。

背景

Kubernetes中的卷有明确的寿命——与封装它的Pod相同。所以，卷的生命比Pod中的所有容器都长，当这个容器重启时数据仍然得以保存。当然，当Pod不再存在时，卷将不复存在。也许更重要的是，Kubernetes支持多种类型的卷，Pod可以同时使用任意数量的卷

卷的类型

Kubernetes支持以下类型的卷:

• awsElasticBlockStore、azureDisk、azureFile、cephfs、csi、downwardAPI、emptyDir
• fc、flocker、gcePersistentDisk、gitRepo、glusterfs、hostPath、iscsi、nfs
• persistentVolumeClaim、projected、portworxVolume、quobyte、rbd、scaleIO、secret
• storageos、vsphereVolume

emptyDir

当Pod被分配给节点时，首先会创建emptyDir卷，并且只要该POd在该节点上运行，该卷就会存在。正如卷的名字所述，它最初是空的。Pod中容器可以读取和写入emptyDir卷中的相同文件，尽管该卷可以挂载到每个容器中的相同或不同路径上。当出于任何原因从节点中删除Pod时，emptyDir中的数据将被永久删除（注：容器崩溃时不会从节点中移除Pod，因此emptyDir卷中的数据在容器崩溃时是安全的）

emptyDir的用法有：

• 暂存空间，例如用于基于磁盘的合并排序
• 用作长时间计算崩溃恢复时的检查点
• Web服务器容器提供数据时，保存内容管理器容器提取的文件

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
    - name: test-container
      image: nginx:1.19.6
      volumeMounts:
        - mountPath: /cache
          # 挂载cache-volume卷
          name: cache-volume
  volumes:
    - name: cache-volume
      emptyDir: {}

不同的容器可以使用不同的mountPath指向同一个卷例如

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
    - name: test-container
      image: nginx:1.19.6
      volumeMounts:
        - mountPath: /cache
          name: cache-volume
    - name: busybox
      image: busybox:1.32
      imagePullPolicy: IfNotPresent
      command: ["/bin/sh", "-c", "sleep 3600s"]
      volumeMounts:
        - mountPath: /test
          name: cache-volume
  volumes:
    - name: cache-volume
      emptyDir: {}

如上test-container容器的卷路径为cache，而busybox容器的卷路径为test都是指向同一个卷cache-volume内容是共享的只是路径不同

hostPath

hostPath卷将主机节点的文件系统中的文件或目录挂载到集群中

hostPath的用途如下：

• 运行需要访问Docker内部的容器，使用/var/lib/docker的hostPath
• 在容器中运行cAdvisor使用/dev/cgroups的hostPath

除了所需要的path属性之外，用户还可以为hostPath卷指定type

使用这种卷类型时请注意：

• 由于每个节点上的文件都不同，具有相同的配置（例如从PodTemplate创建）的Pod在不同节点上的行为可能会有所不同
• 当Kubernetes按照计划添加资源感知调度时，将无法考虑hostPath使用的资源
• 在底层主机上创建的文件或目录只能由root写入。你需要在特权容器中以root身份运行进程，或修改主机上的文件权限以便写入hostPath卷

apiVersion: v1
kind: Pod
metadata:
  name: test-pod-1
spec:
  containers:
    - name: test-container
      image: nginx:1.19.6
      volumeMounts:
        - mountPath: /cache
          name: cache-volume
  volumes:
    - name: cache-volume
      hostPath:
        # 主机中的目录路径
        path: /data
        # 类型，可选值
        type: Directory

注意：如果使用minikube driver=docker方式执行则hostPath.path在minikube容器中

Persistent Volume

Persistent Volume简称PV,是由管理员设置的存储，它是集群的一部分，就像节点是集群中的资源一样，PV也是集群中的资源。PV是Volume之类的卷插件，但具有独立于使用PV的Pod的生命周期。此API对象包含存储实现的细节，即NFS、ISCSI或特定与云供应商的存储系统

PersistentVolumesClaim

PersistentVolumesClaim是用户存储的请求，简称PVC。它与Pod相似，Pod消耗节点资源，PVC消耗PV资源。Pod可以请求特定级别的资源(CPU和内存)。声明可以请求特定的大小和访问模式（例如，可以读/写一次或只读多次模式挂载）

静态PV

集群管理员创建一些PV，他们带有可供集群用户使用的实际存储的细节。他们存在与Kubernetes API中，可以用于消费

动态

当管理员创建的静态PV都不匹配用户的PersistentVolumeClaim时，集群可能会尝试动态的为PVC创建卷。此配置基于StorageClasses:PVC必须请求[存储类],并且管理员必须创建并配置该类才能进行动态创建。声明该类为""可以有效的禁用其动态配置

要器用基于存储级别的动态存储配置，集群管理员需要器用API server上的DefaultStorageClass[准入控制器]。例如，通过确保DefaultStorageClass位于API Server组建的--admission-control标志，使用逗号分隔

44

简介

minikube是什么?

minikube is local Kubernetes, focusing on making it easy to learn and develop for Kubernetes.

All you need is Docker (or similarly compatible) container or a Virtual Machine environment, and Kubernetes is a single command away: minikube start

What you’ll need（重点）

• 2 CPUs or more
• 2GB of free memory
• 20GB of free disk space
• Internet connection
• Container or virtual machine manager, such as: Docker, Hyperkit, Hyper-V, KVM, Parallels, Podman, VirtualBox, or VMWare

引用自minikube官网

当然不安装minikube也可以方便的学习Kubernetes，Kubernetes官网提供了交互式的学习教程并提供了minikube的控制台，点击Hello Minikube查看。建议使用代理以获得良好的体验

先决条件

安装 kubectl

$ curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl
$ chmod +x ./kubectl
$ sudo mv ./kubectl /usr/local/bin/kubectl
$ kubectl version --client

Minikube在不同操作系统上支持不同的驱动

• macOS

  • Docker 缺省驱动

  • xhyve driver , VirtualBox 或 VMware Fusion

• Linux

  • VirtualBox 或 KVM2
  • Docker --driver缺省时驱动

• Windows

  • VirtualBox 或 Hyper-V

安装MiniKube

该安装方式针对于Linux用户，其他平台差不多具体参考MiniKube官网安装文档,这里只解决服务器没有代理无法访问到google镜像仓库的问题。

提示

• 官方推荐使用--driver=docker即缺省参数,此时不支持使用root用户，否则无法安装
• 使用docker作为运行时环境,如果没有则需要提前安装,centos7/8可以使用daocloud提供的自动安装脚本

curl -sSL https://get.daocloud.io/docker | sh

Mac OSX

curl -Lo minikube https://kubernetes.oss-cn-hangzhou.aliyuncs.com/minikube/releases/v1.16.0/minikube-darwin-amd64 && chmod +x minikube && sudo mv minikube /usr/local/bin/

Linux

curl -Lo minikube https://kubernetes.oss-cn-hangzhou.aliyuncs.com/minikube/releases/v1.16.0/minikube-linux-amd64 && chmod +x minikube && sudo mv minikube /usr/local/bin/

Windows
下载 minikube-windows-amd64.exe 文件，并重命名为 minikube.exe

启动

minikube start

为了访问海外的资源，使用阿里云提供的镜像，可按照如下参数进行配置。其中常见参数：

• --driver=xxx 从1.5.0版本开始，Minikube缺省使用本地最好的驱动来创建Kubernetes本地环境，测试过的版本 docker, kvm
• --image-mirror-country=cn 将缺省利用 registry.cn-hangzhou.aliyuncs.com/google_containers 作为安装Kubernetes的容器镜像仓库 （阿里云版本可选）
• --iso-url=xxx 利用阿里云的镜像地址下载相应的 .iso 文件 （阿里云版本可选）
• --registry-mirror=xxx 为了拉取Docker Hub镜像，需要为 Docker daemon 配置镜像加速，参考阿里云镜像服务
• --cpus=2: 为minikube虚拟机分配CPU核数
• --memory=2048mb: 为minikube虚拟机分配内存数
• --kubernetes-version=xxx: minikube 虚拟机将使用的 kubernetes 版本

启动示例推荐

minikube start --driver=docker --image-mirror-country=cn --registry-mirror=https://kaakiyao.mirror.aliyuncs.com

结果

😄  Centos 8.3.2011 上的 minikube v1.16.0
✨  根据用户配置使用 docker 驱动程序
✅  正在使用镜像存储库 registry.cn-hangzhou.aliyuncs.com/google_containers
👍  Starting control plane node minikube in cluster minikube
🔥  Creating docker container (CPUs=2, Memory=2200MB) ...
    > kubectl.sha256: 64 B / 64 B [--------------------------] 100.00% ? p/s 0s
    > kubeadm.sha256: 64 B / 64 B [--------------------------] 100.00% ? p/s 0s
    > kubelet.sha256: 64 B / 64 B [--------------------------] 100.00% ? p/s 0s
    > kubeadm: 37.40 MiB / 37.40 MiB [---------------] 100.00% 14.54 MiB p/s 3s
    > kubectl: 38.37 MiB / 38.37 MiB [----------------] 100.00% 4.21 MiB p/s 9s
    > kubelet: 108.69 MiB / 108.69 MiB [------------] 100.00% 11.48 MiB p/s 10s

    ▪ Generating certificates and keys ...
    ▪ Booting up control plane ...
    ▪ Configuring RBAC rules ...
🔎  Verifying Kubernetes components...
🌟  Enabled addons: default-storageclass, storage-provisioner
🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default

在数学中，两个集合X和Y的笛卡儿积，又称直积，在集合论中表示为X x Y，是所有可能的有序对组成的集合，其中有序对的第一个对象是X的成员，第二个对象是Y的成员。

X×Y={(x,y)∣x∈X∧y∈Y}

举个实例,假设有两个集合 A 和 B:

A = {0,1}
B = {2,3,4}

那么A和B的笛卡尔积 A×B 表示如下：

A×B = {（0，2），（1，2），（0，3），（1，3），（0，4），（1，4）}

笛卡尔积的Java实现如下:

/**
 * 笛卡尔积工具类
 *
 * @author guqing
 * @date 2020-10-13
 */
public class CartesianUtils {
    public static<T> List<List<T>> cartesianProduct(List<List<T>> dimensionValue) {
        List<List<T>> result = new LinkedList<>();
        cartesianProduct(dimensionValue, result, 0, new ArrayList<>());
        return result;
    }

    private static<T> void cartesianProduct(List<List<T>> dimensionValue, List<List<T>> result, int layer, List<T> currentList) {
        if (layer < dimensionValue.size() - 1) {
            if (dimensionValue.get(layer).size() == 0) {
                cartesianProduct(dimensionValue, result, layer + 1, currentList);
            } else {
                for (int i = 0; i < dimensionValue.get(layer).size(); i++) {
                    List<T> list = new ArrayList<>(currentList);
                    list.add(dimensionValue.get(layer).get(i));
                    cartesianProduct(dimensionValue, result, layer + 1, list);
                }
            }
        } else if (layer == dimensionValue.size() - 1) {
            if (dimensionValue.get(layer).size() == 0) {
                result.add(currentList);
            } else {
                for (int i = 0; i < dimensionValue.get(layer).size(); i++) {
                    List<T> list = new ArrayList<>(currentList);
                    list.add(dimensionValue.get(layer).get(i));
                    result.add(list);
                }
            }
        }
    }
}

简述

在高并发场景下查询缓存时很容易出现缓存击穿(本文针对单机没有使用分布式锁)，这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力,因此查询缓存需要进行加锁,但这种代码每次写多了很烦,而且容易写错,因此本文采用模板方法模式简化缓存查询及并发处理

快速开始

Redis Dependency:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

Redis Service

public interface RedisService {
    /**
     * 存储数据
     */
    void set(String key, String value);

    /**
     * SET key value EX seconds，设置key-value和超时时间（秒）
     * 存储数据并设置过期时间
     *
     * @param key cache key
     * @param value cache value
     * @param expire expire time,time unit is seconds
     */
    void set(String key, String value, long expire);

    /**
     * 存储数据并设置过期时间通知指定过期时间的单位
     * @param key 数据的键
     * @param value 值
     * @param expire 过期时间
     * @param timeUnit 过期时间的单位
     */
    void set(String key, String value, long expire, TimeUnit timeUnit);

    /**
     * 获取数据
     */
    String get(String key);

    /**
     * 设置超期时间
     * @param key
     * @param expire 过期时间
     * @return 设置成功返回true, 否则返回false
     */
    boolean expire(String key, long expire);

    /**
     * 删除数据
     */
    void remove(String key);

    /**
     * 自增操作
     * @param delta 自增步长
     */
    Long increment(String key, long delta);
}

Redis Service Impl

@Service
public class RedisServiceImpl implements RedisService {
    private static final long DEFAULT_EXPIRE_SECONDS = 10;

    private final StringRedisTemplate redisTemplate;

    @Autowired
    public RedisServiceImpl(StringRedisTemplate redisTemplate) {
        this.redisTemplate = redisTemplate;
    }

    @Override
    public void set(String key, String value) {
        redisTemplate.opsForValue().set(key, value, DEFAULT_EXPIRE_SECONDS, TimeUnit.MINUTES);
    }

    @Override
    public void set(String key, String value, long expire) {
        redisTemplate.opsForValue().set(key, value, expire, TimeUnit.SECONDS);
    }

    @Override
    public void set(String key, String value, long expire, TimeUnit timeUnit) {
        redisTemplate.opsForValue().set(key, value, expire, timeUnit);
    }

    @Override
    public String get(String key) {
        return redisTemplate.opsForValue().get(key);
    }

    @Override
    public boolean expire(String key, long expire) {
        Boolean result = redisTemplate.expire(key, expire, TimeUnit.SECONDS);
        if(result == null) {
            return false;
        }
        return result;
    }

    @Override
    public void remove(String key) {
        redisTemplate.delete(key);
    }

    @Override
    public Long increment(String key, long delta) {
        return redisTemplate.opsForValue().increment(key,delta);
    }
}

Redis Key Util:

public class RedisUtils {
    /**
     * 主数据系统标识
     */
    private static final String KEY_PREFIX = "halo";
    /**
     * 分割字符，默认[:]，使用:可用于rdm分组查看
     */
    private static final String KEY_SPLIT_CHAR = ":";

    /**
     * redis的key键规则定义
     * @param module 模块名称
     * @param service service名称
     * @param args 参数..
     * @return key
     */
    public static String keyBuilder(String module, String service, String... args) {
        return keyBuilder(null, module, service, args);
    }

    /**
     * redis的key键规则定义
     * @param module 模块名称
     * @param service service名称
     * @param objStr 对象.toString()
     * @return key
     */
    public static String keyBuilder(String module, String service, String objStr) {
        return keyBuilder(null, module, service, new String[]{objStr});
    }

    /**
     * redis的key键规则定义
     * @param prefix 项目前缀
     * @param module 模块名称
     * @param service service名称
     * @param objStr 对象.toString()
     * @return key
     */
    public static String keyBuilder(String prefix, String module, String service, String objStr) {
        return keyBuilder(prefix, module, service, new String[]{objStr});
    }

    /**
     * redis的key键规则定义
     * @param prefix 项目前缀
     * @param module 模块名称
     * @param service 方法名称
     * @param args 参数..
     * @return key
     */
    public static String keyBuilder(String prefix, String module, String service, String... args) {
        // 项目前缀
        if (prefix == null) {
            prefix = KEY_PREFIX;
        }
        StringBuilder key = new StringBuilder(prefix);
        // KEY_SPLIT_CHAR 为分割字符
        key.append(KEY_SPLIT_CHAR).append(module).append(KEY_SPLIT_CHAR).append(service);
        for (String arg : args) {
            key.append(KEY_SPLIT_CHAR).append(arg);
        }
        return key.toString();
    }

    /**
     * redis的key键规则定义
     * @param cacheEnum 枚举对象
     * @param objStr 对象.toString()
     * @return key
     */
    public static String keyBuilder(CacheEnum cacheEnum, String objStr) {
        return keyBuilder(cacheEnum.getPrefix(), cacheEnum.getModule(), cacheEnum.getService(), objStr);
    }
}

Cache Enum

@Data
@AllArgsConstructor
public enum CacheEnum {
    CMS_POST("halo", "cms", "PostService", "文章缓存");
    //other enum....
    
   /**
     * key前缀
     */
    private String prefix;
    /**
     * 模块名称
     */
    private String module;
    /**
     * service名称
     */
    private String service;
    /**
     * 描述
     */
    private String desc;
}

CacheTemplate:

@Component
public class CacheTemplate {
    @Autowired
    private RedisService redisService;

    public <T> T findCache(String key, Class<T> clazz, LoadCallback<T> loadCallback) {
        String cacheValueString =  redisService.get(key);
        if(StringUtils.isEmpty(cacheValueString)) {
            synchronized (this) {
                cacheValueString =  redisService.get(key);
                if(ObjectUtils.isEmpty(cacheValueString)) {
                    T dataOfMysql = loadCallback.load();

                    // 如果为null也放入缓存,过期时间为1分钟
                    if (dataOfMysql == null) {
                        redisService.set(key, "null", 60L);
                    } else {
                        // 否则放入缓存,过期时间为10分钟
                        redisService.set(key, JSON.toJSONString(dataOfMysql));
                    }

                    return dataOfMysql;
                }

                return JSON.parseObject(cacheValueString, clazz);
            }
        } else {
            return JSON.parseObject(cacheValueString, clazz);
        }
    }

    public <T> T findCache(String key, TypeReference<T> typeReference, LoadCallback<T> loadCallback) {
        String cacheValueString =  redisService.get(key);
        if(StringUtils.isEmpty(cacheValueString)) {
            synchronized (this) {
                cacheValueString =  redisService.get(key);
                if(ObjectUtils.isEmpty(cacheValueString)) {
                    T dataOfMysql = loadCallback.load();
                    // 如果为null也放入缓存,过期时间为1分钟
                    if (dataOfMysql == null) {
                        redisService.set(key, "null", 60L);
                    } else {
                        // 否则放入缓存,过期时间为10分钟
                        redisService.set(key, JSON.toJSONString(dataOfMysql));
                    }

                    return dataOfMysql;
                }

                return JSON.parseObject(cacheValueString, typeReference);
            }
        } else {
            return JSON.parseObject(cacheValueString, typeReference);
        }
    }

    public <T> T findCache(String key, long expire, TypeReference<T> typeReference, LoadCallback<T> loadCallback) {
        String cacheValueString =  redisService.get(key);

        if(StringUtils.isEmpty(cacheValueString)) {
            synchronized (this) {
                cacheValueString =  redisService.get(key);
                if(ObjectUtils.isEmpty(cacheValueString)) {
                    T dataOfMysql = loadCallback.load();

                    // 如果为null也放入缓存,过期时间为1分钟
                    if (dataOfMysql == null) {
                        redisService.set(key, "null", 60L);
                    } else {
                        // 否则放入缓存,过期时间为10分钟
                        redisService.set(key, JSON.toJSONString(dataOfMysql), expire);
                    }

                    return dataOfMysql;
                }

                return JSON.parseObject(cacheValueString, typeReference);
            }
        } else {
            return JSON.parseObject(cacheValueString, typeReference);
        }
    }
}

LoadCallback

@FunctionalInterface
public interface LoadCallback<T> {
    /**
     * 从数据库查询数据逻辑,查询后的结果会被优先放入缓存
     * @return 返回查询结果对象
     */
    T load();
}

Example:

@Slf4j
@Service
public class PostServiceImpl extends BasePostServiceImpl<Post> implements PostService {
    private final PostRepository postRepository;
    private final CacheTemplate cacheTemplate;
    
    @Autowired
    public PostServiceImpl(PostRepository postRepository,
                          CacheTemplate cacheTemplate) {
        this.postRepository = postRepository;
        this.cacheTemplate = cacheTemplate;
    }
    
     public Post getBy(PostStatus status, String slug) {
         // 构建缓存key
         String cacheKey = RedisUtils.keyBuilder(CacheEnum.CMS_POST, "status:" + status.getValue() + ":slug:" + slug);
         return cacheTemplate.findCache(cacheKey, Post.class, ()->{
             // 从数据库查询数据的逻辑,这里可以简化为一行写
             return super.getBy(status, slug);
         });
    }
}

使用JavaScript闭包，进行传值操作。

export default {
    name: 'Achievement',
    data () {
        return {
            ...
        }
    },
    methods: {
        ...
    },
    computed: {
        myfilter() {
            return function(index){
                return this.arr[index].username.match(this.name)!==null;         
            }           
        } 
    }
}

使用计算属性传参

<tr v-for="(item,index) in arr" v-if="myfilter(index)">
    <td>{{item.username}}</td>
    <td>{{item.sex}}</td>
    <td>{{item.grade}}</td>
    <td>
        <a href="#" @click="delClick(index)">删除</a>
    </td>
</tr>

引言

对于一个web项目而言后端经常需要对前端参数进行校验，传统方式常常是在controller中使用大量if else进行参数合法性校验，这样做的缺点显而易见，便不在赘述。

解决方案

对于以上问题，SpringBoot项目我列举了三种处理方式：

对于前端传参的实体我们可以写这样一个类例如UserParam，然后使用javax.validation提供的注解进行参数条件限制

@Data
public class UserParam {
    private Integer id;

    @NotBlank(message="用户名不能为空")
    private String username;

    @Pattern(regexp = "^[a-zA-Z0-9_-]+@[a-zA-Z0-9_-]+(\\\\.[a-zA-Z0-9_-]+)+$", message = "邮箱地址格式不正确")
    private String email;

    @Pattern(regexp="^((13[0-9])|(15[^4,\\D])|(18[0,5-9]))\\d{8}$", message="手机号格式不正确")
    private String telephone;

    @Max(value=144, message="长度必须小于144个字符")
    private String description;
}

基于这样一个类，提出了两种关于aop的方式和一种异常处理的方式

AOP参数校验方式一

写一个AOP参数校验的类：

@Aspect
@Component
public class ValidParamAdvice {
    /**
     * 定义切点，切点为xyz.guqing.storycard.controller包和子包里任意方法的执行
     */
    @Pointcut("execution(* xyz.guqing.storycard.controller..*(..))")
    public void controllerPointCut() {
    }

    @Around("controllerPointCut() && args(.., bindingResult)")
    public Object doAround(ProceedingJoinPoint joinPoint, BindingResult bindingResult) throws Throwable {
        // 收集并返回参数校验错误信息，这里根据实际返回结果类自己封装
        if(bindingResult.hasErrors()) {
            Map<String, String> errors = new HashMap<>(16);
            List<FieldError> fieldErrors = bindingResult.getFieldErrors();
            fieldErrors.forEach(fieldError -> {
                errors.put(fieldError.getField(), fieldError.getDefaultMessage());
            });
            return errors.toString();
        }

        return joinPoint.proceed(joinPoint.getArgs());
    }
}

然后在controller中使用如下,只需要在参数UserParam前添加@Valid即可完成参数校验

@RestController
@CrossOrigin
@RequestMapping("/user")
public class UserController {

    @PostMapping("/advice-valid")
    public String exceptionAdviceValidUser(@RequestBody @Valid UserParam userParam) {
        return userParam.toString();
    }
}

AOP参数校验方式二

同样写一个aop参数处理类

@Aspect
@Component
public class ValidParamAdvice {
    /**
     * 定义切点，切点为xyz.guqing.storycard.controller包和子包里任意方法的执行
     */
    @Pointcut("execution(* xyz.guqing.storycard.controller..*(..))")
    public void controllerPointCut() {
    }

    @Around("controllerPointCut()")
    public Object around(ProceedingJoinPoint joinPoint) throws Throwable {
        BindingResult bindingResult = null;
        // 使用遍历参数的方式找到BindingResult
        for(Object arg:joinPoint.getArgs()){
            if(arg instanceof BindingResult){
                bindingResult = (BindingResult) arg;
            }
        }

        if(bindingResult != null && bindingResult.hasErrors()){
            Map<String, String> errors = new HashMap<>(16);
            List<FieldError> fieldErrors = bindingResult.getFieldErrors();
            fieldErrors.forEach(fieldError -> {
                errors.put(fieldError.getField(), fieldError.getDefaultMessage());
            });
            return errors.toString();
        }
        return joinPoint.proceed();
    }
}

在controller中使用

@RestController
@CrossOrigin
@RequestMapping("/user")
public class UserController {
    @PostMapping("/aop-valid")
    public String aopValidUser(@RequestBody @Valid UserParam userParam, BindingResult result) {
        return userParam.toString();
    }
}

如上，不同点在于不仅需要在UserParam参数前写@Valid，还需要多添加一个参数BindingResult result才可以

全局异常处理参数校验

写这样一个异常处理类

@RestControllerAdvice
@Slf4j
public class ValidExceptionAdvice {

    /**
     * 当使用@Valid不带@RequestBody request参数时:
     * 对象验证失败，验证将引发BindException而不是MethodArgumentNotValidException
     * @param e 参数绑定异常
     * @return 返回参数校验失败的错误信息
     */
    @ExceptionHandler(BindException.class)
    public Object validExceptionHandler(BindException e){
        // 将错误的参数的详细信息封装到统一的返回实体
        return validParam(e.getBindingResult());
    }

    /**
     * 使用@Valid并且带有@RequestBody request参数时
     * 参数教研失败将抛出MethodArgumentNotValidException异常，由此方法捕获处理
     * @param e 方法参数校验失败的异常
     * @return 返回校验失败错误信息
     */
    @ExceptionHandler(MethodArgumentNotValidException.class)
    public Object validExceptionHandler(MethodArgumentNotValidException e){
        return validParam(e.getBindingResult());
    }

    private Object validParam(BindingResult bindResult) {
        List<FieldError> fieldErrors = bindResult.getFieldErrors();
        Map<String, String> map = new HashMap<>(16);
        fieldErrors.forEach(fieldError -> {
            map.put(fieldError.getField(), fieldError.getDefaultMessage());
        });

        return map;
    }
}

在controller中使用

@RestController
@CrossOrigin
@RequestMapping("/user")
public class UserController {

    @PostMapping("/advice-valid")
    public String exceptionAdviceValidUser(@RequestBody @Valid UserParam userParam) {
        return userParam.toString();
    }
}

只需要在需要进行参数校验的参数UserParam前添加@Valid即可，当校验不通过时会被ValidExceptionAdvice类拦截处理

@Valid注解说明

java的JSR303声明了@Valid这类接口，而Hibernate-validator对其进行了实现,因此具体注解使用参考Hibernate Validator,下面列举一些常见注解的使用说明：

1、初步认识

观察者模式的定义：
　　在对象之间定义了一对多的依赖，这样一来，当一个对象改变状态，依赖它的对象会收到通知并自动更新。
理解：
　　当被观察者状态改变时通知观察者处理，注意观察者模式与发布订阅模式不同的是观察者模式没有调度中心通俗讲叫经纪人

2、这个模式的结构图

上图解释：

• 抽象被观察者角色：也就是一个抽象主题，它把所有对观察者对象的引用保存在一个集合中，每个主题都可以- - 有任意数量的观察者。抽象主题提供一个接口，可以增加和删除观察者角色。一般用一个抽象类和接口来实现。
• 抽象观察者角色：为所有的具体观察者定义一个接口，在得到主题通知时更新自己。
• 具体被观察者角色：也就是一个具体的主题，在集体主题的内部状态改变时，所有登记过的观察者发出通知。
• 具体观察者角色：实现抽象观察者角色所需要的更新接口，一边使本身的状态与制图的状态相协调。

3、使用场景例子

有一个微信公众号服务，不定时发布一些消息，此时，用户关注公众号那么用于就相当于观察者而公众号则是被观察者，当被观察者状态改变时(有新文章)则观察者会观察到状态改变(收到文章)

4、观察者模式具体实现

1、定义一个抽象被观察者接口

/**
 * 抽象被观察者接口
 * 声明了添加、删除、通知观察者方法
 * @author guqing
 * @date 2019-12-17 19:25
 */
public interface Observerable {
    void addObserver(Observer o);
    void removeObserver(Observer o);
    void notifyObserver();
}

2、定义一个抽象观察者接口

/**
 * 抽象观察者
 * @author guqing
 * @date 2019-12-17 19:30
 */
public interface Observer {
    /**
     * 定义了一个update()方法，当被观察者调用
     * notifyObservers()方法时，观察者的update()方法会被回调。
     * @param message 消息
     */
    void update(String message);
}

3、定义被观察者，实现了Observerable接口，对Observerable接口的三个方法进行了具体实现，同时有一个List集合，用以保存注册的观察者，等需要通知观察者时，遍历该集合即可。

/**
 * 被观察者，也就是微信公众号服务
 * 实现了Observerable接口，对Observerable接口的三个方法进行了具体实现
 * @author guqing
 * @date 2019-12-17 19:32
 */
@Data
public class WechatServer implements Observerable{
    private List<Observer> list = new ArrayList<>();
    private String message;

    @Override
    public void addObserver(Observer o) {
        this.list.add(o);
    }

    @Override
    public void removeObserver(Observer o) {
        if(!list.isEmpty()) {
            list.remove(o);
        }
    }

    @Override
    public void notifyObserver() {
        list.forEach(observer -> {
            observer.update(message);
        });
    }

    public void setInfomation(String s) {
        this.message = s;
        System.out.println("微信服务更新消息： " + s);
        //消息更新，通知所有观察者
        notifyObserver();
    }
}

4、定义具体观察者，微信公众号的具体观察者为用户User

/**
 * 观察者
 * 实现了update方法
 * @author guqing
 * @date 2019-12-17 19:52
 */
public class User implements Observer {
    private String name;
    private String message;

    public User(String name) {
        this.name = name;
    }

    @Override
    public void update(String message) {
        this.message = message;
        read();
    }

    private void read() {
        System.out.println(name + " 收到推送消息： " + message);
    }
}

5、编写一个测试类

首先注册了三个用户，ZhangSan、LiSi、WangWu。公众号发布了一条消息PHP是世界上最好用的语言！，三个用户都收到了消息。
用户ZhangSan看到消息后颇为震惊，果断取消关注(观察者取消观察)，这时公众号又推送了一条消息，此时用户ZhangSan已经收不到消息，其他用户还是正常能收到推送消息。

/**
 * 观察者模式测试类
 * @author guqing
 * @date 2019-12-17 19:54
 */
public class ObserverTest {
    public static void main(String[] args) {
        WechatServer server = new WechatServer();

        // 创建三个用户
        Observer userZhang = new User("ZhangSan");
        Observer userLi = new User("LiSi");
        Observer userWang = new User("WangWu");

        // 让三个用户 关注(叫观察会更贴切些) 该服务(被观察者)
        server.addObserver(userZhang);
        server.addObserver(userLi);
        server.addObserver(userWang);

        // 向服务器（被观察者状态改变）中发送消息
        server.setInfomation("PHP是世界上最好用的语言！");

        /*
         * 输出结果:
         * 微信服务更新消息： PHP是世界上最好用的语言！
         * ZhangSan 收到推送消息： PHP是世界上最好用的语言！
         * LiSi 收到推送消息： PHP是世界上最好用的语言！
         * WangWu 收到推送消息： PHP是世界上最好用的语言！
         */

        System.out.println("---------------------------------");
        // 张三一听不是Java恼火了取消观察
        server.removeObserver(userZhang);

        // 被观察者数据改变，观察者监听到改变作出相应处理
        server.setInfomation("JAVA是世界上最好用的语言！");
        /*
         * 输出结果：
         * 微信服务更新消息： JAVA是世界上最好用的语言！
         * LiSi 收到推送消息： JAVA是世界上最好用的语言！
         * WangWu 收到推送消息： JAVA是世界上最好用的语言！
         */
    }
}

测试结果：

原文内容来自：神仙果 本站略作修改
点击查看原文

引言

使用Arch Linux 时间长了，空间越来越少，不禁想到要清理一下空间。 我将清理的内容分成三部分，清理安装包缓存，清理孤立的软件包，以及清理日志。

清理安装包缓存

使用如下命令

$ sudo pacman -Scc

不仅会删除未安装或旧版本的包文件缓存，也会将安装着的包的包文件缓存也一并删除。这部分是最占空间的，我大概有7-8G。

清理孤立的软件包

使用如下命令

sudo pacman -Rns $(pacman -Qtdq)

就可以删除孤立的软件包。什么是孤立的软件包呢？比如我想要吃西餐，我需要买刀叉。刀叉即西餐的一个依赖，西餐依赖于刀叉。如果我再也不想要吃西餐了，那么已经买来的刀叉也没用了。这个刀叉即孤立的软件包。既然用不上了，那么可以删掉。我大概清理了2-3G。

清理日志

使用如下命令

journalctl --vacuum-size=50M

可以限制日志记录大小在50M，我使用一年没清理过，日志记录大概在2G左右。设置了固定大小为50M后，多的日志就会被删掉。

本文章作者: 杨宇昊

链接: https://qsctech-sange.github.io/arch-linux-clean