一、云原生概念的诞生
云原生（Cloud Native）的概念，由来自Pivotal的MattStine于2013年首次提出，被一直延续使用至今。这个概念是Matt Stine根据其多年的架构和咨询经验总结出来的一个思想集合，并得到了社区的不断完善，内容非常多，包括DevOps、持续交付（Continuous Delivery）、微服务（MicroServices）、敏捷基础设施（Agile Infrastructure）和12要素（The Twelve-Factor App）等几大主题，不但包括根据业务能力对公司进行文化、组织架构的重组与建设，也包括方法论与原则，还有具体的操作工具。采用基于云原生的技术和管理方法，可以更好地把业务生于“云”或迁移到云平台，从而享受“云”的高效和持续的服务能力。
二、云原生概念的理解
云原生从字面意思上来看可以分成云和原生两个部分。
云：云是和本地相对的，传统的应用必须跑在本地服务器上，现在流行的应用都跑在云端，云包含了IaaS,、PaaS和SaaS。
原生：就是土生土长的意思，我们在开始设计应用的时候就考虑到应用将来是运行云环境里面的，要充分利用云资源的优点，比如️云服务的弹性和分布式优势。
云原生：是一种构建和运行应用程序的方法，它利用了云计算交付模型的优势；是关于如何创建和部署应用程序，和位置无关。这意味着应用程序位于云中，而不是传统数据中心。
三、云原生概念的应用
最近讨论云原生应用越来越多。关于云原生应用，它并不是一个产品，简单地说，就是大多数传统的应用，不做任何改动，都是可以在云平台运行起来，只要云平台支持这个传统应用所运行的计算机架构和操作系统。只不过这种运行模式，仅仅是把虚拟机当物理机一样使用，不能够真正利用起来云平台的能力。
云并非把原先在物理服务器上跑的东西放到虚拟机里跑，真正的云化不仅是基础设施和平台的事情，应用也要做出改变，改变传统的做法，实现云化的应用——应用的架构、应用的开发方式、应用部署和维护技术都要做出改变，真正的发挥云的弹性、动态调度、自动伸缩……一些传统IT所不具备的能力。这里说的“云化的应用”也就是“云原生应用”。云原生架构和云原生应用所涉及的技术很多，如容器技术、微服务、可持续交付、DevOps等。
云原生应用最大的特点就是可以迅速部署新业务。在企业里，提供新的应用程序环境及部署软件新版本通常所需时间以日、周甚至以月计算。这种速度严重限制了软件发布所能承受的风险，因为犯错及改错也需要花费同样的时间成本，竞争优势就会由此产生。
所以云原生不是一个产品，而是一套技术体系和一套方法论，而数字化转型是思想先行，从内到外的整体变革。更确切地说，它是一种文化，更是一种潮流，是云计算的一个必然导向。意义在于让云成为云化战略成功的基石，而不是障碍。它可以根据商业能力对公司进行重组的能力，既包含技术、也包含管理，可以说是一系列云技术和企业管理方法的集合，通过实践及与其他工具相结合更好地帮助用户实现数字化转型。
四、云原生应用的四大要素
我们可以简单地把云原生理解为：云原生 = 微服务 + DevOps + 容器化 + 持续交付。
1、微服务
微服务可以解决我们软件开发中一直追求的低耦合+高内聚的问题，但是微服务怎么做呢？
（1）微服务核心方法就是切割，遵循康威定律即系统的服务划分应该是根据组织架构的功能来划分。1968年康威就提出了这个想法，个人认为拿来做微服务的切割非常适用。
按照组织架构划分的优势在于：
A、内聚更强，所有遵循同一种业务准则的人内聚在一起，就容易解决问题。
B、服务解耦，变更容易，更加敏捷。当做到解耦合的时候，要变更就容易。所以微服务应该是切分成这个样子，由上而下来切，根据Function来切。
（2）另外还有一个划分微服务的技巧，可以运用领域驱动设计(Domain Driven Design)的理论，而领域驱动设计亦可算是面向物件的一种设计思维；聚合可以让微服务划分更有依据，也让未来的系统变更具有弹性。
值得一提的是在微服务架构中，如何在分散的服务中进行事物，利用领域驱动设计的Event Souring进行设计，是目前最好的解决办法。
2、DevOps
DevOps如果从字面上来理解就是Dev（开发人员）+Ops（运维人员），实际上，它是一组过程、方法与系统的统称，其概念从2009年首次提出发展到现在，内容也非常丰富，有理论也有实践，包括组织文化、自动化、精益、反馈和分享等不同方面。开发和运维不再是分开的两个团队，而是你中有我，我中有你的一个团队。大部分公司缺乏运维基本上是开发的兼职，运维方面的知识和经验还需要持续提高。
首先，组织架构、企业文化与理念等，需要自上而下设计，用于促进开发部门、运维部门和测试部门之间的沟通、协作与整合，简单而言组织形式类似于系统分层设计。
其次，自动化是指所有的操作都不需要人工参与，全部依赖系统自动完成，比如上述的持续交付过程必须自动化才有可能完成快速迭代。再次，DevOps的出现是由于软件行业日益清晰地认识到，为了按时交付软件产品和服务，开发部门和运维部门必须紧密合作。
总之，DevOps强调的是高效组织团队之间如何通过自动化的工具协作和沟通来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。在内部沟通上，你可以想象DevOps是一个敏捷思维，是一个沟通的文化。当运营和研发有良好的沟通效率，才可以有更大的生产力。如果你的自动化程度够高，可以自主可控，工作负担降低，DevOps能够带来更好的工作文化、更高的工作效率。
3、持续交付
持续交付的意思就是在不影响用户使用服务的前提下频繁把新功能发布给用户使用，要做到这点非常非常难。敏捷开发要求持续交付，因为敏捷开发要求随时有一个版本可以上到大群环境，所以要持续交付。
换句话说，持续交付就是不误时开发。举一个例子，有些公司非常喜欢谈需求，谈很久，可是开发只剩1/3时间就开发完成，然后交付，再上线运营。这就会碰到一个问题，就是你开始谈需求到最后交付产品的时间，短则三月，长则半年，这中间市场已经变化了，需求也随之变化了。因此市场上出现了新的想法，即是不是能够小步快跑，把交付的周期缩短一点，我可以实现快速交付，每次交付都可以重新确认方向，这样尽量避免与未来期待的落差。
用小步快跑的方式，打破瀑布式开发流程。那么问题来了，持续交付对于开发的人员的需求、开发的方式有改变，那它对于开发有影响吗？如果说公司的开发团队一天可以交付五次，那运维团队要帮忙部署一次吗？现在公司大部分部署都是运维团队帮忙部署应用的，运维团队部署五次，要改版五次就需要部署一次，这是无法实现的。而且每次部署的时候都要面对停机，而实际公司的应用经不起一天停机五次部署，在互联网的思维之下，零宕机时间已经是现在企业的基本要求。于是“蓝绿部署”的概念应运而生。即在一个环境里面，第一版还在线上服务，第二版先做封测，封测完成后，让外面的流量进来一些，看log是不是开发人员要的，确认后再把全部的流量导到新的版本上。
但“蓝绿部署”在系统过多过复杂的情况下，在传统架构上实现非常困难，所以企业要做到zero down time的持续交付就需要有良好的平台與工具协助。因此，持续交付的优势在于，它可以缩小开发者认知，重新确认开发方向。
4、容器技术
容器化的好处在于运维的时候不需要再关心每个服务所使用的技术栈了，每个服务都被无差别地封装在容器里，可以被无差别地管理和维护，现在比较流行的工具是docker和k8s。
Docker是软件行业最受欢迎的软件容器项目之一；而Kubernetes是软件容器领域的另一个值得关注的项目。Kubernetes是一个允许自动化部署、管理和伸缩容器的工具。为了便于管理其容器，谷歌建立了Kubernetes。它提供了一些强大的功能，例如容器之间的负载均衡，重启失败的容器以及编排容器使用的存储。
大家在实战中一定会遇到一些批次的管理，另外还有所谓的数据库的部分，这才开始有容器技术（Docker和Kubernetes），容器为云原生应用程序增加了更多优势。使用容器，你可以将微服务及其所需的所有配置、依赖关系和环境变量移动到全新的服务器节点上，而无需重新配置环境，这样就实现了强大的可移植性。
五、云原生和本地部署应用程序之间的差异
云原生应用程序开发采用与传统企业应用程序完全不同的体系结构。
1、编程语言
编写在公司服务器上运行的本地部署应用程序往往使用传统语言编写，如C/C ++，C＃或其他Visual Studio语言（如果部署在Windows Server平台上）和企业级Java。如果它在大型机上，可能使用Cobol。
云原生应用更有可能以网络为中心的语言编写，这意味着使用HTML，CSS，Java，JavaScript，.Net，Go，Node.js，PHP，Python和Ruby。
2、可更新
云原生应用程序始终是最新的，云原生应用始终可用。
本地部署应用程序需要更新，并且通常由供应商按订阅提供，并且在安装更新时需要停机。
3、弹性
云原生应用程序通过在峰值期间增加的资源来利用云的弹性。如果你的基于云的电子商务应用程序使用频繁，你可以将其设置为使用额外的计算资源，直到峰值消退然后关闭这些资源。云原生应用可以根据需要调整增加资源和规模。
本地部署应用程序无法动态扩展。
4、多租户
云原生应用程序在虚拟化环境中工作，并与其他应用程序共享资源没有问题。
许多本地部署应用程序要么在虚拟环境中不能正常工作，要么根本不工作，必须要非虚拟化环境。
5、连接资源
本地部署应用程序与网络资源的连接相当严格，例如网络，安全性，权限和存储。其中许多资源需要进行硬编码，如果移动或更改了任何内容，它们就会中断。
网络和存储在云端完全不同。当你听到“重新平台化”一词时，通常是为了适应网络，存储甚至数据库技术的变化，以允许应用程序在云中运行。
6、停止时间
云中存在比本地部署更大的冗余，因此如果云供应商遭受中断，则另一个冗余区域可以消除中断。
本地部署应用程序可能已准备好故障转移，但如果服务器出现故障，应用程序可能会崩溃。
7、自动化
云计算的大部分都是自动化的，其中包括应用程序管理。 云原生交付的好处，特别是速度和敏捷性，依赖于可靠，经过验证和经过审核的已知良好流程的基础，这些流程根据自动化和编排工具的需要而不是通过人工干预重复执行。工程师应该考虑自动化是不止一次做的任何事情，以实现可重复性，自助服务，敏捷性，可扩展性以及审计和控制。
本地部署应用程序必须手动管理。
8、模块化设计
本地部署应用程序往往在设计上是单一的。他们肯定会将一些工作卸载到库中，但最终它是一个包含大量子程序的大应用程序。云原生应用程序更加模块化，许多功能分解为微服务。这允许在不需要时关闭它们，并将更新推广到那个模块，而不是整个应用程序。
9、无状态
云的松耦合特性意味着应用程序与基础架构无关，这意味着它们是无状态的。云原生应用程序将其状态存储在数据库或其他外部实体中，因此实例可以来取，应用程序仍然可以跟踪应用程序在工作单元中的位置。 这是松耦合的本质。不依赖于基础架构允许和应用程序以高度分布的方式运行，并且仍然保持其状态独立于底层基础架构的弹性性质。
大多数本地部署应用程序都是有状态的，这意味着它们会在运行代码的基础架构上存储应用程序的状态。因此，在添加服务器资源时可能会破坏应用程序。
六、云原生的挑战
客户犯下的一个重大错误就是试图将旧的本地部署应用程序直接并迁移到云端。“试图利用现有的应用程序，特别是单一的遗留应用程序 ，并将它们转移到云基础架构上将无法利用必要的云原生功能。
相反，你应该以新的方式开展新事物，或者将新的云原生应用程序放入新的云基础架构中，或者通过拆分现有的单块应用来从头开始使用云原生原则重构它们。（这个观点可能有点绝对，迁移到云，至少可以先开始利用云的一些优势，至少能提高资源利用率。对许多组织来说，重构应用程序也基本是不可能的。）
还需要放弃旧的开发方法。瀑布模型当然不会再用，甚至敏捷开发可能还不够。因此，必须采用新的云原生方法，如最小可行产品（MVP）开发，多变量测试，快速迭代，以及在DevOps模型中跨组织边界密切合作。
到此，云原生就介绍完了，希望对大家日后的工作能有所启发。云原生有很多方面，包括基础架构服务、自动化/编排、虚拟化和容器化，微服务架构和可观察性。所有这些都意味着一种新的做事方式，意味着在学习新方法时打破旧习惯，对于刚接触这块的公司和团队不可能一下子做到，需要按部就班的学习和在生产环境中逐步实践应用。
