anti middleware - noradle/noradle-oracle-server GitHub Wiki

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

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

说两层架构伸缩性差

是因为传统两层架构的客户端连接数据库的方式是直接连接，导致数据库要直接服务大量客户端，而数据库服务器进程模型是一个连接一个进程，也就是 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，我个人的感受：

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