我们其实一直期望有这样的架构路线，期初我们能够不用陷入复杂的大型架构之争，而是针对实际情况单机单机的一个个部署开发，当我们把这些点都开发部署完毕，然后通过少量的工作，就能够把他们联系起来，这个联系技术就是分布式缓存 JMS等技术。这就是可伸缩架构的真正含义。

所以，楼主这个项目看上去复杂，但是我们必须分而治之，只有一个原则：确保业务基本围绕内存对象中为中心编程，否则，围绕数据库这个单点盒子，到时规模庞大后，就很难打破这个BOX盒子，进行伸缩性扩展了。

>>to vcshcn
这种需求是没有经过我们做任何剪切，直接由客户提出的，要求在不同城市的办公室需要在网络断开的情况下，依然可以保持部分查询的功能可以使用。

>>to banq:
目前来说，只是需求有些特别，而业务并不是非常复杂。倒是考虑过根据功能先分割。

>>to IceQi
就目前来说，我也不知道完整的需求，因为现在，在调研阶段，在这里只是说明一个情况，然后和大家一起”联想“讨论一下。

现在，在调研过程中碰到的一个问题就是：如何满足客户对于速度的需求。因为通过网络，没有太好的办法避免网络条件。

不是我打击你，这种东西从工程技术上说最终都是失败的，当然从其它角度来说没准是成功的，比如大家都捞到了好处。

原因很简单，这种复杂度和难度不是你能控制的。

to:gougou3250
>>由于查询与更新操作比例2：1
>>所以你的服务器部署方式不可能象你说的那样，每个城市放一个镜象
用户提出了需求，我们思考的方式是，让用户在网络无法工作的情况下，也可以有部分查询或者OLAP的业务可以进行。

>>把大量数据缓存到客户端更是不可想象的，要学会对某些不合理的客户需求说NO，或者影响客户去修改他的需求变的更合理一些
>>肯定是在某个地方部署了一个服务器集群，然后都跑这个地方来访问的
目前项目没有进入真正的开发阶段，甚至只是在谈的阶段，因此现在只能是客户提出什么，我们就要先答应着什么，然后努力找解决方案。对于客户的“不合理需求”，要在后期再考虑是真的客户不合理，还是我们自以为是地认为不合理。

>>访问量那么大，应该存在企业或者政府自己的专用网络的吧，这种网络速度应该不是问题
>>JQUERY速度很慢，讨厌这个东西。有太多的JS框架可以来替代这个东西
没打算用UI的东西，只是用一些JQuery封装好的简单操作，比如get()，因此这个应该不成问题
关于网络，速度的确不成问题，但客户反复提出来的是：网络的不稳定性。

>>WEB层框架只是做MVC的作用，用不用事件驱动的影响不是很大，使用JS都是可以来模拟实现的
>>架构的核心是你的业务模型，你并没有提到任何有意义的东西
一个系统包含多个子系统，业务模型不是在这个阶段我就可以提出来的，更何况我需要在知道了所有业务后，大家一起去和这个客户的领域的专家去讨论。
WEB层的确是比较空的，主要是考虑到组件。

另外，现在年底了，找相关的负责人都不好找，估计一拖就是年初了。