微服务架构和SOA区别

微服务现在辣么火，业界流行的对比的却都是所谓的Monolithic单体应用，而大量的系统在十几年前都是已经是分布式系统了，那么微服务作为新的理念和原来的分布式系统，或者说SOA（面向服务架构）是什么区别呢？

软件发展的三个阶段：

1.传统单体架构

先从JEE架构发展至SSH架构。

J2EE架构：以面向对象的Java 编程语言为基础，扩展了Java 平台的标准版，是Java 平台企业版的简称。JEE 将企业级软件架构分为三个层级： Web 层、业务逻辑层和数据存取层。将不同的模块化组件聚合后运行在通用的应用服务器上。

SSH架构：开源软件Struts 、Spring 和Hibernate 开始崭露头角，很快成为行业内企业开发的开源框架标配（简称SSH)，Web MVC 框架Struts 在用户交互的UI 层进一步划分了前端的职责，将用户交互层划分为视图、模型和控制器三大块（简称MVC 模型），在那个时代， 几乎大多数企业服务的Web 项目都是如此。

从JEE 时代到SSH 时代，服务的特点仍然是单体化，服务的粒度抽象为模块化组件，所有组件精合在一个开发项目中，并且配置和运行在一个口叫进程中。也带来了新的问题：

1. 如果某个模块化组件需要升级上线，则会导致其他没有变更的模块化组件同样上线，在严重情况下，对某个模块化组件的变更，由于种种原因，会导致其他模块化组件出现问题。
2. 传统JEE 和SSH 无法满足对海量用户发起的高井发请求进行处理的需求，无法突破稿合在一起的模块化组件的性能瓶颈，单一进程己经无法满足需求，并且水平扩展的能力也是很有限的。

2. SOA架构

SOA 代表面向服务的架构，俗称服务化。

SOA 将应用程序的模块化组件通过定义明确的接口和契约联系起来，接口是采用中立的方式进行定义的，独立于某种语言、硬件和操作系统，通常通过网络通信来完成，但是并不局限于某种网络协议，可以是底层的TCP膺，可以是应用层的HTTP ，也可以是消息队列协议，甚至可以是约定的某种数据库存储形式。

SOA 将模块化组件从单一进程中进一步拆分，形成独立的对外提供服务的网络化组件，每个网络化组件通过某种网络协议对外提供服务，这种架构下的特点如下。

• SOA 定义了良好的对外接口，通过网络协议对外提供服务，服务之间表现为松祸合性，松祸合性具有灵活的特点，可以对服务流程进行灵活组装和编排，而不需要对服务本身做改变。
• 组成整个业务流程的每个服务的内部结构和实现在发生改变时，不影响整个流程对外提供服务，只要对外的接口保持不变，则改变服务内部的实现机制对外部来说可以是透明的。
• SOA 在这一时代的数据通信格式通常为XML ，因为XML 标记定义在大规模、高并发通信过程中，元余的标记会给性能带来极大的影响，所以后来被JSON 所取代。
• SOA 通过定义标准的对外接口，可以让底层通用服务进行下沉，供多个上层的使用方同时使用，增加了服务的可重用性。
• SOA 可以让企业最大化地使用内部和外部的公共服务，避免重复造轮子，例如：通过SOA 从外部获取时间服务。

此时SOA 的两个主流实现方式： Web Service 平日ESB（事件处理、数据转换和映射、消息和事件异步队列顺序处理、安全和异常处理、协议转换和保证通信服务的质量等场景） 。

3. 微服务

Web Service 的问题有：

• 依赖中心化的服务发现机制
• 使用SOAP 通信协议，通常使用XML 格式来序列化通信数据， XML 格式的数据冗余
  太大，协议太重
• 服务化管理和治理设施并不完善

ESB 的问题有：

• ESB 虽然是SOA 实现的一种方式，却更多地体现了系统集成的便利性，通过统一的服务总线将服务组合在一起，并提供组合的业务流程服务
• 组合在ESB 上的服务本身可能是一个过重的整体服务，或者是传统的JEE 服务等
• ESB 视图通过总线来隐藏系统内部的复杂性，但是系统内部的复杂性仍然存在
• 对于总线本身的中心化的管理模型，系统变更影响的范围经常会随之扩大

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

微服务的定义：

• 微服务把每一个职责单一的功能放在一个独立的服务中
• 每个服务运行在一个单独的进程中
• 每个服务有多个实例在运行，每个实例可以运行在容器化平台内，达到平滑伸缩的效果
• 每个服务有自己的数据存储，实际上，每个服务应该有自己独享的数据库、缓存、消息队列等资源
• 每个服务应该有自己的运营平台，以及独享的运营人员，这包括技术运维和业务运营人员：每个服务都高度自治，内部的变化对外透明
• 每个服务都可根据性能需求独立地进行水平伸缩

微服务架构与SOA

相同点

事实上微服务架构与SOA 服务化架构并不冲突，它们一脉相承，微服务架构是服务化架构响应特定历史时期的使用场景的延续，是服务化进行升华井落地的一种实现方式。SOA 服务化的理念在微服务架构中仍然有效，微服务在S OA 服务化的基础上进行了演进和叠加，形成了适合现代化应用场景的一个方法论。

不同点

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

最后需要强调，微服务架构并不是为了拆分而拆分，真正的目的是通过对微服务进行水平扩展解决传统的单体应用在业务急剧增长时遇到的问题，而且由于拆分的微服务系统中专业的人做专业的事，人员和项目的职责单一、低藕合、高内聚，所以产生问题的概率就会降到最小。

微服务和Domain Driven Design

由于微服务是业务而非技术在驱动，这点与DDD不谋而合。DDD的初衷：让业务架构绑定系统架构。

它还可以帮助业务划分领域边界，可以明确哪个领域是自己的核心价值所在，以后应该重点发展哪个领域。甚至可以作为组织进行战略规划的参考。

小结

微服务架构首先要关注的不是RPC/ServiceDiscovery/Circuit Breaker这些概念，也不是Eureka/Docker/SpringCloud/Zipkin这些技术框架，而是服务的边界、职责划分，划分错误就会陷入大量的服务间的相互调用和分布式事务中，这种情况微服务带来的不是便利而是麻烦。DDD给我们带来了合理的划分手段，但是DDD的概念众多，晦涩难以理解，如何抓住重点，合理的运用到微服务架构中呢？我认为如下的几个架构思想是重中之重

• 充血模型

• 事件驱动