分布式系统开发学习之CS模式（二）

http://rayinuk.cnblogs.com/archive/2005/05/16/156786.aspxCS模式的限制与应用
我在上一篇总结的时候提到CS模式含有一系列的限制。那这些限制都是什么呢？其实CS模式最基本的问题在于其缺乏可量测性，主要原因是由于Server逐渐的变成了性能的瓶颈。在前文里曾介绍可量测性和性能是分布式结构的二大特点。二者相辅相成，缺乏了可量测性也成为了CS模式不是一种完全的分布式结构的一个原因。在CS模式中，服务端通常需要通过获取和使用一些资源来处理Client的请求，比如说，连接数据库，获取数据信息等。对于一个软件的开发设计，任何一个需要访问共享资源的设计系统均应该在最短的时间内获取到所需资源，这样其它的用户就可以有机会去访问资源。试想一下，如果同一时间，大量的Client同时对Server发出请求，会出现什么的样的情况？可能会是Server的崩溃，也可能会是网络的停滞，但不管是什么，这一点将会让Server变成一个性能的瓶颈，这也是为什么我说C/S模式对于一个应用软件的可量测性来说含有一定的限制。(有关可量测性，在稍后会补充讨论)。C/S模式不适合大型的网络系统，但对于局域网系统来说是个很好的选择，换句话说，C/S模式适合10到100用户的局域网的系统开发，而对于Internet用户的系统来说，这种模式就不适合了。如果说CS模式不是一种完全的分布式系统，那么它与传统的分布式系统又有什么差别呢？正如我在上一篇学习总结中和一些朋友的讨论，CS模式的大部处理是在Client 中执行，而传统的分布式系统是在另一远程机器中进行处理。二者的边界有点模糊，但我认为针对不同的系统要进行正确的选择，这样才能设计出高性能的系统。在稍后我将会对其它的分布式架构做出学习的总结，例如点对点模式，多层架构模式等，同时也会涉及到一些分布式技术例如RPC, RMI, XML Web Service及.NET Remoting等。


可量测性(Scalability)的讨论

在上一篇学习总结中，和一些朋友讨论了有关可量测性这一词，现做个简短的总结，希望大家能指教指教。博客园的朋友“小陆”指出将Scalability翻译成可量测性不太准确，随后他给出了解释和例子，我在这里非常感谢，这里我贴出来，让大家看看，我认为他的比较容易明白。
|=========<转>=========Scalability翻译成可量测性不太准确, 这个词的意思是: 系统的性能会随着硬件条件的增加而同步增加, 基本上成比例增长. 比如一个服务器的响应时间为100ms, 两个服务器就是50ms, 四个服务器就是25ms. 这是理想的情况, 实际上是不可能的, 总有一些损失.
不仅对于分布式系统, 对于独立系统也有Scalability这个概念, 随着CPU主频, CPU个数和内存的增加, 系统的性能可以同步增加.|=====================
其后我也查了一下相关方面的笔记，得出以下结论：什么是可量测性呢？对于一个含有可量测性的系统来说，当其在物理资源(小陆所说的硬件资源)的数量或者用户的数量增加的前提下，仍应尽可能的保持着效率。当然，在实际的操作中，正如小陆所说，这是不可能的，多多少少性能都会受到影响。再拿我玩的魔兽世界Wow来当例子，当玩家多的时候，大家都需要排队，才能进入到游戏，而当玩家少的时候，大家就可以直接选取人物，进入到游戏中。
对于一个含有这种特性的系统需要有以下的能力：-          控制物理资源的耗费。-          控制系统性能的降低。-          预防系统资源损耗。-          避免系统性能瓶颈。
如果大家对于Scalability 持有不同意见，欢迎大家留言讨论，共同学习。