云原生模式

书名《云原生模式》，副标题：设计拥抱变化的软件。
如下格式为文中原文。

这是书中的原文

云原生，英文为Cloud Native。直译为，云原住居民。天空中云距离我们很远，不停的变化。用“云原生”可以形象化地领会其特点。

感觉这本书是“事后诸葛亮”，已经有了k8s的前提下，对k8s中设计考虑的点进行汇总拔高，形成了云原生的概念。当然还是能帮助大家理解云原生的一些理念，还是值得学习的。

第一章 什么是“云原生”

换一种角度去理解应用的生命周期。传统的大型服务可以长时间运行，不需要（不敢）变更。传统的数据库也是单体或者主备方式运行。服务是基于Client-Server的交互模式，请求-响应范式的。应该也是这些传统的IT架构不再适用于今天快速发展的信息产业对软件的需求，才催生出了微服务和云原生。通过这些需求，可以从根源理解云原生产生的原因，这些需求具体罗列如下 ：

0x01 1.1小节 现代应用程序的需求

1 高可用，零停机。

当今时代人们的生活已经极大依赖网络服务，短暂的停机带来极大的经济损失。主要是对提供服务的企业，特别是上市公司，短暂的异常通过网络传播后，对公司股价有极大的影响。假如疫情期间，健康码不能用了，这个影响估计很多人会疯掉。

2 快速发布，更迭。

更好的特性，可以在与对手的竞争中胜出，吸引到更多的用户。所以拆分，微服务化，以便于各个组件可以独立开发和运行。

3 多设备支持，含互联网设备

终端多样化。手机、PAD、PC、物联网终端、电动汽车。

4 数据驱动

大量数据，加上业务的频繁升级变动，导致传统单体的数据库不再适用。

以超融合为例：
最主要的需求是高可用，自动化运维。严格来说，不符合云原生所标榜的全部场景，超融合中的数据量并不大，但同样有1和2的需求。

0x02 1.2小节 云原生软件的定义

给出了云原生软件的定义。

云原生软件是高度分布式的，必须在一个不断变化的环境中运行，而且自身也在不断地变化。

特点：

1. 分布式： 这是满足高可用、零停机要求的。单机不可能达成。
2. 不断变化：同样也依赖分布式，如果是单机，做变更的时候，很难保证持续可用。这是快速发布的要求的。环境变化，包含运行和支持的设备。比如超融合要支持在x86上运行，也要支持在arm64上运行。同时，要满足高可用，实例可能在各种设备上拉起，容器是达成这一要求的很好的技术手段。
3. 自身变化：升级、回滚。

0x03 1.3小节 云原生软件的构成

云原生软件包含以下3要素。

1. 云原生应用程序
2. 云原生数据
3. 云原生交互

3.1 云原生应用程序

高可用零停机要求应用是分布式多实例的。而多实例会带来很多挑战。

1. 多实例时，哪个实例来提供服务，保证资源不浪费？
2. 多实例时，某个实例故障了怎么办？
3. 多实例时，如何水平扩容、缩容？
4. 多实例时，配置如何变更？

想要决定哪个实例来提供服务也不是很复杂，传统的高可用方便就是在多个实例之间加一个负载均衡，比如知名的HAProxy。

某个实例故障了怎么办？HAProxy也提供了后端健康检查，一旦某个实例异常，不会再向这个实例路由请求。

水平扩容、缩容则要求实例是无状态的，无论哪个实例应答请求得到的响应都是一样的。扩缩容容易实现，但要考虑如何能自动扩缩容，传统虚拟机扩容可以，但缩容就很难了。

配置如何变更？配置变更需要涉及到多个实例，而且多个实例是分布在多个主机上，对配置变更提出了挑战。知名自动化运维工具Puppet就能满足这个场景。

3.2 云原生交互

1. 应用多实例之后，请求方在请求时，刚好被路由到了异常实例，需要重试。
2. 重试会导致重试风暴，需要控制重试策略和熔断机制。
3. 分布式应用之间的请求链可能很长，很多，需要缓存事件提升性能。
4. 合适的网络协议（HTTP）：自定义的二进制RPC协议不再适用，不透明，对网络控制不友好，如自动重试，熔断等。

3.3 云原生数据

数据指数据源，也指保存数据的数据仓库。

云原生软件的高可用零停机，也要求数据仓库是高可用的。数据源是有状态的，其高可用分布式的要求更高。

传统单体的不适用的原因，原单体数据结构变更，无法通知到所有的服务实例。同时单体的变更可能影响到多个微服务，业务变更时的影响面无法控制。

云原生数据推荐的方式：
缓存+事件，缓存用来保证微服务自治，避免请求链过长，性能低下，可用性下降。事件用来保证数据是一致的，Raft协议也可以通过事件来同步数据的，保证副本的一致性的。

0x04 第一章总结

给出了云原生的定义，并详细分析了云原生软件的特点和组成要素，对于理解云原生来说非常有帮助。