云服务目前已经发展了很多年，技术也是层出不穷，这里把目前比较主流或者说发展比较快的技术路线做一个知识储备。

一、容器云（docker）

容器的本质是基于镜像的跨环境迁移。镜像是容器的根本性发明，是封装和运行的标准。在2008 年第一个比较完善的容器技术LXC 就已经诞生，2013 年Docker 诞生是容器技术发展史上的里程碑事件，Docker 公司引入一整套与容器相关的生态系统，因此也成为之后容器技术的主流。

相比于传统的虚拟化技术而言，容器技术是一种轻量级的虚拟化技术，资源占用少、部署和迁移速度快是其最大优势。近年盛行的传统虚拟化技术以平台虚拟化技术为主，包括VMware、KVM、Xen 等等；而容器技术属于操作系统虚拟化，其中关注度最高的是Docker公司推出的容器技术。以VMware为代表的平台虚拟化技术和以Docker为代表的容器技术的最主要的区别在于——前者需要在Hypervisor之上再为各个虚拟机虚拟出一个操作系统（GuestOS）；而容器技术不依赖于Hypervisor，可以直接利用宿主机的操作系统，所以抽象层比虚拟机少（主要是少了虚拟机操作系统这一层），因此更加轻量化、启动速度更快（因为操作系统会占用大量的内存资源）。上述特点分别决定了容器技术与VMware 相比可以在同样的硬件环境中支持更多的实例（因为释放了虚拟机操作系统占用的内存），而且部署、迁移速度很快（因为轻量且不用启动虚拟机OS）。但是容器技术也有缺点，那就是隔离性不如虚拟机。

镜像：Docker 就像往集装箱里装货物的码头工人那样，它把应用打包成具有某种标准规格的集装箱，用计算机领域的语言来说，这种按照一定规格封装的集装箱叫「镜像」。即将原来的代码添加点额外的内容（eg 格式等），生产出来的一个符合某种标准的东西。

Docker 技术在2013 年诞生，但是在2015 年才开始逐渐流行。其主要原因在于在“微服务”出现之前，Docker 技术虽好，但是没有应用场景，所以“好而无用”，无法普及，而“微服务”的出现也同时带动了Docker 另一应用场景“DevOps”的落地普及。

二、微服务

自2015 年起微服务逐步风靡全球，各行业正逐渐经历“架构变革”。“微服务架构”提出是在2013 年，自2015 年逐步风靡并开始广泛应用。如今国外诸如谷歌、亚马逊、Netflix、Twitter 等明星企业，国内诸如BATJ、华为、小米等科技巨头内部微服务技术的运用均已十分成熟，甚至大部分企业已经完成/正准备将微服务能力对外输出并且商业化（例如腾讯云分布式服务框架TSF、华为云微服务云应用平台ServiceStage 及微服务引擎CSE）；且值得关注的是在赢时胜下游客户集中的金融领域，除了蚂蚁金服、京东金融这样的Fintech 领军企业，像上交所、华泰证券、招商银行、浦发银行、民生银行、恒丰银行这样的传统金融机构均已经完成部分系统往微服务架构的转变。

微服务是一种软件架构，而软件架构目前正在经历从传统单体式架构、SOA架构往微服务架构转型的过程。传统单体式应用程序把所有的功能都放在一个单一进程中并且只能通过在多个服务器上复制这个单体进行扩展（基于上述特性单体式架构也被成为“巨石架构”）；而微服务架构把原来单体式架构中的每一个功能元素拆分出来放到一个独立的服务中，并且通过跨服务器分发这些服务进行扩展，只在需要时复制。

企业转型微服务架构为确定性趋势，其原因在于传统的单体式架构、SOA 架构存在着诸多缺陷，而微服务架构与之相比具有诸多优势且正好解决了各企业在传统架构下的诸多痛点，其中最主要的是解决了单体式架构的部署问题和扩展性问题。

单体式架构只能整体部署，微服务组件可独立部署上线：一般复杂的单体式架构应用程序都由几百万行代码构成，日常业务改变需要对代码进行频繁修改，但是在单体式架构下即使只修改了其中一行代码也需要重新部署整个应用程序才能发布该变更。相比之下，把原来巨大的单体式架构拆分成多个细小的微服务之后，在微服务架构中各个服务的部署是独立的，所以只需要针对某个功能对应的微服务中的部分代码进行修改后，将修改过的微服务单独部署上线即可。

单体式架构只能整体扩展，而微服务架构下每一个组件可单独扩展：单体架构只能作为一个整体进行扩展，即使系统中只有一小部分存在性能问题，也需要对整个服务进行扩展；如果使用较小的多个服务（即微服务），因为微服架构模式每个微服务之间是低耦合的，微服务内部是高内聚的，则可以只对需要扩展的服务进行扩展，这样就可以把那些不需要扩展的服务运行在更小的、性能稍差的硬件上。

为什么说容器云平台是支撑微服务应用的“不二之选”？

微服务的部署方式一共4 种，其中容器PaaS 云平台是最佳方式，因此由传统架构向微服务架构转型的趋势将带动容器PaaS 云平台需求的快速提升。微服务的部署方式包括单主机多服务实例、单主机单服务实例、单容器单服务实例、PaaS 平台4 种方式。其中：

单主机多服务：这种方式不可取主要有三个原因：（1）首先需要用传统的虚拟化技术（VMware、VSphere、Xen 和KVM 等）虚拟出主机，但是如前所述，传统的虚拟化技术较“重”，本身会占用过多资源从而导致服务的可用资源减少。（2）管理基础设施的团队工作量与主机量成正比，主机数量增加将相应增加团队工作量。（3）限制技术栈的选择。

单主机单服务：这种方式避免了单主机多服务的问题，简化了监控和错误恢复，减少潜在的单点故障，且不会限制技术栈的选择。其缺点在于主机数量的增加，会引入很多隐式代价（这种方式主机数量比单主机多服务增加得更明显，因为一个服务对应一个主机）。

单容器单服务：即把不同的服务放在同一个容器中，再把容器放置到单台主机上的模式。这么做的好处是使用容器来简化管理，比如对多实例提供集群支持、监控等；另一方面可以节省语言运行时的开销。其缺点在于会限制技术栈的选择，限制自动化和管理技术的选择，影响服务的可伸缩性等。

PaaS 容器云平台：之所以容器云是最适合微服务的支撑平台，是因为容器云的部署能力和扩展需求分别高度契合了微服务的部署和扩展需求。一方面，在微服务架构下，原来单体式应用被拆分成许多个微服务进程，因此导致部署难度增加，而容器云最大的特点之一是支持快速部署，解决了微服务部署难度增加的问题。

另一方面，微服务需要进行横向扩展以提升性能，而容器云的实例快速伸缩能力又刚好满足了微服务的扩展需求。除此之外容器云支持快速升级与回退、支持滚动更新、蓝绿部署、支持大规模大集群管理的性能也进一步提升了微服务的性能。

三、DevOps

DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。

它是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

DevOps 实际上就是将原来从软件（需求）、开发、测试、预发、上线、运营等软件工程生命周期流程实现自动化，即搭建一条IT 服务从开发到交付至生产环境的“软件生产流水线”。

目前各企业纷纷采用DevOps 的最主要的目的在于实现产品的快速交付（在企业实施DevOps 之前，往往存在比较多的重复劳动）。以华泰证券为例，在引入了灵雀云的容器云平台并且实施DevOps 之后，华泰证券以往传统的金融研发模式大概需要一个月上线，但是现在大部分靠自主研发的应用，基本上都提到一、两个星期发布一个版本，交付速度提高至传统模式下的2~4 倍。

DevOps 之所以能实现敏捷开发和快速交付，主要依靠两个方面：

横向部门的打通：将原来相互割裂的开发、测试、运维部门人员融合在一起并重新组合为一个个同时包含“开发、测试、运维”人员的小团队，每个小团队负责每一个微服务（完整的服务由许多个微服务构成）的开发、测试和运维——这样就由原来“串行”的开发、测试、运维流程变为“并行”流程。（康威定律：任何组织在设计一套系统时，所交付的设计方案在结构上都与该组织的沟通结构保持一致。在实施DevOps 时需要进行开发和运维团队的拆分实际上是在与微服务架构转型相配合）。

纵向工具链的打通：工具链的打通使得开发者们在交付软件时可以完成生产环境的构建、测试和运行，即“谁开发，谁运行”，打通应用全生命周期（需求、设计、开发、编译、构建、测试、打包、发布、配置、监控等）的工具集成。纵向集成中DevOps 强调的重点是跨工具链的“自动化”，最终实现全部人员的“自助化”。例如，项目组的开发人员可以通过DevOps 的平台上，自主申请开通需要的各种服务，比如开通开发环境、代码库等。

为什么容器是最适合DevOps 的工具？

容器之所以是最适合DevOps 的工具，是因为容器的本质是基于镜像的跨环境迁移，而生产、开发和测试环境中就需要频繁的迁移。虚拟机镜像和容器镜像相比，大小高达上百G，不适合大量镜像的频繁迁移。因此DevOps需要以容器云平台进行支撑。

四、DevOps、微服务、容器云之间的关系

DevOps、微服务、容器云三者是相辅相成，不可分割的关系，共同构成了新一代IT系统的“三大基石”——微服务主要解决的是开发期的设计问题，DevOps 则是解决开发、测试与运维之间的衔接问题，容器云则是重点在于简化微服务的部署与解放运维。如果不是微服务，根本不需要容器，因为虚拟机就能解决除微服务之外的所有虚拟化问题；同时也不需要DevOps，因为即使开发和运维沟通再慢，也能解决所有的问题。三者相互依存的本质原因是因为微服务将原来单个业务系统解耦拆分成了一个个可以独立开发，设计，运行和运维的小应用（组件），组件数量大幅增加，由于微服务架构下组件越多，将使得集成和部署的难度增加（如果拆分的组件越多，这些组件之间本身的集成和部署运维就越复杂）。那么为了解决这个问题，大家就通过构建DevOps 平台来克服微服务的这个缺陷。

微服务需要构建一个一体化的DevOps平台，在做好单个组件本身的持续集成的基础上，增加多个组件的打包部署和组件间的集成。如果没有DevOps的话，微服务将变得非常复杂混乱。而且在进行DevOps之前首先需要对传统系统进行微服务改造，以及容器化，否则软件系统未进行解耦拆分，那么DevOps的横向开发、测试、运维部门的打通也无法实现（因为在康威定律下，系统架构改变，部门组织结构也要进行相应改变，每个微服务组件都对应一个开发运维小团队；如果没有进行微服务解耦拆分，就没办法实现微服务与开发运维小团队的映射关系）。