云原生从字面意思上来看可以分成云和原生两个部分。云是和本地相对的，传统的应用必须跑在本地服务器上，现在流行的应用都跑在云端，云包含了 IaaS,、PaaS 和 SaaS。

原生就是土生土长的意思，我们在开始设计应用的时候就考虑到应用将来是运行云环境里面的，要充分利用云资源的优点，比如️云服务的弹性和分布式优势。

围绕云原生的对话会直接潜入诸如容器化和微服务之类的技术选择中。这些绝对是云原生项目的潜在组成部分，但绝对不是全部。在本系列文章中，我们将从几个不同的角度探讨本机云，当然包括技术和基础架构，还包括架构，设计，以及可能最被忽略的人员和流程。用最简单的术语来说，云原生意味着不仅要迁移到云，还要充分利用云基础架构和服务的独特性来快速交付业务价值。

在该术语本身开始使用之前，就已经存在云原生概念。从某种意义上说，云原生始于公共云供应商开始提供对弹性计算能力实例的轻松且负担得起的访问。问题就变成了，如何利用该新基础架构的灵活性来编写应用程序，以及由此带来的业务收益?

在过去十年中，云原生方法和技术发生了很大变化，并且仍在不断发展，但是云原生应用程序要实现的核心技术和业务目标却保持不变。这些包括：

敏捷性和生产力：实现以业务指标为指导的快速创新。降低维护风险，并使环境保持最新状态。

弹性和可伸缩性：以自我修复和无停机的持续可用性为目标。提供弹性缩放和无限容量的感知。

优化和效率：优化基础设施和人力资源的成本。启用位置和提供者之间的自由移动。

当我们回顾云原生的“为什么”时，我们将在后面的文章中进一步细分这些目标，但是希望即使是从这个简单的定义来看，也应该清楚的是，云原生的范围比仅仅向新的类型迁移还广。基础设施。但是，尽管这些目标是准确的，但很难看出它们专门适用于本机云。我们需要做更多的工作来定义云原生的真正含义。

与云原生相关的流行参考点(例如微服务)和较早的清单(例如 12factor 应用)可能会让您得出结论，云原生是对体系结构样式的描述，其他选择也随之而来。毫无疑问，云原生架构确实存在。但是，为了在云原生平台上取得成功，公司必须采取更全面的看法。除了架构和基础架构决策外，还存在组织和流程决策。

微服务

微服务解决的是我们软件开发中一直追求的低耦合+高内聚，记得有一次我们系统的接口出了问题，结果影响了用户的前台操作，于是黎叔拍案而起，灵魂发问：“为啥这两个会互相影响？！”

微服务可以解决这个问题，微服务的本质是把一块大饼分成若干块低耦合的小饼，比如一块小饼专门负责接收外部的数据，一块小饼专门负责响应前台的操作，小饼可以进一步拆分，比如负责接收外部数据的小饼可以继续分成多块负责接收不同类型数据的小饼，这样每个小饼出问题了，其它小饼还能正常对外提供服务。

DevOps

DevOps 的意思就是开发和运维不再是分开的两个团队，而是你中有我，我中有你的一个团队。我们现在开发和运维已经是一个团队了，但是运维方面的知识和经验还需要持续提高。

持续交付

持续交付的意思就是在不影响用户使用服务的前提下频繁把新功能发布给用户使用，要做到这点非常非常难。我们现在两周一个版本，每次上线之后都会给不同的用户造成不同程度的影响。

容器化

容器化的好处在于运维的时候不需要再关心每个服务所使用的技术栈了，每个服务都被无差别地封装在容器里，可以被无差别地管理和维护，现在比较流行的工具是 docker 和 k8s。

所以你也可以简单地把云原生理解为：云原生 = 微服务 + DevOps + 持续交付 + 容器化