J2EE简单性的红利

复杂性的代价：

    系统架构上的复杂性，如果并非出于必要，则一定是坏事.

它的影响主要：

1 . 带来大量不必要的代码，这些代码的每一行都需要编写，测试，而且需要带来很大的维护成本

2.  复杂的架构，往往也意味着性能的低下。

3. 复杂的架构往往会使构建比较复杂，并且往往依赖于一些复杂的工具.

4. 复杂的代码难于理解，也就是说，你很难往这的项目中再添加人员，要理解、维护这些代码，成本之大将超过预期收益.



XP 对于复杂性的理念是： 选择能够奏效的最简单的做法.



再来看看，导致复杂性架构的原因有哪些?

1. 使用复杂的技术解决方案，比如以前的EJB

2. 将对象分布化：

         将对象分布化常常会诱发以下几个复杂的情况:

           (1) 你需要在不同的服务器中传输对象，若是需要传输一个复杂层级的对象，将会非常困难.

           (2) 分布式应用的部署将会非常的复杂，和难于监控.我们需要在不同节点之间保持代码同步，所以在一个集群上部署新的二进制程序将会是非常复杂的

　          (3) 所有远程调用都需要面对网络问题，对于类似的异常处理，也是增加复杂度的方面之一

　　　　  (4)　对于分布式代码的测试变得异常复杂，因为要测试多种故障场景以及形形色色的部署现场.

　另：

　　在人们中有一种广为传播的信念：分布式应用系统是高度可扩展的，这也是支持对象分布化的主要论点。

但是事实是，这基本是一个神话。　　人们认为可以通过　４个tomcat容器，８个ＥＪＢ容器来扩展应用，所有请求都通过ＷＥＢ层来进行远程调用。

这里的主要问题是：　每次远程调用消耗的性能过于高，将设理论上这样的调用真是有所收益的话，也早被网络消耗光拉。

　

　　我们更加倾向于：　将应用完整镜像到一个集群，每个镜像放在集群中的机器上，用同一个ＪＶＭ来跑应用，通过硬件或者ｗｅｂ容器的负载均衡技术来对前台的请求来进行分流。让每个机器上的代码都相同，而且每一个应用都是跑在各自机器的一个ＪＶＭ实例中，这样的效率要远远高于分布式应用.

３．模式病

　　系统架构过于偏向于模式的应用，生搬硬套，导致应用过于复杂

４.各个软件厂商的忽悠

　　厂商将复杂的应用以最佳实践方式放出来，以显示他们的产品又多强大，但是往往他们给的最佳实践或许对真正的需求帮助并不大，反而会将应用架构带入泥潭

  结论： 借用quick sort作者，也是图灵奖获得者C.H.A.R.Hoare的一句有深意的话来说：

  “有两种软件开发的方法：一种是尽量把事情做得简单，让人一看就知道系统明显没有缺陷；一种是把事情尽量复杂，这样一来，也就没有明显的缺陷。”