接前文狼的架构暗示
12306春运时的瘫痪距离我们并不是很远，或许我们还在为京东的618的抢购页面无法打开而感到懊恼。好像突然之间电子化的信息如汪洋大海一般充斥到我们的每一个空间，考验着我们的系统。于是分布式的概念深入人心。我们在不断的引入新技术：redis，NoSql，dubbo，hadoop……。
然而我们的改变似乎很缓慢，并不是所有急需改造的系统都能借分布式的东风摇身一变轻松的脱胎换骨，这里面有很多的原因，主要的有：
l 新技术本身的问题如成熟性、学习成本等，
l 应用本身的特殊性。如为提高性能需要在分布式系统上提供本地缓存，而不是Redis。
l 多个应用在数据库层面上耦合。
l 应用内部结构复杂，在引入分布式思路后，使得原先逻辑的复杂性可能会难以接受。如，原先的事务性模型需要彻底废弃，于是开始头大！
也许我们的系统非常幸运，顺利的进入到了分布式系统行列了。然而这有可能在更大的浪费资源。因为“分布”没有从根本上脱离“集中”的内涵！它只是用“技术”的方式在内部实现了物理的分布，但对外还是以一个逻辑“整体”出现的。
举一个例子，假设有一家优秀的B2C公司，在中国市场上因业务的膨胀，现将订单进行了分布式存储，且公司决定开展国际业务。假设国际业务未来几年发展的不错，此时我们的分布式的订单库拥有了海量数据记为M。那么每个顾客的订单记为N，则每个顾客的数据占比为N/M，也就是说，每个顾客在操作自己的数据时，其实就是在大海捞针。
虽然分布式通过哈希来避免了“大海捞针”。但如果M越大，则效率会越低，且M越大，哈希表也就越大，如果哈希表足够大会不会带来问题呢？可能的方案可能是多级哈希，然而hadoop支持多级哈希吗？假设支持，所有顾客操作的叠加将会有多少资源花费在哈希上？这些花费真的是不可避免吗？
因为对外还是一个逻辑整体，是集中的，所以所有的订单业务，不管是中国还是美国的，都会像一棵树一样在接入点进行汇集。而国际业务对网络资源的耗费及用户体验将是一个疑问？但愿我是杞人忧天了。
在这个层面上分布式存储已经无能为力了。当面对这个问题时，我们很自然的想到用多棵树来解决，这需要进行某种层面的分割——系统自治。此时订单数据被封装到自治系统中，打破了逻辑上的整体性，自治系统间的订单数据交换需要通过额外的接口来完成，当然数据量及频度将非常，非常……非常的小，我估计或许平均每天小于N/M。
这里的多个功能相同的“自治”系统也是一种分布式，一种系统级的分布式，只是现有的分布式框架绝对提供不了业务系统的“自治”。其实每个“自治”系统就是类的多个实例，但这里更强调“自治”，只有“自治”的系统才能将一个大任务进行“放心”的分解，而OOP中的封装已经包含这个精神了。在前期文章中我还讲到高内聚和低耦合，如果一个系统做不到高内聚，其实也就谈不到自治了。
现在“云”计算被广为关注，说实在的我看的不太明白，对外应该也是一个逻辑整体，所以它也有接入点流量限制的问题。也就是说，以一个商家建立的“一朵云”不能解决全部问题，只有国际性组织才有这个潜力！不过可以肯定的是“云”使系统的部署变得简单。
无论外部的技术框架有多好，有多么方便，但它解决的只能是我们业务系统中的某几个点，我们可以把它当成砖块垒在我们的系统中，但不可以作为“基因”来决定系统的命运。让理论指导实践，要比技术应用于实践具有更深层次的价值！
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。