场景如果我们打开支付宝首页，查看余额，会显示你的总资产、昨日收入、累计收入等信息。如果本页面展示的信息来自不同的系统/应用，我们会通过各种接口展示数据。如果我们现在要把这几项数据显示在前端页面，应该怎么显示呢？在这种情况下，客户端不可能与6个不同的应用/系统一一通信来完成数据的展示。相反，六个应用程序/系统相互通信以完成调用。最后，客户端只需要调用一个接口就可以获取数据，而不需要和各个应用/系统进行通信。我们的架构可能是这样的：一个电商系统，比如淘宝，我们会在首页展示很多数据信息，比如：首页信息，商品信息，个人信息，推送信息等等，很多。如果首页展示的数据来自100个不同的应用/系统，那么通过上面的架构，我们后台会有成百上千的通信交互，后台的结构会变得非常庞大和复杂。所以在这个架构下，我们需要对上面的架构做一些调整，所以我们引入SOA架构图来区分什么是SOA架构SOA（全称：ServiceOrientedArchitecture），中文意思是“面向服务的架构”，你可以理解为一种架构模型或者一种设计方法，而不是一种服务解决方案。它包含多个服务，服务之间通过相互依赖或通信机制进行通信，最终提供一系列的功能。服务通常以独立的形式存在于操作系统进程中。每个服务都通过网络调用。还有一个与SOA相提并论的ESB（企业服务总线）。简单的说，ESB就是一个用来连接各个服务节点的管道。为了集成不同系统和不同协议的服务，ESB可以简单理解为：它做了消息的转换、解释和路由，使不同的服务可以相互通信；我们去掉了每个应用之间的所有通信，引入了一个ESB企业总线，每个服务只需要和ESB通信。这时候各个应用之间的交互会变得更加清晰，业务架构/逻辑等也会变得更加清晰。将原本杂乱无章的系统整理成了有计划可管理的系统。在这个过程中，最大的变化就是ESB企业总线的引入。SOA解决的核心问题1、系统集成：从系统的角度，解决企业系统间的通信问题，将系统间原本分散的、无计划的网络结构梳理成规则的、可管理的系统间星型结构，这样步骤经常需要介绍一些产品，比如ESB，以及技术规范，服务管理规范；可重用、可组装的服务通过服务编排实现业务的快速再生。目的：将原有固有的业务功能转化为通用的业务服务，实现业务逻辑的快速复用；这一步要解决的核心问题是【重用】3、业务服务：从企业的角度，将企业功能抽象成可重用、可组装的服务；将原有的功能型企业架构转变为面向服务的企业架构，进一步提升企业的对外服务能力；前两步是从技术层面解决系统调用和系统功能复杂度使用问题。第三步，将一个业务单元封装成一个带有业务驱动的服务。这一步要解决的核心问题是【高效】微服务架构微服务架构其实类似于SOA架构，微服务是SOA的升华。微服务架构的重点之一是“业务需要彻底的组件化和服务化”。将原来单一的业务系统拆分成多个可以独立开发、设计、运行的小应用。这样的小应用程序与其他应用程序相互协作、通信，完成一次交互和集成。这就是微服务架构。组件化：一个组件代表一个可以独立更换升级的单元。以PC为例，PC中的CPU、内存、显卡、硬盘都是一样的，可以独立更换升级，不影响其他单元。如果我们将PC构建为componentasaservice，那么这台PC只需要维护主板和一些必要的外设即可。CPU、内存、硬盘都以组件的形式提供服务。PC需要调用CPU进行计算处理，只需要知道CPU组件的地址即可。微服务的特点1.通过服务实现组件化2.根据业务能力划分服务和开发团队3.去中心化4.基础设施自动化（devops，自动化部署）SOA和微服务架构的区别1.微服务集中化，去除ESB企业总线。微服务不再强调传统SOA架构中相对笨重的ESB企业服务总线。同时，SOA的思想进入单体业务系统，实现真正的组件化。2、Docker容器技术的出现，为微服务提供了更便利的条件。比如更小的部署单元，每个服务都可以通过Node或者SpringBoot等技术运行在自己的进程中。3、SOA侧重于系统集成，而微服务侧重于完全分离
