战国《鹖冠子》有云：“欲知来者察往，欲知古者察今。”

在前两篇架构系列文章中，我们追溯了计算机的起源，梳理了几代计算机的迭代脉络。今天，我们把目光聚焦于软件浪潮中的核心推动者——那些以代码为刃、以热爱为炬的“英雄式”人物。

正是他们的孤勇与专注，在软件蛮荒时代劈开了一条通路，构建起如今数字世界的基石。

戈登·摩尔：摩尔定律终将失效，但创新不会停止……未来需要材料、架构、算法的协同突破。

在前一篇文章中，我们追溯了计算机的起源，见证了数字时代的萌芽。今天，我们将顺着时间线，走进四代计算机的演化历程——从体积庞大的电子管计算机，到如今融入生活的个人电脑，每一次迭代的背后，都是技术与创新的双重突破，更是架构体系不断完善的过程。

达芬奇：“学习如何看。现实中的一切都相互关联”

我们所在的宇宙如何起源？目前科学界最主流的观点是大爆炸宇宙论——一切都源于那一声惊天动地的“嘭”。

而你或许想不到，现代计算机与软件的诞生，也藏着一场大爆炸：从核爆研究中的偶然相遇，到定义行业的经典架构，再到软件开发模式的混沌与觉醒，每一步都环环相扣，最终构筑起如今的数字世界。

1929 年，爱德文·鲍威尔·哈勃（Edwin Powell Hubble，就是冠名哈勃望远镜的那位科学家）总结了红移现象，之后爱因斯坦也来到哈勃工作的威尔逊天文台进行了红移现象的观测。在此基础上，到了 1948 年前后，乔治·伽莫夫（George Gamow）第一个建立了热大爆炸的观念。

二战期间，大名鼎鼎的曼哈顿计划，哈勃并没有直接参与，但他在二战期间为美国海军研究局（ONR）提供咨询，研究雷达技术对天文学观测的干扰问题。在哈勃研究雷达技术时，可能就在他隔壁房间，有一个人正在忙着研究原子弹。

宇宙大爆炸与核爆研究：冯·诺依曼的跨界联结​

关于宇宙起源，1929 年爱德文·鲍威尔·哈勃（没错，就是哈勃望远镜的冠名者）总结了红移现象；之后爱因斯坦也专程前往哈勃工作的威尔逊天文台，亲自观测这一现象。在此基础上，1948 年前后，乔治·伽莫夫首次提出了热大爆炸的核心观念。

而同一时期的二战战场，另一场“爆炸”相关的研究正在秘密进行——曼哈顿计划。哈勃虽未直接参与，但二战期间他为美国海军研究局（ONR）提供咨询，专注于解决雷达技术对天文学观测的干扰问题。有趣的是，或许就在他隔壁的房间，另一位大佬正忙着攻克原子弹的核心难题。

AI 技术的大力发展下，很多支持辅助写作的大模型如雨后春笋般出现。

2024年5月，朋友 @东方赞 得到了一批显卡，搭建了多套大模型，为了解决模型应用问题，他调研了当时比较火的一些应用，并重点使用和分析了 Sider AI 和 ChatBox。

最后得出结论，目前没有一个应用能很好的满足：既能对接大模型，又能自定义模型提示词，还能流程化地解决问题。于是我们展望了一下这个需求，梳理出一个核心特性：让多个 AI 模型群聊，流程化、通力解决问题。

在 Micronaut 项目中，使用了 Logback 输出日志。在添加了RollingFileAppender 后，编译 Native Image 就会报错了。

反复搜索后，发现问题原因是：编译 Native Image 也会使用 logback 进行日志输出，这个时候就会打开日志文件句柄，然后编译器发现有文件句柄被打开了，编译就被中止了。

按 GitHub 上大佬的建议，解决文案是定义一个延迟加载的 FileAppender。

当我们不论使用 Micronaut 框架还是其他框架时，如果项目中使用了 AWT 相应特性（仅特性，非 Swing 应用），比如生成图片，在我们将 Java 应用编译为 Native Image 本地应用后，可能就会报出很多和 AWT 相关的异常，导致生成图片相关功能无法使用。

Quarkus 框架给出了官方的解决方案，直接按官方方案使用插件和制作基础镜像即可。

本文将给出一个 Micornaut 框架的完整的指南和项目示例，说明如何配置可以正确正确编译出支持 AWT 特性的项目。

甲辰龙年基本已经过去，等到正月十年元宵节过后，春节就正式结束了。

在过去的一年里，各行各业都遇到了很多瓶颈。身在软件研发行业中，能感受到更多的飘摇。新的一年，我们要怎么做呢？

本文翻译自 How To Implement Synchronous Interactions Between Microservices，原作者：OLEKSII

本文翻译自 How To Understand Twelve-Factor Methodology In Spring Boot Applications，作者 OLEKSII

本文翻译自 How To Understand Microservices Architecture，作者 OLEKSII

本文翻译自 How To Understand Monolithic Architecture，作者 OLEKSII

Micronaut 的英文名字由两部分拼接而成，“micro” 是“微小”，代表微服务，“naut”是船，代表的是载体。两部分的字面意思合并起来，可以理解为微服务的载体、微服务的运载之船。

上一篇中，我们概览一下 pig 项目的整体结构，并将其运行起来了。本篇我们进一步分析一下各子项目。

客户端、授权器与安全配置​

在之前的示例中，我们直接对接 pac4j，并让项目运行起来了。在 Pac4jConfig 中，我们最先的配置的即是客户端 Client。

        GitHubClient gitHubClient = new GitHubClient("a85f19ea0f51face127a", "84bf0695ea2a62674b8d5961a02a4c793bf23e2a");

        GiteeClient giteeClient = new GiteeClient("da28980047eb2c732b8bcee4be567c6a4f38c6459587063f2607084c9c33b957",
                "4cd81eac1dae28b698044ed5b55e2580da94aca7d872e11e5b47d6c8a3b0a26d");

认证协议概述​

我们常见的认证协议，包括 OAuth、SAML、CAS 和 OpenID Connect 等。在这些协议中，OAuth 协议只定义了基本的协议架构，但没有明确要求 API 如何指定，因而针对不同的协议提供厂商，需要开发不同的客户端进行对接。这些客户端最大的差异在于用户 API 响应的数据定义千差万别，所以自定义客户端最主要的实现是对用户数据的解析。

本篇我们以对接 Gitee 的 OAuth2.0 为例，实现自定义客户端。

对接目标及 pac4j 依赖​

我们以对接 GitHub 进行实战，能从项目指定路径 /login/github 跳转 GitHub 认证后，获取登录用户的相关信息在界面展示，其他 API 配置为不受此认证限定。

一个好的软件，需要一个好的文档，一个好的文档，需要一个好的工具。工欲善其事，必先利其器。

在我们写文档之前，选择一个好的工具，将会使用我们的工作事半工倍。

你的产品有多好并不重要，因为如果它的文档不好，人们就不会使用它。即使他们因为别无选择而不得不使用它，如果没有好的文档，他们也不会有效地使用它或按你希望的方式做。

几乎每个人都明白这一点。几乎每个人都知道他们需要好的文档，大多数人都试图创建好的文档。但大多数人都失败了。

什么是 pac4j​

pac4j 是一个简单而强大的安全框架，用于 Java 验证用户、获取用户配置文件和管理授权，以保护 web 应用程序和 web服务。

它提供了一套全面的概念和组件。它适用于大多数框架/工具，并支持大多数认证和授权机制。它的开源授权协议为 Apache 2。

在上一系列，对 RuoYi（若依）的单体项目比较简单地进行了探秘。虽然 RuoYi 的单体项目有很多不足，但是瑕不掩瑜，RuoYi 还是一个在小项目、验证项目、紧急项目时，可用的基础框架项目。本系列将会品鉴一个更有意思的项目：pig。

在上篇中，我们基本对 RuoYi 最重要的菜单相关进行探究，其他业务的代码不再进行探究。本篇将从第三视角，使用第三方代码扫描工具等，对 RuoYi 项目的代码进行品评。

上篇中，我们对 Shiro 框架做一个简单的扩展了解，稍微了解了一些 Shiro 的概念及运行逻辑，然后我们发现了在用户登录成功后，RuoYi 对用户授予了角色和菜单，这两个数据是如何来的，又是怎么样使用的，本篇将会进行探究。

上篇中，我们初步探究了 RuoYi 项目是如何进行登录信息传输、验证码校验、密码校验，以及密码存储安全性方案。我们了解到，整个的验证实现是围绕 Shiro 框架进行的，而数据的传输安全性，RuoYi 是没有考虑的，如果我们做的是要求安全等级比较高的项目，需要考虑采用 https 协议，并对关键数据进行加密后传输，一般会使用非对称密码算法进行加解密。

本篇，我们主要会针对 Shiro 框架做一个简单的扩展了解，然后再初窥 RuoYi 的菜单、权限功能。

上篇中，我们初步观察了 RuoYi 的项目结构，并在最后实际运行起了项目。我们也发现了作者不好的代码习惯，作为反例，我们应该要养成良好的编码习惯。本篇开始，我们会按照 Web 界面逐一对具体子项目的实现的功能进行探秘。

我们正在探秘各种比较火热的后台管理相关的开源项目，探秘结果将以系列文章的形式分享。希望你能在这些文章中学习别人的优点，也能看到别人的不足，进而可以提升自我的技术能力或技术态度，不论是提升了什么，只要你有收获即可。

“你若不离不弃，我必生死相依”，是一句非常痴情的话，也常被人化用于孩子的名字，寄托父母美好的期望。

今天要探的这个最火后台管理系统 RuoYi（若依），便是作者化用女儿的名字命名的项目。

本文翻译自 Using Redis on Cloud? Here are ten things you should know。

我们很难操作大规模的有状态的分布式系统，Redis 也一样不能例外。托管数据库承担了许多繁重的工作，让我们生活更加轻松。但你仍然需要一个良好的架构，并在服务器（Redis）和客户端（应用程序）上应用最佳实践。

本文涵盖了一系列与 Redis 相关的最佳实践、技巧和窍门，包括集群可伸缩性、客户端配置、集成、指标等。虽然我会不时引用 Amazon MemoryDB 和用于 Redis 的 ElastiCache ，但大多数情况（即使不是全部）都适用于 Redis 集群。

本文翻译自 How To Understand CQRS In Microservices Architecture，作者 OLEKSII。

本文翻译自 How To Understand Event Sourcing In Microservices Architecture，作者 OLEKSII。

在上一篇中，我们总结了与索引属性相关的 API。本篇中，我们将介绍一些特殊的管理 API，包括索引模板 API，对索引的监控和状态管理 API，还有特别的悬空索引。

在上一篇中，我们针对索引 API 相关管理 API 进行了总结，包括常见的 CRUD 及 Elasticsearch 特殊的 API。其中，我们提到，在 Elasticsearch 中，没有直接针对索引本身的“修改” API，而只能修改索引相关的属性。本篇，将介绍与属性相关的 API。

在 Elasticsearch 中，索引可被认作一种文档的优化集合，且每个文档都是字段的集合，字段是包含你数据的键值对。

也就是：索引 → 文档 → 字段 → 数据。

一般，我们如果开发了一个工具组件，肯定想将它发布以供其他人使用。在公司内部，我们可以将其发布到私有仓库，在互联网环境，我们一般将其发布到 maven 中央仓库。以下以我们最近开发的java工具 flyRafter 进行介绍，如何将一个组件发布到 maven 中央仓库。

上一篇中，我们按照官方文档直接体验了对 Elasticsearch 的安装，以及安装成功的校验。本篇我们按照官方对各种平台的安装方式，学习一下Elasticsearch 安装相关的基础信息，如目录结构，常见参数等。

想要尽快的熟悉一样东西的方法，就是去使用它，所以我们需要先把 Elasticsearch 运行起来，这样我们才能去使用它、学习它。

官方文档中介绍，最快的入门 Elasticsearch 的方法是在云中免费试用14天 Elasticsearch 服务。

官方概要介绍如下：

Elasticsearch 是位于 Elastic Stack 中心的分布式搜索和分析引擎。Logstach 和 Beats 促进采集、合计以及充实你的数据并在 Elasticsearch 中存储它们。Kibana 允许你去交互式的探索、可视化和共享对数据的见解，以及监视这个栈（Elastic Stack）。Elasticsearch 是索引、搜索和分析的神奇所在。

多年以后，我上着网还玩着各种电脑游戏时，准会想起哥哥们带我玩采蘑菇的那个遥远的下午。

本文介绍Jekyll代码高亮

GitHub Pages目前使用的Jekyll 3.0，和我们博客相关的特性就有：

• 仅支持kramdown解析Markdown
• 仅支持Rouge作为Markdown代码语法高亮

在之前的文章GitHub Pages系列中，介绍了使用GitHub Pages搭建博客。但实际运行一段时间后发现，文章显示的时间是UTC时间，而不是北京时间。

显示效果如图所示：

本文介绍GitHub API基础及上传文件到仓库API，并应用API将GitHub作为图床

GitHub API官方页面

由于GitHub 的约定，一个账户只能拥有一个GitHub Pages，那么，如果你有多个想部署的静态网站（博客和文档等），它们是互相隔离的，如何用同一个GitHub账户进行部署呢？

从之前如何搭建GitHub Pages的系列文章用GitHub Pages搭建博客（一），我们知道Jekyll或者Hexo实现的静态网站的配置中，常常要指定一个当前网站的目录。

2020年的“双十一”又要来到。很多直男朋友又要陷入被女朋友、被老婆抱怨不懂浪漫的时刻。直男们纷纷感到很委屈：啥是浪漫啊？ 我并不喜欢“直男”这个语汇。因为有“直”必有“弯”，虽然这不可否认，但当直男总被冠上“不懂浪漫”的标签时，不正是想表明“弯男”更懂浪漫么？可女性会和“弯男”在一起吗？答案是显而易见的。

前几日，博客园上出现了一篇文章《国内首个 .NET 5 框架 Fur 斩获 1000 stars，1.0.0-rc.final.20 发布》。此文一出，立即引发了吃瓜程序员的好奇，大家纷纷好奇：国产框架到了一个新的高度了吗？

本篇介绍GitHub Pages的一些杂项

本篇介绍百度统计、百度搜索

一般来讲，部署了一个网站后，我们需要知道网站的浏览量，以便知道网站是否有人访问。

本篇介绍GitHub Pages网站加速

在上一篇提到如何对GitHub Pages配置自定义域名。其实，不论GitHub Pages的默认域名还是自定义域名，都使用了GitHub的CDN进行加速，虽然速度还行，但总还是觉得有点慢。

本篇介绍GitHub Pages自定义域名

在**用GitHub Pages搭建博客（二）**中介绍到，默认的GitHub Pages域名就是仓库地址，即：

账号名.github.io

本篇介绍配置网站参数及发布文章

GitHub Pages一般使用的Jekyll，配置项基本都设置在_config.yml文件中，在此文件中，按参数描述进行配置即可。此处以上一篇使用的Jekyll主题为例进行介绍。

本篇介绍通过git工具替换网站主题，并发布。

本篇介绍基本GitHub Pages的搭建流程

GitHub官网介绍 GitHub Pages

官网是这样介绍的：

Websites for you and your projects.

给你和你的项目的网站。

Hosted directly from your GitHub repository. Just edit, push, and your changes are live.

从你的GitHub仓库中直接托管。只用编辑、发布，你的修改直接生效。

  沈从文先生写了一篇小说《边城》，讲湘西的故事，以兼具抒情诗和小品文的优美笔触，描绘了湘西地区特有的风土人情；借船家少女翠翠的纯爱故事，展现出了人性的善良美好。

  由于“边城”与“编程”的谐音，程序员之间，也会偶尔会调侃一句：沈从文先生可是咱们编程界的祖师爷。