时代在进步，周末突然回想起N年前的开发模式与现在相比简直是翻天覆地。虽然现如今的开发模式对于开发者的要求逐步降低，但我们自身不能降低要求。读书有感，一起来了解下云原生给我们带来的变化。
什么是云原生
云原生可分解为“云”（Cloud）和“原生”（Native）两个词。
这里还隐藏了一个词——“计算”（Computing），因为云原生本质上是一种与云计算（Cloud Computing）相同的计算方式，因此通常我们在说云原生的时候，实际上是暗指云原生计算（Cloud Native Computing）
其实大家可以想想，从以前到现在，不知不觉中我们的开发部署已经发生了翻天覆地的变化。
在云计算普及前我们想发布一个应用上线是不是需要如下流程：
买服务器 - 》 IDC机房装服务器 -》装Linux系统 -》开发应用 -》 配置Tomcat -》 上传war到服务器 -》 配置Ningx -》配置域名解析
其中还需要配置Mysql 等各种配置才能把应用跑起来。
这种自建的方式有很多缺点：
-
扩容维护费力，业务突然激增都来不及操作
-
安全系差，应用的部署权限、整体流程安全漏洞太多
-
部署流程不规范，缺少自动化的过程。好点的会搞个运维脚本，差点的完全人肉运维。每次部署都是一次生死考验
所以为了解决里面的各种问题，企业开始推动上云操作，随着技术发展又演变到了云原生时代
云计算：云计算就好比自来水（IT资源），每家想喝水不必自己建一个自来水厂。只需要打开自来水就好了。
云计算企业给大家提供了自来水一样的IT资源获取方式（网络、服务器等等）
云原生：是一套构建、运行应用的技术体系和方法论，一切的开发都基于云，技术栈都是基于开源、开放的技术标准。
所以，从云原生的定位可以看到，云原生包含大量新的PaaS层技术和新的开发理念，是释放云计算价值的最短路径，也推动着云计算的再升级。
云原生是云计算的再升级
云原生不仅是对使用云的应用架构的再升级，也是对云平台的技术和云服务的再升级。
从构建现代化应用的角度，我们可以发现，云原生对应用的重构体现在应用开发的整个生命周期中
下面我们就从几个角度来说一说：
-
重塑研发流水线
-
重新定义软件交付模式
-
运维模式的升级
-
应用架构的升级
重塑研发流水线
每个企业都希望具备应用持续发布能力，但其中有着诸多挑战，比如：
- 配置基线
- 版本管理
- 自动化
特别是当应用具有多个不同的硬件环境、软件、依赖组合时，如何进行有效的变更管理才能保证任何变化都不会使这些组合出现错误？
开发者经常遇到的问题就是本地环境测试都正常，一上线就各种依赖配置出现问题，非常头疼。
升级UP
而容器结合GitOps和不可变的基础设施，对整个应用打包和分发就可实现软件环境的整体部署。
也就是我们对运行环境的所有变化，都必须提交GIt,经过版本管理后重新持续集成，形成新的制品并进行部署。这样我们对运行环境所有的改变都有迹可循。如果某次变更后软件出现异常，可根据Git上的记录回溯到上次正常运行的版本重新部署。
整个过程高度自动化，并且具备版本跟踪和回溯能力，也解决了持续发布遇到的挑战，减少了CI/CD中错误发生的几率，从而提高了整体的质量和效率。
重新定义软件交付模式
传统的软件交付过程中，交付人员需要通过文档学习和技能提升来填平不同环境的差异，这本质上是一个知识转移链条，依赖于知识的质量和交付人员的水平，任何环节出现问题，都会导致软件交付困难。
在传统软件交付模式下，交付人员需要学习手册/文档，然后完成应用的 "安装配置" 和“与老系统的集成”方面的工作。
安装配置点：包括硬件上的安装配置、软件的安装配置和应用本身的安装配置。
集成点：包括新环境中硬件、软件和老系统的集成工作（如：监控、服务调用、消息集成等）
所以传统软件交付很难自动完成相关的配置集成，原因就是上层所依赖的底层环境在不同交付环境中很多是不同的。
升级UP
我们来看下云原生的交付模式：
相较于传统模式，云原生软件交付模式主要有如下几个变化：
1、利用容器做整体交付
-
整体交付减少容器内部组件之间的安装配置工作
-
可通过工具和脚本自动完成软件交付，提升效率
2、将Git作为“Single Version of Truth”（唯一真实版本）
-
Git作为交付和运维的仓库，记录了所有软件变更的版本、配置参数、脚本、用户名和密码等信息
-
所有脚本、工具和Kubernetes的Operator，都读取Git中的信息作为事实的唯一来源，即使是做版本升级或回滚，以及变更评审，都以Git中的信息为准。
3、声明式API
-
声明式API首先是“告诉”系统期望的目标状态是什么（如：在这种环境下部署需要用到两个实例）
-
声明式API实际上它是一种开发理念的彻底升级，因为系统更多的是关注需要什么（达到什么状态），所有的“如何做”都是围绕这个目标状态来服务的
4、尽量采用OpenAPI作为系统间的集成方式
-
标准化的OpenAPI更有利于系统间的集成，因为OpenAPI有明确的契约描述或接口规格描述，且提供了各种开放的工具，可以用来做IoT（连通性测试）、SIT（集成测试）等
-
其开放接口（比如，基于RESTful）的特性，可以实现快速集成，从而提升集成的效率
所以，云原生软件交付模式可以方便地提升软件交付过程的自动化程度，更便于企业实施CI/CD，也可以极大地提升交付效率。
运维模式的升级
传统运维更多的是面向操作的运维，其本质是基于规则的运维。也就是运维人员提前准备好规则 ，在满足规则的情况下采取相应的操作。（如：软件宕机采取故障迁移操作）
而这大部分的运维操作都是需要人工完成的，存在遗漏和操作错误的风险，而风险和故障带来的经验教训继续被规则化，这些都导致了运维无法形成完整的闭环，难以被持续优化。
举例：我们编写自动化脚本完成Redis的升级。
在升级脚本的过程中，容易遗漏的一点就是升级后对各种可能导致Redis工作异常的情况进行完整检测。
如通过redis-cli命令进行延迟测试，禁止THP（Transparent Huge Page，透明大页）甚至完整的内存测试。
这些检测中的绝大部分应用在升级或启动Redis时都不会做，毕竟这些故障的发生概率很低且验证成本很高，一般是当业务系统因此产生了对应的故障时才会进行补救。
升级UP
云原生运维可以基于标准化基础设施的运维，通过完整的可观测性实现系统中各类异常的实时可见，也可以结合声明式API实现自动化运维
举例：Redis升级为例
由于基于Kubernetes部署的Redis所依赖的操作系统及第三方库版本、核心参数配置全都打包到了容器中，因此不会出现所安装的环境产生THP的问题；
安装后的checklist可以被沉淀到负责安装部署的Operator中，在readiness-probe中可以用redis-cli增加延迟测试；
Prometheus可用于观察完整的Redis工作状态；Open Tracing可用于跟踪应用对Redis的每次调用是否存在异常；等等。
所有这些数据全部整合在一起后作为metrics（度量）信息导出，由Operator通过API自动、实时获取，并将异常的Redis服务器下线、替换或者升级
应用架构的升级
应用使用云原生技术有如下两种方式：
re-platform： 这种方式是在不重构代码或不重写代码的情况下，尽量采用云原生技术。（如：使用容器对应用进行打包和部署，把Kafka替换为云服务，把MySQL替换为RDS）
re-build： 这种方式需要重构甚至完全重写应用 （如：把单体架构（Architecture）改为微服务架构，实施存储状态分离，业务实现采用Serverless技术编写，采用事件驱动架构）
re-platform与re-build，两者最大的差别是前者没有进行架构升级，这样就很难构建更好的现代化应用。
从现代化应用特征的角度来，基于容器、可管理、认证和鉴权等的云原生架构确实不需要re-build。
微服务、无状态应用、API会优先选择应用重构，而弹性、可观测性、高可用、自动化等在应用重构的情况下会做得更好
总结：
所谓云原生，就是在上云的过程中，充分发挥云平台的弹性计算、弹性存储的优势，尽量把应用设计成适合云计算的架构，把部署设计成简单易用的流程，这样才能实现业务快速上线，快速迭代。
其真正的目的：降低开发成本，是开发者专注于业务。提升软件交付能力，专业的人做专业的事。
