XIAOSUO 记录个人学习的足迹

摘要：一、缓存 基本上来说，在分布式系统中最耗性能的地方就是最后端的数据库了。 一般来说，只要小心维护好，数据库四种操作（select、update、insert 和 delete）中的三个写操作 insert、update 和 delete 不太会出现性能问题（insert 一般不会有性能问题，update 和 delete 一般会有主键，所以也不会太慢）。除非索引建得太多，而数据库里的数据又太多，这三个操作才会变慢。 绝大多数情况下，select 是出现性能问题最大的地方。一方面，select 会有很多像 join、group、order、like 等这样丰富的语义，而这些语义是非常耗性能的；另一方面，大多数应用都是读多写少，所以加剧了慢查询的问题。 分布式系统中远程调用也会消耗很多资源，因为网络开销会导致整体的响应时间下降。为了挽救这样的性能开销，在业务允许的情况下，使用缓存是非常必要的事情。 缓存是提高性能最好的方式，一般来说，缓存有以下三种模式。 1. Cache Aside 更新模式 这是最常用的设计模式了，其具体逻辑如下。 失效：应用程序先从 Cache 取数据，如果没有得到，则从数据库中取数据，成功后，放到缓存中。 命中：应用程序从 Cache 中取数据，取到后返回。 更新：先把数据存到数据库中，成功后，再让缓存失效。 这是标准的设计模式，为什么不是写完数据库后更新缓存？主要是怕两个并发的写操作导致脏数据。 那么，是不是这个 Cache Aside 就不会有并发问题了？不是的。比如，一个是读操作，但是没有命中缓存，就会到数据库中取数据。而此时来了一个写操作，写完数据库后，让缓存失效，然后之前的那个读操作再把老的数据放进去，所以会造成脏数据。 这个案例理论上会出现，但实际上出现的概率可能非常低，因为这个条件需要发生在读缓存时缓存失效，而且有一个并发的写操作。实际上数据库的写操作会比读操作慢得多，而且还要锁表，读操作必须在写操作前进入数据库操作，又要晚于写操作更新缓存，所有这些条件都具备的概率并不大。 当然，最好还是为缓存设置好过期时间。 2. Read/Write Through 更新模式 在 Cache Aside 套路中，应用代码需要维护两个数据存储，一个是缓存，一个是数据库。所以，应用程序比较啰嗦。而 Read/Write Through 套路…… 阅读全文

摘要：一、分布式锁 我们知道，在多线程情况下访问一些共享资源需要加锁，不然就会出现数据被写乱的问题。在分布式系统下，这样的问题也是一样的。只不过，我们需要一个分布式的锁服务。 分布式的锁服务需要有以下几个特点。 安全性（Safety）：在任意时刻，只有一个客户端可以获得锁（排他性）。 避免死锁：客户端最终一定可以获得锁，即使锁住某个资源的客户端在释放锁之前崩溃或者网络不可达。 容错性：只要锁服务集群中的大部分节点存活，Client 就可以进行加锁解锁操作。 1. Redis 的分布式锁服务 我们通过以下命令对资源加锁。 SET resource_name my_random_value NX PX 30000 解释一下： SET NX 命令只会在 key 不存在的时候给 key 赋值，PX 命令通知 Redis 保存这个 key 30000ms。 my_random_value 必须是全局唯一的值。这个随机数在释放锁时保证释放锁操作的安全性。 PX 操作后面的参数代表的是这个 key 的存活时间，称作锁过期时间。 当资源被锁定超过这个时间时，锁将自动释放。 获得锁的客户端如果没有在这个时间窗口内完成操作，就可能会有其他客户端获得锁，引起争用问题。 通过下面的脚本为申请成功的锁解锁： if redis.call(get,KEYS[1]) == ARGV[1] then return redis.call(del,KEYS[1]) else return 0 end 如果 key 对应的 value 一致，则删除这个 key。通过这个方式释放锁是为了避免 Client 释放了其他 Client 申请的锁。 2. 分布式锁服务的一个问题 虽然 Redis 文档里说他们的分布式锁是没有问题的，但其实还是很有问题的。尤其是上面那个为了避免 Client 端把锁占住不释放，然后，Redis 在超时后把其释放掉，这事儿听起来就有点不靠谱。 我们来脑补一下，不难发现下面这个案例。 1. 如果 Client A 先取得了锁。 2. Client B 在等待 Client A 的工作完成。 3. 这个时候，如果 Client A 被挂在了某些事上，比如一个外部的阻塞调用，或是 CPU 被别的进程吃满，或是不巧碰上了 Full GC，导致 Client …… 阅读全文

摘要：对于分布式系统的容错设计，在英文中又叫 Resiliency（弹力）。意思是，系统在不健康、不顺，甚至出错的情况下有能力 hold 得住，挺得住，还有能在这种逆境下力挽狂澜的能力。其中着眼于分布式系统的各种“容忍”能力，包括服务隔离、异步调用、请求幂等性、可伸缩性（有 / 无状态的服务）、一致性（补偿事务、重试）、应对大流量的能力（熔断、降级）。可以看到，在确保系统正确性的前提下，系统的可用性是弹力设计保障的重点。 我们很难计算我们设计的系统有多少的可用性，因为影响一个系统的因素实在是太多了，除了软件设计，还有硬件，还有第三方服务（如电信联通的宽带 SLA），当然包括“建筑施工队的挖掘机”，宕机原因主要有以下这些： 网络问题。网络链接出现问题，网络带宽出现拥塞…… 性能问题。数据库慢 SQL、Java Full GC、硬盘 IO 过大、CPU 飙高、内存不足…… 安全问题。被网络攻击，如 DDoS 等。 运维问题。系统总是在被更新和修改，架构也在不断地被调整，监控问题…… 管理问题。没有梳理出关键服务以及服务的依赖关系，运行信息没有和控制系统同步…… 硬件问题。硬盘损坏、网卡出问题、交换机出问题、机房掉电、挖掘机问题…… 一个分布式系统的故障是非常复杂的，因为故障是分布式的、多米诺骨牌式的。所以，要充分地意识到下面两个事。 故障是正常的，而且是常见的。 故障是不可预测突发的，而且相当难缠。 这就是为什么我们把这个设计叫做弹力（Resiliency）。 一方面，在好的情况下，这个事对于我们的用户和内部运维来说是完全透明的，系统自动修复不需要人的干预。 另一方面，如果修复不了，系统能够做自我保护，而不让事态变糟糕。 一、隔离设计 隔离设计对应的单词是 Bulkheads，中文翻译为隔板，这个概念来自于船舱里防漏水的隔板。我们的软件设计当然也“漏水”，所以为了不让“故障”蔓延开来，需要使用“隔板”技术，来将架构分隔成多个“船舱”来隔离故障。 1. 按服务的种类来做分离 上图中，我们将系统分成了用户、商品、社区三个板块。这三个块分别使用不同的域名、服务器和数据库，做到从接入层到应用层再到数据层三层完全隔离。这样一来，在物理上来说，一个板块的故障就不会影响到另一板块。 上面这种架构虽然在系统隔离上做得比较好，但是也存在以下一些问题。 如果我们需要同时获得多…… 阅读全文

摘要：我们一直在谈论各式各样的架构，如高并发架构、异地多活架构、容器化架构、微服务架构、高可用架构、弹性化架构等。还有和这些架构相关的管理型的技术方法，如 DevOps、应用监控、自动化运维、SOA 服务治理、去 IOE 等。面对这么多纷乱的技术，很多团队或是公司都是一个一个地去做这些技术，非常辛苦，也非常累。 接下来我们来谈一谈分布式架构。 一、概述 1. 分布式的优缺点 首先，为什么需要分布式系统，而不是传统的单体架构。 增大系统容量。我们的业务量越来越大，而要能应对越来越大的业务量，一台机器的性能已经无法满足了，我们需要多台机器才能应对大规模的应用场景。所以，我们需要垂直或是水平拆分业务系统，让其变成一个分布式的架构。 加强系统可用。我们的业务越来越关键，需要提高整个系统架构的可用性，这就意味着架构中不能存在单点故障。这样，整个系统不会因为一台机器出故障而导致整体不可用。所以，需要通过分布式架构来冗余系统以消除单点故障，从而提高系统的可用性。 当然，分布式系统还有一些优势，比如： 因为模块化，所以系统模块重用度更高； 因为软件服务模块被拆分，开发和发布速度可以并行而变得更快； 系统扩展性更高；团队协作流程也会得到改善； …… 不过，这个世界上不存在完美的技术方案，采用任何技术方案都是“按下葫芦浮起瓢”，都是有得有失，都是一种 trade-off。也就是说，分布式系统在解决上述问题的同时，也给我们带来了其他的问题。因此，我们需要清楚地知道分布式系统所带来的问题。 从上面的表格我们可以看到，分布式系统虽然有一些优势，但也存在一些问题。 架构设计变得复杂（尤其是其中的分布式事务）。 部署单个服务会比较快，但是如果一次部署需要多个服务，流程会变得复杂。 系统的吞吐量会变大，但是响应时间会变长。 运维复杂度会因为服务变多而变得很复杂。 架构复杂导致学习曲线变大。 测试和查错的复杂度增大。 技术多元化，这会带来维护和运维的复杂度。 管理分布式系统中的服务和调度变得困难和复杂。 2. 面向服务的架构有以下三个阶段 下面是一个 SOA 架构的演化图。 我们可以看到，面向服务的架构有以下三个阶段。 20 世纪 90 年代前，是单体架构，软件模块高度耦合。当然，这张图同样也说明了有的 SOA 架构其实和单体架构没什么两样，因为都是高度耦合在一起的。就像图中的齿轮一…… 阅读全文

摘要：.Net生态有一个大名鼎鼎中介者模式实现库MediatR，今天介绍一个优雅的装饰器模式实现库DecoratR。 作为软件工程师，我们不断面临在应用程序中实现横切关注点的挑战，例如日志记录、缓存、验证、重试逻辑和安全性。传统方法通常会导致： 重复的样板代码散布在你的服务中。 业务逻辑与基础设施关注点之间紧密耦合。 由于职责混合而导致测试困难。 当需求变更时，可维护性差。 考虑这个典型的服务方法： public async TaskOrder GetOrderAsync(int orderId) { _logger.LogInformation(Getting order {OrderId}, orderId); // 正在获取订单 {OrderId} // 先检查缓存 var cacheKey = $order_{orderId}; if (_cache.TryGetValue(cacheKey, out Order cachedOrder)) { _logger.LogInformation(Order {OrderId} found in cache, orderId); // 订单 {OrderId} 在缓存中找到 return cachedOrder; } try { // 验证输入 if (orderId = 0) thrownew ArgumentException(Invalid order ID); // 无效的订单 ID // 业务逻辑埋没在基础设施代码中 var order = await _repository.GetOrderAsync(orderId); // 缓存结果 _cache.Set(cacheKey, order, TimeSpan.FromMinutes(5)); _logger.LogInformation(Order {OrderId} retrieved successfully, orderId); // 订单 {OrderId} 成功获取 return order;…… 阅读全文

摘要：一、安装Harbor 1. Harbor介绍 Harbor是由VMWare在Docker Registry的基础之上进行了二次封装，加进去了很多额外程序，而且提供了一个非常漂亮的web界面。 Project Harbor是一个开源的受信任的云本地注册表项目，用于存储、标记和扫描上下文。 Harbor扩展了开源Docker发行版，增加了用户通常需要的功能，如安全、身份和管理。 Harbor支持高级特性，如用户管理、访问控制、活动监视和实例之间的复制。 2. 功能 多租户内容签名和验证 安全性与漏洞分析 审计日志记录 身份集成和基于角色的访问控制 实例间的镜像复制 可扩展的API和图形UI 国际化(目前为英文和中文) 3. docker compose Harbor在物理机上部署是非常难的，而为了简化Harbor的应用，Harbor官方直接把Harbor做成了在容器中运行的应用，而且这个容器在Harbor中依赖类似redis、mysql、pgsql等很多存储系统，所以它需要编排很多容器协同起来工作，因此VMWare Harbor在部署和使用时，需要借助于Docker的单机编排工具(Docker compose)来实现。 Compose是一个用于定义和运行多容器Docker应用程序的工具。使用Compose，我们可以使用YAML文件来配置应用程序的服务。然后，只需要一个命令，就可以从配置中创建并启动所有服务。 4. 部署 需要提前安装好docker 提前下载好安装包：Release v2.13.2 · goharbor/harbor · GitHub 安装docker-compose DOCKER_CONFIG=${DOCKER_CONFIG:-$HOME/.docker} mkdir -p $DOCKER_CONFIG/cli-plugins curl -SL https://github.com/docker/compose/releases/download/v2.39.1/docker-compose-linux-x86_64 -o $DOCKER_CONFIG/cli-plugins/docker-compose chmod +x $DOCKER_CONFIG/cli-plugins/docker-compose docker comp…… 阅读全文

摘要：最近公司有个.net项目需要集群部署，由于不打算使用K8S，计划用docker swarm来搭建整个集群环境。 所以计划用2篇文章，记录一下docker swarm部署的整个过程。 文章使用的环境是本地虚拟机环境，生产环境大同小异。 文中用的到资料下载：docker-swarm.zip 一、安装 Docker 对于 Ubuntu/Debian 系统： # 查看 ip ip a 使用工具测试链接，如putty # 1. 更新软件包索引 sudo apt-get update # 2. 安装依赖包 sudo apt-get install ca-certificates curl gnupg lsb-release # 3. 添加 Docker 官方 GPG 密钥 sudo mkdir -p /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg # 4. 设置稳定版仓库 echo deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null # 5. 安装 Docker 引擎 sudo apt-get update sudo apt-get install docker-ce docker-ce-cli containerd.io docker-compose-plugin # 检查 Docker 版本 docker --version 对于 CentOS/RHEL 系统： # 安装依赖包 sudo yum install -y yum-utils device-mapper-persistent-data lvm2 # 添加 Docker 仓库 sudo yum-config-manager --add-r…… 阅读全文

摘要：一、Magentic-One系统解析 1. Magentic-One定位与价值 预构建专家系统：Magentic-One是一个基于AutoGen框架构建的预构建通用任务解决专家系统，具备处理复杂任务的能力。 双重价值：Magentic-One既可以作为强大的工具直接使用，也是学习复杂多智能体设计的最佳实践蓝图，为开发者提供设计参考。 2. 编排者双循环机制 内循环执行与反思：编排者的内循环围绕进度分类账进行任务执行与即时反思，快速迭代以确保任务按计划推进。 外循环规划调整：当内循环陷入停滞时，编排者启动外循环，重新审视任务分类账，调整宏观计划以应对复杂情况。 自适应能力：双循环机制赋予Magentic-One强大的自适应能力，使其能够灵活应对复杂多变的任务环境。 3. 专家角色能力矩阵 WebSurfer：负责网页浏览与交互，能够控制浏览器状态，执行网页导航、交互和内容阅读等操作。 FileSurfer：专注于本地文件系统操作，支持读取多种文件格式、浏览目录结构和文件管理。 Coder：擅长代码编写和数据分析，根据任务需求生成Python脚本等代码，完成数据处理和信息整合。 ComputerTerminal：为Coder提供安全的代码执行环境，确保代码安全运行并处理依赖库安装等。 4. 环境安装与安全守则 安装准备：运行Magentic-One前需安装autogen-ext[magentic-one]、Playwright及Chromium等依赖，确保环境完备。 安全运行建议：建议在Docker容器中运行Magentic-One，以隔离环境风险，保护系统安全。 人工审批机制：引入人工审批机制，对代码执行等关键操作进行审核，防止潜在风险。 pip install autogen-ext[magentic-one] # 时间比较长，耐心等待 playwrithr install --with-deps chromium # PowerShell 下运行 # https://chocolatey.org/install Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Ne…… 阅读全文

摘要：一、框架概览 1. 框架概览 框架背景：AutoGen是由微软推出的开源框架，专为构建基于大型语言模型的复杂应用而设计。它改变了传统AI应用开发的方式，不再依赖单一的‘超级英雄’式智能体，而是通过多个智能体的协作来解决复杂任务。 核心思想：其核心思想是通过智能体间的对话与协作来动态驱动任务的解决。这种模式将任务分解为多个子任务，并分配给不同的智能体，每个智能体专注于特定的角色和任务，从而实现高效的协作。 架构优势：AutoGen框架的出现是对早期单一、巨型智能体设计局限性的一种回应。它通过任务分解和角色专业化，优化了问题解决的效率，提升了系统的灵活性和可扩展性。 2. 与LangChain和SK对比 LangChain与Semantic Kernel：LangChain通过模块化和组件化编排任务逻辑，形成‘链’或‘图’；Semantic Kernel则侧重于将大型语言模型的能力集成到企业级应用中，通过‘内核’与‘插件’动态编排执行计划。 AutoGen的独特性：AutoGen的核心抽象是‘对话’，通过智能体间的协作与对话隐式地驱动任务解决。开发者的工作重心从编排任务逻辑转向设计智能体团队，这种方式更加灵活，能够适应复杂的任务需求。 3. 设计理念深度解析 以对话为中心：AutoGen的设计理念是‘以多智能体对话为中心’，对话不仅是信息交换的形式，更是整个应用框架的计算核心。通过对话结构，开发者可以管理复杂的控制流，包括条件逻辑、循环和错误处理。 动态执行图：对话被抽象为动态的执行图，开发者可以通过设计智能体的角色、目标和沟通规则来间接引导应用程序的行为，这种方式更灵活、更具适应性。 决策与推理的转移：这种设计理念将应用程序的决策和推理部分从代码转移到对话本身，充分发挥了大型语言模型的自然语言理解和生成能力。 灵活性与适应性：开发者通过设计智能体的角色和沟通规则来引导应用程序的行为，这种方式不仅灵活，还能更好地适应不同的任务需求，契合了大型语言模型的特性。 4. 分层架构设计 核心API 功能：核心API是AutoGen框架的基石，提供最基础、最通用的构建模块，关注底层消息传递机制、智能体的生命周期管理以及对本地与分布式运行时的支持。 使用场景：当开发者需要构建全新的智能体交互模式或将其集成到已有的事件驱动系统中时，核心API提供了必要的灵活性和控…… 阅读全文

摘要：一、RAG核心机制与组件 1. SK RAG架构与抽象层 抽象层转变 Semantic Kernel为RAG应用提供了现代化、企业级的抽象层，从单一组件向精细、解耦、类型安全的抽象转变。这种转变使得系统更加健壮、可维护，分离了数据存储、嵌入生成和信息检索的关注点，提升了模块化和可测试性。 数据模型映射 通过定义C#类和添加特性，可以将数据模型映射到向量数据库的模式。例如，使用VectorStoreKey、VectorStoreData等特性，能够简化与数据库的交互，避免编写复杂的数据库迁移代码，提高代码的可维护性和可扩展性。 技术选型灵活性 这种架构设计增强了技术选型的灵活性，允许开发者根据项目需求选择合适的数据库和嵌入模型，同时保持系统的稳定性和可扩展性。 2. RAG完整生命周期 生命周期阶段 RAG应用的核心生命周期包括数据加载与预处理、文本分块、嵌入、索引、检索和增强生成六个阶段。每个阶段都有明确的作用和输入输出，例如数据加载阶段负责读取数据，嵌入阶段将文本转换为向量。 标准性与通用性 与LangChain课程中提到的生命周期相比，SemanticKernel的RAG生命周期更加标准化和通用化，适用于多种数据类型和应用场景，为开发者提供了一套清晰的开发流程。 二、文本预处理与分块 文本分块的重要性 文本分块是RAG流程中的关键步骤，能够将长文本分割成适合嵌入和检索的小块，从而提高检索的准确性和效率。 自定义Token计算器 默认的Token计算器在处理中文分词时存在局限性，通过自定义Token计算器可以解决这一问题，确保分块的准确性。 TextChunker静态类 Semantic Kernel提供了TextChunker静态类，包含按行分割和段落组合等核心方法。通过设置最大Token数量和重叠Token参数，可以灵活地控制分块的粒度。 封装不稳定依赖 为了隔离变更风险，可以创建稳定的ITextSplitter接口和SemanticKernelTextSplitter包装类，封装不稳定的依赖，提高代码的稳定性和可维护性。 public interface ITextSplitter { Liststring Split(string text, int maxTokensPerChunk, int overlapTokens)…… 阅读全文