巴利·玻姆：软件工程的本质，是在不确定性中寻找确定性的艺术。

作为软件工程师的我们，有没有在那一刹那，思考过这个问题：为什么有的项目能按时上线零bug，有的却卡在需求变更里反复返工？

答案，藏在软件研发模型的进化史里。

上一篇我们聊了软件行业的造神者，今天这篇聚焦和瀑布模型强相关的研发模型——从被误读的瀑布模型，到能应对高风险项目的螺旋模型，再到至今仍在悄悄用的RAD模型，每一种模型的诞生，都是程序员和项目失控的博弈史。

开篇暴击：被全行业误读的瀑布模型，诞生初衷竟是“预警缺陷”​

1970年，温斯顿·罗伊斯（Winston Royce）在论文里写下了瀑布模型的核心框架，但他万万没想到：自己写这篇论文的目的，是警告大家这个模型的缺陷（比如线性流程扛不住需求变更），结果却被全行业当成了“研发圣经”。

图：温斯顿·罗伊斯

为啥会被误读？核心是时代刚需：当时的软件项目需求简单，行业急需一套标准化流程规范混乱的开发行为。于是，这个本是“负面案例”的模型被推上神坛，瀑布模型（Waterfall Model）的名字正式敲定——而类似的线性开发实践，其实早已在行业里悄悄用了十几年。

瀑布模型的核心逻辑特别好懂：像瀑布一样单向倾泻，每个阶段彻底完成后才进入下一个，环环相扣不回头。核心阶段就6个：需求分析，设计，开发，测试，部署，维护。完美适配“需求100%明确、几乎不变更”的大型工程。

图：瀑布模型

但说出来你可能不信，它的雏形早在第一代计算机时代就有了。

溯源：比1970年早14年，世界首个大型计算机网络就用了“类瀑布流程”​

瀑布模型不是突然冒出来的，而是从大型项目实践里“长”出来的。

1950年代初到1963年，美国空军搞了个大项目——SAGE半自动地面防空系统，这是世界上第一个大型实时计算机网络。为了保证这个“国之重器”不出错，团队用了一套“先明确需求、再设计、后开发测试”的线性流程，这就是最早的“类瀑布实践”。

图：防空导弹示意图

这里还有个有趣的小插曲：SAGE系统的核心——AN/FSQ-7计算机，是由 IBM 全权负责开发、构建和维护的。

作为20世纪50年代全球最大的计算机项目，SAGE 堪称 IBM 的“成长加速器”：1952年到1955年期间，这个项目为 IBM 贡献了80%的计算机业务收入；到1958年，参与该项目的 IBM 员工更是超过7000人。更关键的是，SAGE项目催生了大量技术创新，而 IBM 后续将这些创新成果广泛融入到其他计算机产品中，进一步巩固了自身在行业内的地位。

更关键的是，1956年6月29日，赫伯特·D·贝内特（Herbert D. Benington）在“数字计算机高级编程方法研讨会”上，专门以 SAGE 系统为例，写了篇《Production of Large Computer Programs》，第一次系统讲了大型软件的阶段化生产流程——这是目前有文献记载的、最早的类瀑布实践，比罗伊斯1970年的论文早了14年。

图：《Production of Large Computer Programs》 截图

后来，这套流程成了“大型关键项目标配”：IBM 704/709大型机的配套软件、NASA水星计划和双子座计划的载人航天软件、UNIVAC 系列商用软件，全用了瀑布模型。

这些项目有个共性：需求由军方或政府拍板，几乎不可能变；团队动辄几百上千人；交付的是不能出半点错的关键系统——这正好是线性流程的“舒适区”。

就连《人月神话》的作者弗雷德·布鲁克斯（Fred Brooks），在领导 IBM System/360 操作系统开发时，也用了需求→设计→实现→测试的线性流程。虽然没叫瀑布模型，但他强调的文档驱动和阶段评审，后来都成了瀑布模型的核心特征。在前文中我们知道 IBM System/360 难产几年才发布的故事，但正是从它开始，软件的研发模型才具象化，也促使了经典著作《人月神话》的诞生。

致命缺陷爆发：瀑布模型的4个“坑”，逼出了后续所有模型创新​

瀑布模型能稳住大型关键项目，但随着软件行业发展，它的缺陷越来越明显，几乎成了“项目翻车重灾区”：

1. 错从源头起，补救全白搭：需求分析阶段的一点偏差，会像滚雪球一样贯穿整个流程，直到交付才发现，这时再改已经来不及了（需求分析的偏差会一直向后续阶段传导）；
2. 变更等于“推倒重来”：开发中途要改需求或设计？成本高到离谱，往往得从头返工（难以适应需求变化）；
3. 用户体验“盲盒”：产品原型要等到开发后期才能看到，中间过程没法验证用户感受，等发现问题已经晚了（等待最终产品周期长）；
4. 文档拖累效率：对文档要求极严，大量时间花在写文档上，反而耽误了开发进度（输出大量文档，增加时间、人力成本）。

为了填这些坑，行业开始了一波又一波的模型创新——第一个站出来的，就是带反馈的瀑布模型。

瀑布模型的初代优化：从单向流转到原型验证​

带反馈的瀑布模型：打破单向却未解决核心问题​

20世纪70年代末，带反馈的瀑布模型（Modified Waterfall Model）出现了。它的改进很直接：在相邻阶段之间加了“双向反馈通道”——比如设计时发现需求有问题，能回退到需求分析阶段改；编码时发现设计有缺陷，能退回设计阶段调整。

这打破了传统瀑布“只能往前走、不能回头”的绝对限制，但核心还是线性推进，文档评审要求也没减。

可惜改进有限：只能相邻阶段回退，如果测试阶段才发现需求层面的大问题，跨阶段回退还是得大量返工；而且“需求前期冻结”的核心问题没解决，还是扛不住需求变更。

就在这时，另一种更灵活的模型站了出来——原型模型（Prototype model）。

1977 年原型模型：用快速原型搞定模糊需求​

1977年，巴利·玻姆（Barry Boehm，后面会多次提到的模型创新大神）系统化提出了原型模型（Prototype model）。苹果 Lisa 系统原型开发、早期交互式桌面应用、CRM系统原型验证，都用了这个模型。

图：巴利·玻姆

它的核心逻辑特别简单：先快速做一个可运行的产品原型，拿给用户看、让用户试，通过反复迭代验证需求。对于需求模糊、需要用户频繁确认的交互式软件，这简直是“救星”。

原型模型又分为抛弃型原型和演化型原型。

前者用于需求验证（比如项目开工前做一个 Demo），后者则将原型逐步迭代演化为最终产品（比如先做了个微信，包含基本聊天功能，再慢慢加上朋友圈等功能）。

原型模型的优点很突出：能快速澄清模糊需求，减少理解偏差；用户全程参与，后期需求变更风险大幅降低；早期就能验证产品方向，避免走弯路。

但它缺点也明显：

1. 容易“重功能轻质量”，为了赶进度可能忽略代码规范和性能问题，导致后期维护困难
2. 如果原型迭代没节制，容易导致项目范围失控，工期延误
3. 不适用于高复杂度、高可靠性要求的核心系统（比如嵌入式软件、航天软件）

瀑布带原型模型：需求阶段前加 “缓冲垫”​

20世纪80年代初，行业又想到了“组合拳”——把原型法和瀑布模型结合，搞出了瀑布带原型模型（Waterfall with Prototype）。

它的改进点很精准：在瀑布模型的需求分析阶段前，加了一个“原型开发环节”。先快速做个低保真或高保真原型，和客户确认清楚需求，再进入后续的线性开发流程。

这个模型早期在银行账务系统、企业库存管理系统等 MIS 项目里用得很多，完美解决了传统瀑布“需求模糊、前期确认不足”的痛点。

但局限性依然存在：如果原型阶段没覆盖所有需求问题，后续开发还是会出现和传统瀑布一样的缺陷。所以随着更优模型出现，它很快就退出了主流。

1980 年关键年：两款核心模型的双生突破​

V 模型：瀑布的 “测试强化版”，成为研发基础范式​

1980年是软件过程模型发展的“关键年”，这一年诞生了两个影响深远的模型，第一个就是V模型（Verification and Validation Model）。

保罗·洛克（Paul Rook）首次提出V模型的核心概念，到1990年代逐步完善成行业标准。它最典型的应用场景，是军工、航空航天等对质量要求极高的嵌入式软件项目——比如美军机载控制系统、欧洲空客航电软件。

图：空客飞机

V模型的核心创新，是把瀑布模型的“线性阶段”改成了“左侧开发+右侧测试”的对称V型结构，核心逻辑就一句话：测试活动和开发活动同步规划、提前介入。

图：V模型

本质上，V模型就是瀑布模型的“测试强化版”，保留了线性推进的核心框架，重点解决了传统瀑布“测试滞后”的问题。

但它还是没跳出线性的桎梏：

1. 需求变更还是要从源头回退，灵活性极差
2. 测试虽然提前规划了，但实际执行还是在编码之后，没做到“边开发边测试”
3. 阶段间依赖太紧，一个阶段延迟，后续所有测试环节都得拖

不过别小看V模型，它虽然不完善，却成了软件研发流程的“基础范式”——核心思想甚至融入了敏捷、DevOps 等现代研发模式，至今还在被广泛应用。

增量模型：分模块交付，突破线性局限​

1980年的第二个关键模型，是巴利·玻姆提出的增量模型。

它的标志性项目包括美国国防部 DARPA 的软件项目（早期人工智能系统、军事指挥系统），后来又广泛用于大型企业级软件、ERP系统（比如SAP早期R/3系统）。

图：DARPA

增量模型的核心逻辑，是把整个软件产品按功能拆成多个“增量模块”，每个模块都走一遍“需求→设计→编码→测试→交付”的迷你瀑布流程。然后按优先级高低，先开发核心模块、先交付，再一步步开发次要模块，最后把所有模块整合起来，形成完整产品。

这个创新直接突破了传统瀑布的线性局限，带来了三个核心优势：

1. 用户能提前用核心功能，降低项目整体风险
2. 需求可以在后续增量模块中逐步细化，能适配部分需求变更
3. 前期模块暴露的问题，能在后续模块中快速修正，减少整体返工成本

当然缺点也很明显：对模块拆分能力要求极高，如果模块间耦合度高，会频繁出现依赖冲突，协调成本飙升；前期必须明确整体架构和功能划分，架构设计错了，所有模块都受影响，后期改起来极难；如果交付节奏没规划好，用户体验会很不连贯。

所以它更适合技术成熟、风险较低的项目。

1986年，螺旋模型：把“风险控制”做到极致的王者​

1986年，巴利·玻姆又在《IEEE Computer》发表论文，正式提出螺旋模型（Spiral Model）——这是一个把“风险控制”放在核心位置的模型。这次，巴利·玻姆成为了螺旋模型之父。

巴利·玻姆还有一个有趣的故事。在 TRW 公司时，玻姆团队为规范软件流程，花一年时间制定了 20 项政策和 300 页标准，核心是推广瀑布模型，还设计了类似驾照考试的 40 道 “软件流程测试题”，员工答对 35 题以上才能参与项目开发。

后来面对用户密集型决策支持系统，瀑布模型弊端凸显，团队想改用原型法却遭抵制。

员工直言 “在关键设计评审前写原型代码，既违规又不道德”。

玻姆最终推动公司转向风险驱动的流程体系，兼顾瀑布的严谨与原型的灵活，这个故事也成了软件工程中 “流程僵化与文化变革” 的经典案例。而这个事件也推动了螺旋模型的最终出世。

螺旋模型的典型应用场景，是大型、高风险、高复杂度的软件项目：比如航天飞机控制系统、核电站监控系统、早期大型操作系统 UNIX 的部分模块。

图：航天飞机

螺旋模型堪称“集大成者”，融合了三个核心优势：瀑布模型的结构化流程、增量模型的迭代交付、原型法的风险预判。

它把软件开发过程抽象成“螺旋式上升的循环”，每个循环都包含4个步骤：制定计划→风险分析→工程实现（迷你瀑布/原型开发）→评审。每一圈循环代表一个增量版本，产品越迭代越完善，最后交付完整版本。

图：螺旋模型

它的核心优点全围绕风险展开：提前识别技术、需求、管理等层面的风险，避免后期爆发造成不可控损失；迭代过程中能灵活调整策略，支持需求大幅变更；结合原型法，降低需求模糊和技术实现的不确定性。

但它的门槛也极高：流程逻辑复杂，对项目管理能力要求苛刻，需要专业的风险分析团队和丰富经验，小型项目用它会成本太高、效率太低；而且循环什么时候终止没有明确标准，如果客户评估维度模糊，很容易导致项目范围无限扩大、工期延误。

快速交付为王：RAD模型，至今仍在悄悄被使用​

在巴利·玻姆推动模型创新的同时，1980年代末到1990年代初，詹姆斯·马丁（James Martin）正式提出并系统化了快速应用开发模型（RAD）。

RAD 的核心目标就是“快速交付可用产品”，典型项目是需要快速上线的企业级应用、Web 应用——比如早期电商网站、CRM 系统。它能落地，全靠可视化开发工具和组件化技术（比如早期的 VB、Delphi 开发工具）。

本质上，RAD 是增量模型、原型法和组件化开发的结合体，核心流程是“需求规划→用户设计（原型迭代）→构造系统（组件化编码/测试）→交付部署”，核心强调四点：用户全程参与、快速原型迭代、组件化复用、自动化工具支持。

它的改进特别贴合“效率需求”：

1. 大幅减少文档工作量，用可运行原型替代书面文档，沟通效率翻倍；
2. 组件化开发+自动化工具（代码生成器、自动化测试工具），大幅提升开发效率，缩短周期；
3. 用户全程参与原型迭代，减少需求理解偏差。

缺点也很突出：过度依赖可视化工具和组件化技术，没有成熟组件可复用的话，效率会大幅下降；对团队协作和技术水平要求高，需要跨职能团队紧密配合；不适用于高复杂度、高定制化项目（比如嵌入式软件、核心算法开发），只适合业务逻辑简单的场景；原型迭代太快，容易导致代码质量差、后期维护难。

但这里有个有趣的点：即使到了2026年，RAD模型依然在被广泛使用，哪怕很多开发者自己都不知道。

比如开发企业内部OA、CRM系统，或者用若依这类框架做定制化项目——本质上就是复用现成组件快速搭建，这就是标准的RAD模型。你以为是自己的“小技巧”，其实30多年前就已经被定义好了。

V模型的升级版：W模型，把“并行测试”做到极致​

20世纪90年代中后期，V模型广泛应用后，测试环节的局限性又凸显出来——虽然规划提前了，但执行还是滞后。为了解决这个问题，W模型（Double V Model）应运而生。

W模型就是“双V拼接”，是行业对V模型的集体优化，主要用在金融、电信等对质量和进度都有严格要求的项目里——比如银行核心交易系统、电信计费系统。

它的核心改进，是把V模型“开发与测试并行”的理念，从“规划层面”延伸到了“执行层面”，形成“开发V型+测试V型”的对称结构，实现“开发阶段与测试阶段全程并行”。

但它还是没跳出线性框架，需求变更的返工成本依然很高；而且全程并行对团队协作要求极高，沟通不畅的话，很容易出现测试和开发脱节，反而增加成本。

不过W模型的“全程并行测试”思想，后来也被敏捷、DevOps吸收，成了研发质量保障的底层方法。现在它虽然不是普通公司的首选，但在高质量管控场景里依然是“标准流程”——比如银行核心交易系统（毕竟“一分钟几百万上下”，容不得半点差错）、华为的基站管理软件，还有那些甲方明确要求“测试必须并行”的高要求项目。

结尾：60年进化史，本质是“对抗不确定性”的历史​

从1950年代的类瀑布实践，到后来的V模型、螺旋模型、RAD模型，这60年的软件研发模型进化史，本质上是一部“对抗不确定性”的历史——对抗需求的不确定、技术的不确定、风险的不确定。

没有完美的模型，只有适合的模型：

● 瀑布模型和V模型适合需求明确的项目 ● 螺旋模型适合高风险、大型项目 ● 增量模型适合技术成熟、低风险项目 ● 原型模型适合需求不明确，客户参与改进的项目 ● RAD模型适合快速交付的组件化项目

这些开发模型，如果你要参加软考之类的考试，一定要以他们的特征来进行记忆。

这些模型的核心思想，早已融入现代研发模式里——哪怕你现在用的是敏捷、DevOps，其实也能看到瀑布、V模型、增量模型的影子。

下一篇，我们将继续深入软件架构系列，聊聊那些从这些基础模型演化而来的现代研发模型，看看它们如何解决新时代的研发难题。

关注底部微信公众号程序员爱读书，带你从源头读懂软件架构的底层逻辑～

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

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

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

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

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

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

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

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

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仓库中直接托管。只用编辑、发布，你的修改直接生效。

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

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