大家都听过SOA架构，也都知道现在特别火的微服务架构，那么这两个有什么区别呢，别傻傻分不清了，这篇告诉你，学会它，把阿里面试官都说懵逼！
前言
之前找工作面试的时候，面试官总是问我你了解SOA吗，你知道为什么微服务这么火吗，他们有什么区别吗，之前乱说一通的我现在才知道，了解这个可能比你会开发更重要，所以它来了！
系统架构的发展
烟囱式的架构
很多公司老的IT架构属于传统的“烟囱式”架构，也就是每个业务线之间由不同的开发团队独立建设，技术栈不同，互不联系。大多数的架构会被打包成为war包并且被部署到Apache Tomcat Web容器中， 整个结构趋于传统的单体架构，业务逻辑耦合在一个项目中。
这样的架构有几个主要的弊端：
- 重复开发。每个业务线中间同样的模块会重复开发，比如会员营销模块，A业务线要建一个会员营销系统，B业务线也要建一个会员营销系统，这会造成很大的开发资源浪费；
- 技术栈不统一。可能A系统用的是Spring MVC, B系统用的就是Spring Boot/Cloud。这会造成公司内部IT架构无法统一规划，且技术能力难以积累的问题；
- 数据分布广，格式不统一，导致数据难以打通。A系统的会员存在A系统的MySQL库中，B系统的会员存在B系统的Oracle库中，如果要识别A系统中的001会员和B系统中的002会员是同一个人，也许只能在数仓中实现了。
总结：这样的架构的好处就是可以互不影响地独立部署独立迭代了，适合业务线较少且比较独立的公司采用。
SOA架构
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到微服务
SOA的出现其实是为了解决历史问题：企业在信息化的过程中会有各种各样互相隔离的系统，需要有一种机制将他们整合起来，所以才会有上边所述的ESB的出现。同样的，也造成了SOA初期的服务是很大的概念，通常指定的一个可以独立运作的系统（这样看，好像服务间天然的松耦合）。这种做法相当于是「把子系统服务化」。
而微服务没有历史包袱，轻装上阵，服务的尺寸通常不会太大，关于服务的尺寸，在实际情况中往往是一个服务应该能够代表「实际业务场景中的一块不可分割或不易分割的业务实体」。将服务的尺寸控制在一个较小的体量可以带来很多的好处
微服务架构倡导将软件应用设计成多个可独立开发、可配置、可运行和可维护的子服务，子服务之间通过良好的接口定义通信机制，通常使用 RESTful 风格的 API 形式来通信 ，因为RESTful 风格的 API 通常是在 HTTP 或者 HTTPS 通道上传输 JSON 格式的数据来实现的， HTTP协议有跨语言、跨异构系统的优点， 当然，也可以通过底层的 进制协议、消息队列协议等进行交互。这些服务不需要中心化的统 管理，每个服务的功能可自治，并且可以由不同的语言、系统和平台实现。
微服务的架构如下图所示：
我们看到微服务架构的 些特点与 SOA 服务化架构相似， 事实上微服务架构与 SOA服务化架构并不冲突，它们一脉相承，却略有不同：
- 目的不同 微服务使用 系列的微小服务来实现整体的业务流程，目的是有效地拆分应用，实现敏捷开发和部署，在每个微小服务的团队里，减少了跨团队的沟通，让专业的人做专业的事，缩小变更和迭代影响的范围，并达到单一微服务更容易水平扩展的目的。 SOA 服务化涉及的范围更广 些，强调不同的异构服务之间的协作和契约 ，并强调有效集成、业务流程编排、历史应用集成等，典型代表为 Web Service 和ESB。
- 部署不同 微服务将完整的应用拆分成多个细小的服务，通常使用敏捷扩容、缩容的 Docker 技术来实现自动化的容器管理 每个微服务运行在单 的进程内，微服务中的部署互相独立互不影响。 SOA 服务化通常将多个业务服务通过组件化模块方式打包在 War 包里，然后统部署在一个应用服务器上。
- 服务粒度不同 微服务倡导将服务拆分成更细的粒度，通过多个服务组合来实现业务流程的处理，拆到职责单一，甚至小到不能再进行拆分。 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中心化的实现方式，要分清两者的区别，不要混淆了！
假如面试中你被问到这些，我相信你看了这篇一定能拨动面试官的心！
