设想一个大工程,好多家公司提供了不同的模块拼装在一起组成的系统。
模块1:一些.Net组件(C#...开发);
模块2:一些Web Service(某些用Delphi开发,某些用C++/VB,某些是Java...);
模块3:用PHP||JSP||ASP随便什么实现的一套网站页面(运行在Apache||WebLogic||WebSphere...啥的上头);
模块4:一些EJB(java开发,自然)...
后台数据库1:MS Sql server 2000 on Win2k
后台数据库2:Orcale 9i on Unix
后台数据库3:MySQL on Linux
...
etc.只是举个例子来危言耸听地形容这是个大项目,不够恰当呵呵
好了。上述这样庞大的一个企业应用,组合在一起,
为一个企业||N个企业组合实现了个ERP||MRPII or 供应链等等啥子逻辑组合;
分布式是个概念,是种方式。
设想你用c/s模式开发的一个数据库应用,
其规模到了上述这种情况,每日吞吐数据量达到了海量,某些关键服务的日访问次数以M计...
你的系统会怎样?只有一个结果,崩溃。
因为没有哪个强悍主机能在单纯c/s模式下满足这样的负荷。
甚至,你的系统都做不出来,因为它太复杂了。
因此,
当数据库应用的规模扩大到了一定程度后,人们让负荷被多个物理服务分担;
当应用开发复杂到了一定程度后,人们让系统被多个公司/团队开发的模块所分担;
当软件规模达到一定层次后,开发的方式不再是单一的c/s或者随便什么,而是一个混合体。
透过网络,运算任务被各个地方的服务所分担,数据在各个需求者/提供者之间传递...
自然,当前的工业标准,有两个统一的解决方案:Ms .net和Sun One;但只有一种实现方式:
SOAP/Web Service。
分布式么?不要单纯理解它是多个数据服务器被一个服务程序集中起来向客户统一提供服务。
这个概念已经进化/泛化。也不要说“我要学分布式么”,这不是你学不学的问题;
到你做的工作达到一定规模,你必须用。
btw,也没有啥学习的,这又不是个技巧问题,而是要掌握概念,熟练应用。
<!--
<sign>
嗯,随便走走,胡乱说说。
<i>
<b>
Best Regards,
Bug
</b>
</i>
</sign>
-->