.NET企业级应用架构设计系列之技术选型

本文属spanzhang（张友邦）原创，发布地址为：http://blog.csdn.net/spanzhang。转载或引用请注明原文之出处，谢谢！

这里说的技术选型实际上是指技术方向的选择，或者叫平台方案的选择，也或者叫技术路线等，总之是大方向的把握。假定项目背景是要做一个中型WEB系统，公司组建新的技术团队以及运营团队来运作。基于这个模糊的项目背景，看看我们能得到些什么。

首先我们想到的是目标系统的特征：

A) 稳定性及可服务性：这是对软件系统最基本的要求，为客户提供稳定的服务是业务开展的最基础的保证。这是和客户的耐心作战，是赢取客户和扩展业务纵深度的前提。很难想象有人会在一个不稳定的系统面前花费精力去做一件本该很容易的事情。

B) 整体性能及升级扩容余地：虽然很多时候对系统压力的担心是多余的，但系统架构必须有一定的应付突发事故的能力以及具备足够的升级扩容空间来满足潜在的业务扩张，不然总会有手忙脚乱的一天。系统性能是可服务性的一方面，而升级扩容空间是系统持续长期运作的保障。

C) 可维护性及可管理性：除开灵活的系统实现带来的可维护性，系统软件和硬件设备的选择同样对可维护性产生重要的影响。这需要结合团队的人员架构来共同考虑。在维护性和管理性方面的问题必然带来升级扩容和应对业务变化方面的巨大困难。

再者，我们会想想想在市面上的解决方案提供商都能给我们什么：

目前在WEB系统方面流行的主要是Java和.NET两个平台级的软件技术方向，它们之所以流行是因为在许许多多的场合被证明能保障较高的生产效率。两者提供的解决方案都表现不错，只不过可能达到相同的目标所带来的总体拥有成本不一样而已。也就是说，它们在解决方案特征方面差异不大。一些重点比对项参考如下：

	[align=center]Java[/align]	[align=center].NET[/align]	[align=center]备注[/align]
可移植性	[align=left]好，能在大多数操作系统平台上顺利移植。[/align]	差，只有Windows兼容平台上移植。	移植性对于最终客户来说没有多大意义，但Java运行于Linux系统能降低投入成本。
厂商支持	[align=left]多，有许多服务器厂商支持Java。[/align]	少，但呈现增多的趋势。
社区技术支持	[align=left]多，有许许多多的社区和专业的技术支持厂商。[/align]	多，单纯Microsoft一家提供的技术文档就已经相当丰富。	微软的.NET战略不止是技术上的战略，也是针对人的战略。
开源产品	[align=left]多，而且有很多非常成熟的产品级开源项目。[/align]	少，和Microsoft一家独断有历史因素。	开源软件的技术支持整体上都不完备。
社会人力资源	[align=left]多，但两极分化严重。[/align]	多，但做过深入开发的人少，特别是.NET 2.0和3.0平台。	结论来自某人才招聘网统计资料。

另外，我们会想想我们的人手，也就是说开发团队方面我们拥有哪些方面的人和技术。整个系统的开发需要团队的力量，架构设计和技术方向选型必须关注人的因素。只有合适的人做合适的事情才能产生预期的高位价值。人力资源和技术团队架构在选择方向上起重要作用，需要结合人力资源市场的人才分布来思考。团队的历史经验对架构设计有很大影响，因为历史经验可以带来架构重用以及减少学习新技术和新工具的曲线。另外，团队的素质决定了软件过程能否顺利实施。所以，团队在架构设计中占有相当的分量。（这里，绝不要把架构设计孤立起来看待，它不只是规划期的事情，因为架构设计是对未来的把握，任何影响因素都要尽可能的考虑进来，特别是一些重大影响因素）。

上面的三点，是一个相互联系的整体，合在一起就成了一个三角形，我把它叫做“架构设计三角形”：



图1：架构设计三角形

接下来，结合一些指导原则，它们是许许多多软件系统成功失败的经验总结。其实，看起来也是非常直接的，很容易理解和接受：

A) 寻找最容易找到的技术人员组建团队。这样可以将人员流动对项目的影响减到最小，同时也可以快速的组建团队进入开发期。目前，IT人力资源市场上，Java方向和.NET方向是两个主要的企业级开发方向，多数IT人才也集中在这两块。

B) 使用成熟技术。显然，Java和.NET都是成熟的技术。在软件解决方案方面都有各自的长处和优点，但对企业级应用而言都可以胜任。通过这几年的发展，.NET和Java都形成了丰富的社会技术资源。.NET经过1.0到3.5的发展，在企业级应用方面已经在实践中变得更加的成熟了。

C) 使用团队熟悉的技术。避免过于陡峭的学习曲线，可以把对开发人员的的要求降至更低。但这并不等于使用最简单的技术来完成复杂庞大的企业级应用，应该是在易学易用的前提下构造稳定可维护的目标系统。冒着危险选择不成熟的技术或者不熟悉的技术都只能得到一个漏洞百出的系统。

D) 侧重于开发期的规划与管理，开发稳定可维护的产品。对团队的素质侧重点放在沟通和编写稳定可维护代码的视角，避免目标系统走向紊乱而不可控的地步，从而导致最终失败的结局。

结合具体实际情况，结论很容易得出了。考虑的方向是：目标系统 + 技术团队 =〉 解决方案。详细的结论就不写了，我这次为项目选择的是.NET 2.0平台。