64位Windows Server 2003 简体中文企业版？
有64位的中文win 2k3么？
我一直在找，死也找不到……貌似都是英文版再装语言包的……
你的 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
1、网段隔离：估计是有的，只是本图无法看出来而于吧；数据库集群独立成一个网段，保证只跟业务服务器直连，其它针对用户的服务器均无法连接；开发和部署人员需要时连接该网段（不够，实际应用中，为了开发方便，把所有的服务器都连在一起了！）--图示部分是如此，在此啰嗦一下
2、服务器间采用Ipsec，性能损失约是<2%
3、外网用户(Custer)应再细分，不同用户提供不同的安全层级保护
a.普通用户：即图示的Custer
b.企业用户：提供额外的Web Services
c.手机用户
4、数据库应再细分为，提供更好的伸缩性，避免将来使用“链接数据库”的况
a.用户和权限管理数据库服务器
b.业务数据库服务器：可根据不同的业务再扩展
*若无硬件，设计Com+和数据库就要考虑这一点；以便将来作快速切换，否则成本将来可能高得惊人
我比较关心的是设计中提到的‘尽量使用多种技术’，但不知道到底要考虑到采用哪些技术呢？
图画得太不专业了。
而且描述一个系统的架构有多个view，而你的这个是个部署图，另外还需要逻辑视图，组件视图等。
我觉得你在最上面一层太复杂了一些,像CUSTOMER访问RESOURCE SERVER以及EMPLOYEE访问CONFIGSERVER
个人认为,这个设计过于复杂,应该给CUSTOMER仅暴露一个WEBSERVER,WEBSERVER再访问RESOURCESERVER比较好
我觉得,如果你把访问者和被访问者罗列,并且,从访问者到被访问者间画一个路线图,然后在此基础上合并精简的话,出来的效果要好一些
比如现在,如果我是CUSTOMER,那么我与我访问的关系是星状的,但是,可能是你没画清楚吧,我想,应该是线性的较好,或者说,就是一个层次的组合
当然,这只是我的一己之见,仅供参考
@Wuvist
呵呵，如果到时候有正式的中文版，就用中文版，没有的话就用语言包的。但是希望使用64位平台来提高整体性能，并且适应未来的发展趋势。
@a11s
谢谢你的建议。
的确在内部再加一道防火墙会带来更好的安全性。并且，因为cus突破S导致可以直接接触dat serv 的情况是一定要避免的。
@悟
Thanks！
网段隔离是要有的（没有画出来）。
数据库服务器只能由业务服务器访问，所有需要访问数据库的操作均通过业务服务器完成。
对外网用户继续细分的建议很好，其实Man部分是指商品的供应厂商，也就是你说的企业用户吧，不过未来的确可能给他们提供额外的WebService；3G时代到来后，手机用户也一定需要考虑的。
数据库方面，打算根据业务特性（数据量分布、访问频率、性能要求等）对数据进行分解，分布成为多个库（服务器），不知道你说的“考虑这一点”是不是指这个？
@Paker Liu
这个网上很多人都讨论过，比如：使用SqlDataReader、页面ViewState等等很多技术细节。
@风满袖
呵呵，所以才需要大家帮忙指正啊。逻辑视图和组件视图是下一步的事情，还没考虑。希望你也能提点建议啊：）
@菩提树
可能我没有解释清楚ResourceServer的作用。ResourceServer是用于专门存放商品用到的各种图片文件，Customer访问网站时，网页中的图片文件实际上是从ResourceServer上取的。这样就可以让WebServer专心于计算和执行动态页，而ResourceServer也可以专门为图片文件设置缓存策略，并且进行带宽调优。
@SoulEdge
刚开始钱少的话，可以少用几台，呵呵，但是系统必须面向最终目标进行设计。
因为一旦用户数量增加到千万级，就必须事先有所准备，并且能够通过简单添加服务器来平滑扩展。
感觉写的太虚了..是给客户看的..并非能按照规条让你顺利的开发出来的..个人意见..
如果真能按照你的要求开发出来..呵呵..结果是相当让人满意的...关键是看实施..
@[难得一蠢]
呵呵，只有架构设计好了，开发出来才是自己想要的产品。不过，实施也是成功的关键因素
虚倒没有
他这个东西,是写给有钱人的
另外,没钱人,也可以用,不过,那可能要合并一下而已
分布式就是这点不好
还有作者有一点没讲清楚,图中的MESSEAGE SERVICE是用作消息传递,队列及缓存的吗?
还有,ScheduleSERVER应该是相对独立的吧,他仅仅是存取配置然后执行计划吗?,如果是的话,我想,SCHEDULE SERVER的图应该用一个小的图来表示
还有一点,BUSINESS SERVER本来是应用的中心,但图中却未体现出来
第二点就是,以BUSINESS为中心,ConfigSERver是次要服务,另外的SCHEDULE和MESSAGE是辅助服务,这点图中错综的箭头让人看不出这层关系来了,就是说,图对体系的反映不清楚
最后,也是我最关键的一个建议,服务是有层次的,如果按层次设计的系统,就像IOS七层一样,每一层对上次暴露,如非必要,不应跨层,我的意思是,WEB SERVER层不应直接存取CONFIG层
当然,这是一种,我想,你的是想体现的是,两层关系,一层是呈现给用户的WEB层,另一层是为其服务的以BUSINESS为中心的核心层,WEBSERVER层存取所有其他核心层的服务,核心层之间,也存在互相调用
可能两层的这种关系,效率要高一些,但是,第一种,更容易理解一些
这不是有钱没钱的问题，Don't Distribute your object.这是分布式的第一法则！
哪有这样部署的？！
@菩提树
你说的对，有钱没钱都可以用，呵呵。
MessagingServer用于集中执行发送邮件、短信等消息任务；ScheduleServer是相对独立的，用于按计划执行一些特定的任务。
BusinessServer的确是系统的核心，从一些角度看，有些意思的确没表达出来，只是个照顾到一部分视角。
其实ConfigServer主要用于配置和提供整个系统的服务器集群配置信息，WebServer通过它去获取BusinessServer的位置，然后再访问BusinessServer。这样，不同的WebServer可能访问不同的BusinessServer，为实施自定义的负载均衡策略提供了可能。
@csdn shit
能否请你再解释一下 “Don't Distribute your object ”的具体含义？就我的理解，单个object当然不要分布，但是分布多个objects不会有什么问题呀
@csdn shit
昨晚查了企业架构设计那本书，的确提到了“Don't Distribute your object”，也就是“不要分布你的对象”，原因是将对象分布无可避免的要带来性能上的开销，而且在接口粒度方面也不好把握。
所以在可能的情况下不要分布对象，而是使用服务器集群来实现可伸缩性。
Web层采用Web Application会更快点，升级VS2005 sp1后就有了。