SOA架构
(Service-Oriented Architecture)
面向服务的架构是一次具体地、系统性地成功解决分布式服务主要问题的架构模式。
为了对大型的单体系统进行拆分,让每一个子系统都能独立地部署、运行、更新,开发者们曾经尝试过多种方案,笔者列举以下三种较有代表性的架构模式,分别为:
烟囱式架构(Information Silo Architecture)
信息烟囱又名信息孤岛(Information Island),使用这种架构的系统也被称为孤岛式信息系统或者烟囱式信息系统。它指的是一种完全不与其他相关信息系统之间进行互操作或者说协调工作的信息系统。这样的系统其实并没有什么“架构设计”可言,承接着上一节中企业与部门的例子来说,如果两个部门真的完全不会发生任何交互,就并没有什么理由强迫把它们必须在一栋楼里办公;两个不发生交互的信息系统,让他它们使用独立的数据库、服务器即可完成拆分,而唯一的问题,也是致命的问题是,企业中真的存在完全不发生交互的部门?对于两个信息系统来说,哪怕真的毫无业务往来关系,但系统的人员、组织、权限等等主数据,会是完全独立、没有任何重叠的吗?这样“独立拆分”、“老死不相往来”的系统,显然不可能是企业所希望见到的。
微内核架构(Microkernel Architecture)
微内核架构也被称为插件式架构(Plug-in Architecture)。既然烟囱式架构中,两个没有业务往来关系的系统也可能需要共享人员、组织、权限等一些的公共的主数据,那不妨就将这些主数据,连同其他可能被各子系统使用到的公共服务、数据、资源集中到一块,成为一个被所有业务系统共同依赖的核心系统(Kernel,也称为Core System),具体的业务系统就以插件模块(Plug-in Modules)的形式存在,这样便可提供可扩展的,灵活的,天然隔离的功能特性。 这种模式很适合桌面应用程序,也经常在Web应用程序中使用。以更高层抽象来看,任何计算机系统都是由各种架构的软件互相配合工作来实现各种功能的,本文列举的各种不同的架构模式一般都可视作整个系统的一种插件。对于产品型应用程序来说,如果我们想将新特性或者功能及时加入系统,微内核架构会是一种不错的选择。微内核的架构也可以嵌入到其它的架构模式之中,通过插件的方式来提供逐步演化的功能和增量开发。所以如果你准备实现一个能够支持二次开发的软件系统,微内核是一种良好的架构模式。 不过,微内核架构也有它的局限和使用前提,它假设系统中各个插件模块之间是互不认识(不可预知系统会安装哪些模块),这些插件会访问内核中一些公共的资源,但不会发生直接交互。可是,无论是在企业信息系统还是互联网,这一前提假设在许多场景中都并不成立,我们必须找到办法,既能拆分出独立的系统,也能让拆分后的子系统之间可以顺畅地互相调用通讯。
微内核架构示意 图片来自O'Reilly的开放文档《Software Architecture Patterns》
事件驱动架构(Event-Driven Architecture)
为了能让子系统互相通讯,一种可行的方案是在子系统之间建立一套事件队列管道(Event Queues),来自系统外部的消息将以事件的形式发送至管道中,各个子系统可以从管道里获取自己感兴趣、可以处理的事件消息,可以为事件新增或者修改其中的附加信息,甚至可以自己发布一些新的事件到管道队列中去,如此,每一个消息的处理者都是独立的,高度解耦的,但又能与其他处理者(如果存在该消息处理者的话)通过事件管道进行互动。
事件驱动架构示意 图片来自O'Reilly的开放文档《Software Architecture Patterns》
当系统演化至事件驱动架构时,原始分布式时代结尾中提到的第二条通往大规模软件的路径,即仍在并行发展的远程服务调用也迎来了SOAP协议的诞生(详见远程服务调用一文),此时“面向服务的架构”(Service Oriented Architecture,SOA)已经有了它登上软件架构舞台所需要的全部前置条件。SOA的概念最早由Gartner公司在1994年提出,2006年,由IBM、Oracle、SAP等公司共同成立了OSOA联盟(Open Service Oriented Architecture),用于联合制定和推进SOA相关行业标准。2007年,在结构化资讯标准促进组织(Organization for the Advancement of Structured Information Standards,OASIS)倡议与支持下,OSOA由一个软件厂商组成的松散联盟,转变为一个制定行业标准的国际组织,联合OASIS共同新成立了的Open CSA组织(Open Composite Services Architecture),这便是SOA的“官方管理机构”。
当软件架构发展至SOA时代,其中的许多概念、思想都已经能在今天微服务中找到对应的身影了。服务之间的松散耦合、注册、发现、治理,隔离、编排,等等。这些今天微服务中耳熟能详的名词概念,大多数也是在分布式服务刚被提出时就已经可以预见到的困难。SOA针对这些问题,乃至于针对“软件开发”这件事情本身,进行了更加系统性、更加具体的探索。
SOA在21世纪最初的十年里曾经盛行一时,有IBM等一众行业巨头厂商为其呐喊冲锋,吸引了不少软件开发商、尤其是企业级软件的开发商的跟随,最终却还是偃旗息鼓,沉寂了下去。笔者曾在远程服务调用一文中提到SOAP协议被逐渐边缘化的本质原因:过于严格的规范定义带来过度的复杂性。而构建在SOAP基础之上的ESB、BPM、SCA、SDO等诸多上层建筑,进一步加剧了这种复杂性。开发信息系统毕竟不是作八股文章,过于精密的流程和理论也需要懂得复杂概念的专业人员才能够驾驭,SOA诞生的那一天起,就已经注定了它只能是少数系统阳春白雪式的精致奢侈品,它可以实现多个异构大型系统之间的复杂集成交互,却很难作为一种具有广泛普适性的软件架构风格来推广。SOA最终没有获得成功的致命伤与当年的EJB如出一辙,尽管有Sun Microsystems和IBM等一众巨头在背后力挺,EJB仍然败于以Spring、Hibernate为代表的“草根框架”,可见一旦脱离人民群众,终究会淹没在群众的海洋之中,连信息技术也不曾例外过。
当你读到这一段的时候,不妨重新翻到开头,回头想一想《演进中的架构之单体系统时代》中提到的“如何使用多个独立的分布式服务共同构建一个更大型系统”这个问题,再回顾下《演进中的架构之原始分布式时代》一文中Unix DCE提出的分布式服务的主旨:“让开发人员不必关心服务是远程还是本地,都能够透明地调用服务或者访问资源”。经过了三十年的技术进步,信息系统经历了巨石、烟囱、微内核、事件驱动、SOA等等的架构模式,应用受架构复杂度的牵绊却是越来越大,已经距离“透明”二字越来越远了,这是否算不自觉间忘记掉了当年的初心?接下来我们所谈论的微服务时代,似乎正是带着这样的自省式的问句而开启的。
周志明,腾讯云最具价值专家(TVP),Java技术、机器学习和企业级开发技术专家,现任远光软件研究院院长,机器学习方向博士, 开源技术的积极倡导者和推动者,对计算机科学和相关的多个领域都有深刻的见解,尤其是人工智能、Java技术和敏捷开发等领域。曾受邀在InfoQ和IBMDeveloperWorks等网站撰写技术专栏。
著有畅销书多本。著有《智慧的疆界》、《深入理解Java虚拟机》、《深入理解OSGi》,翻译了《Java虚拟机规范》等著作。其中《深入理解Java虚拟机》第1版出版于2011年,已经出至第3版,累计印刷超过35次,销量30万册;不仅销量好,而且口碑更好,是中文计算机图书领域公认的、难得一见的佳作。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。