大家都听过SOA架构，也都知道现在特别火的微服务架构，那么这两个有什么区别呢，别傻傻分不清了，这篇告诉你，学会它，把阿里面试官都说懵逼！

之前找工作面试的时候，面试官总是问我你了解SOA吗，你知道为什么微服务这么火吗，他们有什么区别吗，之前乱说一通的我现在才知道，了解这个可能比你会开发更重要，所以它来了！

很多公司老的IT架构属于传统的“烟囱式”架构，也就是每个业务线之间由不同的开发团队独立建设，技术栈不同，互不联系。大多数的架构会被打包成为war包并且被部署到Apache Tomcat Web容器中， 整个结构趋于传统的单体架构，业务逻辑耦合在一个项目中。

这样的架构有几个主要的弊端：

1. 重复开发。每个业务线中间同样的模块会重复开发，比如会员营销模块，A业务线要建一个会员营销系统，B业务线也要建一个会员营销系统，这会造成很大的开发资源浪费；
2. 技术栈不统一。可能A系统用的是Spring MVC, B系统用的就是Spring Boot/Cloud。这会造成公司内部IT架构无法统一规划，且技术能力难以积累的问题；
3. 数据分布广，格式不统一，导致数据难以打通。A系统的会员存在A系统的MySQL库中，B系统的会员存在B系统的Oracle库中，如果要识别A系统中的001会员和B系统中的002会员是同一个人，也许只能在数仓中实现了。

总结：这样的架构的好处就是可以互不影响地独立部署独立迭代了，适合业务线较少且比较独立的公司采用。

SOA 全称是: Service Oriented Architecture，中文释义为 “面向服务的架构”它是一种设计理念，其中包含多个服务， 服务之间通过相互依赖最终提供一系列完整的功能。各个服务通常以独立的形式部署运行，服务之间 通过网络进行调用。架构图如下：

SOA的核心理念为：松耦合带来的服务重用，通过服务编排助力业务的快速响应和创新。 在SOA时代，有两种SOA的主要实现方式，分别是Web Service 和ESB。

下面会着重讲一下ESB

微服务架构和 SOA 架构非常类似,微服务只是的 SOA 升华，只不过微服务架构强调的是“业务需要彻底的组件化及服务化”，原单个业务系统会被拆分为多个可以独立开发、设计、部署运行的小应用。这些小应用间通过服务化完成交互和集成。组件表示的就是一个可以独立更换和升级的单元，就像 PC 中的 CPU、内存、显卡、硬盘一样，独立且可以更换升级而不影响其他单元。若我们把 PC 中的各个组件以服务的方式构建，那么这台 PC 只需要维护主板和一些必要的外部设备就可以。CPU、内存、硬盘等都是以组件方式提供服务，例如PC 需要调用 CPU 做计算处理，只需知道 CPU 这个组件的地址就可以了。

单体架构和微服务架构对比：

接下来聊一聊SOA中的ESB

随着我们的业务越来越复杂，会发现服务越来越多，SOA架构下，他们的调用关系会变成

怎么去清理这一团糟的东西呢？ESB(企业服务总线)来了！

当你理解系统并不直接交换信息，理解什么是服务，那么现在你可以开始使用ESB了。

简单来说 ESB 就是一根管道，用来连接各个服务节点。ESB的存在是为了集成基于不同协议的不同服务，ESB 做了消息的转化、解释以及路由的工作，以此来让不同的服务互联互通。

从名称就能知道，它的概念借鉴了计算机组成原理中的通信模型——总线，所有需要和外部系统通信的系统，统统接入ESB，岂不是完美地兼容了现有的互相隔离的异构系统，可以利用现有的系统构建一个全新的松耦合的异构的分布式系统。

ESB做了消息的转换解释与路由等工作，让不同的服务互联互通。传统的ESB的服务调用方式是，每一次服务的调用者要向服务提供者进行服务交互请求时都必须通过中心的ESB来进行路由。

每一次服务交互的路线是：

服务调用者-->ESB（接收服务请求）-->服务提供者（服务处理）-->ESB（服务提供返回结果）-->服务调用者（服务返回）

使用了ESB，也需要注意！

毁掉SOA概念的最好的方法就是，推出ESB，就期待所有的事情自己顺顺利利。虽然ESB是一个了不起的想法，但很不幸，只是简单的安装ESB不会解决你太多问题。最好的方法，你还是要整理一下你的架构。

像下图一样，如果不打扫，即使用了ESB也得不到任何好处。

所以从最开始的架构设计到之后的定时整理都至关重要！

SOA的出现其实是为了解决历史问题：企业在信息化的过程中会有各种各样互相隔离的系统，需要有一种机制将他们整合起来，所以才会有上边所述的ESB的出现。同样的，也造成了SOA初期的服务是很大的概念，通常指定的一个可以独立运作的系统（这样看，好像服务间天然的松耦合）。这种做法相当于是「把子系统服务化」。

而微服务没有历史包袱，轻装上阵，服务的尺寸通常不会太大，关于服务的尺寸，在实际情况中往往是一个服务应该能够代表「实际业务场景中的一块不可分割或不易分割的业务实体」。将服务的尺寸控制在一个较小的体量可以带来很多的好处

微服务架构倡导将软件应用设计成多个可独立开发、可配置、可运行和可维护的子服务，子服务之间通过良好的接口定义通信机制，通常使用 RESTful 风格的 API 形式来通信 ，因为RESTful 风格的 API 通常是在 HTTP 或者 HTTPS 通道上传输 JSON 格式的数据来实现的， HTTP协议有跨语言、跨异构系统的优点， 当然，也可以通过底层的 进制协议、消息队列协议等进行交互。这些服务不需要中心化的统 管理，每个服务的功能可自治，并且可以由不同的语言、系统和平台实现。

微服务的架构如下图所示：

我们看到微服务架构的 些特点与 SOA 服务化架构相似， 事实上微服务架构与 SOA服务化架构并不冲突，它们一脉相承，却略有不同：

1. 目的不同 微服务使用 系列的微小服务来实现整体的业务流程，目的是有效地拆分应用，实现敏捷开发和部署，在每个微小服务的团队里，减少了跨团队的沟通，让专业的人做专业的事，缩小变更和迭代影响的范围，并达到单一微服务更容易水平扩展的目的。 SOA 服务化涉及的范围更广 些，强调不同的异构服务之间的协作和契约 ，并强调有效集成、业务流程编排、历史应用集成等，典型代表为 Web Service 和ESB。
2. 部署不同 微服务将完整的应用拆分成多个细小的服务，通常使用敏捷扩容、缩容的 Docker 技术来实现自动化的容器管理 每个微服务运行在单 的进程内，微服务中的部署互相独立互不影响。 SOA 服务化通常将多个业务服务通过组件化模块方式打包在 War 包里，然后统部署在一个应用服务器上。
3. 服务粒度不同 微服务倡导将服务拆分成更细的粒度，通过多个服务组合来实现业务流程的处理，拆到职责单一，甚至小到不能再进行拆分。 SOA对粒度没有要求，在实践中服务通常是粗粒度的，强调接口契约的规范化，内部实现可以更粗粒度。

SOA，ESB，微服务的区别和关系

1、SOA是一种理念，它的主要特性--面向服务的分布式计算，服务间松散耦合，支持服务的封装，服务注册和自动发现，以服务契约方式定义服务交互方式。但是，SOA并没有定义出具体的实现方式，目前有两套SOA理念的实现方式：中心化和去中心化，这两套架构并没有优劣之分，还是要针对企业的根本诉求。

2、SOA中心化的实现方式就是ESB，ESB的根本诉求是为了解决异构系统之间的连通性，通过协议转换、消息解析、消息路由把服务提供者的数据传送到服务消费者。所以，ESB是中心化的，很重，有一定的逻辑，但它的确可以解决一些公用逻辑的问题。

3、SOA去中心化的实现方式的根本诉求是扩展性，实现方式就是微服务。

分布式服务框架，主要有dubbo、spring cloud，实现后端服务治理的功能。

本文主要讲了架构的演变过程，以及各个架构模式的解析，从SOA出发了解它的概念和实现方式，了解ESB的作用和原理，探讨了SOA和微服务之间的关系。

SOA是一种概念，拿SOA和微服务做对比不太恰当，微服务是SOA去中心化的实现方式，而ESB是SOA中心化的实现方式，要分清两者的区别，不要混淆了！

假如面试中你被问到这些，我相信你看了这篇一定能拨动面试官的心！

秘密 第 PAGE Page 1 页 共 NUMPAGES \*ARABIC 23 页 <第一阶段性能测试报告> [说明： 本文件中“[]”中内容为举例和说明文字，请在文件拟制时替换或删除； 若文中某章节内容可省略、不需要或适用，请保留该标题，并根据实际在内容部分写明“略”、“勿需”或“不适用”等，同时适当说明原因。 请作者注意在文档右上角修改该文档的密级。]TITLE一帐通卡性能测试报告 文件修订历史 修订时间 修订概要 作者 审核 批准 新建 张良友 模板修订历史 版本 生效时间 变更概要 作者 审核 批准 秘密 第 PAGE Page 16 页 共 NUMPAGES \*ARABIC 23 页 IST性能测试报告 张良友 目录 TOC \w \x \o "1-3" 1. 本文档为XX银行XX系统性能测试方案，其内容用于描述本次性能测试服务的实施方案，以及测试项目组织实施的技术规范。 本文档中描述的内容，旨在 为XX系统的性能状态进行客观评估，提供性能数据； 为性能测试工作规定有效、完整的实施方案； 为性能测试工作规定具体的任务、角色分工、进度计划上的安排； 背景 满足集团的“一个客户，一个账户，多个产品，多种服务”的战略,XX将以标准的金融卡为基础，加载其他产品服务, XX卡与其它非银行产品的关联，将通过现有集团客户信息管理系统（CIF2）关联。 系统要上线前对XX系统做性能检验和评估。 目标 要求系统能支持并满足目前AS/400主机、信用卡系统的最大发卡量（4500万）及交易性能指标，不影响系统整体的交易性能。 电话银行IVR及人工客服能支持最大发卡量的服务。 程序没有大的性能漏洞； 系统性能能够满足基本上线要求 范围 业务范围 XX业务 系统范围 XX银行业务处理系统 XX接入平台系统 XX业务受理系统 术语和缩略语 术语/缩略词 说明 响应时间 TPS IST 测试内容及测试方法 此次压力测试实施是对XXXX 系统性能进行测试评估的过程，我们将依据系统（生产环境）的实际运行现状，抽取对系统性能产生较大影响的业务交易，模拟最终用户的操作行为，构建一个与生产实际相近的压力仿真模型（场景），对系统实施压力测试，以此评判系统的整体性能的实际性能表现。 测试内容 根据与相关人员的沟通和交流，此期工程上线的目标和期限，通过对现有系统运行数据的统计，结合系统的设计目标和业务特点，遵循着发生频率高、对系统或数据库性能影响大、关键和核心业务等原则，本期测试内容重点为银联交易操作及ESB验密功能，以及后台批处理业务。 测试方法 此次压力测试通过构建与真实环境相同数据规模的压力测试环境，采用业界成熟的自动化性能测试工具Loadrunner，通过创建压力测试程序、构建压力测试模型，对被测试系统实施自动化压力测试，最后形成压力测试结果分析报告。 性能测试流程 通过自动化测试工具模拟最终用户向服务器发起业务请求，进行性能测试。通过测试工具对测试过程中系统各点进行监控，每一次测试结束后工具自动生成结果报告供分析使用。 性能测试模型分析 系统是否能够稳定运行具有重要意义。因此，必须要采取科学的方法对XX系统进行全面的性能验收测试