SOA与基于CDIF的API的联动
发布于 2 年前 作者 nausea 555 次浏览 来自 支持

几千年来,巴别塔的故事一直是人类面对的一个核心的困境。为了交流和沟通我们人类创造出语言,但沟通与交流仍然存在障碍……相同语言之间的沟通依语境的不同,尚且存在巨大的鸿沟,不同语言之间更是让人坐困愁城。

在物质文明高度发达、人工智能都已触手可及的今天,程序员一样在面对这样的困境。我们的先辈基于那时的技术条件,基于那时的业务需求,映射性地逐步发展出FORTRAN/COBOL这样命令式的程序设计、C/PASCAL这样过程式的程序设计,到C++/JAVA这样的面向对象的程序设计,再到今天WebService这样面向服务的程序设计。于是各式各样的异构性层出不穷无所不在,硬件(CPU和指令集、硬件结构、驱动程序)、操作系统(不同操作系统的API和开发环境)、数据库(不同的存储及访问格式)都不尽相同,高级语言更是依赖于特定的编译器和操作系统API编程,它们彼此互不兼容,需要开发和运行环境的支撑。这样的异构性使得各种不同软硬件之间在不同平台不能互联互通,再加上网络协议和通信机制的不同,系统之间还不能有效地相互集成,如同不同族群之间互相比划着沟通。很难协同组织去面对挑战。

虽然语言不同,但人类需要表达的内核是相似相通的,同理,各种应用系统之间的许多基础功能和结构是有相似性的,它们提供的服务和功能是相似的。如果每次开发都从零开始,就像每次造一款汽车都去重新发明一次轮子,那无疑是可笑的。

于是,屏蔽各种异构性,实现某种标准的互操作,以实现复用(而不用每次都去发明轮子),通过松耦合,通过将具体的业务抽象,通过服务的表达和业务过程的原子化去架构规划整个业务流程,这个架构就是SOA。——SOA就是这样的一个范式,用于组织和利用可能处于不同所有权范围控制下的分布式系统。

打一个形象的比喻,一个企业的最终服务就像是要安排各国大厨准备一桌顶级的菜肴,需要日本的生鱼片、清酒,法国的鹅肝、生蚝,德国的啤酒、肘子,中国的爆炒、佛跳墙,在这种情况下,你并不用再去学习各种语言和大厨们交流,只需要自己编排好上菜的顺序,在他们制作好的菜肴照片下写好交付时间,交给大厨,互相点头确认,按点去取菜,有统一的侍者规范上菜, 以保证最佳用户体验。每个大厨后面自成体系,团队内部用各自的语言交流,如同API后面的那个应用。而你编排的上菜顺序,就是流程驱动,服务员取菜就好比是API调用。

实际上,中国古代的四大发明中的印刷术,就是SOA思想应用的典范。没有印刷术之前,书籍需要手工抄写,因此效率低下,质量也不稳定,无法保证一致性。有了印刷术,出版效率和内容一致性提高了数量级!最初的印刷是刻板,这就是“复用”,如同软件通过组件的封装,达到重复和在不同场合使用的“复用”效果。但是,刻板印刷就是一个紧耦合,一块刻板只能印某一本书的某一页,其中具体的“字”无法复用,就如同软件技术中微软VB开发的com+组件就只能在windows环境中使用,无法与JAVA开发的EJB组件进行复用和编排,因为他们与开发环境和运行环境是紧耦合的,要在UNIX环境下使用,必须重新开发,相当于换书就得换版。而后的活字印刷就彻底解决了这个问题,文字和版面之间是松耦合,通过排版来实现一本书的印刷版面…….这又是数量级的跃升——如同我们可以封装服务,形成一个个API,通过服务编排的API联动来实现业务流程。

现在流行的所谓微服务,就是单个的活字,通过SOA串联成为文章(服务)。讲到这里,就必须提到schema。

schema就像是活字印刷里每个字,都应该有的固定规范,比如字体、大小、线条宽度等等,没有这个规范,有的字大、有的字小,印出来乱七八糟,而这恰恰是目前微服务领域的现状:基于XML的很多微服务根本没有schema!它们仅仅是山寨SOA。

综上所述,SOA是把复杂的业务系统切分成一块块小的独立系统,每个系统都叫一个服务,对外提供一组独立的API,然后通过API联动组织起完整的业务来。在每家企业发展的初期,通常一个或几个数据库表格就完成了业务,像大多数小企业那样。但当企业的业务系统复杂性膨胀到一定规模后,就必须考虑如何将各个子系统按照彼此独立的服务切分开来,不然以后会乱成一团麻,根本就无法管理。

这种联动,按照业务流程的要求是可以一步步串起来,提供无限的复杂度。这是企业内部的情况。那么,在外部呢?现在各种云服务厂商也有着无数的API,每一个都可以看成一个独立的服务。但如果把这些独立的服务也串起来呢,那就可以创造出一个个全新的应用。比如:有三个独立的单位,第一个单位是地方卫生系统,他的数据库保存的是该地某个人的医疗保险记录;第二个单位是某个医院,他的数据库中保存的是某个人在该医院所有的就诊记录;第三个单位是保险公司,他的数据库里保存的是某个人的参保记录。本来他们的系统互不相干,通过SOA的API联动,就可以很方便地根据一定条件从上述几个子系统中分别获取数据后,组织起一个完整的新业务流程。比如,如果某人以前参加过社保医疗保险,并且去年就诊次数不多于5次,同时前三年没有在保险公司购买过任何医疗保险,那么就可以给这个人提供50万的医疗保险,不然就少一点或者拒接保险申请,等等。

……可见,API联动的想象空间是无限的,但前提是开放! 因为每一个API就如同一个单独的音符,你稍微联动一下,它就能形成一个曲调; 如果你是一个大师,你就能写成一个恢弘的交响乐章; 如果你…打开apemesh.com…

回到顶部