容器作为标准化的软件单元,将应用及其依赖打包在一起,实现了应用的环境无关性,使其能够在不同计算环境中快速、可靠地运行。
随着开源的Kubernetes的出现,它展示了出色的开放性、可扩展性,并拥有活跃的开发者社区。
在容器编排领域,Kubernetes已经成为分布式资源调度和自动化运维的事实标准。它屏蔽了不同基础架构(如数据中心、云、边缘计算)的差异,并具备良好的可移植性。通过Kubernetes,企业能够根据自身的业务需求设计其云架构,以更好地支持多云和混合云环境,并摆脱被厂商锁定的担忧。随着容器技术的标准化,Kubernetes进一步推动了容器生态系统的分工和协同发展。在Kubernetes的基础上,生态社区正在构建上层的业务抽象,例如服务网格Istio、机器学习平台Kubeflow、无服务器应用框架Knative等。
Kubernetes 已经成为容器编排的事实标准,被广泛用于自动部署,扩展和管理容器化应用。Kubernetes 提供了分布式应用管理的核心能力:
Kubernetes的控制平面包含四个主要的组件:API Server、Controller、Scheduler以及etcd。如下图所示:
自2011年以来,微服务架构理念已经演变出了四个典型的架构模式,按照它们出现的顺序进行归纳。
除了实现业务逻辑外,应用程序还需要自己解决上下游寻址、通信和容错等问题。随着微服务规模的扩大,服务寻址逻辑变得越来越复杂。即便是同一编程语言的另一个应用程序,也需要重新实现上述微服务的基础能力。
引入了旁路服务注册中心作为协调者,实现了服务的自动注册和发现。服务之间的通信和容错机制开始模块化,形成了独立的服务框架。然而,随着服务框架内功能的增加,不同语言的基础功能复用变得困难。这意味着微服务的开发者被限制在特定的编程语言上,违背了微服务的敏捷迭代原则。
服务网格架构将原本被模块化到服务框架中的微服务基础能力进一步演进为一个独立进程,即Sidecar。这个变化彻底解决了第二代架构中的多语言支持问题,实现了微服务基础能力与业务逻辑的彻底解耦。这个架构被称为云原生时代的微服务架构,即Cloud Native Microservices。Sidecar进程接管了微服务应用之间的流量,承载了第二代架构中服务框架的功能,包括服务发现、调用容错以及丰富的服务治理功能,例如权重路由、灰度路由、流量重放和服务伪装等。
在这个架构中,微服务进一步简化为微逻辑(Micrologic),边车模式也提出了更高的要求。更多可复用的分布式能力从应用中剥离,并下沉到边车中,包括状态管理、资源绑定、链路追踪、事务管理和安全等。同时,开发侧开始倡导面向localhost编程的理念,提供标准API来屏蔽底层资源、服务和基础设施的差异,从而进一步降低微服务开发的难度。这就是目前业界提出的多运行时微服务架构(Muti-Runtime Microservices)的概念。
随着云原生技术(以Kubernetes为代表)在云计算中扮演着容器界面的角色,Kubernetes变成了新一代云计算操作系统。针对特定领域的后端云服务(BaaS)则提供了在这个操作系统上的服务API。在存储、数据库、中间件、大数据等领域,许多产品和技术都开始提供全托管的云服务。越来越多的用户已经习惯于使用这些云服务,而不再自行搭建存储系统或部署数据库软件。