图书电信域名扩展参考方案
文档修改历史记录
|
归档日期 |
版本 |
说明 |
作者 |
审批人 |
|
2009-11-09 |
V1.0 |
创建文档 |
刘运锋 |
|
|
|
|
|
|
|
|
|
|
|
|
|
图书电信域名扩展参考方案
一、文档说明
1.1、该文档主要针对图书系统电信域名扩展
1.2、校信通电信ip较少，但是如果高效应用现用电信ip，足够可以满足现有以及将来一至两年内的发展。
1.3、本文档为提供如何高效使用现用电信ip解决现有问题，如何加快电信域名的访问速度等问题提供参考方案。
1.4、如有问题或者是不足之处，请大家指正
二、方案一（基于反向代理服务器方案）
1.1、方案规划拓扑图
1.2、方案优点
1）本方案的优点是，单个Linux的机器仅需一个电信ip就可以将所有的电信域名的服务都解析到反向代理服务器上，合理利用现有资源。
2）架设反向代理服务器，加速电信域名的访问速度，提高用户感知度。
3）测试时间比较长，系统比较稳定且效率比较高，支持较大的访问量，减轻后端服务器的压力。
4）单台反向代理服务器即可满足现有扩展需求，甚至是未来一至两年内的访问。
1.3、方案缺点
1）不支持超大量的访问量，如果需要支持超大访问量需要增加代理服务的数量。
2）需要保证代理服务器的稳定性。
3）不支持分主机的访问日志
1.4、方案总结
1）本方案实施简单方便，所需资源也是比较少的。
2）可以将现在所掌握的知识很好的应用实践。
3）单台代理服务器可以支持比较大的访问量，但是如果想支持比较大的访问量需要增加反向代理服务器的个数或者是构建其他能支持超大访问量的架构。
4）个人比较推荐此方案，可将反向代理服务器应用于实践。
三、方案二（基于Nginx的web服务器假设）
1.1、方案规划拓扑图
1.2、方案优点
1）Nginx是一个比较稳定的web服务器，可以跨机器进行基于域名和虚拟主机的转发。
2）可以创建基于基于域名的访问日志。
3）支持较大的访问量。
4）要求资源比较少，和Squid反向代理服务方案有些类似。
1.3、方案缺点
1）不能减轻后端服务器的压力，因为只是基于转发的。
2）学习和测试时间不长，技术有待进一步的学习和挖掘。
3）不支持超大访问量，如果需要支持需要增加Nginx服务器或者采用其他的架构方式。
1.4、方案总结
1）该方案是一个比较合理的方案，但是中间有些技术需要进行测试和学习。
2）能支持基于域名的访问日志，如果是对电信的域名日志要求比较高的话可以采用这种方式。
3）没有使用缓存机制，只是基于域名转发，不能缓解后端服务器的压力。
四、方案三（基于DNS服务器的假设方案）
1.1、方案规划拓扑图
1.2、方案优点
1）能将电信用户过来的访问分发到电信的服务器上，而网通用户访问通过网通ip返回，能加快访问以及负载均衡之类。
2）有利于长期的规划和网站长期的发展，将来可以统一电信和网通域名，使网络访问合理简洁。
1.3、方案缺点
1）需要多台服务，并需要架设DNS服务器。
2）使用新技术，需要测试稳定性。
3）在不增加ip的情况下，需要和其他的方式结合才能使用。
1.4、方案总结
1）该方案必须和其他的方案进行结合才能使用，这样做有利于知识的积累和网站长期的发展，并为以后统一网通和电信域名，实现快速访问有关系。
2）实施起来相对比较复杂一些，需要对技术做进一步的测试，以求更稳定的架构。
3）本方案主要应对不是大批量的访问，这只是一个针对我们的一个现实的环境进行的一个比较合理的方案。