云计算发展趋势（二）实现云计算的技术以及其他新兴技术介绍

前言

我们在上篇文章云计算的发展趋势（一）云计算相关领域介绍中介绍了与云计算息息相关的一些技术以及应用。那么本文就主要介绍实现云计算的一些技术以及一些新兴的技术。

实现云计算的技术

大家可以参考计算虚拟化简介这篇文章中有简略的提到计算虚拟化的历史，以及KVM、XEN等计算虚拟化技术。这里我们主要介绍一些其他的技术。

容器技术（Container）

一种轻量级的虚拟化技术

轻量级虚拟化

就是使用了一种操作系统虚拟化技术，这种技术允许一个操作系统上用户空间被分割成几个独立的单元在内核中运行，彼此互不干扰，这样一个独立的空间，就被称之为一个容器。

使用容器技术后，应用程序可以在几乎任何地方用相同的方式运行。开发人员可以在自己的电脑上常见并测试好容器，无须任何修改就能够在其它的虚拟机或者物理机上运行。

注意：容器是一种虚拟化技术，但要区别于虚拟机

容器和虚拟机的对比

容器由两部分组成：

1. 应用程序
2. 应用程序运行环境，比如应用程序需要的库等。

容器是一个软件的轻量级独立可执行软件包，包含运行它所需的一切：代码，运行时，系统工具，系统库，设置。不管环境如何，集装箱化软件都可以运行相同的Linux和Windows应用程序。容器将软件与其周围环境隔离开来，例如开发环境和测试环境之间的差异，并有助于减少在同一基础架构上运行不同软件的团队之间的冲突。

虚拟机除了部署应用容器中包含的这些外，还需要包含操作系统，这是二者最大的区别。

那么容器究竟解决了什么问题呢？

当代软件的架构非常复杂，软件环境配置就成了现在软件开发最大的麻烦，开发者常常会说：“它在我的机器可以跑了”，言下之意就是这个软件在别的电脑上不一定能跑得起来，最大的原因是软件所在的操作系统的设置及各种库和组件的安装，只有他们全部正确，软件才能运行起来。比如一个软件是用JAVA开发的，计算必须有配套的引擎、依赖和环境变量的配置。那么我们安装软件的时候，把原始环境也一模一样的复制过来，这样不就解决问题了。

也有人说，那我用虚拟机模板，不也一样可以解决这个问题吗？
但是前面我们讲了，虚拟机是带操作系统的，所以会有以下几个缺陷：

1. 资源占用太多
   虚拟机会独占一部分内存和硬盘空间。它运行的时候，其它程序就不能使用这些资源了。哪怕虚拟机里面的应用程序，真正使用的内存只有 1MB，虚拟机依然需要几百 MB 的内存才能运行。

2. 冗余步骤多
   虚拟机是完整的操作系统，一些系统级别的操作步骤，往往无法跳过，比如用户登录。

3. 启动起来较慢
   启动操作系统需要多久，启动虚拟机就需要多久，所以可能要等几分钟，应用程序才能真正运行。

对比容器，上面的这是缺陷恰恰是容器的优势。

1. 启动快
   容器里面的应用，直接就是底层系统的一个进程，而不是虚拟机内部的进程。所以，启动容器相当于启动本机的一个进程，而不是启动一个操作系统，速度就快很多。

2. 体积小
   对比虚拟机的整个操作系统打包，容器只要包含应用所要用到的组件就可以了。所以容器文件要小的多。

3. 资源占用少
   容器只占用需要的资源，不占用那些没有用到的资源；虚拟机由于是完整的操作系统，不可避免要占用所有资源。另外，多个容器可以共享资源，虚拟机都是独享资源。

但是在有些功能上，容器技术也是不如虚拟机的。

Docker

在计算虚拟化简介中介绍虚拟化的历史时，我们提到最开始提出容器的概念是：Linux中的LXC。但是我们现在提到最多的容器技术是Docker。

Docker

属于 Linux 容器的一种封装，提供简单易用的容器使用接口。它是目前最流行的 Linux 容器解决方案。

Docker 将应用程序与该程序的依赖，打包在一个文件里面。运行这个文件，就会生成一个虚拟容器。程序在这个虚拟容器里运行，就好像在真实的物理机上运行一样。有了 Docker，就不用担心环境问题。总体来说，Docker 的接口相当简单，用户可以方便地创建和使用容器，把自己的应用放入容器。容器还可以进行版本管理、复制、分享、修改，就像管理普通的代码一样。

Docker 的主要用途，目前有三类。

• 提供一次性的环境。比如，本地测试他人的软件、持续集成的时候提供单元测试和构建的环境。
• 提供弹性的云服务。因为 Docker 容器可以随开随关，很适合动态扩容和缩容。
• 组建微服务架构。通过多个容器，一台机器可以跑多个服务，因此在本机就可以模拟出微服务架构。

Docker采用的是 Client/Server 架构。客户端向服务器发送请求，服务器负责构建、运行和分发容器。客户端和服务器可以运行在同一个 Host 上，客户端也可以通过 socket 或 REST API 与远程的服务器通信。
)

Docker 的核心组件包括：

• Docker 客户端 – Docker Client

    最常用的Docker客户端是命令行。通过命令行我们可以在主机上构建和运行容器。
  

• Docker 守护进程 - Docker daemon

    Docker服务器组件指的是Docker daemon，它运行在Linux的操作系统上，负责创建、运行、监控容器，同时也构建和存储镜像。
  

• Docker 镜像 - Image

    它是Docker的关键组件，用来创建Docker容器。
    Docker镜像类似虚拟机模板，只可读。如果需要修改，需要先转换为容器，修改完以后再转为镜像。
  

• Registry

   存放 Docker 镜像的仓库，Registry可分为私有和公有两种。
  

• Docker 容器 - Container

    Docker容器是Docker镜像运行的实例。
  

在云计算3.0的时代，主要的技术就是Docker为主的容器技术，那么在2.0时代我们更多的是用OpenStack。

OpenStack

)
OpenStack是目前最为流行的开源云操作系统框架。自2010年6月首次发布以来，经过数以千计的开发者和数以万计的使用者的共同努力，OpenStack不断成长，日渐成熟。目前，OpenStack的功能强大而丰富，已经在私有云、公有云、NFV。等多个领域得到了日益广泛的生产应用。

与此同时，OpenStack已经受到了IT业界几乎所有主流厂商的关注与支持，并催生出大量提供相关产品和服务的创业企业，在事实上成为了开源云计算领域的主流标准。时至今日，围绕 OpenStack已经形成了一个繁荣而影响深远的生态系统，OpenStack已经是云计算时代一个无法回避的关键话题。可以说，不了解OpenStack，就无法理解当今云计算技术的发展，也无法把握云计算产业的脉搏。

OpenStack：

一种搭建云平台的解决方案。
OpenStack官网对OpenStack的定位：一个云操作系统。
可以说OpenStack是一个云操作系统框架更加合适。

关于云操作系统，我们可以借助PC电脑操作系统来类比，进行理解。
操作系统，是计算机系统领域里一个至关重要的概念。有了操作系统，我们才能将计算机系 统中的各类软硬件整合起来，形成一个能够完成各类处理任务的完整系统，为用户提供服务。这 个描述较为抽象，但结合到日常生活与工作中的实例，就清楚易懂多了。无论是服务器和个人电脑上的Linux、Windows，还是手机上的Android、IOS， 都是操作系统的常见实例。 无论是服务器、个人电脑还是手机上的操作系统，本质上，其核心功能都可以概括为五个方面，即资源接入与抽象、资源分配与调度、应用生命周期管理、系统管理维护和人机交互支持。换言之，只有具备了以上这五个方面的主要功能，一个操作系统才能够实现各类软硬件的整合，让系统具备为用户提供服务的能力。
具体而言：

1. 资源接入与抽象，是指将各类硬件设备，如CPU、内存、本地硬盘、网卡等， 接入到系统中，并将其抽象为操作系统可以识别的逻辑资源，以此作为操作系统对各类硬件资源实施管理的基础
2. 资源分配与调度，是指利用操作系统的资源管理能力，将上述不同的硬件资源，按照需求的类型和数量，分配给不同的系统软件或应用软件，供其使用
3. 应用生命周期管理，是指协助用户实现各类应用软件在操作系统上的安装、升级、启动、停止、卸载等管理操作
4. 系统管理维护，是指协助系统管理员实现对系统自身的各类配置、监控、升级等管理操作
5. 人机交互支持，指提供必要的人机界面，支持系统管理员和用户对系统实施各类操作。

与之对应，一个完整的云操作系统，同样应该能够具备上述五个方面的主要功能。其核心区别只是在于，云操作系统需要管理的，是一个由大量软硬件组成的分布式的云计算系统，而一个普通操作系统需要管理的，则是一台服务器、一台个人电脑，或者一部手机。
针对云操作系统，上述五项主要功能的内容应该是：

1. 资源接入与抽象，是指将各类服务器、存储、网络设备等硬件资源，通过虚拟化的或者可软件定义的方式，接入到云计算系统中，并将其抽象为云操作系统可以识别的计算、存储、网络等资源池，以此作为云操作系统对各类 硬件资源实施管理的基础
2. 资源分配与调度，是指利用云操作系统的资源管理能力，将前述的不同资源，按照不同的云租户对于资源类型与数量的不同需求，将资源分配给各个租户，以及不同租户的不同应用
3. 应用生命周期管理，是指协助租户实现各类云应用在云操作系统上的安装、启动、停止、卸载等管理操作
4. 系统管理维护，是指协助系统管理员实现对于云计算系统的各类管理与运维操作
5. 人机交互支持，指提供必要的人机界面，支持系统管理员和普通租户对系统实施各类操作。

由上述介绍可以看出，虽然云操作系统比我们日常接触的操作系统复杂很多，但其最为关键的五项主要功能，其实是可以一一对应的。通过这种对应，我们可以更为直观地理解云操作系统这个概念。而OpenStack，则是实现云操作系统的关键组件，或者说，是构建一个完整的云操作系统的框架。

要构建一个完整的云操作系统，需要对大量软件组件进行有机整合，让它们协同工作，共 同提供系统管理员和租户所需的功能与服务。而OpenStack本身，尚且不能独立具备一个完整云操作系统所需的全部能力。举例而言：在上面提到的云操作系统的五项主要功能中，OpenStack不能独立实现资源接入与抽象，而需要和底层的虚拟化软件、软件定义存储、软件定义网络等软件相配合；OpenStack不能独立提供完善的应用生命周期管理能力，而需要在上层集成各类管理软件平台；OpenStack自身不具备完整的系统管理维护能力，在投入生产实用时，还需要集成各类管理软件与维护工具；OpenStack自身提供的人机界面，其功能也还不够丰富强大，等等。
由此不难看出，想在OpenStack基础上构建一个完整的云操作系统，需要将OpenStack与其它一些软件组件进行集成，以实现OpenStack自身并不提供的能力。因此，OpenStack自身的准确定位， 是一个云操作系统框架。基于这个框架，可以集成不同的各类组件，实现满足不同场景需要的云操作系统，并在此基础上，最终构建完整的云计算系统。

OpenStack与云计算系统的关系

基于前面的介绍，不难看出，OpenStack与云计算系统之间，既紧密联系，又相互区别。
OpenStack是构建云操作系统的框架。使用云操作系统，集成并管理各类硬件设备，并承载各类上层应用与服务，才能最终形成一个完整的云计算系统。由此可见，OpenStack是云计算系统的核心软件组件，是构建云计算系统的基础框架，但OpenStack和云计算系统并不能直接等同。

OpenStack与计算虚拟化的关系

计算虚拟化，是很多读者非常熟悉的概念。其对应的软件实现，就是平常所说的Hypervisor，如开源的KVM、Xen，以及VMware的vSphere、华为的FusionCompute、微软的Hyper-V等。OpenStack与计算虚拟化之间的关系，是目前仍然被频繁混淆的一个问题。理解这二者之间的联系与区别，也是理解OpenStack的关键之一。

OpenStack是一个云操作系统的框架。为构建完整的云操作系统，特别是为实现资源接入与抽象的功能，OpenStack需要与虚拟化软件实施集成，从而实现对服务器的计算资源的池化。应该指出的是，在资源池化的过程中，物理资源虚拟化的功能，仍然由虚拟化软件完成。举例而言，在使用KVM作为OpenStack的虚拟化软件时，仍然由KVM完成将一台物理服务器虚拟为多台虚拟机的功能，而OpenStack负责记录与维护资源池的状态。例如，系统中一共有多少台服务器，每台服务器的资源共有多少，其中已经向用户分配了多少，还有多少资源空闲。在此基础上，OpenStack负责根据用户的要求，向KVM下发各类控制命令，执行相应的虚拟机生命周期管理操作，如虚拟机的创建、删除、启动、关机等。由此可见，两相对比，OpenStack更像是系统的控制中枢，是云操作系统的“大脑”；计算虚拟化软件则更像是系统的执行机构，是云操作系统的“肢体”。二者分工合作，共同完成对云计算系统中的计算资源池的管理，但绝不能认为OpenStack等同于计算虚拟化软件。

OpenStack的优势

1. 开放
   OpenStack是开源的，而且OpenStack的开源，不仅体现在简单的源代码开放，更体现在其设计、开发、测试、发布的全流程中。

2. 灵活
   OpenStack的灵活，首先体现在其大量使用插件化、可配置的方式进行设计。最为突出的 体现，就在于OpenStack采用插件化的方式实现不同类型计算、存储、网络资源的接入，由此 实现OpenStack对于不同类型资源的灵活接入与管理，用一套架构实现了对于不同厂商、不同 类型设备的资源池化，例如，在计算领域，可以以插件化的形式接入KVM、Xen、vCenter、 FusionCompute等不同的Hypervisor；在存储领域，可以以插件化的形式实现对不同厂商的存储设备，以及Ceph、FusionStorage、vSAN等不同的软件定义存储的管理；在网络领域，可以实现对不同的网络硬件设备，OVS、Liunx-bridge、 HAProxy等开源网络组件，以及多种SDN控制器的接入。并且，这些接入都是通过可配置的方式加以选择。当在不同的资源之间进行选择时，OpenStack自身并不需要重新打包发布，只需通过配置项选择不同的接入插件即可，非常方便。
   在此基础上，OpenStack的灵活还体现在不依赖于任何特定的商用软硬件。换言之，任何商用软硬件产品在OpenStack中一定是可选、可替换的，从而严格保证用户可以使用完全开源、开放的方案来构建基于OpenStack的云计算系统，而完全不必担心被锁定在某些特定厂商的产品之上。

3. 可扩展
   OpenStack的架构高度可扩展。具体而言，其扩展性体现在功能和系统规模两个方面。从功能视角看，OpenStack由多个相互解耦的项目组成。不同的项目分别完成云计算系统中的不同功能，如身份认证与授权服务、计算服务、块存储服务、网络服务、镜像服务、对象存储服 务等。对于一个特定场景下的云计算系统，系统设计人员可以根据实际需要决定使用OpenStack中的若干个项目，也可以在系统上线后，根据需求继续引入新的OpenStack项目。OpenStack的一些项目自身也具有功能可扩展性。系统设计人员可以在这些项目中引入新的功能模块，在不影响项目既有功能使用的前提下，对其功能进行扩展。从系统规模视角看，OpenStack总体上遵循了无中心、无状态的架构设计思想。其主要项目，均可实现规模水平扩展，以应对不同规模的云计算系统建设需求。在系统建成后，可根据应用负载规模的实际增长，通过增加系统管理节点和资源节点的方式，逐渐扩展系统规模。这种架构可以有效避免高额的初始建设投资，也降低了系统初始规划的难度，为云计算系统的建设者和运营者提供了充分的扩展空间。

OpenStack架构与组成

在2010年OpenStack社区首次发布其第一个发行版——Austin时，OpenStack仅包含两个项目Nova和Swift，仅能实现非常简单和基础的功能。时至今日，OpenStack已经日渐成熟和强大，其组成项目也已经大大增多，仅包含在Mitaka版本release notes中的服务项目就多达29个。各个项目各司其责，分工合作，共同形成了一个架构灵活、功能丰富、扩展性强的云操作系统框架。

本文将优先选择 OpenStack中最为关键和有代表性的部分项目，进行扼要介绍，以便帮助读者更为直观地了解 OpenStack。

1. Keystone：身份认证与授权服务
   将计算、存储、网络等各种资源，以及基于上述资源构建的各类IaaS、PaaS、SaaS层服务，在不同的用户间共享，让众多用户安全地访问和使用同一个云计算系统，是一个云操作系统的基本能力。而实现这个能力的基础，就是一个安全可靠的身份认证与授权服务。而Keystone就是OpenStack的身份认证与授权服务项目。Keystone负责对用户进行身份认证，并向被认定为合法的用户发放令牌（token）。用户持 Keystone发放的令牌访问OpenStack的其它项目， 以使用其提供的服务。而各个组件中内嵌的令牌校验和权限控制机制，将与Keystone配合实现对用户身份的识别和权限级别的控制，保证只有恰当的用户能够对恰当的资源实施恰当的操作，以 此保证对不同用户资源的隔离与保护。
2. Nova：计算服务
   向用户按需提供不同规格的虚拟机，是任何一个云操作系统最为基础的功能。而Nova就是 OpenStack中负责提供此类计算服务的项目。Nova的核心功能，是将大量部署了计算虚拟化软件 （即Hypervisor） 的物理服务器统一纳入管理之下，组成一个具有完整资源视图的逻辑资源池。在此基础上，Nova通过接收不同用户发起的请求，对资源池中的资源进行生命周期管理操作。其中最为核心的，就是虚拟机的创建、删除、启动、停止等操作。通过执行客户发起的虚拟机创建操作，Nova将逻辑资源池中的CPU、内存、本地存储、IO设备等资源，组装成不同规格的虚拟机，再安装上不同类型的操作系统，最终提供给用户进行使用，由此满足用户对于计算资源的需求。
   除了虚拟机资源管理服务能力之外，Nova还通 过与Ironic项目配合，共同为用户提供裸机资源管理服务能力。具体而言，Nova可以接收用户发起的裸机资源申请，然后调用Ironic项目的对应功能，实现对裸机的自动化选择、分配与操作系统安装部署，从而使得用户可以获得与虚拟机资源使用体验相当的物理机资源使用体验。
3. Ironic：裸机管理
   Ironic通过与Nova相配合，共同为用户提供裸机服务能力。
   在实际工作时，Ironic直接负责对物理服务器的管理操作。一方面，在物理服务器被纳入到资源池之中时，Ironic负责记录物理服务器的硬件规格信息，并向Nova上报；另一方面，在用户发起裸机管理操作时，Ironic负责根据Nova的指令，对相应的物理服务器执行具体的管理操作动作。例如，当用户发起一个创建裸机操作时，Ironic需要根据Nova调度的结果，对选定的物理服务器执行硬件初始化配置、操作系统安装等一系列具体操作，以完成裸机创建动作。
4. Glance：镜像服务
   通常而言，在虚拟机被创建之后，都需要为其安装一个操作系统，以便用户使用。为此，云计算系统中往往需要预置若干不同种类、不同版本的操作系统镜像，以便用户选用。此外，在一 些应用场景下，为进一步方便用户，镜像中还需要预装一些常用的应用软件，这将进一步增加镜 像的种类与数量。为此，云操作系统必须具备镜像管理服务能力。Glance就是OpenStack中的镜像服务项目。
   Glance主要负责对系统中提供的各类镜像的元数据进行管理，并提供镜像的创建、删除、查询、上传、下载等能力。但在正常的生产环境下，Glance本身并不直接负责镜像文件的存储，而是仅负责保管镜像文件的元数据，本质上是一个管理前端。Glance需要与真正的对象存储后端对接，才能共同提供完整的镜像管理与存储服务能力。
5. Swift：对象存储服务
   对象存储服务，是云计算领域中一种常见的数据存储服务，通常用于存储单文件数据量较大、访问不甚频繁、对数据访问延迟要求不高、对数据存储成本较为敏感的场景。Swift就是OpenStack中用于提供对象存储服务的项目。
   与OpenStack中大部分只实现控制功能、并不直接承载用户业务的项目不同，Swift本身实现了完整的对象存储系统功能，甚至可以独立于 OpenStack，被单独作为一个对象存储系统加以应用。
   此外，在OpenStack系统中，Swift也可以被用做Glance项目的后端存储，负责存储镜像文件。
6. Cinder：块存储服务
   在典型的、基于KVM虚拟化技术的OpenStack部署方案下，Nova创建的虚拟机默认使用各个计算节点的本地文件系统作为数据存储。这种数据存储的生命周期与虚拟机本身的生命周期相同，即当虚拟机被删除时，数据存储也随之被删除。如果用户希望获得生命周期独立于虚拟机自身的、能够持久存在的块存储介质，则需要使用 Cinder提供的块存储服务，也称为卷服务。
   Cinder负责将不同的后端存储设备或软件定义存储集群提供的存储能力，统一抽象为块存储资源池，然后根据不同需求划分为大小各异的卷，分配给用户使用。
   用户在使用Cinder提供的卷时，需要使用 Nova提供的能力，将卷挂载在指定的虚拟机上。 此时，用户可以在虚拟机操作系统内看到该卷对应的块设备，并加以访问。
7. Neutron：网络服务
   网络服务，是任意云操作系统IaaS层能力的关键组成部分。只有基于稳定、易用、高性能的云上虚拟网络，用户才能将云计算系统提供的各类资源和服务能力连接成真正满足需求的应用系统，以解决自身的实际业务需求。
   Neutron是OpenStack中的网络服务项目。Neutron及其自身孵化出来的一系列子项目，共同为用户提供了从Layer 2到Layer 7不同层次的多种网络服务功能，包括Layer 2组网、Layer 3组网、内网DHCP管理、Internet浮动IP管理、内外网防火墙、负载均衡、VPN等。整体而言，Neutron的Layer 2、Layer 3服务能力已经较为成熟。时至今日，Neutron已经取代了早期的novanetwork，成为了OpenStack中Layer 2、Layer3的主流虚拟网络服务实现方式。与之对应，Neutron的Layer 4至Layer 7服务能力仍在迅速发展中，目前已具备初步应用能力。
   需要说明的是，OpenStack的DNS即服务能力，并未包含在Neutron项目的功能范围当中，而是由另一个单独的项目Designate负责实现。
8. Heat：资源编排服务
   云计算的核心价值之一，即在于IT资源与服务管理和使用的自动化。换言之，在引入云计算技术之后，大量在传统IT领域中需要依靠管理人员或用户通过手工操作实现的复杂管理任务，应当可以通过调用云操作系统提供的API，以程序化的方式自动完成，从而显著提高IT系统管理的效率。
   在上述提及的IT领域复杂管理操作中，用户业务应用系统的生命周期管理操作，即应用系统的安装、配置、扩容、撤除等，可谓是具有代表性的一类。这类操作的复杂与耗时耗力，与当前不断凸现的业务快速上线、弹性部署诉求，已经表现出明显的不适应性。Heat项目的出现，就是为了在OpenStack中提供自动化的应用系统生命周期管理能力。具体而言，Heat能够解析用户提交的，描述应用系统对资源类型、数量、连接关系要求的定义模板，并根据模板要求，调用Nova、Cinder、Neutron等项目提供的API，自动实现应用系统的部署工作。这一过程高度自动化，高度程序化。同样的模板，可以在相同或不同的基于OpenStack的云计算系统上重复使用，从而大大提升了应用系统的部署效率。在此基础上，Heat还可以与OpenStack Ceilometer项目的Aodh子项目相配合，共同实现对于应用系统的自动伸缩能力。这更进一步简化了部分采用无状态、可水平扩展架构的应用系统的管理，具有典型的云计算服务特征。
9. Ceilometer：监控与计量
   在云计算系统中，各类资源均以服务化的形式向用户提供，用户也需要按照所使用资源的 类型和数量缴费。这种基本业务形态，就要求云操作系统必须能够提供资源使用量的监控与计量能力。这正是OpenStack引入Ceilometer项目的根本动机。
   Ceilometer项目的核心功能，是以轮询的方式，收集不同用户所使用的资源类型与数量信 息，以此作为计费的依据。
   在此基础上，Ceilometer可以利用收集的信息，通过Aodh子项目发送告警信号，触发Heat项目执行弹性伸缩功能。
   需要说明的是，Ceilometer项目自身并不提供计费能力。系统设计者需要将其与适当的计费模块相对接，才能实现完整的用户计费功能。目前，OpenStack社区已经创建了CloudKitty项目，作为OpenStack社区原生的计费组件。但该项目当前尚处于较为初期的阶段，难以直接商用。
10. Horizon：图形界面
    Horizon项目是OpenStack社区提供的图形化人机界面。经过社区长期的开发完善，Horizon界面简洁美观，功能丰富易用，可以满足云计算系统管理员和普通用户的基本需求，适于作为基于OpenStack的云计算系统的基本管理界面使用。
    此外，Horizon的架构高度插件化，灵活而易于扩展，也便于有定制化需求的系统设计人员针对具体场景进行增量开发。

其他新兴技术介绍

雾计算

雾计算（Fog Computing），在该模式中数据、（数据）处理和应用程序集中在网络边缘的设备中，而不是几乎全部保存在云中，是云计算（Cloud Computing）的延伸概念，由思科（Cisco）提出的。这个因“云”而“雾”的命名源自“雾是更贴近地面的云”这一名句。
雾计算，这个名字由美国纽约哥伦比亚大学的斯特尔佛教授起的，他当时的目的是利用“雾”来阻挡黑客入侵。后来思科首次正是提出，赋予雾计算新含义。雾计算是一种面向物联网的分布式计算基础设施，可将计算能力和数据分析应用扩展至网络“边缘”，它使客户能够在本地分析和管理数据，从而通过联接获得即时的见解。
雾计算和云计算一样，十分形象。云在天空飘浮，高高在上，遥不可及，刻意抽象；而雾却现实可及，贴近地面，就在你我身边。雾计算并非由性能强大的服务器组成，而是由性能较弱、更为分散的各类功能计算机组成，渗入工厂、汽车、电器、街灯及人们物质生活中的各类用品。

边缘计算

云计算从进入我们视线到今，已经发展了十几年，在商业上取得了很大的成功，边缘计算则是云计算继续发展的产物，目前还处于概念阶段。
引用Wikipedia对Edge Computing的定义，边缘计算指的是：与将数据传到远程的云端进行处理相反，边缘计算则是在靠近数据源头的网络边缘提供计算和存储资源。
通俗的说，边缘计算是去中心化或分布式的云计算，原始数据不传回云端，而是在本地完成分析。看好边缘计算的人认为计算能力正在从云端向边缘移动，因此边缘计算会成为下一个像云计算这样成功的技术爆发点。另一方面，边缘计算是驱动物联网的关键技术，因此边缘计算的推动者往往是从事物联网的人。
边缘是一个很笼统的概念，它是指接近数据源的计算基础设施，不同的边缘计算提供商往往有不同的边缘。比如美国电信公司AT&T的边缘就是离客户几英里的蜂窝网络基站；对于世界最大的CDN厂商阿卡麦，边缘则是指遍布全球的CDN设备；对于机场的监控设备，边缘就是覆盖整个机场无死角的高清摄像头。
根据Fog Computing vs. Edge Computing: What’s the Difference？（https://www.automationworld.com/fog-computing-vs-edge-computing-whats-difference）的观点，雾计算与边缘计算都是将智能和计算能力推向靠近数据来源的位置，因此他们常常被混用。他们的区别也正是计算能力（大脑）所处的位置：
• 雾计算将计算能力推向局域网，在雾节点或物联网的网关处完成数据处理。
• 边缘计算将边缘网关的智能，处理能力和通信能力直接推送到诸如可编程自动化控制器的设备。

微服务

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间相互 协调、相互配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用 轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API），每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对于具体的服务，应根据业务上下文，选择合适的语言、工具对其进行构建。 微服务架构模式，核心是将复杂应用划分成小颗粒度、轻量化的自治服务，并围绕微服务开展服务的开发和服务的治理，这是实现云化软件的一种架构模式，也是近两年最热门的架构模式。

实践中，微服务架构模式中的微服务具有如下几个主要特点：

1. 小
   微服务架构通过对于特定的业务领域进行分析和业务建模，将复杂的业务逻辑剥离成为小而 专一、耦合度低并且高度自治的一组服务，每个服务都是很小的应用。 虽然强调每个服务小，但是每个微服务本身还是完整的应用，这与我们通常说的组件、插件、共享库是有区别的。微服务的规模也没有严格的定义，通常一个微服务的开发团队在6~8人左右，一个微服务的架构重构可以在2周时间内完成这样的描述来确定一个大致的规模。这样的开发团队能够完成的开发规模就是一个微服务规模的上限。
2. 独
   独，指的是微服务的独立性。这里的独立性主要是针对一个微服务应用的交付过程而言的， 也就是开发、测试以及部署升级的独立。在微服务架构中，每个服务都是一个独立的业务单元。这个业务单元在部署形态上，是独立的业务进程。对某个微服务进行改变，不会影响其它的服务。对于每个微服务，都有独立的代码库。某个微服务的代码修改，不会影响其它的微服务。 对于每个微服务，都有独立的测试验证机制，不必担心破坏完整功能而开展大范围的回归测试（这往往是现有大集成全覆盖测试研发模式中消耗很大，但测试结果却不让人放心的地方）。
3. 轻
   微服务强调服务自治，因此服务之间的交互，必须采用消息通信的方式予以开展。从效率 的角度，应当选择轻量级的通信机制。在软件实现的实践上，RESTful API的方式被广泛采用。这种通信机制的优点是语言无关、平台无关，并且十分便于制定通信协议，保证接口的前向兼 容性。
   在从传统软件架构向微服务化架构演进的过程中，业界实践部分也保留了RPC的通信机制，但要求基于RPC进行通信协议的制定，以保证接口的前向兼容性，实际是为了支撑服务间的独立和服务的松耦合态。
4. 松
   松是指微服务间松耦合，每个微服务可独立部署，互相之间没有部署先后顺序的依赖，微服 务的接口前向兼容，单独微服务的上线，对于其他服务而言不产生关联，可以独立地灰度发布和灰度升级。
   实现微服务间松耦合还有一点需要注意，就是一个微服务完成且最好仅完成一件事，业务逻辑的独立是微服务间解耦的关键。

无服务器

无服务器和Functions-as-a-Service（FaaS）是云计算最新的热点趋势。

如同许多新的概念一样，Serverless目前还没有一个普遍公认的权威的定义。最新的一个定义是这样描述的

无服务器架构是基于互联网的系统，其中应用开发不使用常规的服务进程。相反，它们仅依赖于第三方服务（例如AWS Lambda服务），客户端逻辑和服务托管远程过程调用的组合。