小菜鸟

微服务（Microservices）：分布式架构的精细化演进

微服务是近年来软件架构领域的核心概念之一，其本质是将复杂系统拆分为一系列独立、自治的小型服务，通过轻量级通信机制协同工作。它并非凭空出现，而是针对单体架构的局限性逐步演化而来的架构模式。

为什么需要微服务？—— 单体架构的困境

传统单体架构（将所有功能打包为一个应用）在业务规模扩大后逐渐暴露以下问题，成为微服务提出的核心动因：

技术栈受限

单体应用通常绑定单一技术栈（如全 Java 开发），若某模块更适合用其他技术（如数据分析用 Python、高并发场景用 Golang），则难以实现。而微服务允许不同服务选择最适合的技术栈，实现 “技术栈解耦”。

部署成本高

单体应用中，即使仅修改一个小模块（如修复一个订单计算 bug），也需重新打包整个应用并部署，大型应用的部署可能耗时数小时，且风险高（一个模块的问题可能导致整个应用崩溃）。微服务中每个服务独立部署，局部修改仅需部署对应服务，部署效率提升 10 倍以上。

扩展性瓶颈

单体应用的所有模块共享服务器资源（CPU、内存、数据库连接），某一模块的高并发（如商品详情页流量突增）会抢占其他模块资源（如订单系统），导致 “一损俱损”。微服务可针对高负载服务单独扩容（如给商品服务增加服务器），资源利用率更优。

团队协作低效

当团队规模超过 10 人，单体应用的代码冲突、分支管理、测试流程会变得复杂，多人同时开发时需频繁等待他人提交，迭代速度放缓。微服务可按业务拆分给独立团队，实现 “团队自治”。

什么是微服务？—— 核心定义与拆分原则

微服务的概念由马丁・福勒（Martin Fowler）于 2014 年正式提出，其核心特征可概括为：

jenkins构建与部署全流程指南

这篇是我自己搭 Jenkins 的时候一步步截图记下来的，跟着走基本能成

配置jenkins

配置全局工具

装完 Jenkins 第一件事，就是告诉它”你该用哪个 JDK、哪个 Maven”。

在 Jenkins 首页左侧点 Manage Jenkins → Global Tool Configuration。进来之后你会看到 JDK、Git、Maven 这些配置项。我这边项目用的是 Maven，所以主要配了 JDK 和 Maven。你可以根据自己项目的实际情况来，让 Jenkins 自动安装也行，指定本地已有的路径也行。

插件管理

Jenkins 的强大之处在于其丰富的插件生态系统。比如我用 Gitee 做代码托管，就先装 Gitee 插件。

操作路径：

1. 进入 “Manage Jenkins”
2. 选择 “Manage Plugins”
3. 切换到 “Available” 选项卡
4. 在右侧的 Filter 输入框中输入 “Gitee”
5. 勾选搜索结果中的 Gitee 插件并点击 “Install without restart”

系统配置

插件装好了，还得让 Jenkins 能连上你的 Gitee 账号，需要配置 Gitee 连接：

Jenkins LTS 安装教程，面向后端开发者。从 Homebrew 安装、JDK 21 前置检查到首次启动配置，避开 brew install 版本号陷阱和端口冲突。

Spring Boot 单元测试详解：从基础配置到 Web 安全测试实战

单元测试是保障代码质量的关键环节，Spring Boot 基于 Spring 单元测试框架提供了更简洁的测试支持，涵盖普通 Bean 测试、Web 接口测试、安全权限测试等场景。从 “Spring 传统测试 vs Spring Boot 测试→基础测试配置→Web 接口测试（MockMvc）→安全测试（Spring Security）” 四个维度，系统讲解 Spring Boot 单元测试的实现方法与最佳实践。

Spring 传统测试与 Spring Boot 测试的核心差异

在 Spring Boot 出现前，传统 Spring 项目的单元测试需要手动配置上下文、指定配置文件，步骤繁琐；而 Spring Boot 通过 @SpringBootTest 注解简化了配置，实现 “零 XML 配置” 的测试环境搭建。

Spring Boot 基础单元测试：环境搭建与普通 Bean 测试

Spring Boot 基础测试主要用于验证普通 Bean（如配置类、Service 类）的逻辑正确性，核心是通过 @SpringBootTest 自动加载 Spring 上下文，注入待测试 Bean。

引入测试依赖

Spring Boot 提供 spring-boot-starter-test 依赖，包含 JUnit、Spring Test、MockMvc 等核心测试组件，无需单独引入其他依赖：

享元模式（Flyweight Pattern）：通过共享优化大量细粒度对象

享元模式是结构型设计模式的一种，核心思想是通过共享技术有效支持大量细粒度对象，减少内存占用和对象创建开销。它将对象的状态分为 “内部状态”（可共享、不变）和 “外部状态”（不可共享、可变），通过共享内部状态实现对象复用，本质是 “分离与共享”。

享元模式的核心结构

享元模式通过四个角色实现对象的共享与管理，分工明确：

享元接口（Flyweight）

• 定义享元对象的公共接口，声明接收外部状态的方法。
• 示例：Character接口（定义字符的显示方法，接收位置等外部状态）。

具体享元（ConcreteFlyweight）

• 实现享元接口，封装内部状态（可共享的不变数据），并通过接口接收外部状态（可变数据）。
• 示例：ConcreteCharacter（存储字符的字形等内部状态，接收坐标等外部状态）。

非共享享元（UnsharedConcreteFlyweight）

• 不需要共享的享元对象，通常包含无法共享的外部状态，直接实例化无需缓存。
• 示例：SpecialCharacter（特殊符号，使用频率低且状态独特，无需共享）。

享元工厂（FlyweightFactory）

• 负责创建和管理享元对象，维护享元池（缓存已创建的享元），确保相同内部状态的对象只被创建一次。
• 示例：CharacterFactory（缓存字符对象，根据字符值返回共享实例）。

核心概念：内部状态与外部状态

享元模式的关键是对对象状态的拆分：