- 博客(31)
- 收藏
- 关注
RSS订阅原创 十一 论文范文参考
摘要： 本人于2010年7月参加国内某某知名港口供电业务系统的开发工作，在该项目中主要担任系统架构师，主要负责该系统架构和网络安全体系架构设计。经过近20年的港口信息化建设，港口供电系统已经建立了一些应用系统，但是，随着港口供电业务的发展，有些系统已经无法满足目前供电业务需求，同时存在已经开发的系统之间信息共享能力弱，系统集成度较低，系统扩展难的现象。 为了解决供电系统中复杂、分散、异构的数据信息之间交换，实现数据的高可复用性，同时适应新的业务需求，开发新的应用系统以适应日益增长的港口供电线系统信息化需求
2026-01-07 09:02:27
867
原创 十 案例分析
1、性能 指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。如响应时间、吞吐量。设计策略：优先级队列、增加计算资源、减少计算开销、引入并发机制、采用资源调度等。2、可靠性 是软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。如MTTF、MTBF。设计策略：心跳、Ping/Echo、冗余、选举。3、可用性 是系统能够正常运行的时间比例，经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。如故障
2026-01-07 09:00:42
887
原创 九 其他知识补充
包含互联互通、即插即用、边缘网关、数据互操作、协同控制、监视与诊断等功能。对路由器评价的主要性能指标有：设备吞吐量、端口吞吐量、全双工线速转发能力、背靠背帧数、路由表能力、背板能力、丢包率、时延、时延抖动、VPN支持能力、内部时钟精度、队列管理机制、端口硬件队列数、分类业务带宽保证、RSVP、IPDiff Serv、CAR支持、冗余、热插拔组件、路由器冗余协议、网管、基于Web的管理、网管类型、带外网管支持、网管粒度、计费能力/协议、分组语音支持方式、协议支持、语音压缩能力、端口密度、信令支持。
2026-01-06 11:22:25
546
原创 八 系统架构设计
从需求分析到软件设计之间的过渡过程称为软件架构。只要软件架构设计好了，整个软件就不会出现坍塌性的错误，即不会崩溃。架构设计就是需求分配，将满足需求的职责分配到组件上。软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构件的描述、构件的相互作用（连接件）、指导构件集成的模式以及这些模式的约束组成。软件架构不仅指定了系统的组织结构和拓扑结构，并且显示了系统需求和构件之间的对应关系，提供了一些设计决策的基本原理。解决好软件的复用、质量和维护问题，是研究软件架构的根本目的。
2026-01-06 11:22:02
800
原创 七 软件工程
软件开发生命周期软件定义时期：包括可行性研究和详细需求分析过程，任务是确定软件开发工程必须完成的总目标，具体可分成问题定义、可行性研究、需求分析等。软件开发时期：就是软件的设计与实现，可分成概要设计、详细设计、编码、测试等。软件运行和维护：就是把软件产品移交给用户使用。软件系统的文档可以分为用户文档和系统文档两类，用户文档主要描述系统功能和使用方法，并不关系这些功能是怎样实现的；系统文档描述系统设计、实现和测试等各方面的内容。
2026-01-06 11:20:26
792
原创 六 系统安全
所谓信息摘要，就是一段数据的特征信息，当数据发生了改变，信息摘要也会发生改变，发送方会将数据和信息摘要一起传给接收方，接收方会根据接收到的数据重新生成一个信息摘要，若此摘要和接收到的摘要相同，则说明数据正确。信息摘要是由哈希函数生成的。信息摘要的特点：不算数据多长，都会产生固定长度的信息摘要；任何不同的输入数据，都会产生不同的信息摘要；单向性，即只能由数据生成信息摘要，不能由信息摘要还原数据。信息摘要算法：MD5（产生128位的输出）、SHA-1（安全散列算法，产生160位的输出，安全性更高）。
2026-01-06 11:18:39
643
原创 五 计算机网络
纤芯半径较大，因此可以同时传输多种不同的信号，光信号在光纤中以全反射的形式传输，采用发光二极管LED为光源，成本低，但是传输的效率和可靠性都较低，适合于短距离传输，其传输距离与传输速率相关，速率为100Mbps时为2KM，速率为1000Mbps时为550m。：一般公司在申请网络时，会直接获得一个范围很大的网络，如一个B类地址，因为主机数之间相差的太大了，不利于分配，我们一般采用子网划分的方法来划分网络，即自定义网络号位数，就能自定义主机号位数，就能根据主机个数来划分出最适合的方案，不会造成资源的浪费。
2026-01-06 11:17:23
573
原创 四 嵌入式技术
但与计算机处理器不同的是，在实际嵌入式应用中，==只保留和嵌入式应用紧密相关的功能硬件，去除其他的冗余功能部分，这样就以最低的功耗和资源实现嵌入式应用的特殊要求。在嵌入式软件开发中，调试时采用的是在宿主机和目标机之间进行的交叉调试调试器仍然运行在宿主机的通用操作系统之上，但被调试的进程却是运行在基于特定硬件平台的嵌入式操作系统中，调试器和被调试进程通过串口或者网络进行通信，调试器可以控制、访问被调试进程，读取被调试进程的当前状态，并能够改变被调试进程的运行状态。，是追求产品系统最大包容的集成器件。
2026-01-04 09:19:28
779
原创 三 数据库系统
数据：是数据库中存储的基本对象，是描述事物的符号记录。· 数据的种类：文本、图形、图像、音频、视频、学生的档案记录、货物的运输情况等。· 数据库DB：是长期存储在计算机内、有组织的、可共享的大量数据的集合。· 数据库的基本特征：数据按一定的数据模型组织、描述和存储；可为各种用户共享；冗余度较小；数据独立性较高;易扩展· 数据库系统DBS：是一个采用了数据库技术，有组织地、动态地存储大量相关数据，方便多用户访问的计算机系统。
2026-01-04 09:16:53
836
原创 二 操作系统知识
线程基本上不拥有资源，只拥有一点运行中必不可少的资源（如程序计数器、一组寄存器和栈）它可与同属一个进程的其他线程共享进程所拥有的全部资源，例如进程的公共数据、全局变量、代码、文件等资源，但不能共享线程独有的资源，如线程的栈指针等标识数据。· 将进程空间分为一个个段，==每段也有段号和段内地址，==与页式存储不同的是，==每段物理大小不同，分段是根据逻辑整体分段的，==因此，段表也与页表的内容不同，页表中直接是逻辑页号对应物理块号，而下图所示，段表有段长和基址两个属性，才能确定一个逻辑段在物理段中的位置。
2025-12-30 17:40:30
447
原创 一 计算机硬件
Cache有一个命中率的概念，即当CPU所访问的数据在Cache中时，命中，直接从Cache中读取数据，设读取一次Cache时间为1ns，若CPU访问的数据不在Cache中，则需要从内存中读取，设读取一次内存的时间为1000ns，若在CPU多次读取数据过程中，有90%命中Cache，则CPU读取一次的平均时间为(90%*1 +10%*1000)ns。磁头首先要寻找到对应的磁道，然后等待磁盘进行周期旋转，旋转到指定的扇区，才能读取到对应的数据，因此，会产生寻道时间和等待时间。其实质是以时间换取空间。
2025-12-30 17:22:40
678
原创 系统架构设计模块知识点故事集
他解释，软件架构就像建筑的蓝图，是系统的高级抽象，核心是 “需求分配”—— 把业务需求拆解后，分配给不同组件，明确组件职责、交互方式和约束规则。根据架构的物理视图，规划服务器部署方案，比如把核心业务组件部署在高性能服务器，把静态资源部署在边缘节点。将开发好的组件按架构组装，重点解决 “体系结构失配” 问题 —— 比如某个组件的接口格式与架构要求不一致，及时调整适配，确保组件间通信顺畅。最终，基于清晰的架构设计，项目开发效率提升了 40%，后续新增 “财务统计” 功能时，仅用 2 周就完成了集成。
2025-12-26 11:30:49
691
原创 软件工程模块知识点故事集
先明确 “做什么”：通过和客户反复沟通，完成问题定义（解决办公协作低效）、可行性研究（技术、经济、操作都可行）、需求分析（梳理出 “即时沟通”“文件在线编辑”“任务跟踪” 等核心需求），最终产出数据流图、数据字典和需求说明书，相当于给项目画好了 “路线图”。
2025-12-26 11:29:32
582
原创 系统安全模块知识点故事集
核心原理：不管数据大小，都会通过哈希函数生成固定长度的信息摘要。只要数据有任何微小修改，生成的摘要就会完全不同。特点：固定长度：比如 MD5 生成 128 位摘要，SHA-1 生成 160 位摘要，和原始数据大小无关；唯一性：不同数据生成的摘要几乎不可能相同；单向性：只能由数据生成摘要，不能由摘要还原数据。应用场景：平台发送订单数据时，会同时发送数据的信息摘要；接收方收到后，对数据重新生成摘要，和收到的摘要对比，如果一致，说明数据没被篡改；如果不一致，说明数据被修改过，直接拒绝接收。
2025-12-24 16:23:41
575
原创 计算机网络模块知识点故事集
后来公司规模扩大，需要把多个子网合并成一个更大的网络，就用了超网聚合 —— 把网络号拿出几位当主机号，让网络覆盖范围变大，比如把 128.11.1.0-128.11.4.0 四个子网聚合成一个超网，方便管理。比如客户通过浏览器下单，用的是 HTTP 协议（应用层），数据传输用 TCP 协议（传输层），通过 IP 协议（网际层）找到总部服务器，最后通过以太网（网络接口层）传到服务器。路由器的核心是路由表，里面记录了不同网络的 “导航信息”，可以人工静态配置，也能通过动态路由协议自动生成。
2025-12-24 16:22:56
418
原创 嵌入式技术模块知识点故事集
最后，BootLoader 把存储在 Flash 里的操作系统映像和应用程序，复制到内存中，然后跳转到操作系统内核的第一条指令，相当于引导员把控制权交给操作系统，说 “硬件都准备好了，该你工作了”，之后操作系统就开始接管设备，运行各种功能。SOC 是芯片家族的 “终极形态”，追求 “一站式超级集成”，不仅集成了 CPU、MCU、DSP 等核心部件，还直接把操作系统的代码模块、外设驱动甚至应用程序都嵌入芯片内部，相当于一个完整的 “智能设备大脑”，拿到手就能直接驱动设备运行。
2025-12-23 14:43:39
757
原创 数据库系统模块知识点故事集
比如 “订单表”（订单 ID，客户 ID，商品 ID，数量）和 “客户表”（客户 ID，姓名，电话）自然连接，会自动匹配 “客户 ID” 相同的记录，合并后只保留一个 “客户 ID” 列，得到 “包含客户信息的订单表”，不用手动关联，比笛卡尔积高效得多。“智能仓库” 刚设计时，“订单表” 里存了 “客户 ID、客户姓名、商品 ID、商品名称、价格、数量”，导致 “客户姓名”“商品名称” 重复存储（比如一个客户下多个订单，客户姓名存多次），修改时要改所有记录，容易出错。历史订单表存在普通磁盘，节省成本；
2025-12-23 14:42:16
919
原创 操作系统模块知识点故事集
线程比进程 “轻” 多了，它基本不占独立资源，只拿点必备的 “工具”（程序计数器、寄存器、栈），还能和同进程的其他线程共享进程的所有资源（比如共享客户数据、程序代码）。和快表相对的是 “慢表”（存在内存里的完整页表），慢表需要访问两次内存（一次查页表，一次取数据），而快表只需要访问一次快表和一次内存，速度快多了。简单说，进程是 “资源分配的单位”，线程是 “调度的单位”—— 就像一个团队（进程）有多个队员（线程），团队申请资源，队员具体干活，协作更高效。
2025-12-22 15:11:02
902
原创 计算机硬件模块知识点故事集
数据加工厂” 的仓库管理有个聪明策略：把常用材料放 “车间货架”（Cache），较常用的放 “工厂仓库”（内存），不常用的放 “校外大仓库”（硬盘）—— 这就是计算机的分级存储体系，解决了 “快的存储容量小，大的存储速度慢” 的矛盾。这背后靠 “局部性原理”：比如客户连续下单，会反复用同一份客户资料（时间局部性），或者查相邻的库存记录（空间局部性），所以把这些常用数据放近的地方，能减少取货时间。比如客户突然说 “先查库存，再算金额”，厂长就会跳过原来的顺序，直接执行 “查库存” 的指令。
2025-12-22 15:09:45
761
原创 高级系统架构师知识融合故事系列 2：智慧文旅综合服务平台的架构攻坚＜六＞架构评估与持续迭代
①评估准备：确定评估团队（架构师 2 人、业务代表 1 人、运维专家 1 人），收集架构文档（架构设计说明书、服务调用链路图），定义质量属性场景（如 “直播秒杀场景下，商品库存更新响应时间≤500ms”“弹幕数据处理延迟≤5 秒”）；②影响评估：技术团队从 “开发工作量、架构适配性、风险等级” 三个维度评估，例如 “直播带货” 变更评估结果：工作量 = 8 人周，架构适配性 = 中（需新增 2 个服务），风险等级 = 中（直播流处理可能影响现有服务）；
2025-12-19 10:24:41
330
原创 高级系统架构师知识融合故事系列 2：智慧文旅综合服务平台的架构攻坚＜五＞系统安全与云原生部署
①资源配置：为每个 Pod 设置资源请求（requests）和限制（limits），例如预约服务 Pod 设置 requests.cpu=1 核、requests.memory=2Gi，limits.cpu=2 核、limits.memory=4Gi，避免资源抢占；⑤自动化部署：通过 Helm Chart 将镜像部署到 K8s 测试环境，测试通过后，手动点击 “生产部署” 按钮，流水线自动部署到生产环境，并执行冒烟测试；而 CI/CD 流水线需要手动触发测试环境部署，效率低下，难以支撑高频迭代需求。
2025-12-19 10:23:29
829
原创 高级系统架构师知识融合故事系列 2：智慧文旅综合服务平台的架构攻坚＜四＞高并发与性能优化
针对慢查询进行专项优化：①慢查询定位：开启 MySQL 慢查询日志（long_query_time=1 秒），通过 pt-query-digest 分析日志，发现 “SELECT * FROM order WHERE user_id=?” 查询耗时 2.3 秒；：将系统中 “非实时、非核心” 流程全部改为异步：①订单通知：预约成功后，预约服务发送消息到 RabbitMQ “order_notice” 队列（交换机类型 = Direct），通知服务消费消息，异步发送短信、推送 APP 通知；
2025-12-18 10:07:04
750
原创 高级系统架构师知识融合故事系列 2：智慧文旅综合服务平台的架构攻坚＜三＞分布式数据存储与一致性保障
客流监测数据（每 30 秒采集一次，包含景区 ID、实时人数、排队时长等）属于典型时序数据，采用 InfluxDB 存储：①数据模型设计：measurement=tourist_flow，tag=scenic_id（景区 ID），field=people_count（人数）、queue_time（排队时长），timestamp = 采集时间；：针对 “预约购票” 流程，优化事务方案：①第一步：预约服务创建订单（状态 = 待支付），同时写入 “本地消息表”（消息状态 = 待发送）；
2025-12-18 10:05:59
655
原创 高级系统架构师知识融合故事系列 2：智慧文旅综合服务平台的架构攻坚＜二＞微服务架构设计与服务治理
②梳理聚合根（如 “用户”“订单”“商品”）；但架构师助理小林坚持 “按领域模型拆分”，认为应将 “用户认证” 独立为 “身份服务”，“用户信息管理” 归属 “用户中心服务”，理由是未来可能对接第三方认证平台（如微信、支付宝登录）。：Sentinel 配置 “熔断策略 = 慢调用比例”，慢调用阈值 = 500ms，比例阈值 = 0.5，熔断时长 = 5 秒 —— 当库存服务慢调用比例超 50% 时，触发熔断，预约服务立即返回 “当前库存查询繁忙，请稍后再试” 的降级响应；
2025-12-17 09:52:56
273
原创 高级系统架构师知识融合故事系列 2：智慧文旅综合服务平台的架构攻坚＜一＞需求拆解与架构规划
某市文旅集团为破解 “黄金周景区拥堵、游客体验差、管理决策滞后” 等痛点，联合科创公司启动投资 2000 万的 “智慧文旅综合服务平台” 项目。架构师林悦带领 15 人技术团队，需在 6 个月内完成平台开发上线，支撑全市 53 个 A 级景区、218 家星级酒店、36 个文化场馆的数字化运营。项目核心挑战在于：国庆高峰期需承载 120 万用户并发访问，客流预警数据延迟需控制在 5 秒内，同时要满足省文旅厅 “数据同源、业务协同” 的监管要求，还要预留未来 “元宇宙导览”“AI 智能推荐” 等功能的扩展接口。
2025-12-17 09:51:47
900
原创 高级系统架构师知识融合故事系列：水文监测云平台的架构蜕变＜六＞系统上线与持续迭代的闭环
小张清楚，系统上线不是终点，而是 “开发 - 运维 - 优化” 闭环的起点，必须通过标准化流程和持续监控，让架构始终适配业务变化，这也是架构师从 “设计” 到 “落地保障” 的核心能力体现。一次暴雨天，监控系统告警 “某区域采集节点磁盘使用率突增到 90%”，运维人员及时介入，发现是站点批量上报的异常日志导致，清理后系统恢复正常，避免了一次潜在的服务中断。整个需求迭代仅用 2 周就完成上线，既满足了业务需求，又没有引入新的架构复杂度，体现了 “架构适配需求，而非需求迁就架构” 的设计原则。
2025-12-16 09:03:15
900
原创 高级系统架构师知识融合故事系列：水文监测云平台的架构蜕变＜五＞安全防线的全面构筑
系统性能和高可用都达标后，项目进入了安全验收阶段。水务局的网络安全部门突然提出了严格的安全审查要求：“水文监测数据属于城市重要地理信息数据，一旦泄露或被篡改，可能危及城市公共安全，必须建立从访问入口到数据存储的全链路安全防护体系！”更棘手的是，系统需要对接水务局内网、科研院所专线、公众查询终端等多类访问渠道，不同渠道的安全等级差异极大；同时，平台内既有普通监测数据，也有核心沉降预警数据，数据分级保护需求迫切。小张意识到，安全架构是系统上线前的最后一道 “生死关”，必须做到无死角防护。多维度身份认证体系（对应
2025-12-16 09:02:18
892
原创 高级系统架构师知识融合故事系列：水文监测云平台的架构蜕变＜四＞性能瓶颈的攻坚之战
小张笑着说：“性能优化没有银弹，要根据不同瓶颈点选对应的技术，这也是高级架构师考试里的重点，得吃透底层逻辑。针对报表查询的数据库瓶颈，小张提出了 “多级缓存” 的解决方案，他先给团队拆解了缓存的核心知识点：“缓存的本质是用空间换时间，把高频访问的数据存到读写更快的介质中，减少对数据库的直接请求，但要注意缓存一致性和缓存穿透等问题。优化后，数据上传的响应时间从原来的 500ms 缩短至 100ms，即使批量上报 1000 条数据，预警信息也能在 10 秒内完成推送，彻底解决了汛期数据积压的问题。
2025-12-15 11:15:52
838
原创 高级系统架构师知识融合故事系列：水文监测云平台的架构蜕变＜三＞高可用防线的搭建
而这次的云平台不仅要支撑海量数据处理，还要应对各种突发故障，小张意识到，必须搭建一套完整的高可用防护体系，才能守住系统的 “生命线”。模拟机房断电，异地集群 30 分钟内恢复业务；小张特别强调：“灾备方案不是越复杂越好，要兼顾成本和恢复效率，我们的方案是‘同城双活 + 本地多副本’，既满足了水务局的恢复时间要求，又控制了运维成本，符合架构设计的‘成本与效益平衡’原则。小张先从核心服务的部署架构入手，他召集团队开会时提出：“单节点部署的风险太高，所有核心服务都要改成集群模式，实现‘故障无感知’的服务兜底。
2025-12-15 11:15:05
485
原创 高级系统架构师知识融合故事系列：水文监测云平台的架构蜕变＜二＞分布式存储的一致性困局
小周一开始对协议原理很困惑，小张用通俗的语言解释：“Raft 协议就像一个‘投票选举’机制，我们的 3 个存储节点会先选举出一个‘主节点’，所有数据写入请求都先发给主节点，主节点同步数据到其他‘从节点’后，才会返回写入成功的结果；他们还做了一次故障模拟：故意断开主节点的网络，结果从节点在 3 秒内完成了新主选举，且未出现数据丢失，同时故障节点的读服务依然可用，完美契合了 “CP 为主、兼顾可用” 的需求。微服务架构方案敲定后，项目很快进入了核心模块的落地阶段，而第一个 “拦路虎” 就卡在了。
2025-12-14 19:22:41
527
原创 高级系统架构师知识融合故事系列：水文监测云平台的架构蜕变＜一＞项目启动的架构抉择
小张所在的科创公司，此前一直用单体架构开发小型水文监测系统，可这次的新项目需求堪称 “重量级”：要接入全市 120 个监测站点的实时数据（包括水位、水质、沉降量等 6 类指标），支撑水务局、科研院所等 5 类用户的不同查询需求，还要预留未来 3 年的数据扩容和 AI 预警模块的接入空间，同时必须保证系统 7×24 小时不宕机 —— 毕竟地下水数据关系到城市防洪和地质安全，容不得半点差错。微服务架构适合复杂、高并发、需持续迭代的大型系统，这个项目的体量和远期规划，微服务是最优解。（全年宕机时间≤8 小时）、
2025-12-14 19:16:52
496
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人