微服务

单体应用

  早些年，各大互联网公司的应用技术栈大致可分为 LAMP（Linux + Apache + MySQL + PHP）和 MVC（Spring + iBatis/Hibernate + Tomcat）两大流派。无论是 LAMP 还是 MVC，都是为单体应用架构设计的，其优点是学习成本低，开发上手快，测试、部署、运维也比较方便，甚至一个人就可以完成一个网站的开发与部署。
  以 MVC 架构为例，业务通常是通过部署一个 WAR 包到 Tomcat 中，然后启动 Tomcat，监听某个端口即可对外提供服务。早期在业务规模不大、开发团队人员规模较小的时候，采用单体应用架构，团队的开发和运维成本都可控。
  然而随着业务规模的不断扩大，团队开发人员的不断扩张，单体应用架构就会开始出现问题。我估计经历过业务和团队快速增长的同学都会对此深有感触。从我的角度来看，大概会有以下几个方面的问题。
  想要解决上面这些问题，服务化的思想也就应运而生。

什么是服务化

  用通俗的话来讲，服务化就是把传统的单机应用中通过 JAR 包依赖产生的本地方法调用，改造成通过 RPC 接口产生的远程方法调用。一般在编写业务代码时，对于一些通用的业务逻辑，我会尽力把它抽象并独立成为专门的模块，因为这对于代码复用和业务理解都大有裨益。
  以微博系统为例，微博既包含了内容模块，也包含了消息模块和用户模块等。其中消息模块依赖内容模块，消息模块和内容模块又都依赖用户模块。当这三个模块的代码耦合在一起，应用启动时，需要同时去加载每个模块的代码并连接对应的资源。一旦任何模块的代码出现 bug，或者依赖的资源出现问题，整个单体应用都会受到影响。
  为此，首先可以把用户模块从单体应用中拆分出来，独立成一个服务部署，以 RPC 接口的形式对外提供服务。微博和消息模块调用用户接口，就从进程内的调用变成远程 RPC 调用。这样，用户模块就可以独立开发、测试、上线和运维，可以交由专门的团队来做，与主模块不耦合。进一步的可以再把消息模块也拆分出来作为独立的模块，交由专门的团队来开发和维护。
  可见通过服务化，可以解决单体应用膨胀、团队开发耦合度高、协作效率低下的问题。

微服务

什么是微服务

  微服务是一种开发软件的架构和组织方法，其中软件由通过明确定义的 API 进行通信的小型独立服务组成。这些服务由各个小型独立团队负责。微服务架构使应用程序更易于扩展和更快地开发，从而加速创新并缩短新功能的上市时间。

整体式架构与微服务架构

  通过整体式架构，所有进程紧密耦合，并可作为单项服务运行。这意味着，如果应用程序的一个进程遇到需求峰值，则必须扩展整个架构。随着代码库的增长，添加或改进整体式应用程序的功能变得更加复杂。这种复杂性限制了试验的可行性，并使实施新概念变得困难。整体式架构增加了应用程序可用性的风险，因为许多依赖且紧密耦合的进程会扩大单个进程故障的影响。
  使用微服务架构，将应用程序构建为独立的组件，并将每个应用程序进程作为一项服务运行。这些服务使用轻量级 API 通过明确定义的接口进行通信。这些服务是围绕业务功能构建的，每项服务执行一项功能。由于它们是独立运行的，因此可以针对各项服务进行更新、部署和扩展，以满足对应用程序特定功能的需求。　　　

微服务的特性

自主性
  可以对微服务架构中的每个组件服务进行开发、部署、运营和扩展，而不影响其他服务的功能。这些服务不需要与其他服务共享任何代码或实施。各个组件之间的任何通信都是通过明确定义的 API 进行的。
专用性
  每项服务都是针对一组功能而设计的，并专注于解决特定的问题。如果开发人员逐渐将更多代码增加到一项服务中并且这项服务变得复杂，那么可以将其拆分成多项更小的服务。

微服务的优势

敏捷性
  微服务促进若干小型独立团队形成一个组织，这些团队负责自己的服务。各团队在小型且易于理解的环境中行事，并且可以更独立、更快速地工作。这缩短了开发周期时间。您可以从组织的总吞吐量中显著获益。
灵活扩展
  通过微服务，您可以独立扩展各项服务以满足其支持的应用程序功能的需求。这使团队能够适当调整基础设施需求，准确衡量功能成本，并在服务需求激增时保持可用性。
轻松部署
  微服务支持持续集成和持续交付，可以轻松尝试新想法，并可以在无法正常运行时回滚。由于故障成本较低，因此可以大胆试验，更轻松地更新代码，并缩短新功能的上市时间。
技术自由
  微服务架构不遵循“一刀切”的方法。团队可以自由选择最佳工具来解决他们的具体问题。因此，构建微服务的团队可以为每项作业选择最佳工具。
可重复使用的代码
  将软件划分为小型且明确定义的模块，让团队可以将功能用于多种目的。专为某项功能编写的服务可以用作另一项功能的构建块。这样应用程序就可以自行引导，因为开发人员可以创建新功能，而无需从头开始编写代码。
弹性
  服务独立性增加了应用程序应对故障的弹性。在整体式架构中，如果一个组件出现故障，可能导致整个应用程序无法运行。通过微服务，应用程序可以通过降低功能而不导致整个应用程序崩溃来处理总体服务故障。

微服务架构

从微服务架构图得出如下结论：
1.微服务把每一个职责单一的功能放在一个独立的服务中 。
2.每个服务有多个实例在运行，每个实例可以运行在容器化平台内，达到平滑伸缩的效 果，单个微服务启动较快。
3.每个服务应该有自己的运营平台，以及独享的运营人员，这包括技术运维和业务运营人 员：每个服务都高度自治，内部的变化对外透明。
4.易于开发和维护：一个微服务只会关注一个特定的业务功能，所以业务清晰、代码量较少。开发和维护单个微服务相对简单。
5.局部修改容易部署：单体应用只要有修改，就得重新部署整个应用。微服务解决了这样的问题。一般来说，对某个微服务进行修改，只需要重新部署这个服务即可。
6.技术栈不受限制：在微服务架构中，可以结合项目业务及团队的特点，合理的选择技术栈。

MVC、RPC、SOA、微服务架构之间的区别

1.MVC架构
  其实从本质上讲，MVC应该算作是一种设计模式，算作是单体架构的一种。比较有代表性的技术：Struts2,、SpringMVC、Spring、Mybatis、Hibernate等等。
2.RPC架构
  RPC（Remote Procedure Call），远程过程调用，它是一种通过网络远程计算机请求，而不需要了解底层网络技术的协议。代表技术，Thrift、Hessian等
SOA架构
  SOA（Service oriented Architecture）面向服务架构
  ESB（Enterparise Servce Bus）：企业总线服务，服务中介。主要提供了服务于服务之间的交互。
  ESB包含的功能如：负载均衡，流量控制，加密处理，服务监控，异常处理，监控警告等等。
  代表性的技术：Mule、WSO2等
微服务架构
  微服务就是一个轻量级的服务治理方案，代表技术：SpringCloud，dubbo等等

微服务应用设计原则

AKF扩展立方体

  立方体，就是一个三维的空间，我们要的是 “可扩展”，那么没有比三维的空间更能表达扩展性的了。
  AKF立方体是一种理论指导，它可以帮助我们在各个方向上做扩展。X、Y、Z三个方向都给我们指明了道路，让我们在执行的时候可以在不同的方向上做一个参考，参照这一理论来确认我们所做的扩展动作是否符合这一理论。

X轴扩展
  X轴扩展主要是面向单体应用程序的扩展，单体应用程序的多个相同实例通过负载均衡器去分配请求，主要用于提升系统吞吐量和可用性，常见应用：集群
Z轴扩展
  Z轴扩展也需要实现单体应用的多个实例，但不同的是实例之间并不是相同的，每个实例只负责数据集的一个子集，路由网关通过请求的属性将请求路由到特定的实例，主要用于提升系统的吞吐量，常见应用：分库分表
Y轴扩展
  X轴扩展和Z轴扩展都可以提升系统的吞吐量，但并没有解决日益增长的开发问题和应用复杂性的问题，Y轴扩展通过拆分功能解决此类问题，主要用于降低系统耦合性，常见应用：微服务

前端后端分离原则

  什么叫做前端后端分离呢！前端和后端在一般的概念上本来就是分离的。这个就要从jsp技术讲起，分工精细才能把一个蛋糕做大，多个领域工程师最好在不需要接触其他领域知识的情况下合作，才可能是效率越来越高。维护也会变的越来越简单。Jsp的模板技术，融合了HTML和Java的代码，使得传统MVC开发中的前端和后端在这个技术中如胶似漆，前端的工作就是做好页面，后端转成模板，发现问题在去找前端解决，前端又看不懂java代码，前后端分离的目的就是将这尴尬的局面打破。
  前后端分离的原则，简单的来讲就是前端和后端代码的分离，我们推荐的模式是最好采用物理分离的办法部署，进一步促使更加彻底的分离，如果继续直接使用服务器端模板技术，如jsp把java，js，html，css都堆到一个页面中，稍微有点复杂一点的页面就没有办法维护了。

无状态服务

  对于无状态服务，首先介绍什么是状态：如果一个数据需要被多个服务共享，才能完成一笔交易，那么和这个数据被称为状态。进而依赖这个状态的数据的服务被称为是状态服务，反之称为无状态服务
  那么这个无状态服务原则并不是说在微服务里就不允许存在状态，表达的真实意思是要把所有状态的业务服务改变为无状态的计算类服务，那么状态数据也就是相应的迁移到对应的有状态数据服务中。
  场景说明：例如我们以前在本地内存中建立的数据缓存、Session缓存，到现在的微服务架构中，就应该把这些数据迁移到分布式缓存中存储，让业务服务变成一个无状态的计算节点。迁移后，就可以做到按需动态伸缩，微服务应用在运行时动态增删节点，就不需要考虑缓存数据如何同步的问题。

微服务架构好处

  微服务架构模式有很多好处。首先，通过分解巨大单体式应用为多个服务方法解决了复杂性问题。在功能不变的情况下，应用被分解为多个可管理的分支 或服务。每个服务都有一个用RPC-或者消息驱动API定义清楚的边界。微服务架构模式给采用单体式编码方式很难实现的功能提供了模块化的解决方案，由 此，单个服务很容易开发、理解和维护。
  第二，这种架构使得每个服务都可以有专门开发团队来开发。开发者可以自由选择开发技术，提供API服务。当然，许多公司试图避免混乱，只提供某 些技术选择。然后，这种自由意味着开发者不需要被迫使用某项目开始时采用的过时技术，他们可以选择现在的技术。甚至于，因为服务都是相对简单，即使用现在 技术重写以前代码也不是很困难的事情。
  第三，微服务架构模式是每个微服务独立的部署。开发者不再需要协调其它服务部署对本服务的影响。这种改变可以加快部署速度。UI团队可以采用AB测试，快速的部署变化。微服务架构模式使得持续化部署成为可能。
  最后，微服务架构模式使得每个服务独立扩展。你可以根据每个服务的规模来部署满足需求的规模。甚至于，你可以使用更适合于服务资源需求的硬件。 比如，你可以在EC2 Compute Optimized instances上部署CPU敏感的服务，而在EC2 memory-optimized instances上部署内存数据库。

微服务相关技术Docker

Docker是什么

  Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口（类似 iPhone 的 app）。几乎没有性能开销,可以很容易地在机器和数据中心中运行。最重要的是,他们不依赖于任何语言、框架包括系统。

为什么要用docker

1.更高效的利用系统资源
  由于容器不需要进行硬件虚拟以及运行完整操作系统等额外开销，Docker 对系统资源的利用率更高。无论是应用执行速度、内存损耗或者文件存储速度，都要比传统虚拟机技术更高效。因此，相比虚拟机技术，一个相同配置的主机，往往可以运行更多数量的应用
2.更快速的启动时间
  传统的虚拟机技术启动应用服务往往需要数分钟，而 Docker 容器应用，由于直接运行于宿主内核，无需启动完整的操作系统，因此可以做到秒级、甚至毫秒级的启动时间。大大的节约了开发、测试、部署的时间。
3.一致的运行环境
  开发过程中一个常见的问题是环境一致性问题。由于开发环境、测试环境、生产环境不一致，导致有些 bug 并未在开发过程中被发现。而 Docker 的镜像提供了除内核外完整的运行时环境，确保了应用运行环境一致性，从而不会再出现 「这段代码在我机器上没问题啊」 这类问题。
4.持续交付和部署
  对开发和运维（DevOps）人员来说，最希望的就是一次创建或配置，可以在任意地方正常运行。
  使用 Docker 可以通过定制应用镜像来实现持续集成、持续交付、部署。开发人员可以通过 Dockerfile 来进行镜像构建，并结合 持续集成(Continuous Integration) 系统进行集成测试，而运维人员则可以直接在生产环境中快速部署该镜像，甚至结合 持续部署(Continuous Delivery/Deployment) 系统进行自动部署。
  而且使用 Dockerfile 使镜像构建透明化，不仅仅开发团队可以理解应用运行环境，也方便运维团队理解应用运行所需条件，帮助更好的生产环境中部署该镜像。
5.更轻松的迁移
  由于 Docker 确保了执行环境的一致性，使得应用的迁移更加容易。Docker 可以在很多平台上运行，无论是物理机、虚拟机、公有云、私有云，甚至是笔记本，其运行结果是一致的。因此用户可以很轻易的将在一个平台上运行的应用，迁移到另一个平台上，而不用担心运行环境的变化导致应用无法正常运行的情况。
6.更轻松的维护和扩展
  Docker 使用的分层存储以及镜像的技术，使得应用重复部分的复用更为容易，也使得应用的维护更新更加简单，基于基础镜像进一步扩展镜像也变得非常简单。此外，Docker 团队同各个开源项目团队一起维护了一大批高质量的 官方镜像，既可以直接在生产环境使用，又可以作为基础进一步定制，大大的降低了应用服务的镜像制作成本。

基本概念

镜像
  我们都知道，操作系统分为内核和用户空间。对于 Linux 而言，内核启动后，会挂载 root 文件系统为其提供用户空间支持。而 Docker 镜像（Image），就相当于是一个 root 文件系统。比如官方镜像 ubuntu:18.04 就包含了完整的一套 Ubuntu 18.04 最小系统的 root 文件系统。
  Docker 镜像是一个特殊的文件系统，除了提供容器运行时所需的程序、库、资源、配置等文件外，还包含了一些为运行时准备的一些配置参数（如匿名卷、环境变量、用户等）。镜像不包含任何动态数据，其内容在构建之后也不会被改变。
容器
  镜像（Image）和容器（Container）的关系，就像是面向对象程序设计中的 类 和 实例 一样，镜像是静态的定义，容器是镜像运行时的实体。容器可以被创建、启动、停止、删除、暂停等。
  前面讲过镜像使用的是分层存储，容器也是如此。每一个容器运行时，是以镜像为基础层，在其上创建一个当前容器的存储层，我们可以称这个为容器运行时读写而准备的存储层为容器存储层。
  按照 Docker 最佳实践的要求，容器不应该向其存储层内写入任何数据，容器存储层要保持无状态化。所有的文件写入操作，都应该使用 数据卷（Volume）、或者绑定宿主目录，在这些位置的读写会跳过容器存储层，直接对宿主（或网络存储）发生读写，其性能和稳定性更高。
  数据卷的生存周期独立于容器，容器消亡，数据卷不会消亡。因此，使用数据卷后，容器删除或者重新运行之后，数据却不会丢失。
仓库
  镜像构建完成后，可以很容易的在当前宿主机上运行，但是，如果需要在其它服务器上使用这个镜像，我们就需要一个集中的存储、分发镜像的服务，Docker Registry 就是这样的服务。
  一个 Docker Registry 中可以包含多个仓库（Repository）；每个仓库可以包含多个标签（Tag）；每个标签对应一个镜像。
  通常，一个仓库会包含同一个软件不同版本的镜像，而标签就常用于对应该软件的各个版本。我们可以通过 <仓库名>:<标签> 的格式来指定具体是这个软件哪个版本的镜像。如果不给出标签，将以 latest 作为默认标签。