J2EE简单性的红利 博客分类： 随笔 网络应用应用服务器软件测试JVMXP
程序员文章站
2024-02-03 13:55:04
...
复杂性的代价：
系统架构上的复杂性，如果并非出于必要，则一定是坏事.
它的影响主要：
1 . 带来大量不必要的代码，这些代码的每一行都需要编写，测试，而且需要带来很大的维护成本
2. 复杂的架构，往往也意味着性能的低下。
3. 复杂的架构往往会使构建比较复杂，并且往往依赖于一些复杂的工具.
4. 复杂的代码难于理解，也就是说，你很难往这的项目中再添加人员，要理解、维护这些代码，成本之大将超过预期收益.
XP 对于复杂性的理念是： 选择能够奏效的最简单的做法.
再来看看，导致复杂性架构的原因有哪些?
1. 使用复杂的技术解决方案，比如以前的EJB
2. 将对象分布化：
将对象分布化常常会诱发以下几个复杂的情况:
(1) 你需要在不同的服务器中传输对象，若是需要传输一个复杂层级的对象，将会非常困难.
(2) 分布式应用的部署将会非常的复杂，和难于监控.我们需要在不同节点之间保持代码同步，所以在一个集群上部署新的二进制程序将会是非常复杂的
(3) 所有远程调用都需要面对网络问题，对于类似的异常处理，也是增加复杂度的方面之一
(4) 对于分布式代码的测试变得异常复杂，因为要测试多种故障场景以及形形色色的部署现场.
另：
在人们中有一种广为传播的信念：分布式应用系统是高度可扩展的，这也是支持对象分布化的主要论点。
但是事实是，这基本是一个神话。 人们认为可以通过 ４个tomcat容器，８个ＥＪＢ容器来扩展应用，所有请求都通过ＷＥＢ层来进行远程调用。
这里的主要问题是： 每次远程调用消耗的性能过于高，将设理论上这样的调用真是有所收益的话，也早被网络消耗光拉。
我们更加倾向于： 将应用完整镜像到一个集群，每个镜像放在集群中的机器上，用同一个ＪＶＭ来跑应用，通过硬件或者ｗｅｂ容器的负载均衡技术来对前台的请求来进行分流。让每个机器上的代码都相同，而且每一个应用都是跑在各自机器的一个ＪＶＭ实例中，这样的效率要远远高于分布式应用.
３．模式病
系统架构过于偏向于模式的应用，生搬硬套，导致应用过于复杂
４.各个软件厂商的忽悠
厂商将复杂的应用以最佳实践方式放出来，以显示他们的产品又多强大，但是往往他们给的最佳实践或许对真正的需求帮助并不大，反而会将应用架构带入泥潭
结论： 借用quick sort作者，也是图灵奖获得者C.H.A.R.Hoare的一句有深意的话来说：
“有两种软件开发的方法：一种是尽量把事情做得简单，让人一看就知道系统明显没有缺陷；一种是把事情尽量复杂，这样一来，也就没有明显的缺陷。”
系统架构上的复杂性，如果并非出于必要，则一定是坏事.
它的影响主要：
1 . 带来大量不必要的代码，这些代码的每一行都需要编写，测试，而且需要带来很大的维护成本
2. 复杂的架构，往往也意味着性能的低下。
3. 复杂的架构往往会使构建比较复杂，并且往往依赖于一些复杂的工具.
4. 复杂的代码难于理解，也就是说，你很难往这的项目中再添加人员，要理解、维护这些代码，成本之大将超过预期收益.
XP 对于复杂性的理念是： 选择能够奏效的最简单的做法.
再来看看，导致复杂性架构的原因有哪些?
1. 使用复杂的技术解决方案，比如以前的EJB
2. 将对象分布化：
将对象分布化常常会诱发以下几个复杂的情况:
(1) 你需要在不同的服务器中传输对象，若是需要传输一个复杂层级的对象，将会非常困难.
(2) 分布式应用的部署将会非常的复杂，和难于监控.我们需要在不同节点之间保持代码同步，所以在一个集群上部署新的二进制程序将会是非常复杂的
(3) 所有远程调用都需要面对网络问题，对于类似的异常处理，也是增加复杂度的方面之一
(4) 对于分布式代码的测试变得异常复杂，因为要测试多种故障场景以及形形色色的部署现场.
另：
在人们中有一种广为传播的信念：分布式应用系统是高度可扩展的，这也是支持对象分布化的主要论点。
但是事实是，这基本是一个神话。 人们认为可以通过 ４个tomcat容器，８个ＥＪＢ容器来扩展应用，所有请求都通过ＷＥＢ层来进行远程调用。
这里的主要问题是： 每次远程调用消耗的性能过于高，将设理论上这样的调用真是有所收益的话，也早被网络消耗光拉。
我们更加倾向于： 将应用完整镜像到一个集群，每个镜像放在集群中的机器上，用同一个ＪＶＭ来跑应用，通过硬件或者ｗｅｂ容器的负载均衡技术来对前台的请求来进行分流。让每个机器上的代码都相同，而且每一个应用都是跑在各自机器的一个ＪＶＭ实例中，这样的效率要远远高于分布式应用.
３．模式病
系统架构过于偏向于模式的应用，生搬硬套，导致应用过于复杂
４.各个软件厂商的忽悠
厂商将复杂的应用以最佳实践方式放出来，以显示他们的产品又多强大，但是往往他们给的最佳实践或许对真正的需求帮助并不大，反而会将应用架构带入泥潭
结论： 借用quick sort作者，也是图灵奖获得者C.H.A.R.Hoare的一句有深意的话来说：
“有两种软件开发的方法：一种是尽量把事情做得简单，让人一看就知道系统明显没有缺陷；一种是把事情尽量复杂，这样一来，也就没有明显的缺陷。”