应用架构设计的三个类型

转载http://www.jdon.com/43952

前段时间在论坛回答两个问题：事务和事件 ，这两个概念涉及到业务和技术架构的区分问题，合适的架构解决合适的业务，就像不同运输工具装载不同的运输物一样，人用客车装载，货物用卡车装载。

通过长期业务实践，我们会发现业务中隐约有一些通用共同的东西，如果我们能够总结出这些通用的业务功能应该使用什么技术架构解决，也就是解决了大部分软件系统的共性问题，可以避免初学者范方向性基本错误，特别是当前云计算 环境下的编程，云计算那些强大的技术服务应该适用怎样的业务，只有这些问题搞清楚了，才能更好地使用云计算 。

从我个人经验来看，业务中通用的东西提炼出来，分为三种模型：串行 星形和并行，见文后附图：

1.串行：这实际代表事务 处理，每次只能存在一个处理过程，在这个过程中调用多个函数，这是一个不可逆的过程，讲究前后顺序时序，每个环节都会产生结果数据。

2.星形：这实际代表一种操作共同数据的模型，比串行要灵活一些，允许多个过程操作一个数据，雅称称：并发计算concurrency computing

3.并行，这比星形更加自由，每个过程都独立于另外一个过程，互相不干扰，雅称并行计算Parallel Computing。

上面三个模型中都涉及两个基本元素：动态过程和静态数据，三个模型实际是这两个元素不同的组合结果，而过程和数据从哲学上讲可以说是抽象时空的两个基本要素，那么我们也许可以假定这三个模型已经涵括大部分需要软件实现的现实中业务系统。

再回到事件 和事务 两个概念，很显然，串行模型特点和事务 特点非常吻合，因此，如果遇到业务中强调事务 实现的，如交易事务 等等应该是用严格的串行模型实现。

而事件 概念一般是突发的，无法人为控制，如某地发生XX大事件 ，所以，事件发生的特点肯定是发散或同时的，很显然，星形模型和并行模型特点和事件 特点吻合。

既然这三个模型是业务和技术的接口模型，也就是说，业务人员和技术人员对这三个模型各有各的理解，通过这三个模型他们能够找到沟通点，也能找到业务功能对应的技术实现途径。

再从“同步”和“异步”来看三个模型，串行模型无疑属于“同步”；而另外两种模型无疑是异步的，或者可以说，不严格要求是同步，而通常异步能够带来高效率和高性能，因此，可以认为是“异步”的。

最 后再从“有状态stateful”和“无状态stateless”角度来看这三个模型，串行和星形属于有态的，而并行属于无态，这里状态实际就是静态数 据，有态表示不同过程需要共享同一个静态数据，从基本常识来看，为获得高性能，这种静态资源争夺必然会降低性能，因此，如果限制静态数据为不可变的，那么 就无需使用多线程锁进行独占式修改访问，应此也会提升性能。


[该贴被banq于2012-05-16 17:28修改过]