云原生这个词其实由来已久，IT行业永远也不缺乏新概念。2015 年，Pivotal公司的Matt Stine提出Cloud Native这一概念，并结合这个概念包装了自己的新产品Pivotal Web Service和Spring Cloud。在Matt Stine所著的Migrating to Cloud Native Application Architectures一书中，他对云原生的概念进行了详细的阐述。该书的中文版《迁移到云原生应用架构》已经在GitHub 上开源，感兴趣的读者可浏览或下载。

什么是云原生
云原生准确来说是一种文化，更是一种潮流，它是云计算的一个必然导向。意义在于让云成为云化战略成功的基石，而不是障碍。
自从云的概念开始普及，许多公司都部署了实施云化的策略，纷纷搭建起云平台，希望完成传统应用到云端的迁移。但是这个过程中会遇到一些技术难题，上云以后，效率并没有变得奇高，故障也没有迅速定位。
为了解决传统应用升级缓慢、架构臃肿、不能快速迭代、故障不能快速定位、问题无法快速解决等问题，云原生这一概念横空出世。云原生可以改进应用开发的效率，改变企业的组织结构，甚至会在文化层面上直接影响一个公司的决策。
另外，云原生也很好地解释了云上运行的应用应该具备什么样的架构特性——敏捷性、可扩展性、故障可恢复性。
综上所述，云原生应用应该具备以下几个关键词：

敏捷
可靠
高弹性
易扩展
故障隔离保护
不中断业务持续更新
以上特性也是云原生区别于传统云应用的优势特点。
从宏观概念上讲，云原生是不同思想的集合，集目前各种热门技术之大成，具体包括如下图所示的几个部分。
%title插图%num

微服务

  • 应用间通过RESTful API进行通信
  • 可以被独立的部署、更新、scale和重启

并不是所有的应用都适合微服务化，也不是说将一个单体应用拆分的越细越好。谈到微服务就不得不提到”十二因素法则“，如下图所示。

%title插图%num

DevOps
自动化发布管道、CI工具
快速部署到生产环境
开发、运维协同合作
设计系统的组织，*终产生的设计等同于组织之内、之间的沟通结构。
——康威定律
开发和运维看似是两个貌似互相矛盾的角色。因为开发负责业务的持续迭代，会为系统引入大量的变更，如果系统正在稳定运行，那么每次上线和发布都给系统带来新的风险。而运维追求的是系统可用性、SLA、而变更就意味着可能带来的不稳定。

持续交付
频繁发布、快速交付、快速反馈、降低发布风险
构建自己的CI/CD 持续构建管道与发布流程，如使用Jenkins。

容器化
微服务的*佳载体
容器化*大的好处是保持运行环境的一致性，只要应用可以打包成容器镜像（我们通常使用Docker容器），就可以一次编译，然后到处运行。
同时，容器也可以作为应用运行的*小组件来部署，且更适合作为无状态应用的运行。结合容器编排工具（如Kubernetes）将大大增强系统的扩展性和自愈能力，轻松应对大流量下的高并发场景，加快业务的迭代速度，Kubernetes作为CNCF成员的核心，本身就是与云原生应用的理念紧密结合的产物。
云原生中包含的不同思想，与其所解释的云上应用架构应该具备的特性几乎是一一对应的。

DevOps、持续交付对应更快的上线速度，即敏捷性。
微服务对应可扩展性及故障可恢复性。
敏捷基础设施实现了扩展能力的资源层支持。
康威定律在组织机构和流程上确保架构特性能够快速实施。
后记
云时代的云原生应用大势已来，将传统的单体架构应用迁移到云原生架构上，你准备好了吗？
俗话说，意识决定行动。在迁移到云原生应用之前，我们需要先对 Cloud Native（云原生）的概念、组织形式、实现技术有一个大概的了解，这样才能真正进入到云原生架构实践中。
公有云大行其道，私有云厂商也不断涌现，为了业务的快速迭代，为了快速形成自己的产业生态，各个业务需求方都在积*的评估和采纳公有云方案。
真正的云原生应用架构不应该限制应用的开发语言和架构选择，虽然目前以Java应用的开发者居多，在云原生概念出来之前就已经积累了不少分布式应用管理经验，如Netflix OSS。
实际上云原生应用架构应该适用于任何应用类型。云原生应用架构适用于异构语言的程序开发，不仅仅是针对Java语言。目前云原生应用生态系统已经初具规模，CNCF成员不断发展壮大，基于Cloud Native的创业公司不断涌现，Kubernetes引领容器编排潮流和 Service Mesh技术，Go语言的兴起等，这些都为将传统应用迁移到云原生架构提供了更多的选择。
————————————————

原文链接：https://blog.csdn.net/broadview2006/article/details/80131068