架构设计—神一般存在的中间件

        初识中间件是CORBA，听主席在上面吹牛，感觉除了神奇还是神奇，又是跨语言、又是跨操作系统、还能跨网络，效率还高，伸缩性还强，真是银弹啊。可是在用的过程中除了感觉难用，还是难用。后识中间件是现在的工作单位使用tuxedo来发布各式各样的服务来构建系统。可是中间件到底是啥，翻了一下维基百科，看了一下中间件的定义，真可谓是含糊不清，五花八门各种定义都有。其实就是按照其中最BT的定义来说，我早在使用CORBA之前使用的ODBC、BDE也是属于中间件的，甚至各种带有网络通讯功能的COM控件仿佛也是，又或者只要不参与到具体的应用服务器或软件中的F5、nginx、apache也是，当我搜到ACE都堂而皇之成为中间件时，我就开始迷糊了为什么MFC、VCL只能称为framework，boost、libev、libevent只能称之为库？我们暂且不执着于中间件这个名词，就以数据库应用中笔者最感兴趣的中间件iBatis和库SOCI的功能来进行对比，实际体验一把差别。

         从支持的数据库产品角度来看，iBatis能够链接任意多的支持JDBC接口的数据库；SOCI可以链接任意多种提供了原生API支持的数据库(部分需要扩展)，也可以通过ODBC连接任意多的支持ODBC接口的数据库。从OR maping来看，两者都支持OR mapping，一个通过配置文件进行OR maping规则指定，一个通过硬编码的方式进行OR mapping规则指定。另外SOCI支持直接书写任意SQL语句，提供SQL语言级别的支持。

        从上述比较看来，两者的区别实也就是车厘子和樱桃的差别，甚至SOCI库提供的功能支持看起来还比iBatis还多一些。一般情况下，当神走下神坛的时候，我们就会发现一大堆问题，比如中间件的维护问题，由厂商支持的还好，毕竟收了客户的钱，至少得敬业一些，可是如果遇到一些开源的中间件，那一旦出了问题，可是绝对要看心情办事。不看心情办事，修修改改就极有可能修改成自己的私有库。总的来说库的应用对数据库的使用带来了极大的便利，但是随之而来的也是对部分开发人员的编程技能要求的提高。更多的时候是随着库代码的日益庞大，当测试无法保证库代码质量时，开源就成了唯一的选择。但是开源就能避免这种崩溃的到来么？显然是不行的。

        这种代码级别的复用，复用的广度越大，底层的代码越是不能随意改动，有时一个bug的修复导致的系统重建的规模是翻天覆地的，真可谓是看似搭积木想法，其实是多米诺骨牌的布局。前不久的SSL的一个心率不齐，结果差点导致了互联网界的一场地震。可是这又怎么能挡住我们寻求安全复用代码的步伐呢，当静态的代码复用给我带来伤害时，那动态代码复用又是如何呢？

        先澄清一下什么是动态代码复用，动态代码服用是笔者自己杜撰的一个新词汇，用来表示那种不把已有的功能代码通过硬编码的方式嵌入到自己的宿主应用中，典型的应用就是UNIX下bash脚本，通过管道连连接一个个独立的程序来组合完成一项新的功能，在扩展一下就是现在时兴的web service调用或者RESTful服务调用，总之，就是功能代码是一个独立完整的进程实体，它的生命周期或长或短，但是和宿主程序的地位是相对对等的一种复用方式。关于这种方式《UNIX编程艺术》里面阐述的非常到位。不得不承认这是一个很接近于银弹的子弹。可惜，在应用的足够广泛时，类似于SSL心脏出血的弊端还是不可能解决，而且问题的发生或许更加隐蔽，就好比中国铁道部的在线网络购票系统竟然能导致远在万里之外的某个技术网站宕机一样。

        神一般的存在，一般都有神一般的威力。能量的守恒定律告诉我们这个世界上没有能够省功的方式，我们只能在省力和省距之间做权衡。这大概也是所有的中间件厂商能用世界100强、500强等等这些牛逼的企业的使用率来绑架用户的原因吧，各中理由已非技术能够解答。可是真正的科技公司，甚至有了一定技术积累的商务公司又有那个会相信这种鬼话呢。