目录

一、虚拟化与容器

  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:7RUN yum -y update && yum -y install httpdEXPOSE 80ADD run-http.sh /run-http.sh
RUN chmod -v +x /run-http.shCMD ["/run-http.sh"]

二、微服务

  2.1  微服务的概念

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

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

  2.2  微服务的特点

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

   

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

   

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

三、为什么使用微服务

        微服务提供敏捷性。

• 每个微服务都有自治生命周期，可以独立发展并频繁部署。 不必等待每季度发布一次才能部署新功能或更新。 可以更新实时应用程序的小区域，降低中断整个系统的风险。 无需完全重新部署应用程序即可进行更新。

• 每个微服务都可以独立缩放。 你可以仅横向扩展需要更多处理能力才能满足所需性能级别和服务级别协议的服务，而不是将整个应用程序作为单个单元进行缩放。 精细缩放可使你更好地控制系统，并且有助于降低总体成本，因为是缩放部分系统（而不是所有内容）。

    3.1  微服务的优缺点

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

  3.2  云原生的支持服务

         在云原生搭建的过程中，你可以自己承载自己的服务，缺点是后续的维护更新都需要自己来搞定。可以在一定程度上锻炼自己的动手能力，美滴很。

        现在，很多的云服务提供商提供了许多的云产品供开发者选择。云提供商大规模地运营资源，并负责性能、安全性和维护。与自己维护相比较，云服务稍微有点费钱。但是会节省大量的体力。