本文源自一次面试官的提问:你觉得微服务和SOA架构有什么联系和区别?回想起来,在我一开始接触到微服务的概念的时候,我也萌生过这个疑惑。于是借着这个机会我认真思考了这个问题,有点自己的想法写下来,未必是合适的, 也希望不对之处大家给指出来。
SOA 出现于 20 世纪 90 年代后期,1994年,Gartner最早提出SOA。它代表了应用程序开发和集成发展的一个重要阶段。在 SOA 成为一种选择之前,将单体应用程序连接到另一个系统中的数据或功能需要复杂的点对点集成,开发人员必须为每个新的开发项目重新创建。通过 SOA 公开这些功能消除了每次都重新创建深度集成的需要。
维基百科上对于SOA的定义是这样子的:“面向服务的体系结构(英语:service-oriented architecture)并不特指一种技术,而是一种分布式运算的软件设计方法。软件的部分组件(调用者),可以透过网络上的通用协议调用另一个应用软件组件执行、运作,让调用者获得服务。”
在 SOA 软件架构中,每项服务都包含执行特定业务功能所需的代码和数据集成,这些服务模块之间相互独立,服务接口提供松散耦合,服务可以轻松被调用,由于这种松耦合和发布服务的方式,开发团队可以通过在整个企业的其他应用程序中重用组件来节省时间。
在SOA架构中一般使用企业服务总线ESB来提供模块之间的共享访问, 它是SOA架构常规实现方法中一个非常重要的组件。ESB通过使用标准网络协议(如 SOAP、XML、JSON、MQ )来开放服务以发送请求或访问数据,实现与各种系统间的协议转换、数据转换、透明的动态路由等功能,ESB的特性有:
SOA提供业务服务、企业服务、应用程序服务和基础设施服务等多种不同的服务类型,用于实现业务功能、基础功能等不同场景。每个服务由三个部分组成:
只要以标准的规范提供的服务就能接入总线,以松耦合的方式对外提供。开发者可以通过组合 SOA 服务来创建更高级别的服务和应用程序。
从以上我们可以看出SOA作为一种架构方法,主要强调的特点有:
与 SOA 一样, 微服务架构由松散耦合的、可重用的和专门的组件组成,这些组件通常彼此独立工作。微服务架构是一种面向服务的架构模式,将应用程序拆分为多个小型服务,软件由通过明确定义的API 进行通信,这些服务由各个小型独立团队负责,使应用程序更易于扩展和更快地开发、部署。
通常,Java 是开发微服务的首选编程语言,也可以使用其他编程语言,例如 Golang和Python。
"微服务"这个词是在2005年被首次提出的,当时指的是专注于单一职责的与语言无关的细粒度web服务,维基百科上对于微服务的定义是:微服务是一种软件开发技术,是SOA的一种变体。
微服务的发展很快,早就跳出一开始的狭窄的定义。它是一种真正的云原生架构方法,微服务通常在容器中运行,这使得它们在创建独立服务时更具可扩展性和可移植性。团队可以使用微服务更轻松地更新代码,为不同的组件使用不同的堆栈并独立地扩展组件,从而减少因单个功能可能面临过多负载而必须扩展整个应用程序相关的成本浪费。由于微服务之间的独立性,它的容错性更好。
总结一下,微服务强调的主要特性有:
很明显可以看出,微服务和SOA架构强调的一些主要能力是相似的,微服务在SOA之上发展出了一些新的关注特性。
1、标准化与自由
我想这应该是这两种架构方法最大的区别。SOA架构的方法论即便从现在来看也是非常先进的,只是当初实现SOA的规范定义过于严格,导致整体架构实现过于复杂,例如构建于SOAP之上的ESB、SDO等,都让SOA的门槛变得更高,大公司还可以撑得住,小公司基本上很难驾驭。
它有点像EJB,虽然设想非常美好,但是脱离了人民群众,一旦不能被普遍应用,那么最终只能成为少数人的实验室用品。
微服务和SOA架构最大的区别在于,微服务是更加自由的架构风格,而SOA则为了实现大一统的架构定义出了更多的标准和约束,所以微服务有各种各样的实现形式,例如springcloud、dubbo、service mesh等,即便一个RPC也可以有gRPC、dubbo等各种各样的框架实现。
微服务要发展就必须脱离SOA强约束的标准,但是微服务的很多思想又脱胎于SOA,所以我觉得说微服务是SOA的一个变种,但是新时期的微服务不是SOA(不要贴上SOA)的标签也许是更合适的。
2、数据和存储
在SOA中,多个应用程序涉及到的数据,其要求是直接在其主要数据来源进行数据获取和更改,且通常抽象出所有服务共享的单个数据存储层,减少数据维护和重复。
而微服务则一般要求每个微服务都可以独立访问它所需要的数据,甚至有独立的数据库集群,复杂性变高了,但是耦合性、弹性、扩展性变得更好了。
3、通信
在微服务架构中,每个服务都是独立开发的,有自己的通信协议,可以是同步亦可以是异步;而对于 SOA,每个服务都必须共享一个称为企业服务总线 (ESB) 的通用通信机制,通常服务间的调用是同步的,SOA 管理和协调它通过 ESB 交付的服务。然而,ESB 可能成为整个企业的单点故障,如果单个服务变慢,整个系统都会受到影响。
4、重用
在 SOA 中,服务的可重用性是架构追求的主要目标,可以基于可重用模块快速构建应用;而在微服务中,则更加强调敏捷和弹性,更倾向于通过复制和接受数据重复来重用代码,实现解耦。
5、应用场景
SOA适合庞大、复杂、异构的企业级系统;而微服务更适合快速、轻量的互联网服务,微服务也常常和Devops结合起来。