云原生模式-设计拥抱变化的软件一
云原生模式–设计拥抱变化的软件（一）
目录
本文主体为《云原生模式–设计拥抱变化的软件》的读书笔记，本书从亚马逊云服务（AWS）的一次宕机事故说起，由浅入深的讲解了在云原生开发模式下的软件架构设计。
众所周知超融合基础架构、网络基础架构作为现代大型云计算数据中心的核心硬件资产已为上层应用提供的非常健壮的计算、网络资源并且在应用的驱动下基础架构设计也在不断演进，身为架构师的我们需要思考如何在“云计算”潮流下充分利用基础架构设备厂商提供的硬件底座，设计适应于未来的应用，榨干每一滴硬件资源充分发挥云计算优势。
一、AWS事故带来的思考
2015年9月20日，星期日，Amazon Web Services（AWS，亚马逊公司旗下的云计算服务平台）经历了一次重大的宕机事故。随着越来越多的公司在AWS上运行自己的关键系统，AWS宕机可能会导致一系统影响深远的事故。在这种情况下，Netflix、Airbnb、Nest、IMDb以及很多其他公司都经历了宕机，服务的客户受到影响，最终企业利益受到损失。AWS核心宕机持续了大约5小时（或者更长，取决于你如何计算），而受AWS影响的客户则花费了更长时间才将其系统从故障中恢复。 如果你是Nest公司，你向AWS付费是因为希望专注于为客户创造价值，而不用关心基础设施的问题。作为协议的一部分，AWS负责保证其系统的正常运行，从而让你的系统也能够正常运行。如果AWS宕机，那么你很容易把自己系统的宕机都归咎于亚马逊。
但是你错了！亚马逊不应该为你的宕机负责！后文我将详细解释这个逻辑，为大家说明如何使用软件架构的设计规避基础架构非计划抖动带来的非预期业务不可用。
二、云原生上下文，为什么·是什么·发展历程
上图为大家简略展示了云原生技术的主要技术栈，每个技术栈都可以为应用的云原生开发注入伟大力量。
1、现代应用的需求
在展开后文之前，我需要为各位回顾现代大型企业应用的几个要求，毕竟能解决需求的新兴技术才更有价值。
- 零停机时间（一直在运行）
任何情况下保证业务发布：不得不承认任何优秀的代码都很难做到部署软件的同时保证持续运行
- 万物互联物联网（多种设备）
适应设备泛在接入，提供计算服务的基础设施也势必不断变化
- 缩短反馈周期（频繁发布）
从需求产生到快速落地，从新需求到频繁变更
- 移动端和多设备支持（多种设备）
设备间的无缝切换，频繁刷新
- 数据驱动（随时随地）
大型、集中式、共享式数据库不复存在
综上所述，我们知道为满足应用的高度分布式以及不断变化的特点，就要求应用实例的冗余多实例部署、适应云基础设施运行环境，松耦合、微服务模块化、弹性伸缩。所以不难得出云原生软件是高度分布式的，运行在不断变化的环境中，而且自身也在不断的发生变化软件。
2、什么不是云原生
云原生并不是解决所有问题的方法论，我们需要云原生但不意味着所有应用都进行云原生改造。最终一致性是云原生的核心，强一致性应用不适用云原生开发模式。
软件不是分布式部署、软件组件很少发生变化、不需要应付大规模接入的软件也不需要进行云原生改造。
3、什么是云原生
- 技术变革，思想先行，云原生是一套技术体系和方法论。云原生（CloudNative）是一个组合词
- Cloud表示应用程序位于云中，而不是传统的数据中心
- Native表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用和发挥云平台的弹性+分布式优势
- 通过云原生技术，构建出更易弹性扩展的应用。应用可以运行在不同的环境中，私有云、公有云、混合云、多云场景
- 云原生实现：容器、微服务、服务网格、Serverless、DevOps、声明式API管理、不可变基础架构等
- 云原生应用：通过云原生技术开发的程序，称为云原生应用，应用与底层基础架构耦合较轻，所以更易于迁移，它可以充分地利用云所提供的能力，因此云原生应用的开发、部署、管理相对于传统的应用程序更加高效和便捷
4、云原生的3个实体
通过上图可知在云原生开发模式中主要涉及3个开发实体，分别是：云原生应用、云原生持久化存储、云原生交互
5、为什么需要云原生应用（部署方便）
5.1传统应用困境 – 部署困难
- 碎片化的变化：环境的变化、部署组件的变化使得传统应用部署十分困难。我们不难发现在传统应用部署流程上经常会遇到各种各样意想不到的报错，这些报错往往由于安装环境与开发环境的差异导致，作为终端用户我们很难排查这些原因，设计开发团队往往又过于理想化应用使用者的安装环境，两者矛盾巨大
- 认为变化是例外：稳态的设计理念使得上线即是运维，开发团队不再介入
- 生产环境的不稳定性：生产与开发环境差别巨大，部署上线时间少而短，运维疲于救火
- 有风险的投产：新部署版本的不确定性可能存在各种各样的bug，如果我们搭建模拟以便完整测试又会消耗大量人力、物力，在降本增效的今天这是不显示的
5.2应用部署困难的新时代解决方案—云原生应用
为解决以上痛点我们提出了如下解决方案：
- 持续交付：迭代抢占市场，敏捷交付船小好掉头。引入迭代开发模式，尽可能的缩短应用发布时间，让市场决定开发方向。
- 可重复性：统一开发、测试、交付镜像环境。控制运行时环境与基础镜像，通过代码托管保证应用统一，BUG可复现，结果可预测
- 安全部署：并行部署版本化的服务，精确的监控，可控的路由
- 变化是一定的：放弃“完成”任务的想法，让系统永远在监控，将实际状态与期望状态进行比较，引入自动化机制恢复理想状态
6、先聊聊容器（Container）和云原生平台（PAAS）
云原生平台将容器作为核心，为软件提供大量功能，应用开发团队与云原生平台团体分而治之各司其职。
常见的云原生平台应该为容器提供如下功能：
- 监视应用的健康状态
- 在基础设施上使用互斥策略部署应用实例
- 为容器分配IP地址
- 动态路由到应用实例
- 配置注入
云原生平台应该支持如下特性
支持“不断变化”
与基础设施解耦合，跨云平台编排，便捷的生命周期管理容器
- 支持“高度分布式”
服务发现、服务注册：引入DNS模式，互联互通配置不再硬编码于源码中，以URL方式访问应用实例
服务配置：在云原生平台的帮助下容器自主完成配置获取
容器小而精：资源消耗少，创建时间短
7、云计算的发展历程
我相信各位对这张图的熟悉了解程度不亚于我，在FAAS阶段我们甚至无需关注软件的版本更新维护，只需要提供业务逻辑源码直接调用FAAS提供商的接口即可为业务提供Pay-As-You-Go随买随用的服务模式，用户无需关注计算、网络资源可用量及其健壮性只需付费调用接口，FAAS供应商更可以实现比IAAS、PAAS更精细的计费逻辑，为用户提供按次调用收费的云计算业务。