为什么说Kubernetes是新的应用服务器？

另外，Java 应用还包括 Servlet 引擎、数据库池、依赖注入、事务、消息等特性。当然，框架可能会提供这些特性，，但是应用服务器必须要具备在任何环境下构建、运行、部署和管理企业级应用所需的各种功能，不管它是不是在容器中运行。实际上，应用服务器可以在任何地方执行，例如，在裸机上、在像 Red Hat Virtualization 这样的虚拟化平台上、在像 Red Hat OpenStack 平台 这样的私有云环境中以及在像 Microsoft Azure 或 Amazon Web Services 这样的公有云环境中。

好的应用服务器要确保它所提供的 API 和具体实现之间的一致性。开发人员可以确信如果他的业务逻辑需要特定的功能，他所部署的逻辑是正常运行的，因为应用服务器开发人员(以及预先定义的标准)能够保证它们之间能够协同工作和协同演化。另外，好的应用服务器还要负责最大化吞吐量和可扩展性，因为它要处理来自用户的所有请求;减少延迟并提升负载能力，它有助于提升应用的可处置性;轻量级的资源占用，最小化硬件资源和成本;最后，还要足够安全，能够防范所有的安全漏洞。对于 Java 开发人员来说，Red Hat 提供了 Red Hat JBoss 企业级应用平台，满足了现代、模块化应用服务器的所有需求。

结论

容器镜像已经成为分发云原生应用的标准打包格式。尽管容器本身并没有为应用提供任何真正的业务优势，但是 Kubernetes 及其相关的项目，如 OpenShift 和 Istio，提供了非功能性的需求，而这些需求过去曾是应用服务器的功能的一部分。

开发人员过去所使用的大多数非功能性需求，来源于应用服务器或者像 Netflix OSS 这样的库，这些需求是与特定语言绑定的，比如 Java。但是，如果开发人员选择使用 Kubernetes + OpenShift + Istio 来满足这些需求的话，它们是与任何特定语言都没有关联的，这样的话就能鼓励开发人员针对每个使用场景选择最佳的技术 / 语言。

最后，在软件开发领域，应用服务器依然有它的位置。但是，它们变得更像是特定语言的框架，在开发应用的时候，这是很简便的，因为它们包含了大量已经编写就绪且经过测试的功能。

转移到容器、Kubernetes 和微服务架构时，最棒的事情之一就是不必为应用选择单一的应用服务器、框架、架构风格甚至编程语言。你可以很容易地部署一个含有 JBoss EAP 的容器，让 JBoss EAP 运行已有的 Java EE 应用，其他的容器则可能会包含使用 Wildfly Swarm 编写的微服务或者使用 Eclipse Vert.x 编写的反应式程序。这些容器都可以通过 Kubernetes 进行管理。如果想了解这些概念如何实际运行，参考 Red Hat OpenShift 应用运行时。

你可以说 Kubernetes/OpenShift 是新的 Linux，甚至可以说“Kubernetes 是新的应用服务器”。但实际上，应用服务器 / 运行时 +OpenShift/Kubernetes + Istio 已经成为了云原生平台的事实标准。

关于作者

（编辑：成都站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!