上诉架构图采用了分层架构，按照调用顺序，从上到下为表示层、业务层、数据访问（DAO）层、DB层。表示层负责用户体验，业务层负责业务逻辑，包括电影、订单和用户三个模块。数据访问层负责DB层的数据存取，实现增删改查的功能。业务层定义了应用的业务逻辑，是整个应用的核心。在单体应用中，所有这些模块都集成在一起，这样的系统架构就叫做单体应用架构，或称为巨石型应用架构。单体应用是最早的应用形态，开发和部署都很简单。在中小型项目中使用单体应用架构，能体现出其优势，且单体应用的整体性能主要依赖于硬件资源和逻辑代码实现，应用架构自身不需要特别关注。单体应用的集成非常简洁，IDE集成开发环境和其他工具都擅长开发一个简单应用；单体应用易于调试，由于一个应用包含所有功能，所以只需要简单运行此应用即可进行开发测试，单体应用易于部署，只需要把应用打包，拷贝到服务器端即可；通过负载均衡器，运行多个服务实例，单体应用可以轻松实现应用扩展。
随着应用项目变得复杂、开发团队不断扩张之后，单体应用的不足和弊端将会变得很明显
单体应用的不足：
可靠性：每个bug都可能影响到整个应用的可靠性。因为所有模块都运行在一个进程中，任何一个模块中的一个bug，比如内存泄漏，都可能拖垮整个进程。
复杂性高：单体应用巨大的代码库可能会令人望而生畏，特别是对团队新成员来说。应用难以理解和迭代，进而导致开发速度减慢。由于没有清晰的模块边界，模块化会逐渐消失。
持续部署困难：巨大的单体应用本身就是频繁部署的一大障碍。\
为了更新一个组件，必须重新部署单个应用。这回中断那些可能与更改无关的后台任务，同时可能引发其他问题。另外，未被更新的组件有可能无法正常启动。重新部署会增加风险，进而阻碍频繁更新。
扩展能力受限：单体架构只能进行一维扩展。一方面，它可以通过运行多个应用服务实例来增加业务容量，实现扩展。但另一方面，不同的应用组件有不同的资源需求：有的是CPU密集型的，有的是内存密集型的。单体架构无法单独扩展每个组件。
阻碍技术创新：单体应用往往使用统一的技术平台或方案解决所有问题，团队的每个成员都必须使用相同的开发语言和架构，想要引入新的框架或技术平台非常困难。单体架构迫使团队长期使用在开发初期选定的技术栈，比如选择了JVM语言，此时以非JVM语言编写的组件就无法在该单体架构的应用中使用
SOA架构：
面向服务的架构，SOA的核心主体是服务，其目标是通过服务的流程化来实现业务的灵活性。服务就像一堆“元器件”，这些元器件通过封装形成标准服务，它们有相同的接口和语义表达规则。但服务要组装成一个流程和应用，还需要有效的“管理”，包括如何注册服务、如何发现服务、如何包装服务的安全性和可靠性，这些就是SOA治理。SOA治理是将SOA的一堆元器件进行有效组装。这是形成一个“产品”的关键。否则那些永远是一堆元器件，而无法形成一个有机整体。
完整的SOA架构由五大部分组成：基础设施服务、企业服务总线、关键服务组件、开发工具、管理工具等。
基础设施：为整个SOA组件和框架提供一个可靠的运行环境，以及服务组件容器，它的核心组件是应用服务器等基础软件支撑设施，提供运行期完整、可靠的软件支撑
企业服务总线：提供可靠消息传输、服务接入、协议转换、数据格式转换、基于内容的路由等功能，屏蔽了服务的物理位置、协议和数据格式。
关键服务组件：SOA在各种业务服务组件的分类。
开发工具和管理工具：提供完善的、可视化的服务开发和流程编排工具，包括服务的设计、开发、配置、部署、监控、重构等完整的SOA项目开发生命周期。具体来说，就是在分布式的环境中，将各种功能都以服务的形式提供给最终用户或则其他服务。企业级应用的开发多采用面向服务的体系架构来满足灵活多变、可重用性的需求。它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口采用中立的方式进行定义，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。
SOA是在企业计算领域中提出的，目的是要将紧耦合的系统，划分为面向业务的、粗粒度、松耦合、无状态的服务。服务发布出来供其他服务调用，一组互相依赖的服务就构成了SOA架构的系统。基于这些基础的服务，可以将业务过程用类似BPEL(业务流程执行语言)流程的方式编排起来，BPEL反映的是业务处理的过程，这些过程对于业务人员更为直观。企业还需要一些服务治理的工具，比如服务注册库、监控管理等。在企业计算领域，如果不是交易系统的话，并发量都不是很大，所以大多数情况下，一台服务器就可以容纳许多的服务，这些服务采用统一的基础设施，可能都运行在一个应用服务器的进程中，虽然说是SOA架构，但还可能是单一的系统。
微服务架构：
微服务架构是一种使用一系列粒度较小的服务来开发单个应用的方式；每个服务运行在自己的进程中；服务间采用轻量级的方式进行通信（通常是HTTP API）；这些服务是基于业务逻辑和范围，通过自动化部署的机制来独立部署的，并且服务的集中管理应该是最低限度的，即每个服务可以采用不同的编程语言编写。使用不同的数据存储技术。
微服务架构已经不是一个新概念了，很多业界前沿互联网公司的实践表明，微服务是一种渐进式的演进架构，是企业应对业务复杂性，支持大规模持续创新行之有效的架构手段。
* Eureka包含两个组件：Eureka Server和Eureka Client * * Eureka Server提供服务发现的能力，各个微服务启动时，会向Eureka Server注册自己的信息(例如IP、端口、微服务名称等)， * Eureka Server会存储这些信息 * * Eureka Client 是一个Java客户端，用于简化与Eureka Server的交互 * * 微服务启动后，会周期性（默认30）秒地向Eureka Server发送心跳以续约自己的“租期” * * 如果Eureka Server在一定时间内没有接收到某个微服务实例的心跳，Eureka Server将会注销该实例（默认90秒） * * 默认情况下，Eureka Server同时也是Eureka Client。多个Eureka Server实例，互相之间通过增量复制的方式，来实现服务注册表中数据的同步。 * Eureka Server默认保证在90秒内，Eureka Server集群内的所有实例中的数据达到一致（从这个架构来看，Eureka Server所有实例所处的角色都是对等的，没有类似Zookeeper、Consul、Etcd等软件的选举过程，也不存在主从，所有的节点都是主节点。Eureka官方将Eureka Server集群中的所有实例称为“对等体（peer）”） * * Eureka Client会缓存服务注册表中的信息。这种方式有一定的优势——首先，微服务无需每次请求都查询Eureka Server，从而降低了Eureka Server的压力；其次，即使Eureka Server所有节点都宕掉，服务消费者依然可以使用缓存中的信息找到服务提供者并完成调用。 * * Eureka通过心跳检查、客户端缓存等机制，提高了系统的灵活性、可伸缩性和可用性 * * Eureka Server本身也集成了Eureka Client，彼此通过Eureka Client同步数据给其他实例又或者从其他实例同步数据。 * * 服务注册与发现，服务提供方将己方调用地址注册到服务注册中心，让服务调用方能够方便地找到自己；服务调用方从服务注册中心找到自己需要调用的服务的地址。 * * 负载均衡：服务提供方一般以多实例的形式提供服务，负载均衡功能能够让服务调用方连接到合适的服务节点。并且，服务节点选择的过程对服务调用方来说是透明的。 * * 服务网关：服务网关是服务调用的唯一入口，可以在这个组件中实现用户鉴权、动态路由、灰度发布、A/B测试、负载限流等功能。 * * 配置中心：将本地化的配置信息注册到配置中心，实现程序包在开发、测试、生产环境中无差别性，方便程序包的迁移。 * * 集成框架：微服务组件都以职责单一的程序包对外提供服务，集成框架以配置的形式将所有微服务组件（特别是管理端组件）集成到统一的界面框架下，让用户能够在统一的界面中使用系统。 * * 调用链监控：记录完成一次请求的先后衔接和调用关系，并将这种串行或并行的调用关系展示出来。在系统出错时，在系统出错时可以方便地找到出错点。 * * 支撑平台：系统微服务化后，各个业务模块经过拆分变得更加细化，系统的部署、运维、监控等都比单体应用架构更加复杂，这就需要将大部分的工作自动化。现在，Docker等工具可以给微服务架构的部署带来较多的便利，例如持续集成、蓝绿发布、健康检查、性能健康等等。如果没有合适的支撑平台或工具，微服务架构就无法发挥它最大的功效 * * 微服务架构可以解决单体应用扩大之后出现的大部分问题。首先，通过将巨大单体应用分解为多个服务的方法解决了复杂性问题。在功能不变的情况下，应用分解为多个可管理的模块或服务。每个服务都有一个用RPC或则消息驱动API定义清楚的边界。微服务架构模式为采用单体式编码方式很难实现的功能提供了模块化的解决方案。由此，单个服务变得很容易开发、理解和维护。 * * 其次，微服务架构模式使得团队并行开发得以推进，每个服务都可以由专门开发团队来开发。不同团队的开发者可以自由选择开发技术，提供API服务。这种自由意味着开发者不需要被迫使用之前采用的过时技术，他们可以选择最新的技术。 *
常见的微服务架构方案有四种，分别是ZeroC IceGrid、基于消息队列、Docker Swarm和Spring Cloud。
1.ZeroC IceGrid
ZeroC IceGrid 是基于RPC框架Ice发展而来的一种微服务架构，ICe不仅仅是一个RPC框架，它还为网络应用程序提供了一些补充服务。Ice是一个全面的RPC框架，支持C++、C#、Java、Javascript、Python等语言。IceGrid具有定位、部署和管理Ice服务器的功能，具有良好的性能与分布式能力。
Ice的DNS。DNS用于将域名信息映射到具体的IP地址，通过域名得到该域名对应的IP地址的过程叫做域名解析。IceGrid为Ice提供了类似的服务:它允许Ice客户端通过简单的名称来查找Ice对象。Ice客户端可以通过提供此对象的完整寻址信息来访问服务器中的Ice对象，例如chatRoom1：ssl-h demo.zeroc.com-p 10000。这样的硬编码虽然很简单，但缺乏灵活性。因为需要Ice服务器（本例中端口为10000）选择一个固定的端口号，因此将Ice服务器移到不同的主机上需要更新其客户端。
IceGrid提供了对这种寻址信息使用符号名称的选项，例如chatRoom1@chatRoomHost。当Ice客户端尝试访问chatRoomHost中的对象时，它会要求IceGrid提供与此符号名称关联的实际地址。例如，IceGrid返回-h demo.zeroc.com-p 65431，客户端就可以直接并透明地连接到服务器。IceGrid架构如图所示
服务器部署。若直接通过IP地址+端口号的方式，当Ice客户端尝试连接到未运行的服务器时，连接将会失败。通过符号或间接寻址，IceGrid有机会检查目标服务器是否正在运行，并在服务器未运行时启动或重新启动服务器。可以配置IceGrid以各种方式启动服务器：手动(通过管理命令)、按需(无论何时请求服务器)和IceGrid始终保持服务器运行。
服务器的复制。IceGrid允许部署同一服务器的多个副本，并可以配置IceGrid将符号名称解析到此服务器副本的策略。可以在所有副本中对客户端进行负载平衡，或者使用主备配置，客户端只要保持可用状态，就使用主备配置。
管理和监控。IceGrid的管理工具可以完全控制已部署的应用程序。诸如启动服务器或修改配置设置等活动只需单击鼠标即可。图1-3为IceGrid管理工具的界面。
IceGrid当前最新的版本为3.7.1，在3.6版本之后增加了容器化的运行方式。总的来说，IceGrid作为微服务架构早期的实践方案，其流行时间并不是很久，当前国内选用这种微服务架构方案的公司非常少。
2.基于消息队列
在微服务架构的定义中讲到，各个微服务之间使用“轻量级”的通信机制。所谓轻量级，是指通信协议与语言无关、与平台无关。微服务之间的通信方式有两种：同步和异步。同步方式有RPC，REST等；除了标准的基于同步通信方式的微服务架构外，还有基于消息队列异步方式通信的微服务架构.
在基于消息队列的微服务架构方式中，微服务之间采用发布消息与监听消息的方式来实现服务之间的交互。图1-4是一个简单的电商系统中商品服务、用户服务、订单服务和库存服务之间的交互示意图，可以看到消息中间件(MQ)是关键，它负责连通各个微服务，承担了整个系统互联互通的重任。
图1-4 基于消息队列的微服务架构
基于消息队列的微服务架构是全异步通信模式的一种设计，各个组件之间没有直接的耦合关系，也不存在服务接口与服务调用的说法，服务之间通过消息来实现彼此的通信与业务流程的驱动。基于消息队列的微服务架构应用的案例并不多，更多地体现为一种与业务相关的设计经验，每个公司都有不同的实现方式，缺乏公认的设计思路与参考架构，也没有形成一个知名的开源平台。因此，如要实施这种微服务架构，需要项目组自己从零开始去设计实现一个微服务架构基础平台，这可能会造成项目的成本较高且风险较大，决策之前需要进行全盘思考与客观评价。
3.Docker Swarm
Swarm项目是Docker公司发布的三剑客中的一员，用来提供容器集群服务，目的是更好地帮助用户管理多个Docker Engine，方便用户使用。通过把多个Docker Engine聚集在一起，形成一个大的Docker Engine，对外提供容器的集群服务。同时这个集群对外提供SwarmAPI，用户可以像使用Docker Engine一样使用Docker集群。
如图1-5所示Docker三剑客包括：Machine、Compose和Swarm。通过Machine可以在不同云平台上创建包含docker-engine的主机。Machine通过driver机制，支持多个平台的docker-engine环境的部署。Swarm将每一个主机上的docker-engine管理起来，对外提供容器集群服务。Compose项目主要用来提供基于容器的应用的编排。用户通过yaml文件描述由多个容器组成的应用，然后由Compose解析yaml文件，调用Docker API，在Swarm集群上创建对应的容器。
Swarm集群结构如图所示
图1-5 Docker三剑客
图1-6 Docker Swarm结构
从图1-6中我们看到一个Swarm集群中有两种角色的节点：
·Manager：负责集群的管理、集群状态的维持及将任务(Task)调度到工作节点上等。
·Worker：承载运行在Swarm集群中的容器实例，每个节点主动汇报其上运行的任务并维持同步状态。
Docker Swarm对外提供Docker API，自身轻量，学习成本、二次开发成本都比较低，是一个插件式框架。从功能上讲，Swarm是类似于Google开源的Kubernetes微服务架构平台的一个产品。
4.Spring Cloud
Spring Cloud是一个基于SpringBoot实现的云应用开发工具，是一系列框架的集合，当添加这些工具库到应用后会增强应用的行为。Spring Boot秉持约定优于配置的思想，因此可以利用这些组件基本的默认行为来快速入门，并在需要的时候可以配置或扩展，以创建自定义解决方案。
Spring Cloud利用Spring Boot的开发便利性，巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以基于Spring Boot组件进行开发，做到一键启动和部署。Spring Cloud并没有重复制造轮子，它只是将目前比较成熟、经得起实际考验、优秀的开源服务框架组合起来，通过Spring Boot进行封装，屏蔽掉复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。
以下为Spring Cloud的核心功能：
·分布式/版本化配置
·服务注册和发现
·服务路由
·服务和服务之间的调用
·负载均衡
·断路器
·分布式消息传递
还有很多基础的功能没有列出，每个功能对应Spring Cloud中的一个组件，包括Spring Cloud Config、Spring Cloud Netflix(Eureka、Hystrix、Zuul、Archaius…)、Spring Cloud Bus等组件。
1.3 云原生与微服务
提及云原生，首先需要了解一下CNCF，即云原生计算基金会，2015年由谷歌牵头成立，基金会成员目前已有一百多个企业与机构，包括亚马逊、微软、思科等巨头。目前CNCF所托管的应用已达14个，知名的项目有Kubernetes、Prometheus、Envoy等。
1.云原生
CNCF宪章中给出了云原生应用的三大特征，概括如下：
·容器化封装：以容器为基础，提高整体开发水平，形成代码和组件重用，简化云原生应用程序的维护。在容器中运行应用程序和进程，并作为应用程序部署的独立单元，实现高水平资源隔离。
·动态管理：通过集中式的编排调度系统来动态管理和调度。
·面向微服务：明确服务间的依赖，互相解耦。云原生包含了一组应用的模式，用于帮助企业快速、持续、可靠、规模化地交付业务软件。如图1-7所示，云原生由微服务架构、DevOps和以容器为代表的敏捷基础架构组成
2.12原则
12原则(12-Factors)经常直译为12要素，12原则由公有云PaaS的先驱Heroku于2012年提出(https://12factor.net/)，目的是告诉开发者如何利用云平台提供的便利来开发更具可靠性和扩展性、更加易于维护的云原生应用。12原则包括：
·基准代码。
·显式声明依赖关系。
·在环境中存储配置。
·把后端服务当作附加资源。
·严格分离构建、发布和运行。
·无状态进程。
·通过端口绑定提供服务。
·通过进程模型进行扩展。
·快速启动和优雅终止。
·开发环境与线上环境等价。
·日志作为事件流。
·管理进程。
另外还有补充的三点：API声明管理、认证和授权、监控与告警
12原则提出来已有六年多，12原则的有些细节可能已经不那么跟得上时代，也有人批评12原则的提出从一开始就有过于依赖Heroku自身特性的倾向。不过不管怎样，12原则依旧是业界最为系统的云原生应用开发指南。
3.容器化
Docker是一个开源引擎，可以轻松地为任何应用创建一个轻量级的、可移植的、自给自足的容器。最近几年Docker容器化技术很火，在各种场合都能够听到关于Docker的分享。Docker让开发工程师可以将他们的应用和依赖封装到一个可移植的容器中。Docker根本的想法是创建软件程序可移植的轻量容器，让其可以在任何安装了Docker的机器上运行，而不用关心底层操作系统。
Docker可以解决虚拟机能够解决的问题，同时也能够解决虚拟机由于资源要求过高而无法解决的问题。其优势包括：
·隔离应用依赖。
·创建应用镜像并进行复制
·创建容易分发的、即启即用的应用。
·允许实例简单、快速地扩展。
·测试应用并随后销毁它们。
虽然自动化运维工具可以降低环境搭建的复杂度，但仍然不能从根本上解决环境的问题。在看似稳定而成熟的场景下，结合使用Docker显然能带来更多的好处。
一旦拥抱了容器，这就需要一个编排框架来调度和管理容器。最常见的编排框架有Kubernetes、Mesos、Docker Swarm。编排框架是容器平台的关键组成部分。
4.DevOps
DevOps是软件开发人员(Dev)和IT运维技术人员(Ops)之间的合作，目标是自动执行软件交付和基础架构更改流程，使得构建、测试、发布软件能够更加地快捷和可靠。它创造了一种文化和环境，可在其中快速、频繁且更可靠地构建、测试和发布软件。通过DevOps流水线加上Docker容器，可以实现自动化工程管理，实现开发、测试环境的自动申请和构建。通过Docker标准化打包应用配置和环境，可以生成轻量容器镜像，并使用镜像方式迭代开发、测试、部署，加速应用上线。自动化运维在合理保障应用高可用的前提下，能够提升资源利用率，降低成本。
DevOps的引入能对产品交付、测试、功能开发和维护起到意义深远的影响。在缺乏DevOps能力的组织中，开发与运营之间存在着信息“鸿沟”，例如运营人员要求更好的可靠性和安全性，开发人员则希望基础设施响应更快，而业务用户的需求则是更快地将更多的特性发布给最终用户使用。
5.微服务
微服务将单体业务系统分解为多个可独立部署的服务。这个服务通常只关注某项业务，或者最小可提供业务价值的“原子”服务单元。
微服务架构有以下优势：
当人们将业务领域分解为可独立部署的环境时，能够将相关的变更周期解耦。只要变更限于单一有限的环境，并且服务继续履行其现有合约，那么这些变更可以独立于其他业务来进行和部署。其结果是实现了更频繁和快速的部署，实现了持续的价值流动。
扩展更多的部署组件本身可以加快部署。在原本的单体应用中，由于沟通和协调的开销，在添加更多的人手时，往往会使软件开发流程变得更长。在软件项目的晚期增加更多的人力往往会使软件项目更加延期。但是微服务架构中可以在有限的环境中构建更多的沙箱，而不是将所有的开发者都放在同一个沙箱中。由于学习业务领域和现有代码负担减少，并且团队较小，因此添加到每个沙箱的新开发人员可以更快速地提高并使得工作变得更高效。
可以加快采用新技术的步伐。大型单体应用程序架构通常与对技术堆栈的长期保证有关。这些保证的存在是用新技术的风险。技术选型的错误在单体架构中的代价非常昂贵，因为这些错误会影响整个企业架构。如果可以在服务的范围内采用新技术，就将隔离并最大限度地降低风险，就像隔离和最小化运行时故障的风险一样。微服务提供独立、高效的服务扩展。单体架构也可以扩展，但要求我们扩展所有组件，而不仅仅是那些负载较重的组件。当且仅当相关联的负载需要它时，才缩放微服务。
