anti middleware

两层架构/三层架构/多层架构

对原先两层架构缺点的误解

说两层架构伸缩性差

是因为传统两层架构的客户端连接数据库的方式是直接连接， 导致数据库要直接服务大量客户端， 而数据库服务器进程模型是一个连接一个进程， 也就是 poll 方式的 I/O 模型， 因此会导致最大连接数的限制， 超过一定的连接数，数据库服务进程数会大量增加，导致大量的CPU切换，系统CPU和内存资源被大量浪费。

但是采用了 oracle dispatcher 模式后， 大量的客户端连接到 dispatcher 上， 一组共享服务进程在有完整请求到达本地共享内存后才进行处理， 不会再出现原先大量服务进程大量CPU切换的问题。

两层架构在部署升级客户端的问题

目前的客户端已经进化到 browser-based application，客户端侧代码动态从 web server 上下载执行，没有纯客户端部署升级问题。

所谓的三层架构

当初引入如 TUXEDO 这场的中间件，主要就是为了降低 oracle 服务进程数。 这和 oracle shared server through dispatcher 架构设计原理一样。 但是引入了 TUXEDO 后，开发模型都改变了，而使用 dispatcher 架构开发模式完全和直接数据库一样。 TUXEDO 似乎起作用的地方只有如下：

• 限制能访问到的后端数据库服务进程数，其实 dispatcher 也一样，同一个 service 下通过 resource manager 控制最大服务进程数
• 缓存得不到处理资源的请求数据，等待资源具备再执行，这个和上面以一样，oracle 本身就可以控制
• 负载均衡、路由。直接从nginx等web proxy中实现负载均衡也很方便。额且负载均衡只对瓶颈点(也即数据库)有意义，对通道服务根本没意义。
• 客户端必然以浏览器为主，客户端和服务端的界面必然以 http 协议为主，既不会是 xDBC，更不是是其他专有协议，使用 tuxedo/cobra... 等还需要在其上在封装一个 http 服务层，简直是自找麻烦

TUXEDO

• 使用私有的 API 和私有的 client/server 通信协议和数据格式，没有采用开放的 http/xml/json 标准
• 基本上只是用来保护数据库，但是完全有更底层的不影响开发模式的方案

CORBA

你可以看看《The rise and fall of CORBA》，作者 Michi Henning 可是corba方面的大大大牛啊，当年是corba的推动者，他写的书《Advanced CORBA programming with C++ 》是用C++开发corba的参考手册。后来他进入反对corba的阵营。他的观点，应该是多年经验的总结。 我用过micro ORB， ACE的TAO，ominiORB，我个人的感受：

1. 标准是个大问题。标准里面没有定义到每个具体的细节，结果不同厂家都按自己的方式进行了扩展，而且又互不兼容，不同厂家的ORB，调用方法并不完全相同，不同厂家的ORB做server和client端会有兼容性问题。
2. 复杂。可以这么说，如果用C++做corba开发，没有2年多C++的开发经验+1年的corba方面的经验+一定的网络通迅方面的经验，那写出来的程序基本上是经不住压力的。
3. 与流行标准不兼容，没有紧跟时代潮流，但又不便于扩充。corba诞生的年代，网络安全问题还不像现在这么严重，内网基本上没有几个有防火墙的，可是现在不一样，大企业内部基本上都有防火墙，但是corba要穿透防火墙，设置起来非常的麻烦，而且还需要程序内部进行一定的特殊处理，对那些已有的应用，这点就行不通。corba不能跟其它技术进行集成，这在进行快速开发的年代，是致命缺陷。
4. corba太老了，催生corba的因素，很多都已不存在。新产生的问题，corba解决不了。
5. 最最重要的一点：利益。 各自为了自己的利益，联盟里的厂家都不想让步，结果呢，就只能造成现在的局面。