1.1.微服务的演变
微服务和SOA（面向服务的架构service-oriented-architecture）有许多共同的特点：比如将重点放到服务上，以及如何把一个服务于另一个服务解耦。SOA通过公开大多基于简单对象访问协议（SOAP）的API，围绕整体应用程序集成展开进化，因此，中间件，比如企业服务总线（ESB），对SOA是非常重要的。
微服务复杂度更低，即使它可能使用消息总线，也仅把它用于消息传输并且不包含任何的逻辑；
微服务的理解：
微服务是自包含（例如在容器中）的轻量进程，它们通过HTTP进行通信，用相对较小的工作量与仪式来创建和部署，将只集中在有限领域的API提供给它们的使用者；
1.2.整体式架构概述
微服务并不是新事物，它已经流传了很多年。其最近的崛起归功于其声望和知名度的提高。在微服务变得流行之前，被用于开发本地部署和云应用的主要是整体式架构；
整体式架构允许分别开发不同的组件，如展示、应用程序逻辑、业务逻辑和数据访问对象（data access objects，DAO），然后你要么将它们一起打包在企业归档（enterprise archive，EAR）或者web归档（web archive，WAR）文件中，要么将它们存储在某个单独的目录层次结构中（例如：Rails。NodeJS，等等）；
许多著名的应用程序：例如Netflix，已经使用微服务进行开发，此外，eBay、亚马逊和Groupon也已经从整体式架构发展到微服务架构；
3.整体式架构的局限性与它的微服务解决方案的对比
比较三种不同的设计方案：
- 传统的整体性设计：所有的组件全部被捆绑在一起，并且相互紧密耦合；
在传统的整体式设计中，一切都被打包在同一个归档文件中，包括展示代码、应用程序逻辑和业务逻辑代码、DAO代码、与数据库文件或者其他数据源进行交互的有关代码；
展示<——>应用程序逻辑<——>业务逻辑<——>DAO<——>数据库
- 使用服务的整体式设计：所有的服务都是捆绑在一起。
在SOA产生之后，应用程序开始基于服务来开发，在这种模式中，每个组件都为其他组件或者外部实体提供服务。
客户API
展示<——> 订单API <——>数据库
分析API
- 微服务设计：各个服务都有自己的层，而DB被捆绑在一个单独的归档文件中。
所有的这些已经部署的服务都提供它们特定的API，甚至连UI也是单独部署，并使用微服务设计的。
【提示：在一些特殊的场景下，整体式的应用程序开发模式还是非常成功的，比如：对等电子商务web应用程序】
在这里，每个组件都是自主的，每个组件都可以独立开发、构建、测试和部署
甚至应用程序的UI组件也可以是一个使用微服务的客户端；
-------------------------------------------------------------------
API1：
展示
应用程序逻辑 <————>数据库
业务逻辑
DAO
-------------------------------------------------------------------
API2：
展示
应用程序逻辑 <————>数据库
业务逻辑
DAO
-------------------------------------------------------------------
API3：
展示
应用程序逻辑 <————>数据库
业务逻辑
DAO
-------------------------------------------------------------------
API网关提供接口，不同的客户端可以通过它访问个别的服务，并且需要解决以下的问题：
（1）让不同的服务给不同的客户端发送不同的响应；
例如：为移动客户端发送最小化的信息，向桌面应用发送详细信息，它们提供不同的细节；
（2）某个响应可能需要从两个或者多个服务中提取信息；
3.1一维的可扩展性
整体式应用程序所有的部件打包在一起，扩展的时候是庞大的，没有最佳利用资源；
微服务提供了只扩展那些需要扩展的服务的灵活性，它允许对资源的最有利用。
微服务开发使用REST式的web服务开发，REST的服务器是无状态的，使得在这个意义上，它是可扩展的，这意味着服务器之间没有太多的通信，从而它可以水平扩展。
3.2在出故障的时候回滚版本
因为整体式应用程序时打包在相同的归档文件或包含在单个目录中的，所以这阻碍了代码的模块化部署。
要解决这种问题，微服务给我们提供仅回滚那些出故障的功能的灵活性。
3.3采用新技术时的问题
微服务是基于组件开发和设计的，它给我们提供了在开发中使用无论是新技术还是旧技术的任何技术的灵活性。它并不限制你使用特定的技术，这给你提供了一种开发和工程活动的新范式。可以在任何时候使用Ruby on Rails或者NodeJS或任何其他技术；
基于微服务的应用程序代码并不打包成一个单独的归档文件中，也并不存储在单个目录中，每个微服务都有自己的文件。并且单独部署。一个新服务可以在隔离的环境黄总开发，微服务还拥有自己独立的进程，它服务于目标的时候不存在任何的冲突，如共享紧密耦合的资源，并且进程也保持独立；
还可以把微服务作为开方源码软件对外提供，所以它可由其他人使用。
3.4与敏捷实践的契合
持续集成（Continuous Integration ，CI）
持续部署（Continuous Deployment，CD）
3.5减轻开发工作量——可以做的更好
微服务的好处:组件之间松耦合的，连续发布周期，减少部署的风险，端点故障处理变得很容易；小即是美；
3.6微服务的构建管道
微服务也可以使用诸如Jenkins、TeamCity等流行的CI/CD工具建立和测试。它与整体式的应用程序的构建方式是非常相似的。在多个微服务中，每个微服务都被当做一个小型的应用程序；
例如：一旦把代码提交到存储库（SCM）中，CI/CD工具就触发构建过程；
清理代码；
代码编译；
执行单元测试；
建立应用程序归档文件；
在开发、QA等各种服务器上部署；
执行功能和继承测试；
创建映像容器；
任何其他步骤；
3.7使用诸如Docker的容器部署
由于微服务的设计，需要有一个提供灵活性、敏捷性和平滑度的环境，以支持持续集成和部署，以及发布。微服务部署需要速度、隔离管理和敏捷的生命周期；
软件容器用于封装它们的内容（产品、应用程序、依赖关系等等）；
以前，虚拟机（virtual machine，VM）被用于创建可以在需要的地方部署和软件映像。后来注入Docker的容器变得更受欢迎，因为它们同时与传统虚拟站系统和云环境兼容。
例如，在开发人员的笔记本电脑上部署超过两个VM不太现实。建立和启动一个VM机器通常是I/O密集型的操作，因此也相当缓慢；
【容器】
例如：Linux容器，提供轻量级运行时环境，该环境由虚拟机和核心功能和操作系统的隔离服务组成。这使得包装和执行微服务变得简单和顺利；
容器作为应用程序（微服务）在操作系统中运行。操作系统位于硬件的顶部，每个操作系统都可以有多个容器，使用一个容器运行应用程序；
容器能够利用操作系统的内核接口，如cname和命令空间，它们允许共享相同内核的多个容器可以完全互相隔离的同时运行。这具有无须为每个用途而完成一个OS安装的好处，从而可以消除开销，这也使得硬件得到最佳的利用；
【Docker】
Docker也利用了Linux内核的功能，例如cgroup和命令空间，以确保资源隔离，并把应用程序以及其依赖项打包在一起。这种依赖项的包装使应用程序能够跨不同Linux操作系统/发行版本正常运行，从而实现可移植性级别的支持。此外，这种可移植性允许开发人员用任何一种语言开发一个应用程序，然后轻松地把它从笔记本电脑部署到测试或者生产服务器上；
Docker原生的可以运行在Linux上，然而，使用VirtualBox和boot2docker，Docker也可以运行在Windows上和Mac OS上；
容器仅由应用程序以及其依赖项组成，依赖项包括基本的操作系统。
Docker容器中的所有程序都可以原生的在主机上执行，并直接使用主机内核。每个容器都具有自己的用户命名空间；
【Docker的架构】
Docker架构使用客户机-服务器架构。客户端与Docker守护进程之间往复通信。Docker守护程序承担构建、运行和发布你的Docker容器的繁重任务。Docker客户端和守护进程通过套接字或者通过基于REST的API进行通信。Docker寄存处是公共或者私有Docker映像存储库，你可以从中上传和下载映像；
Docker的主要组件是一个Docker映像和一个Docker容器；
【Docker映像】
Docker是一个只读的模板，例如映像可以包含安装了Apache web服务器和web应用程序的Ubuntu操作系统。Docker映像是Docker生成组件。映像用于创建Docker容器。
Docker提供简单的方式来生成新的映像或者更新现有的映像。
【Docker容器】
Docker容器是从某个Docker映像创建的。Docker的工作是使得容器只能看到它自己的进程，并有分层到主机文件系统和网络栈的自己的文件系统，它通过管道连接到主机网络栈。
Docker容器可以被运行，停止，启动、移动或者删除；
【部署】
使用Docker部署的微服务处理三个部分的问题：
（1）应用程序打包，如jar
（2）使用jar和依赖文件，包含Docker指令文件、Docker文件和命令docker build来构建Docker映像。这有助于反复创建映像；
（3）使用docker run命令从新构建的映像执行Docker容器