当然，Premake4也有自己的缺陷，目前还不支持自定义规则，所以如果项目中有用到什么自动生成源文件的特性就比较麻烦了，比如这次说到的protobuf要用protoc编译.proto文件生成.pb.cc和.pb.h文件，另外QT也有类似的需求，就我之前某项目中，也使用了tolua++生成过c++的lua接口文件。

但是，Premake4虽然还不支持自定义规则，但是总算有一个prebuildcommands可以用，于是研究了一下，自制了一个.proto文件的"编译规则":

function protobufs(pat)
  local list = {}
  if type(pat) == "string" then
    list[1] = pat;
  elseif type(pat) == "table" then
    list = pat;
  end
  local proj = project();
  for _,pat in ipairs(list) do
    local protofiles = os.matchfiles(pat);
    for _,protofile in ipairs(protofiles) do
      local basename = path.getbasename(protofile);
      local sourcedir = proj.basedir.."/"..path.getdirectory(protofile);
      local sourcefile = proj.basedir.."/"..protofile;
      local targetdir = "$(OBJDIR)/proto/"..path.getdirectory(protofile);
      local targetfile = targetdir.."/"..basename..".pb.cc";
      prebuildcommands {
        "@mkdir -p "..targetdir,
        "@test "..sourcefile.." \\\n"
        .."\t\t\t -ot "..targetfile.." || \\\n"
        .."\t\t( echo protoc "..protofile.." && \\\n"
        .."\t\tprotoc --cpp_out "..targetdir.."\\\n"
        .."\t\t\t"..sourcefile.."\\\n"
        .."\t\t\t".." -I"..sourcedir.." ) \\\n"
      }
      files {
        path.join(targetdir, basename..".pb.h"),
        path.join(targetdir, basename..".pb.cc"),
      }
      includedirs { targetdir }
    end
  end
end

使用方法呢，就是把上面的代码保存到protobuf.lua里面，然后在premake4.lua最开始的时候，调用

dofile "protobuf.lua"

然后在项目定义的时候，使用

protobufs { "**/*.proto" }

就可以了。

• 框架, pomelo的核心, 与以往单进程的游戏框架不同, 它是高性能、分布式的游戏服务器框架，并且使用很简单。
• 库, 包括了开发游戏的常用工具库， 如人工智能(ai)、寻路、aoi等。
• 工具包, 包括管理控制台、 命令行工具、压力测试工具等。

pomelo的主要特性：

• 快速、易上手的游戏开发模型和API。
• 高可伸缩的多进程架构， 支持MMO的场景分区和其它各类分区策略。
• 方便的服务器扩展机制，可快速扩展服务器类型和数量。
• 方便的请求、响应、广播、服务器通讯机制， 无需任何配置。
• 注重性能，在性能、可伸缩性上做了大量的测试、优化。
• 提供了较多扩展组件，包括游戏开发常用的库和工具包。
• 提供了完整的MMO demo代码(客户端html5)，可以作为很好的开发参考。
• 基于socket.io开发，支持socket.io支持的多种语言客户端。

网易pomelo开发团队在项目主页上列举了推荐pomelo的理由：

高并发、高实时的游戏服务器的开发是很复杂的工作。跟Web应用一样，一个好的开源容器或开发框架可以大大减少游戏开发的复杂性，让开发变得更加容易。遗憾的是目前在游戏服务器开发领域一直没有太好的开源解决方案。 pomelo将填补这个空白， 打造一款完全开源的高性能（并发）游戏服务器框架。

pomelo的优势有以下几点：

• 架构的可伸缩性好。 采用多进程单线程的运行架构，扩展服务器非常方便， Node.js的网络IO优势提供了高可伸缩性。
• 使用非常容易， 开发模型与Web应用的开发类似，基于convention over configuration的理念， 几乎零配置， API的设计也很精简， 很容易上手。
• 框架的松耦合和可扩展性好， 遵循Node.js微模块的原则， framework本身只有很少的代码，所有component、库、工具都可以用npm module的形式扩展进来。任何第三方都可以根据自己的需要开发自定义module。
• 提供完整的开源MMO游戏demo参考(基于HTML 5)。 一个超过1万行代码的游戏demo，使开发者可以随时借鉴demo的设计与开发思路。

pomelo为什么采用Node.js开发？

Node.js自身特点与游戏服务器的特性惊人的吻合。 在Node.js的官方定义中， fast、scalable、realtime、network这几个特性都非常符合游戏服务器的要求。游戏服务器是个网络密集型的应用，对实时性要求极高，而Node.js在网络io上的优势也完全可以满足这点。使用Node.js开发游戏服务器的优势总结：

• io与可伸缩性的优势。io密集型的应用采用Node.js是最合适的， 可达到最好的可伸缩性。
• 多进程单线程的应用架构。Node.js天生采用单线程， 使它在处理复杂逻辑的时候无需考虑线程同步、锁、死锁等一系列问题， 减少了很多逻辑错误。 由多进程Node.js组成的服务器群是最理想的应用架构。
• 语言优势。使用javascript开发可以实现快速迭代，如果客户端使用HTML 5，更可实现代码共用。

网易pomelo开发团队介绍了游戏服务器的运行架构：

一个真正高可扩展的游戏运行架构必须是多进程的。Google的gritsgame,、Mozilla的browserquest 都采用了Node.js作为游戏服务器开发语言， 但它们都采用了单进程的Node.js服务器，缺乏扩展性，这使它们可以支撑的在线用户数量是很有限的（这两个游戏主要是作为HTML5游戏的 demo）。而多进程的架构可以很好的实现游戏服务器的的扩展性，达到支撑较多在线用户、降低服务器压力等要求。

该游戏运行架构表面上看与web应用运行架构很类似，connector类似于web应用的apache/nginx等web服务器，后端的服务器群类似于web应用中的应用服务器（如tomcat），但实际上存在着很大的差别：

• 长连接与短连接。web应用使用基于http的短连接以达到最大的可扩展性，游戏应用采用基于socket(websocket)的长连接，以达到最大的实时性。
• 分区策略不同。web应用的分区可以根据负载均衡自由决定， 而游戏则是基于场景(area)的分区模式， 这使同场景的玩家跑在一个进程内，以达到最少的跨进程调用。
• 有状态和无状态。web应用是无状态的， 可以达到无限的扩展。 而游戏应用则是有状态的， 由于基于场景的分区策略，它的请求必须路由到指定的服务器， 这也使游戏达不到web应用同样的可扩展性。
• 广播模式和request/response模式。web应用采用了基于request/response的请求响应模式。而游戏应用则更频繁地使用广播，由于玩家在游戏里的行动要实时地通知场景中的其它玩家， 必须通过广播的模式实时发送。这也使游戏在网络通信上的要求高于web应用。

pomelo framework的组成架构如图所示：

图片来源： Github网易pomelo项目介绍

• server management, pomelo是个真正多进程、分布式的游戏服务器。因此各游戏server(进程)的管理是pomelo很重要的部分，框架通过抽象使服务器的管理非常容易。
• network, 请求、响应、广播、RPC、session管理等构成了整个游戏框架的脉络，所有游戏流程都构建在这个脉络上。
• application, 应用的定义、component管理，上下文配置， 这些使pomelo framework的对外接口很简单，并且具有松耦合、可插拔架构。

pomelo的架构设计目标：

• 服务器（进程）的抽象与扩展：在web应用中， 每个服务器是无状态、对等的， 开发者无需通过框架或容器来管理服务器。但游戏应用不同， 游戏可能需要包含多种不同类型的服务器，每类服务器在数量上也可能有不同的需求。这就需要框架对服务器进行抽象和解耦，支持服务器类型和数量上的扩展。
• 客户端的请求、响应、广播：客户端的请求、响应与web应用是类似的， 但框架是基于长连接的， 实现模式与http请求有一定差别。广播是游戏服务器最频繁的操作， 需要方便的API， 并且在性能上达到极致。
• 服务器间的通讯、调用：尽管框架尽量避免跨进程调用，但进程间的通讯是不可避免的， 因此需要一个方便好用的RPC框架来支撑。
• 松耦合、可插拔的应用架构：应用的扩展性很重要， pomelo framework支持以component的形式插入任何第三方组件, 也支持加入自定义的路由规则、 自定义的filter等。

• Keep it very simple（极简主义）；
• Don’t re-invent the wheel （不重复发明轮子）；
• with proven and solid technologies when you can （能用就用靠谱的技术）；

总而言之，专注于自己的业务和擅长领域，其他事情让更专业的人去做。Instagram选择了美国的亚马逊云计算平台作为基础设施提供商，它部署了数以百计的云服务器和存储服务，却只有区区3名工程师负责维护，不需要任何现场人员支持。如果依赖于传统的IDC服务，光是把这几百台服务器托管到IDC机房，就需要数天时间和大量的人力成本。每当发布一个新版本时，Instagram所要做的只是在云计算平台上开启更多的服务器，便可稳坐钓鱼台，看着自己应用的下载量节节攀升了。

阿里云弹性计算平台（Elastic Compute Service，简称ECS）面向中国互联网开发者和站长，致力于为中国的Instagram提供靠谱的互联网基础服务。它基于底层的飞天分布式计算系统，结合高性能虚拟化技术，实现了计算、存储和网络资源的统一调度和弹性分配。在具体的产品形式上，客户接触的是最简单的云服务器，与物理机无二，没有任何的使用门槛。由于采用了云计算技术，相比传统的IDC托管服务，弹性计算在自助管理、资源组合灵活性、基础环境定制化、数据安全性及硬件资源利用率上都有不小的优势。

在本文中，我们将和大家分享在云计算平台上构建高可用、可扩展应用的一些进阶技巧。考虑到有些读者尚未接触过ECS，所以在进入正题之前，让我们简单浏览一下ECS的各项特性。

自助管理

ECS在aliyun.com的控制台中提供了多种用户自助的操作，例如最为常见的创建、启动、关闭云服务器，将来还会陆续推出比较高级的快照、回滚、自定义镜像（Image）等功能。回想我们以前遇到服务器不可访问时，提交工单、电话催促，在经历漫长等待之后，也未必能够得到一个满意的答复。现在，我们可以在控制台中全程监控和管理每一台服务器的运行情况，从而做出快速的决定——重启或者部署新的服务器。

ECS支持目前主流的Windows和Linux系列操作系统。用户不仅可以使用这些标准的镜像，还可以在此基础上修改配置、安装软件，创建出自己的镜像，当要快速恢复基础环境或者批量部署集群时，自定义镜像将成为提高运维效率的利器。

图1简单地描述了一个自定义镜像的生产过程。

图1 自定义镜像

• 使用标准镜像创建一台云服务器；
• 用户登录云服务器，安装自己所需的软件，配置好系统参数；
• 安全关机，然后将云服务器当前状态存为一个自定义镜像；
• 随后，用户就可以使用刚创建的自定义镜像启动更多的云服务器了。

数据可靠性

对于写入VM磁盘的数据，ECS会实时地在不同的交换机下同步3份拷贝，当集群中的磁盘损坏时，后台进程也会自动地重建故障磁盘的数据。相比常见的RAID硬件方案，这种分布式存储系统能够提供更高的数据安全保障，因为它不受单台服务器可用性的限制，并且，由于多台服务器可以并发处理，数据恢复的时间更短。

ECS提供的在线快照功能可以完美地替代传统的复制备份，它采用先进的增量数据算法，确保做到备份空间和时间的最优化。当用户数据被误删或者系统被病毒破坏时，只需要一个简单操作就可以瞬间恢复环境。

自动故障恢复

有了分布式存储的支持，ECS可以提供比传统主机或VPS服务更高的可用性指标。当一台物理机损坏时，ECS会自动监测到硬件故障，在第一时间内把云服务器迁移到新的宿主机上，同时硬盘数据保持最后一刻的状态。如图2所示。

图2 自动故障恢复

从以上介绍可以看出，托管在弹性计算平台上的应用可以获得更多的保障，但我们是否可以认为，将应用搬到云计算平台之后，它就能跑得欢快、永不宕机，还能自动扩展了？答案是NO！

每时每刻，硬盘、主板、电源或者网络设备都可能突然损坏，甚至整个数据中心发生停电。云计算技术没有办法解决所有硬件问题，只是降低了某些故障的发生几率，例如：

• 普通SATA的年损坏率在2%~4%，但使用分布式存储的年损坏率在1‰以下；
• 自动故障恢复只是减少了服务器的宕机时间，但不能防止宕机。

如果我们的应用只能跑在单台服务器上，只能依赖单台设备的硬件升级才能应付日益增长的访问量，那么这种应用的宕机是迟早的事情。事实上，我们需要从部署架构和应用架构两个方面来破解这个难题。

部署架构

既然没有什么硬件是永不损坏的，我们是否可以用多份冗余的硬件来降低故障的概率？如果挨在一起的服务器被一把火烧掉的可能性太大，我们是否可以把它们分散在不同的集群？如果数据可能被破坏，是否要经常做些备份？……

把各种故障因素都考虑一遍，我们就可以得出下面这个大致的部署框架。

以集群方式提供服务

Web服务器、缓存服务器都是非常适合部署为集群的，单台服务器损坏不会影响整个网站的访问。数据库服务器稍难一些，但它们也提供了主从复制、读写分离的解决方案。

将云服务器分布在不同的可用区（Zone）下

不同的可用区代表数据中心里的不同物理位置，同一可用区内的服务器可能同时遭遇网络设备、电力等故障，因此，把一个集群内的云服务器分散到不同的可用区甚至不同的数据中心（Region）是个明智的选择。

为Web服务集群配置负载均衡与DNS轮询

多台Web服务器可以通过配置负载均衡或者DNS轮询提供对外服务。DNS轮询，负载均衡方式会更加灵活，因为它对外屏蔽了服务器的真实IP，当负载均衡资源池内增加或减少服务器时，对客户是透明的。而DNS存在时延的问题，集群发生调整后，很有可能造成部分用户在很长一段时间内无法正常访问网站。

另外，负载均衡能够跟踪后端应用服务器的健康状态，自动排除有故障的节点，避免出现服务时断时续的问题。
对于特别大的应用，我们推荐使用负载均衡+DNS轮询的方式，只是这里的DNS轮询域名指向的是负载均衡的VIP。

实现动态部署

为了应对经常性的业务推广和可能的DDoS网络攻击，实现系统与应用程序的一键部署很重要。系统管理员可以根据应用的当前状态（CPU、内存使用率、HTTP的响应时间等）作出判断，即时增加服务器，并且快速部署应用程序，顶住突增的业务流量。如果实现得更智能一些，可以在应用服务器内部部署一些监控程序，由主控程序判断当前整个集群的负载情况，调用ECS API自动增减服务节点。

用一台主控机去批量操作其他云服务器时，应该尽量使用一些便捷工具，例如SSH密钥对，它实现了授权服务器间的免登录，使得集群管理更加简单。

定时备份很重要

前面说到，没有什么技术可以保证100%的数据安全，你的数据始终面临误删文件、病毒破坏、程序写错、硬件损坏等种种可能的风险。如果你的数据非常重要，请定期备份！在弹性计算平台上，这件事情相对简单，快照功能自动完成增量数据备份。然而，单个物理位置的存储始终会面临地震、火灾等灾难的威胁，如果你觉得还不够安全，或者有异地使用的需要，且能够承受异地备份带来的存储、带宽等成本，可以自行拷贝数据文件。弹性计算平台也正在考虑跨机房的容灾方案。

将应用程序配置为自恢复的

单台服务器的硬件故障是常见现象，以现有的云计算技术能力，尚无法做到不影响云服务器的运行，但ECS可以快速检测到故障特征，并且将云服务器自动迁移到新的宿主机上。这里存在一个问题，虽然云服务器重新启动了，而且硬盘数据恢复到最后一刻的状态，但原先正在运行的应用程序中止了。为了让你的服务中断时间尽量地缩短，避免人工的介入，强烈建议将应用程序及相关服务设置为开机自启动，这样，你就可以高枕无忧地睡大觉，不用半夜起来恢复应用，尽管只是几个点击或者命令操作。

加固系统

安全也是高可用的重要前提之一。放在IDC机房中的服务器时时面临各种恶意攻击，图3是我们偶然截取的一个攻击片段。

图3 端口扫描攻击

这台服务器在循环探测机房中每一台机器的1433端口，有经验的读者很快猜出来了，它是在试探SQLServer服务，一旦SQLServer被攻破，再利用SQLServer管理员的系统权限漏洞，马上就有一些机器沦为肉鸡。

阿里云弹性计算服务在平台层面就屏蔽了一些影响范围很大的恶意攻击，例如篡改MAC、伪造IP、发送ARP欺骗包等，但用户的系统还是要遵循一些安全最佳实践，才能让自己的系统更加稳固。

• 关闭不必要的系统服务

越多的服务意味着越多的漏洞，特别是Windows共享文件夹、远程修改注册表项等服务都存在巨大的风险，如果你的工作不需要这些服务，请马上关闭。

• 及时升级系统补丁

前段时间爆出的微软高危RDP漏洞让很多用户深受其害，通过一个简单的Python脚本，黑客就可以直接获取系统管理员权限或者直接把服务器打至蓝屏。不要忽略操作系统厂商的安全警告，一旦遭遇攻击，将造成不可挽回的损失。

• 开启系统防火墙

采用白名单控制策略，只开放最小集合的端口。对于数据库服务器，更要设置IP白名单，仅允许前端的Web服务器访问；对于Web服务器，只对外开放80端口。

• 修改常见服务的端口

从刚才的攻击示例看出，黑客虽然漫无目的地扫描同一网段的IP，但攻击的目标端口只有一个1433，这是SQLServer的默认配置。为了减少这类攻击，最有效的方式就是修改数据库、FTP这类常见服务的默认端口，增加黑客扫描的难度。

• 加密数据传输

我曾经遇到过一个很奇怪的现象，在一台Windows 2003服务器上，应用的负载很低，但CPU利用率达到了99%，从任务管理器中看到，有无数个winlogon.exe进程疯狂消耗CPU，当时百思不得其解。一天之后，这台服务器就沦陷了，我才恍然大悟，一定是攻击者在尝试破解密码。对于这类攻击，即使调整密码长度增加破解难度也收效不大，因为攻击过程会消耗大量的系统资源，正常的业务根本无法进行。何况，现在的服务器计算能力越来越强，一个密码的安全性实在太低了。

一些加密传输方式能够有效地抵御这类攻击，也能减少传输过程中的敏感信息泄露问题。Windows可以配置远程桌面服务使用SSL传输，要求客户端必须持有证书登录。Linux则可以使用SSH登录密钥对。结合修改默认端口的方式，将使你的系统安全性提高一个层次。

友情提醒：如果你开启了防火墙，又修改了默认的远程桌面或者SSH端口，请务必在防火墙中设置这些服务的白名单，否则就悲剧了。

应用架构

要支持上述高可用、可扩展的部署架构，应用程序也要做相应的调整。

Web应用的无状态设计

Web应用的诸多因素可能造成系统无法扩展：本地存放的上传文件、进程内的Session等。以上传文件为例，假设使用了本地存储，用户第一个请求上传了一个头像文件，存放在Web-A服务器上，接着刷新页面，但这个请求被发送到Web-B服务器上，他惊奇地发现：上传的头像文件不见了！要解决这个问题，必须把上传文件存放到共享的文件夹，Web服务器不能保留任何自己的数据（即无状态）。而对于Session数据，一般的建议是用Cookie代替，或者存放到共享的Session服务器或者数据库中。

用分布式服务代替单点的服务

单点就意味着故障，不仅有可用性的风险也有性能瓶颈的问题。常见的单点一般出现在共享文件服务器、Session服务器、缓存服务器、数据库服务器。阿里云计算平台提供了一系列分布式服务，是这些单点服务的可行替代方案。

• 需要无空间和访问频率限制的小文件存储？用开放存储服务（OSS）。
• 需要可弹性分配存储空间和IO能力的数据库？用关系型数据库服务（RDS）。
• 需要海量结构化数据存储服务？用开放结构化数据服务（OTS）。

对于平台暂时不提供的分布式缓存服务，业界也提供了一些解决方案，例如Memcached集群技术，但这也对应用程序的设计提出了更高的要求，开发者必须清楚各种服务的HA原理，还需要了解一致性哈希算法等细节的实现。

应用的安全不容忽视

安全不仅是操作系统配置的问题，堡垒更容易从内部被攻破，而这个内鬼很有可能就是我们的应用。从概率上说，一个复杂程序会比一个简单程序多很多漏洞，而Web应用涉及数据库、应用服务器、缓存等诸多组件，稍有不慎，攻击的后门就会向黑客敞开。常见的Web服务漏洞有以下几种。

• XSS跨站脚本攻击

这类Web攻击最为普遍，一般发生在允许用户输入内容的页面，尤其是提供富文本编辑的模块。几乎所有的网站都会被XSS攻击光顾，但防御这类攻击也是最为简单的：限制用户输入，并且在页面输出内容时对敏感字符进行编码，相对来说，后者更为重要一些。PHP语言的htmlspecialchars函数、Java Jakarta commons的StringEscapeUtils类都是实现编码功能的快捷工具。

• SQL注入攻击

只要应用代码中存在这样的SQL：

那么这个应用距离沦陷也就不远了，攻击者只要输入一个值为的

name就可以轻易进入你的应用系统。杜绝这类问题的方法有2种：对输入的特殊字符进行转义，例如PHP的mysql_real_escape_string函数；或者采用参数化的SQL，例如：

后者实现更加优雅，绝对避免了SQL注入的风险，而且在提升数据库的查询性能上也会有所帮助。

• 上传文件漏洞

这是最为危险的应用级漏洞，特别容易出现在允许用户上传内容的网站中。假设一个tomcat搭建的Web网站允许用户上传附件，却忘了限制上传目录的可执行权限，攻击者就可以上传一个带webshell的jsp文件，通过访问这个上传文件的URL就可以完全控制网站服务器。一定要取消上传文件的可执行权限，另外，绝不允许这类文件被当作服务端脚本解析。赶紧为你的网站实施安全策略吧！

• Cookie与传输加密

只要会用HttpWatch、Firebug等开发工具，大家都可以看到各大网站的Cookie数据，而这些Cookie正是网站用于鉴别用户身份的凭证。通过分析Cookie构成，黑客有可能猜测出网站的鉴权策略。要想让你的应用更安全，可以对Cookie等敏感数据进行加密。如果你的网站还包含在线支付功能，部署带授权证书的HTTPS是必不可少的，这也是很多第三方支付平台的强制要求。

综上所述，虽然云计算平台提供了更灵活、更稳定的基础服务保障，但它不足以解决应用的高可用性和可扩展性问题，应用自身必须在架构设计和部署上充分考虑各种意外情况，才能实现真正意义上的高可用、可扩展。

GM(General Manager)                  总经理

HRD(Human Resource Director)   人力资源总监  
OD(Operations Director)               运营总监  
MD(Marketing Director)                 市场总监  
OM(Operations Manager)             运作经理  
PM(Production Manager)              生产经理  
(Product Manager)                        产品经理 

这个是最基本的三层架构模式。

表现层充当系统的界面呈现以及UI逻辑的角色，也就是说，UI（用户界面）属于表现层；

举一个对于asp.net WebForm来说，人们喜欢把对于UI的控制逻辑（服务器控件的读取、设置、事件等等）写在页面的后置隐藏代码中，并且依赖业务逻辑层。当然，服务器控件支持数据绑定的功能，可以通过数据源进行绑定控件。这样就可以节省在后置隐藏中的代码。

因此，我们就可以把表现层分为UI用户界面以及UI逻辑：

UI用户界面的职责只是作为数据输入和输出后的展示工作。

UI逻辑的职责是负责业务逻辑层以及UI用户界面之间的数据交互，并且尽可能地让UI逻辑不依赖于UI技术。

其中UI用户界面的实现方式有很多，包括ASP.NET，WinForm，WPF，Silverlight，移动Web，智能设备等等。

将表现层中UI页面和UI逻辑分离的策略中，当前使用最多的两种模式是MVC模式和MVP模式。

MVC模式，即模型-视图-控制器模式，通过视图触发并执行某个操作，调用控制器，通过控制器去操作业务层，最终返回模型，在视图中进行展示。这里的模型可以是一个领域模型（DM），也可以是一个数据迁移对象（DTO）。

MVP模式，即模型-视图-展示器模式，和MVC模式有点像，不同的是MVP中视图和模型是被完全分离出来的，视图中定义一个接口，而展示器通过调用该接口的方法以控制视图。因此，视图和模型是松散的，展示器也充当了一个控制器的角色，同时它也不依赖于UI技术。

另外再介绍一种模式PM（Preentation Model），它可以说是MVP的变体，在PM中，视图不定义接口，这里的模型只是表示视图状态的类，视图中的元素被直接绑定到模型属性上。例如在WPF中，WPF就先天的具有数据双向绑定机制以及事件通知属性机制。

所以它特别适用于WPF，Sliverlight等等。

在开始业务层之前,不得不说一个前提,在一个小型项目中,直接让表现层调用业务层,足以解决所有问题。但是，当项目大到使用多种表现形式，如使用了各种UI技术，ASP.NET，WPF，移动设备等等，就要考虑在你的表现层和业务层之间增加一个层，以至于让表现层和业务层解耦，因为业务层作为一个业务中间件的平台，最好不要暴露于表现层中，这个层就是传说中的服务层。架构图又演化为：

服务层实际上并不执行任何具体的工作，其功能在于组织各个业务对象,服务层将业务层所有的细节对表现层都隐藏起来,服务器将组织业务逻辑层中的组件,并且通过数据迁移对象(DTO)与表现层交互,因此就产生一个DTO模型。

为了实现服务的可重用性，需要使用服务接口，表现层通过规定的接口访问功能。服务的实现继承服务接口，而服务的实现专注于业务层的调用。

对于服务层，常用的方法包括Web服务、.NET Remoting、Rest以及WCF技术。

本人比较建议使用WCF作为服务，因为可以方便地通过配置达到远程调用服务的目的。

服务层消除了两个表现层和业务层之间的耦合，服务层可以实现一个远程接口，达到多UI技术甚至多平台上的通信。

当然增加服务层也有缺点，假如使用WCF服务，会增加系统的调用开销，进而影响性能。

业务层中包含系统所需要业务过程上的实现，并与下层的数据访问层交互。

我们通常也叫做业务层叫做业务逻辑层，但我认为业务逻辑层是属于业务层的一方面，业务逻辑更专注于业务上逻辑算法的实现。因为业务层还可以包括其他的方面。

业务层必须包括对业务实体尽心建模的对象模型，表达了客户的所有策略和需求的业务规则，因此就产生了领域模型。

（PS：如果这里你不使用领域模型，那么需要采用业务规则层进行业务功能上的业务规则的验证和控制）

领域模型包括对实体的属性定义，方法定义以及实体与实体之间的关系。从这个角度上看，UML建模至关重要，通过对UML动态图和静态图的描述，可以映射到领域模型中。

从服务层刚才讲到了DTO模型，这里需要一个机制将DTO转化为领域模型，所以产生了DTO映射层（DTOMapper）。

另外业务层还包括核心中间件技术，包括第三方组件，以及工作流引擎等等。

业务层需要考虑到一些与数据访问层交互的设计模式，模式中包括事物脚本模式、表模块模式、活动记录模式、领域模型模式。

事物脚本模式是通过方法来执行业务流程，它是一个过程式模型，事物脚本的每个方法都有一个特定的事物脚本，它侧重于业务上一系列流程上的顺序操作，它实现起来很简单，但是它有个致命的缺点就是它会造成很多重复的代码。

表模块模式比起事物脚本模式，具有一定的结构，它的思想也很简单，每个数据表都定义一个业务组件（实体类，实体操作类），在.NET中更多的使用DataSet作为表模型的数据交互。但是它也有一个缺点就是它是从数据库驱动它不适合于大量的数据表以及数据表之间的复杂关系。

活动记录模式中的对象中，可以包含数据和方法。它接近于数据表的结构，它的对象中执行方法中可以包含CRUD操作，验证算法，以及其他的计算功能。一般来说，领域模型不是太复杂，活动记录模式是个好选择。当然他也存在问题，同样地，它对于复杂的业务上，维护的成本也很高，并且如果需求变更导致数据库修改，就需要调整记录对象模型中的相关代码。

经典应用：LINQ-TO-SQL以及Castle ActiveRecord。

领域模型模式是从领域驱动设计中衍生来的，它是以业务为核心的设计模式。它对于复杂的业务逻辑，相当适用。前三种方式使用的是以数据驱动方式，数据驱动方式特点简单，但是当系统到了一定的规模后，就会到难以维护的程度。

数据访问层的目的很明确,主要作为提供数据持久化的功能，包括数据的读取和写入，另外还必须包括事务处理，并发控制等等。

操作数据库的方法可以有两种方式,ORM方式，ADO.NET方式。

ORM可以采用一些第三方的ORM框架来实现，ADO.NET采用ASP.NET自带的数据库操作来实现。

不同的数据库具有不同的持久化实现，因此这里添加一个存储仓库接口层，来适应不同的数据库实现，这里你可以使用IOC依赖注入方式进行数据库选型，可以利用Unity、Spring.NET、Castle的IOC容器等等。

最后各个层中都可以依赖于公共基础设施层。

公共基础设施层可以包括Common通用模块，Logging日志模块，Exception异常模块，Configuration配置模块，DI依赖注入模块，单元测试模块以及第三方组件（例如NHibernate、Sprint.NET、Castle、Quartz计划任务等等）

最终图：

总结：项目类型、项目规模以及业务上的需求，都影响着系统架构的设计，系统架构并不是一层不变的，没有最好的架构，只有更好的架构，并且从项目中多思考系统的扩展性。文中对于架构的分析，只是从通常的角度上去考虑，在项目中，您还需要根据实际情况去做调整。
出处: http://www.cnblogs.com/liping13599168/archive/2011/05/11/2043127.html