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

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

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

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

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

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

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

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

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