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

我们经常会听到的这些概念，比如容器、docker、kubernetes、微服务架构、Paas平台、服务中台、Devops、云原生等等。这些技术和概念彼此之间感觉是独立的，我们很容易从其中某一个角度学习入手并应用；但是，很多时候，我们会发现这些技术彼此之间又有密切的关联，从文章也好、技术落地应用的场景也好，它们往往又出现在同一个地方。它们之间究竟有什么联系，彼此之间有什么依赖，让人十分的困惑。

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

1. Docker容器：

docker大部分人都熟悉或者至少是听过。Docker技术在很多技术资料和书籍上，往往会跟虚拟化技术做对比，它们的对比如下：

• KVM等虚拟化技术是在操作系统级别上进行虚拟和隔离，每一个虚机都是独立的OS。

• 而docker是在同一个操作系统中，实现了轻量级的虚拟化。“轻量级的虚拟化”怎么理解呢？看起来docker容器是独立的操作系统，本质上是同一个操作系统中的进程隔离。所以它是轻量级的；从而，docker比KVM更省资源、资源利用率更高。

Docker的设计理念很伟大、作用也很伟大。但是docker的伟大性远不只是体现在“轻量的虚拟化”；docker的伟大性体现在：它实现了：同一个软件发布，在不同的平台上运行。

这个好处是不是很熟悉？这其实就是Java最初流行起来的原因。Python语言为了实现这一点，弄出了VirtualEnv，把依赖包都随着程序发布，才解决了多平台运行的问题。Docker的设计很优雅，一个应用都打包成一个image格式，image采用分层技术等等，这部分不是本文的重点，大家希望更深入了解的话，可以参考其他资料。

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或部门，每个部门负责各自的业务体。这些业务体中有很多通用型的业务模块，把这些通用的业务模块拿出来，形成一个基础的业务层，这个业务层由在组织结构上相对独立的部门来负责，这个部门负责的东西就是中台。这便是中台的起源。

业务层中台这个概念泛化后，又演化出了数据中台和技术中台。现在（2019年）可能各个大型政企集团都在推进其各自的“中台战略”，猜想其背后的一个很重要的原因可能是：这是一次组织结构和权力分配变革的机遇，有机遇自然会有人去推进。

4. 微服务

引述Sam Newman在Building Mircroservices一书中关于微服务的定义：

Microservices are small, 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很大程度上依赖于基于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 之间相互促进、相互依赖、相互关联，它们之间的关系如下：

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