什么是云原生？是炒作还是软件开发的未来？
21CTO导读：最近有不少有关云原生态开发的讨论，它可以解决啥事？或者这是另一种技术时尚？继续阅读本文，可以获得一些技术见解。
很长一段时间以来，云原生Cloud Native就成了软件开发中热门的话题之一。一些开发人员认为它只是炒作，在失去吸引力后在一段时间就后消失；而对于另一部分人的观点认为，这就是软件开发的未来。
无论未来还会带来什么，云原生软件确是软件行业最大的趋势之一。它在改变着我们思考软件开发，部署和运营软件产品的方式。
那么，究竟什么是“云原生”？
云原生的不同定义
Cloud native不仅仅是云提供商并使用它来运行现有的应用程序。它会影响应用程序的设计，实现，部署和操作。
提供流行的Spring框架和云平台的软件公司Pivotal将云原生描述为：
“云原生是一种构建和运行应用程序的方法，可充分利用云计算模型的优势。”
来源：什么是云原生应用程序？ - Pivotal
云原生计算基金会是一个旨在创建和推动云原生编程范式采用的组织，它将云原生定义为：
“云原生计算使用开源技术栈：
容器。每个部分（应用程序，进程等）都打包在自己的容器中。这有利于再现性，透明度和资源隔离。
动态编排。主动安排和管理容器以优化资源利用率。
微服务为导向。应用程序被拆分为微服务。这将显著提高应用程序的整体灵活性和可维护性。“
来源：常见问题（FAQ） - Cloud Native Foundation
大家看，这两种定义有些相似，但从略微不同的角度来看这个主题。我们可以将云原生的定义概括为以下词句：
“将软件应用程序构建为微服务，并在容器化和动态调度平台上运行，利用云计算模型优势的部署方式。”
老实说：“利用云计算模型的优势”听起来确实不错，但如果是云的新手，我们仍然想知道这到底是什么，以及它如何影响实施与部署软件的方式。这至少是我第一次阅读有关云原生计算的感受。
我们来看看云原生的不同部分。
容器
容器的基本思想是将软件与执行它所需的一切打包到一个可执行的软件包中，例如Java VM，Application服务器和应用程序本身。然后，你可以在虚拟化环境中运行此容器，并将包含的应用程序与其环境隔离开来。
这种方法的主要好处是应用程序独立于环境，并且容器具有高度可移植性。你可以在开发，测试或生产环境上轻松运行相同的容器。如果应用程序设计还支持水平扩展，还可以启动或停止容器的多个实例，还可以根据当前用户需求添加或删除应用程序的实例。
Docker是目前最受欢迎的容器实现。它的确非常受欢迎，以致于Docker和容器这两个术语经常互换使用。但请记住，Docker项目只是容器概念的一个实现，可以在将来被进行替换。
如果你想尝试Docker，应该从免费的社区版开始。我们将它安装在本地桌面上，就可以开始构建自己的容器定义并将第一个应用程序部署到容器中。当你完成部署后，可以将容器交给一个质量保障的同事，将其部署到生产环境中去。
如果你的应用程序在测试或生产环境中工作，或者需要更新某些依赖项，也不用再担心——容器包含应用程序所需的所有内容，你只需启动它即可。
管弦乐作曲家
将包含所有依赖项的应用程序部署到容器中只是第一步。它解决了我们以前的部署问题，但如果想从云平台中充分受益，那么开发者还将面临新的挑战。
根据系统的当前负载启动附加或关闭正在运行的应用程序节点，这做到并非易事。
你需要：
监控系统，
触发容器的启动或关闭，
确保所有必需的配置参数都到位，
平衡活动应用程序实例之间的负载量，
在容器之间共享身份验证机密。
手动完成这些操作需要花费很多精力，并且对于系统负载的意外调整反应也会比较慢。开发者需要拥有适当的工具来自动完成这些工作。这就是构建不同解决方案的原：一些流行的工具有Docker Swarm，Kubernetes，Apache Mesos和亚马逊的ECS。
微服务
现在我们已经有了所有基础架构和管理工具，是时候讨论云原生引入系统架构的变化了。
将云原生应用程序构建为微服务系统，相信你已经听说过这种架构方法了 。
这种架构风格的通用概念是将一个由多个相对较小的应用程序组成系统，它被称之为微服务。它们之间协同工作提供系统的整体功能。
每个微服务都实现了一个功能，具有明确定义的边界和API，可由相对较小的团队开发和管理、操作。
这种方法提供如下几个好处：
微服务的好处
首先，实现和理解一种功能较小的应用程序要容易得多，不用再构建一个要完成所有任务的大型应用程序。这不仅加快了开发速度，让服务适应变更或新需求变得更容易。开发者需要关注看似微小变化的意外副作用，以便专注于手头的开发任务。
微服务还让人们能够有更有效地扩展。我们在前面谈到容器时，说到可以简单地启动另一个容器来处理用户请求的增加，这称为水平缩放。对于每个无状态应用程序，你都可以这样做，这与其应用大小无关。只要应用程序不保留任何状态，你就可以将用户的下一个请求发送到任何可用的应用程序实例中。
即便如此，我们仍然可以使用单体应用程序来实现。但扩展微服务系统的成本通常要低很多。开发者只需要扩展支持大负载的微服务即可。如果系统可以处理得好当前负载，我们就不需要添加服务的任何其它实例。
我们用笨重的应用就做不到这一点。比如需要扩展一个功能的容量，则需要启动完整应用的新实例。这可能看起来也不是什么大问题，但在云环境中，别忘了需要为硬件资源的使用付费。即使你只用应用的一小部分，仍然需要为其他未使用的部分获取额外的资源。
微服务可让你更有效地使用云资源，并有效减少云服务商的账单。
引入微服务的挑战
通常就是这样，人们无法免费获得架构风格的好处。
微服务从服务本身中消除了一些复杂性，并提供了更好的可扩展性，如果你现在正在构建一个分布式系统，微服务会增加系统级别的复杂性。如下图：
为了尽可能降低这种额外的复杂性，你应该避免微服务之间存在任何的依赖关系。
如果现象不可避免，需要确保相关服务相互发现，并有效地实现其通信。开发者还需要处理反映缓慢或不可用的服务，以使它们不要影响系统整体。
系统的分布式特性也使得在生产中监视和管理系统变得困难。
运营者现在需要监控微服务系统而不再是几个整体系统，并且对于每个服务，可能有多个并行运行的实例。人们需要监控更多应用程序实例。我们可以通过使用Retrace，K8s等工具从所有系统来收集信息。
构建微服务
我们并不需要使用特定的框架或技术栈来构建微服务。
它让开发变得容易多了。它为开发者提供了许多即用型功能，这些功能经过了充分测试，并且已在生产环境中使用过。
比如在Java中，有许多不同的选项可用。两个流行的是Spring Boot和Eclipse Microprofile。Spring Boot将Spring框架与其它几个框架/库集成在一起，以应对微服务架构的更多挑战。
Eclipse Microprofile遵守相同的理念，但它使用Java EE架构，即多个Java EE应用程序服务器协同工作，它提供了一组规范和多个可互换的技术实现。
小结
云原生计算的思想和概念，引入了实现避免复杂，高度可扩展系统的新方法。即便 你没有在云平台上托管应用程序，这些新想法也会影响你将来开发应用程序的方式。
容器技术使分发应用程序变得更加容易。你在开发过程中可以和团队成员之间共享应用程序，也可在不同环境中测试运行。执行完所有测试后，你可以轻松地将同一容器部署到生产环境中。
微服务提供了一种构建系统的新方法。虽然引入了新的挑战，但它将我们的注意力转移到每个组件的设计上。这样可以有效改善封装，让人们实现可维护的组件，更好地快速适应新的产品需求。
如果你决定用容器在生产中运行微服务系统，需要一个帮助管理系统的编排解决方案，那还有kubernates，jenkins等工具。
微服务如此神奇，让我们一起发现更多。
编译：洛逸