1.5 Cloud Native 的 原 则
的 角 度 出 发 , 能 够 容 忍 故 障 的 发 生 ,
最 小 化 故 障 的 影 响 范 围 。 例 如 , 在 电
商 系 统 中 , 价 格 很 重 要 , 如 果 价 格 服
务 整 体 不 可 用 , 那 么 这 时 候 前 端 详 情
页 显 示 一 个 没 有 价 格 的 页 面 比 一 个 什
么 也 不 显 示 或 者 显 示 后 端 服 务 失 效 的
页 面 强 得 多 。
不 变 性 原 则
我 们 已 经 听 到 过 很 多 由 于 运 维 人 员 删
错 了 文 件 , 或 者 配 置 错 了 参 数 而 导 致
的 故 障 。 对 于 资 源 调 度 来 说 , 我 们 更
希 望 所 有 的 服 务 无 差 异 化 配 置 , 所 有
的 服 务 都 是 标 准 的 , 而 不 希 望 在 部 署
任 何 服 务 的 过 程 中 还 需 要 手 动 操 作 ,
手 动 操 作 是 不 容 易 回 溯 的 。
实 现 不 变 性 原 则 的 前 提 是 , 基 础 设 施
中 的 每 个 服 务 、 组 件 都 可 以 自 动 安
e 一 一 一 一 一 一 一 e 国
1.4 如 何 衡 量 Cloud Native 的 能 力
装 、 部 署 , 不 需 要 人 工 干 预 。 每 个 服
务 或 组 件 在 安 装 、 部 署 完 成 后 将 不 会
发 生 更 改 , 如 果 要 更 改 , 则 丢 弃 老 的
服 务 或 组 件 并 部 署 一 个 新 的 服 务 或 组
件 。 另 外 , 为 了 提 升 可 用 性 , 我 们 应
该 尽 量 减 少 故 障 修 复 时 间 , 要 知 道 替
换 的 速 度 远 远 快 于 修 复 的 速 度 , 这 种
思 想 与 不 可 变 对 象 [ 的 概 念 完 全 相
同 。
去 中 心 化 原 则
中 心 化 往 往 代 表 的 是 瓶 颈 点 , 在 微 服
务 场 景 下 , 每 个 服 务 可 以 独 立 采 用 自
己 的 技 术 方 案 或 技 术 栈 , 因 为 每 个 服
务 具 有 自 己 独 立 的 业 务 场 景 , 可 以 根
据 实 际 情 况 进 行 选 择 。 服 务 之 间 通 过
进 程 隔 离 , 每 个 服 务 都 有 独 立 的 数 据
库 , 一 个 服 务 实 例 失 效 不 会 导 致 大 规
国

Backlinks