架构设计的指导思想

工作好几年了，也做了几个项目，用了也搞了一些架构，可是基本没有脱离SSH之类的三层或者多层架构，关于这种架构，一直用得很好，却很少去思考为什么要这样做，最近公司要搞统一架构，我想连架构设计的思想都没搞清楚的话，是肯定做不成这件事的，于是乎，开始思考和学习起来。
    查阅一些资料后，我发现，要准确定义什么是架构似乎都是很难的一件事，很多专家都有自己的一套理论，但是总的来说，我比较支持Roy Thomas Fielding博士《架构风格与基于网络的软件架构设计》这篇论文中的说法（感谢满江红的翻译）。
    这篇文章前面对架构的概念，元素，以及评估标准都做了一个比较完整的定义，后面主要是提出REST这种架构的方案，原文比较长，我其实也还没有完全看完，不过一边看一边做做思想总结总是比较好的。
    首先原文明确了对软件架构的认识，作者认为软件架构是对运行时软件的各个部分的抽像方式，作者还特意强调软件架构不是源代码，不是设计文档，而是运行时的软件，作者认为软件架构本身应该是一种实现，而不仅仅是设计，结合现在的敏捷开发思想来说，我觉得始终把注意力放在最终的作品上都是很不错的，所以这个论文的观点一开始就比较对我的胃口了。
    然后原文进一步提出了对于架构中应该有那些抽象的元素，主要分为三部分，即组件(Compoment),连接器(Contector)和数据(Data)。这个抽象层次其实是相当高的，作者认为架构实际上由一个个的组件所构成，由连接器负责将组件组合成一个统一的软件，而数据则是在组件之间传输的单元，我觉得这种方式实际上和我们现在用的大多数架构思想是一致的。比如组件可以认为是Spring中的bean,而spring的ioc容器则扮演了将这些bean连接到一起的任务，而这些组件的接口参数以及返回值，就是数据了，作者也认为组件都应该对外只提供其接口，而隐藏具体实现，这些都和我们一直所遵循的开发模式是相吻合的，所以我也很同意这个元素划分方式。
    提出元素种类之后，作者又对架构的评估标准进行了一个定义，我这里就照抄一下，作者认为评估一个架构的好坏主要以这些方面来看，包括性能，可伸缩性（能够根据需要通过改变配置的方式提高性能），简单性，可修改性（这个里面要分为，可扩展性，可配置性等），可见性（我理解是可监控性），可移植性，和可靠性。我认为普通JAVA项目重点关注，简单性，可修改性，可见性（主要是异常抛出和捕获要明确，定位错误方方便），可靠性就可以了。
    然后作者提出了很多当前用得比较多的架构模式，我觉得都是不错的设计，但是不同的应用要使用不同的模式，我这里就不一一阐述了，我觉得现在比较流行的是多是这样一种模式，叫“分层-按需代码-客户-缓存-无状态-服务器（Layered-Code-on-Demand-Client-Cache-Stateless-Server，简称LCODC$SS）”，名字满唬人的，简称都好复杂，我这里详细讲述一下这种架构是什么思想吧。
    其实这东西是很多种架构模式和技术的组合，客户端服务器模式大家都知道，这东西在这之上又加了几个东西，首先分层搞JAVA的都知道，主要可以提高代码可重用性和可修改性；那么按需代码是什么意思呢？就是说客户端向服务器请求的除了数据，还有处理这些数据的代码，然后客户端执行代码，我看到这段的时候就觉得B/S模式本身就符合这种模式的，特别现在流行的flex,ext之类，不都是把代码下到本地来执行吗（当然C/S模式这种用法比较少）。缓存我就不多说了，客户端和服务端都可以实现；那无状态是什么意思呢，就是说服务器端不保存任何客户端的状态，客户端的每次请求都将所有数据包括状态都放入数据包中发到服务器，服务器从数据包中就能得到所有的数据（考虑到session主要靠客户端管理的cookie和sessionId实现，但是session中的数据又是放到服务器端的，应该也算是符合了无状态的一半思想吧）。这样就能做到服务器端的组件是无状态的了。
      所以我们现在做的大多数BS系统只要不乱搞，本身就符合这种架构模式的，只是我们不知道而已罢了。或者就是缺乏理论指导。
    说了这么多别人的观点，也该总结总结了。好吧，我承认上面的内容都是把我觉得符合我自己情况的内容选出来了，文章里面还有很多其他思想也是很好的，只是可能不太适合我们做的项目。反正综上所述吧，我觉得要设计出适合中小型B/S企业应用的架构主要关注以下几个方面：
    1.对系统常用的各个部分进行抽象，分为组件的抽象，和数据的抽象。
    2.使用一个成熟的连接器把这些组件连接起来。
    3.组件和数据的抽象基于其用途，并且要保证是无状态的（有状态还是无状态，这个观点很多争论，我认为无状态是保证安全的最佳手段）。
    4.提供一些无侵入的手段为组件提供服务（如缓存，事务，同步等）。
    5.URI资源本身以及相关操作的统一描述手段（我总感觉REST不是很适合，有待研究）。
    6.保持简单。