作者：不详 来源：互联网 酷勤网收集 2007-11-12
摘要
以下是一个电子商务系统的架构设计，第一次做这样的设计，请大家一起来挑挑毛病，任何您能够想到的，都请你提出来，万分感谢！需求是：需要支持注册用户数从10万到1000万平滑扩展，并且保证一定的性能，安全性和可用性。
以下是一个电子商务系统的架构设计，第一次做这样的设计，请大家一起来挑挑毛病，任何您能够想到的，都请你提出来，万分感谢！
需求是：需要支持注册用户数从10万到1000万平滑扩展，并且保证一定的性能、安全性和可用性。
系统架构示意图
1、可管理性
- 采用中央配置服务器保存全局所有子系统、负载均衡等配置信息，并将其提供给各子系统；
- 每台服务器上运行一个监控进程，用于定时报告服务器运行状态。
2、可伸缩性
- 使用DNS负载均衡实现Web服务器的可伸缩性；
- 使用业务分解，以及可配置的负载均衡策略实现业务层的可伸缩性；
- 使用数据分解，以及数据库集群实现数据层的可伸缩性；
- 使用其他分解方法实现其他子系统的可伸缩性。
- 将面向Customer的网站分为Web部分和Resource部分，目的是根据内容（页面逻辑和图片资源）对带宽、缓存、服务器性能等进行优化；
3、安全性
- 最外层（Web）设置防火墙以抵御各种攻击；
- 各子系统的相互访问实行严格的IP地址限制并且必须持有合法的KEY；
- 访问中央配置服务器时，对传输的数据进行加密；
- 尽可能对敏感数据（帐号和密码等）进行加密传输和存储；
- 中间业务层负责所有业务逻辑的实现，并封装数据库访问，所有其他子系统均不直接访问数据库；
- 在网络、硬件和操作系统上实施其他的安全策略。
4、缓存
- Web层的缓存策略
- 客户端缓存
- 服务器页面缓存
- 服务器数据缓存
- 业务层的缓存策略
- 数据缓存
- 数据库层的缓存策略
5、性能
- 尽可能采用异步操作以提高整体性能；
- 尽可能重用计算结果以提高整体性能；
- 综合利用各种开发技巧提高整体性能。
6、备份
- 除了程序外，所有数据（包括数据库数据、资源服务器上的资源文件等）均进行集中备份，目的是便于管理，并且在全部丢失时也能够完整恢复；
- 始终在异地保存一份最新的完整备份。
7、可用性
- 综合利用服务器集群方案，防单点故障。
系统技术平台
1、硬件选型
- Web服务器：基于64位CPU的1U机架式服务器
- 其他服务器：基于64位CPU的2U机架式服务器
2、系统软件
- 操作系统：64位Windows Server 2003 简体中文企业版
- WebServer：IIS 6.0
- 数据库：64位SQLServer 2005 简体中文企业版
3、开发平台
- 平台：Visual Studio 2005 Team Suite 简体中文版
- Web层技术：ASP.NET 2.0 Web Site
- 中间层技术：ASP.NET 2.0 Web Service
Feedback
#1楼
2006-03-01 01:11 by Wuvist [未注册用户]64位Windows Server 2003 简体中文企业版？
有64位的中文win 2k3么？
我一直在找，死也找不到……貌似都是英文版再装语言包的……
有64位的中文win 2k3么？
我一直在找，死也找不到……貌似都是英文版再装语言包的……
#2楼
2006-03-01 07:59 by 装配脑袋看起来花费不小
#3楼
2006-03-01 08:29 by a11s你的 cus. man. emp. 都在一个防火墙外面。这样设计比较简单。但是为其他人突破提供了可能。从外面直接用man.的通道进来。也许你的防火墙有其他软件的防护方式。我建议在内部添加另一道弱防火墙 。
cus通过防火墙S进入Web. Res. Comu Server.然后通过Server的授权通过弱防火墙S2 访问其他资源。弱防火墙外是emp.以及man. man可以认为是特殊emp.如果增加安全性或者方便访问也可以，让man拨入服务器交换层。但是对于业务admin来说真的没有必要。即便是系统admin也不需要特意开放(因为他有权直接登陆任意服务器，除非是为了方便开发人员)。
其他emp.通过企业局域网使用服务器提供的服务，他们位于S内部S2外部。对于移动用户通过域管理拨号进入企业内部网。由于内部网有域的安全性保障，可以认为是可控的(安全性由域domain admin保障)不可控的cus在S之外，想突破两层防火墙直接接触dat. Server是有难度的。除非得到你的man. 级别授权 或者 服务器授权。这个就由自己来保护了，属于软件范畴。不会因为cus突破S导致可以直接接触dat serv
cus通过防火墙S进入Web. Res. Comu Server.然后通过Server的授权通过弱防火墙S2 访问其他资源。弱防火墙外是emp.以及man. man可以认为是特殊emp.如果增加安全性或者方便访问也可以，让man拨入服务器交换层。但是对于业务admin来说真的没有必要。即便是系统admin也不需要特意开放(因为他有权直接登陆任意服务器，除非是为了方便开发人员)。
其他emp.通过企业局域网使用服务器提供的服务，他们位于S内部S2外部。对于移动用户通过域管理拨号进入企业内部网。由于内部网有域的安全性保障，可以认为是可控的(安全性由域domain admin保障)不可控的cus在S之外，想突破两层防火墙直接接触dat. Server是有难度的。除非得到你的man. 级别授权 或者 服务器授权。这个就由自己来保护了，属于软件范畴。不会因为cus突破S导致可以直接接触dat serv
#4楼
2006-03-01 08:39 by 悟1、网段隔离：估计是有的，只是本图无法看出来而于吧；数据库集群独立成一个网段，保证只跟业务服务器直连，其它针对用户的服务器均无法连接；开发和部署人员需要时连接该网段（不够，实际应用中，为了开发方便，把所有的服务器都连在一起了！）--图示部分是如此，在此啰嗦一下
2、服务器间采用Ipsec，性能损失约是<2%
3、外网用户(Custer)应再细分，不同用户提供不同的安全层级保护
a.普通用户：即图示的Custer
b.企业用户：提供额外的Web Services
c.手机用户
4、数据库应再细分为，提供更好的伸缩性，避免将来使用“链接数据库”的况
a.用户和权限管理数据库服务器
b.业务数据库服务器：可根据不同的业务再扩展
*若无硬件，设计Com+和数据库就要考虑这一点；以便将来作快速切换，否则成本将来可能高得惊人
2、服务器间采用Ipsec，性能损失约是<2%
3、外网用户(Custer)应再细分，不同用户提供不同的安全层级保护
a.普通用户：即图示的Custer
b.企业用户：提供额外的Web Services
c.手机用户
4、数据库应再细分为，提供更好的伸缩性，避免将来使用“链接数据库”的况
a.用户和权限管理数据库服务器
b.业务数据库服务器：可根据不同的业务再扩展
*若无硬件，设计Com+和数据库就要考虑这一点；以便将来作快速切换，否则成本将来可能高得惊人
#5楼
2006-03-01 09:02 by Paker Liu我比较关心的是设计中提到的‘尽量使用多种技术’，但不知道到底要考虑到采用哪些技术呢？
#6楼
2006-03-01 09:12 by SoulEdge [未注册用户]客户是有钱的主......
#7楼
2006-03-01 09:19 by 风满袖图画得太不专业了。
而且描述一个系统的架构有多个view，而你的这个是个部署图，另外还需要逻辑视图，组件视图等。
而且描述一个系统的架构有多个view，而你的这个是个部署图，另外还需要逻辑视图，组件视图等。
#8楼
2006-03-01 09:27 by 菩提树我觉得你在最上面一层太复杂了一些,像CUSTOMER访问RESOURCE SERVER以及EMPLOYEE访问CONFIGSERVER
个人认为,这个设计过于复杂,应该给CUSTOMER仅暴露一个WEBSERVER,WEBSERVER再访问RESOURCESERVER比较好
我觉得,如果你把访问者和被访问者罗列,并且,从访问者到被访问者间画一个路线图,然后在此基础上合并精简的话,出来的效果要好一些
比如现在,如果我是CUSTOMER,那么我与我访问的关系是星状的,但是,可能是你没画清楚吧,我想,应该是线性的较好,或者说,就是一个层次的组合
当然,这只是我的一己之见,仅供参考
个人认为,这个设计过于复杂,应该给CUSTOMER仅暴露一个WEBSERVER,WEBSERVER再访问RESOURCESERVER比较好
我觉得,如果你把访问者和被访问者罗列,并且,从访问者到被访问者间画一个路线图,然后在此基础上合并精简的话,出来的效果要好一些
比如现在,如果我是CUSTOMER,那么我与我访问的关系是星状的,但是,可能是你没画清楚吧,我想,应该是线性的较好,或者说,就是一个层次的组合
当然,这只是我的一己之见,仅供参考
#9楼 [楼主]
2006-03-01 09:27 by happyprogram@Wuvist
呵呵，如果到时候有正式的中文版，就用中文版，没有的话就用语言包的。但是希望使用64位平台来提高整体性能，并且适应未来的发展趋势。
@a11s
谢谢你的建议。
的确在内部再加一道防火墙会带来更好的安全性。并且，因为cus突破S导致可以直接接触dat serv 的情况是一定要避免的。
@悟
Thanks！
网段隔离是要有的（没有画出来）。
数据库服务器只能由业务服务器访问，所有需要访问数据库的操作均通过业务服务器完成。
对外网用户继续细分的建议很好，其实Man部分是指商品的供应厂商，也就是你说的企业用户吧，不过未来的确可能给他们提供额外的WebService；3G时代到来后，手机用户也一定需要考虑的。
数据库方面，打算根据业务特性（数据量分布、访问频率、性能要求等）对数据进行分解，分布成为多个库（服务器），不知道你说的“考虑这一点”是不是指这个？
@Paker Liu
这个网上很多人都讨论过，比如：使用SqlDataReader、页面ViewState等等很多技术细节。
呵呵，如果到时候有正式的中文版，就用中文版，没有的话就用语言包的。但是希望使用64位平台来提高整体性能，并且适应未来的发展趋势。
@a11s
谢谢你的建议。
的确在内部再加一道防火墙会带来更好的安全性。并且，因为cus突破S导致可以直接接触dat serv 的情况是一定要避免的。
@悟
Thanks！
网段隔离是要有的（没有画出来）。
数据库服务器只能由业务服务器访问，所有需要访问数据库的操作均通过业务服务器完成。
对外网用户继续细分的建议很好，其实Man部分是指商品的供应厂商，也就是你说的企业用户吧，不过未来的确可能给他们提供额外的WebService；3G时代到来后，手机用户也一定需要考虑的。
数据库方面，打算根据业务特性（数据量分布、访问频率、性能要求等）对数据进行分解，分布成为多个库（服务器），不知道你说的“考虑这一点”是不是指这个？
@Paker Liu
这个网上很多人都讨论过，比如：使用SqlDataReader、页面ViewState等等很多技术细节。
#10楼 [楼主]
2006-03-01 09:33 by happyprogram@风满袖
呵呵，所以才需要大家帮忙指正啊。逻辑视图和组件视图是下一步的事情，还没考虑。希望你也能提点建议啊：）
@菩提树
可能我没有解释清楚ResourceServer的作用。ResourceServer是用于专门存放商品用到的各种图片文件，Customer访问网站时，网页中的图片文件实际上是从ResourceServer上取的。这样就可以让WebServer专心于计算和执行动态页，而ResourceServer也可以专门为图片文件设置缓存策略，并且进行带宽调优。
呵呵，所以才需要大家帮忙指正啊。逻辑视图和组件视图是下一步的事情，还没考虑。希望你也能提点建议啊：）
@菩提树
可能我没有解释清楚ResourceServer的作用。ResourceServer是用于专门存放商品用到的各种图片文件，Customer访问网站时，网页中的图片文件实际上是从ResourceServer上取的。这样就可以让WebServer专心于计算和执行动态页，而ResourceServer也可以专门为图片文件设置缓存策略，并且进行带宽调优。
#11楼 [楼主]
2006-03-01 09:36 by happyprogram@SoulEdge
刚开始钱少的话，可以少用几台，呵呵，但是系统必须面向最终目标进行设计。
因为一旦用户数量增加到千万级，就必须事先有所准备，并且能够通过简单添加服务器来平滑扩展。
刚开始钱少的话，可以少用几台，呵呵，但是系统必须面向最终目标进行设计。
因为一旦用户数量增加到千万级，就必须事先有所准备，并且能够通过简单添加服务器来平滑扩展。
#12楼
2006-03-01 10:01 by [难得一蠢] [未注册用户]感觉写的太虚了..是给客户看的..并非能按照规条让你顺利的开发出来的..个人意见..
如果真能按照你的要求开发出来..呵呵..结果是相当让人满意的...关键是看实施..
如果真能按照你的要求开发出来..呵呵..结果是相当让人满意的...关键是看实施..
#13楼 [楼主]
2006-03-01 10:07 by happyprogram@[难得一蠢]
呵呵，只有架构设计好了，开发出来才是自己想要的产品。不过，实施也是成功的关键因素
呵呵，只有架构设计好了，开发出来才是自己想要的产品。不过，实施也是成功的关键因素
#14楼 回复 引用 查看
2006-03-01 10:39 by 菩提树虚倒没有
他这个东西,是写给有钱人的
另外,没钱人,也可以用,不过,那可能要合并一下而已
分布式就是这点不好
还有作者有一点没讲清楚,图中的MESSEAGE SERVICE是用作消息传递,队列及缓存的吗?
还有,ScheduleSERVER应该是相对独立的吧,他仅仅是存取配置然后执行计划吗?,如果是的话,我想,SCHEDULE SERVER的图应该用一个小的图来表示
还有一点,BUSINESS SERVER本来是应用的中心,但图中却未体现出来
第二点就是,以BUSINESS为中心,ConfigSERver是次要服务,另外的SCHEDULE和MESSAGE是辅助服务,这点图中错综的箭头让人看不出这层关系来了,就是说,图对体系的反映不清楚
最后,也是我最关键的一个建议,服务是有层次的,如果按层次设计的系统,就像IOS七层一样,每一层对上次暴露,如非必要,不应跨层,我的意思是,WEB SERVER层不应直接存取CONFIG层
当然,这是一种,我想,你的是想体现的是,两层关系,一层是呈现给用户的WEB层,另一层是为其服务的以BUSINESS为中心的核心层,WEBSERVER层存取所有其他核心层的服务,核心层之间,也存在互相调用
可能两层的这种关系,效率要高一些,但是,第一种,更容易理解一些
他这个东西,是写给有钱人的
另外,没钱人,也可以用,不过,那可能要合并一下而已
分布式就是这点不好
还有作者有一点没讲清楚,图中的MESSEAGE SERVICE是用作消息传递,队列及缓存的吗?
还有,ScheduleSERVER应该是相对独立的吧,他仅仅是存取配置然后执行计划吗?,如果是的话,我想,SCHEDULE SERVER的图应该用一个小的图来表示
还有一点,BUSINESS SERVER本来是应用的中心,但图中却未体现出来
第二点就是,以BUSINESS为中心,ConfigSERver是次要服务,另外的SCHEDULE和MESSAGE是辅助服务,这点图中错综的箭头让人看不出这层关系来了,就是说,图对体系的反映不清楚
最后,也是我最关键的一个建议,服务是有层次的,如果按层次设计的系统,就像IOS七层一样,每一层对上次暴露,如非必要,不应跨层,我的意思是,WEB SERVER层不应直接存取CONFIG层
当然,这是一种,我想,你的是想体现的是,两层关系,一层是呈现给用户的WEB层,另一层是为其服务的以BUSINESS为中心的核心层,WEBSERVER层存取所有其他核心层的服务,核心层之间,也存在互相调用
可能两层的这种关系,效率要高一些,但是,第一种,更容易理解一些
#15楼
2006-03-01 10:44 by csdn shit [未注册用户]这不是有钱没钱的问题，Don't Distribute your object.这是分布式的第一法则！
哪有这样部署的？！
哪有这样部署的？！
#16楼 [楼主]
2006-03-01 11:03 by happyprogram@菩提树
你说的对，有钱没钱都可以用，呵呵。
MessagingServer用于集中执行发送邮件、短信等消息任务；ScheduleServer是相对独立的，用于按计划执行一些特定的任务。
BusinessServer的确是系统的核心，从一些角度看，有些意思的确没表达出来，只是个照顾到一部分视角。
其实ConfigServer主要用于配置和提供整个系统的服务器集群配置信息，WebServer通过它去获取BusinessServer的位置，然后再访问BusinessServer。这样，不同的WebServer可能访问不同的BusinessServer，为实施自定义的负载均衡策略提供了可能。
@csdn shit
能否请你再解释一下 “Don't Distribute your object ”的具体含义？就我的理解，单个object当然不要分布，但是分布多个objects不会有什么问题呀
你说的对，有钱没钱都可以用，呵呵。
MessagingServer用于集中执行发送邮件、短信等消息任务；ScheduleServer是相对独立的，用于按计划执行一些特定的任务。
BusinessServer的确是系统的核心，从一些角度看，有些意思的确没表达出来，只是个照顾到一部分视角。
其实ConfigServer主要用于配置和提供整个系统的服务器集群配置信息，WebServer通过它去获取BusinessServer的位置，然后再访问BusinessServer。这样，不同的WebServer可能访问不同的BusinessServer，为实施自定义的负载均衡策略提供了可能。
@csdn shit
能否请你再解释一下 “Don't Distribute your object ”的具体含义？就我的理解，单个object当然不要分布，但是分布多个objects不会有什么问题呀
#17楼 [楼主]
2006-03-02 11:33 by happyprogram@csdn shit
昨晚查了企业架构设计那本书，的确提到了“Don't Distribute your object”，也就是“不要分布你的对象”，原因是将对象分布无可避免的要带来性能上的开销，而且在接口粒度方面也不好把握。
所以在可能的情况下不要分布对象，而是使用服务器集群来实现可伸缩性。
昨晚查了企业架构设计那本书，的确提到了“Don't Distribute your object”，也就是“不要分布你的对象”，原因是将对象分布无可避免的要带来性能上的开销，而且在接口粒度方面也不好把握。
所以在可能的情况下不要分布对象，而是使用服务器集群来实现可伸缩性。
来自：http://www.cnblogs.com/happyprogram/archive/2006/02/28/339989.html