soa是什么(IBM观点：SOA与微服务区别？)

微服务是SOA的发展演进，但是来自IBM一篇博客文章好像将两者完全置于平等的角度进行比较，本文翻译中加入了本人的批判观点。如果你在IT部门工作，可能已经听过SOA与微服务的争论。毕竟，现在每个人都在谈论微服务和敏捷应用程序。乍一看，这两种方法听起来非常相似，是的，在某些方面，他们是相似，两者都不同于传统的单体架构（banq注：SOA其实本身是一种单体架构），因为每项服务都有自己的责任，两者都受益于一定程度的脱钩解耦。主要区别归结为范围，简而言之，面向服务的架构（SOA）具有企业范围，而微服务架构具有应用程序范围。以下是每种情况的一些非常基本的定义：1. SOA是一项企业级计划，旨在创建可重用、同步可用的服务和API。这有助于开发人员更快速地创建应用程序，并更轻松地集成其他系统。2. 微服务架构是一种用于构建单个app的选项，使该app更加灵活，可扩展且具有弹性。为什么这种差异很重要当你忽视这种差异时，每种方法的许多核心原则都会变得不相容。如果您接受范围的差异，您可能很快意识到这两者可能相互补充而不是竞争。以下是这种区别发挥作用的几种情况：1. 重用, 在SOA中，集成上的重用是企业主要目标，在企业级别，努力实现某种程度的重用是至关重要的。在微服务架构中，强调松耦合、敏捷性和弹性，微服务组件通常更喜欢通过复制重用代码并接受数据复制以帮助改善解耦banq注：软件复杂性是因为一段代码做两件事，因此一段代码只实现一个单一职责，微服务通过运行时调用某个单一职责的微服务来实现重用。但是重用有时如果不仔细设计，就可能导致一段代码做多个事情，因为程序员觉得这几个事情差不多，就是实现单一职责功能，其实忽视了职责功能所处的上下文区别，虽然主要功能差不多，但是细微上有差别，最后实现成可运行时的代码时实际上变成了做几件事，比如通过设置很多if语句来判断不同上下文和入参数据。这就很难修改拓展，变成单体架构。如果开始编码主要目的不是为了单一职责，而是为了重用，很容易在代码级别耦合调用那些所谓重用代码，最后造成紧耦合，变成单体架构，整个代码都如同意大利面条一样混杂在一起，变成铁板一块。SOA主要目的集成重用，比如A系统实现了A功能，B系统实现了B功能，那么现在C=A B，那么当然会将A和B系统集成进来，之所以称为集成，是因为你不能再修改A系统代码了，也许A系统已经是遗留系统，或者别的公司代码，并不配合你修改。所以，这种集成重用是不破坏原来封装情况下的重用，其实这种难度比较大，其实集成主要目的是流程组合：今天希望先完成A系统的A功能，明天希望完成B系统的B功能；过几天两种执行顺序再倒过来，或糅合进入其他功能重组流程。所以，我个人认为：微服务已经通过单一职责方式实现了松耦合的职责功能重用，而SOA主要目的不是职责功能重用，而是职责功能执行流程的重组，而这也是建立在微服务单一职责基础上。见我另外一篇：单一职责和重用可能是对立的2. 同步通讯，SOA中的可重用服务可在整个企业中使用，主要使用RESTful API等同步协议，但是，在微服务应用程序中，同步调用会引入实时依赖性，从而导致弹性丧失。它还可能导致延迟，从而影响性能。在微服务应用程序中，优选是基于异步通信的交互模式，例如事件溯源，其中使用发布订阅模型使微服务组件能够保持最新发生在另一组件中的数据发生的变化。banq注：虽然微服务采取异步更加完美，但是程序员对于异步编程有一定门槛，因此采取RESTful API同步调用也是微服务的主要特点，同步和异步的通讯方式不构成SOA和微服务的主要区别，主要区别是通讯管道的设计特点上，如果所有服务依赖一个复杂的智能的总管道，比如ESB总线之类，这是SOA；而微服务强调智能端点，哑管道，所谓哑管道就是笨管道，管道要求简单，不要采取复杂总线，否则ESB成为单点风险，成为系统耦合中心。3. 数据重复，在SOA中提供服务的明确目标是让所有应用程序直接在其主要数据源上同步获取和更改数据，从而减少维护复杂数据同步模式的需要。在微服务应用程序中，每个微服务理想地拥有自己的数据源，不同微服务不能像SOA那样跨数据库访问，这样才能确保微服务的独立性，但这样做可能意味在自己数据库中存在一些其他数据库的重复数据。当然，这种重复增加了复杂性，因此必须与敏捷性和性能的提升相平衡，但这被认为是微服务设计的现实。banq注：如果一个微服务需要使用其他数据库，需要通过那个数据库所属的微服务调用，微服务是无状态的，也不赞成在本地数据库缓存一些其他微服务的数据，因此，不会存在数据重复和冗余，冗余与重复来自于单一职责没有实现到位。最后一点，数据重复其实是因为只考虑重用导致的后果，结果变成代码实际做了几件事，数据实际复制了好几份，这种复杂性是单体架构正是当前SOA系统主要问题，这些都是因为从系统开始之处只注重复用的设计思维导致。