一、虚拟化与容器

1.1 虚拟机

1.2 容器

1.3 Docker

1.4 Docker代码示例

二、微服务

2.1 微服务的概念

2.2 微服务的特点

三、为什么使用微服务

3.1 微服务的优缺点

3.2 云原生的支持服务

云原生技术使组织能够在新式动态环境（如公有云、私有云和混合云）中构建和运行可缩放的应用程序。容器、服务网格、微服务、不可变基础结构和声明性 API 便是此方法的范例。

这些技术实现了可复原、可管理且可观察的松散耦合系统。它们与强大的自动化相结合，使工程师能够在尽量减少工作量的情况下，以可预测的方式频繁地进行具有重大影响力的更改。

一、虚拟化与容器

1.1 虚拟机

在容器技术之前，业界的“红人”是虚拟机。虚拟机技术的代表是VMware和OpenStack。在大学时，计算机操作系统的课程中经常学习使用VMware进行简单的编程学习。

很多人都用过虚拟机，就是在操作系统里安装一个软件，然后通过这个软件，再模拟一台甚至多台“子电脑”出来。在“子电脑”里，可以和正常电脑一样运行程序，例如微信、Word。“子电脑”和“子电脑”之间，相互隔离互不影响。

虚拟机虽然可以隔离出很多“子电脑”，但占用空间大，启动慢，虚拟机软件可能还要花钱（例如VMware）。而容器技术恰好没有这些缺点，它不需要虚拟出整个操作系统，只需要虚拟一个小规模的环境（类似“沙箱”），启动时间很快，几秒钟就能完成。而且，它对资源的利用率很高（一台主机可以同时运行几千个Docker容器）。此外它占的空间很小，虚拟机一般要几GB到几十GB的空间，而容器只需要MB级甚至KB级。虚拟机和以Docker为代表的容器都是虚拟化技术，不过容器属于轻量级的虚拟化。

1.2 容器

容器是云原生概念的重要组成部分，一种计算单元，容器比虚拟化技术更轻量化、更小开销的方式运行，作为应用的包装形式，容器赋予应用独立和便携的能力。随着Docker、Kubernetes技术的成熟，容器也成为了时下最火的开发理念。并非所有的应用都适合选择容器，开发者可以根据自己应用的特点和需求选择最适合的计算单元。如果应用是高性能、互信的，且处于同一个管理区域，那么用线程或者进程就可以满足；但如果你的应用是多租户的，并且和其他应用运行在同一个空间，那么你就需要考虑如何将这些应用安全地隔离开，使得数据不会被泄露或性能受到影响，容器也许就是一个不错的选择。

容器是「高度隔离的进程」：在一般进程的隔离基础上增加了新的隔离机制，这些隔离机制是使用Linux的内核提供的，它包括一些命名空间（Name Spaces）和CGroup。它保证了容器的网络是独立于其他容器网络的。每个容器自己看到的文件系统和其他容器的是不共享的，每个容器只能看到自己的进程ID，而进程编号也是连续的。

容器是「应用的闭包」：应用不是单一的可执行文件，稍微复杂的应用包括：代码、可执行文件、配置依赖、外部依赖（动态链接库）等。所以在应用发行包装的时候，需要考虑目标操作系统的版本、系统架构以及它所依赖的模块等因素。容器本身包含了应用所有的依赖，这使得它可以再任意的基础设施上运行，不会因为系统版本、架构的问题，而导致各种意外。

1.3 Docker

我们再来看看Docker，Docker本身并不是容器，它是创建容器的工具，是应用容器引擎。虽然Docker 把容器技术推向了巅峰，但容器技术却不是Docker发明的。

Docker本来是做PaaS的公司，原来叫做DotCloud，成立于2010年。但比起Pivotal、Red Hat等著名企业，DotCloud运营并不成功。眼看就要失败的时候，2013年DotCloud决定开源自己的容器项目Docker。但是短短几个月，Docker迅速崛起，吸引大量的开发者使用。随着Docker在开发者中越来越流行，2013年10月，DotCloud公司正式更名为Docker，2014年8月，Docker 宣布把PaaS业务出售，开始专心致志做Docker。

Docker一词意为码头工人，而它的logo则是一个托着许多集装箱的鲸鱼，非常形象：Docker是鲸鱼，而集装箱则是一个个的容器。在Docker的官网上，对于容器有一个一句话的解释“A standardized unit of software”，即“软件的一个标准化单元”。

Docker曾经有一句Slogan叫做“Build once，Run anywhere（搭建一次，随处可用）”。

1.4 Docker代码示例

容器启动后会回显 "Hello world"

FROM ubuntu:latest 
CMD echo "Hello world"

下面这段代码演示如何运行 Java 应用程序。从使用OpenJDK 8映像开始，将包含代码的.jar文件从系统复制到容器中，对此容器进行实例化后，它将运行该 Java 应用程序。

FROM openjdk:8
COPY /hello.jar /usr/src/hello.jar
CMD java -cp /usr/src/hello.jar
org.example.App

下面这段代码是一个更为真实的 Dockerfile 示例，从 CentOS 7 映像开始，进入更新操作系统并安装 Apache的步骤，最后复制应用程序的 Shell 脚本并授予它可执行权限。

实例化容器后，命令会运行该 Shell 脚本。

FROM centos:7

RUN yum -y update && yum -y install httpd

EXPOSE 80

ADD run-http.sh /run-http.sh
RUN chmod -v +x /run-http.sh

CMD ["/run-http.sh"]

二、微服务

2.1 微服务的概念

容器是微服务和云原生架构的最佳实现载体。微服务与容器几乎是完美的搭配。单体式架构（Monolithic）变成微服务架构（Microservices），相当于一个全能型变成N个专能型，每个专能型分配一个隔离的容器，赋予了最大程度的灵活。

服务器势必会走上虚拟化的道路，因为虚拟化有太多的优势，例如前文所说的低成本、高利用率、充分灵活、动态调度等等。而采用容器之后，只需要一台服务器，创建十几个容器，用不同的容器，来分别运行不同用途的服务程序。这些容器，随时可以创建，也可以随时销毁。还能够在不停机的情况下，随意变大，随意变小，随意变强，随意变弱，在性能和功耗之间动态平衡。所以容器化是云计算的终极形态。

2.2 微服务的特点

轻便。微服务架构通过对特定业务领域的分析与建模，将复杂的应用分解成小而专一、耦合度低并且高度自治的一组服务，每个服务都是很小的应用。

耦合度
单一。对于每个服务而言，我们希望它处理的业务逻辑能够单一，在服务架构层面遵循单一职责原则。也就是说，微服务架构中的每个服务，都是具有业务逻辑的，符合高内聚、低耦合原则以及单一职责原则的单元，不同的服务通过「管道」的方式灵活组合，从而构建出庞大的系统。
轻量级通信。服务之间应通过轻量级的通信机制，实现彼此之间的互通互联，互相协作。所谓轻量级通信机制，通常指语言无关、平台无关的交互方式。
在微服务架构中，每个服务都是一个独立的业务单元，当对某个服务进行改变时，对其他的服务不会产生影响。换句话说，服务和服务之间是独立的。对于每个服务，都有独立的代码库。当对当前服务的代码进行修改后，并不会影响其他服务。

微服务的独立性演示
在微服务架构中，应用程序由多个服务组成，每个服务都是一个具有高度自治的独立业务实体。通常情况下，每个服务都能运行在一个独立的操作系统进程中，这就意味着不同的服务能非常容易的被部署到不同的主机上。作为运行微服务的环境，我们希望它能够保持高度自治性和隔离型。

三、为什么使用微服务

微服务提供敏捷性。

每个微服务都有自治生命周期，可以独立发展并频繁部署。不必等待每季度发布一次才能部署新功能或更新。可以更新实时应用程序的小区域，降低中断整个系统的风险。无需完全重新部署应用程序即可进行更新。
每个微服务都可以独立缩放。你可以仅横向扩展需要更多处理能力才能满足所需性能级别和服务级别协议的服务，而不是将整个应用程序作为单个单元进行缩放。精细缩放可使你更好地控制系统，并且有助于降低总体成本，因为是缩放部分系统（而不是所有内容）。

3.1 微服务的优缺点

对比点	微服务架构	单体架构	结论
上手难度	API接口调用	数据库共享或者本地程序调用	单体架构胜
开发效率	早期设计和沟通的工作量加大，随着项目规模和时间的推移，效率变化不大	早期工作量小，随着项目规模和时间的推移，效率大幅度下降	对于简单项目单体架构胜，对于复杂项目微服务架构胜
系统设计（高内聚低耦合）	每个业务单独包装成一个微服务，数据和代码都从物理上隔离开来，实现高内聚低耦合相对容易	以包的形式对代码进行模块划分，控制得当即可实现高内聚。但最终都是在数据层面将整个系统耦合在一起	微服务架构胜
系统设计（扩展性）	独立开发新模块，通过 API 与现有模块交互	在现有系统上修改，与现存业务逻辑高度耦合	微服务架构胜
需求变更响应速度	各个微服务组件独立变更，容易实施敏捷开发方法	需要了解整个系统才可以正确修改，容易导致不相关模块的意外失败	微服务架构胜
系统升级效率	各个微服务组件独立升级，上手和开发效率高，影响面小	需要了解整个系统才可以正确修改，容易导致不相关模块的意外失败	微服务架构胜
运维效率	大系统被拆分为多个小系统，部署和运维难度加大，但可以利用 DevOps 等方式将运维工作自动化	简单直接	单体架构胜
代码复用性	微服务组件可以在新项目中直接复用，包括前端页面	一般以共享库的形式复用后台代码	微服务架构胜
硬件需求	按需为不同业务模块伸缩资源节点，一个系统需部署多个微服务，需要启动多个运行容器	整个系统只需要一个运行容器，为整个系统分配资源	对于简单项目单体架构胜，对于复杂项目微服务架构胜
项目成本	项目早期和后期，成本变化曲线平缓	项目早期成本低，后期成本大	对于简单系统单体架构胜，对于复杂系统微服务架构胜
非功能需求	为单独的微服务按需调优，甚至更换实现方式和程序语言	为整个系统调优，牵一发而动全身	微服务架构胜
职责、成就感	拥有明确的职责划分，主人翁意识和成就感加强，容易形成自组织型团队	职责不明确，容易产生扯皮行为	微服务架构胜
风险	大系统被拆分为小系统，风险可被控制在小系统内，但也引入了各小系统之间的交互风险	系统是一个整体，一荣俱荣，一损俱损	微服务架构胜

对于简单项目来说，单体架构 5 胜 8 败，优势主要体现在开发效率、上手难度、运维效率、硬件需求、项目成本；对于复杂项目来说，微服务架构 11 胜 2败，优势主要体现在硬件需求、项目成本、开发效率、系统设计时的高内聚低耦合和可扩展性、需求变更响应速度、系统升级效率、代码复用性、非功能需求、职责/成就感、风险的可控性。