文章目录
学习参考资料：《企业级云原生架构：技术、服务与实践）》
01 云原生概述
1.1 云原生定义
维基百科对云原生（Cloud Native）的定义：
- 云原生是一种软件开发方法，它充分利用了云计算，使用开源软件技术栈将应用程序部署为微服务。通常，云原生应用程序构建为在
Docker 容器中运行的一组微服务，在Kubernetes中编排，并使用DevOps2 和Git Ops工作流进行管理和部署。使用Docker 容器的优点是能够将执行所需的所有软件及环境配置打包到一个可执行包中。容器在虚拟化环境中运行，从而将包含的应用程序与其环境隔离。
上云初始阶段，多数企业仅仅是把应用从传统的 IDC 机房搬迁到云上的虚拟机，这是云托管模式，或者叫作基础设施即服务（Infrastructure as a Service, IaaS）上云。
但要真正用好云，不仅是基础设施和平台的升级，应用也需要摒弃传统的设计方法，从架构设计、开发方式到部署维护的整个软件生命周期管理，都要基于云的特点进行重构，从而构建“原生为云”而设计的应用，这样才能在云上以最优的架构、最佳的模式运行，并充分利用和发挥云平台的弹性以及分布式优势。
采用基于云原生的技术和管理方法，可以更好地把业务生于“云”或迁移到云平台，从而享受“云”的高效和持续的服务能力。
1.2 云原生涵盖内容
Matt Stine（《迁移到云原生应用架构》作者） 认为云原生是一组思想集合和最佳实践，包括敏捷基础设施（agle infrastructure）、微服务（microservice）、DevOps、持续交付（continuous delivery）等，主要涵盖如下重要的内容:
- 十二要素应用程序：云原生应用程序架构模式的集合；
- 微服务：独立部署的服务，每个服务只做一件事情；
- 敏捷基础设施：快速、可重复和一致地提供应用环境和后台服务的平台；
- 基于应用程序接口（
Application Programming Interface, API）的协作：发布和版本化的API，允许在云原生应用程序架构中的服务之间进行交互； - 抗压性：系统具备良好的健壮性，能够抵抗外界非预期的流量冲击。
从狭义上来讲，云原生包含以容器、微服务、持续集成和持续发布 (Continuous Integration/Continuous Delivery,CI/CD）为代表的云原生技术，使用一种全新的方式来构建、部署、运维应用。
从广义上来讲，云原生完全基于分布式云架构来设计开发应用系统，是全面使用云服务的构建软件。随着云计算技术的不断发展和丰富，很多用户对云的使用，不再是早期简单地租用云厂商基础设施（计算、存储、网络）等 IaaS 资源。
02 为何需要云原生
云的核心理念是弹性，过去我们常以虚拟化作为云平台和与客户系统交互的界面，为企业带来灵活性的同时也带来了一定的管理复杂度。容器的出现，在虚拟化的基础上向上封装了一层，逐步成为云平台和与客户系统交互的新界面之一，应用的构建、分发和交付得以在这个层面上实现标准化，大幅降低了企业 IT 实施和运维成本，提升了业务创新的效率。
① 业务复杂需要云原生：在微服务架构中，应用的数量大幅增加，性能、一致性等问题越来越严重，架构变得越来越复杂，大量服务的治理也变得充满挑战，如何处理和解决这些问题？云原生技术的出现解耦了很多复杂性：
- 以
Docker 为代表的容器技术实现了应用与运行环境的解耦，众多业务应用负载可以被容器化，而且应用容器化满足了敏捷、可迁移、标准化的需求。 -
Kubernetes 的出现实现了资源编排调度与底层基础设施的解耦，应用和资源的管控也开始得心应手，容器编排实现资源编排、高效调度。 - 以
Istio 为代表的服务网格技术实现了服务实现与服务治理能力的解耦。
② 业务创新需要云原生：互联网公司经常提到他们每天实现几十次，甚至上百次的发布。为什么频繁发布如此重要？
- 如果你可以每天实现上百次发布，那么你就可以几乎立即从错误的版本中恢复过来；如果你可以立即从错误中恢复过来，那么你就能够承受更多的风险；如果你可以承受更多的风险，那么你就可以做更“疯狂”的试验一一这些试验结果可能会成为你接下来的竞争优势。
③ 业务不确定性需要云原生：纵观 IT 应用服务器的发展历史：大型机→小型机→x86 服务器→虚拟机→容器 →Serverless，越来越朝着轻量化的方向发展，这也符合云原生敏捷基础设施的策略。轻量化意味着更好的弹性，应用部署时间相应减少：月（大型机）→天（小型机）→小时（x86 服务器）→分钟（虚拟机）→秒（容器）→毫秒（Serverless）。极致的弹性是企业解决业务不确定性的有效手段。
03 云原生设计原则
① 去中心化原则：中心化意味着单点，为了具备良好的线性扩展能力，分布式系统要求去中心化，避免单点故障。对于系统的服务能力，随着资源加入，微服务的性能和容量能够呈线性扩展；
② 松耦合原则
- 实现的松耦合：即服务消费端不需要依赖服务契约的某个特定实现，这样服务提供端的内部变更就不会影响消费端）
- 时间的松耦合:典型的是异步消息队列系统，由于有中介者，生产者也不需要马上等到回复
- 位置的松耦合:典型的是服务注册中心，消费端完全不需要直接知道提供服务端的具体位置，而都通过注册中心查找服务来访问
- 版本的松耦合:消费端不需要依赖服务契约的某个特定版本来工作，这就要求服务的契约在升级时要尽可能地提供向下兼容性；
③ 面向失败设计原则：为了保证系统的健壮性，软件设计领域中一个很重要的原则是，所有的外部输入和外部依赖都是不可信的，系统间依赖的调用随时可能会失败，也包括硬件基础设施服务随时可能死机，还有后端有状态服务的系统能力可能有瓶颈。总之在发生异常时能够快速失败，然后快速恢复，以保证业务永远在线，不能让业务半死不活地僵持着。
④ 无状态原则：云原生的应用服务设计尽可能是无状态的，使得业务天生具有扩展性，在业务流量高峰和低峰时期，依赖云的特性自动弹性扩容、缩容，满足业务需求。无状态指的是服务在处理请求时，不依赖除请求本身以外的其他内容，也不会有除响应请求之外的额外操作。有状态转无状态主要有以下两种手段。
- 状态分离：服务端所有的状态信息统一保存在外部独立的分布式存储中（如缓存、消息队列、数据库）。
- 请求附带全部状态信息：将状态信息前置，丰富请求的入参，将需要处理的数据尽可能都通过上游的客户端放到入参中传过来。
⑤ 不变性原则：实现不变性原则的前提是，基础设施中的每个服务、组件都可以自动安装、部署，不需要人工干预。所有的资源都可以随时拉起、随时释放，同时以 API 的方式提供弹性、按需的计算、存储能力。每个服务或者组件在安装部署完成后将不会发生更改，如果要更改，就丢弃老的服务或组件，并重新部署一个服务或组件。另外，为了提升可用性，我们应该尽量减少故障修复时间，要知道替换的速度远远快于修复的速度。
⑥ 自动化驱动原则：分为持续集成、持续部署、持续交付等阶段，用来确保需求的提出、设计开发测试，再到代码快速、安全地部署到生产环境中。持续集成是指每当开发人员提交了一次改动，就立刻进行构建、自动化测试，确保业务应用和服务均能符合预期，从而可以确定新代码和原有代码能否正确地集成在一起。持续部署是指使用完全的自动化过程把每个变更自动提交到测试环境中，触发自动化测试用例，测试验证通过后将应用安全地部署到生产环境中，打通开发、测试、生产等各个环节。持续交付是软件发布的能力，在持续集成完成后，能够提供到预发布之类的环境上，满足生产环境的条件。
