云原生是什么？是炒作还是软件开发的未来？

本文是翻译的国外的文章，原文连接：https://stackify.com/cloud-native/

在相当长的一段时间里，云原生一直是软件开发中最热门的话题之一。一些开发人员认为它是炒作，一段时间后就会失去牵引力并消失。但是，其他人认为它是软件开发的未来。
无论未来会带来什么，云原生是目前软件行业最大的趋势之一。它已经改变了我们开发、部署和运维软件产品的思维方式。
但是准确地说云原生是什么？

云原生不同的定义

云原生不仅仅是用云平台来运行你现有的应用程序。它影响到你的应用的设计、实现、部署和运维。
提供了流行的Spring框架和云平台的软件公司Pivotal将云原生描述为：

"云原生是一种构建和运维应用程序的方法，可以充分发挥云计算模式的优势。"
来源：云原生应用是什么？——Pivotal

云原生计算基金会是一个旨在创建和推动采用云原生编程模式的组织，它对云原生的定义是：
云原生计算使用的开源软件栈是：

• 容器化。每个部分（应用程序、流程等）都被封装在自己的容器中。这有助于实现可复制性、透明度和资源隔离。
• 动态编排。容器被主动调度和管理，以优化资源利用率。
• 面向微服务。应用程序被划分为微服务。这显著提高了应用程序的整体敏捷性和可维护性。"
  来源：Frequently Asked Questions (FAQ) – Cloud Native Foundation

两个定义都很相似，但看题目的角度略有不同。你可以把这些定义总结为：
"将软件应用程序构建为微服务，并在容器化和动态编排的平台上运行，以利用云计算模式的优势的一种方法。"
说实话："利用云计算模式的优势 "听起来很好，但如果你是云原生计算的新手，你可能还在想这是怎么回事，它如何影响你实现软件的方式。至少当我第一次读到云原生计算的时候，我是这么想的。
我们来看看不同的部分。

容器

容器的基本思想是将你的软件与执行它所需的一切打包成一个可执行包，例如，一个Java虚拟机、一个应用服务器和应用本身。然后，你在虚拟化环境中运行这个容器，并将包含的应用程序与其环境隔离。
这种方法的主要好处是，应用程序变得独立于环境，而且容器具有高度的可移植性。你可以轻松地在你的开发、测试或生产系统上运行同一个容器。而且如果你的应用设计支持水平扩展，你可以启动或停止一个容器的多个实例，根据当前用户的需求增加或删除应用的实例。
Docker项目是目前最流行的容器实现。它如此流行，以至于Docker和容器这两个词经常被互换使用。但请记住，Docker项目只是容器概念的一种实现，未来可能会被取代。
如果你想尝试一下Docker，你应该从免费的社区版开始。你可以在本地桌面上安装它，这样你就可以开始构建自己的容器定义，并将你的第一个应用程序部署到容器中。而当你完成后，你可以将容器交给同事，由他来做质量保证，之后再部署到生产中。
你不再需要担心你的应用程序是否能在测试或生产环境中工作，或者你是否需要更新一些依赖关系。容器中包含了你的应用所需的一切，你只需要启动它。
官方文档向你展示了如何在系统上运行Docker，并提供了一个很好的入门指南。

编排

将你的应用程序与所有依赖项部署到容器中只是第一步。它解决了你之前的部署问题，但如果你想从云平台中充分受益，你就会遇到新的挑战。
根据你的系统当前的负载来启动额外的或关闭运行中的应用节点并不是那么容易。你需要：

• 监控你的系统。
• 触发容器的启动或关闭。
• 确保所有必要的配置参数都已到位。
• 平衡应用实例之间的负载
• 在你的容器之间共享认证密钥。

手动完成所有这些工作需要花费很多精力，而且对系统负载的意外变化反应太慢。你需要有合适的工具来自动完成这一切。这就是不同的编排解决方案的目的。几个流行的是Docker Swarm、Kubernetes、Apache Mesos和Amazon的ECS。

微服务

我们已经完成了所有的基础架构和管理，现在是时候谈谈云原生给系统架构带来的变化了。云原生应用程序被构建为一个微服务系统。我相信你已经听说过这种架构方式，我也在博客上写过一系列关于它的文章。
这种架构风格的总体思路是实现一个由多个相对较小的应用组成的系统。这些被称为微服务。它们一起工作，提供你系统的整体功能。每个微服务正好实现一个功能，有一个明确的边界和API，并由一个相对较小的团队开发和运营。
这种方法提供了几个好处。

微服务的好处

首先，实现和理解一个提供一种功能的小型应用程序要容易得多，而不是建立一个什么都能做的大型应用程序。这加快了开发速度，并使服务更容易适应变化的或新的需求。你需要少担心一个看似微小的变化所带来的意外副作用，你可以专注于手头的开发任务。
它还可以让你更有效地进行扩展。当我谈到容器时，我说你可以简单地启动另一个容器来处理用户请求的增加。这就是所谓的水平扩展。你基本上可以对每一个无状态的应用程序做到这一点，与它的大小无关。只要应用程序不保留任何状态，你就可以将用户的下一个请求发送到任何可用的应用程序实例。
即便如此，你也可以用单体应用或微服务系统来做，扩展微服务系统往往要便宜很多。你只需要扩展获得大量负载的微服务。只要系统的其他部分能够处理当前的负载，你就不需要添加其他服务的任何额外实例。
单体应用是做不到这一点的。如果你需要增加一个功能的容量，你需要启动一个完整的单体的新实例。这看起来似乎没什么大不了的，但在云环境中，你要为硬件资源的使用付费。而且即使你只使用了单体的一小部分，你仍然需要为其他未使用的部分获取额外的资源。
正如你所看到的，微服务让你更有效地使用云资源，减少云提供商的月度账单。

微服务带来的挑战

一如既往，你不会免费获得架构风格的好处。微服务消除了服务本身的一些复杂性，并提供了更好的可扩展性，但你现在正在构建一个分布式系统。这在系统层面上增加了很多复杂性。
为了尽可能降低这种额外的复杂性，你应该尽量避免你的微服务之间的任何依赖关系。如果无法做到这一点，你需要确保依赖的服务能够找到对方，并有效地实现它们的通信。你还需要处理慢速或不可用的服务，以免它们影响到整个系统。我在微服务之间的通信中对微服务之间的通信做了更详细的介绍。
系统的分布式特性也让你在生产中监控和管理系统的难度大大增加。你现在需要监控一个由微服务组成的系统，而不是几个单体，对于每个服务，可能有几个实例并行运行。你需要像过去那样监控更多的应用实例。你可以使用Retrace等工具来收集所有系统的信息。

构建微服务

你不需要使用特定的框架或技术栈来构建微服务。但它使微服务变得更加简单。它们为你提供了很多现成的功能，这些功能都经过了很好的测试，并且之前已经在生产环境中使用过。
在Java世界里，有很多不同的选择。两个流行的是Spring Boot和Eclipse Microprofile。
正如你从它的名字中可能猜到的那样，Spring Boot将著名的Spring框架与其他一些框架和库集成在一起，以处理微服务架构的额外挑战。
Eclipse Microprofile遵循同样的理念，但使用的是Java EE。多个Java EE应用服务器厂商共同合作，提供了一套规范和多个可互换的实现。

总结

云原生计算的思想和概念引入了一种实现复杂、可扩展系统的新方法。即使你没有在云平台上托管你的应用，这些新理念也会影响你未来开发应用的方式。
容器使应用程序的发布变得更加容易。你可以在开发过程中使用它们在团队成员之间共享应用程序，或者在不同的环境中运行它们。而在执行完所有测试后，你可以轻松地将同一个容器部署到生产环境中。
微服务提供了一种新的方式来架构你的系统。它们带来了新的挑战，但它们也将注意力转移到每个组件的设计上。这改善了封装，并允许你实现可维护的组件，你可以快速适应新的需求。
而如果你决定在生产中使用容器来运行微服务系统，你需要一个编排解决方案来帮助你管理系统。