单体架构--＞SOA架构--＞微服务架构

 上诉架构图采用了分层架构，按照调用顺序，从上到下为表示层、业务层、数据访问（DAO）层、DB层。表示层负责用户体验，业务层负责业务逻辑，包括电影、订单和用户三个模块。数据访问层负责DB层的数据存取，实现增删改查的功能。业务层定义了应用的业务逻辑，是整个应用的核心。在单体应用中，所有这些模块都集成在一起，这样的系统架构就叫做单体应用架构，或称为巨石型应用架构。单体应用是最早的应用形态，开发和部署都很简单。在中小型项目中使用单体应用架构，能体现出其优势，且单体应用的整体性能主要依赖于硬件资源和逻辑代码实现，应用架构自身不需要特别关注。单体应用的集成非常简洁，IDE集成开发环境和其他工具都擅长开发一个简单应用；单体应用易于调试，由于一个应用包含所有功能，所以只需要简单运行此应用即可进行开发测试，单体应用易于部署，只需要把应用打包，拷贝到服务器端即可；通过负载均衡器，运行多个服务实例，单体应用可以轻松实现应用扩展。

随着应用项目变得复杂、开发团队不断扩张之后，单体应用的不足和弊端将会变得很明显

单体应用的不足：

   可靠性：每个bug都可能影响到整个应用的可靠性。因为所有模块都运行在一个进程中，任何一个模块中的一个bug，比如内存泄漏，都可能拖垮整个进程。

 复杂性高：单体应用巨大的代码库可能会令人望而生畏，特别是对团队新成员来说。应用难以理解和迭代，进而导致开发速度减慢。由于没有清晰的模块边界，模块化会逐渐消失。

持续部署困难：巨大的单体应用本身就是频繁部署的一大障碍。\

为了更新一个组件，必须重新部署单个应用。这回中断那些可能与更改无关的后台任务，同时可能引发其他问题。另外，未被更新的组件有可能无法正常启动。重新部署会增加风险，进而阻碍频繁更新。

扩展能力受限：单体架构只能进行一维扩展。一方面，它可以通过运行多个应用服务实例来增加业务容量，实现扩展。但另一方面，不同的应用组件有不同的资源需求：有的是CPU密集型的，有的是内存密集型的。单体架构无法单独扩展每个组件。

阻碍技术创新：单体应用往往使用统一的技术平台或方案解决所有问题，团队的每个成员都必须使用相同的开发语言和架构，想要引入新的框架或技术平台非常困难。单体架构迫使团队长期使用在开发初期选定的技术栈，比如选择了JVM语言，此时以非JVM语言编写的组件就无法在该单体架构的应用中使用

SOA架构：

   面向服务的架构，SOA的核心主体是服务，其目标是通过服务的流程化来实现业务的灵活性。服务就像一堆“元器件”，这些元器件通过封装形成标准服务，它们有相同的接口和语义表达规则。但服务要组装成一个流程和应用，还需要有效的“管理”，包括如何注册服务、如何发现服务、如何包装服务的安全性和可靠性，这些就是SOA治理。SOA治理是将SOA的一堆元器件进行有效组装。这是形成一个“产品”的关键。否则那些永远是一堆元器件，而无法形成一个有机整体。

  完整的SOA架构由五大部分组成：基础设施服务、企业服务总线、关键服务组件、开发工具、管理工具等。

   基础设施：为整个SOA组件和框架提供一个可靠的运行环境，以及服务组件容器，它的核心组件是应用服务器等基础软件支撑设施，提供运行期完整、可靠的软件支撑

   企业服务总线：提供可靠消息传输、服务接入、协议转换、数据格式转换、基于内容的路由等功能，屏蔽了服务的物理位置、协议和数据格式。

  关键服务组件：SOA在各种业务服务组件的分类。

   开发工具和管理工具：提供完善的、可视化的服务开发和流程编排工具，包括服务的设计、开发、配置、部署、监控、重构等完整的SOA项目开发生命周期。具体来说，就是在分布式的环境中，将各种功能都以服务的形式提供给最终用户或则其他服务。企业级应用的开发多采用面向服务的体系架构来满足灵活多变、可重用性的需求。它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口采用中立的方式进行定义，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。

  SOA是在企业计算领域中提出的，目的是要将紧耦合的系统，划分为面向业务的、粗粒度、松耦合、无状态的服务。服务发布出来供其他服务调用，一组互相依赖的服务就构成了SOA架构的系统。基于这些基础的服务，可以将业务过程用类似BPEL(业务流程执行语言)流程的方式编排