进来的友友们，这是我申请cn博客后写的第一篇文章。这些知识理论并非晚辈我所亲身实践，是我看了些架构相关的书籍的小总结，生怕自己忘记了，所以到博客以文字表达出来，欢迎前来抛砖扔蛋。篇幅不是很长，请耐心地看完并给点反馈。尊重他人的劳动，积小德而成大义嘛，小编以泪言谢！
本文章的骨格轮廓：
先来引一下标题吧，“架构的搭建，技术选型”需要我们先了解：
1.什么因素会取决于架构的选型？
2.1 应用是否需要分布式
2.2 应用是否需要在集群环境中运行
2.3 持久化数据的存储策略
2.架构对应用系统的影响主要有哪些？
3.1 性能
3.2 可伸缩性
3.3 安全
分布式的讨论
集中式和分布式体系结构的选择，会影响到应用系统的性能，易实现性，可缩放性，坚固性，支持的客户类型，等等......
分布式应用很复杂，并导致显著的运行时开销，而且要求设计工作要保证令人满意的性能。
分布式体系结构提供的好处有：
1.支持许多需要一个共享式业务对象“中间层”的不同类型客户的能力。这个考虑因素不适用于Web应用，因为Web容器已提供了一个中间层。
2.部署任一应用构件到任一物理服务器上的能力。在某些应用中，这对负载均衡来说是非常重要的（请想象一下当一个Web接口做少量工作而业务对象做密集型计算时的一种场景。多个物理服务器总吞吐量可以通过消除瓶颈来得到性能的改善）
3.为了获得对每个应用构件被部署在何处的控制权，以便改进可缩放性和可靠性。
分布式架构不是实现坚固，可缩放应用的唯一方法，倘若有选择的余地，最好是通过选择一个非分布式解决方案来避开分布式应用的各种复杂性。
集群的讨论
集群的风格是多种多样，不管哪种风格，EIS层的资源（如数据库）都是在独立的服务器上，这会牺牲部分性能，无论如何都无法避免进程之间通讯的性能损失，但可以获得管理上的优势。集群方案的选择取决于系统的诸多因素，没有最好的集群方案，只有最合适的。
集群的挑战：
1.路由
发送到集群的请求如何被路由到具体的服务器？
2.状态信息的同步
同步session数据？写入存储进行共享？采用cookie传递？
3.如何保存数据缓存信息的同步
缓存同步？分布式缓存？
4.文件同步
使用共享文件系统？写入存储进行共享？
1.对象分布集群
这种模型的目标是通过把web和业务对象分布到集群中的不同机器中，来获得负载平衡和可伸缩性。所有的业务调用都通过RMI/IIOP，或是XML和web services来进行。把大量的负载组件分布到多台服务器，就是整个用用部署到多台服务器，有着很好的伸缩性，并还能获得硬件(CPU,内存)的支持。
对象分布的关键问题是，获得可伸缩性的同时以大幅度牺牲性能对代价的。远程方法的调用，因为网络传输以及序列化和反序列化的开销，相比本地调用差好几个数量级。在底层发生的基础设施开销往往要比实际传输数据的开销要大，所以我们应该尽量减少分布式调用的次数，即便是一次性传输大数据量。
在某种立场来说，分布对象还对性能有提升的作用。譬如业务功能的操作非常的耗费CPU时间，相对于远程调用的代价要大的多，这种情况来说，大量的服务器组成的专用集群能够很好的应付它。不过类似这样的案例非常罕见，而且，对于长时间才能完成的操作，通过消息队列（message queue）进行异步分布可能是远程方法调用的更好选择。
2.针对部署的集群
是把所有的组件都部署到集群中的每个节点中去。这种模型下，请求到达节点之前就已经进行了路由分配，而不是在单独的组件调用是进行分配。请求被分发到相应的服务器后，所有的调用都是本地调用。
3.农场集群
整个应用运行在多台服务器上，但是每台服务器都不知道其他服务器的存在，多台服务器共享资源（如数据库），不需要进行通讯。就是说服务器之间不需要进行状态复制
持久化数据的存储策略
还记得不久前在网上有这么一句话：“很多大规模的网站都经历了从集中式到集群，再到读写分离，再到垂直分区，再到水平分区，这是一个必然的成长过程！”。这句话对与否呢？我就不敢瞎评了，很多事物都不是对与错所能衡量的，而是立场问题。各位前辈的意思是怎样，请在回复中结合自己的经验和依据谈谈。。。
在面对大量访问的时候,数据库的瓶颈很快就能显现出来,这时一台数据库将很快无法满足应用,于是我们需要使用数据库集群或者库表散列，在数据库集群方面, 很多数据库都有自己的解决方案, Oracle, Sybase 等都有很好的方案,常用的 MySQL 提供的 Master/Slave 也是类似的方案,您使用了什么样的 DB,就参考相应的解决方案来实施即可，上面提到的数据库集群由于在架构,成本,扩张性方面都会受到所采用 DB 类型的限制,于是我们需要从 应用程序的角度来考虑改善系统架构,库表散列是常用并且最有效的解决方案，我们在应用程序中安装 业务和应用或者功能模块将数据库进行分离,不同的模块对应不同的数据库或者表,再按照一定的策略 对某个页面或者功能进行更小的数据库散列,比如用户表,按照用户 ID 进行表散列,这样就能够低成本 的提升系统的性能并且有很好的扩展性，sohu 的论坛就是采用了这样的架构,将论坛的用户,设置,帖 子等信息进行数据库分离,然后对帖子,用户按照板块和 ID 进行散列数据库和表,最终可以在配置文件 中进行简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能；
上面是我在网络上抄袭的，下面总结下我自己的实践后的小经验。以MySql为例子，MySql的最新版本支持主从复制（sql服务器间的数据同步），开启主服务器的二进制日志和配置主从服务器之间关系的授权，就可以实现MySql服务器的集群。当然了，这里还有负载均衡的分发尚未定义，不必担心，反向代理MySql Proxy来帮你解决，根据需要配置LUA脚本来描述指定转发规则，就可以实现你所想要的负载均衡效果。（我听说，有的数据库对集群的支持不是很好，看到这句话心里可真够揪心的啊）。到了这里，还可以根据需要，实现数据的读写分离。DB部署在集群的环境当中，我们只需要配置LUA脚本便能控制读写请求的分离转发，写操作由主服务器来处理，并同步到各个从服务器，读操作分发到各个从服务器去处理。这样就可以按需来增加或移除DB服务器，达到硬件资源的充分利用。如果这种架构还未能满足日益增长的需要，可以进一步的优化，设计数据存储的垂直分区，原理是把耦合度为零或较小的数据进行物理分区，从而赢得更多的硬件资源和可管理性。DB的垂直分区会对应用层有较大的影响，所以，在开发设计的前期就应该对以后的扩展做好充分的考虑。数据存储的垂直分区会带来诸多的问题（远程调用，跨数据源事务，单点故障等等），解决这些问题都有些开源框架组件和成熟的硬件产品，如RMI，webService，JTA，F5等等。。。在进一步往深度优化的话，就是水平分区了，原理是将同一数据表里的记录通过特定的算法分离到多个数据表中，从而可以部署到不同的数据库服务器上。水平分区要求逻辑层面较高的算法，篇幅太长了，小编就不在此罗列了。倘若再进一步优化的话，就得要去研究数据库原理和联系数据库商家的技术支持了。
总结：
选择架构，技术的依据是什么？一切出发于业务需求，性能指标，安全指标，扩展性，资金等等...
正如Rod Johnson所说：是基于实践证据和亲身经历，而不是追寻偶像崇拜或者门户之见。再补充一句，不要过分于依赖哪些花哨的“架构蓝图”，JPetStore，Spring side，EasyJWeb这些能够给你一个很好的参考。
就这样完了？我写这篇文章之前有着千言万语，到了写的时候却欲言又此。对自己无语。。。总体地看了看觉得文章很单调，下次添点图文什么的可能会有更好的可读性。好了，理论和实践是存在差距的，见证真理都得要动手的，呵呵，废话就不多说了，你懂的！
