#
现在各种MVC框架很多，各框架的优缺点网络上也有很多的参考文章，但介绍各框架性能方面差别的文章却不多，本人在项目开发中，感觉到采用了struts2框架的项目访问速度，明显不如原来采用了struts1框架的项目快，带着这些疑惑，我对各类MVC框架的做了一个简单的性能分析比较，其结果应该说是基本符合预期的，可供大家参考。
测试环境：
CPU：酷睿2 T5750，
内存：DDR2-667 2G，
Web容器：Tomcat6.0，最大线程数设置为1000，
操作系统：WinXP-sp3
测试步骤：
搭建6个Web工程，如下：
1.纯JSP:不包含任何MVC框架，只有一个测试用的JSP页面。
2.struts1：包含一个Action，不做任何逻辑处理，直接转发到一个JSP页面
3.struts2 JSP：不包含Action，只包含测试JSP页面，直接访问该页面。
4.struts2 单例Action：采用Spring来管理Struts2的Action实例，并配置成单例模式。
5.struts2 多例Action：采用Spring来管理Struts2的Action实例，并配置成单例模式。
6.SpringMVC3：采用Spring来管理Controller实例，包含一个Controller，不做逻辑处理，收到请求后，直接返回到一个JSP页面。
测试结果：
|
测试工程
|
请求数
|
并发数
|
总时间(s)
|
总时间(s)
|
总时间(s)
|
平均值(s)
|
Requests Per Second(每秒处理请求数)
|
|
JSP
|
2000
|
200
|
5.55
|
3.59
|
4.11
|
4.42
|
452.83
|
|
struts1
|
2000
|
200
|
6.77
|
3.83
|
7.00
|
5.86
|
341.03
|
|
struts2 JSP
|
2000
|
200
|
25.20
|
26.30
|
24.11
|
25.20
|
79.35
|
|
struts2 单例Action
|
2000
|
200
|
28.36
|
27.59
|
27.69
|
27.88
|
71.74
|
|
struts2 多例Action
|
2000
|
200
|
31.31
|
31.97
|
39.56
|
34.28
|
58.34
|
|
SpringMVC3
|
2000
|
200
|
7.16
|
7.50
|
4.27
|
6.31
|
317.09
|
说明：
以上测试虽不是非常的精确，但基本能说明一定的问题。每个JSP页面和Action都不包含任何的业务逻辑代码，只是请求转发。每轮测试取三次总时间的平均值。所有工程的测试均全部完成并正常处理请求，没有请求拒绝情况发生。
结论：
-
纯JSP的性能应该最高，这不难理解，JSP被编译成Servlet后，没有任何多余的功能，收到请求后直接处理。（这也验证一句经典的话：越原始效率就越高。）
-
struts1的性能是仅次于纯JSP的，由于struts1采用单例Action模式，且本身的封装相比struts2应该说简单很多，虽然开发效率不如struts2，但已经过多年的实践考验，性能稳定高效。
-
相比来说struts2的性能就比较差了，这不难理解，struts2之所以开发方便，是由于采用值栈、OGNL表达式、拦截器等技术对请求参数的映射和返回结果进行了处理，另外还采用大量的标签库等，这些都无疑增加了处理的时间。因此降低了效率。在我们实际的项目中，我测试本地工程访问每秒处理请求数只能达到35左右，应该说还有不少可优化的空间。
-
很多人认为struts2性能差是因为它的多例Action模式导致的，但我们采用spring管理struts2的Action，并设置按单例方式生成Action实例后，发现其性能有所提高，但并不是很明显。由此可见，多例Action模式并不是struts2性能瓶颈所在。另外，我们在struts2中采用JSP方式访问，发现其性能依旧和没有采用任何MVC框架的纯JSP之间存在好几倍的差距，这又从另一个侧面证实了我们刚才得出结论，struts2性能的瓶颈不在于它的多例Action模式。
-
SpringMVC3的性能略逊于struts1，但基本是同级别的，这让人眼前一亮，springMVC有着不比struts2差的开发效率和解耦度，但性能却是struts2的好几倍，这让我们灰常振奋，SpringMVC无疑又是项目开发的一个好的选择。
Hadoop最近很火，到处都能看到，查了一下资料大概先了解一下其运行原理。
google在05年公开了Map/Reduce论文，MapReduce在处理巨量数据方面有明显优势。
google公司一个技术大牛jefffery Dean提出的这个算法，随后很多小牛纷纷实现了Mapreduce,Hadoop是它的java实现，MapReduce概念直接推动了云计算概念的火爆。
没有优秀算法云是没法搞的。
这篇文章对Map/Reduce原理讲的很清楚。
http://www.chinacloud.cn/download/Tech/MapReduceOverview.pdf
这个是Apache关系Hadoop的文档，安装、开发示例都有。
http://hadoop.apache.org/common/docs/r0.19.2/cn/mapred_tutorial.html
官方WIKI
http://wiki.apache.org/hadoop/Running_Hadoop_On_OS_X_10.5_64-bit_%28Single-Node_Cluster%29
什么是云计算？
- 网格计算（Grid Computing）
- 分布式计算（Grid Computing）
- 并行计算（Parallel Computing）
- 效用计算（Utility Computing）
- 网络存储（Network Storage Technologies）
- 虚拟化（Virtualization）
- 负载均衡（Load Balance）
表现方式
- 基础架构即服务（IaaS）：Amazon Simple Storage Service，通过Webservice API向外界提供存储服务，数据存到分布式的各个地方
- 平台即服务（PaaS）：Google App Engine，开发平台，写一个JAVA程序部署到上面；Amazon Elastic Compute Clouding
- 软件即服务（SaaS）：Salesforce.com，提供在线的CRM，根据需要买帐号，服务等，企业无须开发系统；Google App，提供一整套的办公系统
以上所介绍的可以称为公有云。
云计算给我们带来了什么
- 小企业：通过公有云降低成本，按需采购IT资源，以小拨大
- 中大企业：通过私有云，提供全新的IT交付方式，高效可扩展的系统
- 开发者：全新的开发模式，需要做一个转换，即熟悉大规模并行运算
关键技术
- 分布式计算模型：MapReduce
- 分布式文件系统：HDFS
- 分布式数据库系统：HIVE
云计算对企业的价值
高度可用性，高度可扩展性
案例
- 金融数据收集分析系统：以廉价的IT设备收集少量金融数据，前端有各种模块收集数据-->云计算模式进行数据处理
-->保存到传统数据库-->用户展现
- IT知识库系统：前端数据取模-->云计算模式进行数据处理-->用户查询-->查询API
JAVA平台对云计算的支持
著名的开源实现：Hadoop
项目组成
- Pig
- Chukwa
- Hive
- MapReduce
- HDFS
- Zookeeper
- Core（核心部份，任务分配，调度）
- Avro（处理序列号）
MapReduce模型
- 源数据（Map）-->中间数据（Reduce）-->结果数据
- 处理流程：客房端提交任务-->Master Node决定如何折分任务-->分到各节点
- 实现：先启动Hadoop系统-->编写客户端程序-->使用Hadoop运行客户端程序
最近看Jboss in action，里面提到Jboss的hot deploy功能，今天动手试了一下了一下，发现确实很好用。
首先使用eclipse的Automaticlly publish when resources change 功能 ，设置一个较短的时间，比如一秒，那么在编辑保存之后，eclipse会自动发布更新到jboss部署目录。
在jboss中，可以使用Jmx Console，deploy，undeploy和redeploy。
例如：C:\Jboss\bin\twiddle invoke "jboss.system:service=MainDeployer" redeploy file://C:\Jboss\server\default\deploy\jbosstest.ear 。即完成对jbosstest.ear的重新部署。
在eclipse中可以把jmx命令行客户端twiddle配置为外部工具。
这样，每次修改后，点击
即可重新部署应用程序。
所谓的热部署（热发布）（下面称为“热部署”），就是说，在web工程发布之后，不可避免的，会遇到修改BUG的问题。现在的热部署就是为了解决这个问题，其功能就是说：在不停止web服务的同时，对jsp和java类进行修改，修改后的效果同时还能够在页面上显示出来。节省了调试时间，提高了效率。不过，修改配置文件是个例外，如果对配置文件做修改，一定要重启web服务。
常用的web服务器一般为tomcat和jboss，现一一做介绍。
1.tomcat热部署
在tomcat中支持热部署有两种方式（在原理上来说，这两种方式是一致的，只是放的位置不同）
a)在catalina_base\conf\catalina\localhost\中依照manager.xml定义一个xml文件，比如我的项目称作sodoperation，我们就可以写一个sodoperation.xml，内容如下：
<context path="/sodoperation" docBase="d:\myportal\sodoperation\src\webapp"/>
其中，path指的是你在tomcat中的项目名称，就像manager一样，docBase是指你的项目所在的web目录。一直到欢迎页面为止（也就是web-inf的前一个目录）。但是一般来说，这个目录中最好不要有中文，如果有的话，可以在文件开始加入
<?xml version='1.0" encoding='utf-8' ?>来试一下，即整个文件变为：
<?xml version='1.0" encoding='utf-8' ?>
<context path="/sodoperation" docBase="d:\myportal\sodoperation\src\webapp"/>
这样就可以了，如果用这种广告，同时使用myeclipse的部署的话，轻易不要remove，这样会使文件都会被删掉，不能持久。所以，建议使用第二种方法。
b)第二种方法和第一种方法在原理上是一致的，其区别就是位置的不同，这次在catalina_base\conf下的server.xml，在文件末加入：
<context path="/sodoperation" docBase="d:\myportal\sodoperation\src\webapp"/>
解释和上面一样，这种方法在启动tomcat后，会在catalina_base\conf\catalina\localhost\中加入一个与第一种方法的文件。这样保证，只要对server.xml不做修改，你可以随便对新生成的文件删除，对热部署没有任何问题
2.jboss热部署
在jboss中做热部署也有两种方法，因为jobss集成了tomcat，也可以说这两种方法是在jobss上的一个修改。
a)修改
/opt/jboss4.3/jboss-as/server/node1/deploy/jboss-web.deployer/context.xml
<Context cookies="true" crossContext="true" antiResourceLocking="true" antiJARLocking="true">
<Manager pathname=""/>
<InstanceListener>org.jboss.web.tomcat.security.RunAsListener</InstanceListener>
</Context>
加上
antiResourceLocking="true" antiJARLocking="true",重启jboss,再用myeclipse Redeploy project的时候就不需要重启,部署完了直接开浏览器预览啦
什么才是软件架构呢？这是一个让人费神的事情，其实呢我觉得“软件架构”至少应该是一个动词，而不是一个专有名词。那么什么才是架构呢？按照我个人的理解，架构这玩意简约不简单。“架构”的过程是一个把抽象转化为具体，其中的美妙不会低于设计师创造艾菲尔铁塔那般的感受。架构的过程会让你变得偏执、疯狂。至少在短时期内会为之寝食难安。那时时候你的世界之后架构二字了。有点长，希望耐心看完～～～ 哈哈！
（PS：尽管架构是与编程语言无关的事情，目前采用Java语言作为例子）
好了，很多人读到这里会怀疑，难道J2EE业界流行的那些SSH、SSI 不是架构吗？我的回答是“NO”，如果硬要如架构沾边的话，那也充其量是一个架构最最低级的一种。在现在的我看来，那些只不过是一些开源框架的简单集成，毫无技术含量可言，对于架构者本人而言，那就是通过固化的配置把这些开源框架进行一定程度的粘合，使其能互相配合完成工作。当然不是否认这个配置的过程，但是这个过程是机械化的学习，丝毫看不到自己的想法，这时的想法都被固化的配置所代替。想当年 偶也是这样子走过来的，所以说呢，现在的我不敢谈论架构的内涵，仅仅是表达出我对架构的一些想法。文以记之。
好了，经过SSH简单的粘合之后，感觉自己很伟大，而且看是跃跃欲试的样子，拿来做项目，这是必经的一部，从程序员到架构是一个设想与实践相结合的一个过程。你自己架构的东西必须通过项目的实践，才能了解是否有改进的余地。我是比较幸运的，一直以来很多项目都是我架构之后在实践呢，在这里感谢那些曾经呆过的公司。是他们给的平台才让我有今天坐在这里写文章的冲动。很多人在使用简单粘合的SSH框架去架构你的项目，你会发现那玩意不适合做项目，太原始了，仿佛回到了石器时代，当然当时你的水平估计也就是才进化到铁器时代吧。
第二阶段了，开始尝试修改SSH搭建的框架，新在而言还是用“框架”来形容比较的贴切一点。通过一轮或者几轮的项目实施，你会发现其实SSH等这些也不是很完美，至少还有很多地方可以改进，这时你已经不再满足于SSH的简单那粘合了，开始尝试去修改加工SSH的粘合。增加一些与SSH直接交互的隔离层代码，这样一来自己项目的代码干净了很多，SSH从入侵式到非入侵式（不可能100%），这已经是一个了不起的飞跃了。你发挥了作为人主观能动性的权利，现在你收获了。那改造的SSH继续项目到项目中去实践，也许改造后的架构在当时的你看来已经很完美了。勇者无惧，Going，开始第二阶段的试水，感觉很好吧，现在的你也许长大一点了，不再从单一的技术去看待项目了，开始考虑项目的开发计划了，有了后则一层的考虑说明你是一位勤奋好学的好孩子，已经不再是单纯的Coder了，面对计划，在看看自己的架构的“框架”，时间紧迫啊。用这玩意尽管目前代码尤雅了很多，但是对于项目小组成员的开发进度还是帮助不大，大家需要学习的东西太多了，Spring、Struts、Hibernate ....... 这对于经验不是很丰富的程序员而言，简直就是噩梦。考虑到这一点，你就开始进入第三阶段的进化了
第三阶段，开始思考屏蔽各种框架集成带来的复杂性，让不懂SSH框架的人也可以快速上手使用，为了达到这一点，又开始废寝忘食的框架重构，增加更多隔离层的代码。这时的框架有点架构的味道了，重构之后的你会洋洋得意，认为这是很完美的了，又去屁颠的拿去项目实战了，这时发现你隔离之后的反而适得其反，百思不得其解啊？什么情况呢？因为你对粘合的框架内核机制不了解，这时的你要虚心学习那些开源框架了，必须是源码级别的阅读，了解他们的内核机制，才能写出更好的隔离层，面对大量的源码，必须有个入口吧，下面我简单吧Spring的入口告诉大家：首先是Spring的Ioc容器，这是核心，主要是看init bean以及loadbean的这点内容是精髓，Aop的话比较深入了，简单一点就是采用动态代理方式实现AOP，在高级的就是采用CgLib的动态代码切入实现。学好这两个之后。在学习Spring MVC 了，这是一个难点，你要吧Mvc的解析流程整理好了，在从每一个环节思考架构为和要多一个这样的环节。（Struts1 太简单了，Struts2太复杂了）。言归正传了，经历一轮源码的洗礼，你脱胎换骨了，SSH对你而言 使用起来游刃有余了。你再也不用为框架不熟悉费力了，这是的你充满了自信，短期内不再关注学习框架了，更多的时间分配给了架构。这时应该进入第四阶段了吧
第四阶段，开始用全新的眼光以及思维去粘合SSH，不错，很多以前的使用不当现在都让你轻易的化解，而且开始考虑使用SSH特有的一些优势去美化的你的架构。现在的你开始考虑的不是开始了，而是如何保证代码的质量问题了，如何保证呢？好吧，找领导申请资源测试吧，对不起，测试团队是很昂贵的，公司很少会配备测试团队的，自测？小弟们才不会如此上心呢？未雨绸缪吧。架构时候为何不架构一套基于SSH的单元测试框架进来呢，好处呢可以脱离容器去测试功能，基于框架的单元测试进入了你的思考范围。等从思考到完全融入架构的时候，你有进入一个新的阶段了。编写测试架构就是为了提高工作效率，目前面向Web的开发，很多测试都需要依赖容器，每次启动容器调试是何等的低效啊。好了集成了自己的测试框架，小弟们高兴了。也会对你刮目相看，至少编写单元测试是一个程序员的义务，保证自己的代码的稳定性，现在你轻松了，每天吧小弟的成果用写的单元测试运行一次。没问题了，不错。下班。
第五阶段，也许这一阶段你的架构开始稳定，很长一段时间都会固化不变，也许到达了一个瓶颈了。单位来了狠多项目，每次你都构建一个基础成，1次 2次 。。。N次，O-MyGod，你开始讨厌这种重复的的劳作了，得，这是你的责任，你是公司的技术一把手，这些肯定有你来做。这是你开始考虑吧基础层与业务层开始解耦。解耦出来的东东作为单独的一个项目存放，自己手动维护，以及版本控制。新建的项目都依赖你的基础项目在做业务开发，现在感觉好多了，不用在为项目每次都搭建了。看着别人在忙，你在一边抽烟偷着乐吧。新在的你体会到一丝分离的快感。这不是就是所谓的程序的解耦吗？这不过你解耦的比较彻底了，从功能和物理上都实现了解耦。恩体会到设计模式的优美了，这是你也会才会发自内心的去迷恋设计模式。这些设计模式是前辈们精华的抽象，不同的模式用于解决各种现实的业务建模。学会是一回事，灵活掌握是另外一回事。关于设计模式，是必经的过程。不仅仅是学会，关键是灵活使用。在合适的场景下选用合适的模式，才是正解。
第六阶段了，通过之前的积累，你已经开始迈出走向架构的第一步了，之前都是为这一步的积累。好比是砍柴，之前都是磨刀了，现在才开始踏上砍柴的路途，哼着儿歌、一路进发。现在刀不是问题了，估计之前的砍柴都是刀不好，注意力都在刀上了，现在刀是没问题了，开始转移到观察柴了，什么柴比较好，砍哪里可以一刀成功，这些多是经验。映射到软件项目就是，开始关于业务建模，不同行业的业务都有其自身的特性，如何针对这些特有的业务特性去架构框架呢，在之前的隔离层上在封装一层业务支撑体系，这个体系可以良好的为业务系统提供强大的动力。通信、政府、金融、医疗、企业、税务、电商。。。。等等，每种行业有有其自身的业务特色，干活去吧，都发现架构的不足了，那就继续完善吧。coding～～～～～好了，针对业务的支撑层也开发完毕了。通过实践运行不错。。。。。 这时你的框架成了公司的某一业务线的开发平台了 。。。。如果继续留在公司，你也许会不断完善其业务建模的支撑体系。可惜，你可能换工作，换工作就意味这换行业。之前积累的业务体系完全行不通啊～～～悲剧了，没办法，从小弟开始做起吧，虚心学习业务基础 。。。。
第七阶段，跳槽太多也不是坏事，经历了几个不同的业务线，你敏锐的嗅觉开始体验到一些独立与业务之外的程序处理规则。如何能搭建一套快速满足不同业务建模的基础模型出来，说到底业务到了底层还是各种流程，只是每个流程节点处理的内容不同（不是工作流，但有其思想）。这时候，你考虑的问题已经不是业务建模了，而是业务之外的东东，这个时候你会忘记SSH这些所谓的框架，这些都是具体的形式体现，现在你需要的是高度的抽象，抽象业务之外，流程图是你研究的核心，因为任何程序其实都可以用流程图去表述，如何开发一套流程配置解析引擎呢，神码业务都是流程上的一个节点而已。只要业务流程化，按照我的配置写入，那么他就可以运行。见山不是山的境界吧哈哈～～～ 到了这一步了，感觉架构才是正的开始了。当然框架是抛不开的，现在面临的问题就是如何利用既有成熟的框架是完成你的这些构想，现在的框架开始考虑自己的分层了，内核层、安全层、缓冲层、ORM层、异常处理机制、国际化机制等等，是不是一项伟大的工程呢，也许Spring就是这样子走过来的。完成了这一阶段的修炼。那么你还不满足吗？恩的确有点就是说不出来，总是有点不满足。现在开始讨论更深层次的话题
第八阶段，架构是有了，你的项目规模也越来越大了，用这个玩意的人也越来越多了，现在考虑的是如何把你的框架能快速推广，市场是检验产品最好的标尺。是否具有可用性。是否能量产程序员（入门级），是否能保证代码的质量、是否能保证出现问题的快速定位，是否能够满足业务扩张的需求、是否满足性能的要求………………….. 咳咳～～一口气说完 太累了！！这些问题是现在需要考虑的问题了。现在架构的推广不仅仅是你的团队在用，也许其他团队也在用，可惜他们无法得到你的亲授，肿么办?开始文档化、标准化、提供实例Demo，这些够了吗？对了 还不够，100个程序员有100中独立风格的编程方式，那就意味这有100个风险的存在，你的架构如何屏蔽或者降低这些风险呢？答案呢？就是要用你的架构去诱导他们尽量编码风格一致。其好处不言而喻啊，统一的编码风格意味这每个程序员都是平等的，从项目角度考虑，那就是把人的风险降低了（包括离职风险）。带来的另外一个好处就是Review代码的快捷，统一风格的编码无需讲解 ……. 自己体会吧。说再多也是没用这个要亲自体会的。到了这一阶段感觉自己是什么？在雕琢一个艺术品？哈哈～～ 这个时候更加需要实践，去完善你的架构。因为现在你的架构是真正的架构吧。这个需要天时地利人和多方面的支撑。能达到这一步的程序员需要的不仅仅是自己的努力了，也需要公司的大环境……………….. 这就是为何什么程序员需要找适合自己发挥的平台。公司成了员工技术发展的桎梏。其结果就是让其平庸，或者释放去更宽广的空间。哇塞。好长久的文章啊。读者看到这里，需要休息休息了，找几张美女图片看看吧～～～也许我的文章让你费力了。现在OK了吗？架构可以了吧。恩 还是有差距的。
第九阶段，见山是山，再次回归项目中来，项目的目的是什么，盈利。这是最本质的东西。偏执也好、狂热也罢。这是一条基准，违背这一原则的任何架构都是失败的架构。盈利不是结果，而是项目每一步风险规避的积累。架构这是需要考虑的就是如何让架构能在每一阶段都能起到规避风险的功能呢？这是一个比较空洞的概念。但是这是必须考虑的，涉及到架构任何一个细微之处的调整。从项目开始到投产到维护。。。。这个过程，架构如何能保证每一阶段的风险规避呢。或者提供解决风险的更好的方法 ………………………..
上述为架构师修炼的过程，架构是具有中国特色的架构。不同于国外，一些老外闲的蛋疼去研究，我们都是苦逼的项目中提炼自己，利用8小时睡觉，8小时工作之外的时间去完成这一修炼，上面的文字也是本人的程序开发的成长历史，抛砖引玉吧～～希望能对开始“架构”你提供一些参考。最后浓缩几个字，算是文章的目的！
盈利、重构、坚持 。
关于标题，我也开始附庸文雅了。哈哈！话说软件架构是本人这些年的一些积累，在此做一点分享，希望对即将做架构或者是正在架构的 ITer 一些参考，也许见解浅薄，还望大家多多包涵，如有异议，可私聊，禁止拍砖。
说起架构可不是一件简单的事情，他是一个很庞大的系统骨架，但是面对到手的软件需求，你是如何设计一个合理的架构呢？原来架构这玩意也是分第一步、第二步、第三步 ........ 以此类推，不能急于求成，这样容易扯着蛋。要做到手中无剑，心中有剑的境界，并非一朝一夕的努力，需要长期项目的实践，经历无数次的失败与重构之后再能叩开“软件架构”这个大门的一丝门缝，从来一窥汪洋。
拿到一个软件的合同或者是用户的最原始的需求，很多架构师的第一直觉就是关注软件本身的功能，有哪些功能，适合采用哪些技术选型。这对于大多数人而言，的确是没有错误。但是在这之前还一点需要去做的事情 ...... 不知道大家想到了吗？架构是基于什么环境呢？这一点在架构之前不知道读者现在是否思考过这个问题。所谓的架构首先要了解软件运行的软硬件以及网络环境。之后明确了这一点才能考虑下一步的事情，否则就有点闭门造车的感觉了。
好了，说到运行环境，这是就要从硬件环境与软件环境分别对待了，例如：
1、硬件是采用几层架构啊，是采用集群还是单机部署呢？ 典型的网络架构是Http服务器 + Web服务器 + 数据库服务器 。比较厉害的就是这些都放在一个机器上 哈哈～～～
2、软件运行的网络环境如何，是基于局域网还是公网呢？是否存在隔离的情况
3、硬件是什么机器呢？IBM刀片 还是 AIX系列呢
4、系统的灾备设备是什么，如何运作
......... 等等诸如此类的硬件环境首先要了解。
硬件明确了，下来考虑软件环境
1、软件运行的环境是 Window 、Linux、Unix ，是32位 /还是 64位
2、软件运行的Web服务器神码 WebSphere？Weblogic、Jboss、Tomcat、GlashFish还是别的？版本号是多少，支持的J2EE规范是多少。
3、JVM是什么版本，是全新部署 还是复用甲方已经存在的软件环境呢？
4、软件是否与其他软件有数据交互，交互采用什么介质
5、采用什么数据库，版本是多少？
.......... 这些是作为软件环境需要考虑的一些基础性的问题
通过上述简单的文字，好像大家有点明白了吧，其实这种事情，很简单的，只要平时多注意点就OK了，否则等开发后去现场实施才发现什么都不配套啊。如果在架构开始之前，你已经关注这一点了，恭喜了 说明你已经具备作为架构师最起码的嗅觉了。
上述的那些问题或多或少影响架构本身，架构是基于单机还是基于集群，这是两种迥然不同的架构模式，很多天真的童鞋认为 单机与集群架构差不多，复制一套在部署一台机器就OK了。其实则不然。二者存在太多的不同了，我举一些简单的例子哈：
在Java行业，很多开源软件使用很频繁，这些开源软件本身集成了Cache，用于提高性能，单系统是单机运行的时候，一切都正常，做了集群出现问题了。Cache 惹得祸，因为你的集群并没有把框架内部自带的缓存集群化，还是保持各自独立的状态，一用户通过A服务器修改了内容，并且刷新了Cache，但是作为集群的B服务器感知不到A对Cache的变化，依旧从自身的缓存中获取“脏数据”，这时其他用访问B服务器读到的值，其实是A用户通过A服务器修改之前的值。很绕吧。希望能理解。瓦咔咔～～～这是架构如果采用cache 需要重写自己的Cache框架，必须屏蔽开源项目中自带的Cached，否则出了问题都让你莫名其妙？
数据库部署是单机还是双机，是热备还是冷备，数据访问需要读写分离吗？如果硬件不支持数据库热切换，如何采用程序实现数据库的热切换？这些都是架构层次的需要直接面对的问题？ 架构师们 你们心里有底吗？
与甲方内部的其他系统是采用什么通信方式？Socket、WS、RMI，访问的系统之间是否有防火墙隔离，采用什么技术可以穿透防火墙阻拦呢？
以后的系统如何快速部署到对甲方的真实环境中，是手动部署还是Ant自动部署？如何做到持续集成？发送错误如何回退？
......................... 现在是不是觉得有点复杂呢？其实没关系，成长有两种，一种是汲取别人成功的经验转为为自己的能力，另外一种是尝试失败，从经历失败中成长，本人呢二者兼有，前几年都是从失败中成长，但是随着时间的推移，发现这样的代价真的是很大。开始虚心学习前人的经验，从而转化为自己的知识。
掌握软件运行的软硬件环境是作为架构的第一步，切记切记！
上述文字，仅仅是作为软件架构之前需要考虑的一些大概，还有很多细节其实我也不是很了解，如有补充请回帖瓦咔咔～～～～ 软件架构 是一件艺术品～～～ 这是我对架构的感性认识。
每次架构完我都会在一段时间把它当作是完美的艺术品去欣赏，过了新鲜期后，发现很多问题，直接重构 这样循环不已 ............. 每次的迭代 都让自己收获很多！