联合利华引进了一条香皂包装生产线，结果发现这条生产线有个缺陷：常常会有盒子里没装入香皂。总不能把空盒子卖给顾客啊，他们只得请了一个学自动化的博士后设计一个方案来分拣空的香皂盒。博士后拉起了一个十几人的科研攻关小组，综合采用了机械、微电子、自动化、X射线探测等技术，花了几十万，成功解决了问题。每当生产线上有空香皂盒通过，两旁的探测器会检测到，并且驱动一只机械手把空皂盒推走。
中国南方有个乡镇企业也买了同样的生产线，老板发现这个问题后大为发火，找了个小工来说:你他妈给老子把这个搞定，不然你给老子爬出去。小工很快想出了办法：他在生产线旁边放了台风扇猛吹，空皂盒自然会被吹走。
这个故事告诉我们“能吹是多么重要”，这当然是一个很搞笑的结论。其实它反映了我们经常把简单的问题复杂化。在软件架构设计上，我们是不是也经常遇到这样的情况呢。的确，架构设计人员都有追求完美的天性，唯美让我们不断的追求，同时也让我们陷入了过度设计的陷阱。
OECP的第一阶段已经结束，财务总账组件也开发完成。OECP的架构方案可以支持web群集、分布式应用、分布式存储，但是回过头来进行总结反思，有些问题一直回绕在脑海中。最近一直泡在架构设计方面的网站上，希望能从中寻找出一些答案。我也将这些问题拿出来与大家分享讨论，寻求一种更有效的解决问题之道。
我们真的需要分布式吗？
既然我们已经实现了分布式，也做了相关的工具类来很好的lookup，为什么还存在自我怀疑呢？原因就是我们在开发的过程中，我们程序实现的复杂性大大的增加。我们要建立本地接口，还要建立远程接口，还要考虑怎样灵活的配置何时使用本地接口，何时使用远程接口。页面少不了树形菜单这样很UI的组件，我们思考是在EJB端实现还是在web端实现。因为分布式调用连接的开销比较大，我们要遵循“少调多取”的原则，我们要思考怎样减少调用频率，一次性取出多少数据，怎样在web层某时间内保持这些数据。我们使用了EJB端缓存，同时还要采取web端缓存，虽然都是缓存的一个东西。华丽的架构体系给我们带来的是巨大的开发难度和工作量，仔细思考一下，这值得吗？至少现阶段值得吗？
分布式计算的确有很高的运行能力和水平扩展能力，是构建大型高效系统的一种很先进的技术。但是仔细分析我们的系统，我们到底哪些地方需要分布式，哪些地方存在大量的高强度的运算，至少现在看不出。翻开我们的代码，EJB中的方法中大部分是简单的SQL执行，一个SQL执行器需要分布式吗？也许未来某些功能和应用需要大量的计算，这20%的部分可以使用分布式计算，只要在现有系统的设计上做到水平扩展的能力就行了，并且扩展分布式的方式也不是非常困难。
没有平台的业务组件好用吗？
组件化的思路是一个非常好的系统开发思路，在OECP的开发上我们会坚定不移的探索和执行。我们实现了财务总账组件，而且也应用起来，但是我们也发现了很多的问题。一个业务组件应该是可以独立运行的，这是组件自治和组件间松耦合的一个体现。我们非常重视业务组件，因为业务领域是我们具有核心竞争力的领域，但是没有平台的业务组件价值到底有多大？即使可以集成多个系统，这种情况又有多少？
在实现上，我们过度的考虑组件独立化，造成主数据操作复杂，同样的操作独立存在多个组件，增加开发的难度和工作量。组件间的通讯也是我们不得不考虑的难题。所以我们首先需要一个平台，这个平台抽象出统一的实体结构，设计统一的程序调用结构，实现流程化的业务集成方式，基于平台架构的快速开发工具，而这些会进一步指导组件的开发，在保持组件独立性上增加相应的约束和粘合，达到快速开发构建系统的目的。
作为OECP主要的设计者，我对系统的设计缺陷负有直接的责任，我必须正视这些问题，及时的调整思路和架构设计方式，从过度设计的泥潭中爬出来。下一步OECP组件的核心任务将以平台开发为主，抽象统一的实体结构和抽取统一的主数据实体，封装相关的操作，制定标准和约束，并在此基础上构建快速开发工具。整体架构依然采用jboss seam为基础框架，弱化分布式解决方案，在平台层面弃用标准的JEE架构，采用更加轻量更加便捷的seam架构体系，减少分层，整合seam给我们提供的解决方案，研发相关工具，为组件的快速开发做前期准备。
以上是OECP存在过度设计的一些问题，这些问题在我们现有的其他系统中也有体现，一味的讲究完美，追求新的技术，而忽视了实际中的问题，没有根据自身实际而量体裁衣。有人说，架构不是设计出来的，而是系统演变形成的，说的也不无道理。保持适当的前瞻性和良好的扩展性，在现实应用和未来架构中进行折中，有所取舍就不失一个很好的架构。下面链接是介绍的myspace的一个数据库架构演变过程，也许会给我们一个提示，罗马不是一天建成的。
回到上面的那个小故事，我们再做一次假设。
比如说，当肥皂生产速度上升了，风扇有极限，未必能完全吹落，可是博士后设计的程式只需调整控制速度的参数就行了。比如说，当市场改变了，肥皂盒子提倡用铁制的，那么风扇就无用武之地了，得重新想办法，可机械手只须调整控制力道的参数就行了；当肥皂厂扩张，要生产电脑零件了，那么风扇可能会把沙子吹入，影响精密度，可是博士后的设计依然可以用。
想象当规模足够大的时候，博士后的程式虽然几十万，可每次的改进或许只须几千就够了，而且使用的技术会越来越成熟。可是民工的办法每次都得重新构思，而且每次都会冒着新的风险。
思考这些问题后，民工的方案就变的过于简单而带来未来扩展的难度和维护成本的上升。这个反应的现象正好是过度设计的对立面，那就是设计不足。我们摒弃过度设计，并不是不要设计，设计不仅仅为现在服务，也要为不远的将来服务，回归现实也不是说不面向未来，这需要设计者的一个平衡。而在我们以前的某些系统，就存在着设计不足的现象，比如集团网站，程序不规范，分层不清晰，结构混乱等。下面根据现有系统，也提出了几个问题我们一起去讨论。
静态化真的能提高速度吗？
集团网、健康社区都大量的使用了静态化，但是我做了一个简单的测试，在带宽512K的ADSL上访问这些网站和实验室的动态网页，速度都不如动态网页打开的快。也许这样的测试缺乏标准和可参照性，但是依然能引起我们的思考，静态化未必能真正的提升效率。大量的静态页面生成到磁盘上，在减少数据库访问的同时，却增加了磁盘的IO，当磁盘文件较少的时候，还感觉不到效率的影响，然而当磁盘的文件大量积攒的时候，IO阻塞就成了系统的瓶颈。国内比较大型的门户网站虽然也大量的使用静态化，然而在存储上，静态文件和动态应用是分开存储的，静态文件由统一的文件分发服务器负责管理，这些服务器主要在IO上进行优化。而动态文件需要动态运算，消耗的是CPU和内存的资源，这些服务器也会在这两个方面进行优化和提升。而我们的应用，不论动态应用还是静态文件全部都集中在一起，都由Tomcat负责解析，各自的优势都没有真正的发挥出来。
与此同时，由静态化引起的开发复杂度和维护难度陡增，也将演变出一系列的问题，比如维护成本较高，重构扩展困难，某些功能难以实现，这些问题，维护健康社区的人员应该深有体会。我建议在没有必要一定得静态化的地方适当的使用缓存是一个替代方法，在内存上斤斤计较，不舍得投入时最不明智的。
网站静态化参考文章：
数据库已经死了吗？
J道网站的创始人benQ曾经写过《
数据库已死》、《
数据库时代的终结》的文章，虽然有点言过其实，但是数据库王者时代确实已经过去，特别是java的出现，使得数据库的地位越发的不再像以前那么重要了。Java应用服务器拥有很强的运算能力，强大的缓存机制，而且可以无限的水平扩展，这些都是数据库所不具备的。现代软件开发的一个优化方式就是要负载、压力前移，由以前的数据库转移到应用服务器上。通过负载均衡、分布式运算、缓存处理来提升性能是现代系统的解决方式。我支持这种方式，所以在我参与设计开发的系统中，我推崇OO设计，而取代以前的数据库模型设计。在OECP项目中，我们直接设计实体，数据库的生成都是在运行时交给JPA，Hibernate去自动建立。同时完全抛弃存储过程，存储过程其实是增加数据库压力的最大祸首，本来应该在业务层完成的运算交给数据库处理，难以维护，难以优化。而在上面提到的分布式应用，我们很多人都是在服务层去简单的执行SQL，无疑是将压力交给数据库，而分布式计算的能力一点没有发挥出来，这种不合理的使用是造成性能缺失的一个很大的因素。
也许某些操作用SQL非常简单，要比写程序更加的直接方便，比如复杂的报表，一句SQL就可以搞定，而用程序可能会分解成几十行或几百行的java代码，这也是我们无法说不的一个原因。但是我们需要从以前以数据库为中心的思维中解脱出来，OO,DDD是我们未来要积极发展的。对于数据库这一个话题，网上benQ和一位网友有个激烈的争论，分享出来解解闷。
google没有使用数据库而是采用的自己的文件系统，而当下的云计算，大型厂商只有微软使用关系数据库，google、IBM等大公司都摒弃了关系型数据库。这方面的内容大家可以去网上搜索一下相关信息进行了解。
其实还有一些问题，比如Ajax的运用，特别当ExtJS华丽的外表下难以维护的问题让我有忧有喜；缓存的合理使用来提升系统性能；Web应用和企业应用的架构设计的不同；这些都值得我们去思考，在实际的开发过程中不断的总结。
让架构回归现实，这不是思想的倒退，也不是技术的落伍，而是因地制宜，合理规避风险，降低开发成本的一种心态，作为架构设计人员要拿得起放得下，这样才能架构设计出好的系统。
今天谈了很多，希望朋友们拍砖。
这个系列的文章，可以通过访问：小工纸上谈兵 来阅读讨论。所有的言论都是我个人的观点，仅仅是一些思考，不夹带任何其他成分，希望大家能积极的讨论，提出建议和批评。
附件：
