精华内容
下载资源
问答
  • esb服务总线
    2020-12-23 06:31:50

    对于ESB服务总线本身的服务状态探测属于APM应用性能监控的一部分内容,在这里不谈完整的APM,包括服务链监控等,而只是谈下对于ESB服务总线如何探测本身服务的可用性。

    首先谈下探测的时效性,是否要做到完全实时,实际上只要我们做到定时探测,而每次探测的时间能够足够短,那么本身就是一种准实时的服务检测。在探测功能实现的过程中,可以做来灵活的配置探测时间间隔,比如每10秒,30秒或者每分钟探测并调用一次服务接口。

    其次再看下探测的范围,对于服务探测范围包括了集成平台本身提供的代理服务,也包括了源端业务系统提供的业务服务。首先应该是探测代理服务,如果代理服务正常那么业务服务一定是正常的;如果代理服务不正常,也不能说就是ESB总线有问题,这个时候应该进一步探测业务服务,以区分出来究竟是ESB总线的问题还是源端业务系统的问题。

    最后说下探测的方式,在前面我曾经谈到过,可以直接访问ESB总线或源业务系统发布的WSDL地址,如果WSDL地址能够正常访问到,就说明业务系统当前状态正常。但是这种方式本身是有问题的,WSDL地址能够访问并不代表业务系统本身的应用中间件部署包,后端的数据库都没有问题。因此最好的方式仍然应该是配置实际检测的服务,同时对于查询,导入等不同的类型都进行配置。同时配置的服务发起对ESB总线和源端业务系统服务的真实调用,对于查询服务本身不会进数据问题不大,而对于导入类服务在输入信息设置的时候可以设置为完整性校验无法通过的数据,这样就不会成功导入并造成目标系统接收到垃圾数据。

    在做服务实例的业务关键字监控功能的时候,引入了Solr全文检索引擎来实现全消息报文的业务关键字查询,比如输入完整的采购订单号,可以快速的检索出在消息报文中出现过该订单号的所有服务实例信息。这也为后续做端到端业务监控,服务链监控提供了很好的底层能力。即服务链监控本身就可以依赖于底层的业务关键字查询能力来实现。

    在ESB总线上原有功能上,已经实现了两个关键功能,其一是服务定时任务功能,即可以将服务服务配置为定时任务,根据预设的条件自动执行和运行。其二是实现了服务自动化测试功能,即可以对ESB总线部署的服务进行自动化测试,对于数值,日期等都给出默认值进行。可以看到这两个功能点一结合,完全就可以用来做服务定时的自动化探测功能。

    可以在定时任务执行处进行服务配置,配置哪些服务需要定时执行,同时对定时执行的任务给出输入默认参数,同时设置服务定时执行的时间间隔。这样基本就完全复用了平台已有的功能能力。

    对于服务运行探测出现错误或异常的信息,完全可以在服务日志监控处查询,当然也可以单独做一个服务状态探测状态查询功能,可以按提供系统,时间等条件来查询和分析服务探测的异常情况。另外对于服务运行状态探测,如果出现服务运行异常,最好的方式仍然是要直接发送邮件或短信通知系统管理员,以方便系统管理员第一时间对异常情况进行处理。

    如果是一个完整的APM性能监控产品,实际上在做应用性能监控前,最重要的就是应用状态监控,而这里面应该包括应用系统提供的服务状态监控。因此APM产品最好是包括上面谈到的这个功能,即可以在APM中配置需要监控哪个业务系统的哪个服务接口,具体监控的时间周期,调用的初始化输入参数等。这样的话基本上通过配置的方式就可以完成对业务系统提供服务的实时探测和监控。

    更多相关内容
  • WSO2ESB安装部署说明,详细操作使用说明,图文教程
  • 架构演进,单体架构、分布式架构、SOA架构、微服务架构,中台架构。ESB企业服务总线、API网关 详细大总结,

    1架构演进

    架构十五年:改变的是形态,不变的是目的

    业务驱动架构形态变化

    过去十几年,随着互联网发展以及业务的多样化,系统的架构也在不断发生变化,总体上来说大体经历了从单体应用架构-垂直应用架构-分布式架构-SOA架构-微服务架构的演变,当前各大企业都在朝着数字化转型和云原生方向前进。

    业务驱动与基础设施的进化推动架构发展

    “架构要解决业务需求的问题,业务需求的变化驱动着架构的进化”。谭待在采访时说道。从互联网的角度出发,结合业务的主要变化,国内软件架构这15年的发展大致
    可以分为三个阶段。

    第一阶段,互联网正式爆发。这一阶段的特点是网页与用户数据的迅速增多,无论是当时流行的搜索引擎、社交网络,还是工业、电商等行业,互联网的爆发带来的数据量是传统的单机和简单的架构模式无法支持的,传统的架构也无法解决相应的业务问题。因此,软件架构就慢慢从原来的单机系统演变成分布式系统以解决新业务形态带来的问题,诸如在架构层面考虑容错、负载均衡等问题。同时需要注意的是,也正是这个时候开启了后来所谓的大数据时代。

    第二阶段, 移动互联网的兴起。移动互联网兴起之后,互联网业务的形式又随之发生了比较大的变化。PC互联网时代比较典型的一个例子就是搜索引擎,搜索引擎对时效性要求并不是特别高,对用户来说只要能找到所需要的内容即可,不追求实时在线,这个时候架构更多解决的是吞吐量大的问题。移动时代则不同,推荐、个性化服务已经成为更主流的方式,业务的场景也变成了对实时性要求非常高的情况。

    这一阶段架构方面主要的变化就是计算从以前的批量计算变成了流式计算,数据处理从离线变成实时,比较典型的例子就是Hadoop到Spark,再到后面Flink的变化。这其中的变化就涵盖了系统架构对用户数据的处理、文档数据的处理、推荐、广告算法等等,这个时期业务对架构的范式要求更高。另外,这一时期硬件等基础设施的大幅提升与大规模的应用,也对架构的演进起到了非常大的推动作用。

    第三阶段,云原生时代。也就是当下,企业上云对许多公司来说已经变成一种默认行为。这个时候业务架构就需要基于云原生进行改造,如何基于云组件做适配,如何合理使用云的弹性、计算存储分离等功能也变的至关重要。如果继续使用老的业务架构跑在云上,那无异于“拉着马车跑在高速公路上”。

    云原生出现之后还衍生了一个有趣的现象,在云原生到来之前,企业软件架构与互联网软件架构是分离的,现在这两者已经开始慢慢交融在一起。传统的厂商需要进行数字化转型,其面临的业务需要互联网化,要解决高并发、大吞吐等问题,势必要采用互联网架构。互联网公司经过多年的发展壮大,内部运营管理上也会面临传统企业的问题,比如如何解决开发效率,如何解决新老系统并存,如何进行数据打通等等。总的来说,业务场景的需求变化驱动着架构的演进。PC互联网时代、移动互联网时代、云原生时代(数字化转型时代)的业务需求是不同的,也就对不同时期的架构提出了更多的要求。另外软硬件等基础设施的创新和开源价值的体现等也都对架构的演进起到了非常大的助推作用。

    1.1单体架构

    单体架构是今天绝大多数软件开发者都学习、实践过的一种软件架构,许多介绍微服务的图书和技术资料中也把这种架构风格的应用,称作“巨石系统”(Monolithic Appplication)。
    在这里插入图片描述

    概述

    (1) 单体架构在整个软件架构演进的历史进程里,出现的最早、应用范围最广、使用人数最多、统治时间最长的一种架构风格。

    (2) 但单体这个名称,是在微服务流行之后,“事后追认” 所形成的的概念。此前,没有多少人将“单体”看作一种架构。很少有教如何开发单体架构的开发资料。这一方面体现单体架构的简单性,另外一方面体现出在相当长时间里,大家已经习惯了软件架构就是单体的这种样子。

    (3) 单体不一定就不好,一般有问题的是“大型单体系统”,而不是小型单体系统。
    对于小型系统,单台机器足以支撑起良好的运行系统,不仅易于开发、测试、部署,而且系统中各个功能、模块、方法的调用都是进程内调用,不会发生进程间通信(Inter-Process Communication, IPC),因此,运行效率也是最高的。

    (4) 单体系统的不足,必须在软件的性能需求超过了单机、软件人员规模明显超过了“2张披萨”(2 Pizza Team)范畴前提下才有讨论的价值。

    (5) 单体系统一般也是分层的。分层架构(Layered Architecture)是现在所有系统中普遍认可,采用的软件设计方法,无论是单体还是微服务,亦或是其他架构风格,都会对代码进行纵向层次划分。 如果常见的:表示层-》业务层-》持久层-》数据库层,像目前很多传统企业都在用的SpringMVC框架、SSH框架、SSM框架等都可以发布到单体服务器进行应用。
    在这里插入图片描述

    (6) 另外,单体架构也支持按照技术、功能、职责等维度,将软件拆分为各种模块,以便重用和管理代码。单体系统并不意味只有一个整体的程序封装形式,如果需要,它完全可以由多个JAR,WAR,DDL,Assembly 或者其他模块格式来构成。即使从横向扩展(Scale Horizontally)角度衡量,在负载均衡器之后同时部署若干个单体副本系统,以达到分摊流量压力的效果。

    单体架构的优缺点

    1、优点

    单体系统所有代码运行在同一个进程内,所有模块、方法的调用都无须考虑网络分区、对象复制的性能损失。进程内的调用简单、高效。发布、部署简单,方便运维。

    2、缺点

    (1)任何一部分代码出现缺陷,过度消耗进程空间内的资源,所造成的营销也是全局性的,难以隔离的。项目大而笨重,改动一处都要进行重新打包、发布。

    (2)譬如:内存泄露、线程爆炸、阻塞、死循环等问题,不仅仅影响某个一个功能、模块的正常运作,还会影响整个程序。

    (3)如果出问题的是某些更高层次的公共资源,譬如端口号或者数据库连接池泄露,还将会影响整台机器甚至集群中其他单体副本的正常工作。

    (4)由于隔离能力的缺失,单体难以阻断错误传播、不便于动态更新程序。还面临难以技术异构的困难,每个模块的代码通常都需要使用一样的程序语言,乃至一样的框架去开发。

    微服务取代单体的最重要原因:单体系统架构风格要求每一个部件、每一处代码都尽量可靠,尽量不出或少出缺陷。然而,当系统规模越来越大时,交付一个可靠的单体系统就变得越来越具有挑战性。软件架构的演进,构建可靠系统的观念“追求尽量不出错”到正视“出错是必然”的转变,才是微服务架构得以挑战并逐步取代单体架构的主要原因。
    允许程序出错,获得自治与隔离能力,以及可以实现技术异构等目标,是继性能与算力之后,让程序再次选择分布式的理由。SOA 就是曾经的探索过的方法之一。新旧世纪之交(20世纪-21世纪)用来对一个大的单体系统拆分为若干个更小的,不运行在同一进程的独立服务,这些服务的拆分方法后来带来了面向服务架构的一段兴盛期。

    1.2 分布式架构

    分布式系统是将一个大的系统划分为多个业务模块,这些业务模块会分别部署到不同的机器上,通过接口进行数据交互。严格意义上来说,它属于是部署层面的架构思想,但是它也属于我们后面所说的微服务。
    这种做法的好处是,可以提高系统的运算能力。与分布式系统相对应的就是 单体应用系统,单体应用系统的思想是all in one 思想, 就是全部在一起,一个系统的全部服务都集中在一个网络节点上。
    在这里插入图片描述

    集群

    从分布式部署架构上延伸出来的集群概念:所谓集群就是,相同的事情多个人做,比如在上图分布式系统中, 商品服务 被部署到一台机器上,但是如果在购物节时,请求太多,一台机器根本扛不住,这时我们也增加10台机器,这10台机器都部署 商品服务, 这样由这10台机器就组成了商品服务集群,集群的初衷就是提高系统的吞吐量,另一个就是提高可用性,比如一台服务器挂了,不至于服务不可用。

    缺点

    虽然分布式架构能解决一系列问题,但是它经常和后面说的SOA、微服务架构结合使用,分布式架构是从软件部署层面来描述的。它固然也存在很多复杂的问题,如,事物一致性等。

    1.3 SOA架构

    SOA 全称是: Service Oriented Architecture,中文释义为 “面向服务的架构”,它是一种设计理念,其中包含多个服务, 服务之间通过相互依赖最终提供一系列完整的功能。各个服务通常以独立的形式部署运行,服务之间通过网络进行调用。它是一种在计算机环境中设计、开发、部署和管理离散模型的方法。SOA不是一种新鲜事物,它是在企业内部IT系统重复构建以及效率低下的背景下提出的。在SOA模型中,所有的功能都被定义成了独立的服务,所有的服务通过服务总线(ESB)或流程管理器来连接。这种松散耦合的结构使得能够以最小的代价整合已经存在的各种异构系统,当然,由于需要实现对各种异构系统的适配(通常使用ESB来完成不同系统之间的协议转换及数据格式转换),因此,其本身也会引入更多的复杂性。

    实施 SOA 的关键目标是实现企业 IT 资产的最大化作用。要实现这一目标,就要在实施 SOA 的过程中牢记以下特征:可从企业外部访问、随时可用、粗粒度的服务接口分级、松散耦合、可重用的服务、服务接口设计管理、标准化的服务接口、支持各种消息模式、精确定义的服务契约。
    在这里插入图片描述
    服务消费者(Service Consumer)可以通过发送消息来调用服务,这些消息由一个服务总线(Service Bus)转换后发送给适当的服务实现。这种服务架构可以提供一个业务规则引(Business Rules Engine),该引擎容许业务规则被合并在一个服务里或多个服务里。这种架构也提供了一个服务管理基础(Service Management Infrastructure),用来管理服务,类似审核,列表(billing),日志等功能。此外,该架构给企业提供了灵活的业务流程,更好地处理控制请求(Regulatory Requirement),例如 Sarbanes Oxley(SOX),并且可以在不影响其他服务的情况下更改某项服务。

    SOA所要解决的核心问题

    系统间的集成 : 我们站在系统的角度来看,首先要解决各个系统间的通信问题,目的是将原先系统间散乱、无规划的网状结构,梳理成规整、可治理的星形结构,这步的实现往往需要引入一些概念和规范,比如 ESB、以及技术规范、服务管理规范; 这一步解决的核心问题是【有序】。

    系统的服务化 : 我们站在功能的角度,需要把业务逻辑抽象成可复用、可组装的服务,从而通过服务的编排实现业务的快速再生,目的是要把原先固有的业务功能抽象设计为通用的业务服务、实现业务逻辑的快速复用;这步要解决的核心问题是【复用】。

    业务的服务化 : 我们站在企业的角度,要把企业职能抽象成可复用、可组装的服务,就要把原先职能化的企业架构转变为服务化的企业架构,以便进一步提升企业的对外服务的能力。“前面两步都是从技术层面来解决系统调用、系统功能复用的问题”。而本步骤,则是以业务驱动把一个业务单元封装成一项服务。要解决的核心问题是 【高效】。

    SOA架构的时代特性

    SOA软件架构时代,包含了许多概念、思想,在今天的微服务中有能找到对应的身影,譬如:
    服务之间的松散耦合、注册、发现、治理、隔离、编排等。
    SOA 对这些问题,包括“软件开发”,都指导的更具体,更系统,如下:

    更具体:
    SOA本身属于抽象概念,不是某一种具体的技术
    1、比**单体架构、烟囱式架构(Information Silo Architecture)、微内核架构 (Microkernel Architecture)、事件驱动架构(Event-Driven Architecture)**操作性更强。
    2、不能简单的认为是一种架构风格,更是一套软件设计的基础平台
    3、有清晰的指导原则:eg:服务的封装性、自治、松耦合、可重用、可组合、无状态等等
    4、采用SOAP作为远程调用协议,依靠SOAP协议族(WSDL、UDDI和WS-*协议)来完成服务的发布、发现和治理。
    5、利用ESB企业服务总线(Enterprise Service Bus,ESB)的消息管道来实现各个子系统之间的交互,令各服务在ESB的调度下无须相互依赖就能相互通信,实现了服务的松耦合,也为后续进一步实现业务流程编排(Business Process Management,BPM)提供了基础。
    6、使用服务数据对象(Service Data Object, SDO)来访问和表示数据
    7、使用服务组件架构(Service Component Architecture, SCA)来定义服务封装的形式和服务运行的容器。

    更系统:
    SOA终极目标希望总结出一套自上而下的软件研发方法论,做到企业只需要跟着SOA的思路,就能一揽子解决掉开发过程中的全部问题。譬如:该如何挖掘需求、如何将需求分解为业务能力、如何编排已有服务、如何开发/测试/部署新的功能等。
    SOA还关注研发过程涉及的需求、管理、流程和组织。
    SOA 21世纪最初的10年里曾盛行一时,有IBM等一众行业巨头厂商为其呐喊冲锋,吸引了不少软件开发厂商,尤其企业级开发商,但最终还是偃旗息鼓,沉寂下去。

    SOAP协议被逐渐边缘化的原因:

    简单说就太复杂了。
    过于严格的规范定义带来过度的复杂性,而构建在SOAP基础上的ESB、BPM、SCA、SDO等诸多上层建筑加剧了这种复杂性。
    过于精密的流程和理论需要懂得复杂概念的专业人员才能驾驭。
    可以实现多个异构大型系统之间的复杂集成交互,却很难作为一种广泛普适性的软件架构风格来推广。

    SOA架构思想过时么?

    答案 NO!!!,因为Apache Dubbo 框架便是这种思想。

    1.4 微服务架构

    概述

    微服务是基于分而治之的思想演化出来的。过去传统的一个大型而又全面的系统,随着互联网的发展已经很难满足市场对技术的需求,于是我们从单独架构发展到分布式架构,又从分布式架构发展到 SOA 架构,服务不断的被拆分和分解,粒度也越来越小,直到微服务架构的诞生。微服务架构是一种架构模式,它提倡将单一应用程序划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。

    每个服务运行在其独立的进程中,服务和服务间采用轻量级的通信机制互相沟通(通常是基于 HTTP 的 RESTful API)。每个服务都围绕着具体业务进行构建,并且能够被独立地部署到生产环境、类生产环境等。另外,应尽量避免统一的、集中式的服务管理机制,对具体的一个服务而言,应根据业务上下文,选择合适的语言、工具对其进行构建。

    和SOA架构简单比较
    1、 微服务是一种SOA思想的延续,任然关注服务,但是强调是"微",微体现的是服务开发成分要低,职责要尽量单一,同时部署也要灵活方便。目前微服务是非常流行的一种软件架构,在Java生态中 SpringCloud就提供了微服务的全站解决方案。

    2、微服务是真正的分布式的、去中心化的。把所有的“思考”逻辑包括路由、消息解析等放在服务内部,去掉一个大一统的 ESB,服务间轻通信,是比 SOA 更彻底的拆分。

    3、微服务架构强调的重点是业务系统需要彻底的组件化和服务化,原有的单个业务系统会拆分为多个可以独立开发,设计,运行和运维的小应用,这些小应用之间通过服务完成交互和集成。
    在这里插入图片描述
    和分布式架构的简单比较
    微服务架构和分布式架构的区别是部署方式不一样。分布式是将一个大的系统划分为多个业务模块,这些业务模块会分别部署到不同的机器上,通过接口进行数据交互。微服务的应用可以部署在是同一个服务器,不一定是分散在多个服务器上。微服务架构是一项在云中部署应用和服务的新技术。微服务架构是一种架构模式,它将一个复杂的大型应用程序划分成多个微服务,这些小型服务都在各自独立的进程中运行。

    1.5 微服务架构与SOA架构的区别

    本小节内容参考自:https://www.toutiao.com/article/6919733527265182219/?channel=&source=search_tab&wid=1660266617488

    SOA本身的定义: SOA是一种架构方法,将传统的单片式应用打破,分解为离散的、自治的业务服务,利用标准提升他们的互操作性,从而可以更好地共享、重用和组装,快速构建复合的应用从而满足业务需求的变化。
    在这里插入图片描述

    在面对企业遗留IT系统架构的时候,SOA本身实际也是做两个重要的事情,其一是找到各个遗留系统共性的可复用的业务能力;其次就是在构建上层业务流程的时候通过服务组装和编排来完成。
    因此SOA更多的是一种架构思想,进一步总结是:基于遗留系统已有可复用的能力,分层组装的方式来构建上层业务应用。

    只要我们在架构设计的时候符合这个思想即是SOA。

    在谈SOA的时候一般会将SOA和ESB服务总线结合起来谈。即认为SOA即是一个类似ESB总线的进行业务系统间接口集成和统一管控的集成平台。

    而ESB总线仅仅是实现SOA架构思想的一个工具,在前面谈SOA架构思想谈到一个是识别可重用的接口服务并统一管理,这个即是需要ESB总线来完成;另外一个就是对可复用的服务进行服务组装或编排,而这个能力往往通过BPEL或BPM来完成。如下图所示:
    在这里插入图片描述
    即SOA架构思想的实现涉及到ESB总线和BPM产品的使用。同时接口的识别和定义是依托在遗留IT系统已有的能力暴露,而不是新产生的能力。

    因此ESB总线一般也用于多个遗留系统之间的接口服务集成和统一管理。

    从SOA到微服务

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

    SOA和微服务的区别,即:

    微服务架构强调的第一个重点就是原来的单体业务系统需要彻底的组件化和服务化,原有的单个业务系统会拆分为多个可以独立开发,设计,运行和运维的小应用。这些小应用之间通过服务完成交互和集成。每个小应用从前端web ui,到控制层,逻辑层,数据库访问,数据库都完全是独立的一套。在这里我们不用组件而用小应用这个词更加合适,每个小应用除了完成自身本身的业务功能外,重点就是还需要消费外部其它应用暴露的服务,同时自身也将自身的能力朝外部发布为服务。

    如果一句话来谈SOA和微服务的区别,即微服务不再强调传统SOA架构里面比较重的ESB企业服务总线,同时SOA的思想进入到单个业务系统内部实现真正的组件化。

    对于微服务实际本身又强调了几个重点,简单总结如下:

    • 拆分后的微服务从数据库,逻辑层到前端都完全独立松耦合。
    • 微服务间通过轻量HTTP API接口交互。
    • 微服务间以去中心化方式调用,不需要中心化总线平台。

    上面三点实际上是我们谈微服务的时候经常会谈到的三点。而对于微服务这个概念本身实际包括了微服务模块和微服务API接口两个部分内容,即:

    传统单体=拆分多个微服务(微服务模块+暴露Http API接口)

    当谈微服务的时候一定是和传统的单体应用对比来说的,如果没有传统单体应用,也没有当前的微服务的概念。单体应用太大,太重了所以需要拆分,同时拆分微服务还需要通过轻量高性能的接口完成交互和协同。

    当把这个理解清楚后,你会看到SOA和微服务实际出发点和目标完全是不同的,虽然两者都会针对传统的单体应用或遗留系统来谈,但是要达到的效果不同。

    • SOA和ESB:遗留单体应用暴露可复用接口,并通过接口完成多系统集成。
    • 微服务:遗留单体应用进行拆分,拆分为多个微服务,再去中心化集成。

    如果从一个单体应用改造为微服务,那么微服务将通过类似服务注册中心等去中心化的方式完成集成。但是如果一个单体应用需要类似APP应用等前端访问,往往仍然需要一个统一的代理网关来对外暴露接口,这个即常说的API网关。

    API网关可以理解为一个轻量的ESB总线能力实现。

    API网关不仅仅实现了服务代理和API接口的位置透明,同时也实现了类似服务安全,限流熔断,日志,监控等关键的服务治理管控能力。

    SOA是否过时?

    再回到这篇文章的主题,即在微服务和云原生时代,微服务是否过时的问题。在前面已经解释了SOA和微服务的一些概念和区别。实际上你会看到SOA和微服务反而不是同一个层面的两个概念。原来业务系统构建中的组件化才是和微服务对等的一个概念。

    在云计算不断发展演进过程中,整个IT架构也在不断地发展演进,新的技术也在层出不穷,有些老的技术过时也是常见现象。但是当前实际是很多人连SOA是什么都还没有搞清楚,就在说SOA已经过时,这种人就是典型的追热点,炒概念的人。

    包括最近已经听到很多人在说中台过时了,阿里在拆中台了,同样这些人连中台究竟是什么?中台思想本质在哪里都没有搞清楚就在批评中台。包括有些提供中台服务的厂商,把中台吹得天花乱坠,无所不能,结果一到了客户内部最终建设实施发现无法落地,发现原来的业务问题同样无法解决,反而引入了更加难以管理的IT复杂度。

    任何一个概念重点是理解思想,基于思想来考虑如何应用和落地实践。

    对于SOA,经常看到的过时说法主要包括如下几点:

    • 微服务是去中心化的,SOA还是中心化集成老架构。
    • 微服务是Http API轻量接口,SOA下还是SOAP WS接口。
    • SOA和ESB很重并紧耦合,而微服务下轻量集成并松耦合。

    当然还有其他的一些说法,重点都是在强调SOA中心化,SOA架构是很重的架构不再能够灵活地适应业务变化和扩展。

    因此,基于以上问题,再逐一展开分析和描述。

    ESB总线和API网关

    在这里插入图片描述
    注意API网关本身也是一个中心化的API接口集成架构。

    在微服务架构体系下本身是去中心化的架构,通过服务注册中心来实现服务注册发现和消费调用,那么为何又需要使用API网关?

    在传统的ESB总线进行服务集成的时候我们就经常谈到一个概念就是位置透明,即需要屏蔽底层业务模块提供API接口服务地址信息,并实现多个微服务API接口的统一出口。即类似设计模式里面经常谈到的门面模式。

    如何给API网关一个定义?

    简单来说API网关就是将所有的微服务提供的API接口服务能力全部汇聚进来,统一接入进行管理,也正是通过统一拦截,就可以通过网关实现对API接口的安全,日志,限流熔断等共性需求。如果再简单说下,通过网关实现了几个关键能力。

    内部的微服务对外部访问来说位置透明,外部应用只需和网关交互
    统一拦截接口服务,实现安全,日志,限流熔断等需求

    从这里,我们就可以看到API网关和传统架构里面的ESB总线是类似的,这些关键能力本身也是ESB服务总线的能力,但是ESB服务总线由于要考虑遗留系统的接入,因此增加了:

    大量适配器实现对遗留系统的遗留接口适配,多协议转换能力
    进行数据的复制映射,路由等能力

    对于两者,我原来做过一个简单的对比,大家可以参考。
    在这里插入图片描述
    因此一个应用内部的微服务模块之间可以去中心化集成,但是这个应用需要和传统的遗留IT系统,需要和外部APP等进行接口集成的时候,往往就需要借助API网关的能力来完成。

    API网关本身也是中心化的架构。

    即使对于一个应用内部,只要存在类似外部APP前端需要访问后端服务接口,那么就引入了API网关,整个架构就很难说是一个完全意义上的去中心化架构。

    因此,简单地说微服务完全去中心化,这个说法是不成立的。

    新老架构并存时仍然需要ESB总线

    同时在微服务架构实施过程中,一个微服务应用本身还需要和传统的遗留IT系统之间集成,只要还存在这种传统的遗留IT系统,那么这种集成场景就存在,仍然需要通过类似ESB总线或轻量的SOA服务总线来完成接口集成和管控工作。

    我们以一个集成场景来进行说明,即企业遗留系统集成采用ESB服务总线,而对于新建设的一个微服务应用采用API网关,那么就存在两者协同和集成的过程,整体集成架构如下:
    在这里插入图片描述
    可以看到,在这种集成架构下,微服务整体应用系统中所有的需要和遗留系统交互的接口全部首先接入和注册到API网关,同时API网关暴露的服务进一步集成和注册到ESB服务总线,形成两级服务集成的方式。

    在这种两级服务集成模式下好处包括

    微服务应用体系里面的各个微服务仅仅需要暴露特定的API接口到网关和ESB
    内部微服务间的Rest API交互仍然可以走注册中心,而且对外透明
    可以进一步使用ESB总线协议转换和适配能力,完成SOAP和Rest接口转换和适配
    虽然两级集成模式下增加了一定的性能损耗,也拉长了整个服务调用链路。但是在新旧架构并存的过程中,这种两级集成仍然是我们推荐采用的方式。既满足了微服务应用内部的微服务治理要求,又实现了和外围系统间的集成。

    全微服务化应用构建场景

    在这里插入图片描述
    接着再谈下如果一个企业所有的IT系统都全新构建,同时都采用微服务架构方式进行构建。那么这个时候是否可以做到完全意义上的去中心化架构,所有的微服化间都通过注册中心去中心化的方式调用和集成。

    对于企业信息化来说,即使全微服务化,那么传统应用的虚拟边界还在,这个短期并不能马上改变。即类似供应链应用,合同应用,HR应用都采用微服务架构开发,但是这个应用的虚拟边界还在,这个应用边界存在的作用包括了:

    • 通过应用需要划分不同的开发组织或开发团队。
    • 应用之间是粗粒度的API接口集成,而非整个微服务集成。

    当谈到这里的时候,你会看到仍然存在多个应用之间的集成问题需要解决。这个集成即可以采用轻量的API网关来完成。

    举例来说,合同应用拆分为10个微服务,10个微服务间可以去中心化集成。同时其中有一个APP前端微服务,这个在合同应用建设中引入了微服务网关来解决统一代理和出口问题。同时合同应用自己搭建了服务注册中心,服务限流熔断能力等。

    在合同应用内部,管控的粒度是到微服务粒度即可。

    但是当合同应用需要和供应链应用交互的时候,这个时候不可能将某个合同的微服务模块完全暴露给供应链应用,而是只能够暴露一个个粗粒度的API接口服务。

    如果合同,供应链,HR三个应用只搭建一个类似Eureka服务注册中心,那么三个应用之间的访问和边界将出现完全混淆和不可控。这个不仅仅是安全类问题,也同样存在接口乱用导致的紧耦合集成等问题。

    从一个企业整个IT应用架构来看,打破虚拟应用的边界,做到完全去中心化是一个艰难并漫长的过程。这个涉及到组织级IT管控治理能力成熟度,组织,开发,运维各个过程间的标准规范制定等。

    所以不要简单地说全新架构和全微服务化后,整个应用域就能够做到完全的去中心化。实际上每个应用之间仍然难以去中心化,最佳的方式仍然是通过API网关或SOA总线来完成集成和交互。

    SOA思想从来没有过时

    对于SOA来说,重点不是ESB总线引擎,而是SOA参考架构思想。SOA架构思想里面虽然也有遗留系统的适配和集成,但是更加重要的是从传统的竖向应用构建思路转变为横向分层构建思路,同时抽取和识别可重用服务,通过服务组装来满足上层业务应用。

    在谈中台的时候我就指出过,中台思想实际上SOA思想和微服务两者的融合。为何这样讲,我们来讲中台思想和中台实现两个层面来说。

    • 共性可复用业务能力下沉,并提供给前台应用使用=》SOA思想
    • 共性能力构建时候尽量大拆小,可扩展,松耦合=》微服务思想

    当前互联网企业谈的中台基本就是SOA架构思想和微服务两者的一个融合,既体现了共性业务能力下沉,又体现了共性能力要大拆小的微服务方式构建。如下图:
    在这里插入图片描述
    当我们理解了这个核心概念后,我们才能够认识到如下几点关键认识。
    中台是一个业务层面概念,微服务是一个技术层面概念。中台核心仍然是共性业务能力下沉和复用,只是互联网企业在实现中台架构的时候,将中台技术实现和微服务做了融合。

    因此企业内业务中台实现,只要满足共性业务能力统一提供给上层使用,即使底层提供能力的仍然是传统遗留业务系统,那么也可以将构建了一个业务服务能力中台。

    同时也可以看到微服务仅仅是中台中应用到的一个技术实现,你可以在很多非中台场景下采用微服务,小到原来一个业务系统拆分后全新构建这种场景。

    在中台构建中,中台和前台之间实际还需要一个中台提供的API接口服务的组装和编排层,也可以理解为进一步的领域服务整合能力,而这个服务组合层,实际上和前面谈到SOA里面的服务组装编排思想是完全一致的。

    在这里插入图片描述
    当重新思考中台这个概念的时候,你会发现中台本质还是SOA架构思想。在我们最终规划和建设SOA集成平台,ESB总线的时候就希望构建一个企业内部的服务能力共享平台,为新的应用构建提供可复用接口服务能力。

    这个和当前中台思路是完全一致的。也就是说企业传统SOA架构规划实施中都难以落地实施的事情,绝对不是简单地将概念包装为中台就能够落地的,包括当前中台还涉及到传统IT架构的微服务化,更加难以推进。这个也是大量中台项目建设失败或夭折的原因。

    结语

    最后简单总结下前面谈到的内容,即:

    SOA架构思想从来就不存在过时的说法,同时当企业存在遗留IT系统,包括遗留IT系统逐步迁移和微服务的情况,往往同时存在ESB服务总线和API网关并存的情况。或者也可以采用ESB总线来提供API网关应该具备的能力。

    随着这个技术发展,企业IT治理管控能力加强,云原生整体技术推进,治理能力的提升,才可能逐步做到完全的去中心化架构。

    我们实施了很多大型的SOA集成平台和ESB总线项目,同时也实施了微服务架构规划咨询和迁移类项目,更加认为企业IT架构微服务化是一个漫长过程,一定要围绕业务目标驱动,逐步迁移和演进,最终达到一个目标架构。

    1.6 SOA架构的分析案例

    SOA落地方式

    SOA的落地方式与水平,跟企业IT特点、服务能力和发展阶段直接相关。目前常见的落地方式主要有分布式服务化和集中式管理两种。

    1.分布式服务化

    互联网类型的企业,业务与技术发展快,数据基数与增量都大,并发访问量高,系统间依赖关系复杂、调用频繁,分布式服务化与服务治理迫在眉睫。通过统一的服务化技术手段,进一步实现服务的注册与寻址、服务调用关系查找、服务调用与消息处理监控、服务质量与服务降级等等。现有的一些分布式服务化技术有dubbo(基于java)、finagle(基于scala)和ICE(跨平台)等。

    2.ESB集中式管理

    传统企业的IT内部遗留系统包袱较重,资源整合很大一部分是需要打通新旧技术体系的任督二脉,所以更偏重于以ESB作为基础支撑技术,以整合集成为核心,将各个新旧系统的业务能力逐渐的在ESB容器上聚合和集成起来。比较流行的商业ESB有IBM的WMB和oracle的osb,开源esb有mule、servicemix、jbossesb、wso2esb和openesb。

    1.7 总结

    基于架构的演进这里做个整体概述,我们知道还有一个比较出名的框架,即 Apache Dubbo ,它是一个分布式的Rpc 框架,毕竟RPC就是为了解决分布式架构中的服务之间的通信、应用与服务之间的通讯问题。

    Apache Dubbo 背景及需求

    以下内容摘自官网:https://dubbo.apache.org/zh/docsv2.7/user/preface/background/

    随着互联网的发展,网站应用的规模不断扩大,常规的垂直应用架构已无法应对,分布式服务架构以及流动计算架构势在必行,亟需一个治理系统确保架构有条不紊的演进。

    在这里插入图片描述

    单一应用架构

    当网站流量很小时,只需一个应用,将所有功能都部署在一起,以减少部署节点和成本。此时,用于简化增删改查工作量的数据访问框架(ORM)是关键。

    垂直应用架构

    当访问量逐渐增大,单一应用增加机器带来的加速度越来越小,提升效率的方法之一是将应用拆成互不相干的几个应用,以提升效率。此时,用于加速前端页面开发的Web框架(MVC)是关键。

    分布式服务架构

    当垂直应用越来越多,应用之间交互不可避免,将核心业务抽取出来,作为独立的服务,逐渐形成稳定的服务中心,使前端应用能更快速的响应多变的市场需求。此时,用于提高业务复用及整合的分布式服务框架(RPC)是关键。

    流动计算架构

    当服务越来越多,容量的评估,小服务资源的浪费等问题逐渐显现,此时需增加一个调度中心基于访问压力实时管理集群容量,提高集群利用率。此时,用于提高机器利用率的资源调度和治理中心(SOA)是关键。

    **结语:**架构的演进或多多少都离不开SOA架构的思想,了解各种架构的关系、了解服务编排与治理,才能更好的设计出自己企业合适的架构。

    参考资料:

    【1】https://www.pdai.tech/md/arch/arch-x-service.html
    【2】https://blog.csdn.net/asdcls/article/details/122162652
    【3】https://www.leixue.com/ask/what-is-the-difference-between-microservice-architecture-and-distributed-architecture
    【4】https://zhuanlan.zhihu.com/p/336649999
    【5】https://mp.weixin.qq.com/s?__biz=MzkyNTI5NTQ1NQ==&mid=2247499596&idx=1&sn=42744e9b34aacc96d53737b82582ae87&source=41#wechat_redirect
    【6】https://www.toutiao.com/article/6919733527265182219/?channel=&source=search_tab&wid=1660266617488

    展开全文
  • 普元ESB服务总线产品

    2017-03-22 13:49:35
    Primeton ESB®是普元基于多年对大型企业的IT建设及分布式计算和集成能力的认识和技术积累而推出的服务整合产品,是部署和实现SOA的理想工具。主要用于企业内及企业间的服务整合,通过总线形式有效改善现有系统之间...
  • ESB服务总线改进

    2020-12-30 21:20:53
    对于消息中间件部分进行单独剥离,即讲服务设计和ESB协议转换和适配部分同消息中间件分离,对于消息中间件部分初步考虑采用RabbitMQ或zeroMQ来实现,其中zeroMQ由于用c语言实现,相当来说更加轻量和高性能。...

    对于消息中间件部分进行单独剥离,即讲服务设计和ESB协议转换和适配部分同消息中间件分离,对于消息中间件部分初步考虑采用RabbitMQ或zeroMQ来实现,其中zeroMQ由于用c语言实现,相当来说更加轻量和高性能。但是RabbitMQ本身更适合做一个企业级的消息系统,其在集群,持久化,高可用性和分布式可扩展性方面往往更加有优势。相当来说RabbitMQ往往是更好的选择。本文引用地址:http://www.eepw.com.cn/article/201612/330512.htm

    对于消息中间件的使用,主要需要实现几个方面的内容,一个是传统MQ的基本功能,即基于消息的异步通讯机制,其次是实现消息发布订阅模式,最后是一个重要功能,即用做ESB内部的消息存储和异步日志记录,通过MQ的异步功能对于日志进行异步持久化以实现ESB层本身的高性能,而不会影响到服务本身调用性能。

    对于数据库可以看到,主要是包括两个方面的内容,其一是对于服务元数据管理部分的内容,其二是对于服务运行实例的持久化内容。其中可以看到对于服务运行实例完全可以采用独立的分布式数据库来存储,由于这种实例运行记录本身就类似key-value的存储模式,因此可以考虑采用mongoDB或redis库来实现这部分数据的存储,个人对于这块倾向于选择redis库来实现即可。

    对于服务总线的管控和治理平台建议是和ESB服务总线进行分离,管控平台部分的核心功能主要还是服务元数据管理,服务目录库,服务运行监控分析,服务安全和访问控制,服务全生命周期管理等基础内容。管控平台数据库可以用结构化的数据库,数据库本身不会有太大的性能瓶颈。

    对于服务设计部份可以引入可视化的服务设计和服务组合,其中核心主要是实现适配器,数据映射转换,日志和异常管理,安全管理,外部接口调用,路由,消息发布订阅等基础设计能力。对于适配器是一个核心基础功能组件,主要需要实现对数据库,SOAP和rest WebService的接入,HTTP服务的接入,JMS消息的适配,FTP文件的适配等基础功能。同时在适配处理过程中实现大数据和大文件传送组件的集成。

    进一步加强服务监控和预警功能,包括对详细SLA服务等级和策略的订阅,对预警策略的定义,能够实现准实时的服务监控和预警。同时在服务视图静态展现上增加服务预警和调用异常的动态实时展示,以帮助管理员更加实时的发现服务运行中的异常。同时增加对ESB服务总线集群的管理功能,其中包括对集群各个节点的监控,对服务部署实现集群化的动态部署,包括服务的热部署能力支持。以提升ESB平台本身的高可用性和可伸缩性。

    可以参考Dubbo服务框架的实现模式,在服务目录库中引入两种服务接入方式,即一种是由ESB来实现服务代理,同时实现服务数据传输映射和运行日志审计;对于其它大数据调用服务为了提升技能,则服务目录中心仅仅是返回可使用的服务调用地址,由服务消费方和提供方进行直接的消息传输通讯。通过两种方式的结合可以更好的兼顾ESB总线的常规能力同时又提升服务总线的性能。

    可以考虑通过本地SDK开发包的引入,进一步来简化服务提供和消费端的代码开发,该模式下虽然整个服务开发和消费过程更加简单,但是本身对业务系统有一定的侵入性,因此也需要慎重采用。

    进一步加强对服务流量控制功能的设计和开发,即根据SLA服务策略可以更加详细的定义服务流量控制策略,包括服务在单位时间的调用次数,服务传送的数据量,同时也包括对于任何一次调用服务本身的数据量控制和预警等,通过服务流量控制一方面是减轻下游接收系统的系统压力,一方面也可以更好的屏蔽和发现各种非法调用。

    可以考虑进一步加强对服务运行日志记录的分析,通过服务运行数据的采集和转换,结合前期总体的业务系统集成架构蓝图规划。可以通过服务消费记录更好的欢迎业务系统间业务系统的情况,这个一方面可以利用来实现业务单据的跨系统传递监控,同时也可以更好的用来实现后续规划的端到端流程监控上。

    展开全文
  • ESB(企业服务总线

    千次阅读 2022-04-21 17:24:05
    ESB全称为Enterprise Service Bus,即企业服务总线。它是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢,是构筑企业神经系统的必要元素。 大规模分布式的企业应用需要相对...

    ESB全称为Enterprise Service Bus,即企业服务总线。它是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢,是构筑企业神经系统的必要元素。

     

         大规模分布式的企业应用需要相对简单而实用的中间件技术来简化和统一越来越复杂、繁琐的企业级信息系统平台。面向服务体系架构(SOA)是能够将应用程序的不同功能单元通过服务之间定义良好的接口和契约联系起来。SOA使用户可以不受限制地重复使用软件、把各种资源互连起来,只要IT人员选用标准接口包装旧的应用程序、把新的应用程序构建成服务,那么其他应用系统就可以很方便的使用这些功能服务。

    展开全文
  • ESB企业服务总线

    2020-03-25 14:24:15
    ESB(Enterprise Service Bus)是一种消息和服务集成的中间件平台,是一个集中式的服务总线。它类似于计算机中的总线,通过总线将各种硬件连接到一起。 所有的企业服务都挂接到该总线上对外公布,企业服务总线负责...
  • 如何让企业的系统间互联互通、打破信息孤岛,是困扰企业的问题。ESB企业服务总线平台可以解决企业的大难题,帮助企业让各IT系统相互组合、形成合力。本文针对公司ESB企业服务总线平台进行产品培训说明。
  • ESB(Enterprise Service Bus,即企业服务总线)是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢,是构筑企业神经系统的必要元素。企业服务总线ESB就是一种可以提供可靠的、有...
  • 企业服务总线 ESB 介绍和用例

    千次阅读 2021-08-27 14:41:23
    企业服务总线(ESB)看起来非常复杂,但事实上,它可以非常有效地执行几个关键功能,协助开发人员进行应用集成。 什么是ESB(企业服务总线)? ESB是一种IT架构方法。ESB旨在通过”总线式”基础设施将各种应用集成在...
  • 火龙果软件工程技术中心 学习和研究在企业中实施面向服务架构(SOA),简单回顾SOA和ESB,重点关注微软在SOA领域的相关指导和.NET社区的相关开源的解决方案,和大家一起来探讨如何在企业里实现SOA,期望有实施SOA经验...
  • 1.介绍了ESB的基本概念 2.ESB功能:通信,集成,服务交互 3.与具体的业务整合使用的方式 4.比较分析常见的几个esb包括开源的mule与jbossesb,以及很牛*的wso2esb
  • Where, when and why did you use ESB in a PHP-project?Where, when and why do you think that it would make sense to use ESB in a PHP-project?Does ESB (and ESB-facilitators like Mule) do provide any capa...
  • 开源ESB服务总线记录

    2018-10-18 10:45:00
    记录下可能用到的开源ESB服务总线项目。 以下是几个比较流行且好用的开源的ESB: Mule ESB:MuleSoft是Mule ESB创建者。Mule ESB是一种广泛的开源ESB下载。 WSO2 ESB:WSO2 ESB旨在极端轻量型和可扩展性。...
  •  那么在这种情况下多套ESB总线之间如何集成和整合。  今天分享一个整合规划方案供大家参考。  企业集成场景和需求分析    大型企业内部随着多年的IT规划和信息化系统建设,集成场景相对来说比较复杂。...
  • Apache Synapse是一种轻量级的高性能企业服务总线ESB)。 由快速和异步中介引擎提供支持,Apache Synapse为XML,Web服务和REST提供了出色的支持。 除了XML和SOAP,Apache Synapse还支持其他几种内容交换格式,例如...
  • WSO2 ESB 企业服务总线总结文档WSO2 ESB 企业服务总线总结文档WSO2 ESB 企业服务总线总结文档WSO2 ESB 企业服务总线总结文档
  • ESB(企业服务总线)知识

    千次阅读 2019-12-18 20:59:38
    ESB是Enterprise Service Bus的简称,中文翻译为企业服务总线,企业服务总线是一个实现系统间集成和互联互通的重要技术架构,可以理解为是一种消息和服务集成的中间件平台。 这个技术是为了解决什么问题呢? 系统...
  • 关于SOA的概念,你可以找到...从概念的角度,IBM对SOA的定义是最为全面的,既SOA是一种构造分布式系统的方法,它将业务应用功能以服务的形式提供给最终用户应用或其他服务。一个体系架构,用开放的标准将软件资产(Asse
  • 用户数最多 社区最活跃的开源框架 企业服务总线 虽然没有实现JBI但是却非常好用。
  • 企业服务总线ESB是什么

    万次阅读 多人点赞 2018-01-17 18:25:14
    在探讨信息系统的SOA架构概念时,一个非常重要的概念是:企业服务总线(ESB)。可以说,企业服务总线也是SOA的核心构成部分。要真正实现应用架构完善的SOA结构,简化SOA构件间的关系,就一定要建设好信息系统的企业级...
  • 面向服务的体系架构 SOA Service Oriented Architecture (SOA)是一个粗...企业服务总线 ESB Enterprise Service Bus (ESB)是由中间件技术实现的全面支持面向服务的基础软件平台,是传统中间件技术与XML、Web服务
  • 从产品介绍和功能说明、成功案例说明、产品比较、市场占有率等多个方面介绍了IBM与Oracle企业数据总线ESB比较1. 产品介绍和功能说明1) IBM MB/MQ 产品线IBM WebSphere Message Broker/MQ 提供了一个能满足您的应用...
  • 关于SOA的概念,你可以找到很多的文章从不同的角度来描述它,不同的软件...从概念的角度,IBM对SOA的定义是最为全面的,既SOA是一种构造分布式系统的方法,它将业务应用功能以服务的形式提供给最终用户应用或其他服务
  • 专题资料
  • 几种ESB(企业服务总线)架构介绍.pdf
  • ESB企业服务总线详细文档

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 9,904
精华内容 3,961
关键字:

esb服务总线

友情链接: stb-master.zip