Mikel
其实很久以前就想写点关于架构设计方面的东西，一直以来都没有最终落到实处。正好这段时间在做一个WEB架构，决定把和架构设计有关的内容写成一个系列文章。算是回馈CSDN提供的各种免费服务，同时给初学架构设计的朋友一点小小的提示。在我工作的六年多时间里，除了第一年是纯粹编码以外，其余时间都在做和架构设计有关的工作，当然也还一直在写各种各样的代码。也就是说，我本人其实也只有不多的经验可以分享，所以文中肯定有一些观点不能让所有人都认同。如有异议，可以发邮件和我讨论。
1、架构设计是件容易的事情。
对于不熟悉的或者没有架构设计经验的程序员来说，架构设计可能看起来很神秘，不知道究竟该如何入手，也不清楚该注意些什么问题。其实架构设计也只是软件系统开发中的一个环节而已，整个软件系统的开发和维护以及变更还涉及到很多事情，包括技术、团队、沟通、市场、环境等等。在分析和设计架构的时候也是有很多套路和原则的，只要我们按照一些最基本最简单的思路和方向去分析问题，就能得到一个大体满足实际情况的架构。前面我曾写过两篇关于人脑思考复杂系统的文章：《破解复杂性》以及《和SOA一起对抗复杂性》。这是软件开发中的方法论问题，可以贯穿于软件开发的多个阶段，包括架构设计、编码实现、后期维护等。掌握一定的原则，对架构设计能带来事半功倍的效果。
2、架构设计不是件简单的事情。
虽然架构设计是件容易的事情，但也不是大多数没有架构设计经验的程序员想象中的画画框图那么简单。把几台服务器一摆，每一台服务器运行什么软件分配好，然后用网络连接起来，似乎每个企业级应用都是如此简间单单的几步。但现实生活中的软件系统实实在在可以用复杂大系统来形容，从规划、开发、维护和变更涉及到许许多多的人和事。架构设计就是要在规划阶段都把后面的事情尽量把握进来，要为稳定性努力，还要为可维护性、扩扩展性以及诸多的性能指标而思前想后。除了技术上的考虑，还要考虑人的因素，包括人员的组织、软件过程的组织、团队的协作和沟通等。也许你会说那些都是项目管理上的事，和架构设计没关系。但一个团队成员无法实现的架构没有任何实际意义。另外，现在是解决方案满天飞的时代，很多事情都可以用多种途径来解决，如何在五花八门的选项中间做出决定，可能让很多人都头疼过。自己的经验、团队的素质、领导的要求、环境的压力以及市场的变化，够折腾了。
3、架构设计需要方法论的指导
所以，总的说来，在正确的方法论指导下，复杂的架构设计其实是件容易的事情。这些方法论的思路包括，至上而下的分析，关注点分离，横向/纵向模块划分等。有时候觉得架构设计决策就像是浏览Google Earth，实际上反映的是一种自上而下的决策过程。对问题的分解是软件思维的基本素质，可以有横向分解、纵向分解以及两者的结合。能不能有效快速准确的分解问题，是软件开发人员需要首先训练的项目。另外，架构设计中图形化的工具非常有用，它能把系统的结构和运作机制以图形化的方式表达出来。也正因为这样才有了架构设计就是画框图的误会。再者，架构设计是一个工程性质的工作，对当事人的实际从业经验要求较高。只有对市场上的各种技术有较全面的了解之后才有可能设计出一个尽可能满足各种设计约束的架构。
这里说的技术选型实际上是指技术方向的选择，或者叫平台方案的选择，也或者叫技术路线等，总之是大方向的把握。假定项目背景是要做一个中型WEB系统，公司组建新的技术团队以及运营团队来运作。基于这个模糊的项目背景，看看我们能得到些什么。
首先我们想到的是目标系统的特征：
A) 稳定性及可服务性：这是对软件系统最基本的要求，为客户提供稳定的服务是业务开展的最基础的保证。这是和客户的耐心作战，是赢取客户和扩展业务纵深度的前提。很难想象有人会在一个不稳定的系统面前花费精力去做一件本该很容易的事情。
B) 整体性能及升级扩容余地：虽然很多时候对系统压力的担心是多余的，但系统架构必须有一定的应付突发事故的能力以及具备足够的升级扩容空间来满足潜在的业务扩张，不然总会有手忙脚乱的一天。系统性能是可服务性的一方面，而升级扩容空间是系统持续长期运作的保障。
C) 可维护性及可管理性：除开灵活的系统实现带来的可维护性，系统软件和硬件设备的选择同样对可维护性产生重要的影响。这需要结合团队的人员架构来共同考虑。在维护性和管理性方面的问题必然带来升级扩容和应对业务变化方面的巨大困难。
再者，我们会想想想在市面上的解决方案提供商都能给我们什么：
目前在WEB系统方面流行的主要是Java和.NET两个平台级的软件技术方向，它们之所以流行是因为在许许多多的场合被证明能保障较高的生产效率。两者提供的解决方案都表现不错，只不过可能达到相同的目标所带来的总体拥有成本不一样而已。也就是说，它们在解决方案特征方面差异不大。一些重点比对项参考如下：
结论来自某人才招聘网统计资料。
另外，我们会想想我们的人手，也就是说开发团队方面我们拥有哪些方面的人和技术。整个系统的开发需要团队的力量，架构设计和技术方向选型必须关注人的因素。只有合适的人做合适的事情才能产生预期的高位价值。人力资源和技术团队架构在选择方向上起重要作用，需要结合人力资源市场的人才分布来思考。团队的历史经验对架构设计有很大影响，因为历史经验可以带来架构重用以及减少学习新技术和新工具的曲线。另外，团队的素质决定了软件过程能否顺利实施。所以，团队在架构设计中占有相当的分量。（这里，绝不要把架构设计孤立起来看待，它不只是规划期的事情，因为架构设计是对未来的把握，任何影响因素都要尽可能的考虑进来，特别是一些重大影响因素）。
上面的三点，是一个相互联系的整体，合在一起就成了一个三角形，我把它叫做“架构设计三角形”：
图1：架构设计三角形
接下来，结合一些指导原则，它们是许许多多软件系统成功失败的经验总结。其实，看起来也是非常直接的，很容易理解和接受：
A) 寻找最容易找到的技术人员组建团队。这样可以将人员流动对项目的影响减到最小，同时也可以快速的组建团队进入开发期。目前，IT人力资源市场上，Java方向和.NET方向是两个主要的企业级开发方向，多数IT人才也集中在这两块。
B) 使用成熟技术。显然，Java和.NET都是成熟的技术。在软件解决方案方面都有各自的长处和优点，但对企业级应用而言都可以胜任。通过这几年的发展，. NET和Java都形成了丰富的社会技术资源。.NET经过1.0到3.5的发展，在企业级应用方面已经在实践中变得更加的成熟了。
C) 使用团队熟悉的技术。避免过于陡峭的学习曲线，可以把对开发人员的的要求降至更低。但这并不等于使用最简单的技术来完成复杂庞大的企业级应用，应该是在易学易用的前提下构造稳定可维护的目标系统。冒着危险选择不成熟的技术或者不熟悉的技术都只能得到一个漏洞百出的系统。
D) 侧重于开发期的规划与管理，开发稳定可维护的产品。对团队的素质侧重点放在沟通和编写稳定可维护代码的视角，避免目标系统走向紊乱而不可控的地步，从而导致最终失败的结局。
结合具体实际情况，结论很容易得出了。考虑的方向是：目标系统 + 技术团队 =〉 解决方案。详细的结论就不写了，我这次为项目选择的是.NET 2.0平台。
这里要说到的是关于三层架构中的应用服务器。对于电子商务网站来说，成熟的架构基本上都是采用分层式的。分层的结构一方面适合人脑的思维方式，另一方面在解决扩展性方面非常有效。目前市面上的各大解决方案提供商在电子商务和一般WEB应用领域都有相应的分层解决方案，软件架构设计在这一方面几乎不存在多少争议。
出于对可扩展性以及可维护性的考虑，对业务逻辑的解耦得到的便是应用服务器。这样的情况在软件系统中非常常见，在任何情况下都能通过额外一层间接来获得灵活性，但可能会引入潜在的性能问题。在Windows Server 2008问世之前的.NET平台没有应用服务器的专门产品，架设应用服务器可以有多种可选的方案。常用的.NET应用服务器方案有：
A) 使用IIS驻留ASP.NET Web Service
B) 使用.NET Remoting提供远程对象
C) 使用Enterprise Services (COM+)提供跨进程对象调用
这三种方式中，采用TCP/Binary通道的.NET Remoting是三个方案中性能最好的，而采用ASP.NET Web Service则能提供更多的跨平台特性。在性能对比上，ASP.NET Web Service大约是TCP/Binary .NET Remoting的60%左右（和传递的数据有关），这中间的差异来自于网络传输上，ASP.NET Web Service会花费较多时间在大对象的数据串行化（Serialization）上。二进制格式的Remoting实现也提供了对象级（包括单件—— singleton特性）的支持，在性能要求占主导地位的方案中较多采用。
面对这个情况，最好的解决方法是在实现的时候提供一个更加灵活的架构来随时调整策略而让调整的代价保持在最小。也就是说，把系统的核心逻辑实现为一个对象群，然后通过facet方式以最小的努力适配到不同的调用接口上。当然，最初是以SOA的方式发布WEB服务给客户端调用，以尽量实现可移植的环境。如果发现这种模式成为了系统中的性能瓶颈，则改为TCP/Binary .NET Remoting的方式发布对象。
总的来说，应用服务器的架构是一个演化模型，可以随着需求和实际负载的变化实行平滑过渡。当应用服务器的横向扩展也无法应付更大的负载的时候，实际的性能瓶颈已经转移到了系统的其它地方，比如磁盘访问或接入带宽等。
