微服务、容器、云原生、Kubernetes、SOA、Paas平台、Devops 之间的关系

作者：lixuefeng

转载链接：https://zhuanlan.zhihu.com/p/74483850

作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

-------------------------------------------------------------------------------------------

IT软件技术架构进入云时代后，出现了大量的新概念和新技术。从几年前热火开始Openstack、计算存储网络三大虚拟化技术Iaas近年来，云计算领域的平台、更热门的容器和云原生相关技术层出不穷。

我们经常听到这些概念，比如容器，docker、kubernetes、微服务架构、Paas平台，服务中台，Devops、云起源等等。这些技术和概念是独立的，我们很容易从某个角度学习和应用；然而，大多数时候，我们会发现这些技术是密切相关的，从文章或技术应用场景，它们经常出现在同一个地方。他们之间的联系和依赖是什么，这是非常令人困惑的。

本文从这些技术之间的依赖和关系出发，讲述了它们在当今软件云和微服务时代的作用。希望读者从这些总结和比较入手，对微服务相关技术体系建立全球视野和理解。

1. Docker容器：

docker大多数人都很熟悉或至少听说过。Docker在许多技术资料和书籍中，技术往往与虚拟化技术进行比较，其比较如下：

KVM等待虚拟化技术在操作系统级别上进行虚拟和隔离，每个虚拟机都是独立的OS。而docker轻量级虚拟化是在同一操作系统中实现的。如何理解轻量级虚拟化？看起来像docker容器是一个独立的操作系统，本质上是同一操作系统中的过程隔离。因此，它是轻量级的；因此，docker比KVM资源利用率更高。

Docker设计理念伟大，作用伟大。docker伟大远不仅体现在轻量虚拟化上；docker其伟大体现在：它实现了：同一软件发布，在不同的平台上运行。

你熟悉这个好处吗？这其实就是Java最初流行的原因。Python为了实现这一点，语言得出了它VirtualEnv，通过程序发布依赖包，解决了多平台运行的问题。Docker设计非常优雅，一个应用程序被包装成一个i ** ge格式，i ** ge采用分层技术等，这部分不是本文的重点，如果您想了解更多，可以参考其他资料。

2. Kubernetes

docker镜像运行是一个接一个的程序。如何将多个程序组合成一个大的分布式应用程序？

答案很简单。同样，程序可以相互调用。就像传统的分布式应用一样，获得更多的服务器，在服务器上安装序，程序之间通过socket基于其他协议的通信。docker分布式应用也是如此，区别只是网络虚拟化，CPU内存资源也是虚拟化的。

但永远不要低估分布式应用程序的复杂性，举两个例子，想象我们建立了一个分布式集群，运行了一个分布式应用程序：

如何检查故障，如何修复该集群中的某台机器故障（断电、硬盘故障等）？由于访问量的增加，该集群的某些业务需要扩大支持能力。如何扩大？

对于这两个问题，我们很容易想到答案，即人们过去检查机器、修理或重新安装。如果负载过大，则更改应用程序的结构，并覆盖负载平衡，并使用可扩展的结构。这些都是传统的方法，这些解决方案也很明显，是修复太慢，劳动力太慢，成本太高，对业务有很大的影响，想象一个网站，如扩展完成，用户将失去。

Kubernetes它是容器编排系统，其主要目的是解决上述例子中的两个问题：

当服务器或容器应用出现问题时，分布式容器应用的可靠性会自动感知，集群中其他机器中容器应用的可扩展性会自动重新运行。

Google为了压制AWS，开源自己的容器运行平台已经成为现在Kubernetes，你可以搜索这段历史。

3. Paas

理论上计算理论上讲三层：Iaas、Paas、Saas，分布是Infrastructure、Platform、Software as a service。其中的Infrastructure指硬件资源虚拟化；Platform指软件平台，是应用软件运行的基本平台。

经典理论为何要把握？Paas这一层单独拿出来？

Saas层直接面向业务用户，Iaas层是应用运行的底层物理资源，中间的Paas它是基础数据库服务、基础中间件服务、基础开发框架及开发套件、应用部署、管理及运维服务等标准平台。Paas平台这一层，Saas层层更注重自身的业务实现，运营平台和运营中间部件由Paas层提供。

因为前述的Kubernetes成熟度和无与伦比的优势，Paas层的基础设施基本采用Kubernetes。

有时会听到中台的概念，包括数据层(称为数据中台)、技术组件层(称为技术中台)和业务层(业务中台)。

中台的概念来自阿里巴巴。随着企业规模的扩大，集团形成了大规模的形成BU或部门，每个部门负责自己的业务实体。这些业务实体中有许多通用的业务模块。取出这些通用的业务模块，形成一个基本的业务层。该业务层由组织结构相对独立的部门负责，该部门负责平台。这就是中间平台的起源。

业务层中台概念泛化后，数据中台和技术中台演变。现在(2020年)，各大政企集团可能都在推进自己的中台战略。猜测背后一个非常重要的原因可能是:这是组织结构和权力分配变革的机遇，有机会自然会有人推进。

Paas中台4. 微服务

引述Sam New ** n在Building Mircroservices本书对微服务的定义：

Microservices are s ** ll,autonomous services that work together.

引用前网飞云架构负责人Adrian Cockcroft的定义：

Loosely coupled service-oriented architecture with bounded contexts.

我们在这里定义为：微服务是一个可以独立部署、小、自主的业务组件，业务组件通过信息互动。微服务组件可根据需要独立扩展，具有容错和故障恢复能力。

由于微服务架构具有以下优点，已成为云计算时代应用的标准架构：

支持快速启动。由于业务组件的自主性和独立性，新的功能和应用程序可以在不担心对系统其他功能的广泛影响的情况下快速发布和启动。新的应用程序可以通过服务组件的重用和重组快速形成和发布。支持独立的扩展和恢复。有针对性地扩展应用程序中的一些服务，以解决性能瓶颈。微服务中的组件可以独立更换或恢复。

快速上线-意味着速度和效率；独立扩容和恢复-这意味着系统的安全性、稳定性和可扩展性。微服务架构系统的应用在开发效率、稳定性和可扩展性方面具有无可比拟的优势，成为云应用的标准架构。

由于微服务本身是独立发布、独立部署、自治、微服务，docker容器也是一个跨平台、独立运行和小型执行单元。因此，容器是微服务架构的良好运行载体。

微服务架构的核心功能组件包括 ** 、微服务治理、服务注册、配置管理、限流和熔断、负载平衡、自动扩容、自动故障隔离、自动业务恢复、监控和日志组件等。

微服务架构本质上与容器及K8S技术无关，在Java体系的Spring Cloud提供了 等** Zuul组件、Ribbon负载平衡组件，Eureka服务注册组件，LCM扩容组件、Hystrix业务恢复组件Spring Cloud能力可以实现完善的微服务架构。Spring Cloud有大量的java它的优势在于开发人员的支持。Spring Cloud缺点是限制编程语言和编程技术。

Kubernetes基于服务注册、配置管理、负荷平衡、故障隔离、业务恢复、自动扩容等能力。Kubernetes的Paas平台还提供基础数据服务， ** 服务、微服务治理服务等基本服务能力。Kubernetes不限制编程语言，社区活跃，功能稳定。kubernetes和Paas平台是微服务技术的运行平台。

微服务架构对应用运营平台依赖性强，功能好，使用方便，稳定Paas只有这样，平台才能架构的优势。相反，如果没有好的Paas平台、应用开发团队的大部分精力都花在平台的建设和利用上，以及微服务架构的设计和应用维护上。在这种情况下，它不仅没有利用微服务架构，而且沉浸在使用微服务架构带来的技术挑战和劣势中。

一般来说，微服务架构是一种重平台、轻应用的架构。总的来说，与传统的应用软件架构相比，平台的研发投资占了很大的比例。利用成熟稳定的商业化Paas平台是成本最好的方案。

5. SOA

SOA（Service-Oriented-Architecture）服务架构是将服务组装形成整体应用架构。SOA服务是指可重用业务模块。

微服务架构与SOA同样，整个应用程序也被拆分，形成一个独立的业务模块。但在许多关键点上，微服务架构和SOA不同。

SOA与微服务架构对比SOA在很大程度上依赖于基基础XML新闻格式及基础SOAP通信协议和微服务架构大多依赖于REST和JSON。SOA架构中有ESB（服务总线）的概念，ESB负责服务之间的通信转发和接口适应SOA实现中，ESB有许多专业处于核心地位ESB厂商提供ESB例如中间件WebSphere ESB、Oracle ESB、Dubbo等。ESB它本身就是一项非常重的技术。在云软件系统和微服务架构中，强调更轻、更快、更分散的技术，因此在微服务架构中不需要ESB，而通过API ** 负责服务界面转发的技术。(由于软件全面云化是一个需要适应和调整才能完成转换的过程，因此在一段时间内面临着大量的遗留系统，ESB在微服务改造过程中，仍将作为适应老系统的重要组成部分。SOA设计理念是通过服务总线组装部分组件和服务，形成更大的应用系统（从小到大）；微服务的设计理念是将应用程序分为独立的小型服务（从大到小）。SOA设计结构强调分层，通常分为显示层、业务层、总线层和数据层。微服务架构中的服务比较松散。SOA服务不强调业务领域的自治，微服务架构强调基于领域的服务自治。

从以上比较来看，两者的区别基本上是实现的。微服务与SOA它本质上是不同时代不同实现的相同设计理念。过去，在容器中，K8S技术没有出现的时代造就了SOA的实现方式。

6. 云原生

着名的CNCF（Cloud-Native Compute Foundation，云原生计算基金会成立于2015年Google在大公司的领导下，目前有100多名企业成员，目的是在容器、微服务和devops在现代云环境中，通过一系列规范和标准，帮助企业和组织在现代云环境中构应用。

CNCF的Landscape定义了关于Provisioning、Runtime、容器编排、Paas开源组件和技术标准，如平台、微服务治理等。

简单直白地说，基于CNCF云原生技术开发的应用可以在行业各个平台上畅通无阻，部署在私有云和公有云中的技术体系和结构相同。

从CNCF的Landscope向上看，进入CNCF的Landscope在功能、稳定性稳定性和活动性方面普遍处于行业领先地位。

CNCF云原生定义的三个特:

容器包装：以容器为基础，提高整体开发水平，形成代码和组件重用，作为应用程序部署的独立单元。动态和自动化管理：通过集中的安排和调度系统进行动态管理和调度。也就是说K8S。微服务：明确服务间的依赖，相互解耦。

综上所述，云原生的三大特点是：docker、kubernetes和微服务。此外，云原生强调自动化，以提高开发效率和运维效率。

7. Devops

DevOps是Development和Operations的组合，重视软件开发人员和运维人员的沟通合作，通过自动化流程来使得软件构建、测试、发布更加迅速和可靠。

Devops与上述的云原生、微服务、容器等技术应用没有直接的关系，可以讲，没有微服务和容器等技术，一样的可以朝着自动化的构建、测试和发布流程上行进。但是，长久以来，devops只是在文化上和流程指导上给出了方向，至于落地的方 ** 和工具链上，并没有很成功，只是在CI/CD流程的个别环节上独立发展出一些比较成功的产品，例如jenkins及一些自动化测试工具。究其原因，还是在软件应用基础架构上，没有完善的技术支撑和技术体系，软件的运行环境千差万别、软件的部署和维护流程千差万别、软件的形态和架构千差万别，Devops落地需要大量定制化，工具链落地难度很大。

基于容器和Kubernetes的平台提供了云原生应用的标准发布和运行环境；基于容器的微服务架构定义了云原生应用的标准架构。通过这些技术，为软件应用在架构、支撑服务和支持组件、基准平台上进行了标准化；同时通过这些技术，解决了升级、扩容、稳定性、私有云/公有云/混合云统一基础架构等问题。

微服务架构的重要目标就是：快速发布，那么就需要在敏捷文化、自动化工具链上对流程提出了高要求。

在这个基础上，利用devops的自动化文化、协作文化、敏捷文化，在软件的开发、测试、部署、运维流程上，提升了开发效率、降低了沟通成本、提升了部署和上线速度。Devops是云原生应用在开发、测试和发布流程上的必要手段，基于容器的Paas平台和微服务架构，为devops的流行提供了土壤。

总括：

微服务、容器、云原生、Kubernetes、SOA、Paas平台、Devops 之间相互促进、相互依赖、相互关联，它们之间的关系如下：

容器和微服务相关技术之间的关系