谷歌推广网站,seo海外运营,河北建设集团有限公司网站,工程机械网官网作者 | 耿立超责编 | 晋兆雨来源 | 《大数据平台架构与原型实现#xff1a;数据中台建设实战》SOA 所有的理念都是基于现有应用系统展开的#xff0c;不管是对服务的梳理还是服务之间的交互#xff0c;都是以现有应用系统为载体的#xff0c;中台不同于SOA 的地方在于… 作者 | 耿立超责编 | 晋兆雨来源 | 《大数据平台架构与原型实现数据中台建设实战》SOA 所有的理念都是基于现有应用系统展开的不管是对服务的梳理还是服务之间的交互都是以现有应用系统为载体的中台不同于SOA 的地方在于中台是一种平台化思维它并不是从系统集成的角度去思考问题而是从架构层面上重构了整个IT 生态。相比之下中台无疑是一种更深刻、更底层的变革因为它完全破除了应用之间的壁垒把企业的核心业务能力“中心化”把它们提炼并沉淀到中台的各个业务中心上而不是面向单一业务方向或渠道的应用系统上。这在SOA 架构下是很难实现的因为中台的业务中心与SOA 的服务载体即应用系统之间有着本质区别它们的定位和服务对象都不同这些区别决定了SOA 依然是一种相对松散的分治式的架构很难与中台这种更加中心化、更为强力的架构体系相抗衡。烟囱式的生态系统并不是今天才突显出来的很多企业已经被这个问题困扰多年了并且尝试过各种措施试图进行改善。回顾企业的IT 生态变迁史一段不得不提的历程就是SOA面向服务的架构。本文核心观点援引自作者所著的《大数据平台架构与原型实现数据中台建设实战》一书全书对数据中台的理念、架构和具体实现做了详细论述。大概在2005 年前后的七八年间随着SOA 理念和相关技术如ESB的不断发展和完善SOA 在当时被认为是改善僵化的IT 生态、解决烟囱架构等弊病的终极方案而被业界寄予厚望很多企业在那个时期纷纷上马SOA 项目希望凭借SOA 将企业的IT生态拉回到一种理想的状态。十多年后回首当初那场SOA 热潮我们发现最终在SOA 改造上取得成功的企业少之又少即使曾经取得了一定的成效伴随后来新业务系统的冲击当年辛苦建立的SOA 生态也大都名存实亡是什么原因导致了这样的结果呢人们很早就意识到点对点式的系统间交互是非常糟糕的在SOA 起源之前已经出现了基于消息队列的“消息总线”架构各个应用系统与消息总线连通由消息总线负责将消息路由到接收方从而让应用系统通过中心化的消息总线完成交互这样就可以消除点对点式的系统交互。但是消息总线用于系统集成时在某些方面依然有所欠缺例如消息都是静态的、预定义的、无法自描述的消息接口无法被注册和发现。同时另外一种以“服务”为视角看待和思考系统间交互的架构思想一直在不断地发展后来随着Web 服务Web Service技术的兴起IT 系统的对外接口逐渐向平台中立的第一代Web 服务标准WSDLSOAP靠拢这为实施这一架构打开了大门这就是SOA。从系统集成的角度看SOA 是一种非常理想的方案SOA 体系的两大核心如下对系统提供的对外交互进行提炼、组织和梳理通过封装、组合与编排将接口以“服务”的形式发布出去系统间的交互统一通过中心化的企业服务总线ESB完成。 典型的SOA 架构如图1所示。图1 典型的SOA 架构 SOA 成功的基础是对“服务”的提炼、组织和梳理只有服务足够灵活才能支撑各种外部系统的复杂需求而这一工作需要建立在对业务的深入了解之上同时要融合良好的设计思想才能达到要求。 SOA 中的“服务”在技术上以Web Service 为载体但是在粒度或者说抽象程度上会有所不同主要有如下三种粒度的服务 基础服务最细粒度的服务最基本、最原子的服务都会在这一层从服务数量上看这一层也是最多的复合服务是基于多个基础服务组合叠加而成的粗粒度服务多用于封装并简化由多个基础服务组合实现的共性服务业务流程是通过工作流引擎将多个服务编排起来形成一个完整的业务流程这是一种粒度更粗的服务常用于实现一个标准的、可复用的大尺度业务流程如审批等。 在应用系统之间SOA 依靠ESB 实现系统集成ESB 是治理点对点式的系统集成的核心手段它肩负着如下重担 实现系统间的连通数据转换智能路由安全控制可靠性控制服务管理监控与日志。 以上是对SOA 的一个基本介绍SOA 针对烟囱架构的治理主要依赖于两个方面 一方面立足于每个应用系统要求系统对提供的“服务”进行提炼和抽象确保其灵活、可重用这是让服务满足外部复杂需求的根本保障另一方面是通过中心化的交互媒介——ESB 来约束系统间的交互消除点对点式集成的负面影响。 但令人感慨的是走到今天SOA 已经很少被人提及了回看企业曾经在SOA 上做出的尝试和努力最后的效果多数都不够理想。在完成SOA 改造之后的若干年间受到后续各种新系统的冲击很多企业都没能坚守住自己的SOA 体系最终又回到了烟囱架构下的野蛮生长状态这其中的原因主要是 沟通与协作成本高新系统迫于业务需求和市场压力急需上线对负责的团队而言与周边系统的对接和调试属于外部不可控因素团队总是倾向于在内部可控的范围内解决问题因此会刻意避开对外部服务的依赖选择自建相关功能这样一来系统间的交互会向着衰减的方向发展重复建设也因此随之蔓延组织架构制约团队往往缺乏为响应其他系统的诉求而改造和升级自身服务的意愿因为新系统与他们没有直接的利益关系企业也缺乏适当的奖惩机制促使各团队之间的积极协作本质上这是组织架构决定的缺乏长效机制SOA 改造常常是作为一个项目实施的项目结束之后就不再有专门的组织和团队对SOA 架构进行持续把控了后续新的系统在融入SOA 生态时受到的支持就减弱了而新系统本身提供的服务也缺乏必要的梳理和管控有的新系统甚至不对外提供服务。 这些问题并不是SOA 自身的问题而是一些普遍的现实问题也是治理烟囱架构过程中遇到的深层次问题这些问题阻碍了SOA 在企业的落地和持续发展。所以说SOA 是曾经的“救赎”企业IT 生态现在面临的问题依然没有得到很好的解决。 关于作者耿立超架构师14年IT系统开发和架构经验对大数据、企业级应用架构、SaaS、分布式存储和领域驱动设计有丰富的实践经验热衷函数式编程。目前负责企业数据中台的架构设计和开发工作对Hadoop/Spark 生态系统有深入和广泛的了解参与过Hadoop商业发行版的开发曾带领团队建设过数个完备的企业数据平台个人技术博客https://laurence.blog.csdn.net/ 作者著有《大数据平台架构与原型实现数据中台建设实战》一书。 该书已在京东和当当上线扫描图中二维码了解详情更多推荐阅读没想到Unicode 字符还能这样玩MongoDB 计划从“Data Sprawl”中逃脱推特惊爆史诗级漏洞App 恶意窃取用户隐私云端安全路向何方开发者批评苹果商店佣金过高库克将面临立法者质疑花呗接入央行征信GitHub 发布更新| 极客头条那个从深圳流水线去了纽约做程序员的女工最近失业了
