“分布式系统的最佳应用，就是不使用分布式”感言

　　刚刚翻阅一份老贴子，其中有一个回贴提到老马说过“分布式系统的最佳应用，就是不使用分布式”这句话，真的是感同身受。btw，搜了半天，竟然再也找不到这篇回贴了。我也没有去验证这话是否是老马说的，权当它是真的吧。

　　说起分布式这个东西，可能更多的时候带有行业特色。传统的C/S时代，因为当时互联网尚不发达的原因，形成一个个的信息孤岛，还是需要分布式的应用的。比如全国性的信息系统，需要在各省、各市分别开发一套内部系统，来统一进行数据的交换。而在互联网已经足够发达，B/S一统天下的今天，竟然还会有分布式系统的出现，就真的是莫名惊诧了！

　　典型的应用，可能就是国内的银行和电信系统。我没有做过这方面的项目，但可以判断出，它们是曾经采用过分布式应用的。如各省分行/分公司是一套独立的系统，通过中间件与总行和其它分行进行数据交互。而近年新成立的商业银行，它的信息系统就应该是集中式的了。

■■分布式的缺点很明显，不便于进行升级和维护、不便于进行统一的安全控制、信息交互容易出错、形成信息孤岛很难提供决策支持......

　　我现在负责的一个电子政务系统，就被迫采用了分布式，深受其苦。采用分布式的原因，在于政务系统的特殊性，对安全性要求比较高，甚至要求内外网物理隔离，而政务系统必须置于内网，这就任谁也没有好办法了，就是用VPN专线客户也是不会同意的。而这套系统对公司是如此的重要，如此的有钱可赚，那也就没的商量了，上！

　　现在的情况时，北京这边总部是一套系统，各省市是独立的一套系统，通过数据交换中间件定时进行数据交互。与其他分布式系统不同的是，我们这是一个循环的工作流系统，举例讲，用户提交一份数据，先到市级系统，市级再转到省级，省再转到中央，中间任何一个环节都有可能将用户的请求驳回，用户再反复提交，直到最终审批通过为止。因此一份申请，可能要流转十几次，才能最终通过。在反复的数据交互过程中，数据的状态频繁变化，而各级系统、数据库也有可能出现各种各样的问题，而导致出现死数据或脏数据。各省市系统的升级、维护非常困难，但木已成舟，也只能被动的接受现状了。这其中固然有我们系统架构、软件bug的原因，但究其根本，还在于分布式。

　　而在去年，我们公司又接了某电力公司一个招标专家管理的项目，对方在开发的中间提出新的需求，要求采用分布式（每个业务人员可以用手提电脑将服务器上的所有数据同步到本机系统，并且在本机操作完以后再与服务器同步）并且态度十分强硬（理由是他们可能需要到环境恶劣的矿井等地，现场无上网条件，但又必须在现场使用此系统），如果我们不能实现就中止合同。我当时没有参与这个项目，但在听闻之后，也向技术总监表示了我的意见，“既然可以使用手提电脑来做现场操作，那么在无线网络已经十分发达的今天，完全可以让客户使用无线网卡或通过手机来上网，不必采用分布式”，也阐述了分布式可能造成的后果，但由于销售方面的压力，被迫接受了用户的需求，而原技术负责人半途而废跑了，竟然把我顶上去做这个项目。最终这个项目是完成了，但工作量、开发时间已经大大超出了预期，原定三个月完成的小项目，最后用了9个月的时间。而在最终项目结束以后，我们竟然发现，客户根本没有使用我们这个分布式！非常的失败。这种失败，不是某个人的失败，而是公司领导强加个人意志、销售单纯看重销售业绩所导致的失败。过去发生过，以后也仍然可能会发生。

续：
　　还有过这样的事情，用户要求在他们备份数据库的时候，由我方为他们提供另一个临时数据库来保证业务的正常运转，然后再两个数据库同步。这样的要求是不是非常无理？对方坚持要停止数据库服务再备份，就是不肯软备份。所以对于这样的无理要求，无论如何一定不能答应，基本上已经到了做软件的底限了。客户就差没让我们给他写一个操作系统+数据库了。
　　类似连锁商场信息系统之类，应该还是要采用分布式，定期传输数据，比如每天从总部获得各种商品的价格信息，并定期将销售、库存信息向总部上报。这样能够保证本地操作的速度，另外也能保证业务不受外部网络的影响。但这类系统的信息流向相对比较单一，数据交换的频率要求也不是很高，实现起来相对容易一些。

Martin Fowler说的"请牢记分布式计算第一法则：不要分布你的对象",和你说的老马说过“分布式系统的最佳应用，就是不使用分布式”差不多的...
对分布式真的有点恐惧感,我们几个在搞agent项目，也是用分布式的,更新远程数据库一个功能就试验了Ｎ久，关系到访问更新的权限问题，这一排才慢慢地试出来...

谢谢！
我也是刚看完那个回贴，记得不太清楚，大概意思是明确的。确实很恐怖，而且不是纯技术所能解决的。

不过“分布式计算”，与“分布式系统”，差别可是挺大的O。我所说的是指“分布式系统”。

不懂技术的客户迷信分布式，我以前也遇到过。秀才碰到兵，有礼说不清

像楼主这样的需求,不用分布式架构可以实现吗?

    看樓主的意思好像是想說：客戶別閑著沒事干提出一些需要分布式實現的需求（又很少用到）。
     和主題：“分布式系统的最佳应用，就是不使用分布式” 關系不大。
     好像你應該詳細說下客戶這個需求如果不用分布式應該怎么實現才更加貼題一些。

对的，是这个意思。
假设说，同样功能的一个系统，不实现分布式应用，工期为一年，合同金额为100万的话，那如果采用分布式，工期和合同金额至少要翻一倍或更多才算合理。但客户并不会这么想。所以对于销售人员和公司高层来讲，一定得把握住这个度，否则就极有可能成为一个失败的项目（工期延长，问题多多，双方都不满意）。

在我们曾经做过的分布式系统中，我有一点想法，还没有经过认真的梳理，比较粗糙的。
1：任何数据均不要物理删除，只打标记，以便于一旦出错时恢复。
2：使用版本控制，强制各系统定时升级，加强统一管理
3：对任何数据项的操作修改，均记录详细的log，以防止扯皮。比如我发了一个贴子，写了攻击某人的话，过一会自己改回去了。这个时候有人找管理员投诉，说xxx刚才骂我来着，如果没有一个前后数据变化的log，那就无法对证了。
4：及时对帐功能。类似财务的对帐。虽然子系统与主系统之间物理隔离，但可以在两端定期生成要对帐的数据，使用程序来核查数据是否完整、状态是否正常。


举一个例子吧，不知我猜的对不对。比如异行转帐，一般对方都说一个月内到帐，而很多情况下15天或更短时间内就到帐了。我猜想正常的转帐时间就是15天，而对方称需要一个月，就是因为中间的转帐有可能会有问题。系统会在A行转出15天后，将A行的数据与B行的进行核对，如果此时B行尚未到帐，则有可能是中间转帐环节出了问题，那么此时再进行一次转帐操作。因为第一次转帐出错的可能性本身就不大，再加一次操作，基本上可以杜绝帐户不统一的情况发生了。

同意这段，分布式系统的确复杂度高。该跟客户多要点。


这段嘛，感觉和分布式关系不大啊。
1，3，4，在任何出现“财务\审计”关键词的系统，都是basic的要求，分布不分布，都是要做的。
2，倒是和分布式有点关系，不过，大家估计也都是这么做的，无可奈何。

对于这个问题，楼主有否新观点？

如果不用分布式系统，那就用集中数据管理模式，只用一个中央数据库，一个总部应用服务器，这是理想情况。
但是在某些行业行不通，比如连锁超市，万一断网了，POS销售终端收银损失就大了，这个时候就要支持脱网销售，客户端就必须用到本地存储了，数据同步问题又来了。