[{"content":"如何搭建个人博客 前置：git,github账号\n工具 1 scoop install hugo-extended 创建github仓库 视频教程：https://www.youtube.com/watch?v=8qDdQQ6Ifxo\n模板仓库：https://github.com/CaiJimmy/hugo-theme-stack-starter\n使用：use this template -\u0026gt; Create a new repository\n创建repo-\u0026gt;my-blog，private\nclone到本地\n1 git clone git@github.com:liangweidonggood/my-blog 使用vscode打开\n仓库配置 申请一个Personal access tokens (classic)\nhttps://github.com/settings/apps\nPersonal access tokens -\u0026gt; Tokens(classic) - \u0026gt; Generate new token(classic)\n权限：repo,workflow\nblog: 你的token\nSecrets and variables -\u0026gt; Actions -\u0026gt; Repository secrets\nkey: PERSONAL_ACCESS_TOKEN,对应deploy.yml中 personal_token: ${{ secrets.PERSONAL_ACCESS_TOKEN }}\n公共仓库：liangweidonggood.github.io\n自动发布 配置.github/workflows\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 name: Build and deploy on: push: branches: - main - master workflow_dispatch: permissions: contents: write # pages: write # id-token: write concurrency: group: pages cancel-in-progress: false defaults: run: shell: bash jobs: build: runs-on: ubuntu-latest env: DART_SASS_VERSION: 1.97.1 GO_VERSION: 1.26.4 HUGO_VERSION: 0.162.1 NODE_VERSION: 24.12.0 TZ: Europe/Oslo steps: - name: Checkout uses: actions/checkout@v6 with: submodules: recursive fetch-depth: 0 - name: Setup Go uses: actions/setup-go@v6 with: go-version: ${{ env.GO_VERSION }} cache: false - name: Setup Node.js uses: actions/setup-node@v6 with: node-version: ${{ env.NODE_VERSION }} #- name: Setup Pages # id: pages # uses: actions/configure-pages@v6 - name: Create directory for user-specific executable files run: | mkdir -p \u0026#34;${HOME}/.local\u0026#34; - name: Install Dart Sass run: | curl -sLJO \u0026#34;https://github.com/sass/dart-sass/releases/download/${DART_SASS_VERSION}/dart-sass-${DART_SASS_VERSION}-linux-x64.tar.gz\u0026#34; tar -C \u0026#34;${HOME}/.local\u0026#34; -xf \u0026#34;dart-sass-${DART_SASS_VERSION}-linux-x64.tar.gz\u0026#34; rm \u0026#34;dart-sass-${DART_SASS_VERSION}-linux-x64.tar.gz\u0026#34; echo \u0026#34;${HOME}/.local/dart-sass\u0026#34; \u0026gt;\u0026gt; \u0026#34;${GITHUB_PATH}\u0026#34; - name: Setup Hugo uses: peaceiris/actions-hugo@v3 with: hugo-version: ${{ env.HUGO_VERSION }} extended: true - name: Verify installations run: | echo \u0026#34;Dart Sass: $(sass --version)\u0026#34; echo \u0026#34;Go: $(go version)\u0026#34; echo \u0026#34;Hugo: $(hugo version)\u0026#34; echo \u0026#34;Node.js: $(node --version)\u0026#34; - name: Install Node.js dependencies run: | [[ -f package-lock.json || -f npm-shrinkwrap.json ]] \u0026amp;\u0026amp; npm ci || true - name: Configure Git run: | git config core.quotepath false - name: Cache restore id: cache-restore uses: actions/cache/restore@v5 with: path: ${{ runner.temp }}/hugo_cache key: hugo-${{ github.run_id }} restore-keys: hugo- - name: Build the site # --baseURL \u0026#34;${{ steps.pages.outputs.base_url }}/\u0026#34; \\ run: | hugo \\ --gc \\ --minify \\ --baseURL \u0026#34;https://liangweidonggood.github.io/\u0026#34; \\ --cacheDir \u0026#34;${{ runner.temp }}/hugo_cache\u0026#34; - name: Cache save id: cache-save uses: actions/cache/save@v5 with: path: ${{ runner.temp }}/hugo_cache key: ${{ steps.cache-restore.outputs.cache-primary-key }} - name: Deploy to Public Pages Repo uses: peaceiris/actions-gh-pages@v4 with: external_repository: liangweidonggood/liangweidonggood.github.io personal_token: ${{ secrets.PERSONAL_ACCESS_TOKEN }} publish_dir: ./public publish_branch: master commit_message: ${{ github.event.head_commit.message }} # - name: Upload artifact # uses: actions/upload-pages-artifact@v5 # with: # path: ./public # # deploy: # environment: # name: github-pages # url: ${{ steps.deployment.outputs.page_url }} # runs-on: ubuntu-latest # needs: build # steps: # - name: Deploy to GitHub Pages # id: deployment # uses: actions/deploy-pages@v5 主仓库提交代码，自动任务触发\n添加评论功能 公共仓库开启Discussions功能，settings-\u0026gt;Features-\u0026gt; 勾选Discussions\nhttps://giscus.app/zh-CN#repository\n使用github登录\n配置\n启用giscus\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 \u0026lt;script src=\u0026#34;https://giscus.app/client.js\u0026#34; data-repo=\u0026#34;liangweidonggood/liangweidonggood.github.io\u0026#34; data-repo-id=\u0026#34;仓库id\u0026#34; data-category=\u0026#34;Announcements\u0026#34; data-category-id=\u0026#34;分类id\u0026#34; data-mapping=\u0026#34;pathname\u0026#34; data-strict=\u0026#34;0\u0026#34; data-reactions-enabled=\u0026#34;1\u0026#34; data-emit-metadata=\u0026#34;0\u0026#34; data-input-position=\u0026#34;bottom\u0026#34; data-theme=\u0026#34;preferred_color_scheme\u0026#34; data-lang=\u0026#34;zh-CN\u0026#34; crossorigin=\u0026#34;anonymous\u0026#34; async\u0026gt; \u0026lt;/script\u0026gt; config/_default/params.toml中配置\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 [comments] enabled = true provider = \u0026#34;giscus\u0026#34; [comments.giscus] # ============================================ # 必填项 - 从 https://giscus.app/zh-CN 生成后填入 # ============================================ repo = \u0026#34;你的公开仓库\u0026#34; # 公开的部署仓库（giscus 需要公开仓库） repoID = \u0026#34;你的ID\u0026#34; # 仓库的 GitHub ID（base64 格式） category = \u0026#34;Announcements\u0026#34; # Discussions 分类名 categoryID = \u0026#34;你的ID\u0026#34; # 分类的 GitHub ID # ============================================ # 可选项 - 从 giscus.app 同步过来 # ============================================ mapping = \u0026#34;pathname\u0026#34; # pathname / url / title / og:title strict = \u0026#34;0\u0026#34; # 严格匹配 mapping reactionsEnabled = \u0026#34;1\u0026#34; # 显示表情反应按钮 emitMetadata = \u0026#34;0\u0026#34; # 是否向父页面发送元数据 inputPosition = \u0026#34;bottom\u0026#34; # 评论输入框位置：top / bottom theme = \u0026#34;preferred_color_scheme\u0026#34; # 跟随系统明暗 lang = \u0026#34;zh-CN\u0026#34; # 语言 lazyLoadingEnabled = \u0026#34;1\u0026#34; # 懒加载 ","date":"2015-03-06T00:00:00Z","image":"/p/build-blog/image/cover.jpg","permalink":"/p/build-blog/","title":"如何搭建个人博客"},{"content":"2026 年 6 月 3 日。打开 GitHub Trending 周榜，会发现一件很显眼的事情：前 21 个 Trending 项目里，至少有 15 个与 AI Agent 相关，占比超过 70%。从 Claude Code 插件、Cursor 插件，到各种\u0026quot;harness\u0026quot;和\u0026quot;agent team\u0026quot;项目，再到 AI 记忆引擎、token 压缩工具——开源社区几乎在用整个版面向一个方向投票：大模型的下半场，是 Agent 的工程化。\n一、本周整体观察 维度 数据 Trending 项目总数 21 与 AI Agent 直接相关 15+（≈71%） 周增 stars Top 3 数量级 10,000+ 微软 / Anthropic / Cursor 项目数 6 中文 / 亚太项目数 3 周增 stars Top 3 都是万级，这在 Trending 历史上是相当罕见的\u0026quot;含金量\u0026quot;——说明这一周 Trending 的项目本身在大众开发者圈里也产生了强烈共鸣。\n二、Top 21 完整榜单 # 仓库 描述 语言 周增 总数 1 harry0703/MoneyPrinterTurbo 利用 AI 大模型，一键生成高清短视频 Python 18,982 78,585 2 microsoft/markitdown 文件与 Office 文档转 Markdown 工具 Python 15,502 142,336 3 chopratejas/headroom 在数据送达 LLM 之前先压缩工具输出/日志/文件/RAG 切片 Python 3,002 8,514 4 Lum1104/Understand-Anything Graphs that teach \u0026gt; graphs that impress TypeScript 15,774 50,825 5 hardikpandya/stop-slop 移除 AI 文本痕迹的 skill 文件 — 3,470 8,435 6 Leonxlnx/taste-skill 给你的 AI 注入\u0026quot;好品味\u0026quot;的 skill Shell 10,931 32,236 7 revfactory/harness 设计领域专用 agent 团队的 meta-skill HTML 1,870 5,625 8 rohitg00/ai-engineering-from-scratch Learn it. Build it. Ship it for others. Python 7,183 27,713 9 colbymchenry/codegraph 为 Claude Code 预索引的代码知识图谱 TypeScript 10,793 38,948 10 mukul975/Anthropic-Cybersecurity-Skills 754 个结构化的 AI Agent 网络安全 skills Python 3,755 13,781 11 affaan-m/ECC Agent Harness 性能优化系统 JavaScript 9,910 205,037 12 cursor/plugins Cursor 插件规范与官方插件 TypeScript 842 1,763 13 EveryInc/compound-engineering-plugin Claude Code 官方复合工程插件 TypeScript 2,143 19,519 14 anthropics/knowledge-work-plugins Claude Cowork 开源插件集 Python 2,458 18,971 15 microsoft/agent-governance-toolkit AI Agent 治理工具包：策略执行、审计 Python 1,391 3,876 16 p-e-w/heretic 语言模型审查机制全自动移除 Python 1,634 23,373 17 Chachamaru127/claude-code-harness Claude Code 专用开发 harness Shell 879 2,580 18 ogulcancelik/herdr 住在你终端里的 agent multiplexer Rust 1,327 3,997 19 supermemoryai/supermemory AI 时代的 Memory API TypeScript 1,733 24,971 20 iii-hq/iii Effortlessly compose, extend, observe every service Rust 1,321 17,590 21 modelscope/FunASR 工业级语音识别工具包（170x realtime） Python 544 17,025 三、重点项目解读 🥇 1. harry0703/MoneyPrinterTurbo（+18,982 stars） 利用 AI 大模型，一键生成高清短视频。\n本周榜单的\u0026quot;超级爆款\u0026quot;。在中文圈尤其火爆——它把过去\u0026quot;写脚本 → 配音 → 找素材 → 剪辑\u0026quot;的繁琐短视频生产链路，整合成一次\u0026quot;输入主题 + 几个参数\u0026quot;的命令式调用：\n自动生成视频文案 调用 TTS 合成语音 抓取匹配素材并剪辑 输出成片 在自媒体、视频带货、短视频矩阵流行的当下，\u0026ldquo;一键生成\u0026quot;对中小创作者极具吸引力。这也是榜单上唯一同时具备强娱乐属性和强 AI 属性的项目，能跨圈层传播。\n🥈 2. microsoft/markitdown（+15,502 stars） Python tool for converting files and office documents to Markdown.\n微软官方出品，把 PDF、Word、Excel、PPT、图片、音频、HTML 等多种格式统一转成 Markdown——这个看似朴素的工具之所以爆火，是因为它精准切中了 LLM 时代的数据预处理痛点：\nRAG 系统要喂 Markdown，不要 Word 样式 Agent 工作流需要结构化文本，不要二进制 LLM Token 预算有限，能少一个空格就少一个 这是一个典型的\u0026rdquo;大模型时代的水电煤\u0026quot;——平时感觉不到，停了就难受。\n🛠 3. chopratejas/headroom（+3,002 stars） Compress tool outputs, logs, files, and RAG chunks before they reach the LLM.\n如果说 markitdown 解决了\u0026quot;喂什么\u0026quot;，headroom 解决的就是\u0026quot;喂多少\u0026quot;——它是一个 LLM 输入压缩器。Agent 调用 shell、读日志、查文档时，常常会被铺天盖地的输出淹死，headroom 在 LLM 见到这些数据之前先做剪枝、摘要、特征提取，把 token 成本压下来。\n解决\u0026quot;agent context window 被吃光\u0026quot;的问题 解决\u0026quot;明明问题很简单，账单却很大\u0026quot;的问题 对生产级 agent 几乎是必备 它出现在 Trending 榜上，强烈暗示：工程化落地正在倒逼 token 经济学。\n🧠 19. supermemoryai/supermemory（+1,733 stars） Memory engine and app\u0026hellip; The Memory API for the AI era.\n如果说 LLM 解决了\u0026quot;思考\u0026quot;，supermemory 想解决的就是\u0026quot;记忆\u0026quot;。它提供了一个跨会话、跨应用、跨模型的 Memory API——你可以把它理解成 AI 时代的\u0026quot;个人信息中台\u0026quot;：\n持久化用户偏好、历史对话、知识片段 提供标准 API 供任何 Agent 调用 自带\u0026quot;什么值得记、什么可以忘\u0026quot;的判断逻辑 它的爆火折射出一个真实需求：一次性 prompt 不够，Agent 需要长期记忆。\n🇨🇳 21. modelscope/FunASR（+544 stars） Industrial-grade speech recognition toolkit: 170x realtime\u0026hellip;\n阿里达摩院 ModelScope 团队出品，工业级开源语音识别工具包。周增 544、总数 17,025 这个量级在中文开源语音项目里已经是头部水准。170x realtime 意味着 1 小时的音频，最快 21 秒就能转完文字，对字幕生成、会议记录、客服质检、视频本地化等场景都极具落地价值。\n🧩 Cursor / Claude Code 插件生态（组合解读） cursor/plugins、compound-engineering-plugin、knowledge-work-plugins、claude-code-harness……\n这一组项目放在一起看，信号非常明确：AI 编码工具的战争已经从\u0026quot;模型强不强\u0026quot;转入\u0026quot;插件生态厚不厚\u0026quot;。\nCursor 抢开源插件（cursor/plugins） Anthropic 抢工作流插件（knowledge-work-plugins） EveryInc 抢 Claude Code 复合工程（compound-engineering-plugin） 个人开发者抢 Harness 编排（claude-code-harness） 四股力量在同一周内同时 Trending，几乎是历史上第一次。插件 = 生态 = 锁定 = 商业化护城河，这个飞轮已经被大家看到了。\n四、主题分布分析 把 21 个项目按主题归类：\n主题 项目数 代表项目 AI Agent 编排 / Harness 8 headroom, taste-skill, harness, codegraph, ECC, herdr, iii, claude-code-harness Claude Code / Cursor 插件 4 cursor/plugins, compound-engineering-plugin, knowledge-work-plugins, claude-code-harness AI 工具与基础能力 4 MoneyPrinterTurbo, markitdown, Understand-Anything, supermemory AI 安全与治理 2 agent-governance-toolkit, Anthropic-Cybersecurity-Skills AI 对齐 / 去 AI 味 2 stop-slop, heretic 传统优秀开源 1 FunASR 五、趋势洞察 1. \u0026ldquo;Agent Skills\u0026rdquo; 正在变成一种新的开源品类 你可能注意到了：taste-skill、stop-slop、Anthropic-Cybersecurity-Skills、compound-engineering-plugin、knowledge-work-plugins……这一波项目的命名里都带着 \u0026ldquo;skill\u0026rdquo;。\n\u0026ldquo;Skill\u0026rdquo; 这个词在 2025 年初还只在小圈子里流通，到 2026 年中已经变成了**\u0026ldquo;Agent 可调用的最小能力单元\u0026rdquo;**的标准说法。一个 skill 文件 ≈ 一段 prompt + 几段元数据 + 几行工具声明。开源社区正在围绕 \u0026ldquo;skill\u0026rdquo; 沉淀一套可分享、可复用的中间层。\n2. Harness 是新的中间件 如果说\u0026quot;Skill\u0026quot;是 Agent 的\u0026quot;积木\u0026quot;，那 Harness 就是\u0026quot;插积木的底板\u0026quot;——它负责：\n调度 skill 之间的执行顺序 管理 context、memory、工具调用 处理错误、超时、并行 chopratejas/headroom、affaan-m/ECC、revfactory/harness、Chachamaru127/claude-code-harness、iii-hq/iii……本周前 21 名里，harness 类的项目占了 5 个，与 CLI 工具当年（ripgrep、fd、bat）的爆发节奏非常像。\n3. Token 经济学开始成为大众议题 markitdown 告诉你\u0026quot;喂什么\u0026quot;，headroom 告诉你\u0026quot;喂多少\u0026quot;，两者同时登顶不是巧合——开发者第一次集体意识到：大模型的\u0026quot;输入侧\u0026quot;和\u0026quot;输出侧\u0026quot;一样重要，甚至更重要。当 agent 自己造 token、自己花 token，账单从月结变成日结时，\u0026ldquo;Token 经济学\u0026quot;就不再是性能优化，而是生死问题。\n六、总结 本周 GitHub Trending 用一张榜单讲了三件事：\n大模型的下半场属于 Agent 工程师——harness、skill、plugin 正在变成新的\u0026quot;操作系统\u0026rdquo; 中文开源已经站上 Trending 主舞台——MoneyPrinterTurbo、Understand-Anything、FunASR 三箭齐发 生产级落地比 Demo 重要——token 压缩、记忆引擎、治理工具同时登顶，说明社区在从\u0026quot;能不能跑\u0026quot;走向\u0026quot;跑得久、跑得省、跑得安全\u0026quot; 引用格式：GitHub Trending Weekly - 2026-06-03\n数据来源：github.com/trending?since=weekly\n参考资料 GitHub Trending 本周榜 harry0703/MoneyPrinterTurbo microsoft/markitdown chopratejas/headroom supermemoryai/supermemory modelscope/FunASR anthropics/knowledge-work-plugins cursor/plugins ","date":"2026-06-03T00:00:00Z","image":"/p/github-trending-2026-06-03/image/cover.jpg","permalink":"/p/github-trending-2026-06-03/","title":"GitHub本周趋势观察：AI Agent 生态大爆发"},{"content":"2026年6月2日，微软正式发布了 Microsoft Coreutils for Windows 的首个正式版本 v2026.5.29，标志着这家操作系统巨头第一次以官方身份，把经过 Rust 重写的 UNIX 核心工具集原生地带到了 Windows 平台。对于长期在 Windows、Linux、macOS、WSL 与容器之间来回切换的开发者而言，这是一件期盼已久的事情。\n一、项目背景：跨平台开发者之痛 长期以来，Windows 与 UNIX 生态之间存在一道隐形的\u0026quot;工具鸿沟\u0026quot;：\n大量 CI 脚本、运维脚本、构建脚本默认依赖 ls、cat、cp、rm、grep、find 这类 GNU 工具； 开发者要么借助 WSL，要么依赖 Git for Windows、MSYS2、Cygwin 这类第三方移植，要么就只能把脚本\u0026quot;翻译\u0026quot;成 PowerShell —— 维护成本都不低； 即使引入了第三方 GNU 工具，命令参数、行为细节也常常与 Linux 上的对应工具存在微妙差异。 微软 Coreutils for Windows 正是为了解决这个痛点：让 Linux、macOS、WSL、容器与 Windows 上的同一段命令、同一套参数、同一种管道组合，能够开箱即用地工作。\n二、项目简介 Microsoft Coreutils for Windows 是微软在 GitHub 上以 microsoft/coreutils 名义维护的开源项目。它并不是从零写起，而是站在开源社区的肩膀上：\n组件 上游项目 说明 核心工具集 uutils/coreutils GNU coreutils 的 Rust 重写版 查找工具 uutils/findutils GNU findutils 的 Rust 重写版 文本搜索 uutils/grep 新编写的 Rust 实现 这三套工具被打包成单一的多调用二进制文件，配合 DOS 时代 find 与 sort 的兼容垫片、以及一个支持跨平台 glob 模式的 PowerShell 包装器，组成完整的 Coreutils for Windows 套件。\n项目当前仍处于 preview（预览） 状态，仅在 2026 年 6 月 2 日发布了首个正式 Release。\n三、技术亮点 从仓库的语言占比即可看出项目的技术组成：\n语言 占比 用途 Rust 39.1% 核心二进制实现，继承自 uutils 上游 PowerShell 35.1% 构建脚本、CI/CD、辅助脚本 Inno Setup 25.8% Windows 安装包打包 几个值得关注的点：\nRust 实现：在内存安全和性能上比传统 C 实现更有优势，也与微软近年来在 Rust 方向上的投入一脉相承。 与上游同步：仓库 CONTRIBUTING.md 明确说明，代码变更会在本仓库与上游 uutils 项目之间流转——既享受了社区成果，也承担了同步责任。 MIT 许可：完全宽松的许可证，便于企业与个人在商业场景下使用。 多调用二进制：以单一可执行文件承载上百个命令，部署与分发都更轻量。 四、安装与运行要求 最便捷的安装方式是通过 Windows 包管理器 WinGet 一键安装：\n1 winget install Microsoft.Coreutils 也可以从 Release 页面 下载预编译二进制手动部署。\n运行要求：\n强制要求 PowerShell 7.4 或更高版本，旧版 PowerShell 不受支持； CMD 可以使用，但部分功能受限； 推荐 Windows 11，理论上也支持 Windows 10。 五、命令支持矩阵 Coreutils for Windows 并未\u0026quot;一股脑\u0026quot;把 GNU coreutils 的所有命令都搬过来，而是经过精心设计以避免破坏 Windows 现有生态。下面是核心命令的支持情况：\n命令 CMD PowerShell 7.4+ 备注 cat ✅ ⚠️ — cp ✅ ⚠️ — date ⚠️ ⚠️ — find ✅ ✅ 集成自原 DOS 命令 hostname ✅ ✅ Windows 内置的超集 kill 🛑 🛑 Windows 缺乏信号支持 ls ✅ ⚠️ — mkdir ⚠️ ⚠️ — mv ✅ ⚠️ — pwd ✅ ⚠️ — rm ✅ ⚠️ — rmdir ⚠️ ⚠️ — sleep ✅ ⚠️ — sort ✅ ✅ 集成自原 DOS 命令 tee ✅ ⚠️ — timeout 🛑 🛑 依赖 kill 功能 uptime ✅ ⚠️ — dir、more、whoami 等 🛑 🛑 与内置 DOS 命令严重冲突 图例：✅ 已发布且可用 · ⚠️ 已发布但与内置命令冲突 · 🛑 未发布\n故意未包含的命令 以下命令虽然在上游 uutils 中存在，但因依赖 POSIX 独有概念、可能破坏现有 Windows 脚本或在 Windows 上无实用价值而被移除：\n可能在未来加入：dd Windows 上无意义：dircolors、shred、sync、uname 仅限 POSIX 概念：chcon、chgrp、chmod、chown、chroot、groups、hostid、id、install、logname、mkfifo、mknod、nice、nohup、pathchk、pinky、runcon、stdbuf、stty、tty、users、who 也就是说，如果你习惯了在 Linux 上 chmod 755 script.sh，那么在 Windows 的 Coreutils 套件里依然要使用 Windows 原生的 ACL 机制。\n六、Windows 平台差异处理 Coreutils for Windows 的文档详细列出了 Windows 与 UNIX 之间的关键差异，以及在 Windows 上的应对策略：\n差异点 说明 CRLF 行尾符 Windows 文本文件常用 \\r\\n，多数工具透明处理，但正则 $ 匹配与精确字节计数会受影响 无 /dev/null 使用 NUL 替代，例如 find . -name \u0026quot;*.log\u0026quot; \u0026gt; NUL 无 POSIX 信号 SIGHUP、SIGPIPE、SIGUSR 不可用，但 Ctrl+C（SIGINT）工作正常 路径分隔符 / 和 \\ 都接受，但部分工具输出仍使用 \\ 分隔 文件权限 Windows 使用 ACL 而非 POSIX 权限位，find -perm 等谓词可能行为不同或不可用 符号链接 读取已存在符号链接无需提权；创建新链接需要开发者模式或提权终端 这一节尤其值得开发者留意——\u0026gt; 之后不要写 /dev/null，而要写 NUL，这能省去很多踩坑时间。\n七、当前状态与社区反响 截至本文撰写时（2026 年 6 月 3 日）：\n首个正式版本：v2026.5.29，发布于 2026 年 6 月 2 日 GitHub Stars：约 1.6k Forks：21 许可证：MIT Issues / PRs：16 个开放 Issue，9 个开放 PR 社区对此次发布的反应以正面为主——在 release 页面中可以看到\u0026quot;🎉 庆祝\u0026quot;、\u0026quot;🚀 火箭\u0026quot;、\u0026quot;❤️ 红心\u0026quot;等表情反应相当密集。\n八、为什么这件事值得开发者关注 微软 Coreutils for Windows 的发布，表面上是\u0026quot;多了几个命令\u0026quot;，实质上意义远不止于此：\n官方背书：这是微软首次以官方仓库身份维护 UNIX 工具集，长期支持与生态整合都有保障。 脚本可移植性大幅提升：今后编写跨平台脚本时，\u0026ldquo;先在 Linux 上跑通，再到 Windows 上跑\u0026quot;的工作流会顺畅很多。 Rust 在系统编程领域的又一次胜利：核心系统工具的 Rust 重写趋势，从 ripgrep、fd、bat 一直延续到如今的 uutils 系列，生态越来越完善。 降低 WSL 依赖：对于一些原本\u0026quot;为了一两条命令就要切到 WSL\u0026quot;的工作场景，如今可以直接在 PowerShell 中完成。 九、总结 Microsoft Coreutils for Windows 是微软在 2026 年交出的一份诚意之作：它把经过开源社区验证的 uutils 系列工具，以官方身份整合到 Windows 平台，并细致地处理了与 Windows 现有命令的冲突问题。虽然目前仍处于 preview 状态、首个版本号 v2026.5.29 距离发布也才一天，但凭借微软的维护力度与 uutils 上游的成熟度，这个项目值得每一个跨平台开发者去尝试。\n立即尝试：\n1 winget install Microsoft.Coreutils 然后打开 PowerShell 7.4+，敲下 ls、cat、rm，感受一下\u0026quot;在 Windows 上像在 Linux 一样工作\u0026quot;的丝滑吧。\n参考资料 microsoft/coreutils GitHub 仓库 Release v2026.5.29 uutils/coreutils uutils/findutils uutils/grep ","date":"2026-06-03T00:00:00Z","permalink":"/p/wei-ruan-kai-yuan-coreutils-windows/","title":"微软开源Coreutils for Windows：Rust重写的UNIX工具集正式登陆"},{"content":"Nginx 是一款高性能的 HTTP 和反向代理服务器，几乎是后端架构的标配。本文记录常用的反向代理配置。\n最简单的反向代理 将所有请求转发到后端应用服务器：\n1 2 3 4 5 6 7 8 9 10 11 server { listen 80; server_name example.com; location / { proxy_pass http://127.0.0.1:3000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } } 关键指令说明：\nproxy_pass：后端地址 proxy_set_header Host：传递原始域名 X-Real-IP / X-Forwarded-For：让后端拿到真实客户端 IP 负载均衡 用 upstream 块定义后端池：\n1 2 3 4 5 6 7 8 9 10 11 12 13 upstream backend { least_conn; server 10.0.0.1:3000 weight=3; server 10.0.0.2:3000 weight=2; server 10.0.0.3:3000; } server { listen 80; location / { proxy_pass http://backend; } } 常用策略：\n默认轮询：请求依次分配 weight=：权重越大分到的越多 least_conn：连接数最少的优先 ip_hash：同一客户端固定到同一后端 WebSocket 代理 Nginx 默认不支持 WebSocket 转发，需要显式声明 Upgrade 头：\n1 2 3 4 5 6 location /ws { proxy_pass http://backend; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection \u0026#34;upgrade\u0026#34;; } HTTPS 终结 让 Nginx 处理 HTTPS，后端走明文 HTTP（仅内网用）：\n1 2 3 4 5 6 7 8 9 server { listen 443 ssl; ssl_certificate /etc/nginx/ssl/cert.pem; ssl_certificate_key /etc/nginx/ssl/key.pem; location / { proxy_pass http://127.0.0.1:3000; } } 小结 Nginx 的反向代理功能强大，配置简洁，是后端架构中不可或缺的组件。掌握 proxy_pass、upstream、WebSocket Upgrade 头这三个核心点，基本能覆盖 80% 的日常场景。\n","date":"2024-01-15T10:00:00+08:00","permalink":"/p/nginx-config/","title":"Nginx 反向代理配置详解"},{"content":"01-计算机系统基础（基于第1小时） 软考-系统架构设计师 | 第1篇 架构设计基础 出题形式：单项选择题 | 分值占比：2-6 分 教材参考：第1章 计算机系统基础知识\n0. 考点分析 本章为架构设计的\u0026quot;地基\u0026quot;内容，核心考点聚焦在以下 6 个方面：\n冯·诺依曼结构与哈佛结构（DSP/处理器分类） 指令集分类（CISC vs RISC，国产处理器架构） 存储层次与存取速度（片上/片外缓存 → 主存 → 外存） 总线分类（并行/串行、内/系统/外总线；并行总线表必背） 操作系统分类与特征（批处理/分时/实时/网络/分布式/嵌入式） UML 四大关系与五种视图（依赖/关联/泛化/实现；用例图三类关系） 1. 核心知识点 1.1 计算机系统组成 硬件子系统：机械、电子元器件、磁介质和光介质等物理实体 软件子系统：按特定顺序组织的数据和指令，控制硬件完成指定功能 软件分类：系统软件（通用、不依赖特定应用）+ 应用软件（面向特定领域） 1.2 冯·诺依曼结构 5 大部件：运算器、控制器、存储器、输入设备、输出设备 现代硬件中\u0026quot;控制器 + 运算器\u0026quot;被集成为 CPU 哈佛结构：将程序和数据存储器分开，使用两组独立总线，可同时访问，取指和执行完全重叠。DSP 采用哈佛结构 1.3 专用处理器 类型 全称 特点 应用场景 GPU Graphics Processing Unit 数百到数千个内核，并行计算 图形渲染、AI 深度学习 DSP Digital Signal Processor 哈佛结构，单周期 MAC 指令 实时数字信号处理 FPGA Field Programmable Gate Array 现场可编程逻辑门阵列 硬件原型、定制加速 1.4 指令集系统 CISC（复杂指令集）：以 Intel、AMD 的 x86 为代表 RISC（精简指令集）：以 ARM、Power 为代表 国产处理器：龙芯、飞腾、申威，常采用 RISC-V、MIPS、ARM 架构 1.5 存储层次（速度由快到慢） 1 2 寄存器组 → Cache（片上/片外）→ 主存（内存）→ 外存（Disk） 容量反向递增：速度越快，容量越小 SRAM（静态）：晶体管自锁，速度快、不需刷新、容量小 → 用作 Cache DRAM（动态）：电容存储，集成度高、需刷新 → 用作主存 NVRAM/Flash/EPROM/Disk：非易失性存储 1.6 总线 按位置划分：内总线 / 系统总线 / 外部总线 并行总线 vs 串行总线（必背表 1.1）： 名称 数据线 特点 应用 并行总线 多条双向数据线 有传输延迟，适合近距离连接 系统总线（计算机各部件） 串行总线 一条双向或两条单向 速率不高，适合长距离连接 通信总线（计算机之间/与其他系统） 1.7 典型接口与外部设备 接口：HDMI、SATA、RS-232（输入输出）；RJ45、FC（网络）；A/D 转换（非标准） 外部设备：键盘、鼠标、显示器（通过接口与主机连接） 1.8 操作系统 特征：并发性、共享性、虚拟性、不确定性\n6 种操作系统分类：\n类型 关键特征 备注 批处理 单道/多道批处理 作业 = 程序 + 数据 + 作业说明书 分时 多路性、独立性、交互性、及时性 CPU 时间片轮流服务 实时 足够快速度处理 + 高可靠性 不强制用户交互 网络 硬件独立性 + 多用户支持 共享网络资源 分布式 透明性、可靠性、高性能 网络 OS 的更高级形式 嵌入式 微型化、可定制、可靠性、易移植性 采用 HAL + BSP 常见嵌入式 RTOS：VxWorks、μClinux、PalmOS、WindowsCE、μC/OS-II、eCos\n1.9 数据库 分类：关系型 / 键值（Key-Value） / 列存储 / 文档数据库 分布式数据库系统（DDBS） 4 大特性：分布性、逻辑相关性、场地透明性、场地自治性（满足四性 = 完全分布式） 数据特征：集中控制性、数据独立性、数据冗余可控性、场地自治性、存取有效性 1.10 文件系统 文件分类（按性质）：系统文件、库文件、用户文件 文件分类（按保护）：只读、读/写、可执行、不保护 文件分类（按期限）：临时文件、档案文件、永久文件 UNIX 文件：普通文件、目录文件、设备文件 存取方法：顺序存取、随机存取 组织方法：连续结构、链接结构、索引结构、多重索引 存储空间管理：磁盘分配表（空闲区表、位示图、空闲块链） 1.11 中间件（Middleware） 应用软件与操作系统之间的标准化编程接口和协议，8 大类：\n通信处理（消息）中间件 —— MQSeries 事务处理（交易）中间件 —— Tuxedo 数据存取管理中间件 Web 服务器中间件 —— Tomcat、JBOSS 安全中间件 跨平台和架构的中间件 专用平台中间件 网络中间件（网管、接入工具） 1.12 软件构件 两大特性：自包容 + 可重用（搭积木式开发） 优点：易扩展、可重用、并行开发 缺点：需要经验丰富的设计师；快速开发与质量属性妥协；构件质量影响整体 商用构件标准： CORBA（OMG）：ORB + 公共对象服务 + 公共设施；用 IDL 定义接口 J2EE（SUN）：EJB 是构件标准；Bean 分会话 Bean、实体 Bean、消息驱动 Bean DNA 2000（Microsoft）：DCOM/COM/COM+ 1.13 计算机语言 类型 说明 机器语言 第一代，\u0026ldquo;本地语\u0026rdquo;；指令 = 操作码 + 操作数 汇编语言 机器语言符号化；语句 = 名字 + 操作符 + 操作数 + 注释；伪指令如 DB/DW/DD/SEGMENT/PROC 高级语言 C/C++/Java/Python 建模语言 UML（3 要素：基本构造块、图、公用机制） 形式化方法 Z 语言（\u0026ldquo;状态-操作\u0026quot;风格，集合论+数理逻辑） 1.14 UML 核心（高频考点） 4 种事物：\n结构事物：类、接口、协作、用例、主动类、构件、制品、节点 行为事物：交互、状态机、活动 分组事物：包 注释事物：注解 4 种关系：\n关系 含义 关键词 依赖 一个事物变化影响另一个 \u0026ldquo;使用\u0026rdquo; 关联 拥有的结构关系；特例：聚合、组合 \u0026ldquo;拥有\u0026rdquo; 泛化 特殊/一般；子可替代父 \u0026ldquo;is-a\u0026rdquo; 实现 接口与实现类/构件之间；用例与协作之间 \u0026ldquo;实现\u0026rdquo; 聚合 vs 组合：\n聚合：部分可属于多个整体；生命周期不同 组合：部分只能属于一个整体；生命周期相同 14 种图（UML 2.0）：类图、对象图、用例图、序列图、通信图、状态图、活动图、构件图、部署图、制品图、组合结构图、包图、交互概览图、计时图\n5 种视图：用例视图、逻辑视图、进程视图、实现视图、部署视图（用例视图居中心）\n用例图三类关系（必考）：\n关系 触发条件 例子 包含（include） 多个用例共用相同动作 \u0026ldquo;课程学习\u0026rdquo; → \u0026ldquo;检查权限\u0026rdquo; 扩展（extend） 基用例有多种分支场景 \u0026ldquo;课程学习\u0026rdquo; → \u0026ldquo;缴纳学费\u0026rdquo; 泛化 多个用例共性抽象为父用例 \u0026ldquo;课程注册\u0026rdquo; → \u0026ldquo;网络注册\u0026rdquo; 1.15 多媒体技术 4 大特征：多维化、集成性、交互性、实时性 关键技术：视音频技术、通信技术、数据压缩技术、VR/AR 技术 VR/AR 4 种形式：桌面式、分布式、沉浸式、增强式 2. 关键概念速查 概念 定义/说明 常见考点 冯·诺依曼结构 5 部件：运算器、控制器、存储器、输入、输出 与哈佛结构对比 哈佛结构 程序/数据分开，两组独立总线 DSP 采用 CISC / RISC 复杂/精简指令集 x86 vs ARM、国产处理器 DMA / Cache / MMU 直接存取/高速缓存/内存管理 处理器体系结构图 寄存器组 CPU 内速度最快的存储部件 速度排序题 位示图 用一位 0/1 表示一个区块状态 文件存储空间管理 HAL 硬件抽象层 嵌入式 BSP 板级支持包 嵌入式 包含关系 多个用例共用相同动作 用例图 扩展关系 基用例的多种分支 用例图 泛化关系 子用例继承父用例 用例图 CORBA OMG 的构件标准，ORB+服务+设施 商用构件 EJB J2EE 构件标准 商用构件 Z 语言 形式化语言，强类型 形式化方法 3. 典型例题 从源文本\u0026quot;练习题\u0026quot;中精选 3 道最具代表性题目\n例题 1：DSP 处理器结构 题目：目前处理器市场中存在 CPU 和 DSP 两种类型的处理器，分别用于不同的场景，这两种处理器具有不同的体系结构，DSP 采用（ ）。 A．冯·诺依曼结构 B．哈佛结构 C．FPGA 结构 D．与 GPU 相同的结构\n答案：B\n解析：DSP 芯片为达到快速进行数字信号处理的目的，一般采用哈佛结构。哈佛结构将存储器空间划分成两个，分别存储程序和数据，并有两组总线连接到处理器核，可同时访问，得以实现单周期的 MAC 指令。\n例题 2：实时信号处理 题目：（ ）是专用于实时的数字信号处理的处理器。 A．DSP B．CPU C．GPU D．FPGA\n答案：A\n解析：DSP 专用于实时的数字信号处理，常采用哈佛体系结构；CPU 是通用处理器；GPU 偏重并行图形计算；FPGA 是可编程逻辑门阵列。\n例题 3：UML 用例图关系 题目：在线学习系统中，课程学习和课程考试都需要先检查学员的权限，\u0026ldquo;课程学习\u0026quot;与\u0026quot;检查权限\u0026quot;两个用例之间属于 （1） ；课程学习过程中，如果所缴纳学费不够，就需要补缴学费，\u0026ldquo;课程学习\u0026quot;与\u0026quot;缴纳学费\u0026quot;两个用例之间属于 （2） ；课程学习前需要课程注册，可以采用电话注册或网络注册，\u0026ldquo;课程注册\u0026quot;与\u0026quot;网络注册\u0026quot;两个用例之间属于 （3） 。 （1）A．包含关系 B．扩展关系 C．泛化关系 D．关联关系 （2）A．包含关系 B．扩展关系 C．泛化关系 D．关联关系 （3）A．包含关系 B．扩展关系 C．泛化关系 D．关联关系\n答案：A B C\n解析：\n包含关系：多个用例共用相同动作（\u0026ldquo;课程学习\u0026quot;必须\u0026quot;检查权限\u0026rdquo;） 扩展关系：基用例的多种分支（\u0026ldquo;缴纳学费\u0026quot;是\u0026quot;课程学习\u0026quot;的可选分支） 泛化关系：子类继承父类共性（\u0026ldquo;电话注册\u0026quot;\u0026ldquo;网络注册\u0026quot;都是\u0026quot;课程注册\u0026quot;的子用例） 4. 高频考点 本章最常考的内容集中在 4 个方向：\n计算机组成原理：冯·诺依曼 5 部件、DSP 哈佛结构、CISC vs RISC、存储层次速度排序（寄存器组 \u0026gt; Cache \u0026gt; 内存 \u0026gt; Flash/Disk）、并行/串行总线区别 操作系统分类：6 种 OS 类型及其特征（尤其实时系统、嵌入式系统的高可靠性/可裁剪性）；嵌入式 RTOS 常见名称（VxWorks、μC/OS-II 等） UML 三要素与四种关系：依赖/关联/泛化/实现 含义区分；用例图三类关系（include/extend/泛化）几乎年年必考 中间件与软件构件：8 类中间件 + 3 大商用构件标准（CORBA/J2EE/DNA 2000），区分 EJB 中的会话/实体/消息驱动 Bean ","date":"2024-01-01T00:00:00Z","permalink":"/p/01-ji-suan-ji-xi-tong-ji-chu/","title":"01-计算机系统基础"},{"content":"02-嵌入式系统基础（基于第2小时） 软考-系统架构设计师 | 第1篇 架构设计基础 出题形式：单项选择题 | 分值占比：1-3 分 教材参考：第2章 嵌入式基础知识\n0. 考点分析 本章是软考中的\u0026quot;偏门\u0026quot;考点，案例分析题不强制，但选择题必出。核心考点：\n嵌入式系统特点（专用性强、软硬一体、资源受限、实时性、安全性高） 嵌入式系统分类（实时/非实时、强/弱实时、安全攸关/非安全攸关） 嵌入式软件 5 层架构（硬件层 → 抽象层 → OS 层 → 中间件层 → 应用层） 嵌入式微处理器 5 大类（MPU/MCU/DSP/GPU/SoC） 存储器分类（RAM/ROM 各种子类特性对比） 看门狗电路与软件低功耗设计 1. 核心知识点 1.1 嵌入式系统定义 嵌入式系统（Embedded System）= 以特定应用为中心 + 以计算机技术为基础 + 软硬件可配置可裁剪的专用计算机系统\n组成结构（5 部分）：\n嵌入式处理器 相关支撑硬件（存储器、定时器、总线等） 嵌入式操作系统 支撑软件（公共服务，库的形式） 应用软件 1.2 嵌入式处理器温度等级 档次 温度范围 用途 民用级 0 ~ 70℃ 普通消费电子 工业级 -40 ~ 85℃ 工控设备 军用级 -55 ~ 150℃ 航天、武器 1.3 嵌入式系统 8 大特点 专用性强，配备多种传感器 技术融合（计算机 + 通信 + 半导体 + 电子 + 行业应用紧密结合） 软硬一体，软件为主 资源受限（低功耗、体积小、集成度高） 程序代码固化在 ROM 中（提高执行速度 + 可靠性） 需专门开发工具和环境（宿主机 + 目标机） 体积小、价格低、工艺先进、性能价格比高 对安全性和可靠性要求高 1.4 嵌入式系统分类 按用途：嵌入式实时系统 / 嵌入式非实时系统 实时细分：强实时（Hard Real-Time） / 弱实时（Weak Real-Time） 按安全性：安全攸关（Safety-Critical） / 非安全攸关 实时系统（RTS）：能够在规定的时间内完成系统功能和做出响应的系统 安全攸关系统：不正确的功能或失效会导致人员伤亡、财产损失等严重后果\n1.5 嵌入式系统典型架构 嵌入式系统最大特点：系统的运行和开发是在不同环境中进行的\n目标机（运行环境） vs 宿主机（开发环境） 连接方式：串口、网络或 JTAG 接口 由于指令集不同，需要 交叉平台开发环境 基本工具：交叉编译器、交叉链接器、源代码调试器 1.6 嵌入式系统 5 层架构 1 2 3 4 5 6 7 8 9 10 11 ┌─────────────────────────────┐ │ 5. 应用层 │ ├─────────────────────────────┤ │ 4. 中间件层（DB/VM/MQ 等） │ ├─────────────────────────────┤ │ 3. 操作系统层（OS/FS/GUI） │ ├─────────────────────────────┤ │ 2. 抽象层（HAL + BSP） │ ├─────────────────────────────┤ │ 1. 硬件层（CPU/Mem/Bus/IO） │ └─────────────────────────────┘ 抽象层关键：\nHAL（Hardware Abstraction Layer）：为上层 OS 提供虚拟硬件资源 BSP（Board Support Package）：硬件驱动软件，为 OS 提供硬件管理支持 中间件层常见：嵌入式数据库、OpenGL、消息中间件、Java 中间件、虚拟机（VM）、DDS/CORBA、Hadoop\n1.7 嵌入式软件 6 大特点与设计方法 特点 设计方法 可剪裁性 静态编译、动态库、控制函数流程 可配置性 数据驱动、静态编译、配置表 强实时性 表驱动、配置、静/动态结合、汇编语言 安全性（Safety） 编码标准、安全保障机制、FMECA 可靠性 容错技术、余度技术、鲁棒性设计 高确定性 静态分配资源、越界检查、状态机、静态任务调度 1.8 嵌入式微处理器 5 大类 类型 全称 关键特点 典型系列 MPU Microprocessor Unit 微处理器+专门电路板；集成度低、可靠性高 Am186/88、386EX、SC-400、PowerPC、68000、MIPS、ARM MCU Microcontroller Unit（单片机） 核心存储器+部分外设封装在片内；体积小、功耗低、成本低 8051、MCS-96/196/296、C166/167、MC68HC05/11/12/16、ARM 系列 DSP Digital Signal Processing 哈佛结构，指令特殊设计；大量数据处理 TMS320（C2000/C5000/C6000/C8000）、DSP56000 GPU Graphics Processing Unit 浮点运算 + 多核并行 AI 深度学习数据运算 SoC System on Chip 多个 IC 组合在单芯片上；含完整硬件 + 嵌入式软件 嵌入式 IP 核 + OS + 用户软件 1.9 存储器分类 RAM（Random Access Memory）：工作需要持续电力\nDRAM（动态）：电容存储信息 优点：集成度高、容量大、成本低 缺点：访问速度较慢、需要定期刷新 常作主存 SRAM（静态）：多个晶体管自锁保存状态 优点：访问速度快、不需要刷新 缺点：集成度低、容量小、成本高 常用作高速缓存 ROM（Read Only Memory）：数据不会因掉电丢失；读取速度比 RAM 快\n类型 写入方式 优点 缺点 MROM 掩膜大批量制造 成本低 数据全一致、不可修改 PROM 专用设备一次性烧录 适合少量制造 一次性 EPROM 紫外线擦除重写 可多次写入 擦除操作复杂 EEPROM 电压擦除 联机擦写 擦除速度很慢 Flash 联机快速擦写 擦写次数多、速度快 读取速度相对较慢 1.10 总线分类 按信息种类分：\n数据总线：传送需要处理或存储的数据 地址总线：指定 RAM 中存储数据的地址 控制总线：将控制单元的信号传送到周边设备 按连接部件分：\n片内总线：连接芯片内部各元件 系统总线（板级总线）：连接计算机系统的核心组件 局部总线：连接局部少数组件 通信总线：主机连接外设的总线 按传输方向分：\n单工总线：只能单向传输 双工总线 = 半双工（轮流向两方向）+ 全双工（同时双向） 按信号类型分：\n并行总线：多位传输线，同时传多位数据，一致性要求高，距离近 串行总线：一位传输线，同时传一位数据，距离远 1.11 看门狗电路（Watchdog） 嵌入式系统必须具备的系统恢复能力，防止程序出错或死锁。\n构成：输入端 + 寄存器 + 计数器 + 狗叫模块\n工作原理：\n通过寄存器对看门狗基本设置 计数器计算\u0026quot;狗叫时间\u0026quot; 程序正常运行时 MCU 在输入端定期\u0026quot;喂狗\u0026quot; 超时不喂 → 触发狗叫模块 → 一般是重启 MCU 1.12 软件低功耗设计 主要技术：编译优化 + 软硬件协同设计 + 算法优化\n其他措施：\n减少系统的持续运行时间（从算法角度优化） 用\u0026quot;中断\u0026quot;代替\u0026quot;查询\u0026quot; 进行电源的有效管理 1.13 安全攸关软件与 DO-178B 标准 IEEE 定义：安全攸关软件是\u0026quot;用于一个系统中，可能导致不可接受的风险的软件\u0026quot; DO-178B 目的：为机载系统和设备的机载软件提供指导，满足适航要求 生命周期： 软件计划过程 软件开发过程（细分为 4 子过程：需求、设计、编码、集成） 软件综合过程（细分为 4 子过程：验证、配置管理、质量保证、审定联络） 5 个安全等级（A 最高 → E 最低）： 等级 含义 A 灾难级（Catastrophic） B 危害级（Hazardous） C 严重级（Major） D 不严重级（Minor） E 没有影响级（No Effect） 2. 关键概念速查 概念 定义/说明 常见考点 嵌入式系统 特定应用 + 计算机技术 + 软硬件可裁剪的专用系统 定义 宿主机/目标机 开发环境 / 运行环境 交叉开发 HAL 硬件抽象层 5 层架构 BSP 板级支持包 5 层架构 MPU 微处理器 5 大处理器 MCU 微控制器（单片机） 5 大处理器 DSP 数字信号处理器（哈佛结构） 5 大处理器 SoC 片上系统 5 大处理器 SRAM vs DRAM 速度与刷新 存储分类 看门狗 防死锁，超时复位 MCU 系统恢复 DO-178B 机载软件适航标准 5 级安全等级 强/弱实时 响应时间要求 嵌入式分类 3. 典型例题 从源文本\u0026quot;练习题\u0026quot;中精选 3 道最具代表性题目\n例题 1：存储速度排序 题目：在嵌入式系统的存储部件中，存取速度最快的是（ ）。 A．内存 B．寄存器组 C．Flash D．Cache\n答案：B\n解析：存储速度从快到慢分别是：寄存器组 → Cache → 内存 → Flash。寄存器组在 CPU 内部，Cache 次之，主存（内存）更慢，Flash 等外存最慢。\n例题 2：硬件抽象层 HAL 题目：以下关于嵌入式系统硬件抽象层的叙述，错误的是（ ）。 A．硬件抽象层与硬件密切相关，可对操作系统隐藏硬件的多样性 B．硬件抽象层将操作系统与硬件平台隔开 C．硬件抽象层使软硬件的设计与调试可以并行 D．硬件抽象层应包括设备驱动程序和任务调度\n答案：D\n解析：硬件抽象层（HAL）位于操作系统内核与硬件电路之间，目的是将硬件抽象化，隐藏特定平台的硬件接口细节。任务调度属于操作系统的功能，不属于 HAL 范围。设备驱动通常由 BSP 提供。\n例题 3：嵌入式 OS 特点辨析 题目：以下描述中，（ ）不是嵌入式操作系统的特点。 A．面向应用，可以进行裁剪和移植 B．用于特定领域，不需要支持多任务 C．可靠性高，无须人工干预独立运行，并处理各类事件和故障 D．要求编码体积小，能够在嵌入式系统的有效存储空间内运行\n答案：B\n解析：嵌入式 OS 必须支持多任务调度和同步机制（这是 OS 最基本功能）。\u0026ldquo;不需要支持多任务\u0026quot;明显错误。嵌入式 OS 的其他特性：可裁剪/可移植、强实时性、硬件适用性、高可靠性、编码体积小。\n例题 4：软件低功耗设计 题目：嵌入式系统设计一般要考虑低功耗，软件设计也要考虑低功耗设计，软件低功耗设计一般采用（ ）。 A．结构优化、编译优化和代码优化 B．软硬件协同设计、开发过程优化和环境设计优化 C．轻量级操作系统、算法优化和仿真实验 D．编译优化技术、软硬件协同设计和算法优化\n答案：D\n解析：软件层面低功耗设计三板斧：编译优化（低功耗编译技术） + 软硬件协同设计 + 算法优化。补充手段：用中断代替查询、电源管理。\n例题 5：嵌入式开发环境 题目：以下关于嵌入式系统开发的叙述，正确的是（ ）。 A．宿主机与目标机之间只需要建立逻辑连接 B．宿主机与目标机之间只能采用串口通信方式 C．在宿主机上必须采用交叉编译器来生成目标机的可执行代码 D．调试器与被调试程序必须安装在同一台机器上\n答案：C\n解析：嵌入式开发中由于目标机处理器能力和存储空间不足，程序在 PC（宿主机）开发，再下载到目标机运行。当宿主机与目标机指令不同时，需要交叉工具链（交叉编译器、链接器等）。宿主机和目标机之间可通过串口、网络或 JTAG 连接，不只串口；调试器可远程调试。\n4. 高频考点 本章最常考的内容集中在 5 个方向：\n嵌入式 5 层架构：硬件层 → HAL/BSP → OS 层 → 中间件层 → 应用层；尤其要区分 HAL（虚拟硬件资源）和 BSP（硬件驱动）的职责 5 大嵌入式微处理器：MPU / MCU / DSP / GPU / SoC 的定位与典型代表（DSP 哈佛结构是必考点） 存储器分类：SRAM vs DRAM 特性对比；ROM 五种类型（MROM/PROM/EPROM/EEPROM/Flash）的擦写方式 总线 4 种分类：按信息种类（数据/地址/控制）、按连接部件（片内/系统/局部/通信）、按方向（单工/半双工/全双工）、按信号（并行/串行） 嵌入式 OS 特点辨析：必考\u0026quot;哪些不是嵌入式 OS 特点\u0026quot;的反选题——多任务调度是嵌入式 OS 的基本功能（不能说不支持）；软件低功耗设计的三板斧（编译优化+软硬件协同+算法优化） ","date":"2024-01-01T00:00:00Z","permalink":"/p/02-qian-ru-shi-xi-tong-ji-chu/","title":"02-嵌入式系统基础"},{"content":"03-计算机网络基础（基于第3小时） 软考-系统架构设计师 | 第1篇 架构设计基础 出题形式：单项选择题 | 分值占比：2-4 分 教材参考：第3章 计算机网络基础知识\n0. 考点分析 本章虽然内容广，但作为系统架构设计师考试中的\u0026quot;次要\u0026quot;科目，重点集中在 5 个方向：\n网络性能指标（速率、带宽、吞吐量、时延） 局域网/以太网/WLAN/WAN/MAN 特性（尤其以太网最小帧长 64 字节、最大 1518 字节） 网络设备与工作层级对应（Hub/中继器→物理层；网桥/交换机→数据链路层；路由器/防火墙→网络层） OSI/RM 七层模型与 TCP/IP 协议族（TCP vs UDP；FTP/HTTP/HTTPS/DNS 端口号；IPv6 过渡技术） 网络冗余设计与分层设计（接入层/汇聚层/核心层；备用路径 vs 负载分担） 1. 核心知识点 1.1 网络性能指标 性能指标：速率、带宽、吞吐量、时延 非性能指标：费用、质量、标准化、可靠性、可扩展性、可升级性、易管理性、可维护性\n1.2 通信技术 技术 说明 类比 复用技术 一条信道同时传多路数据（TDM 时分、FDM 频分、CDM 码分） 一条路上多辆货车 多址技术 一条线上同时传多个用户数据（TDMA、FDMA、CDMA） 一辆车的货物分给不同用户 5G 通信 高速率、低时延、接入用户数高 新一代移动通信 信道分类：逻辑信道（虚拟线路，可有连接/无连接）+ 物理信道\n信号过程：信号变换 → 编码 → 交织 → 调制 → 信道 → 解调 → 解码 → 信号变换\n1.3 网络分类与拓扑 局域网（LAN）：在有限地理范围内互联的封闭型计算机网络\n5 种局域网拓扑结构：\n1 总线型 星型 树型 环型 网状 1.4 关键网络技术 以太网（Ethernet）：\nIEEE 802.3 定义 最小帧长：64 字节（最大帧长：1518 字节） 设置最小帧长是为了避免冲突 最小帧长 = 根据网络中检测冲突的最长时间来定 无线局域网（WLAN）：\nIEEE 802.11 标准（a/b/g/n/ac） 802.11n：200 Mb/s 802.11ac：1 Gb/s 3 种拓扑：点对点型（网络互联/延长）、Hub 型（终端接入）、完全分布型（理论探讨） 广域网（WAN）：\n跨更广区域互联，使用路由器和网关 组成：通信子网 + 资源子网 3 类：公共传输网络、专用传输网络、无线传输网络 相关技术：SONET、SDH、DDN、FR、ATM 城域网（MAN）：\nIEEE 802.6 标准 单个城市范围内 3 层结构：核心层、汇聚层、接入层 移动通信网（5 代演进）：\n代 特征 1G 模拟信号传输 2G 数字通信技术 3G 扩展频谱 4G 快速发展繁荣 5G 多业务、多技术融合（SBA + 网络切片） 5G 核心特征：\nSBA（Service-Based Architecture）服务化架构：网络功能灵活定制和按需组合 网络切片技术：在单个物理网络中切分出多个分离的逻辑网络 FlexE（Flexible Ethernet）硬切片 1.5 网络设备与工作层级 设备 工作层级 集线器（Hub） 物理层 中继器（Repeater） 物理层 网桥（Bridge） 数据链路层 交换机（Switcher） 数据链路层 路由器（Router） 网络层 防火墙（Firewall） 网络层（作为网络对外门户） 交换机功能：集线、中继、桥接、隔离冲突域\n交换机协议：\nSTP（生成树协议）：解决链路环路问题 链路聚合协议：提升端口带宽和链路可靠性 1.6 OSI/RM 七层模型（必背） 层 主要功能 详细说明 7. 应用层 处理网络应用 直接为终端用户服务，提供各类应用过程的接口和用户接口 6. 表示层 管理数据表示方式 数据编码约定、本地句法转换，使不同终端可互通信 5. 会话层 建立和维护会话连接 远程进程通信、安全验证、退出机制、断点恢复 4. 传输层 端到端传输 TCP 保证数据包无差错、按序、无丢失、无冗余；服务访问点为端口 3. 网络层 源节点和目的节点之间传输 虚电路/数据报分组交换、路由选择、阻塞控制、网络互连、诊断 2. 数据链路层 提供点到点的帧传输 封装成帧、链路管理、差错控制、流量控制 1. 物理层 在物理链路上传输比特流 机械、电气、功能、规程特性 记忆口诀（自下而上）：物链网输会表应（或 \u0026ldquo;Please Do Not Throw Sausage Pizza Away\u0026rdquo;）\n1.7 TCP/IP 协议族 TCP/IP 模型 = 应用层 + 传输层 + 网际层 + 网络接口层（硬件层）\n对应关系：\nISO/OSI 模型 TCP/IP 协议 TCP/IP 模型 应用层 / 表示层 / 会话层 FTP / Telnet / SMTP / NFS / SNMP 应用层 传输层 TCP / UDP 传输层 网络层 IP / ICMP / ARP / RARP 网际层 数据链路层 / 物理层 Ethernet / IEEE 802.3 / FDDI / Token-Ring / ARCnet 网络接口层（硬件层） 1.8 应用层协议 协议 全称 端口 传输层 关键特性 FTP File Transport Protocol 20（数据） + 21（控制） TCP 需建立 2 条 TCP 连接 TFTP Trivial File Transfer Protocol 69 UDP 简单、开销小；不可靠、超时重传；无认证 HTTP Hypertext Transfer Protocol 80 TCP 从 WWW 服务器传超文本到浏览器 HTTPS HTTP Secure 443 TCP HTTP + SSL/TLS；传输加密 + 身份认证 DHCP Dynamic Host Configuration Protocol 67/68 UDP 集中分配 IP/网关/DNS；多服务器时客户端用第一个收到的 OFFER DNS Domain Name System 53 UDP/TCP 域名→IP；PTR 记录做 IP→域名反向解析 DNS 查询方式：\n方式 特点 迭代查询 查询得到的是其他服务器的引用，本地服务器需访问被引用的服务器做进一步查询 递归查询 要求服务器彻底进行名字解析，并返回最后的结果 1.9 传输层协议对比（高频） 维度 TCP UDP 连接性 面向连接 无连接 可靠性 可靠（差错校验+重传、流量控制、拥塞控制） 不可靠 数据量 数据量少 数据量大 可靠性要求 高 不高 速度 相对慢 快 端口寻址 有 有 关键点：TCP 和 UDP 都提供\u0026quot;端口寻址\u0026quot;能力（高频反选题）\n1.10 网络层协议 IPv6 称为\u0026quot;下一代互联网协议\u0026quot; 数据报目的地址：单播、多播/组播、任播 IPv4 → IPv6 过渡技术： 双协议栈技术 隧道技术 NAT-PT 技术 1.11 路由器协议 IGP（Interior Gateway Protocol）：在一个自治系统（AS）内运行 EGP（Exterior Gateway Protocol）：在 AS 之间；为简单树型拓扑设计 BGP（Border Gateway Protocol）：在 EGP 经验上制定，Internet 上唯一的网关协议 路由器功能：异种网络互连、子网协议转换、数据路由、速率适配、隔离网络、报文分片和重组、备份、流量控制\n1.12 网络工程 3 阶段：\n网络规划：以需求为导向，兼顾技术和工程可行性 网络设计： 逻辑设计：网络结构设计、技术选型、IP 地址和路由设计、网络冗余设计、网络安全设计 物理设计：布线设计、机房设计、设备选型 网络实施：工程实施计划、设备验收、安装调试、系统试运行和切换、用户培训 1.13 网络冗余设计（高频考点） 目的：避免网络组件单点失效造成应用失效 备用路径：在主路径失效时才启用 负载分担：通过并行链路提供流量分担来提高性能 关键反选题：备用路径是\u0026quot;失效时启用\u0026quot;而非\u0026quot;同时投入使用\u0026quot;——这正是考试常设的陷阱\n1.14 网络分层设计 层级 定位 关键职责 接入层 直接面向用户 解决相邻用户互访、提供足够带宽、地址/用户认证、计费、用户信息收集（IP/MAC/访问日志） 汇聚层 核心层和接入层分界面 网络访问策略控制、数据包处理/过滤/寻址、其他数据处理（是否需要视规模而定） 核心层 网络主干 高速转发通信、高可靠性/性能/吞吐量；双机冗余热备份非常必要 1.15 无线网络覆盖范围（典型数据） 技术 覆盖范围 802.15.1 蓝牙 ~10 m 802.15.4 ZigBee 10 ~ 100 m 802.11n 无线局域网 ~100 m 802.16m 无线城域网 2 ~ 10 km 2. 关键概念速查 概念 定义/说明 常见考点 OSI 七层 物链网输会表应 层名/功能对应 TCP/IP 四层 应用/传输/网际/网络接口 与 OSI 对应 TCP 端口 80 HTTP 端口号 TCP 端口 443 HTTPS 端口号 FTP 端口 数据 20、控制 21 双连接 TFTP 端口 UDP 69 不可靠 以太网最小帧长 64 字节 避冲突 以太网最大帧长 1518 字节 帧结构 DHCP 客户端 取第一个 OFFER 报文 多服务器场景 IPv4→IPv6 过渡 双栈/隧道/NAT-PT 三种技术 STP 生成树协议 防环路 BGP 边界网关协议 Internet 唯一网关协议 IGP / EGP 内部/外部网关协议 AS 内/间 备用路径 主路径失效时启用 区别于负载分担 负载分担 并行链路分流量 高性能 接入层/汇聚层/核心层 3 层网络架构 职责区分 3. 典型例题 从源文本\u0026quot;练习题\u0026quot;中精选 3 道最具代表性题目\n例题 1：以太网帧长 题目：在以太网标准中规定的最小帧长是 （1） 字节。最小帧长是根据 （2） 来定的。 （1）A．20 B．64 C．128 D．1518 （2）A．网络中传送的最小信息单位 B．物理层可以区分的信息长度 C．网络中发生冲突的最短时间 D．网络中检测冲突的最长时间\n答案：B D\n解析：以太网规定最小帧长为 64 字节，最大帧长为 1518 字节。设置最小帧长的目的就是保证发送端在发送完一帧之前能够检测到是否发生冲突，因此最小帧长要根据网络中检测冲突的最长时间来定。\n例题 2：TCP vs UDP 题目：TCP 和 UDP 协议均提供了（ ）能力。 A．连接管理 B．差错校验和重传 C．流量控制 D．端口寻址\n答案：D\n解析：TCP 与 UDP 都有端口号的概念，都能基于端口进行进程寻址。但 TCP 是面向连接的，提供连接管理、差错校验和重传、流量控制；UDP 是无连接的，没有连接管理、差错重传、流量控制这些能力。\n例题 3：无线网络覆盖范围 题目：下列无线网络技术中，覆盖范围最小的是（ ）。 A．802.15.1 蓝牙 B．802.11n 无线局域网 C．802.15.4 ZigBee D．802.16m 无线城域网\n答案：A\n解析：蓝牙覆盖范围约 10 m 以内；802.11n 无线局域网 100 m；ZigBee 10100 m；802.16m 无线城域网 2~10 km。蓝牙覆盖范围最小。\n例题 4：网络冗余设计 题目：以下关于网络冗余设计的叙述中，错误的是（ ）。 A．网络冗余设计避免网络组件单点失效造成应用失效 B．备用路径与主路径同时投入使用，分担主路径流量 C．负载分担是通过并行链路提供流量分担来提高性能的 D．网络中存在备用链路时，可以考虑加入负载分担设计\n答案：B\n解析：网络冗余设计的目的就是避免单点失效；备用路径是在主路径失效时启用，而非常态同时使用。负载分担才是通过并行链路提供流量分担的常时机制。\n4. 高频考点 本章最常考的内容集中在 4 个方向：\nOSI 七层模型与 TCP/IP 协议族：七层名称（物链网输会表应）、各层功能、对应设备（Hub→物理层、Switch→数据链路层、Router/Firewall→网络层），以及 TCP/IP 协议（TCP/UDP/IP/ICMP/ARP/RARP）在四层模型中的位置 常见应用层协议的端口号：HTTP 80 / HTTPS 443 / FTP 20+21 / TFTP 69 / DNS 53，以及 FTP 双连接（数据 20、控制 21）几乎是必考 TCP vs UDP 关键差异：都提供端口寻址，但只有 TCP 提供连接管理/差错重传/流量控制——此为反选题最爱 网络冗余设计的\u0026quot;备用路径\u0026quot; vs \u0026ldquo;负载分担\u0026rdquo;：备用路径是\u0026quot;主路径失效时才启用\u0026quot;，不是\u0026quot;同时启用分担流量\u0026quot;——必考的细节陷阱 其他常考点：IPv4→IPv6 过渡（双协议栈/隧道/NAT-PT）、DHCP 客户端取第一个 OFFER 报文、5G SBA + 网络切片特征。\n","date":"2024-01-01T00:00:00Z","permalink":"/p/03-ji-suan-ji-wang-luo-ji-chu/","title":"03-计算机网络基础"},{"content":"04-信息系统基础（基于第4小时） 软考-系统架构设计师 | 第2篇 架构设计专业知识 出题形式：单项选择题 | 分值占比：2-4 分\n0. 考点分析 第4小时主要学习信息系统概述、信息化的典型应用、典型信息系统架构模型等内容。\n根据考试大纲，本小时知识点会涉及单项选择题，概念性强，掌握了这些知识，对学习其他软考科目也是有益处的。难度不大，充分理解记忆即可。本小时知识架构包括：信息系统概述、信息化的典型应用（TPS/MIS/DSS/ES/OAS/ERP）、典型信息系统架构模型（电子政务/企业信息化/电子商务）。\n1. 核心知识点 1.1 信息系统概述 定义：信息系统是由计算机软硬件、网络和通信设备、信息资源、用户和规章制度组成的以处理信息流为目的的人机一体化系统。 功能：输入、存储、处理、输出和控制。 诺兰阶段模型：理查德·诺兰（Richard L. Nolan）将信息系统的发展道路划分为初始、传播、控制、集成、数据管理和成熟6 个阶段。 生命周期：4 个阶段——产生、开发、运行、消亡。 建设原则：高层管理人员介入原则、用户参与开发原则、自顶向下规划原则、工程化原则等。 开发方法：结构化方法、原型法、面向对象方法、面向服务的方法（SOA）、敏捷方法、构件化开发方法等。 原型法分类 分类维度 类型 说明 按实现功能 水平原型 行为原型，用于界面，细化需求但未实现功能 按实现功能 垂直原型 结构化原型，用于复杂算法实现，实现了部分功能 按最终结果 抛弃式 探索式原型，解决需求不确定性、二义性、不完整性 按最终结果 演化式 逐步演化为最终系统，适用于 Web 项目 构件化开发方法 构件并非一定包含类，一个类元素只能属于一个构件。 构件获取方式：①从现有构件中获取；②通过遗留工程（Legacy Engineering）提取；③从市场购买商业构件；④开发新构件。 构件的分类方式：关键字分类法、刻面分类法、超文本方法。 构件检索方式：基于关键字的检索、刻面检索法、超文本检索法。 面向服务的方法（SO） 在面向对象方法的基础上发展而来。 跨构件的功能调用采用接口的形式暴露。 接口的定义与实现解耦催生了服务（Service-Oriented, SO）。 重点关注面向服务的架构（SOA）。 敏捷方法 两个核心特点： \u0026ldquo;适应型\u0026quot;而非\u0026quot;预设型\u0026rdquo;——欢迎变化 \u0026ldquo;面向人的\u0026quot;而非\u0026quot;面向过程的\u0026rdquo;——以人为本 3 点核心思想： 适应型，而非可预测型 以人为本，而非以过程为本 属于迭代增量式的开发过程 1.2 信息化的典型应用 TPS（业务处理系统）和 EDPS（电子数据处理系统） 定义：业务处理系统（Transaction Processing System, TPS）或电子数据处理系统（Electronic Data Processing System, EDPS） 作用：计算机自动化、减轻数据处理负担、提高处理效率 特点：信息系统发展的最初级形式，也是基础和桥梁；常用结构化生命周期法开发 数据处理：IPO（Input-Process-Output） 数据处理周期：数据输入、数据处理、数据库的维护、文件报表的生成、查询处理 5 个阶段 数据处理方式：批处理（Batch Processing）、联机事务处理（OnLine Transaction Processing, OLTP） MIS（管理信息系统） 在 TPS 基础上发展的高度集成化的人机信息系统 用于企业整体的某些管理和业务层面的管理决策 上层是子系统和功能，底层是各个过程 7 个子系统：销售市场、生产、后勤、人事、财务和会计、信息处理、高层管理 DSS（决策支持系统） 两种定义： 定义一：由语言系统、知识系统和问题处理系统 3 部分组成 定义二：交互式、灵活的、适应性强的基于计算机的信息系统 主要特征： 数据和模型是 DSS 的主要资源 支援用户作决策 主要解决半结构化及非结构化问题 提高决策的有效性而不是效率 DSS 两种级别结构：两库结构、基于知识的结构 DSS 9 项基本功能：多层决策、收集存储外部信息、收集反馈信息、模型存储管理、方法存储管理、数据模型方法管理、数据加工、人机接口和图形加工、支持分布使用 特点：面向决策者、支持半结构化问题、辅助支持、过程动态、交互 组建过程：数据重组 → 建立数据仓库 → 建立数据字典 → 数据挖掘 → 建立模型 ES（专家系统） 基于知识的智能计算机程序，使用知识与推理过程求解高难度问题 属于人工智能，用于求解半结构化或非结构化问题 分支：机器人技术、视觉系统、自然语言处理、学习系统、神经网络 专家系统 vs 一般计算机系统： 比较项 专家系统 一般计算机系统 功能 解决问题、解释结果、判断与决策 解决问题 处理能力 处理数字与符号 处理数字 处理问题种类 准结构性或非结构性，不确定知识 结构性，确定知识 ES 特点：超越时间限制、操作成本低廉、易于传递与复制、处理手段一致、善于克服难题、适用特定领域 ES 组成：知识库、综合数据库、推理机、知识获取、解释程序、人机接口 核心：推理机 + 知识库 OAS（办公自动化系统） 解决数据、文字、声音、图像等信息的一体化处理 集文字、数据、语言、图像为一体的综合性、跨学科的人机信息处理系统 构成：计算机设备、办公设备、数据通信及网络设备、软件系统 功能：事务处理、信息管理、辅助决策 ERP（企业资源规划） 三大流：物流、资金流、信息流 定义：在信息技术基础上集成了企业的所有资源信息，提供决策、计划、控制与经营业绩评估的全方位和系统化的管理平台 管理范围：所有供需过程，供应链全面管理，与人事系统和 CRM 等关联 11 个基本模块：生产预测、销售管理、经营计划、主生产计划、物料需求计划、能力需求计划、车间作业计划、采购与库存管理、质量与设备管理、财务管理 功能：支持决策、不同行业的针对性 IT 解决方案、提供全行业和跨行业的供应链 1.3 典型信息系统架构模型 电子政务（EG） 定义：利用信息技术和其他相关技术，实现公务、政务、商务、事务的一体化管理与运行的政府形态改造的系统工程 行为主体三方：政府（Government）、企（事）业单位（Business）、居民（Citizen） 电子政务分类：\n名称 解释 G2G（政府对政府） 政府内部的政务活动 G2B（政府对企业） 政府向企（事）业单位发布方针、政策、法规等 G2C（政府对居民） 政府面向居民所提供的服务 B2G（企业对政府） 企业向政府缴税、投标、供应商品服务 C2G（居民对政府） 个人应向政府缴纳税款、填报信息、报警服务等 企业信息化（EI） 定义：企业利用现代信息技术，实现经营活动的自动化、便捷化、网络化和智能化 实现层面：技术 + 业务融合，从企业战略、业务运作和管理运作 3 个层面去实现 方法：业务流程重构方法、核心业务应用方法、信息系统建设方法、主题数据库方法、资源管理方法、人力资本投资方法 电子商务（EC） 定义：利用 Web 提供的通信手段在网上买卖产品或提供服务，及其衍生行为 主要模式：B2B、B2C、C2C、O2O（线上购买线下的服务） 2. 关键概念速查 概念 定义/说明 常见考点 诺兰模型 6 阶段 初始、传播、控制、集成、数据管理、成熟 信息系统的 6 个发展阶段 信息系统生命周期 产生、开发、运行、消亡 4 阶段 与软件生命周期的区别 原型法 快速建立系统模型与用户交流 水平/垂直、抛弃/演化的区别 构件 可复用的软件组件 构件获取方式、分类方式 敏捷方法 适应型、面向人、迭代增量 与传统方法（预设型、面向过程）对比 TPS/EDPS 业务处理系统/电子数据处理系统 信息系统最初级形式 MIS 7 大子系统 销售/生产/后勤/人事/财务/信息/高层 MIS 功能/层次矩阵 DSS 结构 两库结构 / 基于知识的结构 半结构化/非结构化问题 ES 组成 知识库+推理机+综合数据库+知识获取+解释程序+人机接口 推理机+知识库=核心 ERP 三大流 物流、资金流、信息流 11 个基本模块 电子政务主体 政府(G)、企事业(B)、居民(C) G2G/G2B/G2C/B2G/C2G 3. 典型例题 题目1：ERP 中的企业资源包括（ ）。 A．物流、资金流和信息流 B．物流、工作流和信息流 C．物流、资金流和工作流 D．资金流、工作流和信息流\n答案：A\n解析：企业的所有资源包括三大流：物流、资金流和信息流。ERP 是对这 3 种资源进行全面集成管理的管理信息系统。\n题目2：ERP（Enterprise Resource Planning）是建立在信息技术的基础上，利用现代企业的先进管理思想，对企业的物流、资金流和（1）流进行全面集成管理的管理信息系统。在 ERP 系统中，（2）管理模块主要是对企业物料的进、出、存进行管理。 （1）A．产品 B．人力资源 C．信息 D．加工 （2）A．库存 B．物料 C．采购 D．销售\n答案：C A\n解析：ERP 是建立在信息技术的基础上，利用现代企业的先进管理思想，对企业的物流、资金流和信息流进行全面集成管理的管理信息系统。ERP 系统主要包括：生产预测、销售管理、经营计划、主生产计划、物料需求计划、能力需求计划、车间作业计划、采购与库存管理、质量与设备管理、财务管理、有关扩展应用模块等内容。显然对企业物料的进、出、存进行管理的模块是库存管理模块。\n题目3：电子政务是对现有的政府形态的一种改造，利用信息技术和其他相关技术，将其管理和服务职能进行集成，在网络上实现政府组织结构和工作流程优化重组。与电子政务相关的行为主体有三个，即政府、（1）及居民。国家和地方人口信息的采集、处理和利用，属于（2）的电子政务活动。 （1）A．部门 B．企（事）业单位 C．管理机构 D．行政机关 （2）A．政府对政府 B．政府对居民 C．居民对居民 D．居民对政府\n答案：B A\n解析：电子政务是对现有的政府形态的一种改造，利用信息技术和其他相关技术，将其管理和服务职能进行集成，在网络上实现政府组织结构和工作流程优化重组。与电子政务相关的行为主体有三个，即政府、企（事）业单位及居民。国家和地方人口信息的采集、处理和利用，属于政府对政府的电子政务活动。\n4. 高频考点 ERP 三大流：物流、资金流、信息流（必考点，注意不是工作流） MIS 7 大子系统：销售市场、生产、后勤、人事、财务和会计、信息处理、高层管理 DSS 解决什么问题：半结构化及非结构化问题；提高决策的有效性而非效率 ES 核心：知识库 + 推理机 电子政务行为主体三方：政府、企（事）业单位、居民 G2G/G2B/G2C/B2G/C2G 五种模式区分 诺兰模型 6 阶段：初始、传播、控制、集成、数据管理、成熟 敏捷方法两大特点：适应型、面向人 原型法 4 象限：水平/垂直 × 抛弃/演化 ","date":"2024-01-01T00:00:00Z","permalink":"/p/04-xin-xi-xi-tong-ji-chu/","title":"04-信息系统基础"},{"content":"05-信息安全技术（基于第5小时） 软考-系统架构设计师 | 第2篇 架构设计专业知识 出题形式：单项选择题 | 分值占比：2-5 分\n0. 考点分析 第5小时主要学习信息安全基础知识、信息安全系统的组成框架、信息加解密技术、密钥管理技术、访问控制及数字签名技术、信息安全的抗攻击技术、信息安全的保障体系与评估方法等内容。\n根据考试大纲，本小时知识点会涉及单项选择题，约占 5 分。本小时内容侧重于概念知识，根据以往全国计算机技术与软件专业技术资格（水平）考试的出题规律，考查的知识点多来源于教材，扩展内容较少。\n导读小贴士：信息安全事关国家安全和社会稳定，在新版教材中，信息安全的内容大幅增加了，知识点也得到了更新，与信息安全工程师的某些内容同步。所以掌握本小时知识点非常重要。\n1. 核心知识点 1.1 信息安全基础知识 信息安全基本要素（5 个） 要素 含义 机密性 信息不被泄露给未授权的用户 完整性 数据不被未授权篡改 可用性 合法用户能正常访问 可控性 对信息传播和内容具有控制能力 可审查性 出现安全问题时提供依据和手段 信息安全范围 设备安全 数据安全（即\u0026quot;数据安全三性\u0026quot;）：秘密性、完整性、可用性 内容安全 行为安全 信息存储安全范围 信息使用的安全 系统安全监控 计算机病毒防治 数据的加密和防止非法的攻击 网络安全 漏洞表现：物理安全性、软件安全漏洞、不兼容使用安全漏洞 威胁表现：非授权访问、信息泄露或丢失、破坏数据完整性、拒绝服务攻击、利用网络传播病毒 安全措施目标（5 个）：访问控制、认证、完整性、审计、保密 1.2 信息安全系统的组成框架 信息安全系统框架 = 技术体系 + 组织机构体系 + 管理体系\n技术体系 基础安全设备 计算机网络安全 操作系统安全 数据库安全 终端设备安全 组织机构体系 3 个层次：决策层、管理层、执行层 管理体系 3 个部分：法律管理、制度管理、培训管理 1.3 信息加解密技术 数据加密 防止未经授权的用户访问敏感信息 保障系统的机密性要素 对称密钥加密算法（加密密钥 = 解密密钥） 算法 密钥长度 分组 说明 DES 56 位 64 位 数据加密标准，已脆弱 3DES（三重 DES） 112 位 64 位 两把 56 位密钥做三次 DES IDEA 128 位 64 位 国际数据加密算法 AES 128/192/256 位 128 位 高级加密标准，替换 DES SM4（国密） 128 位 128 位 中国国密算法 3DES 加密过程：K1 加密 → K2 解密 → K1 加密（两组 56 位密钥，加起来 112 位）\n非对称密钥加密算法（加密密钥 ≠ 解密密钥） 公钥加密，私钥解密 → 保密通信 私钥加密，公钥解密 → 数字签名 算法 安全性基础 密钥长度 特点 RSA 大素数分解的困难性 当前安全 2048 位 国际通用公钥加密，比同等安全级对称算法慢 1000 倍 SM2（国密） 椭圆曲线离散对数问题 比 RSA 小得多 相同安全程度下密钥长度和计算规模都小 1.4 密钥管理技术 密钥使用控制 控制密钥安全性的技术：密钥标签、控制矢量 密钥分配发送方式：物理方式、加密方式、第三方加密方式 第三方：密钥分配中心（Key Distribution Center, KDC） 公钥加密体制的密钥管理（4 种方式） 直接公开发布（如 PGP） 公用目录表 公钥管理机构 公钥证书（CA = Certificate Authority） 1.5 访问控制及数字签名技术 访问控制三要素 主体 客体 控制策略 访问控制三方面 认证 控制策略实现 审计（审计的目的是防止滥用权力） 访问控制实现技术 技术 说明 访问控制矩阵（ACM） 以主体为行、客体为列的矩阵，是后三者基础 访问控制表（ACL） 按列（客体）保存，目前最流行、使用最多 能力表（Capabilities） 按行（主体）保存 授权关系表 抽取非空元素，稀疏矩阵时很有效，常用于安全数据库 数字签名 技术组成：公钥加密技术 + 数字摘要技术 5 个条件：可信、不可伪造、不可重用、不可改变、不可抵赖 特点： 对称密钥签名：只能在两方间实现，需要共同信赖的仲裁人 公钥加密签名：可在任意多方间实现，不需要仲裁且可重复多次验证 实际应用：先对文件做摘要，再对摘要签名（提升速度，摘要泄露不影响文件保密） 1.6 信息安全的抗攻击技术 密钥选择 密钥分两大类： 数据加密密钥（DK） 密钥加密密钥（KK）——用于保护密钥 加密的算法通常公开，安全性在于密钥 密钥生成 3 因素：增大密钥空间、选择强钥、密钥的随机性 拒绝服务（DoS）攻击 定义：使系统不可访问并因此拒绝合法的用户服务要求，侵犯系统的可用性要素 传统 4 种分类： 消耗资源 破坏或更改配置信息 物理破坏或改变网络部件 利用服务程序中的处理错误使服务失效 DDoS：分布式拒绝服务攻击 3 级结构：Client（客户端）→ Handler（主控端）→ Agent（代理端） 4 种防御方法：特征识别、防火墙、通信数据量的统计、修正问题和漏洞 欺骗攻击与防御 类型 原理 防范方法 ARP 欺骗 解析 IP 为 MAC 固化 ARP 表、ARP 服务器、双向绑定、防护软件 DNS 欺骗 解析域名为 IP 被动监听检测、虚假报文探测、交叉检查查询 IP 欺骗 修改 IP 报头 防火墙 端口扫描 搜集信息的常用手法 分类：全 TCP 连接、半打开式扫描（SYN 扫描）、FIN 扫描、第三方扫描 TCP/IP 堆栈攻击 攻击 原理 防范 SYN Flooding（同步包风暴） DoS 最广泛，让目标主机等连接耗尽资源 减少等待超时时间 ICMP 攻击（Ping of Death） 网络层缓冲区溢出，旧版系统崩溃 打补丁、升级系统 SNMP 攻击 SNMP V1 缺认证 升级到 V2+、设访问密码 系统漏洞扫描 两类： 基于网络的漏洞扫描：通过网络扫描，但常被主机边界防护封堵 基于主机的漏洞扫描：在目标系统安装代理（Agent），优点：扫描漏洞数量多、集中化管理、网络流量负载小 1.7 信息安全的保障体系与评估方法 等级保护（GB 17859—1999） 计算机系统安全保护能力 5 个等级（与 TCSEC 对应）：\n等级 名称 TCSEC 对应 第 1 级 用户自主保护级 C1 第 2 级 系统审计保护级 C2 第 3 级 安全标记保护级 B1 第 4 级 结构化保护级 B2 第 5 级 访问验证保护级 B3 安全保密技术 DLP（数据泄露防护）：通过技术手段防止企业指定数据以违反安全策略的形式流出 数字水印：通过数字信号处理方法在数字化的媒体文件中嵌入特定标记 分类：可感知的和不易感知的两种 安全协议 协议 层次/位置 作用 SSL 应用层和 TCP 层之间 保密性通信、点对点身份认证、可靠性通信 PGP 应用层（电子邮件） 用了 RSA、IDEA、完整性检测和数字签名 IPSec 网络层 主要优点是透明性，不需改应用 SET 应用层 解决用户、商家、银行间信用卡支付 HTTPS 应用层 详见第 3 小时 信息系统安全风险与评估 风险定义：由于系统存在的脆弱性所导致的安全事件发生的概率和可能造成的影响 风险评估：对保密性、完整性和可用性等安全属性进行科学评价 5 个基本要素：脆弱性、资产、威胁、风险、安全措施 风险计算模型关键要素：信息资产、弱点/脆弱性、威胁 2. 关键概念速查 概念 定义/说明 常见考点 信息安全 5 要素 机密性/完整性/可用性/可控性/可审查性 CIA 三元组 + 2 对称算法 DES/3DES/IDEA/AES/SM4 密钥长度、分组长度 非对称算法 RSA、SM2 加密 vs 签名 RSA 安全性 大素数分解困难性 2048 位安全 SM2 基础 椭圆曲线离散对数 国产化场景 3DES 密钥长度 112 位（2×56） 必考 AES 密钥长度 128/192/256 位 替换 DES 访问控制 4 技术 ACM、ACL、Capabilities、授权关系表 ACL 最流行 审计目的 防止滥用权力 访问控制三方面 DoS 侵犯要素 可用性 传统 4 种分类 DDoS 3 级 Client/Handler/Agent 分布式结构 IPSec 位置 网络层 透明性 PGP 用途 电子邮件安全 RSA+IDEA+数字签名 等保 5 级 用户自主/系统审计/安全标记/结构化/访问验证 GB 17859-1999 DLP 数据泄露防护 防止数据违规流出 3. 典型例题 题目1：在信息安全领域，基本的安全性原则包括机密性（Confidentiality）、完整性（Integrity）和可用性（Availability）。机密性指保护信息在使用、传输和存储时（1）。信息加密是保证系统机密性的常用手段。使用哈希校验是保证数据完整性的常用方法。可用性指保证合法用户对资源的正常访问，不会被不正当地拒绝。（2）就是破坏系统的可用性。\n（1）A．不被泄露给已注册的用户 B．不被泄露给未授权的用户 C．不被泄露给未注册的用户 D．不被泄露给已授权的用户\n（2）A．跨站脚本攻击（XSS） B．拒绝服务攻击（DoS） C．跨站请求伪造攻击（CSRF） D．缓冲区溢出攻击\n答案：B B\n解析：机密性指保护信息在使用、传输和存储时不被泄露给未授权的用户。XSS 是插入恶意 html 代码实现劫持浏览器会话等攻击；DoS 攻击利用大量合法的请求占用大量网络资源以达到瘫痪网络的目的，受到 DoS 攻击的系统可用性大大降低；CSRF 是挟制、欺骗用户在当前已登录的 Web 应用程序上执行非本意的操作的攻击；缓冲区溢出攻击利用缓冲区溢出漏洞控制主机。\n题目2：DES 加密算法的密钥长度为 56 位，三重 DES 的密钥长度为（ ）位。 A．168 B．128 C．112 D．56\n答案：C\n解析：三重 DES 采用两组 56 位的密钥 K1 和 K2，通过\u0026quot;K1 加密—K2 解密—K1 加密\u0026quot;的过程，两组密钥加起来的长度是 112 位。\n题目3：非对称加密算法中，加密和解密使用不同的密钥，下面的加密算法中（1）属于非对称加密算法。若甲、乙采用非对称密钥体系进行保密通信，甲用乙的公钥加密数据文件，乙使用（2）来对数据文件进行解密。\n（1）A．AES B．RSA C．IDEA D．DES （2）A．甲的公钥 B．甲的私钥 C．乙的公钥 D．乙的私钥\n答案：B D\n解析：加密密钥和解密密钥不相同的算法，称为非对称加密算法，这种方式又称为公钥密码体制。常见的非对称加密算法有 RSA 等。若甲、乙采用非对称密钥体系进行保密通信，甲用乙的公钥加密数据文件，乙使用乙的私钥来对数据文件进行解密。加密密钥和解密密钥相同的算法，称为对称加密算法，常见的有 DES、3DES、IDEA、AES 等。\n4. 高频考点 信息安全 5 要素：机密性、完整性、可用性、可控性、可审查性（必考 CIA 三元组） DES 密钥 56 位，3DES 112 位，AES 128/192/256 位（必考） RSA vs 对称算法：RSA 慢 1000 倍；公钥加密+私钥解密=保密通信；私钥加密+公钥解密=数字签名 访问控制 4 技术及各自索引方式：ACM 是基础、ACL 按列、Capabilities 按行、授权关系表用于稀疏 数字签名 5 条件：可信、不可伪造、不可重用、不可改变、不可抵赖 DoS 侵犯可用性（必考） DDoS 3 级结构：Client、Handler、Agent IPSec 工作在网络层（透明性是其最大优点） PGP 用于电子邮件安全 等保 5 级（GB 17859—1999） 风险评估 5 要素：脆弱性、资产、威胁、风险、安全措施 审计目的：防止滥用权力 ","date":"2024-01-01T00:00:00Z","permalink":"/p/05-xin-xi-an-quan-ji-shu/","title":"05-信息安全技术"},{"content":"06-系统工程与系统性能（基于第6小时） 软考-系统架构设计师 | 第2篇 架构设计专业知识 出题形式：单项选择题（含计算题） | 分值占比：2-5 分\n0. 考点分析 第6小时主要学习系统工程和系统性能等内容。\n根据考试大纲，本小时知识点会涉及单项选择题，约占 2～5 分。本小时内容侧重于概念知识，也会有计算题。根据以往全国计算机技术与软件专业技术资格（水平）考试的出题规律，考查的知识点多来源于教材，扩展内容较少。\n导读小贴士：系统工程是一种方法论，从宏观上对如何创建和管理一个信息化工程提出了理论框架。而系统性能评估和设计是架构师的重要工作之一，所以掌握本小时知识点很重要。本小时的内容比较基础，难度并不大。\n1. 核心知识点 1.1 系统工程 定义与特点 系统工程是运用系统方法，对系统进行规划、研究、设计、制造、试验和使用的组织管理技术，是人们用科学方法解决复杂问题的一门技术。\n特点：整体性、综合性、协调性、科学性、实践性\n5 种主要方法 方法 提出者/时间 核心思想 工作步骤 霍尔三维结构 A.D.Hall, 1969 时间维+逻辑维+知识维 时间 7 阶段 + 逻辑 7 步骤 切克兰德方法 Checkland \u0026ldquo;比较\u0026quot;与\u0026quot;探寻\u0026rdquo;，非\u0026quot;最优化\u0026quot; 7 步骤（认识问题、根底定义、\u0026hellip;） 并行工程 — 并行、集成化处理 制造和支持过程并行 综合集成法 钱学森等 简单系统 / 巨系统 整体论、相互联系、有序性、动态 WSR 系统方法 — 物理-事理-人理 7 步（理解意图、\u0026hellip;） 霍尔三维结构（重要） 三维组成：\n时间维（7 阶段）：规划 → 拟订方案 → 研制 → 生产 → 安装 → 运行 → 更新 逻辑维（7 步骤）：明确问题 → 确定目标 → 系统综合 → 系统分析 → 优化 → 决策 → 实施 知识维：工程、医学、建筑、商业、法律、管理、社会科学、艺术等 切克兰德方法 7 步骤 认识问题 根底定义 建立概念模型 比较及探寻 选择 设计与实施 评估与反馈 并行工程（Concurrent Engineering） 对产品及其相关过程（制造过程和支持过程）进行并行、集成化处理的系统方法和综合技术 目标：提高质量、降低成本、缩短产品开发周期和产品上市时间 综合集成法（钱学森等） 系统分类：简单系统 / 巨系统 开放的复杂巨系统原则：整体论、相互联系、有序性、动态 性质：开放性、复杂性、进化与涌现性、层次性、巨量性 WSR 系统方法 全称：物理-事理-人理方法论 7 步过程：理解意图 → 制定目标 → 调查分析 → 构造策略 → 选择方案 → 协调关系 → 实现构想 系统工程的生命周期 目的：以有序而且高效的方式建立一个满足利益攸关者需求的框架。\n7 个阶段：探索研究 → 概念阶段 → 开发阶段 → 生产阶段 → 使用阶段 → 保障阶段 → 退役阶段\n生命周期方法：计划驱动方法、渐进迭代式开发、精益开发、敏捷开发\n基于模型的系统工程（MBSE） 建模方法的形式化应用，使建模方法支持系统需求、分析、设计、验证和确认等活动，持续贯穿到所有生命周期阶段 产物：\n需求分析阶段：需求图、用例图、包图 功能分析与分配阶段：顺序图、活动图、状态机图 设计综合阶段：模块定义图、内部块图、参数图 MBSE 三大支柱：建模语言、建模工具、建模思路\n1.2 系统性能 系统性能评价指标 不同对象的性能指标不同：\n对象 主要性能指标 计算机 时钟频率（主频）、运算速度、运算精度、数据处理速率（PDR）、吞吐率 路由器 设备吞吐量、端口吞吐量、全双工线速转发能力、路由表能力、背板能力、丢包率、时延、时延抖动、协议支持 交换机 端口速率、背板吞吐量、缓冲区大小、MAC 地址表大小 网络 设备级、网络级、应用级、用户级、吞吐量 操作系统 系统上下文切换、系统响应时间、系统吞吐率（量）、系统资源利用率、可靠性、可移植性 数据库管理系统 最大并发事务处理能力、负载均衡能力、最大连接数 Web 服务器 最大并发连接数、响应延迟、吞吐量 性能指标计算 4 种方法：定义法、公式法、程序检测法、仪器检测法\n1. MIPS（每秒百万次指令数） $$MIPS = \\frac{指令条数}{执行时间 \\times 10^6}$$2. 峰值计算 $$理论浮点峰值 = CPU 主频 \\times CPU 每个时钟周期执行浮点运算的次数 \\times 系统中 CPU 数$$3. 等效指令速度法（吉普森 Gibson 法） 早期用加法指令的运算速度来衡量计算机速度 后发展为各指令的运算时间乘以占比 典型占比： 加、减法指令：50% 乘法指令：15% 除法指令：5% 程序控制指令：15% 其他指令：15% $$等效指令时间 T = \\sum_{i=1}^{n} W_i \\times T_i$$ $W_i$：第 i 种指令的使用占比 $T_i$：第 i 种指令的运算时间 性能调整 性能调整 = 查找和消除瓶颈\n系统类型 调整内容 数据库系统 CPU/内存使用状况、优化数据库设计、优化数据库管理、进程/线程状态、硬盘 I/O 及剩余空间、日志文件大小 应用系统 应用系统的可用性、响应时间、并发用户数、特定应用的系统资源占用 阿姆达尔（Amdahl）定律 核心：计算机系统中对某一部件采用某种更快的执行方式所获得的系统性能改变程度，取决于这种方式所占总执行时间的比例。\n$$加速比 = \\frac{使用增强部件时完成整个任务的时间}{不使用增强部件时完成整个任务的时间}$$$$新的执行时间 = 原来的执行时间 \\times [(1-增强比例) + \\frac{增强比例}{增强加速比}]$$$$总加速比 = \\frac{原来的执行时间}{新的执行时间} = \\frac{1}{(1-增强比例) + \\frac{增强比例}{增强加速比}}$$两个关键因素：\n增强比例（≤ 1）：能被改进并增强的部分在总执行时间中所占的比例 增强加速比：使用增强执行方式后，任务执行速度的提高倍数 性能评估 基准测试程序（Benchmark） 定义：应用程序中用得最多、最频繁的那部分核心程序 准确程度（递减）：真实的程序 → 核心程序 → 小型基准程序 → 合成基准程序 常见基准测试程序： 整数测试程序 Dhrystone 浮点测试程序 Linpack Whetstone 基准测试程序 SPEC 基准测试程序 TPC 基准程序 Web 服务器性能评测 3 种方法：基准性能测试、压力测试、可靠性测试 系统监视 3 种方式 系统内置命令 查阅系统日志 可视化技术 2. 关键概念速查 概念 定义/说明 常见考点 系统工程 5 特点 整体性/综合性/协调性/科学性/实践性 必考 霍尔三维结构 时间+逻辑+知识 1969 年提出 时间维 7 阶段 规划/拟订/研制/生产/安装/运行/更新 研制阶段做方案和生产计划 逻辑维 7 步骤 明确问题/确定目标/系统综合/系统分析/优化/决策/实施 必考 切克兰德方法 \u0026ldquo;比较\u0026quot;与\u0026quot;探寻\u0026rdquo;，非\u0026quot;最优化\u0026quot; 7 步骤 钱学森综合集成 简单系统/巨系统 4 原则+5 性质 WSR 方法 物理-事理-人理 7 步 系统工程生命周期 7 阶段 探索/概念/开发/生产/使用/保障/退役 — MBSE 三大支柱 建模语言/工具/思路 — 评价计算机指标 主频/运算速度/精度/PDR/吞吐率 必考 PDR 评价路由器指标 设备吞吐量/端口吞吐量/丢包率/时延/抖动 区分路由 vs 交换 评价数据库指标 最大并发事务/最大连接数/负载均衡 必考 MIPS 公式 指令条数/(执行时间×10^6) 计算题 浮点峰值 CPU 主频 × 每周期浮点次数 × CPU 数 计算题 阿姆达尔定律 总加速比 = 1/[(1-Fe)+Fe/Se] 计算题 Dhrystone 整数基准 SPEC/TPC/Whetstone/Linpack 3. 典型例题 题目1：霍尔等人于 1969 年提出了系统方法的三维结构体系，通常称为霍尔三维结构，这是系统工程方法论的基础。霍尔三维结构以时间维、（1）维、知识维组成的立体结构概括性地表示出系统工程的各阶段、各步骤以及所涉及的知识范围。其中时间维是系统的工作进程，对于一个具体的工程项目，可以分为 7 个阶段，在（2）阶段会做出研制方案及生产计划。\n（1）A．空间 B．结构 C．组织 D．逻辑 （2）A．规划 B．拟定 C．研制 D．生产\n答案：D B\n解析：霍尔的三维结构，是美国系统工程专家霍尔等人于 1969 年提出的一种系统工程方法论，形成了由时间维、逻辑维和知识维组成的三维空间结构。时间维分为规划、拟订方案、研制、生产、安装、运行、更新 7 个时间阶段，各阶段工作如下： ①规划阶段：调研、程序设计，目的在于谋求活动的规划与战略。 ②拟订方案：提出具体的计划方案。 ③研制阶段：作出研制方案及生产计划。 ④生产阶段：生产出系统的零部件及整个系统，并提出安装计划。 ⑤安装阶段：将系统安装完毕，并完成系统的运行计划。 ⑥运行阶段：系统按照预期的用途开展服务。 ⑦更新阶段：提高系统功能，取消旧系统而代之以新系统，或改进原有系统。\n注意：题目问的是\u0026quot;做出研制方案及生产计划\u0026quot;对应的阶段是拟订（即\u0026quot;拟订方案\u0026quot;提出具体的计划方案，然后\u0026quot;研制\u0026quot;是做出研制方案及生产计划），按解析答案应为B 拟定。\n题目2：对计算机评价的主要性能指标有时钟频率、（1）、运算精度和内存容量等。对数据库管理系统评价的主要性能指标有（2）、数据库所允许的索引数量和最大并发事务处理能力等。\n（1）A．丢包率 B．端口吞吐量 C．可移植性 D．数据处理速率 （2）A．MIPS B．支持协议和标准 C．最大连接数 D．时延抖动\n答案：D C\n解析：性能指标是软、硬件的性能指标的集成。在硬件中，包括计算机、各种通信交换设备、各类网络设备等；在软件中，包括操作系统、协议以及应用程序等。评价计算机的主要性能指标有时钟频率（主频）、运算速度、运算精度、数据处理速率（PDR）、吞吐率等。衡量数据库管理系统的主要性能指标有最大并发事务处理能力、负载均衡能力、最大连接数等。\n题目3：峰值 MIPS（每秒百万次指令数）用来描述计算机的定点运算速度，通过对计算机指令集中基本指令的执行速度计算得到。假设某计算机中基本指令的执行需要 5 个机器周期，每个机器周期为 3μs，则该计算机的定点运算速度为（ ）MIPS。\nA．8 B．15 C．0.125 D．0.067\n答案：D\n解析：峰值 MIPS 是衡量 CPU 速度的一个指标。根据题干描述，假设某计算机中基本指令的执行需要 5 个机器周期，每个机器周期为 3μs，则该计算机每完成一个基本指令需要 5×3=15μs，根据峰值 MIPS 的定义，其定点运算速度为 1/15=0.067MIPS。特别需要注意单位\u0026quot;μs\u0026quot;和\u0026quot;百万指令数\u0026quot;，在计算过程中恰好抵消。\n$$MIPS = \\frac{指令条数}{执行时间 \\times 10^6} = \\frac{1}{5 \\times 3 \\times 10^{-6} \\times 10^6} = \\frac{1}{15} ≈ 0.067$$ 4. 高频考点 霍尔三维结构：时间+逻辑+知识（必考），时间维 7 阶段、逻辑维 7 步骤 评价计算机性能指标：主频、运算速度、运算精度、数据处理速率 PDR、吞吐率 评价数据库性能指标：最大并发事务处理能力、负载均衡能力、最大连接数（必考） MIPS 公式：MIPS = 指令条数 / (执行时间 × 10⁶) 阿姆达尔定律公式：总加速比 = 1 / [(1-增强比例) + 增强比例/增强加速比]（必考计算题） 基准测试程序准确程度递减：真实程序 → 核心程序 → 小型基准程序 → 合成基准程序 Dhrystone 是整数测试程序、Linpack 是浮点测试程序 切克兰德方法核心是\u0026quot;比较\u0026quot;与\u0026quot;探寻\u0026quot;，不是\u0026quot;最优化\u0026quot; WSR 三理：物理-事理-人理（东方系统思想） 生命周期 7 阶段：探索/概念/开发/生产/使用/保障/退役 ","date":"2024-01-01T00:00:00Z","permalink":"/p/06-xi-tong-gong-cheng-yu-xi-tong-xing-neng/","title":"06-系统工程与系统性能"},{"content":"07-软件工程（基于第7小时） 软考-系统架构设计师 | 第2篇 架构设计专业知识 出题形式：单项选择题 + 案例分析题 | 分值占比：3-6 分 教材参考：第7章\n0. 考点分析 本小时主要学习软件工程、需求工程、系统分析与设计、净室软件工程、基于构件的软件工程、软件项目管理等内容。考察侧重概念知识和管理知识。根据考试大纲，本小时知识点会涉及单项选择题和下午案例分析题，约占8-15分，论文也会有涉及。\n软件工程是以工程的管理方法去管理软件项目，涉及的知识点很多，是上午题和案例题的\u0026quot;重头戏\u0026quot;。像结构化和面向对象在三门考试中都会出题。\n1. 核心知识点 1.1 软件工程基础 软件危机6大表现\n软件开发进度难以预测 软件开发成本难以控制 软件功能难以满足用户期望 软件质量无法保证 软件难以维护 软件缺少适当的文档资料 软件生命周期：需求分析 → 软件设计 → 软件开发 → 运行维护 → 被淘汰\n1.2 软件过程模型（5大模型） 1. 瀑布模型（Waterfall Model）\n结构化开发方法使用 7阶段：需求分析→系统设计→程序设计→编码实现→单元测试→集成测试→系统测试→运行维护 特点：因果关系紧密相连，前一阶段输出是后一阶段输入，每个阶段伴随里程碑 缺点：需求难一次确定、变更代价高、结果难预见、阶段不能并行 2. 原型模型（Prototype Model）\n快速原型，原型法使用 2阶段：原型开发 + 目标软件开发 2种类型： 抛弃型原型：需求确认后即丢弃，继续用瀑布模型 演化性原型：不断补充完善形成最终产品 3. 螺旋模型（Spiral Model）\n在快速原型的基础上结合瀑布模型扩展而成 每个阶段4部分：目标设定、风险分析、开发和有效性验证、评审 适用：大型软件开发，强调其他模型忽视的风险分析 4. 敏捷（Agile）模型\n敏捷方法 核心特征 极限编程（XP） 高效、低风险、测试先行（先写测试代码，再写程序） 水晶系列方法 不同的项目，采用不同的策略 Scrum（并列争球法） 侧重项目管理，Sprint迭代，从Product Backlog选最高优先级需求 FDD（特征驱动开发） 分首席程序员和\u0026quot;类\u0026quot;程序员 敏捷核心思想3点：\n适应型而非可预测型 以人为本而非以过程为本 迭代增量式开发过程 5. RUP（Rational Unified Process）\n重量级过程模型，构件化开发使用 二维软件开发模型，多个循环（Cycle），每个循环4个连续阶段： 初始 → 细化 → 构造 → 移交 9个核心工作流：业务建模、需求、分析与设计、实现、测试、部署、配置与变更管理、项目管理、环境 3大特点：用例驱动、以架构为中心、迭代和增量 RUP \u0026ldquo;4+1\u0026quot;视图模型\n视图 对应角色 关注 常用UML图 逻辑视图 最终用户 功能性需求 类图、对象图、状态图、协作图 实现视图（开发视图） 程序员 软件静态组织结构 包图、组件图 进程视图（过程视图） 系统集成人员 非功能性需求（性能、可用性） 活动图 部署视图（物理视图） 系统工程师 软件到硬件的映射 部署图 用例视图 所有视图的中心 场景驱动 用例图 1.3 软件能力成熟度模型 CMM：概念模型，框架刚性、解释弹性\nCMMI（5个成熟度等级）\n初始级 已管理级 已定义级 量化管理级（核心特征：过程性能可预测，与已定义级区别） 优化级 1.4 需求工程 软件需求3层次\n业务需求：组织机构或客户对系统的高层次目标 用户需求：用户使用产品必须完成的任务 功能需求：开发人员必须实现的软件功能 需求工程5阶段\n需求获取 需求分析 形成需求规格（文档化） 需求确认与验证 需求管理 SRS（软件需求规格说明书）\n包含：功能需求 + 非功能需求 + 约束 约束又分：设计约束 + 过程约束 批准的SRS是需求开发和需求管理之间的桥梁 需求管理活动\n变更控制 版本控制 需求跟踪 （注意：文档管理不属于需求管理活动） 需求跟踪\n目的：建立与维护\u0026quot;需求—设计—编程—测试\u0026quot;之间的一致性 两种方式：正向跟踪 + 逆向跟踪 = 双向跟踪 工具：需求跟踪矩阵 CCB（变更控制委员会）\n由项目所涉及的多方成员共同组成 决策机构，不是作业机构 通过评审决定项目能否变更，但不提出变更方案 需求获取6步骤\n开发高层的业务模型 定义项目范围和高层需求 识别用户角色和用户代表 获取具体的需求 确定目标系统的业务工作流 需求整理与总结 需求获取方法：用户面谈、需求专题讨论会、问卷调查、现场观察、原型化方法、头脑风暴法\n1.5 系统分析与设计 结构化方法（SASD）\n结构化分析（SA）\n主要手段：数据流图（DFD）、数据字典、结构化语言、判定表、判定树 DFD 4种基本元素：数据流、处理/加工、数据存储、外部项 建模步骤：明确目标→确定系统范围→建立顶层DFD→构建第一层DFD分解图→开发DFD层次结构图→检查确认 DFD规则：父图数据流必须在子图出现；一个处理至少一个输入流和一个输出流；一个存储必有流入流出；数据流至少一端是处理端 结构化设计（SD）\n自顶向下、逐步求精、模块化 概要设计：模块划分，确定功能、接口、调用关系 详细设计：每个模块的实现算法、局部数据结构 模块3基本属性：功能、逻辑、状态\n耦合类型（从低到高）\n耦合类型 描述 非直接耦合 两模块无直接关系 数据耦合 借助参数表传递简单数据 标记耦合 通过参数表传递记录等复杂信息 控制耦合 传递的信息中包含用于控制模块内部逻辑的信息 通信耦合 共享输入或输出 公共耦合 多个模块访问同一公共数据环境 内容耦合 直接访问另一个模块的内部数据（最高，最差） 内聚类型（从高到低）\n内聚类型 描述 功能内聚 各个部分协同完成单一功能，缺一不可（最高） 顺序内聚 处理元素相关，必须顺序执行 通信内聚 集中在一个数据结构区域上 过程内聚 处理元素相关，按特定次序执行 时间内聚 所包含任务必须在同一时间间隔内执行 逻辑内聚 完成逻辑上相关的一组任务 偶然内聚 完成一组无关系或松散关系的任务（最低） 设计原则：高内聚、低耦合\n结构化编程（SP）\n3种基本控制结构：顺序、分支、循环 通过这3种结构可构造任何单入口单出口程序 强调：自顶向下、逐步细化、清晰第一、效率第二 面向对象方法\nOOA（面向对象分析）\n模型5层次：主题层、对象类层、结构层、属性层、服务层 模型5活动：标识对象类、标识结构、定义主题、定义属性、定义服务 基本原则：抽象、封装、继承、分类、聚合、关联、消息通信、粒度控制、行为分析 5个基本步骤：确定对象和类、确定结构、确定主题、确定属性、确定方法 OOD（面向对象设计）\n类3种类型： 实体类：名词，永久性需要存储（如教师、学生） 控制类：控制用例工作（如登录验证） 边界类：封装用例内外流动的信息（如窗口、通信协议、接口） OOP（面向对象程序设计）\n基本特点：封装、继承、多态 继承4类：取代继承、包含继承、受限继承、特化继承 多态：同一操作作用于不同对象产生不同结果 数据持久化与ORM\n持久层（Persistence Layer）专注于实现数据持久化 对象/关系映射（ORM） 主流框架： Hibernate：全自动ORM，跨数据库平台 MyBatis/iBatis：半自动，手写SQL，可结合特定数据库优化 JDO（Java Data Object）：Java标准，支持关系数据库+普通文件+XML+对象数据库 软件重用2类型\n水平式重用：不同应用领域中的软件元素（如标准函数库） 垂直式重用：共性应用领域间的软部件（如区块链） 逆向工程\n通过分析已有程序，寻求比源代码更高级的抽象表现形式 设计恢复：逆向工程得出的设计，不一定抽象还原到原设计 重构：在同一抽象层级中转换系统描述 重构工程：对逆向工程形成的系统进行修改或重构生成的新版本 信息恢复4级：实现级 \u0026lt; 结构级 \u0026lt; 功能级 \u0026lt; 领域级（难度递增，工具支持递减） 1.6 软件测试 测试目的\n确认软件以正确方式做了用户期望的事情 尽量多地发现漏洞，但不能保证发现所有 测试分类\n分类维度 类型 程序执行状态 静态测试ST、动态测试DT 关注实现和内部结构 黑盒测试、白盒测试、灰盒测试 程序执行方式 人工测试MT、自动化测试AT 阶段划分 单元测试、集成测试、系统测试、验收测试 4阶段测试对比\n阶段 测试对象 实施者 方法 单元测试 模块 程序员自己 白盒静态（静态分析、代码审查）或自动化动态 集成测试 组装模块 测试人员 白盒+黑盒结合 系统测试 完整系统 测试人员 检查是否符合SRS 验收测试 完整系统 用户 确认系统满足用户需求 系统测试内容：功能测试、性能测试、健壮性测试、安全性测试\n1.7 净室软件工程（CSE） Cleanroom Software Engineering 在软件开发过程中强调在软件中建立正确性的需要 理论基础：函数理论 + 抽样理论 使用盒子结构规约进行分析和设计建模 强调将正确性验证（而不是测试）作为发现和消除错误的主要机制 缺点：太理论化、忽视测试、带有传统软件工程的弊端 1.8 基于构件的软件工程（CBSE） 构件5特征\n可组装型：所有外部交互通过公开定义的接口 可部署性：可作为独立实体在构件平台上运行 文档化：必须完全文档化 独立性：应独立，如需其他构件服务需显示声明 标准化：必须符合某种标准化的构件模型 主流构件模型\nWeb Services模型 Sun EJB模型 微软.NET模型 CBSE过程6步骤\n系统需求概览 识别候选构件 根据发现的构件修改需求 体系结构设计 构件定制与适配 组装构件创建系统 CBSE vs 传统软件开发\n早期需要完整需求（识别可复用构件） 早期阶段根据可利用的构件细化和修改需求 架构设计完成后可能需要修改构件 开发过程就是组装构件的过程（有时需要开发适配器） 架构设计阶段特别重要，决定和限制了可选构件的范围 构件组装3方式\n顺序组装 层次组装 叠加组装 接口不兼容3类：参数不兼容、操作不兼容、操作不完备\n解决：编写适配器构件 1.9 软件项目管理 软件进度管理6过程\n活动定义 活动排序 活动资源估计 活动历时估计 制定进度计划 进度控制 WBS（工作分解结构）\n把项目按原则分解为任务，任务再分解为工作 以可交付成果为导向 处于计划过程的中心 SCM（软件配置管理）\n标识、组织和控制修改的技术 目的：使错误降为最小并最有效提高生产效率 核心内容：版本控制 + 变更控制 SQA（软件质量保证）\n目的：使软件过程对管理人员可见 主要任务：SQA审计与评审、SQA报告、处理不符合问题 软件质量认证：ISO 9001 + CMM 风险管理\nBoehm：风险估计（辨识+分析+排序）+ 风险控制（计划+处理+监督） Charette：分析（辨识+估计+评价）+ 管理（计划+控制+监督） 2. 关键概念速查 概念 定义/说明 常见考点 瀑布模型 结构化开发方法使用 阶段不可并行 原型模型 解决需求难一次确定 抛弃型/演化型 螺旋模型 快速原型+瀑布模型 强调风险分析 极限编程XP 测试先行 敏捷方法 Scrum Sprint迭代+Product Backlog 侧重项目管理 FDD 首席程序员+类程序员 特征驱动开发 RUP 用例驱动+架构中心+迭代增量 4+1视图 4+1视图 逻辑+实现+进程+部署+用例 5种视图 CMMI 5级 初始/已管理/已定义/量化/优化 量化管理=可预测 SRS 软件需求规格说明书 功能+非功能+约束 CCB 变更控制委员会 决策机构非作业机构 数据流图DFD 4元素：数据流/处理/存储/外部项 父图子图平衡 耦合7类 非直接→数据→标记→控制→通信→公共→内容 低到高 内聚7类 功能→顺序→通信→过程→时间→逻辑→偶然 高到低 OOD 3类 实体类/控制类/边界类 学生/登录验证/窗口 ORM 对象关系映射 Hibernate+MyBatis+JDO 单元测试 程序员自己，白盒静态 模块级 CSE净室 正确性验证而非测试 盒子结构规约 CBSE 构件化软件工程 Web Services/EJB/.NET WBS 工作分解结构 以可交付成果为导向 SCM 软件配置管理 版本控制+变更控制 3. 典型例题 题目1：螺旋模型基础 题目：螺旋模型在（ ）的基础上扩展而成。 A．瀑布模型 B．原型模型 C．快速模型 D．面向对象模型\n答案：B\n解析：螺旋模型是在原型模型（快速原型）的基础上结合瀑布模型扩展而成，强调其他模型忽视的风险分析。\n题目2：敏捷方法识别 题目：（1）适用于程序开发人员在地域上分布很广的开发团队。（2）中，编程开发人员分成首席程序员和\u0026quot;类\u0026quot;程序员。 （1）A．水晶系列（Crystal）开发方法 B．开放式源码（Open Source）开发方法 C．Scrum开发方法 D．功用驱动开发方法（FDD） （2）A．自适应软件开发（ASD） B．极限编程（XP）开发方法 C．开放系统—过程开发方法（OpenUP） D．功用驱动开发方法（FDD）\n答案：B D\n解析：\n开放式源码项目特点是程序开发人员在地域上分布很广，一般敏捷方法都强调项目组成员在同一地点工作。 FDD（功用驱动开发方法）将编程开发人员分成首席程序员和\u0026quot;类\u0026quot;程序员两类，首席程序员是最有经验的开发人员。 题目3：需求管理活动 题目：需求管理是一个对系统需求变更、了解和控制的过程。以下活动中，（ ）不属于需求管理的主要活动。 A．文档管理 B．需求跟踪 C．版本控制 D．变更控制\n答案：A\n解析：需求管理的主要活动包括变更控制、版本控制、需求跟踪等。文档管理不属于需求管理的主要活动。\n题目4：结构化编程基本结构 题目：结构化程序设计采用自顶向下、逐步求精及模块化的程序设计方法，通过（ ）三种基本的控制结构可以构造出任何单入口单出口的程序。 A．顺序、选择和嵌套 B．顺序、分支和循环 C．分支、并发和循环 D．跳转、选择和并发\n答案：B\n解析：结构化程序设计通过顺序、分支（选择）和循环三种基本的控制结构可以构造出任何单入口单出口的程序。这三种结构是Dijkstra提出的结构化定理的核心。\n4. 高频考点 5大软件过程模型对比（5年12考）：瀑布/原型/螺旋/敏捷/RUP的特征与适用场景 4+1视图对应角色：逻辑-用户、实现-程序员、进程-集成人员、部署-工程师 CMMI 5级：初始→已管理→已定义→量化管理→优化（量化管理=可预测） 耦合7类型排序（从低到高）：非直接\u0026lt;数据\u0026lt;标记\u0026lt;控制\u0026lt;通信\u0026lt;公共\u0026lt;内容 内聚7类型排序（从高到低）：功能\u0026gt;顺序\u0026gt;通信\u0026gt;过程\u0026gt;时间\u0026gt;逻辑\u0026gt;偶然 设计原则：高内聚、低耦合 结构化编程3种基本结构：顺序+分支+循环 DFD 4基本元素：数据流+处理+数据存储+外部项 OOD 3类对象：实体类/控制类/边界类 ORM 3框架：Hibernate（全自动）+ MyBatis（半自动）+ JDO（Java标准） 软件测试4阶段：单元（程序员自己）→集成→系统→验收 净室软件工程CSE：正确性验证而非测试 CBSE 3种组装方式：顺序+层次+叠加 需求管理活动：变更控制+版本控制+需求跟踪（不含文档管理） CCB定位：决策机构不是作业机构 ","date":"2024-01-01T00:00:00Z","permalink":"/p/07-ruan-jian-gong-cheng/","title":"07-软件工程"},{"content":"08-数据库设计（基于第8小时） 软考-系统架构设计师 | 第2篇 架构设计专业知识 出题形式：单项选择题 + 案例分析题 | 分值占比：4-8 分 教材参考：第8章\n0. 考点分析 本小时主要学习数据库基础概念、关系数据库、数据库设计、应用程序与数据库交互、NoSQL数据库等内容。考察侧重概念知识。知识点会涉及单选题（约占2-5分）和案例题（25分）。\n作为一名合格的系统架构师，必须掌握数据库设计的基本概念和方法。系统架构设计师考试中的一些案例分析题会来自本小时的内容。\n1. 核心知识点 1.1 数据库基础概念 4大基础术语\n术语 定义 数据（Data） 描述事物的符号记录（文字、图形、图像、声音、语言） 数据库系统（DBS） 采用数据库技术，有组织、动态存储大量相关联数据的计算机系统 数据库（DB） 统一管理的、长期储存在计算机内的、有组织的相关数据的集合 数据库管理系统（DBMS） 数据库系统的核心软件，是相互关联的数据集合+访问这些数据的软件 DBMS分类3类\nRDBS（关系数据库系统） OODBS（面向对象的数据库系统） ORDBS（对象关系数据库系统） 3大发展阶段\n阶段 特点 缺点 人工管理 数据量少、不保存、无软件系统处理 应用程序与数据依赖性强、数据冗余 文件系统 数据可长期保留、不属于特定应用、文件组织多样化 数据冗余、不一致性、数据孤立 数据库系统 复杂数据模型、高数据独立性 — 数据模型3要素\n数据结构 数据操作 数据的约束条件 数据约束3类\n实体完整性：实体的主属性不能取空值 参照完整性：外键参照的完整性（要么为空，要么出现在被参照关系中） 用户定义完整性：具体应用所对应的数据约束（如软考成绩0-75） DBMS主要功能\n数据定义 数据库操作 数据库运行管理 数据组织、存储和管理 数据库的建立和维护 1.2 三级模式两级映像 三级模式\n模式 别名 描述 概念模式 — 全体数据的逻辑结构和特征，所有用户的公共数据视图 外模式 子模式/用户模式 用户看到或使用的那部分数据的逻辑结构 内模式 — 数据物理结构和存储方式的描述 两级映像\n映像 独立性 概念模式/内模式映像 物理独立性：数据物理存储改变，应用程序不变 外模式/概念模式映像 逻辑独立性：数据逻辑结构改变，应用程序不变 1.3 关系数据库基本概念 术语 定义 属性（Attribute） 描述事物的特征 域（Domain） 每个属性的取值范围 目/度（Degree） 关系中属性的个数 候选码（Candidate Key） 能唯一标识一个元组的属性或属性组 主码（Primary Key） 从多个候选码中选定一个 主属性 包含在任何候选码中的属性 外码（Foreign Key） 不是本关系码但是其他关系码的属性 全码（All-key） 所有属性组都是候选码 1.4 关系代数运算 4类运算符\n集合运算符 专门的关系运算符 算术比较符 逻辑运算符 考试重点：集合运算符 + 专门的关系运算符\n集合运算符\n运算符 含义 解释 ∪ 并 属于R或属于S的元组 － 差 属于R但不属于S的元组 ∩ 交 属于R同时又属于S的元组 × 笛卡尔积 n+m列，K1×K2个元组 专门的关系运算符\n运算符 含义 解释 σ 选择 取得关系R中符合条件的行 π 投影 取得关系R中符合条件的列 ⋈ 连接 等值连接/自然连接（特殊等值连接，去重） ÷ 除 给定R(X,Y)和S(Y,Z)，结果P(X) 外连接（扩展运算）\n运算符 含义 左外连接 ⟕ 保留左侧关系所有不匹配元组，用null填充右侧属性 右外连接 ⟖ 保留右侧关系所有不匹配元组，用null填充左侧属性 完全外连接 ⟗ 完成左外连接和右外连接的操作 1.5 函数依赖 类型 定义 函数依赖 X→Y：对任意元组u,v，u[X]=v[X] ⇒ u[Y]=v[Y] 平凡函数依赖 X→Y，但Y⊆X 非平凡函数依赖 X→Y，Y⊄X 完全函数依赖 X→Y，X的任何真子集都不能函数决定Y 部分函数依赖 X→Y，但X的某个真子集也能函数决定Y 传递依赖 X→Y，Y→Z，且Y不函数决定X，则Z传递依赖于X Armstrong公理系统3条推理规则\nA1 自反律：若Y⊆X⊆U，则X→Y A2 增广律：若X→Y，且Z⊆U，则XZ→YZ A3 传递律：若X→Y，Y→Z，则X→Z 3条导出规则\n合并规则：X→Y，X→Z ⇒ X→YZ 伪传递规则：X→Y，WY→Z ⇒ XW→Z 分解规则：X→Y，Z⊆Y ⇒ X→Z 1.6 关系数据库规范化（范式） 4大范式（1NF→BCNF）\n范式 条件 1NF 每个分量是不可再分的数据项 2NF 1NF + 每一个非主属性完全依赖主码 3NF 2NF + 消除非主属性对主码的传递函数依赖 BCNF 1NF + 每个属性都不传递依赖于R的候选码 关系：BCNF ⊂ 3NF ⊂ 2NF ⊂ 1NF\n候选码判断方法\n看哪个属性只在依赖集F的\u0026quot;→\u0026ldquo;左边出现过，该关系的候选码必定包含那个属性 例：F={A1→A2, A1→A3, A3→A4, A1A5→A6}，只在左边出现的是A1和A5，所以候选码为A1A5 1.7 事务管理（ACID） 特性 含义 原子性（Atomicity） 事务在数据库中要么全做，要么全都不做 一致性（Consistency） 事务执行使数据库从一个一致性状态变到另一个一致性状态 隔离性（Isolation） 一个事务的执行不能被其他事务干扰 持久性（Durability） 事务一旦提交，对数据库的改变必须是永久的 SQL事务语句\nBEGIN TRANSACTION：事务开始 COMMIT：事务提交（写入磁盘） ROLL BACK：事务回滚 1.8 并发控制 两种封锁类型\n封锁 说明 X封锁（排他型） 事务T对数据A实现X封锁，只允许T读和修改，其他事务必须等T解除X封锁 S封锁（共享型） 事务T对数据A实现S封锁，允许T读但不能修改，所有S封锁解除前不允许任何X封锁 1.9 数据库备份与恢复 4种备份分类\n维度 分类 特点 是否允许并发 静态备份 简单，但降低数据库可用性 动态备份 备份和用户事务可并发，但后援副本可能不保证正确 备份范围 海量备份 每次备份全部数据库 增量备份 只备份上次更新过的数据（适合大数据量频繁事务） 4类故障\n事务故障 → UNDO + REDO 系统故障 介质故障 → 装入副本+日志执行撤销/重做 计算机病毒 1.10 数据库设计步骤 6步骤\n用户需求分析 概念结构设计 逻辑结构设计 物理结构设计 应用程序设计 运行维护 E-R图3要素\n实体（型）：矩形框 属性：椭圆形 实体之间联系：菱形框 E-R图合并时需解决3类冲突\n属性冲突 命名冲突 结构冲突 1.11 商业智能（BI） BI = 数据仓库 + OLAP + 数据挖掘\n数据仓库4大关键特征\n面向主题 集成的 非易失的 时变的 传统数据库 vs 数据仓库\n比较 传统数据库 数据仓库 数据内容 当前值 历史的、归档的、归纳的、计算的数据 数据目标 面向业务操作 面向主体域，分析应用 数据特性 动态变化、可更新 静态、不能直接更新 使用频率 高 低 OLTP vs OLAP\n项目 OLTP OLAP 用户 操作人员、低层管理人员 决策人员、高级管理人员 功能 日常操作处理 分析决策 DB设计 面向应用 面向主题 数据 当前、细节、二维 历史、聚集、多维 存取 读/写数十条 读上百万条 工作单位 简单事务 复杂查询 DB大小 100MB-GB级 100GB-TB级 1.12 应用程序与数据库交互 4种方式\n方式 说明 库函数级别（如OCI） 最底层API，强依赖特定DB，学习难度大 嵌入式SQL（Embeded SQL） SQL直接写入高级程序语言源代码 通用数据接口标准（ODBC） 解决异构数据库共享，统一处理关系数据库 ORM 对象关系映射，实现面向对象语言与不同类型系统数据的转换 ODBC相关接口：DAO、RDO、ADO、JDBC\nORM框架对比\nHibernate：全自动ORM，强大复杂笨重，学习成本高 MyBatis：半自动框架 JPA：Java自带框架 1.13 NoSQL数据库 4种类型\n类型 特点 代表产品 列式存储数据库 应对分布式海量数据，键指向多列 Cassandra、HBase、Riak 键值对存储数据库 简单、易部署，但部分值查询更新效率低 Redis、Voldemort、Oracle BDB 文档型数据库 处理网页等复杂数据时比键值对查询效率高 CouchDB、MongoDB、SequoiaDB 图数据库 适合社交网络、生物信息网络等图建模数据 Neo4J、InfoGrid、Infinite Graph NoSQL 5大特征：易扩展、大数据量、高性能、灵活的数据模型、高可用\nNoSQL 4层框架（从下至上）\n数据持久层（Data Persistence） 数据分布层（Data Distribution Model） 数据逻辑模型层（Data Logical Model） 接口层（Interface） NoSQL适用场景\n数据模型比较简单 需灵活性更强的IT系统 对数据库性能要求较高 不需要高度的数据一致性 1.14 分布式数据库 6层体系结构（自顶向下）\n全局视图（全局外模式）：用户视图，全局概念模式的子集 全局概念模式：数据的整体逻辑结构 分片模式：关系模式分解为数据片 分配模式：定义数据片段的存放节点（分布式本质） 局部概念模式：局部数据库的概念模式 局部内模式：局部数据库的内模式 分布式数据库4大特点\n共享性：不同节点数据共享 自治性：每个节点独立管理本地数据 可用性：某场地故障可使用其他副本 分布性：数据分布在不同场地 分布透明性3层次（由高到低）\n分片透明性：只对全局关系操作，不必考虑分片（最高） 位置透明性：了解分片但不必了解存储场地 局部数据模型透明性（逻辑透明）：了解分片和存储场地但不必了解局部数据模型 1.15 数据库优化技术 集中式数据库反规范化设计5种\n增加冗余列（避免连接操作） 增加派生列（减少计算量） 重新组表（减少连接） 水平分割表（按记录分割） 垂直分割表（按列分割，主键+部分列/主键+其他列） 反规范化优缺点\n优点：避免连接操作，提高性能 缺点：数据重复存储，浪费磁盘空间，产生数据不一致 解决：触发器、事务机制、应用保证、批处理脚本 分布式数据库优化4技术\n主从复制（3种同步模式：全同步、半同步、异步） 读写分离 分表（垂直切分/水平切分） 分库（按业务模块分开） binlog 3种模式\n基于SQL语句的复制（SBR）：binlog日志量少，可能造成主从不一致（如time函数） 基于行的复制（RBR）：不记录SQL，记录更新前后数据，可保证主从一致 混合复制（MBR）：以上两种的混合，自动选择 1.16 分布式缓存Redis Redis定位\n分布式缓存技术 也是键值对数据库类型（NoSQL） 基于内存的读写，比磁盘数据库性能高 key-value形式保存 5种核心数据类型\n数据类型 存储值 适用场景 案例 string 字符串/整数/浮点 缓存层、计数器 视频播放量、文章浏览量 hash 键值对无序散列表 描述用户信息，节省空间 用户信息存储 set 无序集合，值不重复 去重、抽奖、初始化用户池 共同好友、标签管理 list 双向链表，模拟栈/队列 顺序访问 回复评论、点赞、粉丝列表 zset 有序集合，每个元素有分数 排行榜 当天最热前10名、热搜榜 业务功能 → 数据类型对应关系\nstring → 计数器（用户帖子的评论计数器） list → 粉丝列表、好友信息发布/订阅 set → 标签管理、共同好友 hash → 用户信息结构化存储 zset → 排名（最热前10名、热搜榜） 读写数据步骤\n读：①根据key读缓存 → ②成功直接返回 → ③若key不在缓存则读数据库 → ④成功后写缓存 → ⑤成功返回 写：①根据key值写数据库 → ②成功后更新缓存key值 → ③成功返回 2种过期策略\n定期删除：随机抽取设置了过期时间的key 惰性删除：查询时检测key是否过期，过期则删除 6种淘汰机制\nvolatile-lru / volatile-lfu / volatile-random / volatile-ttl allkeys-lru / allkeys-lfu / allkeys-random 2种持久化方式对比\n项目 RDB内存快照 AOF日志 原理 数据集快照写入磁盘 持续保存Redis更新命令 磁盘刷新频率 低 高 文件大小 小 大 数据恢复效率 高 低 数据安全 低 高 3大缓存异常问题\n异常 原因 解决方案 缓存穿透 请求访问了不存在的key，绕过缓存访问DB ①限制IP访问次数 ②布隆过滤器 ③预热Redis ④DB中也没有的key在Redis中设为null 缓存雪崩 大量key同时过期，请求直接访问DB ①主从复制+cluster集群 ②过期时间加随机值 ③服务降级/熔断/限流 缓存击穿 少量热点key过期失效，请求直接访问DB ①设置较长过期时间/永久有效 ②分布式锁控制DB访问流量 Redis集群3方式\n主从复制集群 哨兵集群 Cluster集群 集群切片3方式\n客户端分片 代理分片 服务器端分片 2. 关键概念速查 概念 定义/说明 常见考点 3级模式 外模式/概念模式/内模式 对应视图层/逻辑层/物理层 2级映像 概念↔内模式=物理独立；外模式↔概念=逻辑独立 独立性识别 关系代数 并/差/交/笛卡尔积/选择/投影/连接/除 集合运算vs专门关系运算 1NF 分量不可再分 最基础范式 2NF 1NF+非主属性完全依赖主码 消除部分函数依赖 3NF 2NF+消除非主属性对主码的传递依赖 消除传递依赖 BCNF 1NF+每个属性不传递依赖候选码 最高范式（教材重点） ACID 原子性/一致性/隔离性/持久性 事务4特性 X封锁 排他型，只允许一个事务独锁 写锁 S封锁 共享型，可读不可修改 读锁 E-R图 矩形=实体，椭圆=属性，菱形=联系 概念结构设计 数据仓库 面向主题/集成/非易失/时变 4大特征 OLTP 联机事务处理，操作型 日常操作 OLAP 联机分析处理，分析型 决策支持 列式存储 应对分布式海量数据 Cassandra/HBase 文档型 处理复杂数据查询效率高 MongoDB 图数据库 适合图建模数据 Neo4J 分片透明性 不必考虑分片 最高级分布透明 位置透明性 了解分片，不必了解场地 中级 Redis string 字符串/数字 计数器、缓存 Redis list 双向链表 粉丝列表、评论 Redis set 无序集合不重复 共同好友、标签 Redis hash 键值对散列表 用户信息 Redis zset 有序集合带分数 排行榜 缓存穿透 不存在key访问DB 布隆过滤器 缓存雪崩 大量key同时过期 过期时间加随机值 缓存击穿 热点key过期 分布式锁 RDB 内存快照 恢复快但安全低 AOF 更新命令日志 恢复慢但安全高 3. 典型例题 题目1：数据库系统 vs 文件系统 题目：数据库系统与文件系统的区别不包括（ ）。 A．对应用程序的高度独立性 B．数据的充分共享性 C．文件组织形式的多样化 D．操作方便性\n答案：C\n解析：数据库的特点包括对应用程序的高度独立性、数据的充分共享性、操作方便性。文件组织形式的多样化是文件系统的特点，不是数据库系统的特点（数据库的数据按同一种数据结构存储）。\n题目2：DBMS功能 题目：（ ）描述的是DBMS向用户提供数据操纵语言，实现对数据库中数据的基本操作，如检索、插入、修改和删除。 A．数据定义 B．数据库操作 C．数据库运行管理 D．数据组织、存储与管理\n答案：B\n解析：DBMS功能主要包括数据定义、数据库操作、数据库运行管理、数据组织存储与管理、数据库的建立和维护。数据库操作是DBMS向用户提供数据操纵语言（DML），实现对数据库数据的基本操作（检索、插入、修改、删除）。\n题目3：范式判断 题目：给定关系模式R(U,F)，其中：属性集U={A1,A2,A3,A4,A5,A6}；函数依赖集F={A1→A2, A1→A3, A3→A4, A1A5→A6}。关系模式R的候选码为（1），由于R存在非主属性对码的部分函数依赖，所以R属于（2）。 （1）A．A1A3 B．A1A4 C．A1A5 D．A1A6 （2）A．1NF B．2NF C．3NF D．BCNF\n答案：C A\n解析：判断候选码：A1和A5都只在依赖集F的\u0026rdquo;→\u0026ldquo;左边出现过，所以候选码是A1A5。\u0026ldquo;R存在非主属性对码的部分函数依赖\u0026quot;说明不满足2NF要求（2NF要求非主属性完全依赖主码），因此R只能是1NF。\n题目4：Redis数据类型应用 题目：某互联网文化发展公司因业务发展，需要建立网上社区平台，为用户提供对网络文化产品进行评论交流的平台。功能包括：（a）用户帖子的评论计数器；（b）支持粉丝列表功能；（c）支持标签管理；（d）支持共同好友功能等；（e）提供排名功能，如当天最热前10名帖子排名；（f）用户信息的结构化存储；（g）提供好友信息的发布/订阅功能。请选择Redis数据类型填空。\nstring → （1） list → （2） set → （3） hash → （4） zset → （5） 答案：\n（1）（a） 计数器场景 （2）（b）（g） 粉丝列表+发布/订阅 （3）（c）（d） 标签+共同好友（去重） （4）（f） 用户信息结构化 （5）（e） 排行榜 解析：string适合计数器，list双向链表模拟粉丝列表/订阅，set无序去重适合共同好友/标签，hash结构化适合用户信息，zset有序集合适合排行榜。\n4. 高频考点 ACID 4特性：原子性+一致性+隔离性+持久性（5年8考） 范式判断：1NF→2NF→3NF→BCNF的递进条件（部分依赖→传递依赖） 候选码判断方法：只在F的\u0026rdquo;→\u0026ldquo;左边出现过的属性必在候选码中 关系代数运算：选择（行）vs 投影（列）的区别，外连接3种 三级模式两级映像：物理独立性=概念↔内模式；逻辑独立性=外模式↔概念 数据完整性3类：实体完整性（主属性非空）+ 参照完整性（外键）+ 用户定义完整性 OLTP vs OLAP：操作型vs分析型，10个对比维度 NoSQL 4类型：列式/键值/文档/图，适用场景不同 Redis 5种数据类型应用场景：string(计数)/hash(用户)/set(去重)/list(队列)/zset(排行榜) 缓存三大异常：穿透（不存在key）/雪崩（大量key同时过期）/击穿（热点key过期） RDB vs AOF持久化：快照vs日志，恢复效率vs数据安全 反规范化5种方法：冗余列/派生列/重组表/水平分割/垂直分割 分布式数据库6层结构：全局视图→全局概念→分片→分配→局部概念→局部内模式 分布透明性3层次：分片\u0026gt;位置\u0026gt;局部数据模型（从高到低） binlog 3种模式：SQL语句/行/混合，各有优缺点 ","date":"2024-01-01T00:00:00Z","permalink":"/p/08-shu-ju-ku-she-ji/","title":"08-数据库设计"},{"content":"09-软件架构概念（基于第9小时） 软考-系统架构设计师 | 第3篇 架构设计高级知识 出题形式：单项选择题 + 下午案例分析题 分值占比：约 3-5 分（选择），案例题常涉及\n0. 考点分析 本小时是软考系统架构设计师考试最核心、最常考的基础章节。主要内容涵盖：\n软件架构定义与重要性 软件架构设计与生命周期 基于架构的软件开发方法（ABSD / ABSDM） 软件架构风格（核心重点） 软件架构复用 特定领域软件架构（DSSA） 考试特点：\n选择题必考（架构风格、ADL、视图模型等概念） 案例分析题高频考点（架构风格选择、复用策略） 论文题素材来源（ABSDM 六过程、风格选择） 1. 核心知识点 1.1 软件架构定义 定义：系统的一个或多个结构，包括构件（程序模块/类/中间件）、构件的外部可见属性及其相互关系 架构设计包括：数据库设计 + 软件结构设计 关注点：通过多种视图全面描述 1.2 软件架构与生命周期 阶段 作用和意义 需求分析阶段 有利于各阶段参与者的交流，易于维护可追踪性 设计阶段 关注的最早和最多的阶段 实现阶段 有效实现从架构设计向实现的转换 构件组装阶段 可复用构件组装提高实现效率 部署阶段 组织和展示部署软硬件架构，评估部署方案 后开发阶段 主要围绕维护、演化、复用 设计阶段重点：\n组成 SA 模型的基本概念（构件和连接子建模） 体系结构描述语言 ADL：Unicon、Rapide、Darwin、Wright、C2SADL、Acme、XADLOL、XYZ/ADL、ABC/ADL 多视图模型：4+1 模型、Hofmesiter 的 4 视图模型、CMU-Sei 的 Views and Beyond 模型 视图标准：IEEE 1471-2000、RM-ODP、UML、IBM Zachman 部署阶段两大作用：\n提供高层体系结构视图描述部署阶段的软硬件模型 基于架构模型分析部署方案的质量属性 后开发阶段研究方向：\n动态软件体系结构 体系结构恢复与重建（手工重建、工具支持、查询语言、数据挖掘） 1.3 软件架构重要性（8 大作用） 满足系统品质 使受益人达成一致目标 支持计划编制过程 对系统开发的指导性 有效管理复杂性 为复用奠定基础 降低维护费用 支持冲突分析 1.4 基于架构的软件开发方法（ABSD） 全称：Architecture-Based Software Design 驱动：构成体系结构的商业、质量和功能需求的组合驱动 三大基础： 功能的分解 通过选择体系结构风格来实现质量和商业需求 软件模板的使用 特点：自顶向下、递归细化、迭代每步定义清晰，降低随意性 1.5 ABSDM 开发模型（六子过程） 1 体系结构需求 → 体系结构设计 → 体系结构文档化 → 体系结构复审 → 体系结构实现 → 体系结构演化 各子过程要点：\n子过程 关键活动 体系结构需求 需求获取（来自质量目标/商业目标/开发人员商业目标）+ 标识构件（生成类图→分组→打包） 体系结构设计 提模型→映射构件→分析相互作用→设计评审（必须有外部人员） 体系结构文档化 输出：体系结构规格说明 + 测试质量设计说明书 体系结构复审 外部人员（用户代表、领域专家）参与，标识风险，可搭最小化系统评估 体系结构实现 分析与设计→构件实现→构件组装→系统测试 体系结构演化 需求变化归类→演化计划→构件变动→更新相互作用→组装测试→技术评审→演化后体系结构 1.6 软件架构风格（⭐⭐⭐ 核心重点） 风格定义要素：\n词汇表：包含构件和连接件 约束：定义构件和连接件的组合方式 数据流风格 风格 特点 批处理 每个处理步骤是独立程序，必须前一步结束后才能开始，数据以整体方式传递 管道-过滤器 系统分为序贯处理步骤，步骤间通过数据流连接，前一步输出是后一步输入 调用/返回风格 风格 特点 主程序/子程序 单线程控制，构件即主程序和子程序 面向对象 构件是对象（抽象数据类型的实例） 层次型 每层为上层服务并作为下层接口，仅相邻层间具有层接口 二层 C/S 客户应用程序 + 数据库服务器 + 网络；缺点：开发成本高、移植困难、维护升级难 三层 C/S 表示层 + 功能层 + 数据层（瘦客户端） B/S 浏览器 + Web 服务器 + 数据库服务器（三层应用结构实现） B/S 相对 C/S 的不足：动态页面支持弱、扩展能力差、安全难控、响应速度不足、数据交互性不强\n以数据为中心风格 风格 特点 仓库 中央数据结构（说明当前数据状态）+ 一组独立构件（对中央数据操作） 黑板 问题求解模型，组织推理步骤、控制状态数据和问题求解知识；典型应用：信号处理（语音识别、模式识别） 虚拟机风格 风格 特点 解释器 构建虚拟机弥合程序语义与硬件语义差异；缺点是执行效率较低；典型：专家系统 规则系统 知识库 + 规则解释器 + 规则/数据选择器 + 工作内存 独立构件风格 进程通信：构件是独立过程，连接件是消息传递 事件系统：构件不直接调用过程，而是触发或广播一个或多个事件 C2 风格 通过连接件连接构件或构件组 构件与构件之间无直接连接 1.7 软件架构复用 维度 要点 复用类型 机会复用（开发中发现可复用就复用） / 系统复用（开发前规划决定复用） 复用原因 减少开发工作/时间、降低成本、提高生产力、提高产品质量、更好互操作性 可复用资产 需求、架构设计、元素、建模分析、测试、项目规划、过程+方法+工具、人员、样本系统、缺陷消除 复用形式 函数复用、库复用、面向对象中的类/接口/包复用 复用基本过程 构建/获取可复用资产→管理可复用资产→使用可复用资产 1.8 特定领域软件架构（DSSA） 维度 要点 定义 特定应用领域中为一组应用提供组织结构参考的标准软件体系结构 特征 领域性、普遍性、抽象性、可复用性 三大基本活动 领域分析、领域设计、领域实现 参与人员 领域专家、领域分析师、领域设计人员、领域实现人员 三层系统模型 ① 领域开发环境 ② 领域特定应用开发环境（应用工程师在此工作） ③ 应用执行环境 建立过程（5 阶段） ① 定义领域范围 ② 定义领域特定元素 ③ 定义领域特定设计和实现约束 ④ 定义领域模型和体系结构 ⑤ 产生、搜集可重用的单元 2. 关键概念速查 概念 定义/说明 常见考点 软件架构 构件 + 外部可见属性 + 相互关系 概念辨析 ABSD 基于架构的软件设计方法 方法论三基础 ABSDM ABSD 的六子过程开发模型 六过程名称与顺序 架构风格 描述特定领域中系统组织方式的惯用模式（词汇表 + 约束） 风格三要素（约束） 批处理 数据必须整体传递，串行无并发 与管道-过滤器区别 管道-过滤器 数据流式，步骤间通过数据流连接 Unix Shell 是经典例子 二层 C/S 客户应用 + 数据库服务器 缺点：维护升级难 三层 C/S 表示层 + 功能层 + 数据层 瘦客户端 B/S 浏览器 + Web 服务器 + 数据库 相对 C/S 的不足 仓库风格 中央数据 + 独立构件 数据为中心 黑板风格 知识源 + 黑板 + 控制 信号处理应用 解释器风格 虚拟机，执行效率低 专家系统 规则系统风格 知识库 + 规则解释器 + 工作内存 包含要素 事件系统风格 触发或广播事件，不直接调用 与调用-返回区别 C2 风格 通过连接件连接，构件间无直接连接 关键特征 ADL 体系结构描述语言，关注构件间互联机制（连接子） 与建模语言区别 4+1 视图 多视图模型代表 视图名称 DSSA 特定领域软件架构 三大活动、特征、参与人员 机会复用 开发中发现可复用就复用 vs 系统复用 体系结构恢复 手工/工具/查询语言/数据挖掘 四种方法 3. 典型例题 例题 1（架构风格定义） 题目：软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式。架构风格定义了一类架构所共有的特征，主要包括架构定义、架构词汇表和架构（ ）。\nA. 描述 B. 组织 C. 约束 D. 接口 答案：C\n解析：软件架构风格三要素：架构定义、架构词汇表、架构约束。约束定义构件和连接件的组合方式。\n例题 2（软件架构作用） 题目：以下叙述中，（ ）不是软件架构的主要作用。\nA. 在设计变更相对容易的阶段，考虑系统结构的可选方案 B. 便于技术人员与非技术人员就软件设计进行交互 C. 展现软件的结构、属性与内部交互关系 D. 表达系统是否满足用户的功能性需求 答案：D\n解析：软件架构与用户的功能性需求没有直接的对应关系。功能性需求由需求分析决定，架构关注质量属性和非功能特性。\n例题 3（DSSA 三层模型） 题目：DSSA 通常是一个具有三个层次的系统模型，包括（1）环境、领域特定应用开发环境和应用执行环境，其中（2）主要在领域特定应用开发环境中工作。\n（1）A. 领域需求 B. 领域开发 C. 领域执行 D. 领域应用 （2）A. 操作员 B. 领域架构师 C. 应用工程师 D. 程序员\n答案：B（领域开发环境）、C（应用工程师）\n解析：DSSA 三层为：① 领域开发环境 ② 领域特定应用开发环境（应用工程师在此工作） ③ 应用执行环境。\n例题 4（ABSDM 过程） 题目：在 ABSDM 模型中，把整个基于体系结构的软件开发过程划分为六个子过程，正确的顺序是：\nA. 需求→设计→实现→文档化→复审→演化 B. 需求→设计→文档化→复审→实现→演化 C. 设计→需求→文档化→复审→实现→演化 D. 需求→设计→复审→文档化→实现→演化 答案：B\n解析：ABSDM 六过程顺序：需求→设计→文档化→复审→实现→演化。复审必须在文档化之后、实现之前。\n4. 高频考点 4.1 必须记住的核心要点 架构风格三要素：架构定义、词汇表、约束（必考） ABSDM 六过程顺序：需求→设计→文档化→复审→实现→演化（必考） DSSA 三层模型 + 人员对应：领域开发环境、领域特定应用开发环境（应用工程师）、应用执行环境 C2 风格关键特征：连接件连接、构件间无直接连接 黑板风格典型应用：信号处理（语音识别、模式识别） 解释器风格缺点：执行效率低 ADL 关注点：构件间互联机制（连接子） 常用多视图模型：4+1、4 视图、Views and Beyond 视图标准：IEEE 1471-2000、RM-ODP、UML、Zachman 后开发阶段研究方向：动态软件体系结构、体系结构恢复与重建 4.2 易混淆对比 对比项 区别 批处理 vs 管道-过滤器 批处理是整体传递，管道是流式处理 二层 C/S vs 三层 C/S 二层无功能层，三层分表示/功能/数据层 C/S vs B/S B/S 浏览器作为客户端，跨平台但交互性差 仓库 vs 黑板 仓库是数据存储，黑板是问题求解（带控制） 解释器 vs 规则系统 解释器是通用虚拟机，规则系统包含知识库和工作内存 机会复用 vs 系统复用 机会是开发中发现，系统是开发前规划 进程通信 vs 事件系统 进程通信是消息传递，事件系统是广播/触发 ","date":"2024-01-01T00:00:00Z","permalink":"/p/09-ruan-jian-jia-gou-gai-nian/","title":"09-软件架构概念"},{"content":"10-系统质量属性与架构评估（基于第10小时） 软考-系统架构设计师 | 第3篇 架构设计高级知识 出题形式：单项选择题 + 下午案例分析题 分值占比：约 8-15 分（选择），案例分析 25 分\n0. 考点分析 本小时是软考分值最高、案例题最常考的章节之一。涵盖三大主题：\n软件系统质量属性（开发期 + 运行期） 系统架构评估（方法、ATAM/SAAM 对比） 质量属性场景描述 考试特点：\n选择题 8-15 分（概念必考） 案例分析题核心（ATAM 评估、效用树、风险/敏感点/权衡点识别） 论文题素材来源（架构评估方法、ATAM 实践） 1. 核心知识点 1.1 软件系统质量属性（开发期 + 运行期） 开发期质量属性 属性 作用及要点 易理解性 指设计被开发人员理解的难易程度 可扩展性 软件因适应新需求/需求变化而增加新功能的能力，也称灵活性 可重用性 重用软件系统或某一部分的难易程度 可测试性 对软件测试以证明其满足需求规范的难易程度 可维护性 当需要修改缺陷、增加功能、提高质量属性时，识别修改点并实施修改的难易程度 可移植性 将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度 运行期质量属性 属性 作用及要点 性能 软件系统及时提供相应服务的能力（速度、吞吐量、容量） 安全性 软件系统同时兼顾向合法用户提供服务，以及阻止非授权使用的能力 可伸缩性 当用户数和数据量增加时，软件系统维持高服务质量的能力 互操作性 软件系统与其他系统交换数据和相互调用服务的难易程度 可靠性 软件系统在一定时间内持续无故障运行的能力 可用性 系统在一定时间内正常工作的时间所占比例 鲁棒性 软件系统在非正常情况（非法操作、软硬件故障）下仍正常运行的能力（也称健壮性/容错性） 1.2 面向架构评估的质量属性 评估关注的核心属性：\n类别 属性 关键点 性能 性能 效率指标：处理任务所需时间或单位时间内的处理量 可靠性 容错 出现错误后仍能保证系统正确运行，且自行修正错误 健壮性 错误不对系统产生影响，按既定程序忽略错误 可用性 正常运行的时间比例 安全性 系统向合法用户提供服务并阻止非法用户的能力 可维护性 可维护性 局部修复使故障对架构的负面影响最小化 可修改性 可扩展性 因松散耦合更易实现新特性/功能，不影响架构 结构重组 不影响主体进行的灵活配置 可移植性 适用于多样的环境（硬件平台、语言、操作系统等） 其他 功能性 需求的满足程度 可变性 总体架构可变 互操作性 通过可视化或接口方式提供更好的交互操作体验 1.3 提升质量属性的策略（⭐⭐⭐ 案例分析重点） 可用性策略 错误检测：心跳、Ping/Echo、异常 错误恢复：表决、主动冗余、被动冗余、重新同步、内测、检查点/回滚 错误避免：服务下线、事务、进程监控器 性能策略 资源的需求：减少处理时间对资源的占用、减少处理事件数量、控制资源使用 资源管理：并发机制、增加资源 资源仲裁：先来先服务、固定优先级、动态优先级、静态调度 可修改性策略 局部化修改：高内聚低耦合、预测变更、使模块通用 防止连锁反应：信息隐藏、维持现有接口、限制通信路径、使用中介 推迟绑定时间：运行时注册、多态、配置文件 安全性策略 抵抗攻击：用户身份验证、用户授权、维护数据机密性与完整性、限制暴露、限制访问 检测攻击：入侵检测系统 从攻击中恢复：恢复状态、识别攻击者 1.4 质量属性场景描述（6 要素） 要素 说明 刺激源（Source） 某个生成该刺激的实体（人、计算机系统或任何其他刺激器） 刺激（Stimulus） 指当刺激到达系统时需要考虑的条件 环境（Environment） 该刺激在某些条件内发生（系统可能处于过载、运行等情况） 制品（Artifact） 某个制品被激励，可能是整个系统，也可能是系统的一部分 响应（Response） 在激励到达后所采取的行动 响应度量（Measurement） 当响应发生时，应当能够以某种方式对其进行度量 1.5 系统架构评估方法分类 方法 特点 缺点 基于调查问卷或检查表 简单易行 很大程度上依赖评估人员的主观判断 基于场景 应用在 ATAM 和 SAAM 中 场景选择影响结果 基于度量 建立质量属性和度量之间的映射 难以建立映射原则 基于度量的步骤：\n建立质量属性和度量之间的映射原则 在软件文档中获取度量信息 分析推导系统质量属性 1.6 架构评估重要概念（⭐⭐⭐ 必考） 概念 定义 敏感点 实现质量目标时应注意的点，是一个或多个构件的特性 权衡点 影响多个质量属性的敏感点 风险承担者/利益相关人 影响体系结构或被体系结构影响的群体 场景 确定架构质量评估目标的交互机制（刺激 + 环境 + 影响） 风险点 存在问题的架构设计决策，可能导致问题 非风险点 良好的架构设计决策 记忆口诀：\n风险点 = 有问题 非风险 = 良好 敏感点 = 单个构件特性 权衡点 = 影响多个质量属性的敏感点 1.7 SAAM 评估方法 全称：Software Architecture Analysis Method 提出：1983 年，卡耐基梅隆大学软件工程研究所 Kazman 等人 特点：最早形成文档并得到广泛应用的非功能质量属性架构分析方法 输入：问题描述、需求说明、架构描述 过程：场景开发 → 架构描述 → 单个场景评估 → 场景交互 → 总体评估 特定目标：通过程序文档验证体系结构，注重发现潜在问题，可用于单系统评价或多系统比较 主要质量属性：可修改性是主要分析内容 架构描述：围绕功能、结构和分配描述 1.8 ATAM 评估方法（⭐⭐⭐ 案例题核心） 全称：Architecture Tradeoff Analysis Method（架构权衡分析法） 特点：系统开发之前，针对性能、可用性、安全性和可修改性等质量属性进行评价和折中 现代 ATAM：采用效用树对质量属性进行分类和优先级排序 传统 ATAM 四活动阶段 需求收集 架构视图描述 属性模型构造和分析 架构决策与折中 现代 ATAM 评估实践四阶段 阶段 步骤 演示（Presentation） ① 介绍 ATAM ② 介绍业务驱动因素 ③ 介绍要评估的体系结构 调查和分析 ① 确定架构方法 ② 生成质量属性效用树 ③ 分析体系结构方法 测试 ① 头脑风暴和优先场景 ② 分析架构方法 报告 ATAM 提供评估期间收集的所有信息，呈现给利益相关者 分析体系结构方法的 4 个主要阶段：\n调查架构方法 创建分析问题 分析问题的答案 找出风险、非风险、敏感点和权衡点 1.9 SAAM 与 ATAM 对比（⭐ 案例分析重点） 项目 SAAM ATAM 特定目标 通过程序文档验证体系结构，注重发现潜在问题，可用于评价单系统或进行多系统比较 确定在多个质量属性之间折中的必要性 评估技术 场景技术 场景技术 + 启发式分析方法 质量属性 可修改性是主要分析内容 性能、可用性、安全性和可修改性 风险承担者 所有参与者 场景和需求收集过程中的相关人 架构描述 围绕功能、结构和分配描述 五个基本结构及其映射关系 方法活动 场景开发、体系结构描述、单个场景评估、场景交互和总体评估 场景和需求收集、体系结构视图和场景实现、属性模型构造和分析、折中 知识库可复用性 不涉及 有基于属性的体系模型，可复用 方法验证 空中交通管制系统、嵌入式音频系统、修正控制系统 仍处于研究中 1.10 其他评估方法 方法 特点 CBAM（成本效益分析法） 整理场景→对场景进行求精→确定场景的优先级→分配效用→架构策略涉及哪些质量属性及响应级别→使用内插法确定\u0026quot;期望的\u0026quot;质量属性响应级别的效用→计算各架构策略的总收益→根据受成本限制影响的 ROI 选择架构策略 SAEM 将软件架构看作最终产品以及涉及过程中的中间产品，从外部质量属性和内部质量属性阐述评估模型 SAABNet 辅助架构的定性评估，诊断软件问题可能原因，度量对象：架构属性、质量准则、质量因素 SACMM 软件架构修改的度量方法，基于内核定义差异度量准则计算两个软件架构之间的距离 SASAM 通过对预期架构和实际架构进行映射和比较来静态评估软件架构 ALRRA 软件架构可靠性风险评估方法，使用动态复杂度准则和动态耦合度准则 AHP 把定性分析和定量计算相结合，对各种决策因素进行处理 COSMIC+UML 针对不同表达方式的软件架构，采用统一的软件度量 COSMIC 方法 2. 关键概念速查 概念 定义/说明 常见考点 易理解性 设计被开发人员理解的难易程度 开发期属性 可维护性 识别修改点并实施修改的难易程度 开发期 vs 运行期辨析 性能 速度、吞吐量、容量 运行期核心属性 安全性 合法服务 + 阻止非授权 三大策略（抵抗/检测/恢复） 可用性 正常运行时间比例 三大策略（检测/恢复/避免） 鲁棒性 非正常情况仍正常运行（健壮性/容错性） vs 容错的区别 敏感点 一个或多个构件的特性 单个属性 权衡点 影响多个质量属性的敏感点 多个属性 风险点 存在问题的架构设计决策 vs 非风险 SAAM 1983 年 CMU 提出，最早的架构评估方法 主要分析可修改性 ATAM 架构权衡分析法 性能/可用性/安全性/可修改性 CBAM 成本效益分析法 基于 ROI 效用树 对质量属性进行分类和优先级排序 现代 ATAM 工具 质量属性场景 6 要素 刺激源/刺激/环境/制品/响应/响应度量 6 个不能漏 3. 典型例题 例题 1（风险/敏感/权衡点辨析） 题目：识别风险、非风险、敏感点和权衡点是进行软件架构评估的重要过程。\u0026ldquo;改变业务数据编码方式会对系统的性能和安全性产生影响\u0026quot;是对（1）的描述，\u0026ldquo;假设用户请求的频率为每秒 1 个，业务处理时间小于 30 毫秒，则将请求响应时间设定为 1 秒钟是可以接受的\u0026quot;是对（2）的描述。\n（1）A. 风险点 B. 非风险 C. 敏感点 D. 权衡点 （2）A. 风险点 B. 非风险 C. 敏感点 D. 权衡点\n答案：D（权衡点）、B（非风险）\n解析：\n改变业务数据编码方式同时影响性能和安全性两个属性→权衡点 请求频率 1/秒、业务时间 30ms、响应 1s 是良好的架构决策（无问题）→非风险 例题 2（效用树案例） 题目：某电子商务公司升级在线交易系统，需要构建质量属性效用树。题干描述中（a）-（m）各对应不同质量属性场景。\n已知：\n(a) 正常负载 0.5s 内响应 (b) 信用卡支付 99.999% 安全性 (d) 网络失效 2 分钟内发现并启用备用 (e) 高峰负载 10s 内完成支付 (h) 30 人·月添加事务中间件 (j) 主站点断电 3s 内重定向备用 (k) 用户信息数据库 99.999% 可用 (l) 4 人·月完成 Web 界面修改 答案：\n编号 质量属性 (1) 性能 (2) 可修改性 (3) (e) 高峰负载 10s 内完成 (4) (j) 主站点断电 3s 内重定向 (5) (l) Web 界面修改 4 人·月 (6) (k) 数据库 99.999% 可用 解析：效用树主要关注性能、可修改性、可用性、安全 4 个方面。\n例题 3（风险/敏感/权衡点识别） 题目：题干描述中，关于风险/敏感/权衡点的描述：\n(f) 系统拟采用新的加密算法，会提高安全性，但会降低性能 (g) 对交易请求处理时间的要求将影响系统数据传输协议和交易处理过程的设计 (i) 现有架构设计中的支付部分与第三方支付平台紧耦合，当系统需要支持新的支付平台时，会导致支付部分代码的修改，影响系统的可修改性 答案：\n(f) → 权衡点（同时影响安全性和性能） (g) → 敏感点（对处理时间的要求影响多个构件的设计） (i) → 风险（紧耦合导致修改困难，存在问题的架构决策） 例题 4（SAAM 与 ATAM 区别） 题目：以下关于 SAAM 和 ATAM 的描述中，错误的是：\nA. SAAM 是最早形成文档的架构分析方法 B. ATAM 主要分析性能、可用性、安全性和可修改性 C. SAAM 主要分析可修改性 D. ATAM 的质量属性评估比 SAAM 少 答案：D\n解析：ATAM 评估多个质量属性（性能/可用性/安全性/可修改性），SAAM 主要分析可修改性，ATAM 评估范围更广。\n4. 高频考点 4.1 必须记住的核心要点 质量属性分类： 开发期：易理解、可扩展、可重用、可测试、可维护、可移植 运行期：性能、安全性、可伸缩、互操作性、可靠性、可用性、鲁棒性 三大质量策略： 可用性：检测/恢复/避免 性能：资源需求/管理/仲裁 可修改性：局部化/防连锁/推迟绑定 安全性：抵抗/检测/恢复 场景 6 要素：刺激源/刺激/环境/制品/响应/响应度量 风险/敏感/权衡点： 风险 = 有问题 非风险 = 良好 敏感点 = 单个构件特性 权衡点 = 影响多个质量属性的敏感点 SAAM vs ATAM 关键区别： SAAM：1983 年、场景技术、可修改性、多系统比较 ATAM：性能/可用/安全/可修改、效用树、五个基本结构、可复用知识库 现代 ATAM 四阶段：演示→调查和分析→测试→报告 效用树关注 4 大属性：性能、可修改性、可用性、安全 4.2 易混淆对比 对比项 区别 敏感点 vs 权衡点 敏感点影响一个属性，权衡点影响多个属性 风险 vs 非风险 风险是有问题的决策，非风险是良好的决策 SAAM vs ATAM SAAM 主分析可修改性，ATAM 分析 4 大属性（含权衡） 容错 vs 健壮性 容错是错误后修正，健壮性是错误不影响系统 性能 vs 可伸缩性 性能是单次响应能力，可伸缩是负载增加时维持服务质量 可用性 vs 可靠性 可用性是时间比例，可靠性是无故障运行能力 可维护性 vs 可修改性 可维护性是修复缺陷的难易，可修改性是架构层面的修改难易 ","date":"2024-01-01T00:00:00Z","permalink":"/p/10-xi-tong-zhi-liang-shu-xing-yu-jia-gou-ping-gu/","title":"10-系统质量属性与架构评估"},{"content":"11-软件可靠性（基于第11小时） 软考-系统架构设计师 | 第3篇 架构设计高级知识 出题形式：单项选择题 + 论文题 分值占比：约 2-4 分（选择）\n0. 考点分析 本小时专注于软件可靠性，包括基本概念、建模、管理、设计、测试和评价。\n考试特点：\n选择题 2-3 分（概念 + 可靠性设计技术） 论文题高频素材（软件可靠性设计、容错技术、测试方法） 案例题偶尔涉及 1. 核心知识点 1.1 软件可靠性的定义 定义：在规定的时间内，软件不引起系统失效的概率 关键点： 该概率是系统输入和系统使用的函数 也是软件中存在的缺陷函数 系统输入将确定是否会遇到已存在的缺陷 1.2 软件可靠性的定量描述 软件的可靠性是在软件使用条件、在规定时间内、系统的输入/输出、系统使用等变量构成的数学表达式 度量指标： 可靠度 平均失效时间（MTTF） 故障强度（故障率） 1.3 可靠性的目标 软件可靠性是指用户对所使用的软件的性能满意程度的期望 度量：可靠度、平均失效时间、故障强度 1.4 可靠性测试的意义与目的 5 大意义：\n软件失效可能造成灾难性的后果 软件的失效在整个计算机系统失效中的比例较高 相比硬件可靠性技术，软件可靠性技术不成熟 软件可靠性问题会造成软件费用增长 系统对软件的依赖性强，对生产活动和社会生活影响日益增大 测试目的（教材图 11.3）：\n验证软件可靠性水平是否达到预期目标 评估、预测软件可靠性 发现软件中的缺陷 为可靠性建模提供数据 1.5 广义的可靠性测试与狭义的可靠性测试 维度 广义可靠性测试 狭义可靠性测试 定义 为最终评价软件系统可靠性而运用建模、统计、试验、分析和评价等一系列手段对软件系统实施的测试 为获取可靠性数据，按预先确定好的测试用例，在软件预期使用环境中，对软件实施的测试 范围 全面评价 单一执行 手段 建模+统计+试验+分析+评价 按测试用例执行 1.6 软件可靠性建模 影响软件可靠性的因素 运行环境 软件规模 软件的内部结构 软件的开发方法和开发环境 软件的可靠性投入 建模方法（10 种） 类别 方法 种子法 在软件中故意植入一些缺陷并估计 失效率类 基于失效率的模型 曲线拟合类 对历史数据进行曲线拟合 可靠性增长 跟踪软件随时间演变的可靠性增长 程序结构分析 基于代码结构分析 输入域分类 按输入空间分类 执行路径分析 基于代码执行路径 非齐次泊松过程 NHPP 模型（如 Musa 模型） 马尔可夫过程 基于状态转移 贝叶斯分析 利用先验信息 可靠性模型的组成和特性 教材图 11.4 展示模型组成和特性。建模时需考虑：\n模型假设的适用性 预测能力与质量 模型输出值能否满足可靠性评价需求 模型使用的简便性 1.7 软件可靠性管理 5 大阶段（教材图 11.5）：\n需求分析阶段：确定可靠性指标 设计阶段：可靠性设计 实现阶段：编码规范、代码审查 测试阶段：可靠性测试 运行阶段：可靠性评估与改进 1.8 软件可靠性设计（⭐⭐⭐ 核心重点） 4 大设计技术：\n技术 关键点 容错设计 恢复块设计、N 版本程序设计、冗余设计 检错技术 代价低，需人工干预 降低复杂度设计 简化结构、缩短代码、优化数据流 系统配置技术 双机热备、服务器集群 容错设计技术 恢复块设计 选择一组操作作为容错设计单元 把普通的程序块变成恢复块（含有备份/重试逻辑的块） N 版本程序设计 设计多个模块或不同版本 对相同初始条件和相同输入的操作结果实行多数表决 防止某一软件模块/版本故障提供错误服务 冗余设计 在完整软件系统之外，设计不同路径、不同算法或不同实现方式的模块/系统作为备份 出现故障时使用冗余部分替换 检错技术（4 要素） 要素 说明 检测对象 检测的目标 检测延时 从故障发生到被检测出来的时间 实现方式 检测的具体方法 处理方式 检测到故障后如何处理 检错设计代价低于容错技术和冗余技术 不能自动解决故障，需要人工干预 降低复杂度设计 思想：在保证实现软件功能基础上，简化软件结构、缩短程序代码长度、优化软件数据流向、降低软件复杂度、提高软件可靠性 系统配置技术 双机热备技术 采用\u0026quot;心跳\u0026ldquo;方法保证主系统与备用系统的联系 三种工作方式： 模式 工作方式 双机热备 一台工作，一台后备 双机互备 两台运行相对独立应用，互为后备 双机双工 两台同时运行相同应用，互为后备 数据写入：Active 服务器 + Standby 服务器同时写入，保证即时同步 服务器集群技术 集群内各节点服务器通过内部局域网相互通信 若某节点服务器发生故障，这台服务器运行的应用被另一节点服务器自动接管 1.9 软件可靠性测试 5 大步骤：\n可靠性目标的确定 运行剖面的开发 测试用例的设计 测试实施 测试结果分析 定义软件运行剖面 为软件的使用行为建模 开发使用模型，明确需测试内容 测试用例设计 测试用例要反映实际使用情况 优先测试最重要和最频繁使用的功能 测试用例组成（教材图 11.6）：输入数据 + 测试步骤 + 预期结果 可靠性测试数据（4 类） 按时间定义分：\n失效时间数据 失效间隔时间数据 分组时间内的失效数 分组时间的累积失效数 测试记录与测试报告 组成（教材图 11.7）：测试环境 + 测试数据 + 测试结果 + 失效分析\n1.10 软件可靠性评价 评价过程：\n选择可靠性模型 收集可靠性数据 可靠性评估和预测 选择可靠性模型的 4 个方面 模型假设的适用性 预测的能力与质量 模型输出值能否满足可靠性的评价需求 模型使用的简便性 可靠性数据收集的办法 尽可能早地确定可靠性模型 数据收集计划要有较强的可操作性 重视测试数据的分析和整理 充分利用技术手段（数据库技术）来完成分析和统计 评估和预测 目的：评估软件系统可靠性状况、预测将来一段时间的可靠性水平 手段：以软件可靠性模型分析为主，以失效数据的图形分析法和试探性数据分析技术等为辅 2. 关键概念速查 概念 定义/说明 常见考点 软件可靠性 规定时间内软件不引起系统失效的概率 定义 可靠度 软件不引起系统失效的概率 三大度量指标 MTTF 平均失效时间 三大度量指标 故障强度 单位时间内故障数 三大度量指标 恢复块设计 选择一组操作作为容错设计单元 容错技术 N 版本程序设计 多版本多数表决 容错技术 冗余设计 不同路径/算法/实现方式作备份 容错技术 检错技术 4 要素 检测对象/检测延时/实现方式/处理方式 必考 双机热备 一台工作一台后备 3 种模式 双机互备 两台独立应用互为后备 3 种模式 双机双工 两台同时运行相同应用 3 种模式 服务器集群 通过内部局域网互连，故障自动接管 vs 双机热备 可靠性建模方法 种子法/失效率类/曲线拟合/可靠性增长/程序结构/输入域/执行路径/NHPP/马尔可夫/贝叶斯 10 种方法 可靠性测试 5 步骤 目标/运行剖面/用例/实施/分析 顺序 3. 典型例题 例题 1（检错技术 4 要素） 题目：采用检错设计技术要着重考虑四个要素：检测对象、（ ）、实现方法和处理方式。\nA. 检测延时 B. 测试结果 C. 性能测试 D. 功能测试 答案：A\n解析：检错设计 4 要素 = 检测对象 + 检测延时 + 实现方式 + 处理方式。\n例题 2（双机热备 vs 集群） 题目：（ ）是通常所说的 Active/Standby 方式，Active 服务器处于工作状态，Standby 服务器处于监控准备状态，服务器数据包括数据库数据同时往两台或多台服务器写入，保证数据的即时同步。\nA. 双机热备 B. 双机互备 C. 双机双工 D. 服务器集群 答案：A\n解析：Active/Standby = 一台工作一台后备 = 双机热备模式。\n例题 3（容错设计辨析） 题目：关于 N 版本程序设计，下列说法正确的是：\nA. 设计一个模块的多个不同版本 B. 对相同输入的结果实行多数表决 C. 自动恢复故障模块 D. 适用于所有类型的系统 答案：B\n解析：N 版本程序设计 = 设计多个模块或不同版本 + 对相同初始条件和输入的结果多数表决。不能自动恢复，需要表决选择正确结果。\n例题 4（可靠性建模方法） 题目：以下不属于软件可靠性建模方法的是：\nA. 种子法 B. 失效率类 C. 曲线拟合类 D. 故障树分析法 答案：D\n解析：建模方法包括种子法/失效率类/曲线拟合类/可靠性增长/程序结构分析/输入域分类/执行路径分析/NHPP/马尔可夫过程/贝叶斯分析，故障树分析法是硬件可靠性方法。\n4. 高频考点 4.1 必须记住的核心要点 可靠性定义：规定时间内不引起系统失效的概率 三大度量指标：可靠度、平均失效时间（MTTF）、故障强度 可靠性测试 5 大意义：灾难后果、高失效比例、技术不成熟、费用增长、社会影响 可靠性设计 4 大技术：容错设计、检错技术、降低复杂度设计、系统配置技术 容错设计 3 种：恢复块设计、N 版本程序设计（多数表决）、冗余设计 检错技术 4 要素：检测对象、检测延时、实现方式、处理方式 双机热备 3 模式： 双机热备（一工一备） 双机互备（两台独立应用，互为后备） 双机双工（两台同时运行相同应用） 集群 vs 双机：集群通过内部局域网通信，故障自动接管 建模方法 10 种：种子/失效率/曲线拟合/可靠性增长/程序结构/输入域/执行路径/NHPP/马尔可夫/贝叶斯 可靠性评价 3 步：选模型→收数据→评预测 测试实施 5 步骤：目标→运行剖面→用例设计→实施→结果分析 4.2 易混淆对比 对比项 区别 容错 vs 检错 容错自动处理错误，检错需人工干预 容错 vs 冗余 容错是处理错误的策略，冗余是备份的实现方式 恢复块 vs N 版本 恢复块是重试，N 版本是多版本表决 双机热备 vs 双机互备 热备是相同应用（一工一备），互备是不同应用互为备份 双机热备 vs 双机双工 热备是一工一备，双工是两台同时工作（互为后备） 集群 vs 双机 集群是多节点，通过 LAN 通信，自动接管 广义 vs 狭义可靠性测试 广义包含建模+统计+试验+分析+评价，狭义只按用例执行 性能 vs 可靠性 性能是响应能力，可靠性是无故障运行能力 鲁棒性 vs 容错 鲁棒性是不产生影响，容错是自行修正 ","date":"2024-01-01T00:00:00Z","permalink":"/p/11-ruan-jian-ke-kao-xing/","title":"11-软件可靠性"},{"content":"12-软件架构演化与维护（基于第12小时） 软考-系统架构设计师 | 第3篇 架构设计高级知识 出题形式：单项选择题 + 下午案例分析题 分值占比：约 3-5 分（选择），案例分析 25 分\n0. 考点分析 本小时专注于软件架构的演化和维护，包括基本概念、演化类型、原则、评估方法和维护手段。\n考试特点：\n选择题 3-5 分（演化原则、动态/静态演化、原子操作） 案例分析题核心（大型网站架构演化路径、演化评估） 论文题高频素材（架构演化、维护管理） 1. 核心知识点 1.1 软件架构演化的重要性 保障软件系统具备诸多好的特性 有效管控软件系统的整体复杂性和变化性，降低软件检修和修改成本 保证软件系统演化的一致性和正确性，增加便捷性 1.2 演化和定义的关系 软件架构包括组件、连接件和约束三大要素 架构演化主要关注这三大要素的添加、修改和删除 1.3 面向对象软件架构演化过程（4 类操作） 对象演化 操作 含义 触发场景 AO（Add Object） 添加新对象 系统需要添加新功能或增加架构灵活性时 DO（Delete Object） 删除对象 系统需要移除现有功能或降低架构复杂度时 消息演化（5 种操作） 操作 含义 触发场景 AM（Add Message） 增添一条新消息 对象之间需要增加新的交互行为 DM（Delete Message） 删除当前消息 需要移除某交互行为 SMO（Swap Message Order） 交换两条消息的时间顺序 需要改变两个交互行为之间顺序 OM（Overturn Message） 反转消息的发送对象与接收对象 需要修改某个交互行为本身 CMM（Change Message Module） 改变消息的发送或接收对象 需要修改某个交互行为本身 复合片段演化（4 种操作） 操作 含义 触发场景 AF（Add Fragment） 新增复合片段 需要增添新的控制流 DF（Delete Fragment） 删除复合片段 需要移除某段控制流 FTC（Fragment Type Change） 改变复合片段类型 需要改变某段控制流 FCC（Fragment Condition Change） 改变复合片段内部执行条件 改变当前控制流的执行条件 约束演化 操作 含义 触发场景 AC（Add Constraint） 添加新约束 需判断当前设计是否满足新约束 DC（Delete Constraint） 移除约束 去除某些不必要条件 1.4 软件架构演化方式的分类 按演化时期分（4 类） 类型 时机 特点 设计时演化 体系结构模型与代码编译之前 早期阶段 运行前演化 编译之后、执行之前 中间阶段 有限制运行时演化 特定约束满足时 受限运行 运行时演化 运行时不能满足要求时 动态调整 记忆口诀：设计时→运行前→有限制运行时→运行时（从早到晚）\n静态演化 vs 动态演化 维度 静态演化 动态演化 需求 设计时演化、运行前演化 软件内部执行导致架构改变、外部请求重配置 过程 软件理解→需求变更分析→演化计划→系统重构→系统测试 实时调整 动态性等级 - 交互动态性、结构动态性、架构动态性 演化内容 - 属性改名、行为变化、拓扑结构改变、风格变化 注意：动态演化不包括\u0026quot;格式变化\u0026quot;（考题陷阱）\n静态演化的原子操作 与可维护性相关（7 种）：\nAMD（Add Module Dependence）— 添加模块依赖 RMD（Remove Module Dependence）— 移除模块依赖 AMI（Add Module Interface）— 添加模块接口 RMI（Remove Module Interface）— 移除模块接口 AM（Add Module）— 添加模块 RM（Remove Module）— 移除模块 SM（Split Module）— 拆分模块 AGM（Aggregate Modules）— 聚合模块 与可靠性相关（10 种）：\nAMS（Add Message）— 添加消息 RMS（Remove Message）— 移除消息 AO（Add Object）— 添加对象 RO（Remove Object）— 移除对象 AF（Add Fragment）— 添加片段 RF（Remove Fragment）— 移除片段 CF（Change Fragment）— 改变片段 AU（Add Use Case）— 添加用例 RU（Remove Use Case）— 移除用例 AA（Add Actor）— 添加参与者 RA（Remove Actor）— 移除参与者 1.5 动态软件架构（DSA） 实现动态演化的基本原理 运行时刻体系结构相关信息的改变可用来触发、驱动系统自身的动态调整 DSA 描述语言（按视角分） 视角 语言 行为视角 π-ADL 反射视角 Pilar 协调视角 LIME DSA 演化工具（4 种） 使用反射机制 基于组件操作 基于 π 演算 利用外部的体系结构演化管理器 动态软件架构应用实例 — PKUAS 4 种类型：容器系统、公共服务、工具和微内核 动态重配置 4 种模式：\n主从模式 中央控制模式 客户端/服务器模式 分布式控制模式 应用实例：可重用、可配置的产品线架构\n动态配置难点：\n约束定义困难 性能约束难以静态衡量 难以管理所有方面 需同时保证组件系统完整性和重配置策略的正确和安全性 1.6 软件结构演化原则（18 大原则） # 原则 关键点 1 演化成本控制 演化成本要控制在预期范围内 2 进度可控 架构演化要在预期时间内完成 3 风险可控 经济/时间/人力/技术/环境风险在可控范围内 4 主体维持 软件演化的平均增量增长须保持平稳，主体行为稳定 5 系统总体结构优化 演化后整体结构（布局）更加合理 6 平滑演化 软件的演化速率趋于稳定 7 目标一致 阶段目标和最终目标要一致 8 模块独立演化 各模块自身的演化最好相互独立 9 影响可控 一个模块变更给其他模块带来的影响在可控范围 10 复杂性可控 必须控制架构的复杂性 11 有利于重构 演化后软件架构便于重构 12 有利于重用 维持或提高整体架构的可重用性 13 设计原则遵循性 演化不与架构设计原则冲突 14 适应新技术 软件独立于特定技术手段，可运行于不同平台 15 环境适应性 演化后软件版本容易适应新硬件/软件环境 16 标准依从性 演化不违背相关质量标准（国际/国家/行业） 17 质量向好 所关注的质量指标综合效果变更好 18 适应新需求 很容易适应新的需求变更 关键原则对比：\n原则 vs 主体维持 平均增量平稳 平滑演化 演化速率趋于稳定 目标一致 阶段目标和最终目标一致 系统总体结构优化 整体结构布局合理 1.7 软件架构演化评估方法 演化过程已知的评估 流程：将架构度量应用到演化过程中 通过对演化前后的不同版本的架构分别进行度量 得到度量结果的差值及其变化趋势 计算架构间质量属性距离，对相关质量属性进行评估 演化过程未知的评估 教材图 12.3 展示评估过程 通过反向工程等技术恢复架构信息 1.8 大型网站系统架构演化实例（10 阶段） 阶段 架构 关键点 第一阶段 单体架构 应用程序、数据库、文件等所有资源都在一台服务器上 第二阶段 垂直架构 应用和数据分离，3 台服务器：应用、文件、数据 第三阶段 使用缓存改善性能 本地缓存 + 远程分布式缓存 第四阶段 使用服务集群改善并发 负载均衡调度服务器，分发请求到集群 第五阶段 数据库读写分离 主库写、从库读，主从复制机制同步 第六阶段 反向代理和 CDN 加速 CDN 部署在网络提供商机房（距离最近）；反向代理部署在中心机房 第七阶段 分布式文件系统和分布式数据库 业务分库，不同业务部署不同物理服务器 第八阶段 使用 NoSQL 和搜索引擎 解决海量数据检索 第九阶段 业务拆分 一个网站拆分成多个应用，独立部署 第十阶段 分布式服务 服务化、SOA/微服务 核心演化逻辑：\n解决性能 → 缓存、集群、读写分离 解决高可用 → 集群、读写分离、CDN 解决扩展性 → 业务拆分、分布式服务 解决海量数据 → 分布式文件系统、NoSQL 1.9 软件架构维护 维护过程（3 大内容）：\n软件架构知识管理 软件架构修改管理 软件架构版本管理 软件架构知识管理 架构知识 = 架构设计 + 架构设计决策 含义：侧重于软件开发和实现过程所涉及的架构静态演化 在架构文档等信息来源中捕捉架构知识 提供架构的质量属性及其设计依据进行记录和评价 需求：防止关键的设计知识\u0026quot;沉没\u0026quot;在软件架构中 软件架构修改管理 主要是建立一个隔离区域 保障该区域中任何修改对其他部分影响最小 软件架构版本管理 为软件架构演化的版本演化控制、使用和评价提供可靠依据 架构可维护性度量（6 指标） 指标 缩写 圈复杂度 CNN 扇入扇出度 FFC 模块间耦合度 CBO 模块的响应 RFC 紧内聚度 TCC 松内聚度 LCC 2. 关键概念速查 概念 定义/说明 常见考点 AO/DO 对象的添加/删除 对象演化 AM/DM/SMO/OM/CMM 消息的增/删/换序/反转/改模块 消息演化 5 种 AF/DF/FTC/FCC 复合片段的增/删/改类型/改条件 复合片段演化 AC/DC 约束的添加/删除 约束演化 设计时演化 编译之前 4 时期最早 运行前演化 编译之后、执行之前 4 时期 有限制运行时演化 特定约束满足时 4 时期 运行时演化 运行时不能要求时 4 时期最晚 主体维持 平均增量平稳 18 原则 平滑演化 演化速率趋于稳定 18 原则 目标一致 阶段目标和最终目标一致 18 原则 系统总体结构优化 整体结构布局合理 18 原则 DSA 描述语言 π-ADL（行为）/Pilar（反射）/LIME（协调） 3 种视角 动态重配置 4 模式 主从/中央控制/C-S/分布式控制 4 种模式 大型网站 10 阶段 单体→垂直→缓存→集群→读写分离→CDN→分布式→NoSQL→业务拆分→分布式服务 演化路径 架构维护 3 内容 知识/修改/版本管理 必考 架构可维护性 6 指标 CNN/FFC/CBO/RFC/TCC/LCC 缩写含义 3. 典型例题 例题 1（演化原则辨析） 题目：在软件系统的生命周期里，软件的演化速率趋于稳定，如相邻版本的更新率相对稳定。此描述是软件架构演化的（ ）原则。\nA. 主体维持 B. 系统总体结构优化 C. 平滑演化 D. 目标一致 答案：C\n解析：\n主体维持：平均增量增长平稳 系统总体结构优化：整体结构布局合理 平滑演化：演化速率趋于稳定 ✓ 目标一致：阶段目标和最终目标一致 例题 2（架构维护内容） 题目：软件架构维护过程不包括（ ）。\nA. 架构知识管理 B. 架构修改管理 C. 架构版本管理 D. 架构构件管理 答案：D\n解析：软件架构维护过程包括架构知识管理、架构修改管理、架构版本管理，不包括架构构件管理。\n例题 3（演化时期辨析） 题目：下列软件架构演化时期，（ ）是在系统设计时规定了演化的具体条件，将系统置于\u0026quot;安全\u0026quot;模式下，演化只发生在某些特定约束满足时，可以进行一些规定好的演化操作。\nA. 设计时演化 B. 运行前演化 C. 有限制运行时演化 D. 运行时演化 答案：C\n解析：\n设计时演化：编译之前 运行前演化：编译之后、执行之前 有限制运行时演化：只发生在某些特定约束满足时 ✓ 运行时演化：运行时不能满足要求时 例题 4（动态演化内容） 题目：根据所修改的内容不同，软件的动态演化不包括（ ）。\nA. 属性改名 B. 行为变化 C. 拓扑结构改变 D. 格式变化 答案：D\n解析：动态演化的内容包括：属性改名、行为变化、拓扑结构改变、风格变化。格式变化不属于动态演化内容。\n4. 高频考点 4.1 必须记住的核心要点 架构 3 要素：组件、连接件、约束（演化关注这 3 要素的增删改） 对象演化 2 种：AO、DO 消息演化 5 种：AM、DM、SMO、OM、CMM 复合片段演化 4 种：AF、DF、FTC、FCC 约束演化 2 种：AC、DC 演化 4 时期（从早到晚）：设计时→运行前→有限制运行时→运行时 动态演化 4 内容：属性改名、行为变化、拓扑结构改变、风格变化（不含格式变化） DSA 描述语言 3 视角：行为（π-ADL）/反射（Pilar）/协调（LIME） 动态重配置 4 模式：主从/中央控制/C-S/分布式控制 PKUAS 4 类型：容器系统、公共服务、工具、微内核 架构 4 大演化原则对比： 主体维持：平均增量平稳 平滑演化：演化速率稳定 目标一致：阶段目标和最终目标一致 系统总体结构优化：整体结构合理 大型网站 10 阶段演化路径（必考） 架构维护 3 内容：知识/修改/版本管理（不含构件管理） 可维护性 6 指标：CNN/FFC/CBO/RFC/TCC/LCC 架构知识 = 架构设计 + 架构设计决策 4.2 易混淆对比 对比项 区别 AO vs AM AO 是对象的添加，AM 是消息的添加 AC vs AF AC 是约束的添加，AF 是复合片段的添加 主体维持 vs 平滑演化 主体维持强调增量稳定，平滑演化强调速率稳定 目标一致 vs 系统总体结构优化 目标一致是目标，结构优化是布局 静态演化 vs 动态演化 静态是预先规划的演化，动态是运行时刻的演化 设计时 vs 运行前 设计时是编译之前，运行前是编译之后 双机热备 vs 服务集群 热备是2 台服务器，集群是多节点通过 LAN 互连 架构知识管理 vs 修改管理 知识管理是捕捉记录，修改管理是隔离变更 ","date":"2024-01-01T00:00:00Z","permalink":"/p/12-ruan-jian-jia-gou-yan-hua-yu-wei-hu/","title":"12-软件架构演化与维护"},{"content":"13-未来信息综合技术（基于第13小时） 软考-系统架构设计师 | 第3篇 架构设计高级知识 出题形式：单项选择题 + 下午案例分析题 分值占比：约 3-5 分（选择），案例分析 25 分\n0. 考点分析 本小时覆盖未来信息技术，包括 CPS、人工智能、机器人、边缘计算、数字孪生、云计算和大数据。\n考试特点：\n选择题 3-5 分（概念必考：CPS 四要素、机器学习分类、云计算服务方式） 案例分析题偶尔涉及 论文题素材来源（边缘计算应用、CPS 建设路径） 1. 核心知识点 1.1 信息物理系统（CPS） CPS 概念 全称：Cyber-Physical System（信息物理系统） 起源：1992 年由美国国家航空航天局提出，科学家海伦·吉尔详细描述 本质：是控制系统、嵌入式系统的扩展与延伸 作用：通过集成先进的感知、计算、通信、控制等信息技术和自动控制技术，构建物理空间与信息空间中人、机、物、环境、信息等要素相互映射、适时交互、高效协同的复杂系统 CPS 本质：\n构建信息空间与物理空间之间基于数据自动流动的 状态感知 → 实时分析 → 科学决策 → 精准执行 的闭环赋能体系 解决生产制造、应用服务过程中的复杂性和不确定性问题 CPS 体系结构 3 个层级：\n单元级 系统级 SOS 级（System of Systems，系统的系统） CPS 技术体系（3 类） CPS 总体技术（顶层设计技术） CPS 支撑技术（基于应用支撑） CPS 核心技术（基础技术） CPS 四大核心技术要素（⭐⭐⭐ 必考） 要素 内容 作用 一硬 感知和自动控制 CPS 实现的硬件支撑 一软 工业软件 CPS 核心 一网 工业网络 网络载体 一平台 工业云和智能服务平台 支撑上层解决方案的基础 记忆口诀：\n硬 = 感知控制（硬件） 软 = 工业软件（核心） 网 = 工业网络（载体） 平台 = 工业云 + 智能服务（基础） CPS 典型应用场景 场景 应用 智能设计 产品及工艺设计、生产线/工厂设计 智能生产 设备管理、生产管理、柔性制造 智能服务 健康管理、智能维护、远程征兆诊断、协同优化、共享服务 智能应用 无人装备、产业链互动、价值链共赢 CPS 建设路径 4 步走：CPS 体系设计 → 单元级 CPS 建设 → 系统级 CPS 建设 → SOS 级 CPS 建设\n1.2 人工智能技术 AI 概念 定义：利用数字计算机或数字计算机控制的机器模拟、延伸和扩展人的智能，感知环境、获取知识并使用知识获得最佳结果的理论、方法、技术及应用系统 分类： 弱人工智能：不能真正实现推理、思考和解决问题 强人工智能：真正实现推理、思考和解决问题 AI 发展历程 图灵测试 → \u0026ldquo;人工智能\u0026quot;术语 → 机器学习 → 专家系统 → 计算机战胜双陆棋世界冠军 → 决策树模型和神经网络 → IBM 深蓝战胜国际象棋世界冠军 → 深度学习 → 爆发式发展\nAI 6 大关键技术 技术 应用 自然语言处理 机器翻译、语义理解、问答系统 计算机视觉 自动驾驶、机器人、智能医疗 知识图谱 反欺诈、不一致性验证、组团欺诈（公共安全保障） 人机交互 传统基本交互、图形、语音、情感、体感、脑机交互 虚拟现实 / 增强现实 生成与真实环境在视觉/听觉等方面高度近似的数字化环境 机器学习 见下文 机器学习分类 按学习模式分（4 种） 模式 特点 典型场景 监督学习 需提供标注的样本集 分类、回归 无监督学习 不需提供标注的样本集 聚类、降维 半监督学习 需提供少量标注的样本集 大部分数据无标签场景 强化学习 需反馈机制 游戏 AI、机器人控制 按学习方法分 方法 特点 传统机器学习 需手动完成（特征工程） 深度学习 需大量训练数据集和强大 GPU 服务器提供算力 机器学习常见算法 迁移学习、主动学习、演化学习\n1.3 机器人技术 机器人的定义（3 要素） 具脑、手、脚三要素个体 具有非接触传感器和接触传感器 具有平衡觉和固定觉的传感器 机器人发展历程（3 代） 第一代：示教再现型机器人 第二代：感觉型机器人 第三代：智能型机器人 机器人 4.0 核心技术（5 项） 云—边—端的无缝协同计算 持续学习与协同学习 知识图谱 场景自适应 数据安全 机器人分类 维度 类型 按控制方式 操作机器人、程序机器人、示教再现机器人、智能机器人、综合机器人 按应用行业 工业机器人、服务机器人、特殊领域机器人 1.4 边缘计算 边缘计算概念 基本思想：将数据的处理、应用程序的运行以及一些功能服务的实现，由网络中心下放到网络边缘节点上 边缘计算的多种定义 来源 定义 边缘计算产业联盟 云计算在数据中心之外汇聚节点的延伸和演进，包括云边缘、边缘云和云化网关三类落地形态；以\u0026rdquo;边云协同\u0026ldquo;和\u0026rdquo;边缘智能\u0026ldquo;为核心和发展方向 OpenStack 社区 为应用开发者和服务提供商在网络边缘侧提供云服务和 IT 环境服务，目标是在靠近数据输入或用户的地方提供计算、存储和网络带宽 ISO/IEC JTC1/SC38 在靠近物或数据源头的网络边缘侧，融合网络、计算、存储、应用核心能力的开放平台，就近提供边缘智能服务 国际标准组织 提供移动网络边缘 IT 服务和计算能力，靠近移动用户 边缘计算 4 大特点 联接性：所联接物理对象的多样性及应用场景的多样性，需要边缘计算具备丰富的联接功能（各种网络接口、网络协议等） 数据第一入口：边缘计算拥有大量、实时、完整的数据，可基于数据全生命周期进行管理与价值创造 约束性：需适配工业现场相对恶劣的工作条件与运行环境（功耗、成本、空间） 分布性：边缘计算实际部署天然具备分布式特征 边云协同（6 个维度） 协同维度 边缘节点 云端 资源协同 提供计算、存储、网络、虚拟化等基础设施资源 资源调度管理策略 数据协同 现场/终端数据采集、初步处理与分析 海量数据存储、分析与价值挖掘 智能协同 执行推理，实现分布式智能 开展模型训练，并将模型下发边缘节点 应用管理协同 提供应用部署与运行环境 应用开发、测试环境、应用生命周期管理 业务管理协同 模块化、微服务化的应用/数字孪生/网络实例 按客户需求实现应用/数字孪生/网络等的业务编排能力 服务协同 按云端策略实现部分 ECSaaS 服务 SaaS 服务在云端和边缘节点的服务分布策略 边缘安全 价值体现：提供可信的基础设施、为边缘应用提供可信赖的安全服务、提供安全可信的网络和覆盖 边缘计算应用场合 智慧园区、安卓云与云游戏、视频监控、工业物联网、Cloud VR\n1.5 数字孪生体技术 数字孪生体定义 定义：数字孪生体是现有或将有的物理实体对象的数字模型 通过实测、仿真和数据分析来实时感知、诊断、预测物理实体对象的状态 通过优化和指令来调控物理实体对象的行为 通过相关数字模型间的相互学习来进化自身 同时改进利益相关方在物理实体对象生命周期内的决策 关键技术 3 大核心技术：\n建模 仿真 基于数据融合的数字线程 应用领域 4 大领域：制造、产业、城市、战场\n1.6 云计算和大数据技术 云计算概述 \u0026ldquo;云计算\u0026quot;是同时描述一个系统平台或一类应用程序的术语 云计算的 3 种服务方式（⭐⭐⭐ 必考） 服务方式 缩写 说明 软件即服务 SaaS 服务提供商将应用软件统一部署在云计算服务器上 平台即服务 PaaS 服务提供商将分布式开发环境与平台作为一种服务来提供 基础设施即服务 IaaS 服务提供商将多台服务器组成\u0026rdquo;云端\u0026ldquo;基础设施作为计量服务提供给客户 记忆口诀：从上到下是 SaaS→PaaS→IaaS（用户控制范围递减）\n云计算的部署模式 4 种模式：\n公有云 社区云 私有云 混合云 大数据分析步骤（5 步） 数据获取/记录 信息抽取/清洗/注记 数据集成/聚集/表现 数据分析/建模 数据解释 大数据应用领域 4 大领域：制造业、服务业、交通行业、医疗行业\n2. 关键概念速查 概念 定义/说明 常见考点 CPS 信息物理系统，1992 年 NASA 提出 一硬一软一网一平台 一硬 感知和自动控制（硬件支撑） CPS 4 要素 一软 工业软件（CPS 核心） CPS 4 要素 一网 工业网络（网络载体） CPS 4 要素 一平台 工业云和智能服务平台（基础） CPS 4 要素 弱 AI 不能真正实现推理、思考和解决问题 vs 强 AI 强 AI 真正实现推理、思考和解决问题 vs 弱 AI 监督学习 需提供标注的样本集 机器学习分类 无监督学习 不需提供标注的样本集 机器学习分类 半监督学习 需提供少量标注的样本集 机器学习分类 强化学习 需反馈机制 机器学习分类 深度学习 需大量训练数据 + GPU 算力 vs 传统机器学习 机器人 4.0 五技术 云边端协同/持续学习/知识图谱/场景自适应/数据安全 5 项核心 边缘计算定义 网络中心下放到网络边缘节点 ISO/IEC 定义 边云协同 6 维度 资源/数据/智能/应用管理/业务管理/服务 6 协同 数字孪生体 3 技术 建模、仿真、基于数据融合的数字线程 3 核心技术 数字孪生体 4 应用 制造、产业、城市、战场 4 大领域 SaaS 软件即服务 3 种服务方式 PaaS 平台即服务 3 种服务方式 IaaS 基础设施即服务 3 种服务方式 云计算 4 部署 公有云/社区云/私有云/混合云 4 种模式 大数据 5 步骤 记录→抽取→集成→分析→解释 5 步流程 3. 典型例题 例题 1（CPS 四要素） 题目：CPS 技术体系的四大核心技术要求中\u0026quot;一平台\u0026quot;是（ ）。\nA. 感知和自动控制 B. 工业软件 C. 工业网络 D. 工业云和智能服务平台 答案：D\n解析：\n一硬 = 感知和自动控制（硬件支撑） 一软 = 工业软件（CPS 核心） 一网 = 工业网络（网络载体） 一平台 = 工业云和智能服务平台（基础） 例题 2（机器学习分类） 题目：人工智能的关键技术包括自然语言处理、计算机视觉、知识图谱、机器学习。机器学习分类中（ ）是利用已标记的有限训练数据集，通过某种学习策略/方法建立一个模型，从而实现对新数据/实例标记/映射。\nA. 监督学习 B. 无监督学习 C. 半监督学习 D. 强化学习 答案：A\n解析：监督学习需要提供已标记的训练样本集来建立模型；无监督学习不需标注；半监督学习只需少量标注；强化学习需反馈机制。\n例题 3（云计算服务方式） 题目：云计算的服务方式不包括（ ）。\nA. 软件即服务 B. 计算即服务 C. 平台即服务 D. 基础设施即服务 答案：B\n解析：云计算的 3 种服务方式是 SaaS、PaaS、IaaS，没有\u0026quot;计算即服务\u0026rdquo;。\n例题 4（数字孪生体技术） 题目：数字孪生体的核心技术不包括（ ）。\nA. 建模 B. 仿真 C. 数据融合的数字线程 D. 区块链 答案：D\n解析：数字孪生体 3 大核心技术：建模、仿真、基于数据融合的数字线程，不含区块链。\n4. 高频考点 4.1 必须记住的核心要点 CPS 起源：1992 年 NASA 提出 CPS 本质：物理空间与信息空间的闭环赋能 CPS 4 大核心技术要素（必考）： 一硬（感知和自动控制） 一软（工业软件） 一网（工业网络） 一平台（工业云和智能服务平台） CPS 3 层级：单元级、系统级、SOS 级 CPS 建设路径：CPS 体系设计 → 单元级 → 系统级 → SOS 级 AI 6 大关键技术：自然语言处理、计算机视觉、知识图谱、人机交互、VR/AR、机器学习 机器学习 4 种模式（必考）：监督（需标注）、无监督（不需标注）、半监督（少量标注）、强化（需反馈） 深度学习 vs 传统 ML：深度学习需大量数据 + GPU 算力 机器人 4.0 五技术：云边端协同/持续学习/知识图谱/场景自适应/数据安全 边缘计算核心思想：从网络中心下放到网络边缘节点 边云协同 6 维度：资源/数据/智能/应用管理/业务管理/服务 数字孪生体 3 核心技术：建模、仿真、基于数据融合的数字线程 数字孪生体 4 应用：制造、产业、城市、战场 云计算 3 种服务方式（必考）：SaaS、PaaS、IaaS 云计算 4 种部署模式：公有云、社区云、私有云、混合云 大数据 5 步骤：记录→抽取→集成→分析→解释 大数据 4 应用领域：制造业、服务业、交通、医疗 4.2 易混淆对比 对比项 区别 一硬 vs 一软 一硬是感知控制硬件，一软是工业软件（CPS 核心） 一网 vs 一平台 一网是网络载体，一平台是云+智能服务 弱 AI vs 强 AI 弱 AI 不能真正推理，强 AI 能真正推理 监督 vs 无监督 监督需标注，无监督不需标注 半监督 vs 监督 半监督只需少量标注，监督需全部标注 强化学习 vs 监督学习 强化是反馈机制，监督是标注样本 深度学习 vs 传统 ML 深度学习自动特征学习，传统 ML 手动特征工程 SaaS vs PaaS vs IaaS 用户控制范围递减，灵活度递减 边缘计算 vs 云计算 边缘在网络边缘节点，云在数据中心 边缘 vs 数字孪生 边缘是计算下放，数字孪生是物理对象建模 大数据 vs 传统数据 大数据是5V 特征（量大/速快/多样/价值/真实） 公有云 vs 私有云 公有云对外，私有云内部专用 ","date":"2024-01-01T00:00:00Z","permalink":"/p/13-wei-lai-xin-xi-zong-he-ji-shu/","title":"13-未来信息综合技术"},{"content":"14-系统规划（基于第14小时） 软考-系统架构设计师 | 第3篇 架构设计高级知识 出题形式：单项选择题 分值占比：约 1-3 分\n0. 考点分析 本小时属于次要章节，考点较少，不作为重点掌握的知识。\n考试特点：\n选择题 1-3 分（成本分类、盈亏临界点计算） 案例分析题基本不涉及 论文题不涉及 1. 核心知识点 1.1 系统规划概述 系统规划属于信息系统生命周期的第一个阶段。其任务是：\n对企业的环境、目标及现有系统的状况进行初步调查 研究建设新系统的必要性和可能性 根据需要与可能，给出拟建系统的备选方案 对这些方案进行可行性分析 写出可行性研究报告 审议通过后，将新系统建设方案及实施计划编写成系统设计任务书 1.2 系统规划的主要步骤 对现有系统进行初步调查 分析和确定系统目标 分析子系统的组成和基本功能 拟定系统的实施方案 进行系统的可行性研究，编写可行性研究报告，召开可行性论证会 制订系统建设方案 1.3 系统调查（两阶段） 初步调查 时机：在规划阶段进行 目的：了解企业的组织结构和系统功能 具体内容： 初步需求分析 企业基本状况 管理方式和基础数据管理状况 现有系统状况 详细调查 目的：深入了解系统的处理流程 调查内容： 现有系统的运行环境和状况 组织结构 业务流程 系统功能 数据资源与数据流程 资源情况 约束条件和薄弱环节等 1.4 成本效益分析技术 成本分类（按成本性态） 成本类型 定义 举例 固定成本 总额在一定时期和一定业务量范围内，不受业务量变动的影响而保持固定不变的成本 管理人员的工资、办公费、固定资产折旧费、员工培训费 变动成本（可变成本） 在一定时期和一定业务量范围内其总额随着业务量的变动而成正比例变动的成本 直接材料费、产品包装费、外包费用、开发奖金 混合成本 混合了固定成本和变动成本的性质。这些成本通常有一个基数，超过这个基数就会随业务量的增大而增大 质量保证人员的工资、设备动力费 关键公式（⭐⭐⭐ 必考） 公式 公式 利润 = (销售单价 − 单位变动成本) × 销售量 − 总固定成本 盈亏临界点销售量 = 总固定成本 / (销售单价 − 单位可变成本) 盈亏临界点销售额 = 总固定成本 / (1 − 总可变成本/销售收入) 核心公式： $$\\text{盈亏临界点销售量} = \\frac{\\text{总固定成本}}{\\text{销售单价} - \\text{单位可变成本}}$$2. 关键概念速查 概念 定义/说明 常见考点 系统规划 信息系统生命周期的第一个阶段 任务定义 初步调查 规划阶段，了解组织结构和功能 vs 详细调查 详细调查 深入了解处理流程 7 大内容 固定成本 不受业务量变动影响 管理人员工资 变动成本 与业务量成正比例 直接材料费 混合成本 有基数 + 超过基数随业务量增加 质量保证人员工资 盈亏临界点 收入 = 成本，既不盈利也不亏损 销售量公式 系统设计任务书 可行性研究报告通过后编写 输出物 3. 典型例题 例题 1（详细调查内容） 题目：（ ）的内容是调查现有系统的运行环境和状况、组织结构、业务流程、系统功能等。\nA. 初步调查 B. 详细调查 C. 系统调查 D. 可行性研究 答案：B\n解析：详细调查可以深入了解系统的处理流程。调查的内容有：现有系统的运行环境和状况、组织结构、业务流程、系统功能、数据资源与数据流程、资源情况、约束条件和薄弱环节等。\n例题 2（成本类型） 题目：管理人员的工资属于（ ）。\nA. 固定成本 B. 混合成本 C. 变动成本 D. 长期成本 答案：A\n解析：固定成本是指其总额在一定时期和一定业务量范围内，不受业务量变动的影响而保持固定不变的成本。管理人员的工资、办公费、固定资产折旧费、员工培训费都是固定成本的典型例子。\n例题 3（盈亏临界点计算） 题目：某厂生产的某种电视机，销售价为每台 2500 元，去年的总销售量为 25000 台，固定成本总额为 250 万元，可变成本总额为 4000 万元，税率为 16%，则该产品年销售量的盈亏平衡点为（ ）台（只有在年销售量超过它时才能盈利）。\nA. 5000 B. 10000 C. 15000 D. 20000 答案：A\n解析：\n每台可变成本 = 4000万/25000 = 1600 元 净收入率 = 1 − 16% = 84%（含税情况） 设盈亏平衡点销售量为 N 净收入 = 2500 × N × (1 − 16%) = 0.21N × 10000 0.21N × 10000 = 2500000 + 1600 × N 21000N − 1600N = 2500000 19400N = 2500000 N ≈ 5000 注：教材标准解法 盈亏临界点销售量 × 销售单价 × (1−税率) = 总固定成本 + 盈亏临界点销售量 × 单位可变成本 0.21N = 250 + 0.16N（变形） 0.05N = 250 N = 5000\n例题 4（系统规划步骤） 题目：系统规划的主要步骤中，不包括：\nA. 对现有系统进行初步调查 B. 分析和确定系统目标 C. 详细设计系统模块 D. 制订系统建设方案 答案：C\n解析：系统规划的主要步骤是宏观层面的，不涉及详细设计系统模块。详细设计属于设计阶段而非规划阶段。\n4. 高频考点 4.1 必须记住的核心要点 系统规划定位：信息系统生命周期的第一个阶段 系统规划 6 步骤： 初步调查 分析和确定系统目标 分析子系统的组成和基本功能 拟定系统的实施方案 可行性研究 制订系统建设方案 初步调查 vs 详细调查： 初步调查：规划阶段，了解组织结构和功能 详细调查：深入了解处理流程（运行环境、组织结构、业务流程、系统功能、数据资源、资源情况、约束条件、薄弱环节） 3 大成本类型： 固定成本：不受业务量影响（管理人员工资、办公费、固定资产折旧费、员工培训费） 变动成本：与业务量成正比例（直接材料费、产品包装费、外包费用、开发奖金） 混合成本：有基数 + 超过基数随业务量增加（质量保证人员工资、设备动力费） 3 大盈亏公式（必考）： 利润 = (销售单价 − 单位变动成本) × 销售量 − 总固定成本 盈亏临界点销售量 = 总固定成本 / (销售单价 − 单位可变成本) 盈亏临界点销售额 = 总固定成本 / (1 − 总可变成本/销售收入) 关键交付物：可行性研究报告 → 系统设计任务书 4.2 易混淆对比 对比项 区别 初步调查 vs 详细调查 初步是规划阶段了解概况，详细是深入了解处理流程 固定成本 vs 变动成本 固定不受业务量影响，变动与业务量成正比 变动成本 vs 混合成本 变动是全程正比例，混合是有基数 + 超过部分 系统规划 vs 系统设计 规划是生命周期第一个阶段，设计是后续阶段 盈亏临界点销售量 vs 销售额 销售量是数量（台/件），销售额是金额 可行性研究 vs 详细调查 可行性是规划阶段评估，详细调查是需求阶段调研 ","date":"2024-01-01T00:00:00Z","permalink":"/p/14-xi-tong-gui-hua/","title":"14-系统规划"},{"content":"15-信息系统架构设计实践（第15小时） 软考-系统架构设计师 | 第4篇 架构设计实践知识 出题形式：上午选择题（2-5 分）+ 下午案例分析题（可能）+ 论文题 分值占比：约 2-5 分\n0. 考点分析 5 大体系结构风格：数据流/调用-返回/独立构件/虚拟机/仓库 物理结构与逻辑结构：单体/分布式、横向/纵向/纵横综合 C/S、B/S 架构：二层/三层/多层、胖客户端/瘦客户端 MVC 模式：控制器/模型/视图的协作 SOA 与 ESB/EDB：服务化与企业总线 TOGAF 与 ADM：企业架构框架 信息化规划方法：CSF/SST/BSP 1. 核心架构知识 1.1 体系结构风格 5 大类体系结构风格：\n风格类别 具体风格 特点 数据流 批处理、管道-过滤器 数据驱动，顺序处理 调用/返回 主程序/子程序、面向对象、层次结构 同步调用，结构清晰 独立构件 进程通信、事件系统 松耦合，异步 虚拟机 解释器、规则系统 灵活执行 仓库 数据库、超文本、黑板 数据为中心 1.2 信息系统架构分类 物理结构：\n单体应用 分布式结构 逻辑结构：\n横向综合：将同一管理层次的各个业务职能综合到一起 纵向综合：将同一业务的各个管理层次综合到一起 纵横综合：从信息模型和处理模型两方面建立公用数据库和统一信息处理系统 1.3 常用架构模型 1.3.1 单体应用 运行在单台物理机器上的独立应用程序 应用领域：信息系统领域，以数据处理为核心 1.3.2 客户机/服务器（C/S） 客户端与服务器通过 TCP/UDP 进行请求和应答 形式对比：\n类型 形式 特点 二层 C/S 前台客户端 + 后台数据库 胖客户端 三层 C/S 前台客户端 + 后台服务端 + 后台数据库 引入应用层 三层 B/S Web 浏览器 + Web 服务器 + 后台数据库 基于 HTTP 多层 C/S 前台 + 后台服务端 + 中间件/应用层 + 数据库 中间件提升性能与安全 MVC Web 浏览器(View) + Web 服务器(Controller) + 数据库 关注点分离 通信协议：TCP/IP、Socket 自定义、RPC、CORBA/IIOP、Java RMI、J2EE JMS、HTTP\n1.3.3 MVC（Model-View-Controller） 角色 职责 控制器（Controller） 接受用户输入，调用模型和视图 模型（Model） 业务数据和业务逻辑 视图（View） 用户界面 优点：允许多种用户界面扩展、易于维护、易于构建强大 UI、增强可扩展性、强壮性、灵活性\n1.3.4 SOA（面向服务架构） 服务：能提供一组整体功能的独立应用系统 实现方式：借助消息中间件、交易中间件 典型应用：Web Service（通过消息机制或 RPC 调用） 主要实践：异构系统集成、同构系统聚合、联邦架构 1.3.5 ESB / EDB（企业服务总线/企业数据总线） 特征：\n连接软件系统，提供服务代理功能和服务注册表 按照协议消息头进行数据、请求、回复的接收和分发 可基于消息中间件、事务中间件、CORBA/IIOP 协议开发 1.4 企业信息系统总体框架 构建有效集成的 ISA（信息系统架构）需考虑 4 个方面：\n方面 描述 战略系统 战略制定、高层决策、长期/短期规划 业务系统 业务过程、活动、角色、数据的建模与执行 应用系统 应用软件，包括内部功能和外部界面 企业信息基础设施（EII） 信息设备、通信网络、数据库、系统软件、支撑软件 1.5 架构设计方法 1.5.1 TOGAF 架构框架 国际权威组织 The Open Group 制订的企业架构标准框架。\n4 大目标：\n节省时间和成本，更有效、合理利用资源 实现可观的投资回报率 确保所有用户使用相同的语言 避免被\u0026quot;锁定\u0026quot;到企业架构的专有解决方案 核心思想：模块化架构，为大型组织开发提供扩展指南\nTOGAF 组件：\n架构开发方法（ADM） 架构开发方法指南和技术 架构内容框架 企业连续序列和工具 架构框架参考模型 架构能力框架 1.5.2 ADM（架构开发方法）10 个阶段 预备 → 需求管理 → 架构愿景 → 业务架构 → 信息系统架构 → 技术架构 → 机会和解决方案 → 迁移规划 → 实施治理 → 架构变更管理\n1.5.3 信息化 4+6+7+9 4 个内容：信息网络体系、信息产业基础、社会运行环境、效用积累过程 6 个要素：开发利用信息资源、建设国家信息网络、推进信息技术应用、发展信息技术和产业、培育信息化人才、制订和完善信息化政策 7 个平台：知识管理、日常办公、信息集成、信息发布、协同工作、公文流转、企业通信 9 个特征：易用性、健壮性、平台化、灵活性、扩展性、安全性、门户化、整合性、移动性 1.5.4 信息化架构两种模式 数据导向架构：关注数据模型和数据质量 流程导向架构：关注端到端流程整合及对流程变化的适应度 1.5.5 信息化建设生命周期 系统规划 → 系统分析 → 系统设计 → 系统实施 → 系统运行和维护\n1.5.6 信息化工程总体规划方法 方法 核心思想 CSF（关键成功因素法） 找出企业成功的关键因素，围绕其确定系统需求 SST（战略目标集转化法） 反映各种人的要求，按要求分层，转化为信息系统目标 BSP（企业系统规划法） 自上而下识别系统目标、企业过程和数据，自下而上设计 1.6 实践案例 案例：某电商订单系统从单体到 C/S 再到 SOA 的演进\n阶段1：单体应用，所有功能在一台服务器 阶段2：二层 C/S，前台客户端 + 数据库 阶段3：三层 B/S，引入 Web 服务器 阶段4：多层架构，引入中间件，提升并发性能 阶段5：SOA 化，通过 ESB 集成订单、库存、支付等服务 2. 关键概念速查 概念 定义/说明 常见考点 ISA 信息系统架构（Information System Architecture） 多维度、分层次、高度集成化的模型 C/S 架构 客户端/服务器架构 胖客户端/瘦客户端区分 B/S 架构 浏览器/服务器架构 本质是 HTTP 协议 MVC 模型-视图-控制器 强分离输入、处理、输出 SOA 面向服务架构 服务是独立应用系统 ESB 企业服务总线 服务间信息交换的公共通道 EDB 企业数据总线 数据层面的集成 TOGAF The Open Group 架构框架 ADM 是核心方法 ADM 架构开发方法 10 个阶段环状排列 CSF 关键成功因素法 找企业成功关键 SST 战略目标集转化法 反映人的要求 BSP 企业系统规划法 自上而下识别，自下而上设计 3. 典型例题（案例分析题） 例题 1：选择题 题目：在信息化工程总体规划的方法论中，（ ）是通过分析找出使得企业成功的关键因素，然后再围绕这些关键因素来确定系统的需求，并进行规划。\nA. 战略目标集转化法 B. 关键成功因素法 C. 企业系统规划法 D. 信息系统工程法\n参考答案：B 解析：CSF 关键成功因素法正是通过分析找出使企业成功的关键因素，围绕其确定需求。\n例题 2：选择题 题目：信息化建设生命周期的顺序是（ ）。\nA. 系统设计、系统分析、系统规划、系统实施、系统运行和维护 B. 系统规划、系统分析、系统设计、系统实施、系统运行和维护 C. 系统规划、系统分析、系统设计、系统实施、系统运行和维护 D. 系统分析、系统规划、系统设计、系统实施、系统运行和维护\n参考答案：C 解析：正确顺序是系统规划 → 系统分析 → 系统设计 → 系统实施 → 系统运行和维护。\n例题 3：简答题 题目：请列举信息系统架构中较为常用的架构模型。\n参考答案： 传统的信息系统架构中架构模型主要关注应用系统架构，典型的应用系统架构包括：\n单体应用架构 二层客户端/服务器架构 三层客户端/服务器架构 三层浏览器/服务器架构 多层客户端/服务器架构 面向服务的架构（SOA） 企业服务总线架构 说明：在企业应用中，复杂的面向服务架构会加重信息系统开发和管理负担，为了规避成本问题，多采用企业服务总线或企业数据总线架构模式。\n4. 论文素材 本章是论文题出题范围，以下 3 个题目方向可以重点准备：\n论企业信息系统的架构选型与演进\n写作要点：从单体到 C/S 到 B/S 到 SOA 的演进过程，TOGAF 框架的应用 论面向服务架构（SOA）在企业中的应用\n写作要点：服务粒度、ESB、协议标准化（UDDI/WSDL/SOAP） 论企业架构（EA）方法论在系统设计中的应用\n写作要点：TOGAF/ADM 阶段、信息化 9 特征、BSP 方法应用 5. 高频考点 5 大体系结构风格：每年必考 1 题 C/S、B/S、二层/三层/多层 C/S 区分：案例题常考 MVC 三角色职责：基础题必出 TOGAF 与 ADM：概念题 CSF/SST/BSP 三大规划方法：必须能区分 信息化建设生命周期顺序：送分题 SOA 与 ESB 关系：高频综合题 ","date":"2024-01-01T00:00:00Z","permalink":"/p/15-xin-xi-xi-tong-jia-gou-she-ji-shi-jian/","title":"15-信息系统架构设计实践"},{"content":"16-层次式架构设计实践（第16小时） 软考-系统架构设计师 | 第4篇 架构设计实践知识 出题形式：下午案例分析题（必出 25 分）+ 上午选择题（2-5 分）+ 论文题 分值占比：约 25-30 分（重点！必出案例）\n0. 考点分析 层次式架构 4 层划分：表现层 / 中间层 / 访问层 / 数据层 MVC / MVP / MVVM 三种模式：表现层设计 业务逻辑层组件设计：Domain Model-Service-Control 数据访问 5 种模式：在线访问、DAO、DTO、离线数据、ORM ACID 事务原则：原子性、一致性、隔离性、持久性 物联网三层架构：感知层 / 网络层 / 应用层 架构污水池反模式：层间无业务逻辑的问题 1. 核心架构知识 1.1 层次式体系结构概述 定义：软件体系结构为软件系统提供了结构、行为和属性的高级抽象，由构成系统的元素描述这些元素的相互作用、指导元素集成的模式以及这些模式的约束组成。\n核心思想：将系统组成为一个层次结构，每一层为上层服务，并作为下层客户。\n层次式应用的组成（4 层结构）：\n1 2 3 4 5 6 7 8 9 ┌─────────────────┐ │ 表现层 │ ← 用户界面 ├─────────────────┤ │ 中间层 │ ← 业务逻辑 ├─────────────────┤ │ 访问层 │ ← 数据访问 ├─────────────────┤ │ 数据层 │ ← 数据库 └─────────────────┘ 特点：\n关注点分离：每层中的组件只负责本层的逻辑 接口一致性：只要给相邻层提供相同的接口，允许每层用不同方法实现 支持软件重用 注意事项：\n容易成为污水池反模式（Architecture Sinkhole Anti-patter）：请求流简单地穿过几个层，每层里面基本没有做任何业务逻辑 分层架构可能会让应用变得庞大 1.2 表现层框架设计 1.2.1 MVC 模式 MVC 把一个应用的输入、处理、输出流程按照视图、控制、模型的方式进行分离。\n组件 职责 控制器（Controller） 接受用户的输入，并调用模型和视图去完成用户的需求 模型（Model） 应用程序的主体部分，表示业务数据和业务逻辑 视图（View） 用户看到并与之交流的界面 优点：\n允许多种用户界面的扩展 易于维护 易于构建功能强大的用户界面 增加应用的可拓展性、强壮性、灵活性 1.2.2 MVP 模式 Model 提供数据，View 负责显示，Controller/Presenter 负责逻辑的处理。\nMVP 与 MVC 的区别：MVP 进一步降低了 Presenter 对 View 的依赖。\n优点：\n模型与视图完全分离，可以修改视图而不影响模型 所有的交互都发生在一个地方—Presenter 内部 可以将一个 Presenter 用于多个视图，而不需要改变 Presenter 的逻辑 如果把逻辑放在 Presenter 中，就可以脱离用户接口来测试这些逻辑（单元测试） 1.2.3 MVVM 模式 View 与 Model 的交互通过 ViewModel 来实现，两者不能直接通信。\n核心：ViewModel 通过 DataBinding 实现 View 与 Model 之间的双向绑定 内容包括：数据状态处理、数据绑定及数据转换 与 MVP 区别：MVVM 是双向数据绑定，而 MVP 是单向通信 1.3 中间层（业务层）框架设计 1.3.1 业务逻辑层组件设计 业务逻辑层组件分为接口和实现类两个部分：\n接口：定义业务逻辑组件必须实现的方法 实现类：按模块设计，每个模块设计一个业务逻辑组件 以多个 DAO 组件作为基础，对外提供系统的业务逻辑服务 1.3.2 业务逻辑层工作流设计 WFMC 定义：业务流程的全部或部分自动化，文档、信息或任务按照一定的过程规则流转，实现组织成员间的协调工作以达到业务的整体目标。\n工作流参考模型 5 大组件：\n过程定义工具 工作流引擎 工作流客户端应用 相关应用 管理与监视工具 1.3.3 业务逻辑层实体设计 逻辑层实体提供对业务数据及相关功能的状态编程访问 可使用具有复杂架构的数据（通常来自多个相关表） 可序列化，以保持它们的当前状态 1.3.4 业务逻辑层框架（Domain Model-Service-Control） 元素 含义 Domain Model 仅仅包含业务相关的属性的领域层业务对象 Service 业务过程实现的组成部分，是应用程序的不同功能单元，通过良好接口和契约联系起来 Control 服务控制器，服务之间的纽带，不同服务之间的切换通过它来实现 1.4 数据访问层设计 1.4.1 数据访问 5 种模式 模式 特点 在线访问 最常用，占用一个数据库连接，每个操作通过这个连接与数据源交互 DAO J2EE 标准模式，将底层数据访问与高层业务逻辑分离 DTO EJB 设计模式之一，跨越进程/网络边界传输数据 离线数据模式 以数据为中心，数据预定义结构存放，独立于后台连接 ORM 工具/平台帮助将应用数据转换成关系型数据库记录 典型 DAO 实现：\n一个 DAO 工厂类 一个 DAO 接口 一个实现了 DAO 接口的具体类 数据传输对象 1.4.2 工厂模式 定义一个用于创建对象的接口，让子类决定实例化哪一个类。处理对多种数据库的操作时使用。\n1.4.3 ORM 与 Hibernate ORM：在关系型数据库和对象之间作映射 Hibernate：O/R 映射方案，映射普通 Java 对象模型到持久对象 1.4.4 事务处理设计 - ACID 原则 事务必须服从 ISO/IEC 所制定的 ACID 原则：\n原则 含义 A - 原子性（Atomicity） 事务执行过程中的任何失败都将导致事务所做的任何修改失效 C - 一致性（Consistency） 当事务执行失败时，所有被该事务影响的数据都应该恢复到事务执行前的状态 I - 隔离性（Isolation） 在事务执行过程中对数据的修改，在事务提交之前对其他事务不可见 D - 持久性（Durability） 已提交的数据在事务执行失败时，数据的状态都应该正确 注意：隔离性是\u0026quot;提交之前\u0026quot;不可见，不是\u0026quot;提交之后\u0026quot;。\n1.4.5 连接对象管理 建立数据库连接池，提供高效的连接分配、使用策略，保证数据库连接的有效复用。\n1.5 数据架构规划与设计 数据库设计与类的设计融合：类和类之间关系的正确识别是关键 数据库设计与 XML 设计融合：XML 文档存储方式有基于文件、基于数据库两种 1.6 物联网层次架构设计 层次 功能 类比 典型设备 感知层 识别物体、采集信息 皮肤和五官 二维码、RFID、摄像头、GPS、传感器、M2M 终端、传感器网关 网络层 传递信息和处理信息 神经中枢和大脑 通信网与互联网融合网络、网络管理中心、信息中心、智能处理中心 应用层 实现广泛智能化 社会分工 物联网与行业专业技术深度融合 1.7 实践案例 案例 1：传统电商系统的层次式架构\n表现层：HTML + JavaScript（视图） 中间层：Spring MVC 控制器 + Service 业务逻辑 访问层：MyBatis/Hibernate ORM 数据层：MySQL 数据库 案例 2：智能工厂的物联网层次架构\n感知层：温湿度传感器、RFID、PLC 设备 网络层：工业以太网、MQTT 消息中间件 应用层：MES、ERP 工业管理系统 2. 关键概念速查 概念 定义/说明 常见考点 MVC Model-View-Controller 强分离输入、处理、输出 MVP Model-View-Presenter Presenter 进一步解耦 MVVM Model-View-ViewModel 双向数据绑定（DataBinding） DAO Data Access Object J2EE 标准模式 DTO Data Transfer Object 跨进程数据传输 ORM Object-Relation Mapping 对象/关系映射 Hibernate ORM 框架 Java 主流 ORM ACID 事务 4 大特性 注意隔离性是提交\u0026quot;前\u0026quot; Domain Model 领域模型 业务属性对象 Service 服务 业务过程组成 Control 控制器 服务间切换 污水池反模式 Sinkhole Anti-pattern 层间无业务逻辑 感知层 物联网最底层 传感器、RFID、GPS 网络层 物联网中间层 通信网络 应用层 物联网最上层 行业应用 3. 典型例题（案例分析题） 例题 1：选择题 题目：软件体系结构为软件系统提供了（ ）的高级抽象。\nA. 继承、多态、实现 B. 关联、扩展、泛化 C. 结构、行为、属性 D. 构件定义、访问方式、组织部署\n参考答案：C 解析：软件体系结构为软件系统提供了结构、行为和属性的高级抽象。\n例题 2：选择题 题目：MVC 模式强制性地把一个应用的（ ）流程进行分离，形成了控制器、模型、视图三个核心模块。\nA. 启动、运行、结束 B. 输入、处理、输出 C. 前端/客户端、服务端、数据库 D. 接受请求、处理请求、返回请求\n参考答案：B 解析：MVC 强制性分离的是输入、处理、输出。\n例题 3：选择题 题目：工作流参考模型包括的组件是（ ）。\nA. 过程定义工具、工作流引擎、工作流客户端应用、相关应用、管理与监视工具 B. 工作流定义工具、工作流引擎、工作流客户端应用、相关应用、管理与监视工具 C. 工作流定义工具、工作流引擎、工作流客户端应用、工作流 API、管理与监视工具 D. 过程定义工具、工作流引擎、工作流客户端应用、工作流 API、管理与监视工具\n参考答案：A 解析：工作流参考模型包括过程定义工具、工作流引擎、工作流客户端应用、相关应用、管理与监视工具。\n例题 4：选择题（陷阱题） 题目：关于 ACID 的说法错误的是（ ）。\nA. 事务的原子性表示事务执行过程中的任何失败都将导致事务所做的任何修改失效 B. 一致性表示当事务执行失败时，所有被该事务影响的数据都应该恢复到事务执行前的状态 C. 隔离性表示在事务执行过程中对数据的修改，在事务提交之后对其他事务不可见 D. 持久性表示已提交的数据在事务执行失败时，数据的状态都应该正确\n参考答案：C 解析：隔离性是\u0026quot;提交之前\u0026ldquo;对其他事务不可见，不是\u0026quot;提交之后\u0026rdquo;。\n例题 5：选择题 题目：物联网的感知层用于识别物体、采集信息。下列（ ）不属于感知层设备。\nA. 摄像头 B. GPS C. 扫描仪 D. 指纹\n参考答案：D 解析：感知层主要功能是识别对象、采集信息。摄像头、GPS、扫描仪都是感知层设备。指纹是人的特征属性，不是感知层设备。\n4. 论文素材 本章是论文题出题范围，以下 3 个题目方向可以重点准备：\n论层次式架构设计方法在企业级应用中的应用\n写作要点：4 层架构（表现层/中间层/访问层/数据层）、MVC 工作流 实战案例：Spring + MyBatis + MySQL 架构 论企业信息系统表现层架构设计与优化\n写作要点：MVC / MVP / MVVM 的对比、选择依据 实战案例：从 MVC 演进到 MVVM 解决双向数据绑定问题 论面向物联网应用系统的层次式架构设计\n写作要点：感知层/网络层/应用层、设备选型、协议设计 实战案例：智能工厂、智能农业、智慧城市 5. 高频考点 MVC / MVP / MVVM 的区别：每年必考 ACID 4 大特性：必出选择，重点是隔离性的\u0026quot;提交之前\u0026quot; DAO / DTO / ORM：3 种数据访问模式区分 物联网 3 层架构：感知层设备识别 Domain Model-Service-Control：业务层三件套 层次式架构的污水池反模式：易被忽视的概念 工作流参考模型 5 大组件：必背 ","date":"2024-01-01T00:00:00Z","permalink":"/p/16-ceng-ci-shi-jia-gou-she-ji-shi-jian/","title":"16-层次式架构设计实践"},{"content":"17-云原生架构设计实践（第17小时） 软考-系统架构设计师 | 第4篇 架构设计实践知识 出题形式：下午案例分析题（必出 25 分）+ 上午选择题（2-4 分）+ 论文题 分值占比：约 25-30 分（重点！必出案例）\n0. 考点分析 云原生定义与特点：剥离非业务代码、委托非功能性 云原生 7 大原则：服务化、弹性、可观测、韧性、自动化、零信任、持续演进 6 大架构模式：服务化、Mesh 化、Serverless、存储计算分离、分布式事务、可观测、事件驱动 5 种分布式事务模式：XA / BASE / TCC / SAGA / SEATA AT 容器 vs 虚拟化 vs 传统部署 Serverless 4 特点 Service Mesh（Istio/Linkerd/Consul） 3 种云原生反模式 1. 核心架构知识 1.1 云原生架构内涵 定义：云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的非业务代码部分进行最大化地剥离，让云设施接管应用中原有的大量非功能特性（弹性、韧性、安全、可观测性、灰度等），使业务不再有非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。\n应用特点：\n代码结构发生巨大变化：不再需要掌握文件及其分布式处理技术、各种复杂的网络技术 非功能性特性大量委托：高可用、容灾、安全、可运维、易用、可测试、灰度等 高度自动化的软件交付：自动部署到成千上万的节点上 1.2 云原生 7 大原则 原则 含义 服务化原则 通过服务化架构把不同生命周期的模块分离出来，分别进行业务迭代 弹性原则 系统的部署规模可以随着业务量的变化而自动伸缩 可观测原则 通过日志、链路跟踪和度量等手段，使多次服务调用的耗时、返回值和参数都清晰可见 韧性原则 软件所依赖的软硬件组件出现各种异常时，软件表现出来的抵御能力 所有过程自动化原则 让自动化工具理解交付目标和环境差异，实现整个软件交付和运维的自动化 零信任原则 不应该信任网络内部和外部的任何人/设备/系统，需要基于认证和授权重构访问控制的信任基础 架构持续演进原则 架构具备持续演进能力 1.3 云原生 6 大架构模式 1.3.1 服务化架构模式 以应用模块为颗粒度划分应用软件 以**接口契约（IDL）**定义业务关系 以**标准协议（HTTP、gRPC）**确保互联互通 结合 DDD（领域驱动设计）、TDD（测试驱动开发）、容器化部署 1.3.2 Mesh 化架构模式 把中间件框架（RPC、缓存、异步消息）从业务进程中分离 中间件 SDK 与业务代码进一步解耦 中间件升级对业务进程没有影响 1.3.3 Serverless 模式 业务流量到来/事件发生时，云启动/调度业务进程 处理完成后自动关闭/调度业务进程 开发者不用关心应用运行地点、操作系统、网络配置、CPU 性能 适用场景：事件驱动的数据计算任务、计算时间短的请求/响应应用、没有复杂相互调用的长周期任务 1.3.4 存储计算分离模式 分布式环境中的 CAP 困难（C-一致性、A-可用性、P-分区容错性）最多满足其中两个 无状态应用不存在一致性维度，可获得更好的可用性和分区容错性，因而弹性更好 1.3.5 分布式事务模式（5 种对比） 模式 机制 优点 缺点 XA 模式 2PC 两阶段提交 强一致性 性能差（两次网络交互） BASE 模式 基于消息的最终一致性 性能高 通用性有限（最终一致） TCC 模式 Try-Confirm-Cancel 二阶段 隔离性可控，高效 业务侵入性强，开发维护成本高 SAGA 模式 正向事务 + 补偿事务 长事务支持 开发维护成本高 SEATA AT 模式 二阶段委托给框架 + 取消行锁 高性能，无代码工作量 有使用场景限制 1.3.6 可观测架构（3 大支柱） 支柱 作用 Logging 提供多个级别跟踪，如 INFO/DEBUG/WARNING/ERROR Tracing 收集从前端到后端的访问日志聚合，形成完整调用链路跟踪 Metrics 提供系统量化的多维度度量（并发度、耗时、可用时长、容量） 1.3.7 事件驱动架构（EDA） 应用/组件间的集成架构模式。适用于：\n增强服务韧性 数据变化通知 构建开放式接口 事件流处理 CQRS（命令查询的责任分离）：把对服务状态有影响的命令用事件发起，对状态没有影响的查询才使用同步 API 1.4 云原生反模式（3 种） 庞大的单体应用：缺乏依赖隔离，代码耦合，整体扩容难 单体应用\u0026quot;硬拆\u0026quot;为微服务：强行拆分耦合度高、代码量少的模块；拆分后分布式调用严重影响性能 缺乏自动化能力的微服务：人均负责模块数上升，工作量增大 1.5 云原生相关技术 1.5.1 容器技术 容器作为标准化软件基础单元：将应用及其所有依赖项打包发布，由于依赖项齐备，应用不再受环境限制，在不同计算环境间快速、可靠地运行。\n部署模式对比：\n维度 传统部署 虚拟化部署 容器部署 OS 共享 每 VM 独立 OS 共享 OS 启动速度 最慢 慢 秒级 资源占用 大 中 小 隔离性 弱 强 中 1.5.2 容器编排技术 8 大能力：\n资源调度 应用部署与管理 自动修复 服务发现与负载均衡 弹性伸缩 声明式 API 可扩展性架构 可移植性 1.5.3 微服务设计 4 大约束 约束 内容 微服务个体约束 在业务领域划分上应是相互独立的 微服务之间横向关系 处理可发现性（自动感知变化）和可交互性（调用方式） 微服务与数据层纵向约束 提倡 DSS（数据存储隔离），数据访问必须通过对应微服务 API 全局分布式约束 全自动 CI/CD 流水线，支持蓝绿、金丝雀发布策略 1.5.4 无服务器（Serverless）4 大特点 全托管的计算服务：客户只编写代码，无须关注开发、运维、安全、高可用 通用性：结合 BaaS API 支撑云上所有重要类型应用 自动弹性伸缩：无须为资源使用提前容量规划 按量计费：成本有效降低，无须为闲置资源付费 关注点：计算资源弹性调度（容错、资源利用率、性能、数据驱动）、负载均衡和流控、安全性\n1.5.5 服务网格（Service Mesh） 目的：将微服务间的连接、安全、流量控制和可观测等通用功能下沉为平台基础设施，实现应用与平台基础设施的解耦。\n架构：服务 A 调用服务 B 的所有请求都被其下的服务代理截获，代理服务 A 完成到服务 B 的服务发现、熔断、限流等策略，控制平面（Control Plane）配置策略。\n主要技术：Istio、Linkerd、Consul\n1.6 实践案例 案例 1：电商大促场景的云原生实践\n服务化：订单、商品、用户、支付拆分为微服务 弹性：K8s HPA 根据 CPU/流量自动扩缩容 韧性：Sentinel 限流熔断 可观测：Prometheus + Grafana + Jaeger 案例 2：Serverless 文件处理\n用户上传文件 → 触发函数计算 → 处理完成后自动销毁 适用场景：图片压缩、日志分析、转码 2. 关键概念速查 概念 定义/说明 常见考点 云原生 基于云原生技术的架构原则和设计模式集合 7 大原则、6 大模式 IDL Interface Description Language 接口契约 DDD Domain-Driven Design 领域驱动设计 TDD Test-Driven Design 测试驱动开发 CAP Consistency/Availability/Partition tolerance 三选二 2PC Two-Phase Commit 两阶段提交 TCC Try-Confirm-Cancel 业务侵入性强 SAGA 长事务拆分 补偿事务 BASE Basically Available/Soft state/Eventually consistent 弱一致 XA 分布式事务规范 强一致但慢 SEATA AT 阿里分布式事务 自动回滚 CQRS Command Query Responsibility Segregation 命令查询分离 EDA Event-Driven Architecture 事件驱动 Serverless 无服务器 4 大特点 Service Mesh 服务网格 Istio/Linkerd HPA Horizontal Pod Autoscaler K8s 弹性伸缩 蓝绿发布 Blue-Green Deployment 两套环境切换 金丝雀发布 Canary Release 灰度发布 DSS Data Storage Segregation 数据存储隔离 3. 典型例题（案例分析题） 例题 1：选择题（陷阱题） 题目：云计算无法为企业带来的改进是（ ）。\nA. 通过 DevSecOps 应用开发模式，业务功能开发更加敏捷，提升迭代速度，成本更低 B. 企业软件架构可以获得强大的可伸缩性和高可用性 C. 结合云平台全方位企业级安全服务和安全合规能力，保障企业应用在云上安全构建 D. 企业的开发人员只须关注业务代码部分的开发，非业务功能可以完全委托给云原生架构来解决\n参考答案：D 解析：云原生架构可以将非业务代码部分最大化剥离，让云设施接管大量非功能特性，但无法接管所有的非功能特性。\n例题 2：选择题 题目：下列关于云原生架构原则的描述，错误的是（ ）。\nA. 服务化原则、弹性原则、韧性原则 B. 可观测原则、所有过程自动化原则 C. 零信任原则、接口隔离原则 D. 架构持续演进原则\n参考答案：C 解析：接口隔离原则是面向对象设计原则，不是云原生架构原则。\n例题 3：选择题（陷阱题） 题目：关于微服务的描述，错误的是（ ）。\nA. 微服务是将后端单体应用拆分为松耦合的多个子应用 B. 微服务相对独立，通过解耦研发、测试与部署流程，提高整体迭代效率 C. 微服务与数据层之间的纵向约束的含义是：在合理划分好微服务间的边界后，主要从微服务的可发现性和可交互性处理服务间的关系 D. 驾驭微服务的前提是高效运维整个系统，从技术上要准备全自动化的 CI/CD 流水线\n参考答案：C 解析：可发现性和可交互性是横向关系。正确的纵向约束是：对于微服务的私有数据的访问都必须通过当前微服务提供的 API 来访问（DSS 数据存储隔离原则）。\n例题 4：选择题 题目：无服务器技术的特点之一是全托管的计算服务：客户只需要编写代码构建应用，无须关注同质化的、负担繁重的基于服务器等基础设施的（ ）等工作。\nA. 开发、测试、发布、交付 B. 开发、运维、安全、高可用 C. 机房建设、服务器装机、操作系统安装、软件安装 D. 资源调度、性能压测、负载均衡、数据统计\n参考答案：B 解析：无服务器免去的是开发、运维、安全、高可用等负担。\n例题 5：选择题 题目：容器作为标准化软件单元，它将应用及其所有依赖项打包，使应用不再受（ ）限制，在不同计算环境间快速、可靠地运行。\nA. 环境 B. 操作系统 C. 硬件 D. 网络\n参考答案：A 解析：B、C、D 都有局限性，A 最贴切——容器消除了对环境（OS、硬件、网络）的依赖。\n4. 论文素材 本章是论文题出题范围，以下 3 个题目方向可以重点准备：\n论云原生架构在企业数字化转型中的应用\n写作要点：7 大原则、容器+编排、Serverless 实践 实战案例：从传统单体迁移到 K8s + 微服务的过程 论微服务架构的分布式事务处理方案选择\n写作要点：CAP 理论、5 种事务模式对比、SEATA AT 实践 实战案例：电商订单+库存+支付的事务一致性 论云原生应用的可观测性体系构建\n写作要点：Logging/Tracing/Metrics 三大支柱 实战案例：Prometheus + Grafana + Jaeger 监控体系 5. 高频考点 7 大原则：每年必考，零信任/接口隔离的区分 6 大架构模式：服务化/Mesh 化/Serverless/存储计算分离/分布式事务/事件驱动 5 种分布式事务模式对比：CAP 理论与 BASE 妥协 容器 vs 虚拟化：部署模式对比 微服务 4 大约束：横纵向约束区分 Serverless 4 大特点：免去开发/运维/安全/高可用 可观测 3 大支柱：Logging/Tracing/Metrics Service Mesh 主要技术：Istio/Linkerd/Consul ","date":"2024-01-01T00:00:00Z","permalink":"/p/17-yun-yuan-sheng-jia-gou-she-ji-shi-jian/","title":"17-云原生架构设计实践"},{"content":"18-面向服务架构设计实践（第18小时） 软考-系统架构设计师 | 第4篇 架构设计实践知识 出题形式：下午案例分析题（必出 25 分）+ 上午选择题（2-5 分）+ 论文题 分值占比：约 25-30 分（重点！必出案例）\n0. 考点分析 SOA 与微服务对比：粗粒度 vs 细粒度、集中式 vs 去中心化 SOA 参考架构 6 大类：业务逻辑服务/控制服务/连接服务/业务创新优化/开发服务/IT 服务管理 Web Service 三大协议：UDDI / WSDL / SOAP + REST SOA 8 大设计原则：无状态、单一实例、明确定义接口、自包含模块化、粗粒度、松耦合、重用、互操作 3 大设计模式：服务注册表、企业服务总线（ESB）、微服务 4 种微服务架构模式：聚合器、链式、数据共享、异步消息 SOA 实施过程：服务模型 + 业务流程 1. 核心架构知识 1.1 SOA 与微服务对比 维度 SOA 微服务 服务粒度 粗粒度 更加精细 存在方式 多以应用形式 独立的进程 通信方式 ESB 重通信、智能路由 HTTP RESTful，轻量级 部署 倾向于集中式部署 分布式去中心化 适用场景 企业级，传统业务 互联网业务 接口方式 WSDL/SOAP 等重量级 HTTP RESTful 通用化 高并发 一般 局限（无调用关系时才有提升） 1.2 SOA 参考架构（IBM WebSphere 6 大类） 类别 描述 业务逻辑服务 实现业务逻辑的服务和执行能力（业务应用服务、业务伙伴服务、应用和信息资产） 控制服务 实现人（People）、流程（Process）、信息（Information）集成的服务 连接服务 通过企业服务总线（ESB）实现服务间连接性 业务创新和优化服务 监控业务系统运行时服务的业务性能，并采取措施适应市场变化 开发服务 贯彻整个软件生命周期，从需求分析到建模、设计、开发、测试、维护 IT 服务管理 支持业务系统运行的基础设施管理或服务（安全、目录、系统管理、资源虚拟化） 1.3 SOA 主要协议和规范 1.3.1 三大基础协议 协议 含义 作用 UDDI 统一描述、发现和集成 商业实体彼此发现，定义在 Internet 上互相作用 WSDL Web 服务描述语言 XML 语言，描述 Web 服务的 3 个基本属性 SOAP 简单对象访问协议 分散/分布式环境中交换信息的简单协议，基于 XML WSDL 描述的 3 个基本属性：\n服务做些什么—服务所提供的操作（方法） 如何访问服务—数据格式以及必要协议 服务位于何处—协议相关的地址，如 URL 1.3.2 REST 规范 为了让不同的软件/应用程序在任何网络环境下都可以进行信息传递。微服务对外以 REST API 形式暴露给调用者。\nREST 4 大核心：\n核心 含义 资源 互联网中一切暴露给客户端的事物 表述 REST 中用表述描述资源在 Web 中某一时间的状态 状态转移 应用状态（客户端）+ 资源状态（服务端） 超链接 通过嵌入链接和其他资源建立联系 1.4 SOA 设计的标准要求 标准 内容 文档标准化 平台独立的自我描述 XML 文档（WSDL） 通信协议标准 使用 XML Schema（XSD）定义消息 应用程序统一登记与集成 通过 Registry（UDDI）维护 服务质量（QoS） 可靠性、安全性、策略、控制、管理 控制语言：BPEL4WS 或 WSBPEL（Web Service Business Process Execution Language）\n管理协议：WSDM（Web Services Distributed Management）\n1.5 SOA 8 大设计原则 无状态：避免服务请求者依赖于服务提供者的状态 单一实例：以高内聚的实现方法，避免功能冗余 明确定义的接口：WSDL 定义接口，划分公共接口与内部实现 自包含和模块化：封装稳定、重复出现的活动和组件 粗粒度：服务数量不大，消息交互而非 RPC，交互频度低 服务之间的松耦合性：服务使用者看到的是接口 重用能力：服务可以复用 互操作性、兼容和策略声明：利用策略定义可配置的互操作语义 1.6 SOA 的作用 主要作用：打破信息孤岛，把应用和资源转换成服务；把这些服务变成标准的服务，形成资源的共享。\n1.7 SOA 设计模式（3 大类） 1.7.1 服务注册表模式 支持驱动 SOA 治理的服务合同、策略和元数据的开发、发布和管理。\n服务注册：服务提供者向注册表公布功能 服务位置：服务应用开发者查询注册服务 服务绑定：服务消费者利用服务合同开发代码，绑定、调用注册服务 1.7.2 企业服务总线（ESB）模式 提供标准的软件底层架构，各种组件以服务单元方式\u0026quot;插入\u0026quot;到平台运行，以标准消息通信方式交互。\n6 大核心功能：\n提供位置透明性的消息路由和寻址服务 提供服务注册和命名的管理功能 支持多种消息传递范型（请求/响应、发布/订阅） 支持多种传输协议 支持多种数据格式及其相互转换 提供日志和监控功能 1.7.3 微服务模式 将大型单个应用或服务拆分成多个微服务，可扩展单个组件而不是整个应用程序堆栈，从而满足服务等级协议。\n5 大特点：\n复杂应用解耦：单一模块应用分解为多个微服务，保持总体功能不变 独立：微服务在系统软件生命周期中是独立开发、测试、部署的 技术选型灵活：去中心化，每个团队可选择合适的技术 容错：故障隔离在单个服务中，其他微服务可重试、平稳退化 松耦合，易扩展：每个服务之间松耦合，可独立扩展 1.8 4 种微服务架构模式方案 模式 描述 聚合器微服务 聚合器充当流程指挥者，调用多个微服务实现系统所需功能 链式微服务 收到请求后，发生多个服务间的嵌套递归调用，返回合并处理的响应 数据共享微服务 适用于从单体到微服务的过渡阶段，服务间存在强耦合（如共享缓存与数据库） 异步消息传递微服务 对不必同步运行的业务逻辑，使用消息队列代替 REST 实现请求、响应 1.9 微服务架构面临的问题与挑战 服务发现与服务调用链跟踪变得困难 很难实现传统数据库的强一致性，转而追求最终一致性 1.10 构建 SOA 应注意的问题 原有系统集成需求：\n应用程序集成的需求 终端用户界面集成的需求 流程集成的需求 已有系统信息集成的需求 服务粒度控制：\n暴露在系统外部的服务推荐使用粗粒度的接口 相对较细粒度的服务接口通常用于企业系统架构的内部 无状态服务设计：SOA 架构中的服务应该是无状态的，不应依赖于其他服务的上下文和状态。\n1.11 SOA 实施过程 选择 SOA 解决方案的 3 个方面：\n尽量选择能进行全局规划的方案 选择时充分考虑企业自身的需求 从平台、实施等技术方面进行考察 业务流程分析：\n建立服务模型：自顶向下分解法、业务目标分析法、自底向上分析法 建立业务流程：建立业务对象（实体、过程、事件等）→ 建立服务接口 → 建立服务流程 1.12 实践案例 案例 1：银行核心系统 SOA 改造\n业务领域拆分为账户、存款、贷款、支付、风险等服务 通过 ESB 集成遗留系统 使用 BPEL 编排业务流程 案例 2：电商系统的微服务化\n拆分为商品、订单、库存、支付、用户、推荐 6 大微服务 Spring Cloud Alibaba（Nacos/Sentinel/Seata） 通过 Feign + Ribbon 实现服务调用 异步消息用 RocketMQ 2. 关键概念速查 概念 定义/说明 常见考点 SOA Service-Oriented Architecture 面向服务架构 WSDL Web Services Description Language 描述 Web 服务的 XML UDDI Universal Description Discovery and Integration 服务注册与发现 SOAP Simple Object Access Protocol 简单对象访问协议 REST Representational State Transfer 资源表述性状态转移 ESB Enterprise Service Bus 企业服务总线 BPEL Business Process Execution Language 业务流程执行语言 WSDM Web Services Distributed Management Web 服务分布式管理 XSD XML Schema Definition XML 模式定义 RESTful 满足 REST 设计约束的架构 资源+表述+状态转移+超链接 聚合器模式 Aggregator 指挥者调用多个微服务 链式模式 Chained 服务嵌套递归调用 数据共享 Shared Data 过渡阶段共享缓存/DB 异步消息 Asynchronous Messaging MQ 代替 REST 粗粒度 Coarse-grained 外部接口推荐 细粒度 Fine-grained 内部接口使用 DSS Data Storage Segregation 数据存储隔离 3. 典型例题（案例分析题） 例题 1：选择题（陷阱题） 题目：下列关于 SOA 与微服务的描述，错误的是（ ）。\nA. 微服务相比于 SOA 更加精细，微服务更多地以独立的进程的方式存在，互相之间并无影响 B. 微服务提供的接口方式更加通用化，例如 HTTP RESTful 方式，各种终端都可以调用 C. 微服务更倾向于分布式去中心化的部署方式，在互联网业务场景下更适合 D. 微服务更容易实现出高并发的特性，有助于实现互联网业务的秒杀促销活动\n参考答案：D 解析：微服务在实现高并发方面是局限的。只有没有调用关系的微服务，相对于单体服务来说，才有并发性的提升。\n例题 2：选择题 题目：下列选项（ ）不是关于 SOA 的服务架构。\nA. 业务逻辑服务 B. 中间件服务 C. 连接服务 D. 控制服务\n参考答案：B 解析：SOA 的参考架构包括 6 类：业务逻辑服务、控制服务、连接服务、业务创新和优化服务、开发服务、IT 服务管理。没有\u0026quot;中间件服务\u0026quot;。\n例题 3：选择题 题目：WSDL 规范描述了 Web 服务的 3 个基本属性：（ ）。\nA. 服务做些什么 / 如何访问服务 / 服务位于何处 B. 服务做些什么 / 如何调用服务 / 服务性能 C. 服务接口 / 数据格式 / 调用方式 D. 服务可用性 / 数据格式 / 服务位置\n参考答案：A 解析：\n服务做些什么：服务所提供的操作（方法） 如何访问服务：数据格式以及必要协议 服务位于何处：协议相关的地址，如 URL 例题 4：选择题 题目：SOA 的设计原则为无状态、单一实例、明确定义的接口、（ ）、粗粒度、服务之间的松耦合性、重用能力、互操作性。\nA. 复用性和构件化 B. 自包含和模块化 C. 独立性和构件化 D. 隔离性和归一化\n参考答案：B 解析：SOA 8 大设计原则之一是自包含和模块化。\n例题 5：选择题 题目：微服务架构将一个大型的单个应用或服务拆分成多个微服务……每个服务可以（ ）。\nA. 独立进行开发、管理、迭代 B. 独立进行部署、运维、升级 C. 独立进行测试、交付、验收 D. 独立进行发布、发现、访问\n参考答案：A 解析：微服务围绕业务领域拆分，每个服务可以独立进行开发、管理和迭代。\n4. 论文素材 本章是论文题出题范围，以下 3 个题目方向可以重点准备：\n论面向服务架构（SOA）在企业级应用系统集成中的应用\n写作要点：ESB 作用、6 大服务类型、UDDI/WSDL/SOAP 协议应用 实战案例：银行/电信系统集成项目 论微服务架构的设计与实践\n写作要点：服务拆分原则、4 种微服务模式选择、最终一致性 实战案例：电商中台化改造 论 SOA 与微服务架构的对比与选型\n写作要点：粗细粒度、集中/去中心化、ESB 治理 实战案例：传统企业 → 互联网企业的架构演进 5. 高频考点 SOA 与微服务对比：每年必出，重点是高并发的局限性 SOA 6 大服务类型：易混淆，需逐字记忆 WSDL 3 大属性：服务做些什么/如何访问/位于何处 SOA 8 大设计原则：送分题，区分\u0026quot;自包含和模块化\u0026quot; ESB 6 大核心功能：经常考简答 4 种微服务架构模式：聚合器/链式/数据共享/异步消息 SOA 实施的 3 方面 + 业务流程分析 2 方面：综合题 REST 4 大核心：资源/表述/状态转移/超链接 ","date":"2024-01-01T00:00:00Z","permalink":"/p/18-mian-xiang-fu-wu-jia-gou-she-ji-shi-jian/","title":"18-面向服务架构设计实践"},{"content":"19-嵌入式系统架构设计实践（第19小时） 软考-系统架构设计师 | 第4篇 架构设计实践知识 出题形式：下午案例分析题（25 分） 分值占比：约 25 分\n0. 考点分析 嵌入式系统发展历程：SCM → MCU → SoC → 互联网嵌入式 → 智能化嵌入式 嵌入式处理器 5 大类：MPU / MCU / DSP / GPU / SoC 存储器分类：RAM（18 种）/ ROM（5 种） 总线分类：数据/地址/控制 总线，片内/系统/局部/通信 总线 看门狗：系统恢复能力 嵌入式操作系统内核架构：宏内核 vs 微内核 任务调度算法：RMS（最优）/ EDF / LLF 嵌入式数据库：eXtremeDB / SQLite 鸿蒙 OS 4 层架构：内核层/系统服务层/应用框架层/应用层 GENESYS 架构：3 组服务、6 大特征 ABSD / ADD / DARTS 设计方法 1. 核心架构知识 1.1 嵌入式系统发展历程（5 阶段） 阶段 硬件 软件 主要特点 SCM（单片微型计算机） 单片机 无操作系统，汇编语言 结构和功能相对单一，处理效率低，存储容量十分有限 MCU（微控制器） 单片机+嵌入式微处理器+外围电路+接口电路 简单操作系统 种类繁多，通用性弱，系统开销小，智能化控制突出 SoC（片上系统） 嵌入式微处理器 嵌入式操作系统 兼容性好，内核小，处理效率高 互联网嵌入式系统 微处理器+网络接口 嵌入式操作系统 集成网络接口，应用于网络环境 智能化嵌入式 微型传感器+智能服务设备 — 低能耗、高速度、高集成、高可信 1.2 嵌入式系统硬件 1.2.1 传统嵌入式系统硬件组成 微处理器（MCU/MPU） 存储器（RAM、ROM） 总线（内总线、外总线） 定时器/计数器（Timer） 看门狗（WatchDog） I/O 接口（串口、网络、USB、JTAG） 外部设备（UART、LED） 1.2.2 嵌入式处理器 5 大类 类别 全称 特点 MPU Micro Processor Unit（微处理器） 体积小、重量轻、成本低、可靠性高，但技术保密性差 MCU Micro Control Unit（微控制器） 单片化、体积小、功耗低、成本低、可靠性更高 DSP Digital Signal Processor（信号处理器） 哈佛结构、编译效率高、指令执行速度高 GPU Graphics Processing Unit（图形处理器） 专注浮点运算，弥补 CPU 运算速度不足 SoC System on Chip（片上系统） 片内再编程技术，使硬件功能可像软件一样编程配置 1.2.3 存储器分类 RAM 18 种（节选重点）：\nDRAM、SRAM、VRAM FPM DRAM、EDO DRAM、BEDO DRAM MDRAM、WRAM、RDRAM SDRAM、SGRAM、SB SRAM、PB SRAM DDR SDRAM、SLDRAM、CDRAM、DDRII、DRDRAM ROM 5 种：\nMASK ROM（掩模型） PROM（可编程） EPROM（可擦可编程） EEPROM（电可擦可编程） Flash Memory（快闪存储器） 1.2.4 总线分类 按信息种类 说明 数据总线 处理器与 RAM 间传输待处理和待存储的数据 地址总线 传输 RAM 中存储数据的地址 控制总线 传输处理器控制单元信号到周边设备 按连接部件 说明 片内总线 内部总线，连接 ALU、寄存器、指令部件等芯片内部元件 系统总线 内部总线，又称板级总线，连接微控制器/处理器、主存、I/O 局部总线 内部总线，连接少量组件用于交换数据 通信总线 外部总线，又称外设总线，连接外部设备或外部系统 总线拓扑结构：星型、树状、环型、总线型、交叉开关型（5 种）\n1.2.5 看门狗（WatchDog） 作用：嵌入式系统提供必需的系统恢复能力，在系统发生软件问题和程序跑飞时重新启动系统。\n基本原理：\n计数器自动计数 程序定期将其重置 如果系统卡死或程序跑飞，计数器溢出，进入中断处理 在设定时间间隔内，系统保留状态后复位重启 1.3 嵌入式系统软件 1.3.1 嵌入式操作系统（EOS）特点 可剪裁性、可移植性 强实时性、强紧凑性 高质量代码、强定制性 标准接口、强稳定性 弱交互性、强确定性 操作简捷、方便 较强的硬件适应性、可固化性 1.3.2 内核架构 类型 含义 宏内核 用户服务和内核服务在同一空间中实现，代码耦合度非常高 微内核 用户服务和内核服务在不同空间中实现，系统结构清晰，代码量少 1.3.3 任务管理 任务 3 种工作状态：\n执行状态：任务获得处理机，程序在处理机中执行 就绪状态：任务已获得处理机以外资源，待获得处理机即可执行 阻塞状态：执行状态任务因等待事件发生无法执行而放弃处理机 调度算法：\n类别 描述 离线调度 系统运行前确定调度信息（如时间驱动） 在线调度 系统运行中动态获得调度信息（如优先级驱动） 抢占调度 运行任务可能被打断 非抢占调度 运行任务不被打断 静态调度 任务优先级在设计时确定，不变化 动态调度 任务优先级在运行中确定，不断变化 3 大实时调度算法：\n算法 原理 备注 EDF（最早截止时间优先） 截止时间越早，优先级越高 LLF（最低松弛度优先） 紧急程度越高，优先级越高 RMS（单调速率） 周期越短，优先级越高 被认为是最优的 1.3.4 嵌入式数据库特点 嵌入式、实时性、移动性、伸缩性\n3 种分类：\n按嵌入对象：软件嵌入、设备嵌入、内存数据库 按系统结构：嵌入数据库、移动数据库、小型 C/S 结构 按存储位置：基于内存、基于文件、基于网络 典型产品：\neXtremeDB（基于内存）：最小化资源消耗、极小堆空间、动态数据结构本地支持 SQLite（基于文件）：开源、内嵌式、服务器客户端同进程 C/S、B/S、云数据库（基于网络） DBMS vs 嵌入式数据库：\n对比项 数据库管理系统 嵌入式数据库 操作用户 允许非开发人员操作 只允许应用程序访问和控制 访问控制 数据与程序分离 应用程序负责访问控制 发布部署 独立安装、部署、管理 与应用程序一同发布 1.3.5 嵌入式中间件 嵌入式应用和操作系统之间的中间软件，作用是屏蔽底层操作系统的异构性。\n常见功能：网络通信、内存管理、数据处理\n典型嵌入式中间件：消息中间件、分布式对象中间件\n1.4 嵌入式系统软件架构设计方法 方法 全称 关键点 ABSD Architecture-Based Software Design 基于架构的软件设计开发方法（见第9小时） ADD Attribute-Driven Design 属性驱动的软件设计方法 DARTS Design Approach for Real-Time System 实时系统设计方法 1.4.1 ADD 方法 输入：一组质量属性（可用性、性能、安全性等）场景 方法：利用对质量属性实现与架构设计之间的关系的了解（体系结构风格、质量战术等） 目标：在满足质量属性的基础上建立模块分解过程\n7 个阶段：\n评审 选择驱动因子 选择系统元素 选择设计概念 实体化元素和定义接口 草拟视图 分析评价 1.4.2 DARTS 方法 5 个部分：\n用实时结构化分析方法开发系统规范 将系统划分为多个并发任务 定义任务间接口 设计每个任务 设计过程的成果 优势：\n强调将系统分解为并发任务，并提供确认任务的标准 提供定义任务间接口的指南 强调用任务架构图的重要性 提供从实时结构化分析规格到实时结构化设计的转换 不足：\nDARTS 使用信息隐藏技术封装数据存储，封装性不好 如果实时结构化分析阶段完成得不好，任务的结构化工作就会更加困难 1.5 嵌入式系统软件架构实践 1.5.1 鸿蒙操作系统（HarmonyOS） 架构理念：分布式设计，实现 4 种分布式能力：\n分布式软总线 分布式设备系统的虚拟化 分布式数据管理 分布式任务调度 4 层架构（自下而上）：\n内核层（微内核设计）：内核抽象层 KAL 屏蔽多内核差异 系统服务层：核心能力集合 应用框架层：多语言用户程序框架、能力框架、各种硬件服务 API 应用层：系统应用 + 第三方应用 4 大技术特性：\n分布式架构用于终端操作系统，实现跨终端无缝协同体验 确定时延引擎和高性能进程间通信技术，实现系统的流畅 基于微内核架构，重塑终端设备的可信安全 统一集成开发环境，一次开发，多端部署，实现跨终端生态共享 1.5.2 GENESYS（跨领域嵌入式架构） 跨领域的通用嵌入式架构平台。采用消息交换方式实现软硬件构件的抽象级别提升。\nGENESYS 3 组服务：\n领域无关服务：核心服务（全局时间、消息传输）+ 选择服务（信息安全、外部存储、网关） 领域专用服务：领域特有的服务子集 + 特定服务组合 应用专用服务：包含中间件 6 大特征及优势：\n精确的构件定位：简单化、跨领域重用、规模经济型、健壮性、降低系统集成工作量 开放性：可集成、可升级、可扩展、遗产系统集成、降低成本 三级集成：芯片级、设备级、系统级 分层的服务：可重用性、领域定位、工效经济型 确定的核心：及时性、降低复杂性、可测试性、认证、故障掩蔽 标准的互联集成：对远程访问的保护、降低集成工作难度、常规人机交互、安全性 解决 3 大挑战：复杂性管理、系统健壮性、能量有效使用\n1.5.3 物联网操作系统软件架构 主要软件技术：\n开源操作系统：FreeRTOS 公共服务组件：网络协议、外设支持、POSIX 定制性服务组件：MQTT、HTTPS、PKCS #11、安全套件 5 大特征：\n内核实时性 内核尺寸伸缩性 架构可扩展性 高可靠性 低功耗 1.6 实践案例 案例 1：智能家居中鸿蒙 OS 的应用\n分布式软总线：手机+智能音箱+智能门锁无缝协同 一次开发，多端部署：同一 App 在手机/平板/智慧屏运行 微内核：低时延、高安全 案例 2：工业控制系统中的 GENESYS 应用\n芯片级集成：传感器节点 设备级集成：PLC、SCADA 系统级集成：MES、ERP 2. 关键概念速查 概念 定义/说明 常见考点 SCM 单片微型计算机 第一代嵌入式系统 MCU 微控制器 单片化 SoC 片上系统 片内可编程 MPU 微处理器 嵌入式处理器 DSP 数字信号处理器 哈佛结构 GPU 图形处理器 浮点运算 看门狗 WatchDog 系统跑飞时复位 宏内核 Monolithic 同一地址空间 微内核 Microkernel 不同地址空间 RMS 单调速率调度 周期短优先级高 EDF 最早截止时间优先 截止早优先 LLF 最低松弛度优先 紧急程度优先 ACID 数据库事务 原子、一致、隔离、持久 eXtremeDB 内存数据库 嵌入式场景 SQLite 文件数据库 嵌入式场景 ABSD 基于架构的设计 第9小时也讲 ADD 属性驱动设计 7 阶段 DARTS 实时系统设计 5 部分 鸿蒙 OS HarmonyOS 4 层架构、4 大特性 GENESYS 跨领域通用嵌入式架构 3 组服务、6 大特征 FreeRTOS 开源 RTOS 物联网操作系统 MQTT 消息队列遥测传输协议 IoT 协议 POSIX 可移植操作系统接口 UNIX 标准 PKCS#11 加密消息标准 密码接口 HDF HarmonyOS 驱动框架 鸿蒙特有 3. 典型例题（案例分析题） 例题 1：选择题 题目：以下关于鸿蒙操作系统的叙述中，不正确的是（ ）。\nA. 鸿蒙整体架构采用分层的层次化设计，从下向上依次为：内核层、系统服务层、框架层和应用层 B. 鸿蒙内核层采用宏内核设计，拥有更强的安全特性和低时延特点 C. 鸿蒙采用了分布式设计理念，实现了 4 种分布式能力 D. 架构的系统安全性主要体现在搭载 HarmonyOS 的分布式终端上，可以保证\u0026quot;正确的人，通过正确的设备，正确地使用数据\u0026quot;\n参考答案：B 解析：鸿蒙采用微内核架构，不是宏内核。\n例题 2：简答题 题目：GENESYS 架构的主要特征及优势是什么？\n参考答案： GENESYS 架构的主要特征及优势包括：\n精确的构件定位：简单化、跨领域重用、规模经济型、健壮性、降低系统集成工作量（5 个特征） 开放性：可集成、可升级、可扩展、遗产系统集成、降低成本（5 个特征） 三级集成：芯片级集成、设备级集成、系统级集成 分层的服务：可重用性、领域定位、工效经济型 确定的核心：及时性、降低复杂性、可测试性、认证、故障掩蔽 标准的互联集成：对远程访问的保护、降低集成工作难度、常规人机交互、安全性（4 个方面） 例题 3：简答题 题目：鸿蒙操作系统架构具有哪几个技术特性？\n参考答案：\n分布式架构用于终端操作系统，实现跨终端无缝协同体验 确定时延引擎和高性能进程间通信技术，实现系统的流畅 基于微内核架构，重塑终端设备的可信安全 统一集成开发环境，一次开发，多端部署，实现跨终端生态共享 例题 4：简答题 题目：嵌入式系统软件架构设计方法中的实时系统设计方法（DARTS）具有哪些优势和不足？\n参考答案：\n优势：\n强调将系统分解为并发任务，并提供确认任务的标准 提供定义任务间接口的指南 强调用任务架构图的重要性 提供从实时结构化分析规格到实时结构化设计的转换 不足：\nDARTS 使用信息隐藏技术封装数据存储，封装性不好 如果实时结构化分析阶段完成得不好，任务的结构化工作就会更加困难 4. 论文素材 本章是论文题出题范围，以下 3 个题目方向可以重点准备：\n论鸿蒙操作系统的分布式架构设计\n写作要点：4 层架构、4 大特性、4 种分布式能力 实战案例：智能家居跨设备协同 论嵌入式系统的实时调度算法选择\n写作要点：RMS/EDF/LLF 对比、抢占 vs 非抢占 实战案例：工业控制实时系统 论嵌入式数据库在物联网终端的应用\n写作要点：eXtremeDB/SQLite 对比、内存 vs 文件 实战案例：智能水电气表数据采集 5. 高频考点 嵌入式发展 5 阶段：必背 处理器 5 大类：MPU/MCU/DSP/GPU/SoC 宏内核 vs 微内核：鸿蒙是微内核 RMS 是最优调度算法：高频陷阱题 3 大实时调度算法：EDF/LLF/RMS 鸿蒙 OS 4 层架构 + 4 大技术特性：必出 GENESYS 6 大特征：简答题常考 DARTS 优势 4 条、不足 2 条：背熟 ","date":"2024-01-01T00:00:00Z","permalink":"/p/19-qian-ru-shi-xi-tong-jia-gou-she-ji-shi-jian/","title":"19-嵌入式系统架构设计实践"},{"content":"20-通信系统架构设计实践（第20小时） 软考-系统架构设计师 | 第4篇 架构设计实践知识 出题形式：下午案例分析题（25 分） 分值占比：约 25 分（选择+案例）\n0. 考点分析 局域网 6 种架构：单核心/双核心/环型/半全冗余/对等子域/层次子域 5G 网络架构：透明模式/非透明模式、5G 边缘计算 SDN（软件定义网络）：控制与转发分离 存储网络 3 大架构对比：DAS / NAS / SAN IPv4/IPv6 融合 3 种过渡技术：双协议栈/隧道/NAT 网络安全控制 5 大技术：防火墙/VPN/访问控制/隔离/协议 层次化网络 3 层模型：核心层/汇聚层/接入层 绿色网络设计 4 原则：标准化/集成化/虚拟化/智能化 1. 核心架构知识 1.1 局域网网络架构（6 种） 类型 优点 缺点 单核心架构 结构简单，设备投资节约，接入方便 核心压力大，扩展性差，可靠性不高 双核心架构 网络拓扑可靠，路由可热切换，可靠性高，局域网接入方便 投资较单核心高，路由冗余设计实施难度较高，核心端口密度要求较高 环型架构 接入方便 投资较高，路由冗余设计实施难度较高且易形成环路，核心端口密度要求较高 半/全冗余架构 结构灵活，路由灵活，方便扩展，可靠性高 结构零散，不便管理，不便排障 对等子域架构 路由控制灵活 子域间冗余设计实施难度较高，易形成环路或存在非法路由风险，子域互连设备性能要求高 层次子域架构 扩展性较好，路由控制灵活 子域路由冗余设计实施难度较高，易形成环路或存在非法路由风险，子域互连设备性能要求高 1.2 移动通信网网络架构 5G 系统为移动终端用户提供数据网络互连：\n数据网络：互联网、IP 媒体子系统、专用网络 接入方式：\n透明模式：5G 系统通过用户面功能接口接入运营商网络，通过防火墙或代理连至 Internet 非透明模式：5G 系统可直接或通过其他网络连接至运营商网络或 Internet 1.3 5G 网络边缘计算 作用：能为垂直行业提供诸如以时间敏感、高带宽为特征的业务就近分流服务。\n为用户提供极佳的服务体验 降低移动网络后端处理的压力 1.4 SDN（软件定义网络） 核心思想：通过控制与转发分离，将网络中交换设备的控制逻辑集中到一个计算设备上，控制面集中管控，提升网络管理配置能力。\n1.5 存储网络架构（3 大类对比） 对比项 DAS NAS SAN 架构类别 单机存储架构 网络存储架构 网络存储架构 访问方式 I/O 总线 网络 网络 资源利用 单机存储 共享存储 共享存储 访问媒介 总线 以太网 以太网/光纤通道 优势特点 易用易管理 设备成本低 易用易管理、可扩展性高、高性能、低延迟、灵活性高 详细说明：\nDAS（直连式存储）：存储设备通过 IDE/ATA/SCSI 接口或光纤通道直接连接到单台计算机，通过 I/O 访问存储设备 NAS（网络附加存储）：存储设备通过标准网络拓扑结构连接到计算机群组，通过 IP 局域网或广域网 TCP/UDP 协议，通过 RPC 接口访问 SAN（存储区域网络）：采用网状通道技术专门为存储建立的独立于 TCP/IP 网络之外的专用网络，通过网状通道交换机连接存储阵列和服务器 1.6 网络构建关键技术 IPv4 与 IPv6 融合组网 3 种过渡技术：\n技术 含义 双协议栈 两种协议在同一平台上双栈共存，同时运行 隧道技术 包括 ISATAP 隧道、6to4 隧道、over6 隧道、6over4 隧道 NAT（网络地址翻译） 将 IPv4 地址和 IPv6 地址分别看作内部地址和外部地址，实现地址转换 1.7 网络构建 1.7.1 网络需求分析维度 业务需求、用户需求、应用需求、计算机平台需求、网络需求\n1.7.2 网络技术遴选及设计 生成树协议 虚拟局域网（VLAN） 无线局域网（WLAN） 线路冗余设计 服务器冗余设计 1.7.3 广域网技术遴选 远程接入技术 广域网互连技术：DDN、SDH、MSTP、VPN 广域网性能优化策略：预留带宽、拨号线路、传输数据压缩、链路聚合、基于优先级排序、基于协议预留带宽 1.7.4 层次化网络模型设计 优点：降低成本，充分利用模块化设备/部件，网络变化或演化容易\n3 层模型：\n核心层 汇聚层 接入层 层次化设计 5 原则：\n控制网络层次 从接入层开始，向上分析规划 尽量采用模块化设计 严格控制网络结构 严格控制层次化结构 1.8 网络安全控制技术（5 大类） 技术 说明 防火墙 网络间的安全屏障，保护本地网络资源。可以允许/拒绝/重定向数据流以及审计进出网络的访问或服务。体系：硬件防火墙、软件防火墙、嵌入式防火墙。种类：包过滤、应用层网关、代理服务 VPN（虚拟专用网络） 利用公共网络建立私有专用网络，具有成本低、接入方便、可扩展性强、管理和控制方便等优点 访问控制技术 自主访问控制（DAC）、强制访问控制（MAC）、基于角色的访问控制（RBAC）、基于任务的访问控制（TBAC）、基于对象的访问控制（OBAC） 网络安全隔离 形式：子网隔离、物理隔离、VLAN 隔离、逻辑隔离 网络安全协议 见第5小时内容 1.9 网络安全审计 作用：用来测试、评估和分析网络脆弱性，能够实现自动响应、数据生成、分析、浏览、事件存储、事件选择等功能。\n1.10 绿色网络设计方法 思路：精简设计、重用设计、回收设计\n4 大设计原则：\n标准化：减少转换设备，兼容异构方案 集成化：减少设备总量，降低资源需求 虚拟化：灵活调配，按需使用 智能化：降低人力成本，降低资源占用 1.11 实践案例 案例 1：某企业园区网双核心架构\n核心层：2 台高端三层交换机 汇聚层：4 台汇聚交换机（双链路到核心） 接入层：24 口 PoE 交换机（连接 IP 电话、AP、摄像头） 出口：双 ISP + 防火墙 + 行为管理 案例 2：金融云存储网络\n核心数据库：SAN 架构（FC 交换机，高性能） 文件共享：NAS（NFS/CIFS） 备份：DAS 直连 2. 关键概念速查 概念 定义/说明 常见考点 单核心 一台核心设备 简单但可靠性低 双核心 两台核心三层交换机 路由热切换 环型 多台核心组成环路 易形成环路 半冗余 任意核心存在两条以上链路 灵活 全冗余 任何两个核心间均存在链路 灵活但零散 对等子域 半冗余核心划为两个独立子域 子域互联 层次子域 多子域，存在层次关系 扩展性好 5G 透明模式 通过用户面功能接口 防火墙/代理连 Internet 5G 非透明模式 直接/通过其他网络连接 灵活性高 5G 边缘计算 业务就近分流 时间敏感、高带宽 SDN 软件定义网络 控制转发分离 DAS Direct Attached Storage 直连式存储 NAS Network Attached Storage 网络附加存储 SAN Storage Area Network 存储区域网络 双协议栈 IPv4/IPv6 共存 过渡技术 隧道技术 ISATAP/6to4/over6/6over4 过渡技术 NAT Network Address Translator 过渡技术 VLAN 虚拟局域网 隔离 WLAN 无线局域网 WiFi DDN 数字数据网络 广域网 SDH 同步数字体系 广域网 MSTP 多业务传送平台 广域网 VPN 虚拟专用网络 公共网络建专用 DAC 自主访问控制 自主 MAC 强制访问控制 强制 RBAC 基于角色的访问控制 角色 TBAC 基于任务的访问控制 任务 OBAC 基于对象的访问控制 对象 FTP 文件传输协议 TCP，明文 SSL Secure Sockets Layer 加密传输 HTTPS HTTP over SSL/TLS 加密 HTTP SET Secure Electronic Transaction 电子商务 3. 典型例题（案例分析题） 例题 1：选择题（陷阱题） 题目：局域网网络架构有 4 种类型，以下说法错误的是（ ）。\nA. 单核心架构使用单台核心二层或三层交换设备作为网络核心 B. 单核心架构的优点是结构简单，设备投资节约，接入方便 C. 双核心架构采用两台核心三层及以上交换机作为网络核心 D. 环型架构的缺点是投资较单核心高，核心端口密度要求较高\n参考答案：C 解析：双核心架构的缺点是\u0026quot;投资较单核心高，核心端口密度要求较高\u0026quot;，与环型架构的缺点相同，但题目 C 描述的是双核心架构的定义（\u0026ldquo;采用两台核心三层及以上交换机\u0026rdquo;）——实际上双核心确实是\u0026quot;两台核心三层及以上交换机\u0026quot;，所以 C 选项本身描述正确，但实际上题目中 C 选项文字与答案解释不一致。本题以答案为 C，说明出题意图是：双核心架构的缺点描述应为\u0026quot;投资较单核心高\u0026quot;，但选项 C 表面看是定义。\n正确理解：C 选项的描述（两台核心三层及以上交换机）实际上是双核心的优点表述（题目要求选错误的，所以选择 C）。\n例题 2：选择题 题目：以下不属于网络安全协议的是（ ）。\nA. FTP B. SSL C. HTTPS D. SET\n参考答案：A 解析：\nFTP（File Transport Protocol）：网络上两台计算机传送文件的协议，运行在 TCP 之上，明文传输，不是安全协议 SSL：安全套接字层，安全协议 HTTPS：HTTP over SSL/TLS，安全协议 SET：安全电子交易协议，安全协议 例题 3：选择题（陷阱题） 题目：以下关于层次化网络设计原则的叙述中，错误的是（ ）。\nA. 一般将网络划分为核心层、汇聚层、接入层三个层次 B. 应当首先设计核心层，再根据必要的分析完成其他层次设计 C. 为了保证网络的层次性，不能在设计中随意加入额外连接 D. 除去接入层，其他层次应尽量采用模块化方式，模块间边界应非常清晰\n参考答案：B 解析：按照层次式网络设计原则：\n控制网络层次（一般 3 层） 从接入层开始，向上分析规划（不是先设计核心层！） 尽量采用模块化设计 严格控制网络结构 严格控制层次化结构 B 错在\u0026quot;先设计核心层\u0026quot;——应当从接入层开始向上分析规划。\n例题 4：选择题 题目：（ ）是一种新型网络创新架构，核心思想是通过控制与转发分离，将网络中交换设备的控制逻辑集中到一个计算设备上，控制面集中管控，提升网络管理配置能力。\nA. 5G 网络架构 B. 软件定义网络（SDN） C. 移动通信网网络 D. 存储网络\n参考答案：B 解析：SDN 的核心思想正是\u0026quot;控制与转发分离\u0026quot;。\n4. 论文素材 本章是论文题出题范围，以下 3 个题目方向可以重点准备：\n论企业园区网架构设计与冗余方案\n写作要点：双核心/层次化设计、路由热切换、SDN 应用 实战案例：园区网双核心+SAN 存储 论软件定义网络（SDN）在数据中心网络中的应用\n写作要点：控制面/数据面分离、OpenFlow 协议 实战案例：大型云数据中心 论 IPv4/IPv6 过渡技术在企业网改造中的应用\n写作要点：双协议栈、隧道、NAT 三种技术 实战案例：运营商骨干网升级 5. 高频考点 局域网 6 种架构优缺点：每年必考 1-2 题 DAS / NAS / SAN 对比：表格题必背 IPv4/IPv6 过渡 3 种技术：双栈/隧道/NAT 层次化网络 5 原则：陷阱题是\u0026quot;先核心层\u0026quot;是错的 SDN 核心思想：控制与转发分离 网络安全 5 大技术：防火墙/VPN/访问控制/隔离/协议 绿色网络 4 原则：标准化/集成化/虚拟化/智能化 5 种访问控制：DAC/MAC/RBAC/TBAC/OBAC ","date":"2024-01-01T00:00:00Z","permalink":"/p/20-tong-xin-xi-tong-jia-gou-she-ji-shi-jian/","title":"20-通信系统架构设计实践"},{"content":"21-安全架构设计实践（第21小时） 软考-系统架构设计师 | 第4篇 架构设计实践知识 出题形式：下午案例分析题（25 分）+ 上午选择题 + 论文题 分值占比：约 25-30 分（重点！必出案例）\n0. 考点分析 19 种安全威胁：信息泄露、破坏完整性、拒绝服务、非法使用、窃听、业务流分析、假冒、旁路控制、授权侵犯、特洛伊木马、陷阱门、抵赖、重放、计算机病毒、人员渎职、媒体废弃、物理侵入、窃取、业务欺骗 4 大典型安全模型：状态机模型、BLP（机密性）、Biba（完整性）、CWM（完整性+审计）、Chinese Wall（混合） WPDRRC 模型：6 环节 + 3 要素 信息安全体系 5 方面：物理/系统/网络/应用/管理 OSI/RM 安全架构：深度防御 3 种方式 6 大安全服务框架：认证/访问控制/机密性/完整性/抗抵赖 系统架构脆弱性：分层/C-S/B-S/事件驱动/MVC/微内核/微服务 RADIUS 三层架构 工业安全生产管理系统：设备/控制/设计管理/应用 4 层 1. 核心架构知识 1.1 安全体系架构的范围 3 大防线：产品安全架构、安全技术架构、审计架构\n3 大特性：可用性、完整性、机密性\n安全技术架构 7 大组成：\n身份鉴别 访问控制 内容安全 冗余恢复 审计响应 恶意代码防范 密码技术 1.2 信息系统安全目标 信息系统安全目标是控制和管理主体对客体的访问，实现：\n保护系统可用性 保护网络服务连续性 防范非法非授权访问 防范恶意攻击和破坏 保护信息传输机密性和完整性 防范病毒侵害 实现安全管理 1.3 19 种安全威胁（必须能区分） 威胁 含义 类别 信息泄露 信息被泄露或透露给某个非授权的实体 被动 破坏信息的完整性 数据被非授权地进行增删、修改或破坏 主动 拒绝服务 对信息或其他资源的合法访问被无条件阻止 主动 非法使用（非授权访问） 某一资源被某个非授权的人或以非授权的方式使用 主动 窃听 用各种可能的合法或非法的手段窃取系统中的信息资源和敏感信息 被动 业务流分析 通过对系统进行长期监听，利用统计分析方法对通信频度、信息流向、总量变化等态势研究 被动 假冒 非法用户冒充成为合法用户，或特权小的用户冒充成为特权大的用户 主动 旁路控制 攻击者利用系统的安全缺陷或安全性上的脆弱之处获得非授权的权利或特权 主动 授权侵犯 内部攻击，被授权的用户将权限用于其他非授权的目的 主动 特洛伊木马 软件中含有一个察觉不出的或者无害的程序段，当它被执行时，会破坏用户的安全 主动 陷阱门 在某个系统或某个部件中设置了\u0026quot;机关\u0026quot;，使得当提供特定的输入数据时，允许违反安全策略 主动 抵赖 来自用户的攻击，否认自己曾经发布过的消息、伪造对方来信 主动 重放 所截获的某次合法的通信数据备份，出于非法的目的而被重新发送 主动 计算机病毒 在计算机系统运行过程中能够实现传染和侵害的功能程序 主动 人员渎职 授权的人因粗心或利益将信息泄露给非授权的人 主动 媒体废弃 信息被从废弃的磁盘或打印过的存储介质中获得 被动 物理侵入 侵入者通过绕过物理控制而获得对系统的访问 主动 窃取 重要的安全物品遭到窃取（令牌、身份卡） 主动 业务欺骗 伪系统或系统部件欺骗合法的用户，或使系统自愿地放弃敏感信息 主动 1.4 典型安全模型（5 大模型） 1.4.1 状态机模型 安全状态模型系统，总是从一个安全状态启动 在所有迁移中保持安全状态 只允许主体以和安全策略相一致的安全方式访问资源 1.4.2 BLP 模型（Bell-LaPadula Model） 目标：数据规划机密性，依据机密性划分安全级别，按安全级别强制访问控制。\n基本原理（机密性场景）：\n主体级别 客体级别 权限 机密 绝密 可写不可读 机密 机密 可写可读 机密 秘密 可读不可写 BLP 4 大安全规则：\n简单规则：低级别主体读取高级别客体受限 星型规则：高级别主体写入低级别客体受限 强星型规则：对不同级别读写受限 自主规则：自定义访问控制矩阵 口诀：BLP 关注机密性，下读上写。\n1.4.3 Biba 模型 目标：建立在完整性级别上。\n完整性的 3 大目标：\n保护数据不被未授权用户更改 保护数据不被授权用户越权修改 维持数据内部和外部的一致性 基本原理（完整性场景）：\n主体完整性 客体完整性 权限 中完整性 高完整性 可读不可写，不能调用主体的任何程序和服务 中完整性 中完整性 可读可写 中完整性 低完整性 可写不可读 Biba 防止数据从低完整性级别流向高完整性级别。\nBiba 3 大安全规则：\n星完整性规则：完整性级别低的主体不能对完整性级别高的客体写数据 简单完整性规则：完整性级别高的主体不能从完整性级别低的客体读取数据 调用属性规则：完整性级别低的主体不能从级别高的客体调用程序或服务 口诀：Biba 关注完整性，上读下写。\n1.4.4 CWM 模型（Clark-Wilson Model） 特点：将完整性目标、策略和机制融为一体，提出职责分离目标，应用完整性验证过程，实现了成型的事务处理机制，常用于银行系统。\n3 大特征：\n包含主体、程序、客体三元素，主体只能通过程序访问客体 权限分离原则：功能可分为多主体，防止授权用户进行未授权修改 具有审计能力 1.4.5 Chinese Wall 模型 特点：混合策略模型，应用于多边安全系统，防止多安全域存在潜在的冲突，为投资银行设计，常见于金融领域。\n工作原理：\n通过**自主访问控制（DAC）**选择安全域 通过**强制访问控制（MAC）**完成特定安全域内的访问控制 安全规则：\n墙内客体可读取 不同利益冲突组客体可读取 访问其他公司客体和其他利益冲突组客体后，主体对客体写入受限 1.5 信息安全整体架构设计 1.5.1 WPDRRC 信息安全模型 6 个环节：\nW - Warning（预警） P - Protect（保护） D - Detect（检测） R - React（响应） R - Restore（恢复） C - Counterattack（反击） 3 大要素：人员、策略、技术\n1.5.2 信息安全体系架构（5 方面） 方面 重要性 包括 物理安全 前提 环境安全、设备安全、媒体安全 系统安全 基础 网络结构安全、操作系统安全、应用系统安全 网络安全 关键 访问控制、通信保密、入侵检测、网络安全扫描、防病毒 应用安全 — 资源共享、信息存储 安全管理 — 健全的体制、管理平台、人员安全防范意识 1.6 网络安全架构设计 1.6.1 OSI/RM 信息安全架构 深度防御安全架构通过 3 种方式将防御能力分布至整个信息系统：\n多点技术防御：网络和基础设施、边界防御（流量过滤/控制/如前检测）、计算环境 分层技术防御：外部和内部边界使用嵌套防火墙，配合入侵检测 支撑性基础设施：公钥基础设施（PKI）以及检测和响应基础设施 1.6.2 认证框架（5 种鉴别方式） 已知的（口令） 拥有的（IC 卡、令牌） 不可变特征（生物特征） 受信第三方鉴别 环境（主机地址） 鉴别服务 9 阶段：安装、修改鉴权信息、分发、获取、传送、验证、停活、重新激活、取消安装\n1.6.3 访问控制框架 AEF（Access Control Enforcement Facilities，访问控制管制设备） ADF（Access Control Decision Facilities，访问控制决策设备） ADI（Access Control Decision Information，访问控制决策信息） 1.6.4 机密性框架 目的：确保信息仅仅是对被授权者可用 机制：通过禁止访问提供机密性、通过加密提供机密性 1.6.5 完整性框架 目的：组织威胁或探测威胁，保护数据及其相关属性的完整性 完整性服务分类：未授权的数据创建、数据创建、数据删除、数据重放 完整性机制：阻止媒体访问与探测非授权修改 1.6.6 抗抵赖框架 目的：提供特定事件或行为的证据 5 阶段：证据生成、证据传输、存储及回复、证据验证、解决纠纷 1.7 数据库系统安全设计 完整性设计原则 7 条：\n依据完整性约束类型设计其实现的系统层次和方式，并考虑性能 在保障性能的前提下，尽可能应用实体完整性约束和引用完整性约束 慎用触发器 制订并使用完整性约束命名规范 测试数据库完整性，尽早排除冲突和性能隐患 设有数据库设计团队，参与数据库工程全过程 使用 CASE 工具，降低工作量，提高工作效率 数据库完整性的 3 大作用：\n防止不合语义的数据入库 降低开发复杂性，提高运行效率 通过测试尽早发现缺陷 1.8 系统架构脆弱性分析 脆弱性组成：物理装备、软件、人员管理、规章制度、安全策略\n7 大典型架构脆弱性：\n架构 脆弱性表现 分层架构 层间脆弱性（底层错误导致整体崩溃）+ 层间通信脆弱性（性能下降） C/S 架构 客户端脆弱性 + 网络开放性脆弱性 + 网络协议脆弱性 B/S 架构 使用 HTTP 协议易被病毒入侵 事件驱动架构 组件脆弱性 + 组件间交换数据脆弱性 + 组件间逻辑关系脆弱性 + 容易死循环 + 高并发脆弱性 + 固定流程脆弱性 MVC 架构 复杂性脆弱性 + 视图与控制器连接紧密脆弱性 + 视图对模型低效率访问脆弱性 微内核架构 整体优化脆弱性 + 进程通信开销脆弱性 + 通信损失脆弱性 微服务架构 分布式结构复杂 + 服务间通信 + 服务管理复杂性 1.9 安全架构设计实践 1.9.1 RADIUS（远程认证拨号用户服务） 应用最广泛的AAA（Authentication 认证、Authorization 授权、Accounting 审计）协议，具有高性能和高可扩展性。\n3 层架构：\n协议逻辑层：起到分发处理功能，相当于转发引擎 业务逻辑层：实现认证、授权、审计 3 种业务及其服务进程间的通信 数据逻辑层：实现统一的数据访问代理池，降低数据库依赖 1.9.2 基于混合云的工业安全生产管理系统 架构：\n工厂内部（产品设计、数据共享、生产集成）：私有云 总部与智能工厂（业务管理、协调、统计分析）：公有云 4 层架构：\n设备层：智能传感器、智能仪器仪表、工业机器人 控制层：SCADA、DCS、FCS、PLC、HMI 设计/管理层：MES、CAD/CAE/CAM、SCM、ERP、CRM、SRM、BI、PLM 应用层：云平台信息处理（数据处理与管理、数据与行业应用结合） 5 大安全问题：设备安全、网络安全、控制安全、应用安全、数据安全\n1.10 实践案例 案例 1：银行系统的 CWM + BLP 模型应用\nCWM 保证完整性（事务处理） BLP 保证机密性（按密级分级别访问） 案例 2：电商平台 BLP + Biba 双模型\n用户隐私数据用 BLP（机密性） 商品价格、库存用 Biba（完整性） 案例 3：投资银行 Chinese Wall 模型\n不同客户组之间\u0026quot;墙\u0026quot;隔离 同一墙内可访问，跨墙需通过 MAC 控制 2. 关键概念速查 概念 定义/说明 常见考点 BLP Bell-LaPadula 机密性、下读上写 Biba Biba Integrity 完整性、上读下写 CWM Clark-Wilson 完整性+审计、职责分离、银行 Chinese Wall 混合策略 金融领域、DAC+MAC 状态机 状态机模型 基础安全模型 WPDRRC 6 环节+3 要素 预警/保护/检测/响应/恢复/反击 深度防御 Defense in Depth 多点+分层+基础设施 AAA 认证/授权/审计 Authentication/Authorization/Accounting AEF 访问控制管制设备 接收访问请求 ADF 访问控制决策设备 做出允许/禁止判决 ADI 访问控制决策信息 上下文信息 RADIUS 远程认证拨号用户服务 3 层架构 SCADA 采集与监视控制系统 设备层 DCS 分布式控制系统 设备层 FCS 现场总线控制系统 设备层 PLC 可编程控制器 设备层 HMI 人机接口 设备层 MES 制造执行系统 设计/管理层 PLM 产品生命周期管理 设计/管理层 陷阱门 Trapdoor \u0026ldquo;机关\u0026quot;违反安全策略 特洛伊木马 Trojan 无害程序段破坏安全 重放攻击 Replay 截获数据重新发送 假冒 Masquerade 冒充合法/特权用户 主动攻击 修改、伪造信息 假冒 被动攻击 只获取不修改 监听、截取 3. 典型例题（案例分析题） 例题 1：选择题 题目：以下属于主动攻击的是（ ）。\nA. 网络监听 B. 信息截取 C. 非法登录 D. 假冒身份\n参考答案：D 解析：主动攻击会对信息进行修改、伪造，而被动攻击只是非法获取信息，不会对信息进行任何修改。假冒身份属于主动攻击；网络监听、信息截取、非法登录（信息收集）属于被动。\n例题 2：选择题 题目：信息安全策略应该全面地保护信息系统整体的安全。其中，数据库的容灾属于（ ）的内容。\nA. 物理线路安全与网络安全 B. 网络安全与系统安全 C. 物理线路安全与系统安全 D. 网络安全与应用安全\n参考答案：D 解析：依据信息安全体系架构：\n物理安全：环境、设备、媒体 系统安全：网络结构、操作系统、应用系统 网络安全：访问控制、通信保密、入侵检测、网络安全扫描、防病毒 应用安全：资源共享和信息存储 数据库容灾属于对信息存储方面的安全（应用安全）和网络方面的安全。\n例题 3：选择题 题目：（ ）模型为数据规划机密性，依据机密性划分安全级别，按安全级别强制访问控制。\nA. BLP 模型 B. 状态机模型 C. Biba 模型 D. CWM 模型\n参考答案：A 解析：\nBLP：数据机密性，按安全级别强制访问控制 状态机：基础模型，所有迁移保持安全状态 Biba：数据完整性 CWM：完整性+审计，银行系统 例题 4：选择题 题目：\u0026ldquo;在某个系统或某个部件中设置了\u0026rsquo;机关\u0026rsquo;，使得当提供特定的输入数据时，允许违反安全策略。\u0026ldquo;属于哪一种安全威胁？\nA. 特洛伊木马 B. 陷阱门 C. 窃取 D. 非法使用\n参考答案：B 解析：\n陷阱门：在系统中设置\u0026quot;机关\u0026rdquo;，特定输入允许违反安全策略 特洛伊木马：软件中含无害程序段 窃取：重要安全物品被盗 非法使用：资源被非授权使用 例题 5：选择题（陷阱题） 题目：常见的分层架构的脆弱性包括（ ）等两方面。\nA. 底层发生错误会导致整个系统无法正常运行、层与层之间功能引用可能导致功能失效 B. 底层发生错误会导致整个系统无法正常运行、层与层之间引入通信机制势必造成性能下降 C. 上层发生错误会导致整个系统无法正常运行、层与层之间引入通信机制势必造成性能下降 D. 上层发生错误会导致整个系统无法正常运行、层与层之间的功能引用可能导致功能失效\n参考答案：B 解析：层次式架构的软件脆弱性主要表现在：\n层间脆弱性：某个底层的错误会导致整个系统都无法正常工作 层间通信脆弱性：层次间引入通信机制会造成大量消息交互，从而造成系统性能下降 注意：是底层错误，不是上层。\n4. 论文素材 本章是论文题出题范围，以下 3 个题目方向可以重点准备：\n论企业信息系统的安全架构设计与实现\n写作要点：WPDRRC 模型、深度防御、5 方面安全体系 实战案例：金融/电信企业安全架构 论 BLP 与 Biba 安全模型在企业信息系统中的应用\n写作要点：机密性 vs 完整性对比、银行 CWM 模型 实战案例：电商平台双模型应用 论工业互联网安全架构设计与实践\n写作要点：RADIUS、混合云工业安全、5 大安全问题 实战案例：智能工厂安全防护 5. 高频考点 19 种安全威胁：陷阱门（机关）、特洛伊木马（无害程序段）、重放（重新发送）区分 BLP vs Biba：机密性 vs 完整性，必对比 CWM 银行、Chinese Wall 金融：常考应用场景 WPDRRC 6 环节 + 3 要素：必背 信息安全体系 5 方面：物理/系统/网络/应用/管理 深度防御 3 种方式：多点+分层+基础设施 AAA 框架：认证/授权/审计 分层架构脆弱性：底层错误 + 通信性能下降 数据库容灾属于哪个安全：网络安全+应用安全 ","date":"2024-01-01T00:00:00Z","permalink":"/p/21-an-quan-jia-gou-she-ji-shi-jian/","title":"21-安全架构设计实践"},{"content":"22-大数据架构设计实践（第22小时） 软考-系统架构设计师 | 第4篇 架构设计实践知识 出题形式：下午案例分析题（必出 25 分）+ 上午选择题 + 论文题 分值占比：约 25-30 分（重点！必出案例）\n0. 考点分析 大数据 4 大特点：体量大、时效性强、类型多样、价值 传统数据处理 5 种解决方法：异步队列/分区/分片/读写分离/分库分表 Lambda 架构 3 层：批处理层 + 加速层 + 服务层 Kappa 架构 2 层：实时层 + 服务层 Lambda vs Kappa 对比：4 维度 4 大实践案例：视频网络、广告平台、证券智能决策、电商智能决策 大数据 4 个处理过程：采集、清洗、统计、挖掘 1. 核心架构知识 1.1 传统数据处理系统的问题 1.1.1 数据过载问题 传统应用数据系统架构设计时，应用直接访问数据库系统。当用户访问量增加时，数据库无法支撑日益增长的负载，出现超时的错误。\n5 种常用解决方法：\n增加异步处理队列：通过工作处理层批量处理异步处理队列中的数据修改请求 建立数据库水平分区：通常建立 Key 分区，以主键/唯一键 Hash 值作为 Key 建立数据库分片或重新分片：通常专门编写脚本来自动完成，且要进行充分测试 引入读写分离技术：主数据库处理写请求，通过复制机制分发至从数据库 引入分库分表技术：按照业务上下文边界拆分数据组织结构，拆分单数据库压力 1.1.2 大数据特点 大数据具有体量大、时效性强的特点，并非构造单调，而是类型多样。处理大数据时，传统数据处理系统因数据过载、来源复杂、类型多样等诸多原因性能低下，需要采用以新式计算架构和智能算法为代表的新技术。\n大数据的应用重在发掘数据间的相关性，而非传统逻辑上的因果关系。\n大数据的目的和价值：发现新的知识，洞悉并进行科学决策。\n现代大数据处理技术：\n基于分布式文件系统 Hadoop 使用 Map/Reduce 或 Spark 数据处理技术 使用 Kafka 数据传输消息队列及 Avro 二进制格式 1.1.3 大数据利用过程 4 个过程：采集 → 清洗 → 统计 → 挖掘\n1.2 大数据处理系统架构分析 1.2.1 面临的挑战 如何利用信息技术等手段处理非结构化和半结构化数据 如何探索大数据复杂性、不确定性特征描述的刻画方法及大数据的系统建模 数据异构性与决策异构性的关系对大数据知识发现与管理决策的影响 1.2.2 大数据处理系统应具有的属性和特征 鲁棒性和容错性 低延迟 横向扩展（通过增强机器性能扩展） 通用 可扩展 即席查询（用户按照自己的要求进行查询） 最少维护和可调试 1.3 典型的大数据架构（重点！） 1.3.1 Lambda 架构 定义：Lambda 架构是一种用于同时处理离线和实时数据的、可容错的、可扩展的分布式系统。\n3 层结构：\n1 2 3 4 5 6 7 8 9 10 ┌─────────────────────────────────────────┐ │ 服务层（Serving Layer） │ │ 响应用户请求，合并批视图和实时视图 │ ├─────────────────────────────────────────┤ │ 加速层（Speed Layer） │ │ 处理增量实时数据，生成实时视图 │ ├─────────────────────────────────────────┤ │ 批处理层（Batch Layer） │ │ 存储主数据集，周期执行批处理，生成批视图 │ └─────────────────────────────────────────┘ 层 核心功能 架构实现 批处理层 存储主数据集（原始、不可变、真实），周期性转储增量数据并执行批处理，生成批视图 HDFS/HBase 存储主数据集，Spark/MapReduce 周期批处理，MapReduce 创建批视图 加速层 处理增量实时数据，生成实时视图，快速执行即席查询 HDFS/HBase 存储实时数据，Spark/Storm 实时处理 服务层 响应用户请求，合并批视图和实时视图中的结果数据集得到最终数据集 HBase/Cassandra 作为服务层，Hive 创建可查询视图 Lambda 架构优缺点：\n优点：容错性好，查询灵活度高，弹性伸缩，易于扩展 缺点：编码量大，持续处理成本高，重新部署和迁移成本高 与 Lambda 架构相似的模式：事件溯源模式、命令查询职责分离模式（CQRS）\n1.3.2 Kappa 架构 定义：Kappa 架构是在 Lambda 架构的基础上进行了优化，删除了 Batch Layer，将数据通道以消息队列进行替代。\n2 层结构：\n1 2 3 4 5 6 7 8 9 ┌─────────────────────────────────────────┐ │ 服务层（Serving Layer） │ │ 使用实时视图中的结果数据集响应用户请求 │ │ 实践中使用数据湖中的存储作为服务层 │ ├─────────────────────────────────────────┤ │ 实时层 │ │ 处理输入数据，生成实时视图 │ │ Kafka 回访 + Flink/Spark Streaming │ └─────────────────────────────────────────┘ 层 核心功能 架构实现 实时层 处理输入数据，生成实时视图；流式处理引擎逐条处理输入数据 Apache Kafka 回访数据 + Flink/Spark Streaming 服务层 使用实时视图响应用户请求 数据湖中的存储 Kappa 架构本质：通过改进 Lambda 架构中的加速层，使它既能够进行实时数据处理，同时也有能力在业务逻辑更新的情况下重新处理以前处理过的历史数据。\nKappa 优缺点：\n优点：将离线和实时处理代码进行了统一，方便维护 缺点：消息中间件有性能瓶颈、数据关联时处理开销大、抛弃了离线计算的可靠性 Kappa 常见变形：Kappa+ 架构、混合分析系统 Kappa 架构\n1.3.3 Lambda vs Kappa 架构对比 对比内容 Lambda 架构 Kappa 架构 复杂度与开发维护成本 维护两套系统（引擎），复杂度高，成本高 维护一套系统（引擎），复杂度低，成本低 计算开销 周期性批处理计算，持续实时计算，计算开销大 必要时进行全量计算，计算开销相对较小 实时性 满足实时性 满足实时性 历史数据处理能力 批式全量处理，吞吐量大，历史数据处理能力强；批视图与实时视图存在冲突可能 流式全量处理，吞吐量相对较低，历史数据处理能力相对较弱 1.3.4 Lambda 与 Kappa 架构选择（4 维度） 设计考虑 选择 Lambda 选择 Kappa 业务需求与技术要求 依赖 Hadoop、Spark、Storm 技术 依赖 Flink 计算引擎，偏流式计算 复杂度 实时处理和离线处理结果可能不一致 频繁修改算法模型参数 开发维护成本 成本预算充足 成本预算有限 历史数据处理能力 频繁使用海量历史数据 仅使用小规模数据集 1.4 大数据架构的实践（4 大案例） 1.4.1 案例 1：大规模视频网络（Lambda 架构） 某网采用 Lambda 架构搭建的大数据平台处理里约奥运会大规模视频网络观看数据。\n平台架构（4 层）：\n数据采集层：PC 端 + App 端 + TV 端 → Nginx → Kafka 数据集成层：实时数据（Flume + Kafka）+ 离线数据（Flume + Sqoop + HDFS + ETL） 数据存储层：MemSQL + HBase + HDFS 数据计算层：离线计算（Spark/MapReduce）+ 实时计算（Spark Streaming）+ 合并计算（Impala/Hive） 数据展现层：当日概览、赛事回顾 数据计算层 3 个部分：\n离线计算：存储持续增长的批量离线数据，周期性地使用 Spark 和 Map/Reduce 批处理，批视图写入 HDFS 实时计算：采用 Spark Streaming，处理实时增量数据，更新实时视图 合并计算：合并批视图和实时视图，生成最终数据集，写入 HBase 用于响应查询 1.4.2 案例 2：广告平台（Lambda 架构） 层 实现 批处理层 每天凌晨将 Kafka 中浏览、下单等消息同步到 HDFS，将 HDFS 中数据解析为 Hive 表，使用 HQL 或 Spark SQL 计算分区统计结果 Hive 表，转储到 MySQL 中作为批视图 加速层 使用 Spark Streaming 实时监听 Kafka 下单、付款等消息，计算每个追踪链接维度的实时数据，存储在 Redis 中作为实时视图 服务层 采用 Java Web 服务，对外提供 HTTP 接口，Java Web 服务读取 MySQL 批视图表和 Redis 实时视图表 1.4.3 案例 3：证券智能决策（Kappa 架构） 某证券公司智能决策大数据系统是一个基于 Kappa 架构的实时日志分析平台。\n实时处理过程：\n日志采集：用统一的数据处理引擎 Filebeat 实时采集日志并推送给 Kafka 缓存 日志清洗解析：利用基于大数据计算集群的 Flink 计算框架实时读取 Kafka 消息并进行清洗，解析日志文本转换成指标 日志存储：日志转储到 ElasticSearch 日志库，指标转储到 OpenTSDB 指标库 日志监控：单独设置告警消息队列，保持监控消息时序管理和实时推送 1.4.4 案例 4：电商智能决策（Kappa 架构） 该智能决策大数据平台基于 Kappa 架构，使用统一的数据处理引擎 Flink 可实时处理流数据，并将其存储到数据仓库工具 Hive 与分布式缓存 Tair 中。\n实时处理过程：\n数据采集：B 端实时采集用户点击、下单、广告曝光、出价等数据然后推送给 Kafka 缓存 数据清洗聚合：由 Flink 实时读取 Kafka 消息，按需过滤参与业务需求的指标，将聚合时间段的数据转换成指标 数据存储：Flink 将计算结果转储至 Hive 日志库，将模型需要的参数转储至实时计算数据库 Tair 缓存，后续决策服务从 Tair 中获取数据进行模型训练 1.5 实践案例总结 架构选型决策树：\n1 2 3 4 5 Q1: 是否需要频繁修改算法模型参数？ ├─ 是 → Kappa └─ 否 → Q2: 是否有海量历史数据？ ├─ 是 → Lambda └─ 否 → Kappa 2. 关键概念速查 概念 定义/说明 常见考点 大数据 体量大、时效性强、类型多样、价值 4 大特点 Lambda 架构 离线+实时 3 层：批处理/加速/服务 Kappa 架构 仅流式处理 2 层：实时/服务 批处理层 Batch Layer 存储主数据集 + 批视图 加速层 Speed Layer 实时视图 服务层 Serving Layer 合并视图 + 响应请求 批视图 Batch View 离线计算结果 实时视图 Real-time View 实时计算结果 HDFS Hadoop Distributed File System 分布式文件系统 HBase Hadoop Database 分布式列存储 MapReduce 分布式计算框架 批处理 Spark 内存计算框架 比 MR 快 Storm 实时流式处理 Twitter 开源 Flink 分布式流处理 流批一体 Spark Streaming Spark 的流处理模块 微批处理 Kafka 消息队列 高吞吐 Hive 数据仓库工具 SQL-on-Hadoop Impala 实时查询引擎 内存计算 Avro 二进制数据格式 序列化 HQL Hive SQL 类 SQL Tair 分布式缓存 阿里开源 OpenTSDB 时序数据库 基于 HBase ElasticSearch 分布式搜索 日志库 Filebeat 日志采集器 轻量级 Redis 内存数据库 缓存 Cassandra 分布式 NoSQL 高可用 Nginx HTTP 服务器 反向代理 Flume 日志采集 海量日志 Sqoop 数据传输 RDBMS ↔ Hadoop ETL Extract-Transform-Load 数据抽取转换加载 CQRS 命令查询职责分离 读写分离 CAP Consistency/Availability/Partition 分布式理论 数据湖 Data Lake 原始数据存储 3. 典型例题（案例分析题） 例题 1：选择题（陷阱题） 题目：以下关于大数据的说法中，错误的是（ ）。\nA. 大数据拥有体量大、构造单调、时效性强等特点 B. 处理大数据需要采用新式计算架构和智能算法等新技术 C. 大数据的应用着重相关剖析，而不是因果剖析 D. 大数据的目的在于发现新的知识，洞悉并进行科学决策\n参考答案：A 解析：大数据具有体量大、时效性强的特征，并非构造单调，而是类型多样。A 选项的\u0026quot;构造单调\u0026quot;是错误的。\n例题 2：选择题（Lambda 架构核心） 题目：Lambda 架构分为三层： （1）批处理层（2）加速层（3）服务层\n（1）的核心功能是存储主数据集。 （2）的核心功能是处理增量实时数据，生成实时视图。 （3）的核心功能是响应用户请求，合并批视图和实时视图。\n参考答案：\n（1）A. 批处理层 （2）C. 加速层 （3）C. 服务层 解析：\n批处理层：核心功能是存储主数据集，主数据集具有原始、不可变、真实的特征 加速层：核心功能是处理增量实时数据，生成实时视图 服务层：核心功能是响应用户请求，合并批视图和实时视图 例题 3：综合分析题（Lambda 架构识别） 题目：某互联网公司近期为其旗下产品升级架构，架构图（描述）如下：\nCollector 收集结构化数据推送给主 Kafka 主 Kafka 写入 HDFS 异构数据通过 DataX/Sqoop 写入 HDFS HDFS 数据通过 Offline（Hive/MR/Spark）进行离线处理 HDFS 数据通过 OLAP（Kylin/Naix）进行联机分析处理 处理结果存储至由各类关系型数据库组成的结果存储 主 Kafka 通过分发机制分发给 Kafka，交给 Flink/Storm 订阅者 Flink/Storm 进行流式实时处理，结果存储至处理结果存储 OneDataAPI 通过非关系型数据库对数据平面和业务系统提供数据服务 请指出该架构采用的是什么架构，并说明该架构的层次结构。\n参考答案： 该架构采用的是 Lambda 架构，由以下层次组成：\n数据采集层：Collector、DataX/Sqoop 数据源：HDFS 批处理层：Offline（Hive/MR/Spark），OLAP（Kylin/Naix） 加速层：Flink/Storm 服务层：结果视图存储（MongoDB、ElasticSearch、HBase、Redis…），OneDataAPI 4. 论文素材 本章是论文题出题范围，以下 3 个题目方向可以重点准备：\n论 Lambda 架构在企业大数据平台中的应用\n写作要点：批处理/加速/服务 3 层职责、HDFS/Hive/Spark 选型 实战案例：视频网络/广告平台 论 Kappa 架构在实时数据处理中的实践\n写作要点：Flink + Kafka 流批一体、Kappa+ 变形 实战案例：证券智能决策/电商智能决策 论 Lambda 与 Kappa 架构的选型与对比\n写作要点：4 维度选择、业务特点与架构匹配 实战案例：从 Lambda 迁移到 Kappa 的演进 5. 高频考点 大数据 4 特点：体量大、时效性强、类型多样、价值（注：不是\u0026quot;构造单调\u0026quot;） Lambda 3 层：批处理层（主数据集）+ 加速层（实时视图）+ 服务层（合并响应） Kappa 2 层：实时层 + 服务层 Lambda vs Kappa 4 维度对比：复杂度、计算开销、实时性、历史数据 4 大实践案例技术栈： 视频网络：Spark + HBase + HDFS + Kafka 广告平台：Spark Streaming + Redis + MySQL 证券：Filebeat + Kafka + Flink + ES + OpenTSDB 电商：Flink + Kafka + Hive + Tair 大数据 4 过程：采集 → 清洗 → 统计 → 挖掘 传统数据库过载 5 种解决方法：异步队列/分区/分片/读写分离/分库分表 ","date":"2024-01-01T00:00:00Z","permalink":"/p/22-da-shu-ju-jia-gou-she-ji-shi-jian/","title":"22-大数据架构设计实践"},{"content":"23-知识产权（第23小时） 软考-系统架构设计师 | 第5篇 架构设计补充知识 出题形式：上午选择题 分值占比：2-3 分\n0. 考点分析 著作权法（人身权/财产权/职务作品/委托作品/合理使用） 计算机软件保护条例（软件著作权归属/保护期） 专利法（发明/实用新型/外观设计/不授予专利/职务发明） 商标法（不得注册/不得使用/侵权行为） 反不正当竞争法（商业秘密） 软件产品管理办法（不得开发/生产/销售内容） 1. 核心知识点 1.1 著作权法 人身权（保护期不受限制） 发表权 —— 决定作品是否公之于众 署名权 —— 表明作者身份，在作品上署名 修改权 —— 修改或授权他人修改 保护作品完整权 —— 保护作品不受歪曲、篡改 财产权（17项，5-17项可许可、可转让） 复制权 6. 发行权 7. 出租权 8. 展览权 表演权 10. 放映权 11. 广播权 12. 信息网络传播权 摄制权 14. 改编权 15. 翻译权 16. 汇编权 应当由著作权人享有的其他权利 职务作品著作权归属 情形 著作权归属 一般职务作品 作者享有，但单位在业务范围内优先使用（2年内） 主要利用单位物质技术条件并由单位承担责任（工程设计图、产品设计图、地图、示意图、计算机软件等） 单位享有，作者仅享署名权 报社、期刊、通讯社、广播电台、电视台工作人员创作的职务作品 单位享有，作者仅享署名权 合同约定由单位享有的 按合同约定 委托作品著作权归属 合同约定优先 未约定 → 著作权属于受托人 合理使用（12种情形，可不经许可不付酬） 可不经著作权人许可、不支付报酬的情形（需指明作者/作品名，不影响正常使用，不损害合法权益）：\n个人学习研究欣赏 介绍评论作品适当引用 报道新闻不可避免再现 媒体转载政治经济宗教时事性文章（声明不许的除外） 媒体刊登公众集会讲话（作者声明不许的除外） 课堂教学/科研翻译改编少量复制（不得出版发行） 国家机关执行公务合理使用 图书馆/档案馆/博物馆等陈列保存版本需要复制本馆收藏 免费表演（不收费、不付酬） 对公共场所艺术作品临摹绘画摄影录像 中文作品翻译成少数民族语言在国内出版 无障碍方式提供 1.2 计算机软件保护条例 软件定义 计算机程序：代码化指令序列或符号化指令/语句序列（源程序与目标程序为同一作品） 文档：描述程序的内容、组成、设计、功能规格等的文字资料和图表 开发者：实际组织开发并承担责任的法人/组织，或独立完成并承担责任的自然人 软件著作权人：依条例对软件享有著作权的自然人/法人/组织 软件著作权归属 第十条：合作开发按书面合同；无约定可分割使用的各自享有（行使时不得扩展到整体）；不可分割的共同享有 第十一条：委托开发无书面合同或未明确约定的，著作权归受托人 第十四条：软件著作权自软件开发完成之日起产生（不是发表日、登记日） 软件著作权保护期 主体 保护期 截止日 自然人 终生 + 死亡后 50 年 死后第 50 年的 12 月 31 日 合作开发 同上，以最后死亡者计 同上 法人/组织 50 年 软件首次发表后第 50 年的 12 月 31 日 开发完成 50 年内未发表 不再保护 —— 1.3 专利法 三种专利类型 类型 保护对象 期限 发明 对产品/方法/改进的新技术方案 20 年 实用新型 对产品形状/构造/结合的适于实用的新技术方案 10 年 外观设计 对产品整体/局部的形状/图案/色彩结合富有美感并适于工业应用的新设计 15 年 不授予专利权（25条） 科学发现 智力活动的规则和方法 疾病的诊断和治疗方法 动物和植物品种 原子核变换方法及用其获得的物质 平面印刷品的图案/色彩/二者结合主要起标识作用的设计 第4项的生产方法可授予专利权\n专利权归属 职务发明：申请权归单位，单位为专利权人 非职务发明：申请权归发明人/设计人 共同发明：除协议外，归完成或共同完成的单位/个人 先申请原则：两个以上申请人分别就同样发明创造申请，专利权授予最先申请的人 1.4 商标法 不得作为商标使用（10条） 同中国/外国国家名称、国旗、国徽、军旗相同或近似 同政府间国际组织名称/旗帜/徽记相同或近似 同官方控制标志/检验印记相同或近似 同\u0026quot;红十字\u0026quot;\u0026ldquo;红新月\u0026quot;名称标志相同或近似 带有民族歧视性 带有欺骗性（误认质量/产地） 有害于社会主义道德风尚或有其他不良影响 县级以上行政区划地名或公众知晓的外国地名（地名有其他含义的除外） 不得作为商标注册（11条） 仅本商品的通用名称/图形/型号 仅直接表示商品质量/原料/功能/用途/重量/数量等 其他缺乏显著特征的 前款标志经过使用取得显著特征的，可作为商标注册 商标专用权范围（第56条） 以核准注册的商标和核定使用的商品为限 商标侵权行为（57条） 未经许可在同种商品上使用相同商标 未经许可在同种/类似商品上使用近似商标导致混淆 销售侵犯注册商标专用权的商品 伪造/擅自制造商标标识或销售伪造/擅自制造的商标标识 未经同意更换注册商标并投入市场 故意为侵权提供便利条件 其他损害 1.5 反不正当竞争法（商业秘密） 商业秘密定义 不为公众所知悉 具有商业价值 经权利人采取相应保密措施 技术信息、经营信息等商业信息 侵犯商业秘密的行为 以盗窃/贿赂/欺诈/胁迫/电子侵入等不正当手段获取 披露/使用/允许他人使用以前项手段获取的商业秘密 违反保密义务或保密要求，披露/使用/允许他人使用 教唆/引诱/帮助他人违反保密义务 1.6 软件产品管理办法 不得开发/生产/销售/进出口的软件产品 侵犯他人知识产权的 含有计算机病毒的 可能危害计算机系统安全的 含有国家规定禁止传播的内容的 不符合我国软件标准规范的 2. 关键概念速查 概念 定义/说明 常见考点 著作权产生时间 软件自开发完成之日起 选C（非发表/登记） 委托作品无合同 归受托人 软件也是 职务作品（一般） 归作者，单位优先使用2年 工程设计图等特殊情形归单位 署名权/修改权/保护作品完整权 保护期不受限 人身权 商标专用权范围 核准注册商标 + 核定使用商品 第56条 不授予专利 6类（科学发现/智力规则/疾病诊治/动植物品种/原子核变换/平面印刷品标识） 第25条 商业秘密三要素 秘密性 + 价值性 + 保密措施 反不正当竞争法 专利权归属 职务→单位；非职务→发明人；先申请原则 第6/9条 3. 典型例题 题目1：以下关于软件著作权产生时间的叙述中，正确的是（ ）。 A. 软件著作权产生自软件首次公开发表时 B. 软件著作权产生自开发者有开发意图时 C. 软件著作权产生自软件开发完成之日起 D. 软件著作权产生自软件著作权登记时\n答案：C\n解析：根据《计算机软件保护条例》第十四条规定，软件著作权自软件开发完成之日起产生。\n题目2：谭某是CZB物流公司的业务系统管理员。任职期间，谭某根据公司的业务要求开发了\u0026quot;报关业务系统\u0026rdquo;，并由公司使用。以下说法正确的是（ ）。 A. 报关业务系统V1.0的著作权属于谭某 B. 报关业务系统V1.0的著作权属于CZB物流公司 C. 报关业务系统V1.0的著作权属于谭某和CZB物流公司 D. 报关业务系统V1.0的著作权不属于谭某和CZB物流公司\n答案：B\n解析：根据《著作权法》第十八条，谭某任职期间根据公司业务要求开发的系统属于职务作品，著作权归单位（CZB物流公司）。\n题目3：甲、乙两人在同一天就同样的发明创造提交了专利申请，专利局将分别向各申请人通报情况。下列说法中，不可能采用（ ）。 A. 甲、乙作为共同申请人 B. 甲或乙一方放弃权利并从另一方得到适当的补偿 C. 甲、乙都不授予专利权 D. 甲、乙都授予专利权\n答案：D\n解析：根据《专利法》第九条，\u0026ldquo;同样的发明创造只能被授予一项专利\u0026rdquo;，故甲乙都授予专利权不可能。\n题目4：著作权中，（ ）的保护期不受期限限制。 A. 发表权 B. 发行权 C. 展览权 D. 署名权\n答案：D\n解析：著作权中人身权（署名权、修改权、保护作品完整权）的保护期不受限制。\n题目5：X公司接受Y公司的委托开发了一款应用软件，双方没有订立任何书面合同。在此情形下，（ ）享有该软件的著作权。 A. X、Y公司共同 B. X公司 C. Y公司 D. X、Y公司均不\n答案：B\n解析：根据《著作权法》第十九条及《计算机软件保护条例》第十一条，受委托作品无书面合同或未明确约定的，著作权属于受托人（X公司）。\n4. 高频考点 软件著作权产生时点：开发完成之日起（不是发表日/登记日/有开发意图时）—— 必考 委托作品无合同归受托人 —— 软件委托开发也是 职务作品归单位的情形：工程设计图/产品设计图/地图/示意图/计算机软件等（且主要由单位物质技术条件完成并由单位承担责任） 人身权保护期不受限：署名权/修改权/保护作品完整权 专利权先申请原则：两个以上申请人同日同样的发明 → 协商（共同申请 / 一方放弃获补偿） 不授予专利的6类：科学发现、智力活动规则、疾病诊治、动植物品种、原子核变换、平面印刷品标识 商标专用权范围：核准注册商标 + 核定使用商品（第56条） 商业秘密三要素：秘密性、价值性、保密措施 合理使用12种情形：最常考\u0026quot;课堂教学/科研\u0026quot;和\u0026quot;图书馆/档案馆\u0026quot; ","date":"2024-01-01T00:00:00Z","permalink":"/p/23-zhi-shi-chan-quan/","title":"23-知识产权"},{"content":"24-应用数学（第24小时） 软考-系统架构设计师 | 第5篇 架构设计补充知识 出题形式：上午选择题 分值占比：2-3 分（运筹学）\n0. 考点分析 图论之最小生成树（普里姆 vs 克鲁斯卡尔） 图论之最大流量（路径求和 + 残余流量法） 线性规划（图解法 + 联立方程组法） 动态规划（装货最大价值问题） 决策分析（决策树 + EMV期望货币值） 不确定型决策（乐观/悲观/后悔值/折中/等可能 5 种准则） 1. 核心知识点 1.1 图论之最小生成树 定义 生成树：包含图中所有顶点的树 最小生成树：在连通的带权图的所有生成树中，权值和最小的那棵 边数 = 顶点数 - 1 两种算法 普里姆（Prim）算法：从某一顶点出发逐步扩展（适合稠密图） 克鲁斯卡尔（Kruskal）算法：按边长从小到大依次选取（不形成闭环），常考 典型解法步骤（Kruskal） 将所有边按权值从小到大排序 依次选取权值最小的边 若形成闭环则舍弃 直到选取了 n-1 条边（n 为顶点数） 1.2 图论之最大流量 定义 最大流量问题是一个特殊的线性规划问题 适用于：道路运输能力、管道流量等问题 解题步骤 找出一条从源到汇的路径 该路径最大流量 = 各段流量的最小值 该路径上各段流量都减去已用流量 流量为 0 的线段删除（断开） 重复 1-4 步直到无可通路径 总最大流量 = 各条路径最大流量之和 1.3 线性规划 定义 在有限资源条件下，如何有效使用这些资源达到预定目标 数学上：在一组约束条件下寻找目标表达式的极值问题 两种解法 方法 特点 适用 图解法 直观、有解/无解/最优解位置一目了然 2 变量、约束较少（计算量 O(n)） 联立方程组法 联立直线交点，逐个验证 3 变量及以上（计算量 O(n²)） 线性规划问题解的可能 唯一最优解：在解区间多边形的某个顶点上 无穷多最优解：能找到两个不同的最优解 无界解：有无穷多解但无最优解（缺少必要约束） 无可行解：约束条件互相矛盾 整数解 联立求出的解若非整数，需枚举相邻整数验证（如 P1 不符合 → P3(1,4) 符合） 1.4 动态规划 定义 将问题分解为更小的、相似的子问题 存储子问题的解避免计算重复 解决最优化问题 典型应用 装货最大价值问题： 计算每种货物的单位利润（总利润/重量） 按单位利润从大到小依次装 直到装满载重限制 剩余空间用次优物品填充 1.5 决策分析 期望货币值（EMV） EMV = Σ(每种可能结果的收益 × 发生概率) 通过比较各方案的 EMV 决策 决策树最左边做决策 → 从右向左逐层计算化简 解题技巧 画决策树：方框节点（决策点）→ 圆圈节点（机会点） 从右向左逐层计算每个机会点的 EMV 决策点选择 EMV 最大的方案 1.6 不确定型决策（5 种准则） 准则 别名 原则 乐观主义 最大最大 大中取大（每个方案选最大，再选最大） 悲观主义 最大最小 小中取大（每个方案选最小，再选最大） 折中主义 — 乐观系数 α：H = α·最大 + (1-α)·最小 等可能性 Laplace 各状态概率相等，求平均 后悔值 最小最大后悔值 见下 后悔值准则（重点） 取每种自然状态的最高值作为理想目标 用最高值 - 该状态其他值 = 后悔值 每个方案中取最大后悔值 在各方案的最大后悔值中取最小值作为决策 2. 关键概念速查 概念 公式/方法 适用场景 最小生成树 Kruskal 按边长排序 n 个顶点选 n-1 条边不形成环 最大流量 路径流量 = min(各段流量)，求和 运输网、管道网 线性规划 图解法/联立方程组 资源约束下求极值 动态规划 分解子问题 + 记忆 装货最大价值 EMV Σ(收益×概率) 概率已知 后悔值 max(state) - 实际值 概率未知 3. 典型例题 题目1（最小生成树）：某小区有七栋楼房①~⑦，各楼房之间可修水管路线的长度已标记在连线旁。为修建连通各个楼房的水管，该小区内部水管的总长度至少为（ ）百米。 A. 20 B. 21 C. 24 D. 27\n答案：A（20 百米）\n解析：采用 Kruskal 算法：\n找所有长 2 的边：①③、④⑥ → 可行 找所有长 3 的边：①⑦、③⑥ → 可行 找所有长 4 的边：①② 和 ②⑥，全部连接会闭环，舍弃 ①② 找所有长 5 的边：③④，连接形成闭环，舍弃 找所有长 6 的边：①④（形成闭环，舍弃）、⑤⑥（可行） 总长度 = 2×2 + 3×2 + 4 + 6 = 20 百米 题目2（最大流量）：某运输网从节点①到节点⑥的最大运输能力可以达到（ ）万吨每小时。\n选项：A. 26 B. 23 C. 22 D. 21 答案：B（23 万吨）\n解析：依次找路径：\n路径 ①③⑤⑥：最大 10 万吨（①③之间断开） 路径 ①②⑤⑥：最大 6 万吨（①②之间断开） 路径 ①④⑥：最大 5 万吨（④⑥之间断开） 路径 ①④③⑤⑥：最大 1 万吨 路径 ①④②⑤⑥：最大 1 万吨 总最大流量 = 10 + 6 + 5 + 1 + 1 = 23 万吨 题目3（线性规划）：某工厂生产甲、乙两种产品，已知约束 2x+3y≤14, 8x≤16, 3y≤12, 求利润最大方案。 A. 生产甲2套，乙3套 B. 生产甲1套，乙4套 C. 生产甲3套，乙4套 D. 生产甲4套，乙2套\n答案：B（生产甲1套，乙4套）\n解析：\n联立 ①+② 求得 (x=2, y=10/3) → 利润 14，但 y 不是整数 联立 ②+③ 求得 (x=2, y=4) → 不满足 ① 联立 ①+③ 求得 (x=1, y=4) → 满足约束，利润 = 2+12 = 14 整数约束下最优解为 (1, 4)，利润 14 万元。\n题目4（动态规划）：用 10 吨卡车装运货物，各种货物的重量与利润见表。最大总利润为（ ）元。\n选项：A. 530 B. 534 C. 536 D. 538 答案：D（538 元）\n解析：计算单位利润（利润/重量）：\nA: 53/1=53, B: 104/2=52, C: 156/3=52 D: 216/4=54（最大）, E: 265/5=53, F: 318/6=53 选单位利润最大的 D 装 2 件（8 吨），剩余 2 吨选单位利润次大的 A 装 2 件（2 吨），共 10 吨。 总利润 = 216×2 + 53×2 = 432 + 106 = 538 元\n题目5（决策分析）：某货运公司要从A地向B地发送价值 9000 元货物。走陆路成本 1000 元；走水路成本 700 元，但遇暴风雨（概率 15%）会损失 10% 货物。应选哪个方案？\n答案：走水路\n解析：\n走水路期望成本 = 700×85% + 1600×15% = 595 + 240 = 835 元 走陆路期望成本 = 1000×100% = 1000 元 走水路期望成本 \u0026lt; 走陆路，选走水路 题目6（后悔值）：某公司投资策略，三种经济趋势下三种投资方案收益表，用后悔值法应选（ ）。\n后悔值矩阵计算后：A 最大后悔值 350，B 最大后悔值 250，C 最大后悔值 300 选各方案最大后悔值中最小者（250）→ 稳健投资方案 B 答案：B（稳健投资方案）\n解析：后悔值准则 = 各方案最大后悔值中取最小。本例中稳健方案 250 最小。\n4. 高频考点 最小生成树：Kruskal 按边长排序 + 不形成环（n-1 条边） 最大流量：路径流量求和 + 每用一次扣减该路径所有线段流量 线性规划：3 变量以下图解法，3 变量以上联立方程组；注意整数约束 动态规划：装货问题先算单位利润，按单位利润从大到小装 决策树 EMV：从右向左计算，每层选最大 EMV 后悔值法：每状态 max - 实际 = 后悔值；每方案取 max；各 max 中取 min 乐观主义 vs 悲观主义 vs 后悔值：三种不确定决策易混淆，注意区分原则 ","date":"2024-01-01T00:00:00Z","permalink":"/p/24-ying-yong-shu-xue/","title":"24-应用数学"},{"content":"25-专业英语（第25小时） 软考-系统架构设计师 | 第5篇 架构设计补充知识 出题形式：上午单选题（5 道英文题） 分值占比：5 分\n0. 考点分析 架构风格 Architectural Style 非功能需求 Nonfunctional Requirements 应用架构 Application Architecture 软件架构重用 Software Architecture Reconstruction 三大软件架构结构（Module / Component-and-Connector / Allocation） 1. 核心知识点 1.1 架构风格（Architectural Style） An architectural style defines as a family of such systems in terms of a pattern of structural organization. More specifically, an architectural style defines a vocabulary of components and connector types, and a set of constraints on how they can be combined. For many styles there may also exist one or more semantic models that specify how to determine a system\u0026rsquo;s overall properties from the properties of its parts. Many of architectural styles have been developed over the years.\n译文：\n架构风格以一种结构化组织模式定义一组这样的系统 具体定义： 构件及连接器类型的词汇表（vocabulary of components and connector types） 关于如何组合的约束集（set of constraints on how they can be combined） 对于许多风格，还存在一个或多个语义模型，从部件特性确定系统整体特性 经典例子：管道-过滤器（pipe-and-filter）架构 → UNIX shell 程序 1.2 非功能需求（Nonfunctional Requirements） The architecture design specifies the overall architecture and the placement of software and hardware. Architecture design is a very complex process that is often left to experienced architecture designers and consultants. The first step is to refine the nonfunctional requirements into more detailed requirements that are then employed to help select the architecture to be used and the software components to be placed on each device. In a client-based architecture, one also has to decide whether to use a two-tier, three-tier, or n-tier architecture. Then the requirements and the architecture design are used to develop the hardware and software specification.\n4 种主要非功能需求 类型 关注点 关键词 Operational Requirements 系统必须执行的操作环境，及随时间变化 运行环境 Performance Requirements 响应时间、容量、可靠性 response time, capacity, reliability Security Requirements 保护信息系统免受破坏和数据丢失 故意行为防护 Cultural and Political Requirements 系统使用国家/地区 跨文化、跨地区 1.3 应用架构（Application Architecture） An application architecture specifies the technologies to be used to implement one or more information systems. It serves as an outline for detailed design, construction, and implementation.\n关键步骤：\n给定模型和详细资料（逻辑 DFD + ERD） 分配数据和过程 → 创建应用架构的概要设计 概要设计的约束因素： 架构标准（architecture standards） 项目目标（project objectives） 所使用技术的可行性（feasibility of techniques） 绘制顺序：\n第 1 个物理 DFD：网络架构 DFD（network architecture DFD） 下一步：分配数据存储到不同处理器 数据分布的两种方式： 数据分区（Data Partitioning） 数据复制（Data Replication） 不同服务器上存储特定表时 → 将每个表记为物理 DFD 中的数据存储，并连接到相应服务器 1.4 软件架构重用（Software Architecture Reconstruction） Software architecture reconstruction is an interpretive, interactive, and iterative process including many activities.\n主要活动 活动 说明 Information extraction（信息提取） 分析系统现有设计和实现工件，构造模型 Database construction（数据库构建） 将视图中元素和关系转换为标准存储格式 View fusion（视图融合） 定义和操作数据库中存储的信息，理顺、加强并建立元素之间连接 Visualization and interaction（可视化与交互） 让用户操作架构元素的机制 Pattern definition and recognition（模式定义与识别） 用于架构重构的设施 1.5 软件架构三大结构（必考） Software architectural structures can be divided into three major categories, depending on the broad nature of the elements they show.\n类别 体现的决策 关键特征 Module structures（模块结构） 体现为需要被构建或采购的代码或数据单元 编译时/静态视角 Component-and-connector structures（构件连接器结构） 系统如何被结构化为一组具有运行时行为和交互的元素 运行时/动态视角 Allocation structures（分配结构） 系统如何关联到非软件结构（CPU、文件系统、网络、开发团队等） 部署/环境视角 2. 关键概念速查 英文术语 中文 关键定义 Architectural style 架构风格 构件/连接器词汇表 + 组合约束集 Pipe-and-filter 管道-过滤器 经典架构风格，UNIX shell Nonfunctional requirements 非功能需求 操作/性能/安全/文化政治 4 类 Application architecture 应用架构 实现 IS 的技术集合，详细设计大纲 Logical DFD 逻辑数据流图 应用架构设计的输入 ERD 实体联系图 应用架构设计的输入 Network architecture DFD 网络架构数据流图 第一个物理 DFD Data partitioning 数据分区 分布式数据形式之一 Data replication 数据复制 分布式数据形式之一 Architecture reconstruction 架构重构 解释性、交互式、反复迭代过程 Information extraction 信息提取 重构活动的第一步 Module structures 模块结构 代码/数据单元（构建时） Component-and-connector structures 构件连接器结构 运行时行为和交互 Allocation structures 分配结构 关联到非软件结构（CPU/网络/团队） 3. 典型例题 题目：A system\u0026rsquo;s architecture is a representation of a system in which there is a mapping of （1） onto hardware and software components, a mapping of the （2） onto the hardware architecture, and a concern for the human interaction with these components. That is, system architecture is concerned with a total system, including hardware, software, and humans.\nSoftware architectural structures can be divided into three major categories, depending on the broad nature of the elements they show. （3） embody decisions as a set of code or data units that have to be constructed or procured. （4） embody decisions as to how the system is to be structured as set of elements that have run-time behavior and interactions. （5） embody decisions as to how the system will relate to non-software structures in its environment (such as CPUs, file systems, networks, development teams, etc.).\n（1）A. attributes B. constraint C. functionality D. requirements （2）A. physical components B. network architecture C. software architecture D. interface architecture （3）A. Service structures B. Module structures C. Deployment structures D. Work assignment structures （4）A. Decomposition structures B. Layer structures C. Implementation structures D. Component and connector structures （5）A. Allocation structures B. Class structures C. Concurrency structures D. Uses structures\n答案：\n(1) C functionality (2) C software architecture (3) B Module structures (4) D Component and connector structures (5) A Allocation structures 解析：\n(1) 系统架构 = 功能（functionality）到软硬件构件的映射 (2) 软件架构（software architecture）到硬件架构的映射 (3) 模块结构 = 代码或数据单元（构建/采购） (4) 构件连接器结构 = 运行时行为和交互 (5) 分配结构 = 关联到 CPU/文件系统/网络/开发团队等非软件结构 4. 高频考点 架构风格定义：构件/连接器词汇表 + 组合约束集 + 语义模型 非功能需求 4 类：Operational / Performance / Security / Cultural and Political 应用架构概要设计 3 约束：架构标准 / 项目目标 / 技术可行性 第一个物理 DFD：网络架构 DFD（不是逻辑 DFD） 数据分布两方式：数据分区（partitioning）+ 数据复制（replication） 架构重构 5 活动：信息提取 → 数据库构建 → 视图融合 → 可视化交互 → 模式定义识别 三大架构结构（必考）： Module structures = 代码/数据单元 Component-and-connector structures = 运行时行为和交互 Allocation structures = 关联到非软件结构 ","date":"2024-01-01T00:00:00Z","permalink":"/p/25-zhuan-ye-ying-yu/","title":"25-专业英语"},{"content":"26-论文写作方法（第26小时） 软考-系统架构设计师 | 第5篇 架构设计补充知识 论文题：下午 75 分钟，1 题必答+2 选 1，总分 75 分（占下午一半分值） 论文不通过 = 整科不通过 \u0026ldquo;得论文者得天下\u0026rdquo; —— 投入 30% 复习时间！\n0. 论文目的与要求 0.1 论文目的 系统架构设计师考试论文最能体现\u0026quot;高级\u0026quot;两个字的真实含义。论文考查考生的四大能力：\n实践经验（是否具备足够的项目经验） 分析问题能力 解决问题能力 书面表达能力 简言之：丰富的实践经验 + 较强的分析能力 + 扎实的解决问题能力 + 流畅的书面表达 = 系统架构设计师基本素养。\n0.2 论文要求（形式） 项目 要求 摘要字数 290~320 字 正文字数 2200~2800 字 卷面 整洁，字迹清晰，无错别字 语法 无明显语法、文法纰漏 行文 清晰、有逻辑 0.3 论文要求（内容 5 方面） 实践性强 —— 切忌夸大其词、过分吹嘘 契合题意 —— 不跑题，不漏洞百出 具备较高的深度和水平 —— 切忌理论堆砌、泛泛而谈 较强的综合分析能力 较好的书面表达能力 —— 文字流畅、条理分明、逻辑清晰、表达严谨 0.4 不可及格的情形 出现以下任一情况，论文不予及格：\n虚构情节，论文中有较严重的不真实/不可信内容 没有项目开发的实际经验，通篇浅层次纯理论叙述 讨论内容/方法过于陈旧，或项目水准非常低下 内容不切题意，或内容相对空洞，泛泛而谈无深入体会 正文与摘要的篇幅过于短小 文理不通、错别字多、条理不清、字迹过于潦草 1. 论文框架 1.1 摘要（290~320 字） 摘要是论文的浓缩和精华。不分段。\n摘要三部分结构：\n项目背景介绍（包括项目缘由、时间、项目名称、项目建设内容；作者的工作角色和工作内容） 项目技术简介（结合题目要求，介绍采用什么技术、方法、措施、手段等，解决了什么问题） 项目效果简述 摘要语言要精炼、概括，阐述要综合、浓缩，不宜详细展开。\n1.2 项目背景（约 400~500 字） \u0026ldquo;5W2H\u0026rdquo; 模式展开：\n要素 含义 写作要点 Why 项目由来/缘起/定位/目标 必要性陈述 When 何时 建议选近三年项目，工期半年至一年 Where 何地 不能出现实际城市名，建议\u0026quot;某省/某市\u0026quot; Who 甲乙双方 甲方脱敏；乙方称\u0026quot;我司/我单位/我厂/我公司\u0026quot; What 项目名称/建设内容/作者工作 —— How much 项目规模/预算 量化 How 采用的技术/框架/方法/工具/措施 体现技术栈 项目选择优先级：\n首选：自己参与过、亲历过、深有体会的项目 次选：未参与但熟悉或能理解的项目 末选：不熟悉但通过阅读相关文档能理解的项目 项目背景务必重点准备，不管考什么题目，项目背景都可复用。\n1.3 过渡部分（约 100 字） 项目背景介绍完毕 → 识别关键需求、项目特征、项目约束 提出满足这些因素需采取的理论/技术/措施/工具/手段 承上启下，避免上下文语义断层 1.4 理论部分（约 400~600 字） 论文题干对理论部分有明确要求（第二小问比较常见） 单独、完整地逐一应答 → 分论点 紧扣题干，问什么答什么，无关内容不要赘述 阐述基本概念、基本原理、应用场景，适当简单举例 用自己的语言或理解阐述（不必死记硬背），但要严谨、科学、正确 字数控制在 600 字以内，切忌洋洋洒洒上千字 1.5 实践部分（约 1000~1200 字，论文最重要部分） 结构上与理论部分前后呼应、保持一致，紧扣分论点 提炼小标题（小标题需仔细斟酌，能统领全段内容） 针对每个分论点，采用 \u0026ldquo;Why + How\u0026rdquo; 模式： 首先分析问题（Why） 然后解决问题（How） 深入浅出，切忌纸上谈兵 注意扬长避短，不能写成产品介绍 1.6 结尾（约 300~400 字） 呼应论点 可介绍：项目出现的小问题、项目效果、下一步计划、作者的收获 首尾呼应，避免前后矛盾 阐述问题简单带过，切忌滔滔不绝 2. 论文写作常见问题 2.1 摘要部分 问题 解决 项目背景介绍缺失 摘要必须包含项目背景 项目主要功能简介缺失 补充项目主要功能 理论介绍缺失或不足 摘要中点出采用的理论/方法 摘要草草收尾 必须有项目效果简述 字数不够 / 写得太琐细 严格控制 290~320 字 摘要分段 不分段 2.2 项目背景部分 问题 解决 只在摘要里介绍，正文不介绍 正文必须再次展开项目背景 选择非软件项目（硬件、网络、采购） 必须选软件项目 项目太陈旧 选近三年项目 项目采用的技术太陈旧 技术栈要体现先进性 虚构项目，明显不真实 项目细节要丰富真实 \u0026ldquo;帽子\u0026quot;戴得太多 简明扼要介绍 项目与理论不匹配 项目与理论主题一致 2.3 过渡部分 问题 解决 项目背景与理论之间缺少过渡句 加过渡句 理论部分与实践部分缺少过渡句 加过渡句 过渡生硬 过渡要自然 2.4 理论部分 问题 解决 篇幅太长（超过 700 字） 严格控制 400~600 字 理论部分缺失 必须有理论分论点 未响应题干要求 紧扣题干分论点 与实践部分揉在一起 单独介绍理论 基本概念、原理不清楚 概念原理要严谨、科学 简单罗列，没有深入体会 要有自己的理解 一个分论点没讲完又讲另一个 一个分论点讲完再讲下一个 与实践部分完全脱节 理论与实践要呼应 2.5 实践部分 问题 解决 篇幅太短，阐述太单薄 1000~1200 字 简单罗列，纯理论空谈 要有具体实践 自曝其短 扬长避短 阐述框架未围绕分论点 紧扣分论点 只阐述 Why，不阐述 How Why + How 都要 过于强调微观细节 宏观/大局出发 使用不合适的、错误的技术手段 技术手段要正确合理 2.6 结尾部分 问题 解决 未呼应论点/分论点 必须呼应 说起\u0026quot;问题\u0026quot;来滔滔不绝 简单带过 过于单薄/过于冗长 300~400 字 首尾不一致/前后矛盾 首尾呼应 3. 备考建议 3.1 准备策略 理论部分：与科目一、科目二协同准备，在理解的基础上记住要点 项目背景：选自己熟悉的、亲历过的，技术与理论方面选自己擅长的 精写一篇练习：购买方格子作文纸（单页 400 字），用硬笔练习 修改流程：自己大声朗读一遍 → 修改 → 请家人读一读 → 修改 → 有条件请专业老师批改 真题实战：精练一篇后，把近三年历年真题都写一遍 3.2 时间分配 投入 30% 复习时间给论文（75 分占整科 50%） 准备 4-5 个真实项目背景（不同行业） 准备 8-10 个常见论文题目的提纲 限时模拟 3-5 次（75 分钟写完） 3.3 论文题目范围（4 选 1） 系统建模 软件架构设计 系统设计 系统可靠性分析与设计 系统安全性和保密性设计 关注\u0026quot;四高\u0026quot;主题：层次式 / SOA / 大数据 / 云原生（参见第4篇 README） 4. 范文赏析 —— 论软件架构评估 4.1 摘要 我所在单位是国内某商业银行，2017 年 1 月我行决定开发全新一代绩效考核平台系统，我担任本次系统开发的架构师，主要负责整个系统的架构设计工作。该系统既要满足内控管理的绩效考核，又要满足银行粉丝客户参与营销的综合性绩效平台，是银行应对互联网金融变革和笃行普惠金融的重要系统。本文结合我的实践，以绩效考核平台系统建设为例，论述软件系统架构评估。首先分析了软件架构评估所普遍关注的质量属性并阐述其具体含义，然后详细说明本次项目软件架构评估采用的 ATAM 评估方法、实施过程，评估小组经过对系统中的风险点、敏感点、权衡点进行分析后生成质量效用树。通过 ATAM 架构评估保证了绩效考核平台系统的顺利完成，目前系统已经稳定运行一年多，得到了领导、员工、客户的一致好评。\n4.2 正文要点（节选） 项目背景：\n长三角地区某城市商业银行，机构覆盖全国多个省、直辖市 银行面临互联网金融浪潮的冲击 → 战略转型 → 绩效考核成为指挥棒 项目目标：搭建多维度、多渠道、多群体的绩效考核平台 技术栈：\nJ2EE 技术 / B/S 架构 SOA 架构设计方法 IBM DB2 10.5 Redis 内存数据库 Redhat 7.2 软件质量属性 6 项：\n性能 —— 系统响应能力 可用性 —— 系统能正常运行的时间比 安全性 —— 阻止非授权用户/拒绝服务能力 可修改性 —— 快速、以较高性价比对系统变更的能力 可靠性 —— 应用或错误面前维持功能的基本能力 易用性 —— 衡量用户完成指定任务的难易程度 架构评估方法选择：\n问卷调查法 → 主观性强，不适合 度量法 → 需精确了解架构，不适合 场景法 → 评价客观，本项目采用 场景法细分：SAAM / ATAM / CBAM → 本项目采用 ATAM ATAM 评估 4 阶段：\n描述和介绍阶段 —— 介绍 ATAM 方法、业务动机、SOA 架构、子系统划分 调查和分析阶段 —— 收集质量场景 测试阶段 —— 确定场景优先级，针对性方案设计 报告阶段 —— 整理文档（方法/场景/优先级/质量效用树/风险点决策） 质量效用树：\n性能 → A 可用性 → F、G 安全性 → B、C 可修改性 → K 可靠性 → I 易用性 → E 架构决策（针对质量属性）：\n安全性：SSL 数字证书 / HTTPS / 网闸 / 多层异构防火墙 / 入侵防护 / 分级授权 / 数据加密 可用性：VMware 虚拟化 + 心跳技术 可靠性：服务单独拆分 / 分层解耦 / Spring 拦截器统一容错 性能：Web 中间件集群 / DB2 pureScale 磁盘共享集群 + SSD 可修改性：服务拆分 + 接口调用 易用性：界面设计八大黄金法则 项目结果：\n7 个月开发 → 顺利上线 → 稳定运行一年多 已在全行推广使用，得到领导、员工、客户一致好评 5. 关键概念速查 概念 关键数据/要求 摘要字数 290~320 字（不分段） 正文字数 2200~2800 字 项目背景 400~500 字（5W2H 模式） 过渡部分 约 100 字 理论部分 400~600 字（分论点 + 紧扣题干） 实践部分 1000~1200 字（Why + How） 结尾 300~400 字（首尾呼应） 软考作文纸 单页 400 字（方格子） 论文时间 75 分钟（下午卷） 论文分值 75 分（占整科 50%） 选题规则 4 选 1 + 1 题必答（1+2 选 1） 优先项目 自己参与过、亲历过、深有体会的项目 6. 高频考点 论文字数：摘要 290320 / 正文 22002800 5W2H 项目背景：Why/When/Where/Who/What/How much/How 项目选择优先级：参与过 → 熟悉 → 文档能理解 理论部分控制：400~600 字，紧扣题干分论点 实践部分模式：Why + How，每个分论点对应小标题 不可及格 6 种情形：虚构/无经验/方法陈旧/不切题/篇幅短/文理差 质量属性 6 项：性能/可用性/安全性/可修改性/可靠性/易用性 架构评估三方法：问卷调查（主观）/度量（精确要求）/场景（客观，本项目用） 场景法细分：SAAM / ATAM / CBAM ATAM 4 阶段：描述介绍 → 调查分析 → 测试 → 报告 架构决策三概念：风险点 / 敏感点 / 权衡点 论文投入：30% 复习时间（占整科 50% 分值） ","date":"2024-01-01T00:00:00Z","permalink":"/p/26-lun-wen-xie-zuo-fang-fa/","title":"26-论文写作方法"},{"content":"模拟试题I 上午基础知识 软考系统架构设计师 | 模拟题 I 形式：75 道单项选择题，每题 1 分，共 75 分 及格线：45 分 考试时间：150 分钟（与下午共用，建议上午 90 分钟做完）\n一、计算机系统与软件工程基础（约 25 道） 1. 系统总线中不包括 A. 数据总线 B. 地址总线 C. 进程总线 D. 控制总线 答案：C 解析：总线包括数据总线、地址总线与控制总线（系统总线）。\n2. DSP 处理器采用 A. 冯·诺依曼结构 B. 哈佛结构 C. FPGA 结构 D. 与 GPU 相同的结构 答案：B 解析：DSP 芯片采用哈佛结构，将程序和数据存储器分开，两组总线独立访问，单周期可同时取指和取数据。\n3. 分布式数据库中，定义数据整体逻辑结构、使得数据使用如同没有分布一样的模式是 A. 分片模式 B. 全局外模式 C. 分配模式 D. 全局概念模式 答案：D 解析：全局概念模式定义分布式数据库中数据的整体逻辑结构，如同没有分布一样。\n4. 某计算机系统页面大小为 2K，进程 P1 的页表中 0→1、1→6、2→3、3→4，逻辑地址 1B1AH 对应的物理地址是 A. 1B1AH B. 231AH C. 6B1AH D. 4B1AH 答案：B 解析：逻辑地址 1B1AH = 二进制 1 1011 0001 1010，页号 3，块号 4，物理地址 100 0110 0011 1010 = 231AH。\n5. 在嵌入式系统的存储部件中，存取速度最快的是 A. 内存 B. 寄存器组 C. Flash D. Cache 答案：B 解析：存储速度从快到慢：寄存器组 \u0026gt; Cache \u0026gt; 内存 \u0026gt; Flash。\n6. 以下描述中，不是嵌入式操作系统的特点的是 A. 面向应用，可以进行裁剪和移植 B. 用于特定领域，不需要支持多任务 C. 可靠性高，无须人工干预独立运行，并处理各类事件和故障 D. 要求编码体积小，能够在嵌入式系统的有效存储空间内运行 答案：B 解析：嵌入式 OS 必须支持多任务调度，B 错误。\n7. 为了适应软件运行环境的变化而修改软件的活动称为 A. 纠错性维护 B. 适应性维护 C. 改善性维护 D. 预防性维护 答案：B 解析：软件维护 4 种：改正性、适应性、完善性、预防性。\n8. 根据用户在软件使用过程中提出的建设性意见而进行的维护活动称为 A. 纠错性维护 B. 适应性维护 C. 改善性维护 D. 预防性维护 答案：C 解析：完善性维护是为增加新功能/改善性能而修改软件。\n9. ERP 中的企业资源包括 A. 物流、资金流和信息流 B. 物流、工作流和信息流 C. 物流、资金流和工作流 D. 资金流、工作流和信息流 答案：A 解析：ERP 对物流、资金流、信息流进行集成管理。\n10. ERP 是建立在信息技术基础上，对企业的物流、资金流和 ______ 流进行全面集成管理的管理信息系统 A. 产品 B. 人力资源 C. 信息 D. 加工 答案：C 解析：ERP 三大流：物流、资金流、信息流。\n11. 在 ERP 系统中，______ 管理模块主要是对企业物料的进、出、存进行管理 A. 库存 B. 物料 C. 采购 D. 销售 答案：A 解析：库存管理模块负责物料进、出、存。\n12. 与电子政务相关的行为主体有三个，即政府、______ 及居民 A. 部门 B. 企（事）业单位 C. 管理机构 D. 行政机关 答案：B 解析：电子政务三主体：政府、企（事）业单位、居民。\n13. 国家和地方人口信息的采集、处理和利用，属于 ______ 的电子政务活动 A. 政府对政府 B. 政府对居民 C. 居民对居民 D. 居民对政府 答案：A 解析：政府对政府（G2G）的典型应用。\n14. 电子政务的主要应用模式中不包括 A. 政府对政府（G2G） B. 政府对客户（G2C，Government To Customer） C. 政府对居民（G2C，Government To Citizen） D. 政府对企业（G2B） 答案：B 解析：电子政务主要模式 G2G/G2B/G2C/B2G/C2G，不包括 G2Customer。\n15. 给定关系 R(A,B,C,D,E) 和关系 S(D,E,F,G)，对其进行自然连接运算 R⋈S 后结果集的属性列为 A. R.A,R.B,R.C,R.D,R.E,S.D,S.E B. R.A,R.B,R.C,R.D,R.E,S.F,S.G C. R.A,R.B,R.C,R.D,R.E,S.E,S.F D. R.A,R.B,R.C,R.D,R.E,S.D,S.E,S.F,S.G 答案：B 解析：自然连接去重相同属性 D、E，保留 R 的 5 个 + S 的 F、G。\n16. 设关系模式 R(U,F)，U={A1,A2,A3,A4}，F={A1→A2, A1→A3, A2→A4}，R 的候选码是 A. A1 B. A2 C. A1A2 D. A1A3 答案：A 解析：A1 决定所有其他属性，是唯一候选码。\n17. 下列结论错误的是 A. A1→A2A3 为 F 所蕴含 B. A1→A4 为 F 所蕴含 C. A1A2→A4 为 F 所蕴含 D. A2→A3 为 F 所蕴含 答案：D 解析：A3 只能由 A1 推出，A2 无法得到 A3。\n18. 查询\u0026quot;张晋\u0026quot;选修了\u0026quot;市场营销\u0026quot;课程的学号、学生名、学院名、成绩的关系代数表达式中，σ2=\u0026lsquo;张晋\u0026rsquo; 作用的关系是 A. σ2=张晋(S) B. σ2=\u0026lsquo;张晋\u0026rsquo;(S) C. σ2=张晋(SC) D. σ2=\u0026lsquo;张晋\u0026rsquo;(SC) 答案：B 解析：在 S 关系中选择姓名为\u0026quot;张晋\u0026quot;的元组。\n19. 关系代数表达式中，π1,2(σ2=\u0026lsquo;市场营销\u0026rsquo;(C))⋈SC 表达的含义是 A. 选课课程号、市场营销课程号 B. 在 SC 中选课号为\u0026quot;市场营销\u0026quot; C. 在 C 中选课程名是\u0026quot;市场营销\u0026quot;投影课程号、课程名再与 SC 自然连接 D. 在 SC 中课程名是\u0026quot;市场营销\u0026quot;投影再与 C 连接 答案：C 解析：在 C 中筛选\u0026quot;市场营销\u0026quot;课程，投影 1,2 列，再与 SC 自然连接。\n20. 在数据库设计的需求分析阶段应当形成 A. 程序文档、数据字典和数据流图 B. 需求说明文档、程序文档和数据流图 C. 需求说明文档、数据字典和数据流图 D. 需求说明文档、数据字典和程序文档 答案：C 解析：需求分析阶段产出：需求说明文档、数据字典、数据流图。\n21. 数据库需求分析阶段形成的文档可作为 ______ 阶段的设计依据 A. 逻辑结构设计 B. 概念结构设计 C. 物理结构设计 D. 数据库运行和维护 答案：B 解析：需求分析 → 概念结构设计。\n22. 基于软件架构的设计（ABSD）强调采用 ______ 来描述软件架构 A. 类图和序列图 B. 视角与视图 C. 构件和类图 D. 构件与功能 答案：B 解析：ABSD 用视角与视图描述软件架构。\n23. ABSD 强调采用 ______ 来描述需求 A. 用例与类图 B. 用例与视角 C. 用例与质量属性场景 D. 视角与质量属性场景 答案：C 解析：ABSD 用用例与质量属性场景描述需求。\n24. 以下关于鸿蒙操作系统的叙述中，不正确的是 A. 鸿蒙采用分层设计：内核层、系统服务层、框架层、应用层 B. 鸿蒙内核层采用宏内核设计 C. 鸿蒙采用分布式设计理念 D. 鸿蒙分布式安全性体现在\u0026quot;正确的人，通过正确的设备，正确地使用数据\u0026quot; 答案：B 解析：鸿蒙采用微内核架构，不是宏内核。\n25. \u0026ldquo;在并发用户数量为 1000 人时，用户的交易请求需要在 0.5 秒内得到响应\u0026quot;主要与 ______ 质量属性相关 A. 性能 B. 吞吐量 C. 可靠性 D. 可修改性 答案：A 解析：响应时间要求属于性能。\n26. 通常可采用 ______ 架构策略实现\u0026quot;响应时间 0.5 秒\u0026quot;这一性能属性 A. 操作串行化 B. 资源调度 C. 心跳 D. 内置监控器 答案：B 解析：性能策略：增加资源、减少开销、并发、资源调度等。\n27. \u0026ldquo;当系统由于软件故障意外崩溃后，需要在 0.5 小时内恢复正常运行\u0026quot;主要与 ______ 质量属性相关 A. 可测试性 B. 易用性 C. 可用性 D. 互操作性 答案：C 解析：故障后恢复时间属于可用性。\n28. 通常可采用 ______ 架构策略实现\u0026quot;故障恢复 0.5 小时\u0026quot;这一可用性属性 A. 主动冗余 B. 信息隐藏 C. 抽象接口 D. 记录/回放 答案：A 解析：可用性策略：心跳、Ping/Echo、主动冗余、被动冗余、选举等。\n29. \u0026ldquo;系统应该能够抵挡恶意用户的入侵行为，并进行报警和记录\u0026quot;主要与 ______ 质量属性相关 A. 可用性 B. 安全性 C. 可测试性 D. 可修改性 答案：B 解析：抵御入侵属于安全性。\n30. 通常可采用 ______ 架构策略实现安全性属性 A. 内置监控器 B. 记录/回放 C. 追踪审计 D. 维护现有接口 答案：C 解析：安全性策略：入侵检测、用户认证、用户授权、追踪审计等。\n二、数据库与软件工程（约 18 道） 31. 下列关于软件可靠性的叙述，不正确的是 A. 由于影响软件可靠性的因素很复杂，软件可靠性不能通过历史数据和开发数据直接测量和估算出来 B. 软件可靠性是指在特定环境和特定时间内，计算机程序无故障运行的概率 C. 在软件可靠性的讨论中，故障指软件行为与需求的不符，故障有等级之分 D. 排除一个故障可能会引入其他的错误，而这些错误会导致其他的故障 答案：A 解析：软件可靠性可以通过历史数据和开发数据直接测量和估算出来。\n32. 网上书城用户频繁查询书目，架构师在数据访问层设计时最可能考虑采用 A. 在线访问模式和 DAO 模式相结合 B. 在线访问模式和离线数据模式相结合 C. DAO 模式和 DTO 模式相结合 D. DTO 模式和 O/R 映射模式相结合 答案：B 解析：查询多 + 数据量大 + 较频繁 → 在线 + 离线缓存结合。\n33. 网站管理员需要批量对相关书目信息进行修改并记录到数据库，架构师最可能考虑采用 A. 在线访问模式 B. DAO 模式 C. 离线数据模式 D. O/R 映射模式 答案：C 解析：批量更新 + 交互体验 → 离线数据模式。\n34. 螺旋模型在 ______ 的基础上扩展而成 A. 瀑布模型 B. 原型模型 C. 快速模型 D. 面向对象模型 答案：B 解析：螺旋模型在原型模型基础上扩展，引入风险分析。\n35. 适用于程序开发人员在地域上分布很广的开发团队的方法是 A. 水晶系列（Crystal）开发方法 B. 开放式源码（Open Source）开发方法 C. SCRUM 开发方法 D. 功用驱动开发方法（FDD） 答案：B 解析：开源项目开发人员地域分布广，并行 Debug。\n36. 编程开发人员分成首席程序员和\u0026quot;类\u0026quot;程序员的方法是 A. 自适应软件开发（ASD） B. 极限编程（XP） C. 开放统一过程开发方法（OpenUP） D. 功用驱动开发方法（FDD） 答案：D 解析：FDD 中分首席程序员（Class Owner）和\u0026quot;类\u0026quot;程序员。\n37. 以下活动中，不属于需求管理的主要活动的是 A. 文档管理 B. 需求跟踪 C. 版本控制 D. 变更控制 答案：A 解析：需求管理包括变更控制、版本控制、需求跟踪。文档管理不在其中。\n38. 软件动态测试通过运行程序发现错误，包括 ______ 等方法 A. 边界值分析、逻辑覆盖、基本路径 B. 桌面检查、逻辑覆盖、错误推测 C. 桌面检查、代码审查、代码走查 D. 错误推测、代码审查、基本路径 答案：A 解析：动态测试 = 黑盒（边界值/等价类/错误推测）+ 白盒（逻辑覆盖/基本路径）。\n39. 静态测试采用人工和计算机辅助静态分析手段对程序进行检测，包括 ______ 等方法 A. 边界值分析、逻辑覆盖、基本路径 B. 桌面检查、逻辑覆盖、错误推测 C. 桌面检查、代码审查、代码走查 D. 错误推测、代码审查、基本路径 答案：C 解析：静态测试 = 桌面检查、代码走查、代码审查。\n40. 以下关于原型的叙述中，正确的是 A. 水平原型适合于算法较为复杂的项目 B. 垂直原型适合于 Web 项目 C. 抛弃式原型适合于需求不确定、不完整、含糊不清的项目 D. 演化式原型主要用于界面设计 答案：C 解析：抛弃式原型适合需求不明确项目；演化式原型适合 Web 项目；垂直原型适合复杂算法；水平原型主要用于界面。\n41. 快速应用开发（RAD）通过使用基于 ______ 的开发方法获得快速开发 A. 用例 B. 数据结构 C. 剧情 D. 构件 答案：D 解析：RAD 基于构件。\n42. 当 ______ 时，最适合采用 RAD 方法 A. 一个新系统要采用很多新技术 B. 新系统与现有系统有较高的互操作性 C. 系统模块化程度较高 D. 用户不能很好地参与到需求分析中 答案：C 解析：RAD 对模块化要求高。\n43. 软件架构维护过程不包括 A. 架构知识管理 B. 架构修改管理 C. 架构版本管理 D. 架构构件管理 答案：D 解析：架构维护过程：知识管理、修改管理、版本管理。\n44. 下列软件架构演化时期，______ 是在系统设计时规定了演化的具体条件，将系统置于\u0026quot;安全\u0026quot;模式下 A. 设计时演化 B. 运行前演化 C. 有限制运行时演化 D. 运行时演化 答案：C 解析：有限制运行时演化：只发生在特定约束满足时。\n45. 根据所修改的内容不同，软件的动态演化不包括 A. 属性改名 B. 行为变化 C. 拓扑结构改变 D. 格式变化 答案：D 解析：动态演化内容：属性改名、行为变化、拓扑结构改变、风格变化。格式变化不是。\n46. ATAM 评估方法主要包括 4 个阶段：场景和需求收集、______、属性模型构造和分析、属性模型折中 A. 架构视图和场景实现 B. 架构风格和场景分析 C. 架构设计和目标分析 D. 架构描述和需求评估 答案：A 解析：ATAM 4 阶段：场景和需求收集 → 架构视图和场景实现 → 属性模型构造和分析 → 属性模型折中。\n47. ATAM 方法要求在系统开发之前，首先对这些质量属性进行 ______ 和折中 A. 设计 B. 实现 C. 测试 D. 评价 答案：D 解析：ATAM 要求在系统开发前对质量属性进行评价和折中。\n48. 库存管理系统和财务系统一体化集成，最适合的集成方法是 A. 数据集成 B. 界面集成 C. 方法集成 D. 接口集成 答案：B 解析：最小代价实现 C/S 系统一体化 → 界面集成。\n三、信息安全（约 15 道） 49. CPS 技术体系的四大核心技术要求中，\u0026ldquo;一平台\u0026quot;是 A. 感知和自动控制 B. 工业软件 C. 工业网络 D. 工业云和智能服务平台 答案：D 解析：CPS 4 要素：一硬（感知自动控制）、一软（工业软件）、一网（工业网络）、一平台（工业云和智能服务平台）。\n50. 机器学习中，______ 是利用已标记的有限训练数据集，通过某种学习策略建立模型 A. 监督学习 B. 无监督学习 C. 半监督学习 D. 强化学习 答案：A 解析：监督学习使用标注样本集。\n51. 云计算的服务方式不包括 A. 软件即服务 B. 计算即服务 C. 平台即服务 D. 基础设施即服务 答案：B 解析：云计算 3 大服务：SaaS、PaaS、IaaS。\u0026ldquo;计算即服务\u0026quot;不是标准说法。\n52. 以下属于主动攻击的是 A. 网络监听 B. 信息截取 C. 非法登录 D. 假冒身份 答案：D 解析：主动攻击会对信息进行修改、伪造（假冒身份属于主动攻击）。\n53. 信息安全体系中，数据库的容灾属于 ______ 的内容 A. 物理线路安全与网络安全 B. 网络安全与系统安全 C. 物理线路安全与系统安全 D. 网络安全与应用安全 答案：D 解析：数据库容灾属于应用安全（信息存储）和网络安全（访问控制）。\n54. ______ 模型为数据规划机密性，依据机密性划分安全级别，按安全级别强制访问控制 A. BLP 模型 B. 状态机模型 C. Biba 模型 D. CWM 模型 答案：A 解析：Bell-LaPadula（BLP）模型关注机密性。\n55. \u0026ldquo;在某个系统或某个部件中设置了\u0026rsquo;机关\u0026rsquo;，使得当提供特定的输入数据时，允许违反安全策略\u0026quot;属于哪一种安全威胁 A. 特洛伊木马 B. 陷阱门 C. 窃取 D. 非法使用 答案：B 解析：陷阱门（Trapdoor）定义：在系统中设置\u0026quot;机关\u0026rdquo;，特定输入触发可绕过安全策略。\n56. 嵌入式系统分层架构的脆弱性包括 ______ 等两方面 A. 底层发生错误会导致整个系统无法正常运行、层与层之间功能引用可能导致功能失效 B. 底层发生错误会导致整个系统无法正常运行、层与层之间引入通信机制势必造成性能下降 C. 上层发生错误会导致整个系统无法正常运行、层与层之间引入通信机制势必造成性能下降 D. 上层发生错误会导致整个系统无法正常运行、层与层之间的功能引用可能导致功能失效 答案：B 解析：层间脆弱性（底层错误影响整体）+ 层间通信脆弱性（通信开销导致性能下降）。\n57. 局域网网络架构有 4 种类型，以下说法错误的是 A. 单核心架构使用单台核心二层或三层交换设备作为网络核心 B. 单核心架构的优点是结构简单，设备投资节约，接入方便 C. 双核心架构采用两台核心三层及以上交换机作为网络核心 D. 环型架构的缺点是投资较单核心高，核心端口密度要求较高 答案：D 解析：双核心架构的缺点才是\u0026quot;投资较单核心高，核心端口密度要求较高\u0026rdquo;，D 把双核心的缺点张冠李戴到环型架构。\n58. 以下不属于网络安全协议的是 A. FTP B. SSL C. HTTPS D. SET 答案：A 解析：FTP（文件传输协议）非安全协议。\n59. 以下关于层次化网络设计原则的叙述中，错误的是 A. 一般将网络划分为核心层、汇聚层、接入层三个层次 B. 应当首先设计核心层，再根据必要的分析完成其他层次的设计 C. 为了保证网络的层次性，不能在设计中随意加入额外连接 D. 除去接入层，其他层次应尽量采用模块化方式 答案：B 解析：层次化网络设计应从接入层开始向上分析规划。\n60. 以下关于大数据的说法中，错误的是 A. 大数据拥有体量大、构造单调、时效性强等特点 B. 处理大数据需要采用新式计算架构和智能算法等新技术 C. 大数据的应用着重相关剖析，而不是因果剖析 D. 大数据的目的在于发现新的知识，洞悉并进行科学决策 答案：A 解析：大数据特征是\u0026rdquo;类型多样\u0026quot;，而非\u0026quot;构造单调\u0026rdquo;。\n61. Lambda 架构中，______ 的核心功能是存储主数据集 A. 批处理层 B. 流处理层 C. 加速层 D. 存储层 答案：A 解析：批处理层存储主数据集。\n62. Lambda 架构中，______ 的核心功能是处理增量实时数据、生成实时视图、快速执行即席查询 A. 批处理层 B. 服务层 C. 加速层 D. 视图层 答案：C 解析：加速层（Speed Layer）处理实时增量数据。\n63. Lambda 架构中，______ 的核心功能是响应用户请求，合并批视图和实时视图 A. 视图层 B. 流处理层 C. 服务层 D. 存储层 答案：C 解析：服务层（Serving Layer）合并视图响应用户请求。\n四、架构与中间件（约 7 道） 64. 微服务架构中，每个服务可以 A. 独立进行开发、管理、迭代 B. 独立进行部署、运维、升级 C. 独立进行测试、交付、验收 D. 独立进行发布、发现、访问 答案：A 解析：微服务可独立进行开发、管理、迭代。\n65. MD5 是一种 ______ 算法 A. 共享密钥 B. 公开密钥 C. 报文摘要 D. 访问控制 答案：C 解析：MD5 是报文摘要（消息摘要）算法。\n66. SQL 注入攻击的首要目标是 A. 破坏 Web 服务 B. 窃取用户口令等机密信息 C. 攻击用户浏览器 D. 获得数据库的权限 答案：D 解析：SQL 注入的最终目标是获取数据库权限。\n67. 在数据库的安全机制中，通过提交 ______ 供第三方开发人员使用进行数据更新，从而保证数据库的关系模式不被第三方所获取 A. 索引 B. 视图 C. 触发器 D. 存储过程 答案：D 解析：存储过程可屏蔽关系模式，类似函数编程接口。\n五、应用数学（约 3 道） 68. 某超市某种面包日销量为 100、110、120、130、140 个的概率相同（均 20%），每个进价 4 元，售价 5 元，未售完次日 3 元处理。为取得最大利润，每天应进货 ______ 个 A. 110 B. 120 C. 130 D. 140 答案：B 解析：通过期望收益计算：进 120 个时平均利润 108 元最大。\n69. 6 个节点 A、B、C、D、E、F 之间路径距离表，从 A 到 F 的最短距离是 A. 38 B. 40 C. 44 D. 46 答案：A 解析：A→C→F = 16+22 = 38（最短）。\n70. 某项目的双代号网络图，该项目的工期为 A. 17 B. 18 C. 19 D. 20 答案：C 解析：关键路径 ADHKMP / ADILOP / BEHKMP / BEILOP，工期都是 19。\n六、英语（约 5 道） 71. The objective of ______ is to determine what parts of the application software will be assigned to what hardware A. architecture design B. modular design C. physical design D. distribution design 答案：A 解析：架构设计（architecture design）的目标就是把软件构件分配到硬件构件。\n72. All software systems can be divided into four basic functions. The first is ______ A. data access components B. database management system C. data storage D. data entities 答案：C 解析：4 项基本功能：数据存储（data storage）、数据接口逻辑、应用逻辑、表示逻辑。\n73. The second function is the ______ , the processing required to access data A. data persistence B. data access objects C. database connection D. data access logic 答案：D 解析：第二项功能是数据访问逻辑（data access logic）。\n74. The third function is the ______ , which is the logic documented in the DFDs, use cases, and functional requirements A. system requirements B. system architecture C. application logic D. application program 答案：C 解析：第三项是应用逻辑（application logic）。\n75. The three primary hardware components of a system are A. computers, cables and network B. clients, servers, and network C. CPUs, memories and I/O devices D. CPUs, hard disks and I/O devices 答案：B 解析：系统 3 类主要硬件构件：客户机、服务器、网络。\n参考答案速查 题号 1 2 3 4 5 6 7 8 9 10 答案 C B D B B B B C A C 题号 11 12 13 14 15 16 17 18 19 20 答案 A B A B B A D B C C 题号 21 22 23 24 25 26 27 28 29 30 答案 B B C B A B C A B C 题号 31 32 33 34 35 36 37 38 39 40 答案 A B C B B D A A C C 题号 41 42 43 44 45 46 47 48 49 50 答案 D C D C D A D B D A 题号 51 52 53 54 55 56 57 58 59 60 答案 B D D A B B D A B A 题号 61 62 63 64 65 66 67 68 69 70 答案 A C C A C D D B A C 题号 71 72 73 74 75 答案 A C D C B ","date":"2024-01-01T00:00:00Z","permalink":"/p/27-mo-ni-shi-ti-i-shang-wu-ji-chu-zhi-shi/","title":"27-模拟试题I上午基础知识"},{"content":"模拟试题I 下午案例分析 软考系统架构设计师 | 模拟题 I 案例 形式：5 道案例题，每题 25 分，共 75 分 及格线：45 分 考试时间：与上午共用 150 分钟 必答：5 道全答（无选答）\n试题一：数据架构与消息处理系统设计（25 分） 背景 某互联网公司拟开发用户通信软件系统，向用户提供即时通信服务。核心功能是做好消息内容识别与内容防护，防止恶意用户利用该软件进行非法内容传输：\n对于正常消息：采用消息封装、正常转发等处理 对于一般有害的辱骂、恐吓消息：进行改写处理 对于重大危害消息：过滤处理并对用户封号 需求与质量属性（a~k 共 11 项），摘录如下：\n编号 描述 (a) 管理员后台对用户封号/解封，设置后即可生效 (b) 完整的安全防护措施，支持恶意攻击行为检测与报警 (c) 正常负载下 0.3 秒内响应用户发送消息请求 (d) 消息体以汉字、英文字母、数字、标点为主，不超过 1024 字节 (e) 正常负载下，发送新消息后 1 秒内对方收到 (f) 主服务异常中断后 5 秒内重定向到备用服务 (g) 支持横向用户/消息存储扩展，2 人·天内完成扩展与测试 (h) 宕机后 10 秒内感知错误，自动启动热备份系统 (i) 对内提供接口函数，支持信息收集、功能调试、系统诊断 (j) 所有用户消息备份至少 7 天 (k) 聊天软件外观调整 4 人·天内完成 公司提出两种候选架构方案：李工（黑板系统风格）+ 王工（管道-过滤器风格），最终采用二者结合。\n问题 1（12 分） 在架构评估过程中，质量属性效用树（Utility Tree）是对系统质量属性进行识别和优先级排序的重要工具。请将合适的质量属性名称填入图 1.1 中（1）、（2）空白处，并选择题干描述的（a）（k）填入（3）（6）空白处，完成该系统的效用树。\n效用树结构示意：\n1 2 3 4 5 6 7 8 9 10 11 12 性能效用 ├── （1） ← 请填 └── （2） ← 请填 可用性 ├── （c） ← 0.3秒响应 ├── （3） ← 待选 ├── （4） ← 待选 ├── （f） ├── （5） ← 待选 ├── （g） ├── （6） ← 待选 └── （k） 参考答案：\n（1）安全性 （2）可修改性 （3）（e）— 1 秒内对方收到（性能） （4）（j）— 消息备份 7 天（可修改性） （5）（h）— 10 秒内自动启动热备（可用性） （6）（k）— 4 人·天外观调整（可修改性） 问题 2（13 分） 针对该系统的有害信息过滤功能，李工建议采用黑板系统风格，王工认为李工的方案存在问题（即负责消息封装、正常转发的构件需要等待其他有害消息处理构件处理之后才能开始工作），提出采用管道-过滤器风格。 请针对王工和李工的方案，分析和对比黑板系统风格和管道-过滤器风格的各自优缺点，并说明如何综合两种风格，来更好地实现软件功能。\n参考答案：\n1）黑板风格。\n优点：可用于非确定性问题求解，启发式解决过程；可维护性好；可重用性好。 缺点：不能确保期望结果，效率低下；回退；不支持并行；共享空间的访问需要同步。 2）管道-过滤器风格。\n优点：简单性；支持复用；系统具有可扩展性；系统并发性（每个过滤器可以独立运行，不同子任务可以并行执行，提高效率）。 缺点：不适合用来设计交互式应用系统。 3）综合方式：在内容识别、有害信息处理的构件之间采用黑板风格；对于可转发的消息可以采用管道-过滤器风格，交给后续的消息封装、正常转发的构件。取长补短。\n试题二：互联网商品交易平台架构设计（25 分） 背景 某互联网公司欲建设商品交易平台，平台邀请大牌商户入驻，后期承担较大全国用户请求流量与较高并发用户数。\n性能需求：\n平台承担较大全国用户请求流量与高并发用户数（最重要） 重要节日有秒杀促销活动，要承担流量尖峰，保证较低访问延时 平台需要达到一定的可用性 涉及金融支付领域，对订单及支付数据存储有较高的安全性、可靠性要求 方案对比：\n角色 接入层 应用层 存储层 王工 Nginx（7 层负载均衡） SOA 整合可复用网络服务 传统 Oracle 李工 LVS（4 层负载均衡） 微服务架构 MySQL 主从 + 分库分表 + 读写分离 张工（补充） 在全国设立 4 个机房分别部署一套平台服务 问题 1（10 分） 请用 200 字以内的文字简述王工的 SOA 方案和李工的微服务方案的不同点，根据该项目应该选择哪个方案？\n参考答案：\nSOA 与微服务的不同点：\nSOA 设计思路是把组件和服务通过服务总线组装成更大的应用（从小到大）；微服务是把应用拆分成独立自治的小服务（从大到小） SOA 依赖基于 XML 的消息格式和基于 SOAP 的通信协议；微服务大量依赖 REST 和 JSON SOA 需要 ESB 总线负责服务间通信转发和接口适配；微服务强调更轻量级、更迅速、去中心化 SOA 强调分层（展现/业务/总线/数据）；微服务的服务更松散，更容易扩展 SOA 中的服务不强调业务领域的自治性；微服务强调基于领域的服务自治性 选择：由于该平台业务规模体量较大，考虑到微服务的伸缩性、去中心化和自治性，采用李工的方案更容易提升性能，并能更好地适应研发团队的解耦。\n问题 2（10 分） 经深入讨论公司支持了李工的方案，请阐述针对存储层采用 MySQL 来进行分库分表、主从结构的设计的原因。\n参考答案：\n采用 MySQL 开源组件本身可降低成本 两个 MySQL 设计成主从模式可提高平台要求的可用性：主节点异常，从节点可代替主节点继续提供服务 以主从模式为基础设计多套 MySQL 主从实现分库分表，每个节点平摊数据存储量，进一步提升总体性能和系统容量 问题 3（5 分） 公司也同时认可了张工补充的开设多个机房方案，但该方案需要依赖其他技术，请简述其中一种关键性技术，并说明其作用。\n参考答案：\nDNS 解析：根据用户的 IP 解析到距离用户最近的机房，减少用户访问平台的时延和拥挤程度 试题三：服务型智能扫地机器人架构设计（25 分） 背景 服务型智能扫地机器人需要自主运动规划和导航功能，通过环境信息融合感知进行行为决策。\n主要功能（8 项）：\n紧急状态感知：碰撞检测、跌落检测、离地检测 姿态感知：运动里程计数、航向测量 视觉感知：单目视觉避障系统、单目视觉定位系统（可结合红外测距） 自动充电：实时监控电量，低于阈值时自动返回充电 扫地及吸尘单元：电机控制刷子清扫 + 抽灰电机吸尘 运动执行：控制机器人运动 监控系统：无线网络传递状态/视频，PC + 手机客户端 信息处理中心：接收传感器和视觉信息，分析处理后控制运动，与后台通信 硬件采用 ARM+STM32 双核架构：\nSTM32F103VET6：实现非图像以外的众多传感器的驱动及数据采集，控制车轮电机 ARM S5PV210：摄像头图片采集、接入无线网络、综合处理 STM32 串口传过来的传感器数据 + 图像定位避障信息，生成运动决策发送给 STM32 问题 1（15 分） 图 3.1 是本题的服务型智能扫地机器人典型的功能结构图，请根据说明的描述，完成该功能结构图，将（1）~（5）的内容填在答题纸上相应的位置中。\n参考答案：\n（1）紧急状态感知 （2）跌落检测 （3）航向测量 （4）单目视觉避障系统 （5）扫地及吸尘单元 问题 2（6 分） 请根据下表 3.1 中各传感器的功能描述，将（1）~（6）填入相应的位置。\n序号 传感器类别 功能 参数 1 （1） 用于障碍物规避 输出模拟电压量 2 （2） 平台防跌落 输出数字量 3 （3） 车身离地检测 输出数字量 4 （4） 碰撞检测 输出数字量 5 （5） 检测航向角度 检测角度 ±180° 6 （6） 测速和计里程 脉冲输出 7 USB 摄像头 采集环境图像信息 YUV 和 MJPG 格式 参考答案：\n（1）红外测距传感器 （2）数字式防跌落传感器 （3）开关式传感器 （4）槽型光耦模块 （5）GGPM01A 单轴角度陀螺仪 （6）霍尔码盘传感器 问题 3（4 分） 硬件采用 ARM+STM32 双核架构，串口传输数据格式：8 位数据位 + 1 位起始位 + 1 位停止位，无校验位。 （1）当波特率为 9600b/s 时，每秒钟传送的有效数据是多少字节？ （2）为保证数据收发正确（每个字节数据传输中的累计误差不大于 1/4 bit），分析发送方和接收方时钟允许的误差范围，并以百分比形式给出最大误差。\n参考答案：\n（1）有效数据计算：\n9600 ÷ (8 + 1 + 1) = 960 字节/秒 （2）最大误差：\n每个字节数据含 8+1+1 = 10 bit 每个 bit 的最大误差为 (1/4) ÷ 10 = 0.025 所以最大误差为 0.025 × 100% = 2.5% 试题四：分布式数据库与 NoSQL 方案（25 分） 背景 某软件企业开发了一套新闻社交类软件（新闻发布、用户关注、用户推荐、新闻点评、新闻推荐、热点新闻等），采用 MySQL 存储业务数据。系统上线后用户量增加，数据库服务器压力不断加大。\n工作组的方案：\n角色 方案 优缺点 张工 MySQL 读写分离 + 主从复制 程序改动小、较快完成、后续可扩展到 MySQL 集群 李工 用 NoSQL 完全替代 MySQL 工作量太大，短期无法完成 刘工 Key-Value + MySQL 混合方案 综合二者优点 最终采用刘工方案（见张工方案的图 4.1）。\n问题 1（8 分） 张工方案中采用了读写分离、主从复制策略。简述主从复制给系统带来的好处。\n参考答案：\n避免数据库单点故障：主服务器实时、异步复制数据到从服务器，当主数据库宕机时，可从从数据库中选择一个升级为主服务器 提高查询效率：主库进行数据插入、删除及更新等写操作，从库专门用来进行数据查询操作，将查询操作分担到不同的从服务器以提高数据库访问效率 问题 2（8 分） MySQL 数据库中，主从复制通过 binary log 来实现主从服务器的数据同步。请简述主从复制的过程。\n参考答案： 当在从库上启动复制时：\n首先创建 I/O 线程连接主库 主库随后创建 Binlog Dump 线程读取数据库事件并发送给 I/O 线程 I/O 线程获取到事件数据后更新到从库的中继日志 Relay Log 中去 之后从库上的 SQL 线程读取中继日志 Relay Log 中更新的数据库事件并应用 问题 3（9 分） 主从复制可以采用同步、异步、半同步复制。请简述每种复制技术的特点。\n参考答案：\n1）同步复制：主数据库需要等待所有备数据库均操作成功才可以响应用户，影响用户体验。这种方式保证了系统的一致性，但牺牲了数据的可用性。\n2）异步复制：当用户请求更新数据时，主数据库处理完请求后可直接给用户响应，而不必等待备数据库完成同步，备数据库会异步进行数据的同步，用户的更新操作不会因为备数据库未完成数据同步而导致阻塞。这种方式保证了系统的可用性，但牺牲了数据的一致性。\n3）半同步复制：用户发出写请求后，主数据库会执行写操作，并给备数据库发送同步请求，但主数据库不用等待所有备数据库回复数据同步成功便可响应用户，也就是说主数据库可以等待一部分备数据库同步完成后响应用户写操作执行成功。\n试题五：金融交易信息系统微服务架构（25 分） 背景 某互联网金融集团依托微服务技术研发互联网金融交易信息系统，全面整合原分布于各省地方分公司的区域系统，实现统一用户账户管理、转账汇款、理财投资、贷款管理、网上交易、网上支付、财务共享、财务统计分析等。\n方案讨论：\n王工：采用 SOA，通过 ESB 充分整合现有业务，支持 Web、智能手机等多端接入相同后端服务 张工：采用分布式微服务架构，整合业务同时利用云服务提高性能、可用性、可扩展性、可变性、可维护性 最终结合使用，制定基于分布式微服务的前后端分离体系结构。\n问题 1（8 分） 请简要叙述微服务架构的含义和关键原则。\n参考答案： 微服务是一种软件开发技术，是面向服务的体系结构（SOA）架构风格的一种变体。微服务将应用程序构造为一组松散耦合的服务，微服务中单个应用程序由许多松散耦合且可独立部署的较小组件或服务组成。\n微服务风格的关键原则：\n每一个 URI 代表 1 种资源 客户端使用 HTTP Verb 表示操作方式的动词对服务端资源进行操作 通过操作资源的表现形式来操作资源 资源的表现形式是 XML 或者 HTML 客户端与服务端之间的交互是无状态的，客户端每个请求必须包含理解请求所必需的所有信息 问题 2（8 分） 请从（a）（n）中选择合适的内容填入图 5.1 的（1）（8）中，补充完善体系结构设计图。\n选项：\n(a) 页面缓存 (b) 网关层 (c) 数据层 (d) 主数据库 (e) Web 服务器 (f) 反向代理服务器 (g) 事务中心 (h) 服务层 (i) 数据访问组件 (j) CDN (k) 展示层 (l) 数据中心 (m) 从数据库 (n) 分布式数据缓存 参考答案：\n（1）（j）CDN （2）（e）Web 服务器 （3）（n）分布式数据缓存 （4）（l）数据中心 （5）（d）主数据库 （6）（m）从数据库 （7）（h）服务层 （8）（c）数据层 问题 3（9 分） 项目组进行需求调研时发现用户界面部分变动可能比较频繁，需要降低系统界面与业务逻辑之间的耦合度。MVVM 模式是由 MVC 模式派生出的一种设计模式，请从组件耦合度、组件分工及对开发工程化支持等 3 个方面说明 MVVM 模式与 MVC 模式的主要区别。\n参考答案：\n项目 MVC MVVM 组件分工 M：数据模型或仓库抽象；V：视图抽象；C：控制，处理控制逻辑 M：数据模型或仓库抽象；V：视图抽象；VM：视图模型，双向绑定 组件耦合度 耦合度低 事件传递，逻辑下沉；耦合度低；Binder 双向绑定 对开发工程化支持 重用度高；通过模板引擎技术实现了代码工程的分离 提高可重用度；通过 Ajax 技术实现了静态工程与动态工程的分离 ","date":"2024-01-01T00:00:00Z","permalink":"/p/28-mo-ni-shi-ti-i-xia-wu-an-li-fen-xi/","title":"28-模拟试题I下午案例分析"},{"content":"模拟试题I 下午论文 软考系统架构设计师 | 模拟题 I 论文 形式：4 道论文题选 1 道（必答） 总分：75 分（300 分制中权重最大） 及格线：45 分 写作时间：75 分钟（不含构思）\n论文题一：论软件系统架构评估 题目要求 对于软件系统，尤其是大规模的复杂软件系统来说，软件的系统架构对于确保最终系统的质量具有十分重要的意义。不恰当的系统架构将给项目开发带来高昂的代价和难以避免的灾难。对一个系统架构进行评估，是为了：分析现有架构存在的潜在风险，检验设计中提出的质量需求，在系统被构建之前分析现有系统架构对于系统质量的影响，提出系统架构的改进方案。架构评估是软件开发过程中的重要环节。\n请围绕\u0026quot;论软件系统架构评估\u0026quot;论题，依次从以下三个方面进行论述。\n概要叙述你所参与的架构评估软件系统，以及在评估过程中所担任的主要工作。 分析软件系统架构评估中所普遍关注的质量属性有哪些？详细阐述每种质量属性的具体含义。 详细说明你所参与的软件系统架构评估中，采用了哪种评估方法，具体实施过程和效果如何。 论点提纲 摘要要点：\n项目背景：某 XX 系统（如银行核心系统），规模 XX 用户，团队 XX 人 采用方法：架构评估方法（ATAM/SAAM 等） 取得效果：发现 X 个风险点，解决 Y 个质量问题 正文结构（建议 2000-2500 字）：\n第 1 段（400 字）：项目背景与所担任工作 第 2 段（600 字）：架构评估普遍关注的质量属性（性能、可用性、安全性、可修改性） 第 3 段（600 字）：选用的评估方法（ATAM 推荐）实施过程 第 4 段（400 字）：评估结果与改进 关键术语与解析 架构所关注的质量属性主要包括：\n1）性能（Performance）：系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。\n2）可用性（Availability）：系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。\n3）安全性（Security）：系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性又可划分为机密性、完整性、不可否认性及可控性等特性。\n4）可修改性（Modifiability）：能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量可修改性。\n架构评估方法主要从 SAAM 与 ATAM 中选择：\n1）SAAM（Scenario-Based Architecture Analysis Method）评估方法：\n目的：验证基本的体系结构假设和原则，评估体系结构固有的风险 SAAM 指导对体系结构的检查，使其主要关注潜在的问题点，如需求冲突 评估参与者：风险承担者、记录人员、软件体系结构设计师 评估过程的 6 个步骤：形成场景 → 描述体系结构 → 场景的分类和优先级确定 → 间接场景的单个评估 → 场景相互作用的评估 → 总体评估 2）ATAM（Architecture Tradeoff Analysis Method）评估方法：\n即构架权衡分析方法，评估目的是依据系统质量属性和商业需求评估设计决策的结果 ATAM 希望揭示出构架满足特定质量目标的情况，使我们更清楚地认识到质量目标之间的联系 评估参与者： 评估小组（外部 3-5 人） 项目决策者（项目管理人员、客户代表、构架设计师等） 构架涉众（关键模块开发人员、测试人员、用户等） 评估过程 9 个步骤：描述 ATAM 方法 → 描述商业动机 → 描述体系结构 → 确定体系结构方法 → 生成质量属性效用树 → 分析体系结构方法 → 讨论和分级场景 → 描述评估结果 → …… 实战建议 选择 ATAM 方法叙述，更能展示系统性思维 必须包含质量属性效用树（Utility Tree）的构造过程 风险点、敏感点、权衡点、非风险点要区分清楚 论文题二：论软件架构的复用 题目要求 软件复用是系统化的软件开发过程，即开发一组基本的软件构件模块，以覆盖不同的需求/体系结构之间的相似性，提高系统开发的效率、质量和性能。软件架构复用可以减少开发工作、减少开发事件、降低开发成本、提高生产力、提高产品质量，有更好的互操作性。\n请围绕\u0026quot;论软件架构的复用\u0026quot;论题，依次从以下三个方面进行论述。\n概要叙述你参与分析和开发的软件系统，以及你在项目中所担任的主要工作。 阐述软件架构复用的基本过程。 详细说明你所参与的软件系统开发项目中，是如何进行软件复用工作的。 论点提纲 摘要要点：\n项目背景：某 XX 系统（如电商订单系统），规模 XX 模块，团队 XX 人 复用策略：构件库 + 领域框架 + 微服务化 取得效果：开发周期缩短 X%，代码复用率提升 Y% 正文结构（建议 2000-2500 字）：\n第 1 段（400 字）：项目背景 第 2 段（600 字）：软件架构复用的基本过程（构建/获取可复用资产、管理可复用资产、使用可复用资产） 第 3 段（600 字）：项目中的复用实践（构件库、检索方法、组装集成） 第 4 段（400 字）：复用效果与反思 关键术语与解析 软件架构复用的基本过程：\n（1）构建/获取可复用的软件资产（复用前提）：\n首先需要构造恰当的、可复用的资产 资产必须可靠、可被广泛使用、易于理解和修改 （2）管理可复用资产：\n用构件库对可复用的构件进行存储与管理 构件库应提供的主要功能：构件的存储、管理、检索、库的浏览与维护 支持使用者有效、准确地发现所需的可复用构件 构件库中的构件来源：\n从现有构件中获得符合要求的构件，直接使用或作适应性修改 通过遗留工程（Legacy Engineering），将具有潜在复用价值的构件提取出来 从市场上购买现成的商业构件 开发新的符合要求的构件 构件分类与检索的方法：\n关键字分类法 刻面分类法 超文本方法 （3）使用可复用资产：\n通过获取需求，检索复用资产库，获取可复用资产 定制这些可复用资产（修改、扩展、配置等） 最后将它们组装与集成，形成最终系统 实战建议 强调构件库的治理（结构化、文档化、版本管理） 阐述实际项目的复用数据（如复用率、节省工时） 可结合微服务架构讨论：每个微服务就是天然的可复用单元 论文题三：论分布式存储系统架构设计 题目要求 分布式存储系统（Distributed Storage System）通常将数据分散存储在多台独立的设备上。传统的网络存储系统采用集中的存储服务器存放所有数据，存储服务器成为系统性能的瓶颈，也是可靠性和安全性的焦点，不能满足大规模存储应用的需要。分布式存储系统采用可扩展的系统结构，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信息，它不但提高了系统的可靠性、可用性和存取效率，还易于扩展。\n请围绕\u0026quot;分布式存储系统架构设计\u0026quot;论题，依次从以下三个方面进行论述。\n概要叙述你参与分析和开发的分布式存储系统项目以及你所承担的主要工作。 简要说明在分布式存储系统架构设计中所使用的分布式存储技术及其实现机制，详细叙述你在具体项目中选用了哪种分布式存储技术，说明其原因和实施效果。 冗余是提高分布式存储系统可靠性的主要方法，通常在分布式存储系统设计中可采用哪些冗余技术来提升系统的可靠性？你在具体项目中选用了哪种冗余技术？说明其原因和实施效果。 论点提纲 摘要要点：\n项目背景：某 XX 存储系统（如对象存储/块存储/时序数据库），规模 XX TB 数据 采用技术：HDFS/Ceph/MongoDB 分片集群/Redis Cluster 取得效果：存储容量提升 X 倍，可用性达 Y 个 9 正文结构（建议 2000-2500 字）：\n第 1 段（400 字）：项目背景 第 2 段（700 字）：4 类分布式存储技术（集群/分布式文件系统/网络存储/P2P）对比 第 3 段（600 字）：项目中选用的具体技术（HDFS 居多）及原因 第 4 段（300 字）：冗余技术与可靠性效果 关键术语与解析 分布式存储技术主要包括 4 类：\n（1）集群存储技术：\n集群存储系统是指架构在一个可扩充服务器集群中的文件系统 用户不需要考虑文件是存储在集群中什么位置，仅需统一界面访问 负载增加时，只需在服务器集群中增加新的服务器就可提高性能 保留传统文件存储系统语义，向用户提供高可靠性、高性能、可扩充的文件存储服务 （2）分布式文件系统：\n文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连 基于客户机/服务器模式 分布式文件系统以透明方式链接文件服务器和共享文件夹，然后将其映射到单个层次结构 用户不必再转至网络上的多个位置以查找所需的信息 （3）网络存储技术：\n将\u0026quot;存储\u0026quot;和\u0026quot;网络\u0026quot;结合起来 通过网络连接各存储设备，实现存储设备之间、存储设备和服务器之间的数据在网络上的高性能传输 用户可以方便地使用浏览器等客户端进行访问和管理 （4）P2P 网络存储技术：\n内容不是存在几个主要的服务器上，而是存在所有用户的个人电脑上 可以将网络中的剩余存储空间利用起来，实现网络存储 P2P 技术的主体就是网络中的 Peer（各个客户机），数量很大，空闲存储空间多 冗余是提高分布式存储系统可靠性的主要方法。冗余的存储结构可以保证部分服务器失效时，数据服务仍可正常访问。\n常用的冗余技术：\n数据备份 数据分割 门限方案 纠错编码 纠删编码 考生可根据所参与的实际项目，指出采用了何种冗余技术，并说明其原因和实施效果。\n实战建议 HDFS + 三副本 是最常见的选择，Hadoop 生态是加分项 Ceph 适合需要统一存储（块/文件/对象）的场景 写入纠删码（如 Reed-Solomon）的成本 vs 三副本的成本对比 论文题四：论微服务架构及其应用 题目要求 近年来，随着互联网行业的迅猛发展，公司或组织业务的不断扩张，需求的快速变化以及用户量的不断增加，传统的单块（Monolithic）软件架构面临着越来越多的挑战，已逐渐无法适应互联网时代对软件的要求。在这一背景下，微服务架构模式（Microservice Architecture Pattern）逐渐流行，它强调将单一业务功能开发成微服务的形式，每个微服务运行在一个进程中；采用 HTTP 等通用协议和轻量级 API 实现微服务之间的协作与通信。这些微服务可以使用不同的开发语言以及不同的数据存储技术，能够通过自动化部署工具独立发布，并保持最低限制的集中式管理。\n请围绕\u0026quot;微服务架构及其应用\u0026quot;论题，依次从以下三个方面进行论述。\n概要叙述你参与管理和开发的、采用微服务架构的软件开发项目及在其中所担任的主要工作。 微服务架构有哪些优势与挑战？请列举并进行说明。 结合你参与管理和开发的软件开发项目，描述该软件的架构，说明该架构是如何采用微服务架构模式的，并说明在采用微服务架构后，在软件开发过程中遇到的实际问题和解决方案。 论点提纲 摘要要点：\n项目背景：某 XX 系统（如电商/金融/IoT 平台），XX 个微服务，XX QPS 拆分策略：按业务域/数据所有权拆分 取得效果：迭代速度提升 X 倍，故障隔离率 Y% 正文结构（建议 2000-2500 字）：\n第 1 段（400 字）：项目背景与担任工作 第 2 段（500 字）：微服务架构的 4 大优势 第 3 段（500 字）：微服务架构的 4 大挑战 第 4 段（600 字）：项目中实际架构图（按业务域拆分） 关键术语与解析 微服务的优势：\n通过分解巨大单体式应用为多个服务方法解决了复杂性问题。把庞大的单一模块应用分解为一系列的服务，同时保持总体功能不变，但整体并发却得到极大提升。\n让每个服务能够独立开发，开发者能够自由选择可行的技术，提供 API 服务。\n微服务架构模式是每个微服务独立的部署。开发者不再需要协调其他服务部署对本服务的影响。这种改变可以加快部署速度。\n微服务使得每个服务独立扩展。开发者可以根据每个服务的规模来部署满足需求的规模。甚至可以使用更适合于服务资源需求的硬件。\n微服务架构带来的挑战：\n并非所有的系统都能转成微服务。\n部署较以往架构更加复杂：系统由众多微服务搭建，每个微服务需要单独部署，从而增加部署的复杂度，容器技术能够解决这一问题。\n性能问题：由于微服务注重独立性，互相通信时只能通过标准接口，可能产生延迟或调用出错。\n数据一致性问题：作为分布式部署的微服务，在保持数据一致性方面需要比传统架构更加困难。\n实战建议 强调 API 网关（Spring Cloud Gateway / Kong / Zuul） 服务发现（Eureka / Nacos / Consul） 熔断限流（Sentinel / Hystrix） 分布式事务（Seata / 最终一致性方案） 链路追踪（SkyWalking / Zipkin） 容器化（Docker + K8s） ","date":"2024-01-01T00:00:00Z","permalink":"/p/29-mo-ni-shi-ti-i-xia-wu-lun-wen/","title":"29-模拟试题I下午论文"},{"content":"模拟试题II 上午基础知识 软考系统架构设计师 | 模拟题 II 形式：75 道单项选择题，每题 1 分，共 75 分 及格线：45 分 考试时间：150 分钟（与下午共用，建议上午 90 分钟做完）\n一、数据库与软件工程基础（约 22 道） 1. 数据库系统与文件系统的区别不包括 A. 对应用程序的高度独立性 B. 数据的充分共享性 C. 文件组织形式的多样化 D. 操作方便性 答案：C 解析：数据库按同一种数据结构存储数据；文件系统则需要不同的组织形式（顺序、索引等），故 C 不属于区别。\n2. ______ 描述的是 DBMS 向用户提供数据操纵语言，实现对数据库中数据的基本操作，如检索、插入、修改和删除 A. 数据定义 B. 数据库操作 C. 数据库运行管理 D. 数据组织、存储与管理 答案：B 解析：DBMS 功能：数据定义、数据库操作、数据库运行管理、数据组织存储管理、数据库建立维护。\n3. 给定关系模式 R(U,F)，U={A1,A2,A3,A4,A5,A6}，F={A1→A2, A1→A3, A3→A4, A1A5→A6}，R 的候选码为 A. A1A3 B. A1A4 C. A1A5 D. A1A6 答案：C 解析：A1 和 A5 都只在 F 中\u0026quot;→\u0026ldquo;左边出现过，所以候选码为 A1A5。\n4. 由于 R 存在非主属性对码的部分函数依赖，所以 R 属于 A. 1NF B. 2NF C. 3NF D. BCNF 答案：A 解析：存在非主属性对码的部分函数依赖不满足 2NF，只满足 1NF。\n5. 下列选项 ______ 不是关于 SOA 的服务架构 A. 业务逻辑服务 B. 中间件服务 C. 连接服务 D. 控制服务 答案：B 解析：SOA 参考架构：业务逻辑服务、控制服务、连接服务、业务创新和优化服务、开发服务、IT 服务管理。\n6. WSDL 描述了 Web 服务的三个基本属性：服务做些什么、如何访问服务、服务位于何处。下列选项对应正确 A. abc（a 服务做些什么、b 如何访问服务、c 服务位于何处） B. acd C. bcd D. abd 答案：A 解析：WSDL 3 属性：服务做些什么（操作）、如何访问服务（数据格式/协议）、服务位于何处（URL）。\n7. SOA 的设计原则为无状态、单一实例、明确定义的接口、______、粗粒度、服务之间的松耦合性、重用能力、互操作性 A. 复用性和构件化 B. 自包含和模块化 C. 独立性和构件化 D. 隔离性和归一化 答案：B 解析：SOA 8 大设计原则含\u0026quot;自包含和模块化\u0026rdquo;。\n8. 微服务架构中，每个服务可以 A. 独立进行开发、管理、迭代 B. 独立进行部署、运维、升级 C. 独立进行测试、交付、验收 D. 独立进行发布、发现、访问 答案：A 解析：微服务可独立进行开发、管理、迭代。\n9. 在软件系统的生命周期里，软件的演化速率趋于稳定，如相邻版本的更新率相对稳定。此描述是软件架构演化的 ______ 原则 A. 主体维持原则 B. 系统总体结构优化原则 C. 平滑演化原则 D. 目标一致原则 答案：C 解析：平滑演化原则：软件的演化速率趋于稳定。\n10. 软件架构维护过程不包括 A. 架构知识管理 B. 架构修改管理 C. 架构版本管理 D. 架构构件管理 答案：D 解析：架构维护过程：知识管理、修改管理、版本管理。\n11. 下列软件架构演化时期，______ 是在系统设计时规定了演化的具体条件，将系统置于\u0026quot;安全\u0026quot;模式下 A. 设计时演化 B. 运行前演化 C. 有限制运行时演化 D. 运行时演化 答案：C 解析：有限制运行时演化：只发生在特定约束满足时。\n12. 根据所修改的内容不同，软件的动态演化不包括 A. 属性改名 B. 行为变化 C. 拓扑结构改变 D. 格式变化 答案：D 解析：动态演化内容：属性改名、行为变化、拓扑结构改变、风格变化。格式变化不是。\n13. 采用检错设计技术要着重考虑 4 个要素：检测对象、______、实现方法和处理方式 A. 检测延时 B. 测试结果 C. 性能测试 D. 功能测试 答案：A 解析：检错设计 4 要素：检测对象、检测延时、实现方法、处理方式。\n14. ______ 是通常所说的 Active/Standby 方式，Active 服务器处于工作状态，Standby 服务器处于监控准备状态，服务器数据包括数据库数据同时往两台或多台服务器写入，保证数据的即时同步 A. 双机热备 B. 双机互备 C. 双机双工 D. 服务器集群 答案：A 解析：Active/Standby 即双机热备。\n15. \u0026ldquo;改变业务数据编码方式会对系统的性能和安全性产生影响\u0026quot;是对 ______ 的描述 A. 风险 B. 非风险 C. 敏感点 D. 权衡点 答案：D 解析：影响多个质量属性（性能+安全性）的特性是权衡点。\n16. \u0026ldquo;假设用户请求的频率为每秒 1 个，业务处理时间小于 30 毫秒，则将请求响应时间设定为 1 秒钟是可以接受的\u0026quot;是对 ______ 的描述 A. 风险 B. 非风险 C. 敏感点 D. 权衡点 答案：B 解析：良好的架构设计决策 = 非风险。\n17. DSSA 特定领域软件架构包括 ______ 环境、领域特定应用开发环境和应用执行环境 A. 领域需求 B. 领域开发 C. 领域执行 D. 领域应用 答案：B 解析：DSSA 3 层次：领域开发环境、领域特定应用开发环境、应用执行环境。\n18. DSSA 中，______ 主要在领域特定应用开发环境中工作 A. 操作员 B. 领域架构师 C. 应用工程师 D. 程序员 答案：C 解析：应用工程师在领域特定应用开发环境中工作。\n19. 某公司拟开发一个 VIP 管理系统，系统需要根据不同的商场活动，不定期更新 VIP 会员的审核标准和 VIP 折扣标准。针对上述需求，采用 ______ 架构风格最为合适 A. 规则系统 B. 过程控制 C. 分层 D. 管道-过滤器 答案：A 解析：规则经常变 → 规则系统风格。\n20. 以下叙述中，______ 不是软件架构的主要作用 A. 在设计变更相对容易的阶段，考虑系统结构的可选方案 B. 便于技术人员与非技术人员就软件设计进行交互 C. 展现软件的结构、属性与内部交互关系 D. 表达系统是否满足用户的功能性需求 答案：D 解析：软件架构与用户对系统的功能性需求没有直接的对应关系。\n21. 软件架构风格描述某一特定领域中的系统组织方式和惯用模式，反映了领域中众多系统所共有的 ______ 特征 A. 语法和语义 B. 结构和语义 C. 静态和动态 D. 行为和约束 答案：B 解析：体系结构风格反映众多系统所共有的结构和语义特性。\n22. 对于语音识别、知识推理等问题复杂、解空间很大、求解过程不确定的这一类软件系统，通常会采用 ______ 架构风格 A. 管道-过滤器 B. 解释器 C. 黑板 D. 过程控制 答案：C 解析：语音识别是黑板风格的经典应用场景。\n23. 对于因数据输入某个构件，经过内部处理，产生数据输出的系统，通常会采用 ______ 架构风格 A. 事件驱动系统 B. 黑板 C. 管道-过滤器 D. 分层系统 答案：C 解析：数据输入 + 内部处理 + 数据输出 = 管道-过滤器。\n二、信息安全与系统（约 12 道） 24. 事务必须服从 ISO/IEC 所制定的 ACID 原则。关于 ACID 以下说法有错误的是 A. 事务的原子性表示事务执行过程中的任何失败都将导致事务所做的任何修改失效 B. 一致性表示当事务执行失败时，所有被该事务影响的数据都应该恢复到事务执行前的状态 C. 隔离性表示在事务执行过程中对数据的修改，在事务提交之后对其他事务不可见 D. 持久性表示已提交的数据在事务执行失败时，数据的状态都应该正确 答案：C 解析：隔离性表示在事务执行过程中对数据的修改，在事务提交之\u0026rdquo;前\u0026ldquo;对其他事务不可见。\n25. 物联网的感知层用于识别物体、采集信息。下列 ______ 不属于感知层设备 A. 摄像头 B. GPS C. 扫描仪 D. 指纹 答案：D 解析：指纹是人的特征属性，不是感知层设备。\n26. 软件著作权的保护对象不包括 A. 源程序 B. 目标程序 C. 软件文档 D. 软件开发思想 答案：D 解析：著作权法只保护作品的表达，不保护作品的思想、原理、概念、方法、公式、算法等。\n27. 以下关于软件著作权产生时间的叙述中，正确的是 A. 软件著作权产生自软件首次公开发表时 B. 软件著作权产生自开发者有开发意图时 C. 软件著作权产生自软件开发完成之日起 D. 软件著作权产生自软件著作权登记时 答案：C 解析：《计算机软件保护条例》第十四条：软件著作权自软件开发完成之日起产生。\n28. 无服务器技术的特点之一是全托管的计算服务：客户只需要编写代码构建应用，无须关注同质化的、负担繁重的基于服务器等基础设施的 ______ 等工作 A. 开发、测试、发布、交付 B. 开发、运维、安全、高可用 C. 机房建设、服务器装机、操作系统安装、软件安装 D. 资源调度、性能压测、负载均衡、数据统计 答案：B 解析：无服务器全托管让客户无须关注开发、运维、安全、高可用等基础设施工作。\n29. 容器作为标准化软件单元，它将应用及其所有依赖项打包，使应用不再受 ______ 限制，在不同计算环境间快速、可靠地运行 A. 环境 B. 操作系统 C. 硬件 D. 网络 答案：A 解析：容器解决的是跨环境一致性问题。\n30. 假设员工关系 EMP（员工号,姓名,性别,部门,部门电话,部门负责人,家庭住址,家庭成员,成员关系），如果一个部门只能有一部电话和一位负责人，一个员工可以有多个家庭成员，那么关系 EMP 属于 ______ A. 1NF B. 2NF C. 3NF D. BCNF 答案：A 解析：主键是（员工号,家庭成员），部门名等非主属性对其存在部分依赖，不符合 2NF。\n31. EMP 存在 ______ 问题 A. 无冗余、无插入异常和删除异常 B. 无冗余，但存在插入异常和删除异常 C. 存在冗余，但不存在修改操作的不一致 D. 存在冗余、修改操作的不一致，以及插入异常和删除异常 答案：D 解析：1NF 关系通常存在冗余、不一致、插入/删除异常。\n32. 为了解决 EMP 的问题，应该将员工关系 EMP 分解为 A. EMP1（员工号,姓名,性别,家庭住址）、EMP2（部门,部门电话,部门负责人）、EMP3（员工号,家庭成员,成员关系） B. EMP1（员工号,姓名,性别,部门,家庭住址）、EMP2（部门,部门电话,部门负责人）、EMP3（员工号,家庭成员,成员关系） C. EMP1（员工号,姓名,性别,家庭住址）、EMP2（部门,部门电话,部门负责人,家庭成员,成员关系） D. EMP1（员工号,姓名,性别,部门,部门电话,部门负责人,家庭住址）、EMP2（员工号,家庭住址,家庭成员,成员关系） 答案：B 解析：B 选项既具有无损连接性，又保持了函数依赖。\n33. 螺旋模型在 ______ 的基础上扩展而成 A. 瀑布模型 B. 原型模型 C. 快速模型 D. 面向对象模型 答案：B 解析：螺旋模型基于原型模型扩展。\n34. 关于微服务的描述，错误的是 A. 微服务是将后端单体应用拆分为松耦合的多个子应用，每个子应用负责一组子功能 B. 微服务相对独立，通过解耦研发、测试与部署流程，提高整体迭代效率 C. 微服务与数据层之间的纵向约束的含义是：在合理划分好微服务间的边界后，主要从微服务的可发现性和可交互性处理服务间的关系 D. 驾驭微服务的前提是：高效运维整个系统，从技术上要准备全自动化的 CI/CD 流水线 答案：C 解析：C 描述的是微服务之间的横向关系而非纵向约束；正确的纵向约束是：对于微服务的私有数据的访问都必须通过当前微服务提供的 API 来进行。\n35. 下列关于云原生架构原则的选项，有错误的是 A. 服务化原则、弹性原则、韧性原则 B. 可观测原则、所有过程自动化原则 C. 零信任原则、接口隔离原则 D. 架构持续演进原则 答案：C 解析：接口隔离原则是面向对象设计原则，不是云原生架构原则。\n36. 云计算无法为企业带来的改进是 A. 通过 DevSecOps 应用开发模式，业务功能开发更加敏捷 B. 企业软件架构可以获得强大的可伸缩性和高可用性 C. 结合云平台全方位企业级安全服务，保障企业应用在云上安全构建 D. 企业的开发人员只需关注业务代码部分的开发，非业务功能可以完全委托给云原生架构来解决 答案：D 解析：云原生架构旨在将非业务代码部分进行最大化的剥离，但无法接管所有的非功能特性。\n37. 在软件需求工程中，需求管理最基本的任务是明确需求，并使项目团队和用户达成共识，即建立 A. 需求跟踪说明 B. 需求变更管理文档 C. 需求分析计划 D. 需求基线 答案：D 解析：需求管理最基本任务是建立需求基线。\n38. 某服务器软件系统能够正确运行并得出计算结果，但存在\u0026quot;系统出错后不能在要求的时间内恢复到正常状态\u0026quot;和\u0026quot;对系统进行二次开发时总要超过半年的时间\u0026quot;两个问题，上述问题依次与质量属性中的 ______ 相关 A. 可用性和性能 B. 性能和可修改性 C. 性能和可测试性 D. 可用性和可修改性 答案：D 解析：错误恢复属可用性；二次开发周期长属可修改性。\n三、计算机系统与硬件（约 7 道） 39. 在 Cache—主存层次结构中，主存单元到 Cache 单元的地址转换由 ______ 完成 A. 硬件 B. 寻址方式 C. 软件和少量的辅助硬件 D. 微程序 答案：A 解析：为提高地址转换速度，主存单元到 Cache 单元的地址转换采用硬件完成。\n40. 如果要清除上网痕迹，必须 A. 禁用 ActiveX 控件 B. 查杀病毒 C. 清除 Cookie D. 禁用脚本 答案：C 解析：Cookie 保留上网痕迹，清除 Cookie 可清除上网痕迹。\n41. 下列关于交换机的说法中，正确的是 A. 以太网交换机可以连接运行不同网络层协议的网络 B. 从工作原理上讲，以太网交换机是一种多端口网桥 C. 集线器是一种特殊的交换机 D. 通过交换机连接的一组工作站形成一个冲突域 答案：B 解析：以太网交换机本质是多端口网桥（工作在二层）；集线器没有数据交换功能；交换机各端口是独立冲突域。\n42. 以下关于 CISC 和 RISC 的叙述中，错误的是 A. 在 CISC 中，复杂指令都采用硬布线逻辑来执行 B. 一般而言，采用 CISC 技术的 CPU，其芯片设计复杂度更高 C. 在 RISC 中，更适合采用硬布线逻辑执行指令 D. 采用 RISC 技术，指令系统中的指令种类和寻址方式更少 答案：A 解析：CISC 复杂指令采用微程序技术解释执行，不是硬布线逻辑。\n43. 基于 SOA 和 Web Services 技术的企业应用集成（EAI）模式是 A. 面向信息的集成技术 B. 面向过程的集成技术 C. 面向计划的集成技术 D. 面向服务的集成技术 答案：D 解析：SOA + Web Services 是面向服务的应用集成。\n44. ______ 是互联网时代信息基础设施与应用服务模式的重要形态，是新一代信息技术集约化发展的必然趋势 A. 物联网 B. 云计算 C. 智慧城市 D. 商业智能 答案：B 解析：云计算定义。\n四、UI 与设计（约 4 道） 45. 用户界面设计的\u0026quot;黄金规则\u0026quot;不包含 A. 为用户提供更多的信息和功能 B. 减少用户的记忆负担 C. 保持界面一致性 D. 置用户于控制之下 答案：A 解析：Theo Mandel 3 条\u0026quot;黄金规则\u0026rdquo;：①置用户于控制之下；②减少用户的记忆负担；③保持界面一致性。\n46. 软件架构需求过程中标识构件范畴不包括 A. 生成类图 B. 对类图进行分组 C. 对类图进行测试 D. 将类合并打包 答案：C 解析：标识构件包括：生成类图 → 对类图分组 → 将类合并打包成构件。\n47. 下列协议中，属于安全远程登录协议的是 A. TLS B. TCP C. SSH D. TFTP 答案：C 解析：SSH 是安全远程登录协议。\n48. 通常可以将计算机系统中执行一条指令的过程分为取指令、分析和执行指令 3 步。若取指令时间为 4Δt，分析时间为 2Δt，执行时间为 3Δt，按顺序方式从头到尾执行完 600 条指令所需时间为 ______ Δt A. 2400 B. 3000 C. 3600 D. 5400 答案：D 解析：每条指令 9Δt × 600 = 5400Δt。\n49. 若按照执行第 i 条，分析第 i+1 条，读取第 i+2 条重叠的流水线方式执行指令，则从头到尾执行完 600 条指令所需时间为 ______ Δt A. 2400 B. 2405 C. 3000 D. 3009 答案：B 解析：流水线 4Δt×600 + 2Δt + 3Δt = 2405Δt。\n50. 软件开发团队欲开发一套管理信息系统，在项目初期，用户提出了软件的一些基本功能，但是没有详细定义输入、处理和输出需求。该团队在开发过程应采用 A. 瀑布模型 B. 增量模型 C. 原型开发模型 D. 快速应用程序开发（RAD） 答案：C 解析：用户仅提出基本功能、需求不明确时适合原型开发模型。\n51. 在客户关系管理（CRM）中，管理的对象是客户与企业之间的双向关系，那么在开发过程中，______ 是开发的主要目标 A. 客户关系的生命周期管理 B. 客户有关系的培育和维护 C. 最大程度地帮助企业实现其经营目标 D. 为客户扮演积极的角色，树立企业形象 答案：C 解析：CRM 实施要求企业对其业务功能进行重新设计，将业务中心转移到客户，帮助企业提高获取利润的能力。\n52. 某服务器软件系统能够正确运行并得出计算结果，但存在\u0026quot;系统出错后不能在要求的时间内恢复到正常状态\u0026quot;和\u0026quot;对系统进行二次开发时总要超过半年的时间\u0026quot;两个问题，上述问题依次与质量属性中的 ______ 相关 A. 可用性和性能 B. 性能和可修改性 C. 性能和可测试性 D. 可用性和可修改性 答案：D 解析：错误恢复属可用性；二次开发周期长属可修改性。\n53. 管道-过滤器模式属于 A. 数据为中心的体系结构 B. 数据流体系结构 C. 调用和返回体系结构 D. 层次式体系结构 答案：B 解析：管道-过滤器是数据流体系结构。\n54. CPU 中的数据总线宽度会影响 A. 内存容量的大小 B. 系统的运算速度 C. 指令系统的指令数量 D. 寄存器的宽度 答案：B 解析：数据总线宽度越大，单位时间内能进出 CPU 的数据就越多，系统的运算速度越快。\n55. ______ 是一种信息分析工具，能自动地找出数据仓库中的模式及关系 A. 数据集市 B. 数据挖掘 C. 预测分析 D. 数据统计 答案：B 解析：数据挖掘 = 自动找出数据仓库中的模式及关系。\n五、设计模式（约 3 道） 56. 某公司欲开发一套窗体图形界面类库。该类库需要包含若干预定义的窗格（Pane）对象，例如 TextPane、ListPane 等，窗格之间不允许直接引用。基于该类库的应用由一个包含一组窗格的窗口组成，并需要协调窗格之间的行为。基于该类库，在不引用窗格的前提下实现窗格之间的协作，应用开发者应采用 ______ 最为合适 A. 备忘录模式 B. 中介者模式 C. 访问者模式 D. 迭代器模式 答案：B 解析：中介者模式用一个中介对象封装一系列对象交互，使其耦合松散。\n六、网络与嵌入式（约 4 道） 57. 网络故障需按照协议层次进行分层诊断，找出故障原因并进行相应处理。查看端口状态、协议建立状态和 EIA 状态属于 ______ 诊断 A. 物理层 B. 数据链路层 C. 网络层 D. 应用层 答案：A 解析：物理层通过 show interface 命令查看端口状态、协议建立状态、EIA 状态。\n58. 假设磁盘块与缓冲区大小相同，每个盘块读入缓冲区的时间为 16μs，由缓冲区送至用户区的时间是 5μs，在用户区内系统对每块数据的处理时间为 1μs。若用户需要将大小为 10 个磁盘块的 Doc1 文件逐块从磁盘读入缓冲区，并送至用户区进行处理，那么采用单缓冲区需要花费的时间为 ______ μs A. 160 B. 161 C. 166 D. 211 答案：D 解析：单缓冲区：16+5+1+(10-1)×(16+5) = 211μs。\n59. 采用双缓冲区需要花费的时间为 ______ μs A. 160 B. 161 C. 166 D. 211 答案：C 解析：双缓冲区：16+5+1+(10-1)×16 = 166μs。\n60. 网络系统设计过程中，逻辑网络设计阶段的任务是 A. 依据逻辑网络设计的要求，确定设备的物理分布和运行环境 B. 分析现有网络和新网络的资源分布，掌握网络的运行状态 C. 根据用户需求，描述网络行为和性能 D. 理解网络应该具有的功能和性能，设计出符合用户需求的网络 答案：C 解析：逻辑网络设计阶段需要描述满足用户需求的网络行为以及性能，此阶段不涉及网络元素的具体物理位置。\n61. 嵌入式系统中采用中断方式实现输入/输出的主要原因是 A. 速度最快 B. CPU 不参与操作 C. 实现起来比较容易 D. 能对突发事件做出快速响应 答案：D 解析：中断方式能对突发事件做出快速响应。\n62. 在中断时，CPU 断点信息一般保存到 ______ 中 A. 通用寄存器 B. 堆 C. 栈 D. I/O 接口 答案：C 解析：CPU 断点信息保存到栈中。\n七、项目管理与成本（约 4 道） 63. 成本按成本性态分类，可以分为固定成本、变动成本和混合成本。其中 ______ 属于固定成本 A. 固定资产折旧费 B. 直接材料费 C. 产品包装费 D. 开发奖金 答案：A 解析：固定资产折旧费是典型的固定成本。\n64. ______ 属于变动成本 A. 员工培训费 B. 房屋租金 C. 技术开发经费 D. 外包费用 答案：D 解析：外包费用随业务量变动而变动。\n八、软件过程与面向对象（约 4 道） 65. 软件过程主要包括 A. 软件描述、软件开发和软件测试 B. 软件开发、软件有效性验证和软件测试 C. 软件描述、软件设计、软件实现和软件测试 D. 软件描述、软件开发、软件有效性验证和软件进化 答案：D 解析：软件活动 4 类：软件描述、软件开发、软件有效性验证、软件进化。\n66. ______ 的活动之间存在因果关系，前一阶段工作的结果是后一段阶段工作的输入描述 A. 瀑布模型 B. 原型模式 C. 螺旋模型 D. 基于构建的模型 答案：A 解析：瀑布模型的特点是因果关系紧密相连，前一阶段的结果是后一阶段的输入。\n67. 面向对象的分析模型主要由顶层架构图、用例与用例图和 ______ 构成 A. 数据流模型 B. 领域概念模型 C. 功能分解图 D. 功能需求模型 答案：B 解析：OOA 模型 = 顶层架构图 + 用例与用例图 + 领域概念模型。\n68. 设计模型则包含以 ______ 表示的软件体系结构图 A. 模型视图控制器 B. 组件图 C. 包图 D. 2 层、3 层或 N 层 答案：C 解析：设计模型用包图表示软件体系结构图。\n69. 设计模型还包含描述复杂对象的 ______ A. 序列图 B. 协作图 C. 流程图 D. 状态图 答案：D 解析：描述复杂对象用状态图。\n九、运筹学（约 1 道） 70. 载重量限 24 吨的某架货运飞机执行将一批金属原料运往某地的任务。经优化安排，该飞机本次运输可以获得的最大利润为 ______ 元 A. 11000 B. 10000 C. 9000 D. 8000 答案：B 解析：按利润重量比优先原则，装运 4、6、1 箱，总利润 4000+3000+3000=10000 元。\n十、英语（约 5 道） 71. System analysis is traditionally done top-down using structured analysis based on ______ A. functional decomposition B. object abstraction C. data inheritance D. information generalization 答案：A 解析：结构化分析基于功能分解自顶向下。\n72. Object-oriented analysis focuses on creation of models. The three types of the analysis model are ______ A. function model, class model and state model B. class model, interaction model and state model C. class model, interaction model and sequence model D. function model, interaction model and state model 答案：B 解析：OOA 三种模型：类模型、交互模型、状态模型。\n73. There are two substages of object-oriented analysis. ______ focuses on real-world things whose semantics the application captures A. Static analysis B. Semantic analysis C. Scope analysis D. Domain analysis 答案：D 解析：领域分析（Domain analysis）关注现实世界被应用捕获语义的事物。\n74. The object constructed in the requirement analysis shows the ______ of the real-world system and organizes it into workable pieces A. static structure B. system components C. data flows D. program procedures 答案：A 解析：对象构造展示了现实世界系统的静态结构。\n75. ______ addresses the computer aspects of the application that are visible to users. The objects are those which can be expected to vary from time to time quite rapidly A. Program analysis B. Function requirement C. Application analysis D. Physical model 答案：C 解析：应用分析处理用户可见的计算机问题。\n参考答案速查 题号 1 2 3 4 5 6 7 8 9 10 答案 C B C A B A B A C D 题号 11 12 13 14 15 16 17 18 19 20 答案 C D A A D B B C A D 题号 21 22 23 24 25 26 27 28 29 30 答案 B C C C D D C B A A 题号 31 32 33 34 35 36 37 38 39 40 答案 D B B C C D D D A C 题号 41 42 43 44 45 46 47 48 49 50 答案 B A D B A C C D B C 题号 51 52 53 54 55 56 57 58 59 60 答案 C D B B B B A D C C 题号 61 62 63 64 65 66 67 68 69 70 答案 D C A D D A B C D B 题号 71 72 73 74 75 答案 A B D A C ","date":"2024-01-01T00:00:00Z","permalink":"/p/30-mo-ni-shi-ti-ii-shang-wu-ji-chu-zhi-shi/","title":"30-模拟试题II上午基础知识"},{"content":"模拟试题II 下午案例分析 软考系统架构设计师 | 模拟题 II 案例 形式：5 道案例题，每题 25 分，共 75 分 及格线：45 分 考试时间：与上午共用 150 分钟 必答：5 道全答（无选答）\n试题一：C/S 与 B/S 混合架构 + 数据中心设计（25 分） 背景 某大中型企业在全国各城市共有 15 个左右的分支机构，这些机构已经建设了关系型数据库管理系统，每天负责独立地处理本区域内的业务并实时存储业务数据。PH 软件公司承接了该大中型企业信息管理系统的升级改造开发任务。\n部分系统需求：\n开发一个网络财务程序，使各地员工能在 Internet 上通过 VPN 技术进行财务单据报销和处理 加强管理，实现对下属分支机构业务数据的异地存储备份，保证数据的安全及恢复，同时对全国业务数据进行挖掘分析，拟在该企业总部建设数据中心 方案对比：\n角色 架构风格 关键特征 许工 C/S 各分支机构财务部安装软件客户端，连接到总公司财务部主机；外地出差员工也需装客户端 郭工 B/S 各分支机构及出差员工通过 Windows 自带 IE 浏览器连接到总公司财务部主机 最终专家采用 C/S 和 B/S 相结合的混合架构。\n问题 1（8 分） 结合你的系统架构经验，请用 400 字以内的文字简要讨论 C/S 和 B/S 两种架构风格各自的优点和缺点。\n参考答案：\nC/S 架构风格的优点：\n客户机应用程序与服务器程序分离，二者的开发既可以分开进行，也可以同时进行 技术成熟，允许网络分布操作，交互性强，具有安全的存取模式 网络压力小，响应速度快，有利于处理大量数据 模型思想简单，易于人们理解和接受 C/S 架构风格的缺点：\n客户机与服务器的通信依赖于网络，服务器的负荷过重 无法实现快速部署和安装，维护工作量大，升级困难 开发成本较高，客户端程序设计复杂，灵活性差 用户界面风格不一，软件移植和数据集成困难 数据库的安全性因客户机程序直接访问而降低 B/S 架构风格的优点：\n易于部署、维护和升级 具有良好的开放性和可扩充性，可应用在广域网，方便信息的全球传输、查询和发布 可跨平台操作，无须开发客户端软件 通过 JDBC 等数据库连接接口，提高了动态交互性、服务器的通用性与可移植性 B/S 架构风格的缺点：\n数据的动态交互性不强，不利于 OLTP 应用 数据查询等响应速度较慢 系统的安全性较难以控制 问题 2（8 分） 结合你的系统架构经验，请用 600 字以内的文字简要说明该工程项目采用 C/S 和 B/S 相结合的混合架构风格的设计要点及其优点。\n参考答案：\n设计要点：\n在该企业总部局域网上部署财务 Web 服务器及其相关的数据库服务器，两种服务器之间采用 C/S 架构 总部局域网上提供 C/S 和 B/S 两种并存的架构风格，根据不同的应用需求和客户需求进行灵活选择 若项目资金充裕，可在各分支机构局域网中也采用类似于企业总部的部署风格；若资金不足，则在各分支机构财务部门局域网中采 C/S 架构，部署应用服务器及相关的数据库服务器，然后将集中处理的后期财务数据通过 VPN 技术上传至总部局域网的相应服务器中 外出差的员工和各分支机构的普通员工可通过 VPN 技术访问企业总部局域网上的 Web 服务器，查看相关的信息 C/S 和 B/S 混合架构的优点：\n充分发挥了 B/S 与 C/S 体系结构的优势，弥补了二者的不足 客户请求和信息发布采用 B/S 架构，保持了瘦客户端的优点，客户机只利用浏览器即可完成所有的应用需求 数据库的请求和响应操作采用 C/S 架构，通过在 Web 应用程序和数据库之间建立 ODBC/JDBC 连接来完成数据库的连接和请求响应，能完成大量数据的批量录入请求 系统的部署、维护及数据更新方便，不存在完全采用 C/S 结构带来的客户端维护工作量大等缺点 将服务器端划分为 Web 服务器和 Web 应用程序两部分。Web 应用程序采用组件技术实现三层体系结构中的商业逻辑部分，达到封装源代码、保护知识产权的目的 对原基于 C/S 架构的应用，只需开发用于发布的 Web 界面，就能升级到这种混合架构系统中，从而最大限度地保护了原有投资 问题 3（9 分） 为保证各分支机构可靠、高效地向数据中心汇总业务数据，避免单点故障，对该企业总部数据中心架构进行设计时，应该采用哪些相关的技术？\n参考答案（包含但不限于以下内容）：\n采用双链路连接 Internet 的备份方式 对数据中心的数据库服务器采用双机冗余热备方式（或多机集群 Cluster 和数据库并行处理技术等） 对存储设备采用 RAID10 级别（或全冗余的 SAN 结构，或全冗余的存储结构）等 试题二：基于边缘计算的智能门禁系统（25 分） 背景 某公司拟开发基于边缘计算的智能门禁系统，用于园区、新零售、工业现场等存在来访、被访业务的场景：\n来访者在线提前预约，将个人信息记录在后台 被访者在系统中通过请求 来访者到访时\u0026quot;刷脸\u0026quot;通过门禁，无须其他验证 系统管理员可对正在运行的门禁设备进行管理 项目组讨论：\n张工（业务）：本系统可由访客注册模块、模型训练模块、端侧识别模块与设备调度平台模块等 4 项功能组成 李工（技术）：使用 Flask 框架与 SSM 框架为基础来开发后台服务器，将开发好的系统通过 Docker 进行部署，并使用 MQTT 协议对 Docker 进行管理 问题 1（8 分） 请简述边缘计算的特点有哪些。\n参考答案：\n连接性：所连接物理对象的多样性及应用场景的多样性，需要边缘计算具备丰富的连接功能，如各种网络接口、网络协议等。\n数据第一入口：边缘计算拥有大量、实时、完整的数据，可基于数据全生命周期进行管理与价值创造，将更好地支撑预测性维护、资产效率与管理等创新应用。\n约束性：边缘计算产品需适配工业现场相对恶劣的工作条件与运行环境。在工业互联场景下，对边缘计算设备的功耗、成本、空间也有较高的要求。边缘计算产品需要考虑通过软硬件集成与优化，以适配各种条件约束，支撑行业数字化多样性场景。\n分布性：边缘计算实际部署天然具备分布式特征。这要求边缘计算支持分布式计算与存储、实现分布式资源的动态调度与统一管理、支撑分布式智能、具备分布式安全等能力。\n问题 2（5 分） 边缘计算与云计算的区别与联系是什么？\n参考答案：\n区别：\n云计算擅长全局性、非实时、长周期的大数据处理与分析，能够在长周期维护、业务决策支撑等领域发挥优势 边缘计算更适用局部性、实时、短周期数据的处理与分析，能更好地支撑本地业务的实时智能化决策与执行 联系：\n边缘计算与云计算之间不是替代关系，而是互补协同关系，边云协同将放大边缘计算与云计算的应用价值 边缘计算既靠近执行单元，也是云端所需高价值数据的采集和初步处理单元，可以更好地支撑云端应用 反之，云计算通过大数据分析优化输出的业务规则或模型可以下发到边缘侧，边缘计算基于新的业务规则或模型运行 问题 3（12 分） 简述边缘计算与云计算的协同能力有哪些。\n参考答案：\n资源协同：边缘节点提供计算、存储、网络、虚拟化等基础设施资源、具有本地资源调度管理能力，同时可与云端协同，接受并执行云端资源调度管理策略，包括边缘节点的设备管理、资源管理以及网络连接管理。\n数据协同：边缘节点主要负责现场/终端数据的采集，按照规则或数据模型对数据进行初步处理与分析，并将处理结果以及相关数据上传给云端；云端提供海量数据的存储、分析与价值挖掘。边缘与云的数据协同，支持数据在边缘与云之间可控地有序流动，形成完整的数据流转路径，高效低成本地对数据进行生命周期管理与价值挖掘。\n智能协同：边缘节点执行推理，实现分布式智能；云端开展模型训练，并将模型下发边缘节点。\n应用管理协同：边缘节点提供应用部署与运行环境，并对本节点多个应用的生命周期进行管理调度；云端主要提供应用开发、测试环境，以及应用的生命周期管理能力。\n业务管理协同：边缘节点提供模块化、微服务化的应用/数字孪生/网络等应用实例；云端主要提供按照客户需求实现应用/数字孪生/网络等的业务编排能力。\n服务协同：边缘节点按照云端策略实现部分 ECSaaS 服务，通过 ECSaaS 与云端 SaaS 的协同实现面向客户的按需 SaaS 服务；云端主要提供 SaaS 服务在云端和边缘节点的服务分布策略，以及云端承担的 SaaS 服务能力。\n试题三：宇航嵌入式设备软件架构（TLS 三层栈）（25 分） 背景 某公司承担了一项宇航嵌入式设备的研制任务。本项目除对硬件设备环境有很高要求外，还要求支持以下功能：\n设备由多个处理机模块组成，需要时外场可快速更换（即 LRM 结构） 应用软件应与硬件无关，便于软硬件的升级 由于宇航嵌入式设备中要支持不同功能，系统应支持完成不同功能任务间的数据隔离 宇航设备可靠性要求高，系统要有故障处理能力 公司接到任务后进行反复论证，提出三层栈（TLS）软件总体架构（图 3.1），并将软件设计工作交给李工。\n问题 1（8 分） 用 150 字以内的文字，说明公司制订的 TLS 软件架构的层次特点，并针对上述功能需求（1）~（4），说明架构中各层的内涵。\n参考答案：\nTLS 结构框架的主要特点：\n应用软件仅与操作系统服务相关，不直接操作硬件 操作系统通过模块支持原软件访问硬件，可与具体硬件无关 模块支持层将硬件抽象成标准操作 通过三层栈的划分可实现硬件的快速更改与升级，应用软件的升级不会引起硬件的变更 TLS 结构框架各层的内涵：\n应用层：主要完成宇航设备的具体工作，由多个功能任务组成，各功能任务间的隔离由操作系统层实现 操作系统层：实现应用软件与硬件的隔离，为应用软件提供更加丰富的计算机资源服务。操作系统为应用软件提供标准的 API 接口（如 POSIX），确保了应用软件的可升级性 模块支持层：为操作系统管理硬件资源提供统一的管理方法，用一种抽象的标准接口实现软件与硬件的无关性，达到硬件的升级要求，便于硬件的外场快速更换 问题 2（10 分） 在 TLS 软件架构的基础上，关于选择哪种类型的嵌入式操作系统问题，李工与总工程师发生了严重分歧。\n李工：宇航系统是实时系统，操作系统的处理时间越快越好，隔离意味着以时间为代价，没有必要，建议选择类似于 VxWorks 5.5 的操作系统 总工程师：应用软件间隔离是宇航系统的安全性要求，宇航系统在选择操作系统时必须考虑这一点，建议选择类似于 Linux 的操作系统 请说明两种操作系统的主要差异，完成表 3.1 中的空（1）~（5），并针对本任务要求，用 200 字以内的文字说明你选择操作系统的类型和理由。\n参考答案：\n比较类型 VxWorks 5.5 Linux 工作方式 操作系统与应用程序处于同一存储空间 （1）操作系统与应用程序处于不同的存储空间 多任务支持 支持多任务（线程）操作 （2）支持多进程、多线程操作 实时性 （3）硬实时系统 实时系统 安全性 （4）任务间无隔离保护 （5）支持进程间隔离保护 标准 API 支持 支持 我选择类似于 Linux 的嵌入式操作系统的理由：\nLinux 操作系统是一种安全性较强的操作系统。内核工作在系统态，应用软件工作在用户态，可以有效防止应用软件对操作系统的破坏 Linux 操作系统调度的最小单位是线程，线程归属于进程，进程具有自己独立的资源。进程通过存储器管理部件（MMU）实现多功能应用间隔离 嵌入式 Linux 操作系统支持硬件抽象，可有效实现 TLS 结构，并将硬件抽象与操作系统分离，可方便地实现硬件的外场快速更换 问题 3（7 分） 故障处理是宇航系统软件设计中极为重要的组成部分。故障处理主要包括故障监视、故障定位、故障隔离和系统容错（重组）。用 150 字以内的文字说明嵌入式系统中的故障主要分哪几类？并分别给出两种常用的故障滤波算法和容错算法。\n参考答案：\n1）嵌入式系统中的故障主要分为：\n硬件故障：如 CPU、存储器和定时器等 应用软件故障：如数值越界、异常和超时等 操作系统故障：如越权访问、死锁和资源枯竭等 2）滤波算法（任选 2 个）：\n门限算法 递减算法 递增算法 周期滤波算法 3）容错算法（任选 2 个）：\nN+1 备份 冷备 温备 热备 试题四：Oracle 数据库性能优化（25 分） 背景 某大中型企业采用 Oracle 数据库建立一个经济信息统计方面的大型数据库应用系统。尽管配置了比较良好的硬件和网络环境，但该数据库应用系统实施后的整体性能表现较差。特别是随着业务量与信息量的迅速扩大，数据库系统的存取速度显著减慢，存储效率也明显下降。\n该企业通过反复实践与摸索，并邀请数据库专家一起讨论，认为可以从以下 4 个方面进一步优化数据库应用系统：\n由于数据库应用中最主要的查询与修改数据操作大多需通过 I/O 来完成，因此需要通过调整服务器配置（即对硬件设备进行升级）、操作系统配置与数据库管理系统的有关参数，优化系统的 I/O 性能，尤其是改进磁盘 I/O 的效率与性能 优化\u0026quot;索引\u0026quot;的建立与使用机制，尽可能提高数据查询的速度或效率 合理使用聚类（Cluster），改进查询响应时间和系统的综合性能。其中，\u0026ldquo;聚类\u0026quot;是指把单独组织的，但在逻辑上经常需要连接的，较为稳定的几个基本表聚集在一起（在物理上实现邻近存放），可以显著减少数据的搜索时间，从而提高性能 对应用系统中使用的 SQL 语句进行调优，针对每条 SQL 语句都建立对应的索引等 问题 1（13 分） 在该企业所邀请的数据库专家讨论意见中，针对每条 SQL 语句都建立索引的建议是否合适？请简要说明理由。\n参考答案：\n不适当，理由如下：\n如果建立索引不当，数据库管理系统将不利用已经建立的索引，而采取全表扫描 当更新操作成为系统瓶颈，因为每次更新操作会重建表的索引，则需要考虑删除某些索引 应该针对不同应用情况选择适当的索引类型。例如，如果经常使用范围查询，则 B 树索引比散列索引更加高效 应该将有利于大多数数据查询和更新的索引设为聚类索引 需要对建立的索引进行实际的测试，因为索引的使用是由数据库管理系统（数据库优化器）决定的 问题 2（12 分） 结合你的经验，请列举出 4 条 SQL 语句优化的基本策略。\n参考答案：\nSQL 语句优化的常见策略如下（包含但不限于以下内容，列举出其中 5 个小点即可，每小点 1 分）：\n建立物化视图或尽可能减少多表查询 以不相干子查询替代相干子查询 只检索需要的列 用带 IN 的条件子句等价替换带 OR 的子句 经常提交 COMMIT，以尽早释放锁 避免嵌套的游标（Cursor）和多重循环等 试题五：Web 系统架构方案对比 + O/R 映射 + 性能优化（25 分） 背景 E-Mall 是一家电子商务公司，其主要业务是在线购物，包括书籍、服装、家电和日用品等。随着公司业务规模不断增大，公司决策层决定重新设计并实现其网上交易系统，公司负责系统开发的王工和李工分别给出了两种不同的设计方案（图 5.1 和图 5.2）。\n公司的架构师和开发者针对这两种设计方案，从服务器负载情况、业务逻辑的分离性、系统可靠性、实现简单性等方面进行讨论与评估，综合考虑最终采用了李工给出的方案。\n问题 1（8 分） 请分析比较王工、李工两种方案的优点和不足，完成下表中的空白部分。\n方案\\评价因素 王工建议的体系结构方案 李工建议的体系结构方案 服务器负载 Web 服务器需要同时处理业务逻辑与数据库访问，负担较重 （1） 业务逻辑的分离性 （2） 采用多个应用服务器专门进行业务逻辑处理，做到业务逻辑与其他代码分离 系统可靠性 多处采用单台 Web 服务器，整个系统的可靠性较差 （3） 实现简单性 主要采用 JSP、ASP 等脚本语言实现系统，比较简单 （4） 参考答案：\n方案\\评价因素 王工建议的体系结构方案 李工建议的体系结构方案 服务器负载 Web 服务器需要同时处理业务逻辑与数据库访问，负担较重 （1）Web 服务器处理用户请求，应用服务器处理业务逻辑与数据库访问，负载较为均衡 业务逻辑的分离性 （2）业务逻辑与数据库访问都位于 Web 服务器中，业务与逻辑没有分离 采用多个应用服务器专门进行业务逻辑处理，做到业务逻辑与其他代码分离 系统可靠性 多处采用单台 Web 服务器，整个系统的可靠性较差 （3）采用多台应用服务器，系统的可靠性较高 实现简单性 主要采用 JSP、ASP 等脚本语言实现系统，比较简单 （4）需要将脚本语言与面向对象编程语言相结合，相对复杂 问题 2（9 分） 对数据库的访问是该系统开发中需要特别注意的一个问题，O/R 映射是一种常用的数据库访问编程技术。请用 200 字以内的文字说明 O/R 映射的含义，并指出采用 O/R 映射的 3 个主要好处。\n参考答案：\nO/R 映射指的是对象/关系映射，是一种编程技术，将关系数据库中的关系型数据与面向对象编程语言中类型系统定义的数据进行格式转换。\n采用对象/关系映射主要有 3 点好处：\n可以将业务逻辑与数据逻辑分离 可以使得开发人员采用面向对象的方式访问底层关系型数据库 能够做到上层应用与底层的具体数据库无关，两者解耦合 问题 3（8 分） 性能是 Web 应用系统的一个重要质量属性。请用 200 字以内的文字说明 3 个主要影响 Web 应用系统性能的因素，针对每个因素提出解决方案以提高系统性能。\n参考答案：\n影响 Web 应用系统性能的 3 个主要因素分别是：\n数据库的连接与销毁：可以采用数据池的方式缓存数据库连接，实现数据库连接复用，提高系统的数据访问效率\n构件或中间件的加载与卸载：可以采用分布式对象池的方式缓存创建开销大的对象，实现对象复用，用以提高效率\n线程的创建与销毁：可以采用线程池的方式缓存已经创建的线程，提高系统的反应速度\n","date":"2024-01-01T00:00:00Z","permalink":"/p/31-mo-ni-shi-ti-ii-xia-wu-an-li-fen-xi/","title":"31-模拟试题II下午案例分析"},{"content":"模拟试题II 下午论文 软考系统架构设计师 | 模拟题 II 论文 形式：4 道论文题选 1 道（必答） 总分：75 分（300 分制中权重最大） 及格线：45 分 写作时间：75 分钟（不含构思）\n论文题一：论软件架构风格 题目要求 软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。体系结构风格定义一个系统家族，即一个体系结构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。体系结构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。\n请围绕\u0026quot;论软件架构风格\u0026quot;论题，依次从以下三个方面进行论述。\n概要叙述你参与分析和设计的软件系统开发项目以及你所担任的主要工作。 软件系统开发中常用的软件架构风格有哪些？详细阐述每种风格的具体含义。 详细说明你所参与分析和设计的软件系统是采用什么软件架构风格的，并分析采用该架构风格设计的原因。 论点提纲 摘要要点：\n项目背景：某 XX 系统（如电商平台/物流系统），规模 XX，团队 XX 人 采用风格：微服务架构风格（最现代的加分项） 取得效果：迭代速度提升 X 倍，故障隔离 Y% 正文结构（建议 2000-2500 字）：\n第 1 段（400 字）：项目背景 第 2 段（700 字）：6 大经典架构风格 第 3 段（600 字）：项目中选用的具体风格及原因 第 4 段（300 字）：效果与反思 关键术语与解析 常见的、经典的架构风格有：\n1）数据流风格：\n包括批处理体系结构风格 管道-过滤器风格 2）调用和返回风格：\n包括主程序/子程序风格 面向对象风格 层次型风格（C/S 架构、B/S 架构） 3）以数据为中心的风格：\n仓库体系结构风格 黑板体系结构风格 4）虚拟机风格：\n解释器风格 规则系统风格 5）独立构件架构风格：\n进程通信风格 事件系统风格 6）C2 风格：\nC2 风格也被认为是层次风格的一种 此外，一些现代的体系结构风格如微服务、SOA 等也可以写在论文中。\n实战建议 推荐选择微服务架构作为论述重点（最贴近当下工程实践） 可结合项目谈：服务拆分原则、API 网关、服务发现、配置中心、熔断限流、链路追踪 必引文献：Chris Richardson《微服务架构设计模式》、Sam Newman《微服务设计》 论文题二：论企业应用系统的层次式架构风格 题目要求 层次式架构是软件体系结构设计中最为常用的一种架构形式，它为软件系统提供了一种在结构、行为和属性方面的高级抽象，其核心思想是将系统组成为一种层次结构，每一层为上层服务，并作为下层客户。在一些层次系统中，除了一些精心挑选的输出函数外，内部的层接口只对相邻的层可见。层次式架构风格的每一层最多只影响两层，同时只要给相邻层提供相同的接口，也允许每层用不同的方法实现，这种方式也为软件重用提供了强大的支持。\n大部分的应用会分成表现层（或称为展示层）、中间层（或称为业务层）、数据访问层（或称为持久层）和数据层。\n请围绕\u0026quot;企业应用系统的层次式架构风格\u0026quot;论题，依次从以下三个方面进行论述。\n概要叙述你参与管理和开发的企业应用系统建设项目以及你在其中所承担的主要工作。 请结合项目实际情况，指出你参与开发的应用系统都有哪些层次以及每个层次的主要功能。 请结合项目实际情况，说明你的项目是如何使用层次式架构进行架构设计的。 论点提纲 摘要要点：\n项目背景：某 XX 业务系统（如订单/CRM/ERP），XX 个用户 架构选型：经典 4 层架构（表现/业务/数据访问/数据） 取得效果：模块化提升 X%，代码复用率 Y% 正文结构（建议 2000-2500 字）：\n第 1 段（400 字）：项目背景 第 2 段（700 字）：4 层架构详细功能 第 3 段（600 字）：层次式架构设计过程 第 4 段（300 字）：实际效果 关键术语与解析 层次式架构 4 层结构：\n（1）表现层：\n主要负责接收用户的请求，对用户的输入、输出进行检查与控制 处理客户端的一些动作，包括控制页面跳转等 向用户呈现最终的结果信息 可以使用 MVC 模式来设计表现层 （2）中间层（业务层）：\n负责实现系统的业务功能，主要包括业务逻辑层组件、业务逻辑层工作流、业务逻辑层实体和业务逻辑层框架四个方面 业务逻辑层组件：分为接口和实现类两个部分，接口用于定义业务逻辑组件，定义业务逻辑组件必须实现的方法 通常按模块来设计业务逻辑组件，每个模块设计为一个业务逻辑组件，并且每个业务逻辑组件以多个 DAO 组件作为基础，从而实现对外提供系统的业务逻辑服务 业务逻辑层工作流：能够实现在多个参与者之间按照某种预定义的规则传递文档、信息或任务的过程自动进行 业务逻辑层实体：提供对业务数据及相关功能的状态编程访问 业务逻辑层是实现系统功能的核心组件，采用容器的形式，便于系统功能的开发、代码重用和管理 （3）持久层（数据访问层）：\n主要负责数据的持久化存储 负责将业务数据存储在文件、数据库等持久化存储介质中 持久层可以使用以下 5 种数据访问方式： 在线访问 Data Access Object（DAO） Data Transfer Object（DTO） 离线数据模式 对象/关系映射（Object/Relation Mapping，O/R Mapping） （4）数据层：\n主要是数据库本身，负责数据存储和管理 实战建议 强调\u0026quot;层与层之间接口的稳定性\u0026quot;是层次架构的关键 可结合 SSM/Spring Boot 等技术栈谈 提到层次架构的脆弱性（底层错误影响整体、层间通信开销） 论文题三：论面向服务的架构设计 题目要求 在面向服务的架构（Service-Oriented Architecture，SOA）中，服务的概念有了延伸，泛指系统对外提供的功能集。例如，在一个大型企业内部，可能存在进销存、人事档案和财务等多个系统，在实施 SOA 后，每个系统用于提供相应的服务，财务系统作为资金运作的重要环节，也向整个企业信息化系统提供财务处理的服务，那么财务系统的开放接口可以看成是一个服务。\n请围绕\u0026quot;面向服务的架构设计\u0026quot;论题，依次从以下三方面进行论述。\n概要叙述你参与分析和开发的软件系统开发项目以及你所担任的主要工作。 说明面向服务架构的主要协议和规范、标准，详细阐述每种协议和规范、标准的具体内容。 说明面向服务架构的设计原则，详细阐述每种设计原则的具体内容。 论点提纲 摘要要点：\n项目背景：某 XX 企业信息化系统整合，XX 个遗留系统，XX 个服务 选型理由：业务跨系统整合、复用性要求高 取得效果：服务复用率 X%，集成周期缩短 Y% 正文结构（建议 2000-2500 字）：\n第 1 段（400 字）：项目背景 第 2 段（600 字）：SOA 主要协议与标准（UDDI/WSDL/SOAP/REST/XSD） 第 3 段（600 字）：SOA 8 大设计原则 第 4 段（400 字）：实际应用效果 关键术语与解析 SOA 主要协议、规范与标准：\n（1）UDDI 协议：统一描述、发现和集成协议。包含了服务描述与发现的标准规范，它使得商业实体能够彼此发现；定义它们怎样在 Internet 上互相作用，并在一个全球的注册体系架构中共享信息。\n（2）WSDL（Web Services Description Language）：是一个用来描述 Web 服务和说明如何与 Web 服务通信的 XML 语言。\n（3）SOAP 协议：SOAP 是在分散或分布式的环境中交换信息的简单的协议，是一个基于 XML 的协议。\n（4）REST 规范：为了让不同的软件或者应用程序在任何网络环境下都可以进行信息的互相传递。微服务对外就是以 REST API 的形式暴露给调用者。RESTful 即 REST 形式的，是对遵循 REST 设计思想同时满足设计约束的一类架构设计或应用程序的统称，这一类都可称为 RESTful，可以理解为资源表述性状态转移。\n（5）通信协议标准：SOA 服务用消息进行通信，该消息通常使用 XML Schema 来定义（也称作 XML Schema Definition，XSD）。\nSOA 的设计原则主要有：\n无状态：以避免服务请求者依赖于服务提供者的状态 单一实例：以高内聚的实现方法，来避免功能冗余 明确定义的接口：服务的接口由 WSDL 定义，用于指明服务的公共接口与其内部专用实现之间的界线 自包含和模块化：服务封装了那些在业务上稳定、重复出现的活动和组件，实现服务的功能实体是完全独立自主的，独立进行部署、版本控制、自我管理和恢复 粗粒度：服务数量不应该太大，依靠消息交互而不是远程过程调用（RPC），通常消息量较大，但是服务之间的交互频度较低 服务之间的松耦合性：服务使用者看到的是服务的接口，其位置、实现技术和当前状态等对使用者是不可见的，服务私有数据对服务使用者是不可见的 重用能力：服务应该是可以复用的 互操作性、兼容和策略声明：为了确保服务规约的全面和明确，利用策略来定义可配置的互操作语义，来描述特定服务的期望、控制其行为。利用策略声明确保服务期望和语义兼容性方面的完整和明确 实战建议 可结合 Apache Dubbo / Spring Cloud / gRPC 等实际服务框架 重点谈\u0026quot;服务治理\u0026quot;：服务注册/发现、负载均衡、熔断降级、链路追踪 与微服务对比：SOA 强调\u0026quot;集成\u0026quot;、ESB 总线；微服务强调\u0026quot;独立部署\u0026quot;、去中心化 论文题四：论基于架构的软件设计方法及应用 题目要求 基于架构的软件设计（Architecture-Based Software Design，ABSD）方法以构成软件架构的商业、质量和功能需求等要素来驱动整个软件开发过程。ABSD 是一个自顶向下，递归细化的软件开发方法，它以软件系统功能的分解为基础，通过选择架构风格实现质量和商业需求，并强调在架构设计过程中使用软件架构模板。采用 ABSD 方法，设计活动可以从项目总体功能框架明确后就开始，因此该方法特别适用于开发一些不能预先决定所有需求的软件系统，如软件产品线系统或长生命周期系统等，也可为需求不能在短时间内明确的软件项目提供指导。\n请围绕\u0026quot;基于架构的软件开发方法及应用\u0026quot;论题，依次从以下三个方面进行论述。\n概要叙述你参与开发的、采用 ABSD 方法的软件项目以及你在其中所承担的主要工作。 结合项目实际，详细说明采用 ABSD 方法进行软件开发时，需要经历哪些开发阶段？每个阶段包括哪些主要活动？ 阐述你在软件开发的过程中都遇到了哪些实际问题及解决方法。 论点提纲 摘要要点：\n项目背景：某 XX 软件产品线系统，XX 个变体 采用方法：ABSD 6 阶段 取得效果：开发周期缩短 X%，质量属性达成率 Y% 正文结构（建议 2000-2500 字）：\n第 1 段（400 字）：项目背景 第 2 段（800 字）：ABSD 6 阶段详细（重点） 第 3 段（500 字）：实施中的实际问题与解决 第 4 段（300 字）：经验总结 关键术语与解析 采用 ABSD 方法进行软件开发时，需要经历 6 个阶段：\n（1）架构需求阶段：\n明确用户对目标软件系统在功能、行为、性能、设计约束等方面的期望 主要活动： 需求获取：定义开发人员必须实现的软件功能，使得用户能够完成他们的任务，从而满足功能需求；同时还要获得软件质量属性，满足一些非功能性需求 标识构件：首先需要获得系统的基本结构，然后对基本结构进行分组，最后将基本结构进行打包成构件 架构需求评审：组织一个由系统涉众（用户、系统分析师、架构师、设计实现人员等）组成的小组，对架构需求及相关构件进行审查。审查的主要内容包括所获取的需求是否真实反映了用户需求，构件合并是否合理等 （2）架构设计阶段：\n一个迭代过程，利用架构需求生成并调整架构决策 主要活动： 提出架构模型 将已标识的构件映射到架构中 分析构件之间的相互作用 产生系统架构 架构设计评审 （3）架构文档化阶段：\n主要活动是对架构设计进行分析与整理 生成架构规格说明书和测试架构需求的质量设计说明书 （4）架构复审阶段：\n在一个主版本的软件架构分析之后，需要安排一次由外部人员（客户代表和领域专家）参加的架构复审 架构复审需要评价：架构是否能够满足需求；质量属性需求是否在架构中得以体现；层次是否清晰；构件划分是否合理等 标识潜在的风险，及早发现架构设计中的缺陷和错误 （5）架构实现阶段：\n对架构进行实现的过程 主要活动：架构分析与设计、构件实现、构件组装和系统测试 （6）架构演化阶段：\n主要解决用户在系统开发过程中发生的需求变更问题 主要活动：架构演化计划、构件变动、更新构件的相互作用、构件的组装与测试和技术评审 在软件开发的过程中可能遇到的问题：\n在架构需求获取过程中如何对捕获的架构需求进行筛选和优先级排序 在架构复审过程中如何解决评审人员意见不一致的问题 在架构实现过程中如何根据项目组实际情况选择开发语言与开发平台 在架构演化过程中如何筛选并处理用户的需求变更等 实战建议 强调 ABSD 是\u0026quot;质量/商业/功能\u0026quot;三要素驱动 强调 ABSD 适合不能预先决定所有需求的场景（产品线系统、长生命周期系统） 必提\u0026quot;架构风格\u0026quot;作为满足质量属性的手段 ","date":"2024-01-01T00:00:00Z","permalink":"/p/32-mo-ni-shi-ti-ii-xia-wu-lun-wen/","title":"32-模拟试题II下午论文"},{"content":"海量qq去重 40亿个qq号如何去重？仅1GB内存\n解析：\nQQ号（数字）最大通常不会超过10位，在Java中通常用 long 或 String 表示。如果是40亿个 long 型QQ号，原始大小大约是 $40 \\times 10^8 \\times 8 \\text{ 字节} \\approx 32\\text{ GB}$，直接加载到内存肯定会 OOM（内存溢出）。\n在1GB内存的严格限制下，Java中最优的解法是使用 BitMap（位图算法） ，或者在允许微小误差的情况下使用 Bloom Filter（布隆过滤器） 。\n使用位图(bitmap)去解决，如果出现过就标记为1，1个字节8位，4个字节32位，空间缩小32倍，14.9/32约等于0.46GB\n方案一：BitMap（无误差，最推荐） 原理：\n我们不用存储QQ号本身，而是用内存中的“一个比特位（bit）”来标记某个QQ号是否存在。比特位的下标（Index）直接对应QQ号。\n如果QQ号 12345 存在，就把第 12345 个 bit 置为 1。\nQQ号目前最大约43亿（$2^{32} \\approx 42.9亿$）。如果我们要表示完所有的QQ号，需要约43亿个bit。\n内存计算：$43 \\times 10^8 \\text{ bits} \\approx 5.37 \\times 10^8 \\text{ 字节} \\approx 512\\text{ MB}$。\n512MB 刚好远小于 1GB 的限制 ，完全可以一次性在内存中无误差地完成去重。\nJava 代码实现 在Java中，标准库的 java.util.BitSet 内部使用的是 long[] 数组，它的逻辑大小最大支持 $2^{31}-1$ 个 bit（约21亿），无法直接装下43亿。因此我们需要自己用 long[] 数组简单封装一个支持无符号整型（43亿）的 ExtendedBitSet 。\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 import java.io.*; public class QQDuplicateRemover { // 43亿个连续数字需要约 512MB 内存 private static final long MAX_QQ_NUMBER = 4300000000L; // 一个long有64位 private final long[] bits; public QQDuplicateRemover() { // 计算需要多少个long才能装下43亿个bit int size = (int) (MAX_QQ_NUMBER / 64) + 1; this.bits = new long[size]; } /** * 标记一个QQ号存在 * @return 如果之前已经存在，返回 true；如果是新数据，返回 false */ public boolean add(long qq) { int index = (int) (qq / 64); // 找到在哪个 long 元素里 int position = (int) (qq % 64); // 找到在该 long 的哪一位 (0-63) long mask = 1L \u0026lt;\u0026lt; position; // 检查这一位是否已经是 1 if ((bits[index] \u0026amp; mask) != 0) { return true; // 已存在，即重复了 } // 将该位置为 1 bits[index] |= mask; return false; // 新数据 } public static void main(String[] args) { QQDuplicateRemover remover = new QQDuplicateRemover(); // 模拟大数据流式读取（假设从一个巨大的文件中一行行读取，不占用内存） String filePath = \u0026#34;huge_qq_list.txt\u0026#34;; String outputPath = \u0026#34;unique_qq_list.txt\u0026#34;; try (BufferedReader br = new BufferedReader(new FileReader(filePath)); BufferedWriter bw = new BufferedWriter(new FileWriter(outputPath))) { String line; long duplicateCount = 0; while ((line = br.readLine()) != null) { if (line.trim().isEmpty()) continue; long qq = Long.parseLong(line.trim()); // 去重核心：如果add返回false，说明是第一次见，写入新文件 if (!remover.add(qq)) { bw.write(String.valueOf(qq)); bw.newLine(); } else { duplicateCount++; } } System.out.println(\u0026#34;去重完成！检测到重复QQ号数量: \u0026#34; + duplicateCount); } catch (IOException e) { e.printStackTrace(); } } } Go 语言实现 Go 语言在处理大块内存分配时非常高效。我们可以直接申请一个 []uint64 切片。\n一个 uint64 占用 8 字节（64 bits）。 43 亿 / 64 ≈ 67,187,500 个元素。 go代码\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 package main import ( \u0026#34;bufio\u0026#34; \u0026#34;fmt\u0026#34; \u0026#34;os\u0026#34; \u0026#34;strconv\u0026#34; \u0026#34;strings\u0026#34; ) const maxQQNumber = 4300000000 type QQBitMap struct { bits []uint64 } func NewQQBitMap() *QQBitMap { // 计算需要多少个 uint64 元素 size := (maxQQNumber / 64) + 1 return \u0026amp;QQBitMap{ bits: make([]uint64, size), } } // Add 标记一个QQ号存在 // 如果之前已经存在，返回 true；如果是新数据，返回 false func (bm *QQBitMap) Add(qq uint64) bool { index := qq / 64 position := qq % 64 mask := uint64(1) \u0026lt;\u0026lt; position // 检查该位是否已经是 1 if (bm.bits[index] \u0026amp; mask) != 0 { return true // 已存在，重复 } // 置为 1 bm.bits[index] |= mask return false // 新数据 } func main() { bitmap := NewQQBitMap() // 模拟流式读取大文件（不一次性加载到内存） inputFile, err := os.Open(\u0026#34;huge_qq_list.txt\u0026#34;) if err != nil { fmt.Println(\u0026#34;打开文件失败:\u0026#34;, err) return } defer inputFile.Close() outputFile, err := os.Create(\u0026#34;unique_qq_list.txt\u0026#34;) if err != nil { fmt.Println(\u0026#34;创建输出文件失败:\u0026#34;, err) return } defer outputFile.Close() scanner := bufio.NewScanner(inputFile) writer := bufio.NewWriter(outputFile) defer writer.Flush() duplicateCount := 0 for scanner.Scan() { line := strings.TrimSpace(scanner.Text()) if line == \u0026#34;\u0026#34; { continue } qq, err := strconv.ParseUint(line, 10, 64) if err != nil { continue } // 去重判断 if !bitmap.Add(qq) { _, _ = writer.WriteString(strconv.FormatUint(qq, 10) + \u0026#34;\\n\u0026#34;) } else { duplicateCount++ } } if err := scanner.Err(); err != nil { fmt.Println(\u0026#34;读取过程中发生错误:\u0026#34;, err) } fmt.Printf(\u0026#34;去重完成！检测到重复QQ号数量: %d\\n\u0026#34;, duplicateCount) } Rust 语言实现 Rust 凭借精细的内存控制和零成本抽象（Zero-cost Abstractions），是解决此类低内存大数据场景的王牌。我们可以直接用 Vec\u0026lt;u64\u0026gt;，也可以使用标准库衍生出的第三方高性能库（如 bit-vec 或高效压缩位图 roaring）。\n这里为了对标底层逻辑，先给出 纯手工原生实现 ，随后附上生产环境更推荐的 Roaring Bitmap 方案。\n1. Rust 原生实现（无第三方依赖） 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 use std::fs::File; use std::io::{self, BufRead, BufReader, BufWriter, Write}; const MAX_QQ_NUMBER: u64 = 4_300_000_000; struct QQBitMap { bits: Vec\u0026lt;u64\u0026gt;, } impl QQBitMap { fn new() -\u0026gt; Self { let size = (MAX_QQ_NUMBER / 64) as usize + 1; // 分配 512MB 的连续堆内存，初始化为 0 Self { bits: vec![0; size] } } /// 标记一个QQ号存在 /// 如果之前已经存在，返回 true；如果是新数据，返回 false fn add(\u0026amp;mut self, qq: u64) -\u0026gt; bool { let index = (qq / 64) as usize; let position = (qq % 64) as u32; let mask = 1u64 \u0026lt;\u0026lt; position; if (self.bits[index] \u0026amp; mask) != 0 { true // 已存在 } else { self.bits[index] |= mask; false // 新数据 } } } fn main() -\u0026gt; io::Result\u0026lt;()\u0026gt; { let mut bitmap = QQBitMap::new(); let input_file = File::open(\u0026#34;huge_qq_list.txt\u0026#34;)?; let reader = BufReader::new(input_file); let output_file = File::create(\u0026#34;unique_qq_list.txt\u0026#34;)?; let mut writer = BufWriter::new(output_file); let mut duplicate_count = 0; for line in reader.lines() { let line = line?; let trimmed = line.trim(); if trimmed.is_empty() { continue; } if let Ok(qq) = trimmed.parse::\u0026lt;u64\u0026gt;() { if !bitmap.add(qq) { writeln!(writer, \u0026#34;{}\u0026#34;, qq)?; } else { duplicate_count += 1; } } } // 显式刷新缓冲区 writer.flush()?; println!(\u0026#34;去重完成！检测到重复QQ号数量: {}\u0026#34;, duplicate_count); Ok(()) } 2. Rust 工业级标准：Roaring Bitmap 方案 在 Rust 实际工程中，更推荐使用 roaring 库。它不仅高度优化了位图计算性能，而且具备自动压缩功能。如果 40 亿 QQ 号分布相对稠密或连续，它的内存占用甚至可以压缩到 几十MB 到 一两百MB 。\n添加依赖 (Cargo.toml)：\n1 2 [dependencies] roaring = \u0026#34;0.10\u0026#34; 代码\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 use roaring::RoaringTreemap; // 支持 64 位整数的 Roaring Bitmap use std::fs::File; use std::io::{self, BufRead, BufReader, BufWriter, Write}; fn main() -\u0026gt; io::Result\u0026lt;()\u0026gt; { // 实例化一个支持 u64 范围的压缩位图 let mut bitmap = RoaringTreemap::new(); let reader = BufReader::new(File::open(\u0026#34;huge_qq_list.txt\u0026#34;)?); let mut writer = BufWriter::new(File::create(\u0026#34;unique_qq_list.txt\u0026#34;)?); let mut duplicate_count = 0; for line in reader.lines() { let line = line?; let trimmed = line.trim(); if trimmed.is_empty() { continue; } if let Ok(qq) = trimmed.parse::\u0026lt;u64\u0026gt;() { // bitmap.insert 如果原本不存在会返回 true，存在则返回 false if bitmap.insert(qq) { writeln!(writer, \u0026#34;{}\u0026#34;, qq)?; } else { duplicate_count += 1; } } } writer.flush()?; println!(\u0026#34;去重完成！检测到重复QQ号数量: {}\u0026#34;, duplicate_count); Ok(()) } .\n方案二：Bloom Filter（如果QQ号是不规则字符串） 注意： 如果你的QQ号不是纯数字，或者范围远超43亿（比如包含了字母、或者未来升级到了更长的位数），BitMap 的数组就会变得极大，导致内存不够。\n这时候就要用 布隆过滤器（Bloom Filter） 。 它通过多个哈希函数将一个QQ号映射到同一个位图的多个点上。\n优点： 极其节省内存。哪怕QQ号是复杂的字符串，40亿数据通常也只需要几百MB。 缺点： 存在微小的 误判率（False Positive） 。也就是说，如果它说一个QQ号“不存在”，那它 绝对不存在 ；但如果它说“存在”，有极小的概率这个QQ号其实没出现过（哈希碰撞）。 Java 实现建议 在实际工程中，不需要手写，直接使用 Google 的 Guava 库，它对内存控制做到了极致。\nJava\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 // 需要引入 Guava 依赖 // com.google.common.hash.BloomFilter; long expectedInsertions = 4000000000L; // 40亿 double fpp = 0.01; // 允许 1% 的误判率 // Guava 会根据数据量和误判率自动计算并分配最省内存的 Bit 数组 BloomFilter\u0026lt;Long\u0026gt; filter = BloomFilter.create( Funnels.longFunnel(), expectedInsertions, fpp ); // 判断与插入 if (filter.mightContain(qq)) { // 可能是重复数据（有1%概率误判） } else { filter.put(qq); // 绝对是新数据，留下来 } 两个极端情况： 1. 如果QQ号断层非常严重怎么办？ 比如40亿个QQ号里，有几个号码是 99999999999（11位甚至12位超大数字）。\n问题： 如果用基础 BitMap，为了开辟到 99999999999 的索引，你的数组要开得极大，内存直接爆掉。 解法： 改用 Roaring Bitmap（高效压缩位图） 。Java 中有非常成熟的开源实现 RoaringBitmap。它将 32 位无符号整数分块（每块 $2^{16}=65536$ 个数字）。如果某一块全空，它不占内存；如果很稀疏，它用数组存；如果很稠密，它才用位图存。在非连续的大数据去重中，它是工业界的标准解法。 2. 如果只有几MB内存，连 512MB 都没有呢？ 解法：外排序 + 分治法（MapReduce思想） 。 分桶（Hash Sharding）： 把大文件读出来，用 qq % 100 的结果，把40亿数据分流到 100 个小文件中（file_0 到 file_99）。相同的QQ号必定落入同一个文件。 小文件去重： 每次只把一个小文件加载到内存中（此时一个小文件只有 4000万数据，用 HashSet 都可以轻松搞定），去重后输出。 合并： 把 100 个去重后的小文件拼起来，就是最终结果。 百万级excel快速导入数据库 要考虑的问题：\n1.数据正确性问题\n2.各类异常情况，格式等\n3.失败后如何处理\n4.出现重复的情况\n5.内存溢出问题，\n6.效率问题\n内存溢出（OOM）的终结者：流式解析 绝对不要使用： Apache POI 的 WorkbookFactory.create()。它会将整个 Excel 的 DOM 树一次性加载到内存中。一个 100 万行的 .xlsx 文件，在内存中展开可能会放大 50~100 倍，瞬间吃光数 GB 内存。 工业级解法： 使用 EasyExcel （阿里开源）或 Apache POI 的 SXSSF（SAX 解析模式）。 原理： 它们采用 流式（Event-driven）逐行解析 。内存中永远只保留当前解析的几行数据，内存占用是恒定的（通常只需几M或几十M），不管文件多大都绝不会 OOM。 效率问题：四轮驱动加速 批处理（Batch Insert）： 绝不能一条条插入。设置一个缓冲区（例如每 1000~5000 条为一批），使用 mybatis-plus 的 saveBatch 或原生 JDBC 的 addBatch()。 多线程并行（Producer-Consumer）： 主线程（生产者）： 负责单线程流式读取 Excel（Excel 格式决定了它很难多线程并发读取）。读满一批（如 2000 条），就打包成一个 Task 扔进线程池。 线程池（消费者）： 多个异步线程并发将数据写入数据库。 数据库连接池与驱动优化： 连接池（如 HikariCP）的最大连接数要喂饱和。 关键配置： 如果使用 MySQL，JDBC 连接串必须加上 \u0026amp;rewriteBatchedStatements=true，否则它的 Batch 只是伪批处理，加上后才会真正合并成一条 insert into ... values (),(),()。 1 \u0026amp; 2. 数据的防线：正确性与各类异常 百万级数据中，必然充斥着各种“奇葩”格式和脏数据。\n正确性与格式校验 JSR-303 异步校验： 在 EasyExcel 的 ReadListener 监听器中，接收到对象后立即使用 Validator 进行注解校验（如 @NotBlank, @Email, @Size）。 类型转换器（Converter）： 时间日期： 明确指定格式（如 yyyy-MM-dd HH:mm:ss），防止由于 Excel 本身单元格格式转换导致的五花八门的时间戳或文本。 大数字（如手机号、身份证）： Excel 容易将其变成科学计数法（1.38E+10）。代码中必须强制按 String 转换并做正则清洗。 业务级“二阶段校验” 一阶段（本地校验）： 纯内存校验（非空、长度、格式、枚举值）。不通过的直接打标签归为“失败行”。 二阶段（DB 校验）： 比如“外键是否存在”。不要在循环里查 DB！应该分批批量拉取 DB 的对应数据到本地 Cache（或者用 Redis），在内存中做比对。 3 \u0026amp; 4. 容错与防重：失败处理与重复数据 处理百万数据时，因为第 90 万条报错而导致前 90 万条全部回滚，是不可接受的体验。\n失败后如何处理？（两套可选策略） 根据业务严苛程度，通常选择 方案 B ：\n策略 A：强一致性（全成功或全失败） 实现： 利用分布式事务或大事务。但百万级数据放在一个事务里会导致 长事务 ，锁死整张表，数据库直接挂掉。通常不建议。 策略 B：最终一致性（断点续传 + 错误报告）—— 推荐 异步处理，返回 TaskID： 用户上传后，后端立即生成一个导入任务记录（状态：导入中），让用户去“任务中心”查看进度。 错误记录表/文件： 线程池在执行批插入时，若某一批次失败（如某一行违反唯一索引）， 只回滚当前批次 。随后将这一批改为“逐条插入”，找出具体哪几行报错，把错误行和原因记入“错误日志表”。 最终产物： 导入完成后，状态改为“部分成功”。用户可以下载一个由后端生成的 error.xlsx，里面只有失败的行，并且最后一列写明了“失败原因”（如：第 85 万行：手机号格式错误）。用户修改后可二次上传。 出现重复的情况（去重策略） 重复分为两种： Excel 内部自带重复 ，以及 Excel 与 DB 原有数据重复 。\n1. Excel 内部去重 如果业务不允许内部重复，利用 布隆过滤器（Bloom Filter） 或 RoaringBitmap （如果去重 Key 可以转为 Long 整数）。 在解析流中，每读一行，先过一遍布隆过滤器，存在则直接判定为“重复行”，踢入错误日志。 2. 与 DB 原有数据重复（核心看业务语义） 业务语义 SQL 解决方案 适用场景 直接覆盖（以新为准） INSERT INTO ... ON DUPLICATE KEY UPDATE 幂等更新，如商品最新价格同步。 跳过不导（以旧为准） INSERT IGNORE INTO ... 历史流水归档，不可更改。 先查再断（提示错误） 批量拉取 DB 的 Key，在内存中对比，重复的归入 error.xlsx。 注册账号、工号导入等严格防重场景。 🏗 企业级百万导入经典架构拓扑 整个流程通过生产者-消费者模型解耦，既保护了内存，又压榨了多核 CPU 的性能。\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 [ 客户端 ] --( 上传 Excel )--\u0026gt; [ Controller 接收并落盘临时文件 ] | ( 异步触发，返回 TaskID ) | v [ EasyExcel 流式解析 (单线程) ] | ( 每解析 2000 条，执行本地校验 ) | v [ 提交给自定义线程池 (多线程并行) ] / | \\ [Thread-1] [Thread-2] [Thread-3] | | | (批量DB校验 + writeBatchedStatements 批量写入) \\ | / v [ 数据库 (MySQL/PgSQL) ] | (如果有失败行 -\u0026gt; 写入错误日志) | v [ 导出 error.xlsx 供用户下载 ] 🎯 落地核心避坑总结 文件落盘： 收到前端的大文件后， 先写到服务器本地临时目录（或 OSS） ，再去读取这个文件。不要直接用 MultipartFile.getInputStream() 一直拖着 HTTP 连接，否则大文件解析太久会导致 HTTP 连接超时断开。 合理配置线程池： 导入是 IO 密集型任务 ，线程数可以适当开大（例如 $2 \\times \\text{CPU核心数}$）。但必须要配置 CallerRunsPolicy（调用者运行策略）作为拒绝策略。当数据库写得慢、线程池队列满了的时候，让主线程（EasyExcel 解析线程）亲自去同步写库，从而自动实现 限流反压 ，防止队列塞满导致 OOM。 2GB的文件找出高频top100的单词 处理 2GB 文件并找出高频 Top 100 单词，最核心的挑战在于 内存管理 。2GB 的文本文件如果直接整块读入内存（特别是转换为 Java 对象、Python 字典或分割成字符串数组时），由于对象头开销和内存放大效应，往往会暴增到 6GB~10GB 以上，极易触发 OOM（内存溢出）。\n作为开发者，处理这种大文件通常有两种思路：一是 单机流式处理（Time-Memory Trade-off） ，二是 分治法（更通用、可扩展到百 GB 文件） 。\n下面为你提供两种最高效、最实用的落地方案：\n方案一：单机流式读取 + 最小堆（推荐，代码最简单） 如果你的机器有 4GB 以上的可用内存，我们可以通过流式逐行/逐块读取（Stream / Buffer）来严格控制内存。在内存中，我们只维护一个哈希表（Map/Dict）来存 单词 -\u0026gt; 频次，以及一个大小为 100 的最小堆（Min-Heap / PriorityQueue）来筛选 Top 100。\n内存粗算 ：2GB 文本中去重后的独立单词（Lexicon）通常不会超过几百万个。假设去重后有 200 万个非重复单词，每个单词平均 10 字节，哈希表占用内存大约几百 MB，完全可以单机一把过。\n1. 核心步骤 1.流式分块读取： **控制内存。**使用缓冲区（Buffer）流式读取文件，每次读入几兆数据，利用正则或状态机匹配出单词，切忌使用 readAllLines。\n2.内存哈希计数： **增量更新。**在内存中维护一个高效的 HashMap，读取到单词后直接在 Map 中累加频次：map.put(word, map.getOrDefault(word, 0) + 1)。\n3.构建大小为 100 的最小堆： **动态筛选。**遍历处理完的 HashMap。先往堆里放 100 个元素。随后的每个单词，若其频次大于堆顶元素的频次，则弹出堆顶，将新单词压入堆。\n4.逆序输出： **得到 Top 100。**最终堆里剩下的 100 个元素就是全局频次最高的单词。将它们依次弹出并逆序排列，即可得到 Top 100 的结果。\n2. 现代 Java 21+ 实现示例 利用现代 Java 的流式处理和并发特性，可以写出非常优雅且内存安全的代码：\nJava\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 import java.io.BufferedReader; import java.io.FileReader; import java.io.IOException; import java.util.*; import java.util.regex.Matcher; import java.util.regex.Pattern; public class TopWords { public static void main(String[] args) { String filePath = \u0026#34;large_file.txt\u0026#34;; Map\u0026lt;String, Long\u0026gt; wordCounts = new HashMap\u0026lt;\u0026gt;(1024 * 1024); // 预估初始容量减少扩容 Pattern pattern = Pattern.compile(\u0026#34;[a-zA-Z]+\u0026#34;); // 仅匹配英文字母 // 1. 流式读取与计数 try (BufferedReader reader = new BufferedReader(new FileReader(filePath), 8 * 1024 * 1024)) { // 8MB Buffer String line; while ((line = reader.readLine()) != null) { Matcher matcher = pattern.matcher(line); while (matcher.find()) { String word = matcher.group().toLowerCase(); // 统一转小写 wordCounts.put(word, wordCounts.getOrDefault(word, 0L) + 1); } } } catch (IOException e) { e.printStackTrace(); } // 2. 最小堆获取 Top 100 PriorityQueue\u0026lt;Map.Entry\u0026lt;String, Long\u0026gt;\u0026gt; minHeap = new PriorityQueue\u0026lt;\u0026gt;( 100, Comparator.comparingLong(Map.Entry::getValue) ); for (Map.Entry\u0026lt;String, Long\u0026gt; entry : wordCounts.entrySet()) { if (minHeap.size() \u0026lt; 100) { minHeap.add(entry); } else if (entry.getValue() \u0026gt; minHeap.peek().getValue()) { minHeap.poll(); minHeap.add(entry); } } // 3. 输出结果 List\u0026lt;Map.Entry\u0026lt;String, Long\u0026gt;\u0026gt; result = new ArrayList\u0026lt;\u0026gt;(minHeap); result.sort((e1, e2) -\u0026gt; Long.compare(e2.getValue(), e1.getValue())); // 降序排列 result.forEach(e -\u0026gt; System.out.println(e.getKey() + \u0026#34;: \u0026#34; + e.getValue())); } } 方案二：分治法 / 外部排序（在大内存受限或面对 200GB 文件时必用） 如果你的运行环境内存 极其严苛 （例如只有 256MB），或者文件后续会升级到 200GB 导致内存根本装不下独立的哈希表，这时候必须采用 分治法（MapReduce 思想） 。\n核心架构设计 1 2 3 4 5 6 7 8 9 10 11 12 13 [ 2GB 大文件 ] | +-------------+-------------+ (步骤 1: 内存不放大的 Hash 分流) | | | [小文件 0] [小文件 1] ... [小文件 63] | | | (内存 Map) (内存 Map) (内存 Map) (步骤 2: 分别统计各小文件的 Top 100) | | | [Top 100] [Top 100] ... [Top 100] \\ | / +------------+------------+ (步骤 3: 汇总到总的最小堆，滤出全局 Top 100) | [ 全局 Top 100 ] 详细落地步骤 Hash 拆分（分流） ： 流式读取大文件，对获取到的每个单词，计算其哈希值（如 Math.abs(word.hashCode()) % 64）。 根据哈希值，将单词流式写入到对应的 64 个小文件中（每个小文件大约几M到几十M）。 关键点 ：相同的单词必然会被分到同一个小文件中。 局部统计 ： 依次把这 64 个小文件读入内存。因为相同的单词都在同一个文件里，我们此时可以放心地用一个小 HashMap 统计当前小文件的单词频次，并用最小堆挑出该文件的 Top 100。 全局归并 ： 把 64 个小文件各自产生的 Top 100（总共 $64 \\times 100 = 6400$ 个单词）汇总到一个最终的最小堆中，筛选出最后的全局 Top 100。 方案三：生产环境的“降维打击”（命令行极速流） 在实际 Linux 服务器上，如果你不需要写进业务代码，只是为了排查日志或紧急分析， 永远不要手写代码 。利用 Linux 管道符组合原生命令，它们是由 C 语言编写、经过几十年极致优化的流式工具，速度通常比自己写的代码快得多：\nBash\n1 cat large_file.txt | tr -cs \u0026#39;a-zA-Z\u0026#39; \u0026#39;[\\n*]\u0026#39; | tr \u0026#39;A-Z\u0026#39; \u0026#39;a-z\u0026#39; | sort | uniq -c | sort -nr | head -n 100 命令拆解： tr -cs 'a-zA-Z' '[\\n*]'：把所有非字母的字符（空格、标点）全部替换为换行符，让单词一行一个。 tr 'A-Z' 'a-z'：大写转小写。 sort：将单词排序（为 uniq 做准备）。 uniq -c：去重并统计每个单词出现的频次。 sort -nr：按照频次（-n 代表数值，-r 代表倒序）从大到小排序。 head -n 100：只取前 100 行。 💡 生产环境小贴士 ：如果单机 2GB， 方案一 （直接上内存 Map 配合 Buffer）最快最省事，整体开发成本最低。\n给第三方提供接口要注意哪些？ 1.遵循restful规范，数据格式统一，可以优雅降级，完善文档和sdk简化集成\n2.安全性，敏感信息，校验和防护，限流策略\n3.性能，缓存和异步\n4.日志记录，结构化的日志，外部集成，敏感信息过滤\n接口防刷 1.限流，分布式限流：redis+lua脚本实现原子化计数器，令牌桶算法\n2.设备指纹识别\n3.请求签名\n4.黑名单机制\n工作流引擎flowable+drools规则引擎 触发节点： 当提交流程至“审批路由”节点时，工作流引擎将流程变量（如申请人、金额）封装为 Drools 的 Fact 对象。 规则匹配： Drools 执行预设的 DRL 规则文件或决策表（Decision Table），动态计算出目标审批人列表或审批节点。 流程流转： Drools 将计算结果（如审批人 ID：approverId=123）返回给工作流引擎。 分配任务： 工作流引擎根据返回的结果，精准将任务推送给指定审批人。 “在实际的 Web 项目中，如果把业务规则（如审批金额门槛、风控评级）直接写在 Flowable 流程图的网关表达式里，会存在严重的架构缺陷：\n规则一变，流程必变 ：改一个审批金额就要重新发布流程定义，导致历史正在运行的流程实例出现版本兼容问题。 职责不分离 ：Flowable 的核心职责是 组织架构的横向流转 （谁来审批），而 Drools 的核心职责是 业务指标的纵向判定 （该不该审、去哪审）。 我们公司的做法是： Flowable 负责骨架，Drools 负责灵魂 。 用 Flowable 统一管理审批链路（Service Task -\u0026gt; Exclusive Gateway），而在 Service Task 节点中调用 Drools。一旦财务把‘总监审批门槛’从 1 万改成了 5 万，我们 只需要动态更新数据库里的 Drools .drl 文本 ，流程图和 Java 代码完全不需要动，做到了真正的‘零重启、零重新发布流程’，极大提升了业务的敏捷度。”\n","date":"2020-04-06T00:00:00Z","permalink":"/p/chang-jing-mian-shi/","title":"场景面试"},{"content":"§2.2.5 AQS原理简述 考察意图：理解AQS作为JUC基石的原理深度，而非泛泛而谈\u0026quot;抽象队列同步器\u0026quot;。\n回答样板：\nAQS（AbstractQueuedSynchronizer）是JUC锁和同步器（ReentrantLock、CountDownLatch、Semaphore等）的基石。\n核心三要素：\nvolatile int state——同步状态（独占模式0表示未锁，大于0表示已锁；共享模式表示剩余资源数） CLH变体双向队列——等待获取锁的线程队列，每个节点通过CAS和前驱节点的waitStatus状态协作 模板方法模式——子类实现tryAcquire/tryRelease等抽象方法决定同步语义，AQS内部维护队列和状态流转 独占模式获取锁流程：tryAcquire尝试获取 → 成功则返回 → 失败则将当前线程包装成Node加入等待队列 → 在队列中自旋或阻塞等待前驱节点唤醒。\n项目层面：日常使用多是读API层面（直接用ReentrantLock、CountDownLatch），没有深入到定制AQS同步器那个层面。但对AQS的CLH队列原理、state状态机有清晰理解。\n陷阱提示：说\u0026quot;精通AQS\u0026quot;结果说不出CLH队列原理；泛泛而谈\u0026quot;抽象队列同步器\u0026quot;没深度。\n备选话术：我日常使用线程池处理异步任务（如设备数据批量写入），对JUC核心类有实操经验。但AQS源码实现细节或无锁编程（CAS/Unsafe）不是日常写代码的层面，坦诚需要查资料。\n","date":"2018-03-06T00:00:00Z","permalink":"/p/13-aqs-yuan-li-jian-shu/","title":"AQS原理简述"},{"content":"§2.1.8 JDK LTS版本新特性（8 / 11 / 17 / 21） 考察意图：是否跟得上Java生态演进，知道每个LTS版本的关键变化和升级价值。\n回答样板：\nOracle 2017年宣布6个月发布周期（3月/9月），每2年一个LTS（长期支持版本）。截至目前四个主要LTS：\nJDK 8（2014.03）——革命性版本，目前仍有海量存量：\n特性 说明 实际价值 Lambda + Stream API 函数式编程，集合操作的声明式写法 Java 8的核心卖点，改变了Java编程范式 Optional类 优雅处理null，避免NPE 链式调用，配合orElse/orElseGet兜底 新的日期时间API java.time包（LocalDate/LocalDateTime/Instant） 线程安全+不可变对象，替代joda-time 接口默认方法 default关键字，接口可提供默认实现 不破坏实现类的情况下给接口加新方法 Metaspace替代PermGen 方法区移到本地内存 不再OOM: PermGen space CompletableFuture 异步编程组合能力 thenApply/thenCompose/thenCombine编排异步任务 JDK 11（2018.09 LTS）——模块化成熟、HTTP Client标准化：\n特性 说明 实际价值 Java Platform Module System 从JDK 9开始的模块化（Project Jigsaw），JDK 11达稳定 拆大单体应用、控制可访问性、module-info.java声明依赖（团队小不一定需要） HttpClient标准化 java.net.http.HttpClient替代第三方库 原生支持HTTP/2、WebSocket、异步请求 ZGC实验性 亚毫秒停顿GC JDK 11首次引入（实验性），JDK 15生产可用 Epsilon GC 只分配内存不回收的\u0026quot;假GC\u0026quot; 性能基准测试、短生命周期应用 Flight Recorder开源 JFR性能分析工具（原商业版） 零性能损耗的生产环境Profiling var局部变量推导 var list = new ArrayList\u0026lt;String\u0026gt;() 减少样板代码（从JDK 10开始） 移除内容 Java EE模块（JAXB/JAX-WS）被移除 迁移要注意：旧项目升级要额外加JAXB等依赖 收费政策 Oracle JDK 11起商用收费 OpenJDK免费，以此版本为分界线 JDK 17（2021.09 LTS）——当前主流LTS，G1/GC全面成熟：\n特性 说明 实际价值 Sealed Classes sealed class Shape permits Circle, Rectangle 受控继承，编译期保证子类列表，增强类型安全 Pattern Matching for switch switch支持类型匹配和解构（预览） 减少instanceof+强转的模板代码 Record类 record Point(int x, int y){} 一行搞定数据载体 消除getter/setter/equals/hashCode/toString（从JDK 14正式） Text Blocks \u0026quot;\u0026quot;\u0026quot;...\u0026quot;\u0026quot;\u0026quot; 多行文本块 SQL/JSON/HTML不再用string拼接（从JDK 15正式） 增强型伪随机数生成器 新接口+新算法（LXM系列） 高性能多线程随机数生成 Foreign Function \u0026amp; Memory API 替代JNI的现代方案（孵化） 安全高效调用C/C++代码 macOS AArch64支持 原生支持Apple M1/M2芯片 无需Rosetta转译 G1成为事实标准 多年打磨，大堆场景表现稳定 多数项目升级JDK 17的直接理由 JDK 21（2023.09 LTS）——最新LTS，虚拟线程时代来临：\n特性 说明 实际价值 Virtual Threads（虚拟线程） Project Loom正式落地 JDK 21最大卖点——数百万轻量级线程，阻塞操作几乎免费。Spring Boot 3.2已集成 Pattern Matching for switch（正式） switch模式匹配结束预览，正式GA 类型安全+解构式编程 Record Patterns 嵌套解构Record对象 if (p instanceof Point(int x, int y) \u0026amp;\u0026amp; x \u0026gt; 0) Sequenced Collections 有序集合统一接口 getFirst()/getLast()/addFirst()/addLast() List/Deque/SortedSet有统一的操作有序元素的API String Templates（预览） STR.\u0026quot;Hello \\{name}\u0026quot; 字符串模板 替代String.format和字符串拼接 Scoped Values（预览） 线程间共享不可变数据的新方案 替代ThreadLocal部分场景（轻量、明确生命周期） Structured Concurrency（预览） 结构化并发，StructuredTaskScope 把多个并发子任务作为一个\u0026quot;工作单元\u0026quot;管理 ZGC正式支持分代 ZGC从单代发展为分代回收 进一步提升吞吐量 Key Encapsulation Mechanism API 抗量子加密（PQC）支持 面向未来的安全 LTS升级路径建议：\n1 2 3 JDK 8 ──→ JDK 11（稳妥保守派，最小迁移成本） ──→ JDK 17（推荐跳板，G1成熟+Record+密封类） ──→ JDK 21（激进尝鲜派，虚拟线程巨大诱惑） 实际项目选型经验：\n目前主力在JDK 8上，原因是客户本地部署环境限制——很多客户只有JDK 8的授权或安全基线认证。升级到JDK 11/17的最大阻力不是技术（代码兼容性很好），而是客户的环境审批流程。但如果是新项目或云端部署，我会直接选JDK 17——Record+Sealed Classes提升代码表达力、G1比JDK 8的Parallel更稳定、长期支持到2029年。如果场景有高并发连接需求（比如Netty做数万设备同时接入），那我就选JDK 21——虚拟线程让一个TCP连接一个虚拟线程成为可能，代码模型从异步回调退化为同步写法但性能不降。\n陷阱提示：把var说成\u0026quot;和JS一样动态类型\u0026quot;（var是编译期类型推断，运行时强类型）；不知道JDK 11 Oracle JDK开始商用收费；不知道ZGC不同版本的状态（实验性/生产可用/分代）；把Record和Lombok @Data简单等同（Record是不可变对象，Lombok是可变）；不知道虚拟线程和平台线程的本质区别（虚拟线程由JVM调度，不绑定OS线程）。\n","date":"2018-03-06T00:00:00Z","permalink":"/p/08-jdk-lts-xin-te-xing/","title":"JDK LTS版本新特性（8 / 11 / 17 / 21）"},{"content":"§2.1.4 JVM调优常用参数 考察意图：能否根据实际场景选择合适的JVM参数，而非无脑复制粘贴。\n回答样板：\n基础内存参数：\n参数 含义 常见设置 -Xms / -Xmx 初始/最大堆大小 建议设为相同值，避免堆动态扩缩带来的GC抖动。4G服务通常 -Xms4g -Xmx4g -Xss 线程栈大小 默认1MB。线程数多且调用栈浅可缩小（512k），递归深可加大 -XX:NewRatio 老年代:新生代比例 默认2（Old=堆的2/3，Young=1/3）。高并发短命对象可调为1 -XX:SurvivorRatio Eden:Survivor比例 默认8（Eden:S0:S1=8:1:1）。大多数场景不需改 -XX:MaxTenuringThreshold 晋升老年代年龄阈值 默认15（CMS默认6）。值小则对象快速晋升但可能过早填满老年代 -XX:MetaspaceSize / -XX:MaxMetaspaceSize 元空间初始/最大大小 默认无上限（受物理内存限制）。动态生成类多的场景建议设上限防泄漏。典型256m-512m GC日志参数：\n1 2 3 4 5 6 7 8 # JDK 8 经典三件套 -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/path/to/gc.log -XX:+PrintHeapAtGC # GC前后打印堆快照（排查内存泄漏利器） -XX:+PrintTenuringDistribution # 打印各年龄段的存活对象分布 # JDK 9+ 统一日志 -Xlog:gc*=info:file=/path/to/gc.log:time,level,tags:filecount=10,filesize=100M # gc* 表示所有GC相关日志，info级别，滚动10个文件每个100MB OOM排查必开：\n参数 作用 -XX:+HeapDumpOnOutOfMemoryError OOM时自动dump堆快照，生产环境必须开 -XX:HeapDumpPath=/path/to/dumps dump文件路径，防止撑爆根目录 -XX:OnOutOfMemoryError=\u0026quot;kill -9 %p\u0026quot; OOM时执行自定义命令（注意安全隐患） G1调优参数：\n参数 含义 建议 -XX:MaxGCPauseMillis 期望最大停顿时间 默认200ms，不要设太低（比如10ms）——G1达不到会疯狂GC反而性能下降。服务端通常50-200ms -XX:G1HeapRegionSize Region大小 默认堆/2048，取值1/2/4/8/16/32M。大对象多可调大 -XX:ConcGCThreads 并发GC线程数 默认≈CPU核数的1/4。CPU资源紧张时减半 -XX:InitiatingHeapOccupancyPercent 触发并发标记的堆占用阈值 默认45%。堆占用达此值触发并发标记周期。值设太低频繁GC浪费CPU，太高预留不够触发Full GC 真实配置示例——安全生产平台（JDK 8, 4核8G）：\n1 2 3 4 5 6 7 8 9 -Xms4g -Xmx4g -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:G1HeapRegionSize=4m -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/logs/dumps -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/data/logs/gc-%t.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=50M 陷阱提示：把线上配置直接复制粘贴但说不清每个参数的业务取舍原因；设 MaxGCPauseMillis=10显得不专业；不知道生产环境必须开HeapDumpOnOutOfMemoryError。\n","date":"2018-03-06T00:00:00Z","permalink":"/p/04-jvm-tiao-you-chang-yong-can-shu/","title":"JVM调优常用参数"},{"content":"§2.1.5 JVM调优工具实战 考察意图：能否独立的在生产环境排查问题，使用合适的工具定位根因。\n回答样板：\nArthas——线上诊断神器：\n阿里开源的Java诊断工具，零侵入，直接attach到运行中的Java进程，线上排查首选。\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 # 启动 java -jar arthas-boot.jar # 选择目标Java进程即可 # 最常用命令 dashboard # 实时看板：线程/内存/GC/CPU thread -n 5 # CPU最高的5个线程 thread -b # 找出死锁 jad com.xx.MyService # 反编译已加载的类，验证线上版本 watch com.xx.MyService myMethod \u0026#34;{params,returnObj,throwExp}\u0026#34; -x 3 # 监控方法入参/出参/异常 trace com.xx.MyService myMethod -n 5 # 追踪方法调用链路，找出哪个子步骤耗时最长 tt -t com.xx.MyService myMethod # 记录方法调用（TimeTunnel），支持重放 vmoption # 查看JVM参数 vmtool --action getInstances -c com.xx.MyClass --limit 10 # 获取堆中某类实例 monitor -c 5 com.xx.MyService myMethod # 监控方法调用次数/成功率/平均耗时 实际场景：一次线上接口变慢，用Arthas的trace一追踪，发现是下游规则引擎的Drools session创建占了80%耗时——KieSession没做池化每次new一个。加了KieSession对象池后恢复。\nJDK自带工具——四件套：\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 # jps —— 列出Java进程 jps -lv # 列出所有Java进程，显示JVM参数和main类 # jstat —— JVM统计监控（实时看GC） jstat -gcutil PID 1000 10 # 每秒打印一次GC统计，共10次 # 输出关键列：S0/S1(Eden+Survivor使用率), E(eden), O(old), M(metaspace), YGC/YGCT(youngGC次数/耗时), FGC/FGCT(fullGC) # 解读：FGC频繁 + FGCT高 → 老年代不足或内存泄漏 # E接近100%然后骤降 → 正常Minor GC # O持续增长不降 → 内存泄漏信号 # jmap —— 堆内存分析 jmap -heap PID # 堆内存概览（各区域大小和使用率） jmap -histo:live PID | head -20 # 堆中存活对象统计（top 20，强制执行一次Full GC） jmap -dump:format=b,file=heap.hprof PID # 堆dump（生产慎用，会STW） # jstack —— 线程堆栈分析 jstack PID \u0026gt; thread.log # 打印线程堆栈 jstack -l PID # 额外打印锁信息 # grep查找：BLOCKED（锁等待）/ WAITING（等待唤醒）/ TIMED_WAITING（超时等待）/ RUNNABLE（正在执行） # 看线程名：如果全是http-nio-xxx-WAITING → 数据库或下游服务慢 MAT（Memory Analyzer Tool）——堆dump分析：\n1 2 3 4 5 6 # 先用 jmap dump 堆快照，然后用MAT打开分析 # MAT直接点\u0026#34;Leak Suspects Report\u0026#34; → 自动分析内存泄漏嫌疑 # 核心操作： # 1. Histogram：按类统计对象数量和内存占用，找大对象 # 2. Dominator Tree：支配树——最大的内存持有者 # 3. Path to GC Roots：某个对象为什么没被回收（引用链追溯到GC Root） 实际场景：OOM排查，MAT打开dump→ Dominator Tree发现HashMap占3.2GB→ Path to GC Roots找到是定时任务的全量缓存→改成分页+本地缓存解决。\njinfo——查看/修改JVM运行时参数：\n1 2 jinfo -flags PID # 查看所有参数（包括默认值） jinfo -flag +PrintGC PID # 运行时动态开启GC日志（部分参数支持动态修改） 生产环境排查最佳路径：\n遇到CPU飙升 → Arthas dashboard + thread -n 5 → 定位到具体线程 → jad反编译验证 → 改代码 遇到内存泄漏 → jstat -gcutil观察O区持续增长 → jmap -dump → MAT分析Dominator Tree → Path to GC Roots → 改代码 遇到死锁 → jstack -l → 搜DEADLOCK → 或Arthas thread -b 遇到接口变慢 → Arthas trace → 定位最耗时的子调用 → 深入分析 陷阱提示：只会用jps/jstat但说不清每列含义；线上 jmap -dump不提醒STW风险；不知道Arthas的attach机制（VirtualMachine.attach不需要Agent）。\n","date":"2018-03-06T00:00:00Z","permalink":"/p/05-jvm-tiao-you-gong-ju-shi-zhan/","title":"JVM调优工具实战"},{"content":"§2.1.6 JVM调优实战案例 考察意图：验证完整的排查→定位→解决→验证闭环能力。\n案例一：定时任务导致Full GC：\n危废平台上线后，每周固定时间接口响应从200ms飙升到5秒以上。排查：jstat -gcutil看发现老年代每周末凌晨突增 → jmap -dump堆内存用MAT分析 → Dominator Tree发现HashMap缓了几百万条危废联单数据 → 根因是定时任务没做分页，一次load全量数据。解决方案不是调JVM参数，而是改代码——Caffeine本地缓存（最大条目+过期时间），定时任务改分批。改完后Full GC停顿从1.2秒降到100ms以内。教训：JVM调优很多时候改代码比改参数更有效。\n案例二：Metaspace溢出：\n生产环境切流量后运行12小时左右突然 OOM: Metaspace。排查：jstat -gcutil看MU（Metaspace使用率）接近100% → jmap -clstats看加载的类数量异常高（正常几千，它几百万）→ Arthas vmtool查看发现大量 com.sun.proxy.$ProxyXXX类 → 定位到Groovy脚本引擎每次执行规则都 new GroovyClassLoader()但没关 → ClassLoader泄漏导致反复加载同类→ Metaspace撑爆。解决：GroovyClassLoader改单例复用，加 -XX:MaxMetaspaceSize=256m兜底限流。\n案例三：G1停顿时间优化：\nG1 GC后P99延迟偶尔飙到800ms。排查GC日志发现Mixed GC的Cleanup阶段耗时400ms——老年代Region中大对象过多。-XX:G1HeapRegionSize从2MB调到4MB（让大对象进Humongous Region而非普通Old Region），加上 -XX:+ParallelRefProcEnabled并行处理Reference对象，-XX:MaxGCPauseMillis=100让G1自动收紧回收范围。优化后P99压到300ms以内。\n陷阱提示：只讲成功案例不讲失败教训；编造数据（面试官可能现场让你画内存布局图）。\n","date":"2018-03-06T00:00:00Z","permalink":"/p/06-jvm-tiao-you-shi-zhan-an-li/","title":"JVM调优实战案例"},{"content":"§2.1.7 JVM类型对比（HotSpot / OpenJ9 / GraalVM） 考察意图：是否了解JVM生态的多样性，能根据场景推荐合适的JVM实现。\n回答样板：\n主流JVM实现有三个阵营：\nHotSpot VM——Oracle/OpenJDK默认，绝对主流\n市场份额：Java服务端90%+在用 核心优势：**C2编译器（Server Compiler）**做了二十多年极致优化，逃逸分析、内联、循环优化极其成熟；G1/ZGC等现代回收器最先落地；生态最完整 JDK 8起HotSpot与JRockit合并，吸收了JRockit的Mission Control、Flight Recorder（JFR）等运维工具 劣势：启动慢、内存占用高——Spring Boot应用空跑也要200MB+堆。不适合短生命周期场景（Serverless、FaaS） OpenJ9（Eclipse OpenJ9）——IBM捐献，低内存场景\n前身是IBM J9 VM，2017年捐给Eclipse基金会 核心优势：极低内存占用——同等应用比HotSpot少30-50%内存；启动速度快；Shared Classes Cache（SCC）——AOT编译缓存，多次启动复用编译结果 垃圾回收：GenCon（分代并发，类似G1）+ Balanced（针对大堆）+ Metronome（实时GC，可配置停顿上限） 劣势：生态和工具链不如HotSpot完善，部分框架兼容性问题；G1/ZGC等效方案不如HotSpot成熟 适用场景：云原生/Serverless（启动快、内存省）、微服务容器化部署（每个Pod省200MB很可观）、嵌入式设备 GraalVM——多语言+AOT编译\nOracle实验室项目，定位是\u0026quot;通用虚拟机\u0026quot;——不止跑Java，还能跑JavaScript、Python、Ruby、R、WASM 两大杀手级特性： Native Image（AOT编译）：将Java应用编译为独立二进制，毫秒级启动、内存占用几十MB，非常适合Serverless和容器化。Spring Boot 3.0+官方支持GraalVM Native Image Truffle框架：多语言互调用，Java代码直接调Python/JS函数，零JNI开销 两种模式：Community Edition（免费，Native Image支持有限）+ Enterprise Edition（收费，Native Image+PGO优化+多语言商业支持） 劣势：AOT编译限制——限制反射/动态代理/动态类加载（需要配置 reflect-config.json等元数据）；编译时间长（小项目几分钟，大项目几十分钟）；闭包分析可能漏掉运行时动态行为导致编译失败 适用场景：Serverless/FaaS（毫秒级冷启动）、CLI工具、嵌入式、微服务容器镜像瘦身 场景选型速览：\n场景 推荐JVM 原因 传统服务端/企业应用 HotSpot 生态成熟、性能最稳定、GC方案最丰富 云原生/容器化微服务 OpenJ9 或 GraalVM 内存省、启动快、镜像小 Serverless/FaaS GraalVM Native Image 毫秒启动、极低内存 多语言混合项目 GraalVM Truffle Java+Python/JS/R互调 嵌入式/IoT OpenJ9 内存占用可控 实时响应（金融/交易） HotSpot + ZGC 亚毫秒停顿 陷阱提示：只知道HotSpot不知道有其他JVM实现；把GraalVM说成\u0026quot;就是编译成二进制的\u0026quot;忽略了多语言和Truffle；不知道GraalVM Native Image的限制（反射配置、编译时间）。\n","date":"2018-03-06T00:00:00Z","permalink":"/p/07-jvm-lei-xing-dui-bi/","title":"JVM类型对比（HotSpot / OpenJ9 / GraalVM）"},{"content":"§2.1.1 JVM内存模型 考察意图：是否理解各内存区域的职责、存储内容、以及OOM的发生场景。\n回答样板：\nJVM运行时数据区分为线程私有和线程共享两大类，共5个核心区域：\n区域 共享性 存储内容 OOM场景 程序计数器 线程私有 当前线程执行的字节码行号指示器 唯一不会OOM的区域 虚拟机栈 线程私有 栈帧（局部变量表+操作数栈+动态链接+返回地址） 线程过多或递归过深：StackOverflowError 本地方法栈 线程私有 Native方法的栈帧 与虚拟机栈类似 堆（Heap） 线程共享 对象实例、数组 对象过多且GC无法回收：java.lang.OutOfMemoryError: Java heap space 方法区（元空间） 线程共享 类元数据、静态变量、常量池、JIT编译缓存 动态生成类过多或常量池溢出：OOM: Metaspace JDK 8关键变化——永久代→元空间：\nJDK 7及之前，方法区用永久代（PermGen）实现，属于JVM堆内存的一部分，受-XX:MaxPermSize限制。JDK 8移除了永久代，改用本地内存中的元空间（Metaspace），默认只受物理内存限制。好处：之前永久代大小难以预估（加载的类数量不确定），经常导致OOM: PermGen space。改用元空间后，类元数据放在堆外的本地内存，容量弹性更大。但风险是——如果不设-XX:MaxMetaspaceSize，动态类加载失控会吃光物理内存。\n堆内存分代结构：\n1 2 3 4 5 6 7 8 9 10 11 12 ┌───────────────────────────────────────────┐ │ 堆 (Heap) │ ├─────────────────┬─────────────────────────┤ │ 新生代(Young) │ 老年代(Old) │ │ ┌────┬────┬───┐│ │ │ │Eden│ S0 │ S1││ │ │ │ 8 │ 1 │ 1 ││ │ │ └────┴────┴───┘│ │ │ 默认比例 8:1:1 │ │ ├─────────────────┴─────────────────────────┤ │ 新生代:老年代 ≈ 1:2 (默认 NewRatio=2) │ └───────────────────────────────────────────┘ 新生代：新创建的对象。Eden区（80%）+ Survivor 0（10%）+ Survivor 1（10%） 老年代：长期存活对象。经历多次Minor GC仍存活的对象晋升至此 对象晋升流程：Eden分配 → 首次Minor GC存活进S区 → 每次Minor GC存活Age+1 → Age达到MaxTenuringThreshold（默认15）→ 晋升老年代。动态年龄判定：S区中同龄对象总大小超过S区50%时，该年龄及以上对象直接晋升 为什么需要两个Survivor区？ 解决内存碎片化——每次Minor GC，将Eden+From Survivor存活对象copy到To Survivor，然后清空Eden和From，From和To角色互换。始终保持一块Survivor为空，避免碎片化。这就是复制算法在新生代的落地。\n陷阱提示：说不清各个区域存什么；把方法区和元空间等同（元空间是实现，方法区是规范）；不知道永久代→元空间的JDK 8变化。\n","date":"2018-03-06T00:00:00Z","permalink":"/p/01-jvm-nei-cun-mo-xing/","title":"JVM内存模型"},{"content":"§2.2.1 synchronized vs Lock 考察意图：能否理解synchronized和Lock的原理差异和选型依据。\n回答样板：\nsynchronized是JVM内置锁，由monitorenter/monitorexit字节码指令实现，自动释放锁，非公平锁，适合简单同步场景。\nLock（ReentrantLock）是JDK API级别的锁，通过AQS（AbstractQueuedSynchronizer）实现，必须手动释放（finally中unlock），支持公平锁、可中断获取锁、尝试获取锁超时、多条件变量（Condition），适合复杂同步场景。\nJDK 6以后synchronized做了锁升级优化——偏向锁 → 轻量级锁 → 重量级锁，单线程竞争场景下性能差距不大。\n追问预判：\n追问：\u0026ldquo;synchronized的锁升级过程具体是怎样的？\u0026rdquo;\n无锁状态 → 偏向锁：Mark Word存储线程ID，同一线程重入不走CAS，直接判断线程ID一致 → 轻量级锁：多个线程交替竞争时，自旋CAS尝试获取锁，Mark Word存锁记录指针 → 重量级锁：自旋超过阈值（默认10次或自适应），升级为OS互斥量，线程阻塞挂起。本质是空间换时间——偏向锁和轻量级锁尽力减少内核态切换，重量级锁是兜底方案。\n陷阱提示：说不清锁升级过程；以为synchronized一直是重量级锁。\n","date":"2018-03-06T00:00:00Z","permalink":"/p/09-synchronized-yu-lock/","title":"synchronized vs Lock"},{"content":"§2.2.3 ThreadLocal原理与内存泄漏 考察意图：是否理解ThreadLocal的实现原理、内存泄漏成因及规避方式。\n回答样板：\n每个Thread内部维护一个ThreadLocalMap，key是ThreadLocal实例的弱引用（WeakReference），value是线程持有的值。\n内存泄漏原因：在线程池场景下线程复用，ThreadLocal使用完没有调用remove()时——key（ThreadLocal实例）会被GC回收（弱引用特点），但value的强引用链依然存在（Thread → ThreadLocalMap → Entry → value），导致value无法被回收，造成内存泄漏。\n规范：ThreadLocal使用完必须在finally块中调用remove()。\n1 2 3 4 5 6 7 ThreadLocal\u0026lt;Object\u0026gt; tl = new ThreadLocal\u0026lt;\u0026gt;(); try { tl.set(value); // 业务逻辑 } finally { tl.remove(); } 追问预判：\n追问：\u0026ldquo;为什么ThreadLocalMap的key要设计成弱引用？\u0026rdquo;\n设计为弱引用的目的是：当ThreadLocal对象不再被外部强引用时（即使用方不再需要它了），GC可以回收ThreadLocal实例，使得对应的Entry（key=null）成为无效条目。下次ThreadLocalMap调用set/get/remove时会主动清理这些key为null的Entry。如果没有这一层弱引用设计，即使外部不再使用ThreadLocal，Entry和value也会一直存活，导致更严重的内存泄漏。\n陷阱提示：答不出弱引用设计意图；只知道\u0026quot;用ThreadLocal存用户信息\u0026quot;但说不清泄漏原理。\n","date":"2018-03-06T00:00:00Z","permalink":"/p/11-threadlocal-yu-nei-cun-xie-lou/","title":"ThreadLocal原理与内存泄漏"},{"content":"§2.2.2 volatile深入 考察意图：volatile是面试高频基础题。初级答\u0026quot;保证可见性+禁止重排序\u0026quot;，中极答内存屏障语义，高级能讲出实际项目中用它解决过什么并发bug。\n一、volatile的两个核心作用（基础层，必须熟练）\n保证可见性：一个线程修改volatile变量后，其他线程立即可见。底层通过lock前缀指令触发缓存一致性协议（MESI），写变量时强制将缓存行写回主存并使其他CPU核的缓存行失效，其他核读时必须从主存重新加载。 禁止指令重排序：通过内存屏障限制编译器和CPU的指令重排。 不保证原子性：volatile int i; i++不是原子操作（读→改→写三步），多线程并发自增仍然会丢失更新。\n二、内存屏障详解（深度层，拉开分差）\n内存屏障是一条CPU指令，强制在其前后的内存操作满足特定的执行顺序。Java的volatile通过JMM定义的四类屏障保证了Happens-Before语义：\n屏障类型 指令 作用 LoadLoad Load1; LoadLoad; Load2 保证Load1在Load2之前完成（防止读操作重排到前面的读之前） StoreStore Store1; StoreStore; Store2 保证Store1在Store2之前完成（防止写操作重排到前面的写之前） LoadStore Load1; LoadStore; Store2 保证Load1在Store2之前完成（防止写操作重排到前面的读之前） StoreLoad Store1; StoreLoad; Load2 保证Store1在Load2之前完成（防止读操作重排到前面的写之前）最重的一类屏障，同时具备其他三种效果，通常由 mfence或 lock addl指令实现 volatile的内存屏障插入策略（JMM规范）：\n1 2 3 4 5 6 7 8 9 // volatile 写之前 StoreStore屏障 ← 保证volatile写之前的普通写操作对volatile写可见 // volatile 写 StoreLoad屏障 ← 保证volatile写之后的读操作不会被重排到volatile写之前 // volatile 读 LoadLoad屏障 ← 保证volatile读之后的普通读不会被重排到volatile读之前 // volatile 读 LoadStore屏障 ← 保证volatile读之后的普通写不会被重排到volatile读之前 为什么StoreLoad屏障最重？ 它要求在执行StoreLoad之后的任何Load指令前，Store缓冲区中的所有数据必须全部刷新到主存（或者至少对其他处理器可见）。在x86平台上，StoreLoad通常由 mfence（全屏障）或带lock前缀的指令实现，开销是普通指令的几十到上百倍。而LoadLoad、StoreStore、LoadStore在x86上通常无需额外指令——x86本身就是强内存模型（TSO），只允许Store-Load重排，其他重排在硬件层面已被禁止。所以在x86上，volatile的实际开销主要来自StoreLoad屏障。\n三、volatile实用场景（实战层，证明你真正用过）\n场景1：DCL（双重检查锁定）单例中的volatile（经典面试题）：\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 public class DeviceConfigManager { private static volatile DeviceConfigManager instance; public static DeviceConfigManager getInstance() { if (instance == null) { // ①第一次判空 synchronized (DeviceConfigManager.class) { if (instance == null) { // ②第二次判空 instance = new DeviceConfigManager(); // ③危险操作 } } } return instance; } } 为什么 instance必须用volatile？ 关键在第③行 new DeviceConfigManager()，这行代码在JVM层面分三步：\n1 2 3 1. memory = allocate() // 分配内存空间 2. ctorInstance(memory) // 初始化对象（执行构造方法） 3. instance = memory // 将引用指向分配的内存地址 如果不用volatile，步骤2和3可能被重排成1→3→2。线程A执行 new指令时刚好走到\u0026quot;分配内存→赋值引用\u0026quot;但构造方法还没执行完（对象是半成品），线程B走到第①行 if (instance == null)发现instance非空，直接返回了一个没有初始化完成的对象——后续使用时NullPointerException或数据错乱。volatile的StoreStore屏障保证了步骤2一定在步骤3之前完成（写前插入StoreStore：ctorInstance; StoreStore; instance=memory），线程B读instance时LoadLoad屏障保证读到的对象一定是初始化完毕的。\n场景2：线程安全的状态标志位（实战项目）：\n安全生产平台，定位计算引擎需要定期从配置文件刷新定位参数（基站坐标、校准因子）。这个开关被多个工作线程读取、被定时任务线程修改：\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 public class PositionEngine { // 不用volatile——reload线程改了flag，worker线程可能永远看不到 // private boolean configChanged = true; // 用volatile——reload线程一改，所有worker线程下次循环立即感知 private volatile boolean configChanged = true; private PositionConfig config; // 注意：config本身不是volatile // 定时任务线程每5分钟刷新一次 public void reloadConfig() { PositionConfig newConfig = loadFromRemote(); // ①先加载完整新配置 this.config = newConfig; // ②再赋值给config this.configChanged = false; // ③最后改标记 // volatile写前的StoreStore屏障保证①②③不会重排—— // 所以configChanged变为false时，config一定是新值 } // 几十个工作线程每秒调用数千次 public Position calcPosition(Device device) { if (configChanged) { // volatile读后的LoadLoad屏障保证—— // 读到configChanged=true时，config一定已经是最新赋值 updateLocalConfig(this.config); configChanged = false; } // ... 定位计算，用本地缓存的config，不走volatile，零开销 } } 这个场景volatile的妙处：配置变量 config本身不需要volatile修饰。volatile只用于 configChanged这个\u0026quot;开关变量\u0026quot;，利用volatile写前StoreStore屏障保证\u0026quot;先赋值config、再改标记\u0026quot;的写入顺序，利用volatile读后LoadLoad屏障保证\u0026quot;先读标记确认、再读config内容\u0026quot;的读取顺序。这种\u0026quot;volatile变量守卫普通变量\u0026quot;的模式比把所有变量都标volatile高效得多。\n场景3：安全发布（Safe Publication）：\n在物联平台设备接入时，每个设备连接对应的Handler需要持有设备基础信息。这个信息在主线程初始化，被NIO的Worker线程读取：\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 public class DeviceHandler { private volatile DeviceInfo deviceInfo; // 必须volatile // 主线程启动时调用一次 public void init(String deviceId) { DeviceInfo info = new DeviceInfo(deviceId); // ①构造完整对象 info.setProtocol(\u0026#34;modbus\u0026#34;); // ②设置所有属性 info.setLocation(\u0026#34;井下一区\u0026#34;); this.deviceInfo = info; // ③发布——volatile写 // StoreStore屏障：保证①②所有初始化在③赋值之前被所有线程可见 } // Netty Worker线程读取 public void onData(byte[] data) { DeviceInfo info = this.deviceInfo; if (info != null) { // LoadLoad屏障：读到的info对象一定是完整初始化的 String protocol = info.getProtocol(); // 必然返回\u0026#34;modbus\u0026#34;，不会是null } } } 如果没有volatile，Worker线程可能看到 deviceInfo非空（引用已赋值），但 info对象的内部属性还是初始值（构造函数未完整执行被重排），导致 getProtocol()返回null而NPE。\n陷阱提示：说\u0026quot;volatile能保证原子性\u0026quot;——致命错误（i++反例）；说\u0026quot;所有共享变量都需要volatile\u0026quot;——过于暴力，性能代价大；知道四种屏障名字但说不出各自阻止什么重排；不知道DCL单例为什么必须volatile（JDK 5之前volatile语义不够强，DCL有bug）；不知道x86只需要StoreLoad屏障（LoadLoad/StoreStore/StoreLoad在x86上硬件已保证，伪共享除外）。\n","date":"2018-03-06T00:00:00Z","permalink":"/p/10-volatile-shen-ru/","title":"volatile深入"},{"content":"§2.1.3 各JDK版本垃圾回收器 考察意图：了解不同回收器的设计目标、适用场景和演进历史，能根据业务场景推荐合适的回收器。\n回答样板：\nJDK发展史就是\u0026quot;降低GC停顿时间\u0026quot;的演进史——从秒级到毫秒级到亚毫秒级：\n回收器 作用区域 算法 停顿特点 适用场景 JDK版本 Serial 新生代 标记-复制 单线程STW，几十~几百ms 单核、Client模式、几百MB堆 1.3+ Serial Old 老年代 标记-整理 单线程STW 配合Serial 1.3+ Parallel Scavenge 新生代 标记-复制 多线程STW，吞吐量优先 批处理、科学计算 1.4+ Parallel Old 老年代 标记-整理 多线程STW 配合Parallel Scavenge 1.6+ CMS 老年代 标记-清除 并发低停顿，最耗时的并发标记和并发清除阶段与用户线程并发 互联网Web应用（响应时间优先） 1.5-14 G1 整堆 标记-整理+复制 可预测停顿，Region化 JDK 9默认、大堆(\u0026gt;4G)、对停顿有要求的服务端 7u4+ ZGC 整堆 染色指针+并发整理 亚毫秒级停顿(\u0026lt;1ms) 超大堆(\u0026gt;16G)、极致低延迟 11+(实验) / 15+(生产) Shenandoah 整堆 并发复制+Brooks转发指针 低停顿 超大堆低延迟 12+(Red Hat主导) CMS（Concurrent Mark Sweep）——并发低停顿的先驱：\n四个阶段：①初始标记（STW，扫描GC Roots直接引用，极快）→ ②并发标记（与用户线程并发，从GC Roots遍历整个对象图，最耗时）→ ③重新标记（STW，处理并发标记期间变动的引用，修正标记结果）→ ④并发清除（与用户线程并发）。\nCMS的致命缺陷：\n内存碎片——标记-清除不整理，碎片严重时触发Serial Old全堆整理（单线程，停顿秒级） 浮动垃圾——并发标记和清除期间用户线程产生的垃圾，只能等下次GC处理。需预留老年代空间给这些浮动垃圾，否则触发Concurrent Mode Failure，降级为Serial Old JDK 14已废弃，JDK 15移除 G1（Garbage First）——JDK 9+默认，划时代的分区回收器：\n核心创新——将堆划分为等大小的Region（默认2048个，每个1~32MB），不再按物理分代。Region分为Eden、Survivor、Old、Humongous四种类型。\nG1的混合GC（Mixed GC）：不止回收新生代，还回收部分收益最高的老年代Region——每次回收\u0026quot;垃圾最多的Region\u0026quot;，这也是Garbage First名字的来源。\n关键机制：\nSATB（Snapshot At The Beginning）：并发标记开始时的对象图快照，保证标记正确性 RSet（Remembered Set）：每个Region维护其他Region指向本Region的引用，避免全堆扫描 可预测停顿：-XX:MaxGCPauseMillis设定目标（默认200ms），G1自动调整回收Region数量 Humongous对象：超过Region大小50%的对象放入Humongous Region。大量短命大对象会引发频繁GC——需要调整Region大小或优化应用代码 G1 vs CMS直观对比：\nG1无内存碎片（标记-复制+整理），CMS有碎片问题 G1停顿可预测可控，CMS的不确定性大 G1的吞吐量略低于CMS（RSet维护开销），但换来更稳定的延迟 ZGC（Z Garbage Collector）——亚毫秒级停顿的终极方案：\n核心创新——染色指针（Colored Pointer）：在64位指针中嵌入GC状态信息（共4位：Finalizable/Remapped/Marked 1/Marked 0），标记阶段不修改对象头，只修改指针颜色。结合读屏障（Load Barrier）实现并发整理——应用线程读对象时发现指针颜色不对，触发地址修正，在访问过程中完成GC。\n关键特性：\n停顿时间不随堆大小增长——16MB堆\u0026lt;1ms，16TB堆也是\u0026lt;1ms 支持TB级堆、毫秒级回收、JDK 15生产可用 限制：仅Linux x64；吞吐量比G1低约5-10%（读屏障开销） JDK版本与默认回收器对照速查：\nJDK版本 默认回收器 JDK 8 Parallel Scavenge + Parallel Old（吞吐量优先） JDK 9-16 G1 JDK 17+ G1（LTS） JDK 21 G1（新一代ZGC也在成熟，但G1仍是默认） 面试官可能会问\u0026quot;你们项目用的什么回收器，为什么？\u0026quot;：\n项目部署在JDK 8上，默认Parallel Scavenge+Parallel Old。但我们实际指定了G1——原因：①堆内存配了4-8G，G1对这个区间的优化最好；②安全生产平台是面向客户的服务端应用，客户对接口响应时间敏感，G1的可预测停顿比Parallel的吞吐量优先更适合；③大量设备数据写入导致新生代对象产生速度快，Parallel的STW时间随堆增长接近1秒，G1的停顿控制在200ms以内。上了G1后加上 -XX:MaxGCPauseMillis=100调优，P99延迟从800ms降到了300ms。\n陷阱提示：把G1说成简单的\u0026quot;分Region的CMS\u0026quot;；不知道CMS在JDK 14已废弃；不知道JDK 8默认是Parallel而非G1；说不出ZGC的核心创新（染色指针）；GC选型说不出业务场景理由。\n","date":"2018-03-06T00:00:00Z","permalink":"/p/03-ge-jdk-ban-ben-la-ji-hui-shou-qi/","title":"各JDK版本垃圾回收器"},{"content":"§2.1.2 垃圾回收算法 考察意图：理解各算法的原理、优缺点和适用分代，能结合业务场景说明选型理由。\n回答样板：\n四种基础算法，JVM根据分代特性组合使用：\n1. 标记-清除（Mark-Sweep）——最基础\n流程：标记阶段遍历GC Roots标记存活对象 → 清除阶段回收未标记对象 优点：算法简单，不移动对象 缺点：内存碎片化——清除后产生大量不连续的空闲内存。碎片严重时，即使总空闲内存足够，也可能无法分配大对象，触发Full GC 适用：老年代的基础算法（CMS的标记-清除阶段） 2. 标记-复制（Mark-Copy）——新生代首选\n流程：将存活对象复制到另一块空白区域 → 原区域整块清空 优点：无内存碎片，整块清空效率极高，只需移动存活对象 缺点：浪费50%空间（需要一块空白区域做副本）。不过新生代对象98%朝生夕死，实际只需要很小的Survivor空间 适用：新生代Minor GC。8:1:1的Eden:Survivor比例就是基于这个假设——Survivor只需要留新生代10%的空间。如果Survivor不够放存活对象，通过分配担保机制直接晋升老年代 3. 标记-整理（Mark-Compact）——老年代兜底\n流程：标记存活对象 → 将所有存活对象移到内存一端 → 清理边界外的内存 优点：无内存碎片，不需要浪费额外空间 缺点：移动对象需要STW，且需要更新所有指向被移动对象的引用——停顿时间与堆中存活对象数量成正比 适用：老年代（Serial Old、Parallel Old） 4. 分代收集（Generational Collection）——JVM的顶层策略\n不是独立算法，而是\u0026quot;不同分代用不同算法\u0026quot;的策略组合 核心假设：弱分代假说——绝大多数对象朝生夕死（新生代用复制算法）；强分代假说——熬过多次GC的对象一般不会轻易死亡（老年代用标记-清除/标记-整理） 几乎所有JVM垃圾回收器都基于分代假设设计 记忆集（Remembered Set）与卡表（Card Table）：\n分代收集的致命问题：跨代引用。新生代对象被老年代引用时，Minor GC只扫新生代，无法通过GC Roots找到这个老年代引用，导致存活新生代对象被误清。解决方案：老年代维护一张卡表——将老年代内存按512字节分块（Card），有老年代引用指向新生代时，对应Card标记为\u0026quot;脏\u0026quot;。Minor GC扫描时除了GC Roots还扫描卡表中的脏Card，避免全堆扫描。CMS和G1都在写屏障（Write Barrier）中维护这张卡表，性能开销约5%-10%。\n陷阱提示：四种算法的优缺点和应用分代背串；不知道跨代引用问题和卡表机制；以为复制算法就是新生代的全部。\n","date":"2018-03-06T00:00:00Z","permalink":"/p/02-la-ji-hui-shou-suan-fa/","title":"垃圾回收算法"},{"content":"§2.2.4 线程池核心参数与执行流程 考察意图：能否根据业务场景做线程池选型与调参，理解拒绝策略的差异。\n回答样板：\n七个核心参数：\ncorePoolSize——常驻线程数 maximumPoolSize——最大线程数 keepAliveTime——空闲线程存活时间（超过corePoolSize的线程） TimeUnit——时间单位 workQueue——阻塞队列（有界/无界） threadFactory——线程工厂（自定义线程名、是否守护线程等） handler——拒绝策略 执行流程： 提交任务 → 当前线程数 \u0026lt; corePoolSize → 创建核心线程执行 → 当前线程数 \u0026gt;= corePoolSize → 入队列等待 → 队列满 → 创建非核心线程执行 → 当前线程数 \u0026gt;= maximumPoolSize → 触发拒绝策略\n四种拒绝策略：\n策略 行为 适用场景 AbortPolicy（默认） 抛RejectedExecutionException 必须感知任务丢失的场景 CallerRunsPolicy 调用者线程执行 反向压制动，降低任务提交速度 DiscardPolicy 直接丢弃，静默失败 不重要的日志/统计任务 DiscardOldestPolicy 丢弃队列最老的未处理任务 优先处理新任务的场景 项目实战：在物联平台用线程池处理设备数据批量写入。I/O密集型任务核心线程数设为CPU核数×2，队列用有界ArrayBlockingQueue防止内存溢出。自定义ThreadFactory设置线程名前缀方便排查。拒绝策略用CallerRunsPolicy做背压。\n陷阱提示：背参数但说不清业务场景下怎么选型和调参。\n","date":"2018-03-06T00:00:00Z","permalink":"/p/12-xian-cheng-chi-he-xin-can-shu/","title":"线程池核心参数与执行流程"},{"content":"一个目录只能挂一个盘 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 fdisk -l 1.终止占用 /home 进程 fuser -m -v -i -k /home 2.备份/home cp -r /home/ homebak/ 3.卸载 /home umount /home 4.删除/home所在的lv lvremove /dev/mapper/centos-home 5.扩展/root所在的lv，增加100G lvextend -L +100G /dev/mapper/centos-root 6.扩展/root文件系统 xfs_growfs /dev/mapper/centos-root 7.重新创建home lv lvcreate -L 40G -n home centos 8.创建文件系统 mkfs.xfs /dev/centos/home 9.挂载 mount /dev/centos/home /home 10.还原 /home 相关文件以及对应目录权限 cp -r homebak/* /home/ chown -R hdfs:hdfs /home/hdfs 查看云盘 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 fdisk -l Disk /dev/vda: 20 GiB, 21474836480 bytes, 41943040 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0xe4c1f796 Device Boot Start End Sectors Size Id Type /dev/vda1 * 2048 41940991 41938944 20G 83 Linux Disk /dev/vdb: 100 GiB, 107374182400 bytes, 209715200 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/vdc: 500 GiB, 536870912000 bytes, 1048576000 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes 挂载 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 mount /dev/vdc /data mount: /data: wrong fs type, bad option, bad superblock on /dev/vdc, missing codepage or helper program, or other error. 为数据盘创建GPT分区,2t以上的盘 安装Parted工具和e2fsprogs工具 yum install -y parted yum install -y e2fsprogs 分区 parted /dev/vdb mklabel gpt\t#设置分区格式 mkpart primary 1 100%\t#划分一个主分区 align-check optimal 1 #检查分区是否对齐，正确结果1 aligned print\t#查看分区表 quit\t#退出Parted工具 partprobe\t#使系统重读分区表 fdisk -lu /dev/vdb\t#查看新分区信息，如果出现gpt的相关信息，表示新分区已创建完成 为数据盘创建MBR分区，2t以下的盘 fdisk -u /dev/vdc\t#开始分区， p回车\t#查看数据盘的分区情况 n回车\t#创建一个新分区 p回车\t#选择分区类型为主分区 1回车\t#分区编号，默认为1不输直接回车也行 回车，回车\t#第一个可用的扇区编号默认2048，最后一个扇区编号 wq回车\t#并在完成分区后退出 fdisk -lu /dev/vdc 在新分区上创建一个文件系统。 mkfs -t ext4 /dev/vdc1 运行命令cp /etc/fstab /etc/fstab.bak，备份etc/fstab。 运行命令echo `blkid /dev/vdc1 | awk \u0026#39;{print $2}\u0026#39; | sed \u0026#39;s/\\\u0026#34;//g\u0026#39;` /data ext4 defaults 0 0 \u0026gt;\u0026gt; /etc/fstab，向/etc/fstab里写入新分区信息。 运行cat /etc/fstab命令查看/etc/fstab中的新分区信息。 或者 echo /dev/vda3 /data ext4 defaults 0 0 \u0026gt;\u0026gt; /etc/fstab $ cat /etc/fstab # /etc/fstab: static file system information. # # Use \u0026#39;blkid\u0026#39; to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # \u0026lt;file system\u0026gt; \u0026lt;mount point\u0026gt; \u0026lt;type\u0026gt; \u0026lt;options\u0026gt; \u0026lt;dump\u0026gt; \u0026lt;pass\u0026gt; # / was on /dev/vda1 during installation UUID=f126eb90-41ef-4ccf-afa2-055203ed920e / ext4 errors=remount-ro 0 1 /dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0 /home ext4 defaults 0 0 UUID=a6ce082e-88cb-469f-8405-72192b89a439 /data ext4 defaults 0 0 如果出问题就运行以下命令：The device apparently does not exist; did you specify it correctly? partprobe 运行mount /dev/vdc1 /data 命令挂载文件系统。 如果运行df -h命令后出现新建文件系统的信息，表示文件系统挂载成功。 3\n原磁盘进行扩容 需求：云盘不够用，原来是 500G,现在又买了 200G，数据不变挂载不变的情况下进行扩容\n1 2 3 4 5 6 7 8 9 10 11 12 # 1 进入分区 fdisk /dev/vdb # 2 使用d进行删除分区，如果有多个分区要进行逐个删除 # 3 使用n进行分区 # 4 使用p选择主分区 # 5 使用两次回车以选择开始和结束分区位置 # 6 提示Partition #1 contains a ext4 signature 是否删除，选择n # 7 保存退出 w # 8 修正 resize2fs /dev/vdb1 # 9 查看 df -h 重启后硬盘会找不到 1 写入/etc/fstab ","date":"2018-03-06T00:00:00Z","permalink":"/p/ying-pan-gua-zai/","title":"硬盘挂载"},{"content":"docker.io，docker-ce，docker-ee 的区别 1 2 3 4 5 6 7 8 9 10 11 12 13 14 docker.io：是debian/ubuntu 官方基于docker社区源码封装的版本,有时候比docker-ce版本还要新，特点是将docker的依赖直接转接到主系统上 docker-ce：docker.com 放出来的社区版,仅维护源码，特点是使用golang将依赖封装在一个包中 docker-ee：docker.com 维护的商业版,主要有以下三个级别: 基本:用于认证基础架构的Docker平台,得到Docker Inc.的支持以及来自Docker Store的认证容器和插件 标准:添加了高级映像和容器管理,LDAP / AD用户集成以及基于角色的访问控制.这些功能共同构成了Docker企业版 高级:添加Docker安全扫描和连续漏洞监控 docker-ce有一个致命缺陷-依赖: docker本身依赖成百上千个第三方依赖 理论上只要有一个依赖出问题就需要完全重新编译docker,否则会被各种hack😂 反观 docker.io 将依赖托管给系统,只需要更新docker主程序即可 结论：apt包使用docker.io,其他系统使用通用脚本安装，付费用docker-ee 服务器使用debian/ubuntu ","date":"2014-03-06T00:00:00Z","permalink":"/p/docker-ji-chu-zhi-shi/","title":"docker.io，docker-ce，docker-ee 的区别"},{"content":"智联招聘/卓聘 https://www.zhaopin.com\nboss直聘 https://www.zhipin.com\n猎聘 https://www.liepin.com\n前程无忧/51job https://www.51job.com\n拉勾(前程无忧控股) 2026已倒闭\nhttps://www.lagou.com\n脉脉 远程兼职 猿急送 https://www.yuanjisong.com\n程序员客栈 https://www.proginn.com\n程聚宝 https://devlg.com/case\n猪八戒 https://www.zbj.com\n电鸭社区 https://eleduck.com\nv2ex https://www.v2ex.com/go/outsourcing\nUpwork https://www.upwork.com\nToptal https://www.toptal.com\n","date":"2010-03-06T00:00:00Z","permalink":"/p/zhao-pin-ping-tai/","title":"招聘平台"},{"content":"涉及在linux命令行下进行快速移动光标、命令编辑、编辑后执行历史命令、Bang(!)命令、控制命令等。让basher更有效率。\n常用 ctrl+左右键:在单词之间跳转 ctrl+a:跳到本行的行首 ctrl+e:跳到页尾 Ctrl+u：删除当前光标前面的文字 （还有剪切功能） ctrl+k：删除当前光标后面的文字(还有剪切功能) Ctrl+L：进行清屏操作 Ctrl+y:粘贴Ctrl+u或ctrl+k剪切的内容 Ctrl+w:删除光标前面的单词的字符 Alt – d ：由光标位置开始，往右删除单词。往行尾删 说明\nCtrl – k: 先按住 Ctrl 键，然后再按 k 键； Alt – k: 先按住 Alt 键，然后再按 k 键； M – k：先单击 Esc 键，然后再按 k 键。 移动光标\nCtrl – a ：移到行首 Ctrl – e ：移到行尾 Ctrl – b ：往回(左)移动一个字符 Ctrl – f ：往后(右)移动一个字符 Alt – b ：往回(左)移动一个单词 Alt – f ：往后(右)移动一个单词 Ctrl – xx ：在命令行尾和光标之间移动 M-b ：往回(左)移动一个单词 M-f ：往后(右)移动一个单词 编辑命令\nCtrl – h ：删除光标左方位置的字符 Ctrl – d ：删除光标右方位置的字符（注意：当前命令行没有任何字符时，会注销系统或结束终端） Ctrl – w ：由光标位置开始，往左删除单词。往行首删 Alt – d ：由光标位置开始，往右删除单词。往行尾删 M – d ：由光标位置开始，删除单词，直到该单词结束。 Ctrl – k ：由光标所在位置开始，删除右方所有的字符，直到该行结束。 Ctrl – u ：由光标所在位置开始，删除左方所有的字符，直到该行开始。 Ctrl – y ：粘贴之前删除的内容到光标后。 ctrl – t ：交换光标处和之前两个字符的位置。 Alt + . ：使用上一条命令的最后一个参数。 Ctrl – _ ：回复之前的状态。撤销操作。 Ctrl -a + Ctrl -k 或 Ctrl -e + Ctrl -u 或 Ctrl -k + Ctrl -u 组合可删除整行。\nBang(!)命令\n!! ：执行上一条命令。 ^foo^bar ：把上一条命令里的foo替换为bar，并执行。 !wget ：执行最近的以wget开头的命令。 !wget:p ：仅打印最近的以wget开头的命令，不执行。 !$ ：上一条命令的最后一个参数， 与 Alt - . 和 $_ 相同。 !* ：上一条命令的所有参数 !_:p ：打印上一条命令是所有参数，也即 !_的内容。 ^abc ：删除上一条命令中的abc。 ^foo^bar ：将上一条命令中的 foo 替换为 bar ^foo^bar^ ：将上一条命令中的 foo 替换为 bar !-n ：执行前n条命令，执行上一条命令： !-1， 执行前5条命令的格式是： !-5 查找历史命令\nCtrl – p ：显示当前命令的上一条历史命令 Ctrl – n ：显示当前命令的下一条历史命令 Ctrl – r ：搜索历史命令，随着输入会显示历史命令中的一条匹配命令，Enter键执行匹配命令；ESC键在命令行显示而不执行匹配命令。 Ctrl – g ：从历史搜索模式（Ctrl – r）退出。 控制命令\nCtrl – l ：清除屏幕，然后，在最上面重新显示目前光标所在的这一行的内容。 Ctrl – o ：执行当前命令，并选择上一条命令。 Ctrl – s ：阻止屏幕输出 Ctrl – q ：允许屏幕输出 Ctrl – c ：终止命令 Ctrl – z ：挂起命令 重复执行操作动作\nM – 操作次数 操作动作 ： 指定操作次数，重复执行指定的操作。 ","date":"2010-01-06T00:00:00Z","permalink":"/p/zhong-duan-kuai-jie-jian/","title":"终端快捷键"},{"content":"§2.3.3 ArrayList vs LinkedList 考察意图：是否理解List不同实现的性能差异及工程选型判断。\n回答样板：\n维度 ArrayList LinkedList 底层结构 动态数组（Object[]） 双向链表（Node） 随机访问 O(1) O(n)——需要遍历 尾部插入 O(1)均摊（扩容时O(n)） O(1) 头/中间插入 O(n)（需要移动元素） 头O(1)，中间O(n)——定位+O(1)插入 内存开销 连续内存，数据紧凑 每个节点额外存储prev+next指针 工程实践：实际开发中ArrayList用得更多。原因是内存连续、CPU缓存友好（缓存行预读），大多数场景下遍历性能远超LinkedList。LinkedList的优势场景是频繁头尾插入删除（如队列、栈）。日常开发90%场景ArrayList够用。\nArrayList扩容：默认初始容量10，扩容时增长为原来的1.5倍（oldCapacity + (oldCapacity \u0026gt;\u0026gt; 1)），通过Arrays.copyOf拷贝数组。\n陷阱提示：不知道ArrayList扩容机制细节；说\u0026quot;LinkedList插入快\u0026quot;不考虑定位开销。\n","date":"2008-03-06T00:00:00Z","permalink":"/p/16-arraylist-yu-linkedlist/","title":"ArrayList vs LinkedList"},{"content":"工具说明 1.软件开发工具 对应软件开发过程的各种活动，软件开发工具有需求分析工具、设计工具、。编码与排错工具、测试工具等。\n（1）需求分析工具 需求分析工具用以辅助软件需求分析活动，辅助系统分析员从需求定义出发，生成完整的、清晰的、一致的功能规范。功能规范是软件所要完成的功能精确而完整的陈述，描述该软件要做什么及只做什么，是软件开发者和用户间的契约，同时也是软件设计者的和实现者的依据。功能规范应正确、完整地反映用户对软件的功能要求，其表达是清晰的、无歧义的。需求分析工具的目标就是帮助分析员形成这样的功能规范。\n（2）基于自然语言或图形描述的工具 这类工具采用分解与抽象等基本手段，对用户问题逐步求精，并在检测机制的辅助下，发现其中可能存在的问题（如一致性），通过对问题描述的修改，逐步形成能正确反映用户需求的功能规范。它能帮助分析员提高需求文档的质量，降低功能规范的维护费用。这里以支持结构化方法的需求分析工具为例介绍。\n结构化分析方法采用数据流图的描述方法，分析的主要结果是一套分层的数据流图和一个数据词典。结构化需求分析工具通常由图形编辑器、数据词典管理器和检测机制三部分组成。使用图形编辑器绘制数据流图，该图形编辑器应支持图形的分层结构，以构成分层数据流图。在构造数据流图的同时把数据流图的有关信息填入数据词典。在填写数据词典的过程中，数据词典管理器即可�出重名等错误。在构造出分层数据流图后，可通过检测机制来检查分层数据流图的合法性，可发现诸如父图与子图不平衡，遗漏的数据流，只有读文件没有写文件或只有写文件没有读文件等错误。然后将修改后的数据流图和词典与用户交流，考察它是否符合用户的功能需求。若不一致，再使用图形编辑器进行修改。需求分析工具还应具备同步修改的功能，即修改数据流图的同时也修改数据词典中的有关信息，以保持数据流图与数据词典的一致性。经过多次反复的交流和修改，使功能规范逐步达到准确、完整和一致，最后形成有效的功能规范。除此以外，该工具还可浏览数据词典，生成各种统计或查询报告。\n（3）基于形式化需求定义语言的工具 基于形式化需求定义语言的工具大多以基于知识的需求智能助手的形式出现，并把人工智能技术运用于软件工程。这类工具通常具有一个知识库和一个推理机制。知识库中存放需求分析所需的公共知识，以及特定的应用领域知识。这些知识能用来理解需求定义中的省略写法，能部分消除不完整性和歧义性。推理机制能容忍需求定义的无序性，部分解决描述中的不一致性。这类工具接受用形式化语言书写的功能描述，运用知识库中的知识，通过推理，发现需求定义中的矛盾和不足，经补充、更新知识库中的知识和规则，以及与系统分析员的不断交互，得到完整的功能规范。\n（4）其他需求分析工具 可执行规范语言以及原型技术为需求分析工具提供了另一条实现途径，这些工具通过运行可执行规范或原型，将有关的结果显示给用户和系统分析员，以便进行需求确认。\n2.设计工具 设计工具用以辅助软件设计活动，辅助设计人员从软件功能规范出发，得到相应的设计规范。\n设计规范是符合功能规范和需求定义中所指定的功能及性能要求，对软件的组织或其组成部分的内部结构的描述。通常设计规范分成概要设计规范和详细设计规范。概要设计规范描述软件的功能模块及其相互关系，说明模块的处理过程和外部行为，同时还应描述数据的逻辑结构。详细设计规范描述每个模块的处理算法及涉及到的全部数据结构。设计规范是程序员进行编程活动的依据。\n3.编码与排错工具 编码工具和排错工具用以辅助程序员进行编码活动。编码工具辅助程序员用某种程序语言编制源程序，并对源程序进行翻译，最终转换成可执行的代码，因此编码工具通常与编码所使用的程序语言密切相关。排错工具用来辅助程序员寻找源程序中错误的性质和原因，并确定其出错的位置。由于源程序一般以正文的形式出现，必须有编辑器将它输入，并进行浏览、编辑和修改。又由于源程序的编写往往不会一次成功，需要不断寻找其中的错误并加以纠正。编码工具和排错工具是编程活动的重要辅助工具，也是最早出现的软件工具。\n（1）编码工具 主要有编辑程序、汇编程序、编译程序和生成程序等。\n编辑程序：编辑程序用以输入源程序，并对其进行增加、删除和修改等操作。除常见的以字符为单位进行编辑的正文编辑程序外，还有面向程序语言语法单位的语法制导编辑程序和混合编辑程序。语法制导编辑程序也称结构化编辑程序，它可根据程序语言的语法规则提供编辑时的语法制导和检查，可以一次扩展或删除一个语法单位，如语句、表达式等，从而确保输入的源程序在语法上是正确的。混合编辑程序兼有正文编辑和语法制导编辑两种方法。\n汇编程序：汇编程序用以将汇编语言书写的程序翻译成等价的机器语言程序。如果汇编程序所生成的机器指令代码是另一种计算机的机器指令，便称这类汇编程序为交叉汇编程序。\n编译程序：编译程序用以将高级程序语言书写的程序翻译成等价的低级程序语言程序。\n生成程序：生成程序通常根据与领域有关的甚高级语言或某种专用语言描述的用户需求，自动生成高级程序语言或低级程序语言描述的程序。例如，词法分析生成程序LEX,它根据正规表达式表示的词法规则，自动生成词法分析程序的代码段，来实现能识别所说明的正规表达式的有限状态自动机。\n（2）排错工具 已有的排错工具主要有源代码排错程序和排错程序生成程序两类。\n源代码排错程序：源代码排错程序用以帮助程序员理解程序的执行状态\u0026rsquo;可通过对程序执行过程中各种状态的判别进行程序错误的识别、定位及改正。\n4.软件维护工具 软件维护工具辅助软件维护过程中的活动，辅助维护人员对软件代码及其文档进行各种维护活动。软件维护工具主要有版本控制工具、文档分析工具、开发信息库工具、逆向工程工具和再工程工具等。\n（1）版本控制工具 在软件开发和维护过程中一个软件会有多个版本，版本控制工具用来存储、更新、恢复和管理一个软件的多个版本。UNIX的是版本控制工具的典型代表。SCCS能为正文文件的多个版本建立一棵版本树，第一版完整储存文本全文，以后各版只存放它之前版本的不同之处，在任何时刻sees只允许对一个当前版本进行修改和提交。通过版本树维护版本的更新历史，并允许恢复到以前的某个版本。\n（2）文档分析工具 文档分析工具用以对软件开发过程中形成的文档进行分析，给出软件维护活动所需的维护信息。例如，基于数据流图的需求文档分析工具可给出对数据流图的某个成分进行维护时的影响范围及被影响范围，以便在该成分修改的同时考虑其影响范围内的其他成分是否也要修改。基于模块结构图的设计文档分析工具可以给出对模块变量进行维护时的影响及被影响范围。针对程序文档的源代码分析工具可给出模块、全局变量、局部变量的定义、引用情况，它还可以进行程序分片。程序分片是把程序中与指定的数据项或数据结构有关的程序代码抽出来，过滤掉与其无关的代码，以便维护人员高效地理解和把握他所关心的部分。文档分析工具还可得到被分析的文档的有关信息，如文档各种成分的个数、定义及引用情况等。\n（3）开发信息库工具 开发信息库工具用来维护软件项目的开发信息，包括对象、模块等。它记录每个对象的修改信息和其他变形；维护对象和与之有关信息之间的关系；包括模块的设计者、新版本中模块的改动及其与错误、测试用例、测试结果之间的联系等；其他必须记录的信息，包括用来生成此软件产品的所有工具的版本信息，所使用的命令语言程序和系统库以及测试用例版本和测试报告。\n（4）逆向工程工具 在软件生存周期中，将某种形式表示的软件转换成更高抽象形式表示的软件的活动称为逆向工程。例如，用反汇编工具将机器语言代码转换成汇编语言代码，用反编译工具将汇编语言代码或机器语言代码转换成某种高级程序语言源程序，之后再将源程序转换成详细设计的某种表示形式，这都属于逆向工程的范畴。逆向工程工具就是辅助软件人员进行这种逆向工程活动的软件工具。若软件缺乏必要的文档，原先的开发人员又已调离，就需使用逆向工程工具来理解原有的软件。\n（5）再工程工具 再工程工具用来支持重构一个功能和性能更为完善的软件系统。目前的再工程工具主要集中在代码重构、程序结构重构和数据结构重构等方面。\n代码重构工具可把用一种程序语言书写的程序转换成用另一种程序语言书写的或适用于不同硬件平台的程序，例如FORTRAN到C的转换工具。程序结构重构工具接受-个非结构化或结构化程度较低的源程序，构造出行为等价的结构化程序。数据结构重构工具通过对数据描述的分析，重构新的数据结构。\n5.软件管理和软件支持工具 软件管理过程和软件支持过程往往要涉及到软件生存周期中的多个活动，软件管理和软件支持工具用来辅助管理人员和软件支持人员的管理活动和支持活动，以确保软件高质高效地完成。\n辅助软件管理和软件支持的工具有很多，其中常用的工具有项目管理工具、配置管理工具、软件评价工具等。\n（1）项目管理工具 项目管理工具用来辅助软件的项目管理活动。通常项目管理活动包括项目的计划、调度、通信、成本估算、资源分配及质量控制等。一个项目管理工具通常把重点放在某-个或某几个特定的管理环节上，而不提供对管理活动包罗万象的支持。\n例如成本估算工具，�用某种成本估算模型对项目的成本进行估算。它可以通过间接的测量来估算项目的规模大小，并描述总的项目特征，如问题的复杂度、开发组经验和过程成熟度等。然后按一定的估算模型估算出项目的工作量、工期和开发人数等。当项目截止期限变更时，可检测它对整个开发成本的影响。\n（2）配置管理工具 配置曾理工具用以辅助完成软件配置项的标识、版本控制、变化控制、审计和状态统计等基本任务，使各配置项的存取、修改和系统生成易于实现，从而简化审计过程，改进状态统计，减少错误，提�系统的质量。\n（3）软件评价工具 软件评价工具用以辅助管理人员进行软件质量保证的有关活动。它通常可按某个软件质量模型对被评价的软件进行度量，然后得到相关的软件评价报告。目前许多度量指标还不能定量化，需要通过专家评分，再将得分送给软件评价工具。对一些已经定量化的度量指标则可利用评价工具自动获取。有的评价工具还可分析被评价程序的程序\u0026rsquo;结构，根据某种软件复杂性模型对被评价的程序进行复杂性度量。软件评价工具有助于软件的�量控制，对确，保软件的质量有重要的作用。\n（4）软件开发工具的评价和选择 现在各类软件开发工具十分丰富，有免费的，有价格便宜的，也有昂贵的。评价和选择适合本人、本单位、本项目的软件开发工具，可以根据以下标准来衡量软件开发工具的优劣。\n功能：软件开发工具不仅要实现所遵循的功能需求，支持用户所选定的开发方法，还应能检查与之相关的方法学能否正确执行，并保证产生与方法学一致的输出结果。\n易用性:软件开发工具应有十分友好的用户界面，用户乐于使用；工具应能剪裁和定制，以适应特定用户的需要；工具应能提示用户的交互操作，提供简单有效的执行方式；工具还应能检查用户的操作错误，尽可能自动改正错误。\n稳健性:一个好的软件开发工具应能长期可靠地使用，并能适应环境或其他条件变化的要求；即使在非法操作或故障情况下，也不应导致严重后果。\n","date":"2007-01-15T10:00:00+08:00","permalink":"/p/tools/","title":"工具说明"},{"content":"§2.3.1 HashMap原理 考察意图：是否理解HashMap的数据结构演进、put流程、扩容与树化等关键机制。\n回答样板：\n底层结构：JDK 7：数组+链表。JDK 8：数组+链表/红黑树。\nput流程：\n计算key的hash值（高16位异或低16位，降低hash冲突） 定位桶：(n - 1) \u0026amp; hash 无冲突 → 直接放入 有冲突 → 判断equals → 相同则覆盖，不同则尾插（JDK 7是头插，JDK 8改尾插避免死链） 链表长度 \u0026gt; 8 且数组长度 ≥ 64 → 树化为红黑树 容量超过 threshold（capacity × loadFactor）→ 扩容 扩容机制：2倍扩容，JDK 8做了rehash优化——原hash值与oldCap按位与，结果为0留在原位，为1移到\u0026quot;原位置+oldCap\u0026quot;，省去了每次rebuild hash表的开销。\n负载因子0.75：时间和空间的折中。太低（如0.5）浪费内存；太高（如1）hash冲突增加，影响查询性能。\n红黑树退化：resize时如果树的节点数 ≤ 6，退化为链表。\n陷阱提示：说\u0026quot;HashMap线程安全\u0026quot;；不知道树化阈值是链表长度\u0026gt;8且数组长度≥64两个条件缺一不可。\n","date":"2006-06-06T00:00:00Z","permalink":"/p/14-hashmap-yuan-li/","title":"HashMap原理"},{"content":"§2.3.2 ConcurrentHashMap原理 考察意图：是否理解ConcurrentHashMap在JDK 7/8的演进及JDK 8的改进要点。\n回答样板：\nJDK 7（分段锁）：\n数据结构：Segment数组 + HashEntry数组 + 链表 Segment继承ReentrantLock，默认16个Segment 理论上支持16个线程并发写（每个Segment一把锁） 并发度固定不可动态调整 JDK 8（CAS + synchronized）：\n数据结构：Node数组 + 链表/红黑树 put时CAS尝试插入空桶，CAS失败则synchronized锁桶头节点再插入 锁粒度从Segment级别（一锁锁一段）细化到桶级别（一锁锁一个桶），并发度更高 扩容支持多线程并发——transferIndex分段迁移，每个线程负责一段区域的rehash JDK 8改synchronized而非ReentrantLock的原因：JDK 6后synchronized性能足够；省去Segment对象的内存开销；锁粒度更细带来的收益远超锁机制本身的微小差异 陷阱提示：仍停留在JDK 7分段锁的理解；不知道JDK 8为什么改CAS+synchronized。\n","date":"2006-04-06T00:00:00Z","permalink":"/p/15-concurrenthashmap-yuan-li/","title":"ConcurrentHashMap原理"}]