迁移到云原生应用架构
文章说明：
1.1 为何使用云原生应用架构
速度
在传统企业中，为应用提供环境和部署新版本花费的时间通常以天、周或月来计算。
互联网公司经常提到它们每天几百次发布的实践。为什么频繁发布如此重要？
- 如果你可以每天实现几百次发布，你们就可以几乎立即从错误的版本恢复过来。
- 如果你可以立即从错误中恢复过来，你就能够承受更多的风险
- 如果你可以承受更多的风险，你就可以做更疯狂的试验
- 这些试验结果可能会成为你接下来的竞争优势
所以，速度快很重要。这个快速发布-》试错 -》改进 实现快速创新的说法不错。
TODO：考虑画一个示意图，用来说明为什么要快。
精益大师Mary Poppendick提出的问题了——“如果只是改变了应用的一行代码，您的组织需要多长时间才能把应用部署到线上？“
这个说法非常适合用来直观的体现快。
安全
云原生应用架构在快速变动的需求、稳定性、可用性和耐久性之间寻求平衡。这是可能的而且非常有必要同时实现的。
安全的实现方式：
- 可观测性：指标、监控、警报、数据可视化框架和工具是所有云原生应用程序体系结构的核心
- 故障隔离：将系统拆解为微服务；结合容错
- 容错：防止级联故障
- 自动恢复：有可观测性、故障隔离、容错字后，就有机会做自动恢复。在可替换性的支持下，可以简单的重新或者重新部署
弹性扩展
如何扩大服务能力:
- 水平扩展应用实例
- 改善资源利用率：虚拟化/容器化 + 部署多个工作负载 (需要隔离性支持)，然后通过编排来调度以调高效率
公有云基础设施的出现有助于实现这个目标。
付出的代码：
- 架构：支持水平扩展的应用程序的架构必须不同
- 状态：应用无状态 + 状态外部化
移动应用和客户端多样性
- 移动平台的巨大差异也对应用架构提出了要求
- 移动应用程序通常必须与多个传统系统以及云原生应用程序架构中的多个微服务进行交互
- 云原生应用程序架构还通过诸如API网关之类的设计模式来支持移动优先开发的概念：指的是BFF模式吧？
1.2 云原生架构定义
12因素应用
12因素应用是一系列云原生应用架构的模式集合，最初由Heroku提出。如Cloud Foundry、Heroku和Amazon ElasticBeanstalk都对部署12因素应用进行了专门的优化。
微服务
微服务将单体业务系统分解为多个“仅做好一件事”的可独立部署的服务。
自服务敏捷架构
使用云原生应用架构的团队通常负责其应用的部署和持续运营。(开始 + 测试 + 部署 + 运营)
基于API的协作
在云原生应用程序架构中，服务之间的唯一互动模式是通过已发布和版本化的API。 实现体现为微服务
抗脆弱性
稳健性或弹性，
Nassim Taleb在他的Antifragile（Random House）一书中介绍了抗脆弱性的概念
“混沌猴” 将随机故障注入到生产组件中，目的是识别和消除架构中的缺陷。
感觉这个说法有点不太合适，还是用回 弹性 比较好。
2.1 文化变革
企业IT采用云原生架构所需的变革根本不是技术性的，而是企业文化和组织的变革，围绕消除造成浪费的结构、流程和活动。
这个说到点了！
从信息孤岛到DevOps
企业IT通常被组织成以下许多孤岛：
- 软件开发：开发
- 质量保证：测试
- 数据库管理：DBA
- 系统管理：运维
- IT运营
- 发布管理
- 项目管理
DevOps代表着这样一种思想，即将这些信息孤岛构建成共享的工具集、词汇表和沟通结构，以服务于专注于单一目标的文化：快速、安全得交付价值。
从间断均衡到持续交付
从集中治理到分散自治
TBD：后面写云原生文化时再整理。