第1章 云计算概述

1.1 虚拟化技术简史

1.1.2 X86平台虚拟化历史

• VMware Workstation主要是在Windows上创建虚拟机，虚拟机可使用Linux或Windows系统。此外，通过虚拟机快照方式，可快速完成软件的回归测试、系统备份恢复以及POC演示等活动；
• Xen属于半虚拟化技术，需要对部署在虚拟机上的操作系统的代码进行少量修改，使其适应虚拟化环境，亚马逊和阿里云的公有云虚拟机都是基于Xen技术定制演化而来；Xen允许虚拟机操作系统跨过虚拟化层直接操作底层硬件，从而保证虚拟机的性能基本达到裸机运行的性能；
• KVM属于全虚拟化，即无须对操作系统进行任何改造，直接就在Linux内核运行，KVM创建的虚拟机直接可以安装Windows、Linux等系统，其缺点是由于存在虚拟化的硬件层，所以其网络I/O和存储I/O的吞吐性能会受到影响；

1.2 虚拟化热点技术与目标

1.2.1 网络虚拟化

• 网络虚拟化是虚拟化技术体系中最难的的领域；

• 网络虚拟化就是将作为单独通信端点的物理机虚拟化为多个拥有独立IP的虚拟机，这些虚拟机与物理机一样，需要挂接到交换机上进行通信；

• 通常来讲，位于一个机房或数据中心的所有物理机属于同一个局域网，这些物理机上的所有虚拟机也属于同一个虚拟局域网，这个虚拟局域网被称为“大二层”交换网，即总体是一个扁平的二层网络，只有交换没有路由；

• 网络虚拟化中的两个热门领域：
  

  • SDN(Software Definied Network,软件定义的网络)：通过简单的软件操作完全控制网络的定义和管理，SDN将网络分为3部分：
    • 数据平面：负责数据传输，相当于网络底层的传输部分；
    • 控制平面：负责对网络设备下发管理指令，所有网络设备都由集中的一个Controller控制；
    • 网络管理接口：采用REST API方式定义接口，如使用编程方式定义路由策略、流量控制策略、映射NAT端口以及创建子网；
  • NFV（Network Function Virtualization网络功能虚拟化）：NFV将网元底层硬件交给X86，并且将底层网络功能交给网络虚拟化技术实现，从而使得网元中的上层电信应用可以统一在X86平台上提供，各个厂商的软件只要符合NFV标准规范即可，从而实现网元设备软硬件的彻底分离及标准化目标；未来各个电信软件开发商只需要提供具有标准化功能的网元软件，这些网元软件可安装在x86服务器或虚拟机上，因此电信业务很容易根据用户规模的变化而快速弹性伸缩；

  1.2.3 虚拟化的终极目标

• 虚拟化的终极目标是实现一个软件定义的纯虚拟化的数据中心；

1.3 容器技术

1.3.1 容器技术的历史

• 虚拟机与容器的区别：
  • 虚拟机需要一个完整的操作系统，而容器则是共享同一个宿主机的操作系统，容器仅包括相关的用户代码和所依赖的类库，因此容器被称为进程级的虚拟化；
  • 两者镜像尺寸大小不同，虚拟机镜像很大，而容器镜像很小；
  • 容器多部署在物理机上，如果部署在虚拟机上则需要经过2层的虚拟化，网络I/O和存储I/O会收到很大影响；

1.3.3 容器技术带来的变革

• Docker推动了微服务架构设计理念的落地，即将一个复杂应用系统拆分成一个个基于业务功能的完全独立的小程序，并且分布式部署在一个集群中，从而增加系统的稳定性和水平扩展能力，这就是微服务架构的核心思想和做法；
• 微服务架构相比传统单体应用的两个优势：
  • 在开发上一个很大的团队拆分成一个个小的专业团队，各自关注不同的有任务功能的开展，因此系统的开发迭代、更新和升级都非常敏捷；
  • 由于微服务架构本身是分布式的，因此很容易实现系统的高可用以及快速弹性扩容；
• 微服务将一个完整应用拆分成多个独立部署的微服务进程，会大大增加系统发布、测试和部署的工作量，Docker的出现使得我们可以把每个微服务打包成独立的镜像；
• Docker的出现也促进了DevOps的发展，即通过流水线串联并驱动整个应用的开发生命周期过程，包括源码编译、镜像打包、自动部署、自动化测试以及运维阶段的监控告警；

1.4 重新流行的PaaS

1.4.3 K8s和Mesos

• Kubernetes：目前PaaS领域影响最大、最活跃的开源项目，其最重要的概念是Service，即微服务架构理念，Service就是一个微服务，具备弹性扩容和自动故障恢复的能力；
  

  • Kubernetes的核心思想是“高度自动化”，即资源调度、程序部署、监控和故障恢复都是自动化的；
  • Kubernetes第一次将Service的高度提升到超过Machine的地位，不再需要关注部署细节，而只规划好系统是由多少种不同的Service组成，每种Service需要部署多少个容器实例(Pod)才能满足性能要求，其他的就交给K8s引擎；

• Mesos：Mesos主要负责底层资源的分配和管控，其设计理念分两层：下层是物理机器，组成资源池；上层是称为Framework的应用框架，每一个应用必须针对Mesos的Framework开发框架做定制化的开发后才能在Mesos上运行。为了支持Docker容器，Mesos后来提供了Marathon这个Framework。但Marathon并不是一个完整的微服务架构平台，缺乏负载均衡器、DNS等必需的组件。

第2章 微服务

2.2 微服务概要介绍

2.2.1 微服务架构原理

2.2.2 微服务的特征

• 特征1，组件化与多服务：传统应用通过库实现组件，微服务则是通过服务实现组件，从而将应用拆散为一系列的服务运行在不同的进程中，因此单一服务的局部变化仅需重新部署对应的服务进程；
• 特征2，围绕“业务功能”组织团队：
  
• 特征3，关注产品而不是项目，即“谁构建谁运行”：微服务架构倾向于让开发团队负责整个产品的全部生命周期，对软件在生产环境中的运行负全部责任；
  
• 特征4，“智能端点”与“傻瓜管道”：微服务将服务间的通信尽可能地轻量化，
  
• 特征5&特征6：去中心化地治理技术&去中心化地管理数据
  

2.3 微服务的高级进阶

2.3.2 微服务的进程间通信(IPC)

• 微服务架构中，每个服务实例都是一个进程，因此服务之间的交互必须通过进程间通信(IPC)实现；
• IPC通信类型：
  
  • 请求/响应：客户端向服务器发起请求等待响应，等待过程可能会造成线程阻塞；
  • 请求/异步响应：服务器端异步响应请求，客户端不会阻塞，而且被设计为默认响应，不回立刻到达；
  • 发布/订阅：客户端发布通知消息，被零个或多个感兴趣的服务消费；
  • 发布/异步响应：客户端发布请求消息，然后等待从感兴趣服务发回的响应；

2.3.5 微服务部署模式

• 单机单服务：方式简单，但存在监控困难问题；
• 多应用程序容器：
• 单主机单服务：
• 使用PaaS：PaaS平台自动配置机器，对系统进行弹性管理；

2.4 从单体架构转向微服务