文章目录

SOA(Service Oriented Architecture)面向服务的架构,探索大概始于 2000 年,概念产生可能更早一些,它是一种架构风格,设计方法,其中包含多个服务, 服务之间通过相互依赖最终提供一系列的功能。一个服务 通常以独立的形式存在与操作系统进程中,各个服务之间 通过网络调用。也是指为了解决在inernet环境下业务集成的需要,通过连接能完成特定任务的独立功能实现的一种软件系统架构

ESB(企业服务总线),指的是传统中间件技术与XML、Web服务等技术结合的产物。是SOA技术架构落地的一个基本部件,现在我们说的SOA集成平台基本都需要有ESB组件,ESB最基本功能即是实现点对点集成到总线式集成的转换,在这个过程中实现了消息协议的转换和适配,数据传输,数据转换和映射,路由等基本功能。ESB提供了网络中最基本的连接中枢,是构筑企业神经系统的必要元素。简单来说ESB就是一根管道,用来连接各个服务节点。为了集成不同系统,不同协议的服务,ESB做了消息的转化解释和路由工作,让不同的服务互联互通。

企业服务总线(EnterpriseServiceBus,ESB)是构建基于面向服务体系结构(SOA)解决方案时所使用基础架构的关键部分,是由中间件技术实现并支持SOA的一组基础架构功能。

WebService是一个平台独立的,低耦合的,自包含的、基于可编程的web的应用程序,可使用开放的XML(标准通用标记语言下的一个子集)标准来描述、发布、发现、协调和配置这些应用程序,用于开发分布式的交互操作的应用程序。它一种分布式部署系统的一种模式,意思就是说分布式的部署系统可以采用WebService技术来写相关的接口。是一种技术方面的标准,真正的跨语言,跨平台,提供了标准的服务定义,服务注册,服务接入和访问的方式。

WebService是SOA的一种实现技术。WebService基于两种协议:soap和rest协议,XML,SOAP和WSDL就是构成WebService平台的三大技术。现阶段,我们能看到的大部分SOA系统好像都是 用WebService实现的。但一定要明确,那些把自己能提供的服务包装一下,对外提供一个ws接口,就声称自己是SOA,肯定是错误的,因为他的系统并不一定符合SOA架构。

有网友这么形容SOA,ESB,WebService的关系

SOA是方法论,就像建筑学一样,指导性质的;
ESB是建筑图纸,理顺整个建筑的架构;
Web S是具体的建筑材料,就好像预制板;

大家知道当初 ERP、CRM、OA 之类的信息系统都是一套套部署起来的,不同系统往往由不同的供应商分别开发的,技术差别也很大,各个系统孤零零的,企业于是有了应用集成和数据集成的需求,SOA 就出来了,各个系统对外提供粗粒度的服务供外部系统访问,所有的服务都集中在一个 ESB 上,曾经 SOA 和 SOA 治理是信息化领域的热门话题,然而这种集成方式开发代价大、通信效率低,且有单点故障的风险, 实际上在企业中并没有得到大规模应用。

微服务,Martin Fowler在2014年正式提出了“微服务”的概念,它出现在互联网相当成熟的时代,将功能分解到离散的各个服务当中,从而降低系统的耦合性,并提供更加灵活的服务支持。微服务架构是一种将单个应用程序作为一套小型服务开发的方法,每种应用程序都在自己的进程中运行,并与轻量级机制(通常是HTTP资源API)进行通信。这些服务是围绕业务功能构建的,可以通过全自动部署机制独立部署。这些服务的集中管理最少,可以用不同的编程语言编写,并使用不同的数据存储技术。

来看下网上找到的对微服务架构的一些定义和阐述:

微服务可以在“自己的程序”中运行,并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构(在现有系统中分布一个API)区分开来。在服务公开中,许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能,那么就必须缩小进程范围。在微服务架构中,只需要在特定的某种服务中增加所需功能,而不影响整体进程。

微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。定义中称,微服务是需要与业务能力相匹配,这种说法完全正确。不幸的是,仍然意味着,如果能力模型粒度的设计是错误的,那么,我们就必须付出很多代价。如果你阅读了Fowler的整篇文章,你会发现,其中的指导建议是非常实用的。在决定将所有组件组合到一起时,开发人员需要非常确信这些组件都会有所改变,并且规模也会发生变化。服务粒度越粗,就越难以符合规定原则。服务粒度越细,就越能够灵活地降低变化和负载所带来的影响。然而,利弊之间的权衡过程是非常复杂的,我们要在配置和资金模型的基础上考虑到基础设施的成本问题。

参考文献:

文章目录