.NET企业级应用架构设计系列

65 阅读 0 评论 43 点赞

我是靠谱客的博主粗暴热狗，最近开发中收集的这篇文章主要介绍.NET企业级应用架构设计系列，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

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

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

首先我们想到的是目标系统的特征：
A) 稳定性及可服务性：这是对软件系统最基本的要求，为客户提供稳定的服务是业务开展的最基础的保证。这是和客户的耐心作战，是赢取客户和扩展业务纵深度的前提。很难想象有人会在一个不稳定的系统面前花费精力去做一件本该很容易的事情。
B) 整体性能及升级扩容余地：虽然很多时候对系统压力的担心是多余的，但系统架构必须有一定的应付突发事故的能力以及具备足够的升级扩容空间来满足潜在的业务扩张，不然总会有手忙脚乱的一天。系统性能是可服务性的一方面，而升级扩容空间是系统持续长期运作的保障。
C) 可维护性及可管理性：除开灵活的系统实现带来的可维护性，系统软件和硬件设备的选择同样对可维护性产生重要的影响。这需要结合团队的人员架构来共同考虑。在维护性和管理性方面的问题必然带来升级扩容和应对业务变化方面的巨大困难。

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

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

二、.NET企业级应用架构设计系列之应用服务器

这里要说到的是关于三层架构中的应用服务器。对于电子商务网站来说，成熟的架构基本上都是采用分层式的。分层的结构一方面适合人脑的思维方式，另一方面在解决扩展性方面非常有效。目前市面上的各大解决方案提供商在电子商务和一般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的方式发布对象。

总的来说，应用服务器的架构是一个演化模型，可以随着需求和实际负载的变化实行平滑过渡。当应用服务器的横向扩展也无法应付更大的负载的时候，实际的性能瓶颈已经转移到了系统的其它地方，比如磁盘访问或接入带宽等。

三、.NET企业级应用架构设计系列之结尾篇

首先说点废话。这段时间有挺多新朋友通过CSDN联系到我，大部分是希望我能给他们的学习和工作提点建议。我很感谢这些朋友对我的兴趣，也感谢他们对我的信任。我总是告诉他们一些听过很多遍的道理，现在想想，也许大家以为我在敷衍。但是请一定相信一句话：之所以常常重复，是因为它真的重要。

对于技术上的提高，不外乎多学习、多实践、多思考。学习可以是看书或者上网，看书是大餐而上网就像是快餐。我家里书架上的书已经把书架装得满满的了，以至于最后放了许多不常看或过时了的书到酒柜里。看书并不是要一字一句的看，要有快速浏览反复研究的习惯。另外就是多实践，这个可能是个程序员都能体会到，脱离了实践就无从谈软件开发。实践有多种形式，一是系统的实践，还有测试性的实践，还有熟悉性的实践。针对不同的目的，有不同的方式方法来实践。最后就是多思考，反复琢磨。说得最直接一点，愚者千虑必有一得。不要偷懒，常做重构，并思考重构前后的得失。我一直觉得完成一次精良的重构会让人精神焕发，如果你没有这样的感觉，我只能说你可能不适合写程序。

软件开发，工夫在诗外。当实践的多了，就会觉得以前认为重要的东西慢慢的已经不那么重要了。做一个技术无关的开发者，品位生活和人生的道理。多发展业余爱好，比如画画或者书法或者旅游、摄影之类的。我们需要养成良好的习惯，写字的时候尽量不要有错别字。多看看古典名著、小说散文之类的。还要记得给自己找个漂亮贤惠的女朋友，如果没有家庭而只获得了一堆代码，我想这样的人生并不算完整。

废话说太多了，说说这篇文字的主题。以前发了三篇关于.NET企业级应用架构方面的文章，很多网友以为发完了。其实还没有，这里才是这个系列的终结篇。这里还是围绕着中间层来展开的，顺便说到了前端的状态服务器。中间层承载着许多东西，它前要面对接入服务器（可能是WEB）后面要面对数据持久化系统，所以要稍微复杂一点点了。

层间调用机制

层间调用涉及到的是跨进程的访问，包括前端系统和应用服务器的交互以及应用服务器和后台数据库的交互。在通常的分布式部署方案中，这样的跨进程调用实际上是跨机器的调用，会对网络环境提出一定的要求。

应用服务器对前端表示层提供的接口隐藏了所有后端的处理逻辑，包括业务逻辑以及数据持久化等。前端应用和应用服务器之间的调用效率直接决定了外在的系统效率，必须采用高效的机制以保证前端服务器能最大限度的发挥计算能力。.NET平台是一个完全面向对象的分布式平台，它提供了许多优秀的特性以实现可扩展的大型分布式系统，其中包括异步调用机制。

通过异步调用Web Service或远程对象的方式可以发挥IIS线程池的最大潜力，因为一台配置固定的IIS Web服务器能运行的最大线程数是有限的，通常不应该配置过高。ASP.NET 2.0的页面生命周期中允许注册异步调用事件，对应用服务器的调用可以安排为异步执行。其实，应该在尽量多的地方采用异步调用机制，包括数据库访问。这样可以提高系统整体的并行度，从而达到更大的系统吞吐量。如果表示层对业务逻辑层采用同步访问的方式，就没有必要将业务逻辑层单独放在应用服务器上运行，将业务逻辑和表示层放在同一个进程空间中运行还能提高部分性能。只有采用异步调用方式才能真正体现出应用服务器的价值，避免服务器处于假忙碌状态。

前端系统调用应用服务器的Web Service的时候要注意一个小问题：HTTP双连接限制。连接到web资源的默认双连接限制可以通过一个名为connectionmanagement的配置元素来控制。connectionmanagement设置允许添加要让其采用非默认连接限制的站点的名称。

数据访问层

之所以用“数据访问层”而不是数据持久层，是因为我通常将数据库系统作为数据持久层，数据访问层是位于应用服务器和数据持久层之间的调用接口，它对外隐藏了数据持久层的细节。Java应用在数据访问层通常采用O-R Mapping来做，业务逻辑被实现为许许多多的业务实体。.NET本身没有对O-R Mapping提供任何支持，对数据访问层提供的是一套底层API，包括ADO.NET和Data Access Application Block。

在.NET开源社区，有几个开源框架提供了ORM支持，比如NHibernate、iBATIS.NET。NHibernate诞生于.NET 1.0时代，是一种“全自动”的ORM框架，它无需开发人员编写任何SQL语句。而iBATIS.NET是一种更加灵活的“半自动”数据映射持久化框架（Data Mapper Framework），以SQL开发的工作量和数据库移植性上的让步给系统设计提供了更大的自由空间。另外，DevExpress XPO是一款商业ORM产品，是一个完全透明的数据持久层解决方案，无须建表、建字段、取数据之类的所有数据库相关操作，但需要200$的价格。

使用ORM框架有两个好处，一是可以实现流行数据库的移植，开发人员编写的代码是数据库无关的。这样就可以方便的在数据库之间切换，有利于软件开发商应对众多客户的不同需求。另一个好处是开发人员可以不用了解SQL的细节，降低了SQL方面的学习曲线。同时把实现关注点集中在业务逻辑上，而不是数据持久化上。再者，ORM提供的是一个面向对象的体系，可以采用更多的面向对象思维来实现系统的业务逻辑。

但任何灵活的东西总是有副作用的，ORM的副作用主要表现在性能上。ORM必然导致更多的网络传输，因为数据持久在ORM里面通常被分解成了许许多多的数据库调用。同时，使用ORM也不利于数据库引擎发挥计算能力，数据库变成了一个“瘦服务器”。虽然ORM框架能屏蔽SQL细节，降低了SQL的学习曲线，但同时却带来了框架本身的学习曲线问题。再者，由于对系统内部处理细节的不熟悉，开发人员难以写出高效的代码。另外，ORM框架如果只是对数据库表的映射的话，并没有节约多少开发时间，而且数据库设计的变动会经常引起代码同步的问题。

整体上来说，ORM提供的是一种灵活的高端解决方案，适合软件企业在长期开发的过程中为应对各种不同的客户需求而实现平滑的数据库切换。这也是为什么大多数Java应用系统采用ORM的原因，因为Java体系是一个可移植的解决方案，可以为软件企业带来“客户无关”的开发能力。但可移植总是带来性能上的下降（没人愿意承认），虽然不可移植的代码不一定绝对快过可移植代码。既然选择.NET了，可能在移植性上本身就不是很在乎了。

状态服务器

状态保存的第一个原则是尽量保存少的数据，对于大对象不推荐保存为状态。在实现过程中需要对状态保存做一层封装，让状态保存和其它实现逻辑分离开来。对于.NET状态保存机制，涉及到采用进程内还是采用进程外的问题。

进程外状态保存可以确保应用更新的时候不会影响在线用户的状态。因为电子商务网站的业务变化相对来说多一些，经常会有更改程序的可能。如果采用进程内状态保存机制，每次部署更新的时候所有旧状态都将被清空。

进程外状态保存实现的是一个无共享架构（Share Nothing Architecture），可以增加系统的分布性，有利于提升系统的横向扩展能力。Web Farm中的服务器也将成为真正对等的实体，负载均衡器可以采用更加简单的角度算法。在初期系统服务器设备不足的情况下可以和应用服务器或者WEB服务器部署在同一台机器上。

但进程外保存可能引入性能问题，因为中间有跨进程的数据交换。进程外保存还带来了维护上的麻烦，部署的时候也增加了复杂度。但对本案来说这些都不是问题，采用尽量小的数据保存可以减小性能上的影响，维护和部署的问题也都是时间问题而已。

开发期可以不用对采用何种机制保存状态作太多处理，只需要在部署的时候做相应的调整即可。需要注意的是，只有Serializable对象可以进程外保存为状态。初期系统压力不大的时候可以采用ASP.NET State Server这样的轻量级方案，系统负载增加后可以采用进程外SQL Server来做状态服务器。

服务器群集

服务器群集可以提供一个高可用、高可靠、可伸缩的计算环境。Windows Server 2003 Enterprise Edition提供了NLB以及MSCS支持负载均衡以及服务器集群策略。这是一种软件解决方案，在系统初期压力不大的情况下可以采用此种方式来进行系统横向扩展（Scale Out）。随着系统负载不断增加，可以使用更多的服务器群集和硬件负载均衡器来分配负载。最终的系统性能瓶颈将会推到磁盘读写设备上。

本系统的服务器共有四种：前端WEB服务器，旁边的状态服务器，中间的应用服务器，后端的数据库服务器。其中，状态服务器没必要做集群，因为状态服务一方面要为所有的消费者提供同一的状态数据，另一方面因为状态数据一般都很小。其余几种服务器都是系统中的关键设施，任何一个环节出现问题都可能导致系统整体表现的急剧下降。

WEB服务器群集构建的是展现层的对等计算体系（WEB Farm），它的吞吐量直接决定了系统的整体性能。应用服务器的群集和WEB服务器差不多，所有计算实体均为对等单元。这样，单台WEB服务器和应用服务器都可以随时从群集中分离出来进行离线更新（在线更新有可能会失败或者引起客户端表现异常）。但这需要集群软件或集群硬件的支持，Windows 2003 Server NLB可以允许集群运行状态下进行扩展或压缩。数据库方面，SQL Server 2005可以配置为最多8个结点的集群。

张友邦的专栏