Hunter的大杂烩 技术学习笔记

2008-06-08

大型网站架构之:MySpace的体系架构

Filed under: 架构 — hunter @ 12:24 am

留做备份,呵呵

 简单的说,所有成功的web2.0网站都会经历“仓促成长”(在某个blog上看到的词汇)的过程,如果哪个

傻瓜(我们就是-_-!)在产品发布前就以千万、亿万级目标去构架整个系统,那只能说是设计过度或者把刀刃用错了地方

from: http://tech.it168.com/i/2007-11-15/200711150956250.shtml

  MySpace.com有着6500万的订阅者,是因特网上增长最快的网站之一,每天还有260,000新用户注册。它经常因为性能问题而受指责,MySpace不得不处理其他网站很少碰到的或大或小的一些问题。它们是怎么做的呢?
Site: http://myspace.com
站点:http://myspace.com 

(more…)

2007-12-29

微软官网Microsoft.com的一些安全防护数据

Filed under: .NET,架构 — hunter @ 11:36 pm

 大型互联网公司的架构体系恐怕都差不多,据说yahoo也没有防火墙,老板从yahoo/google

考察回来后,收获颇大的说….

原文/来源链接:http://news.mydrivers.com/1/96/96493.htm

为一个庞大的软件帝国,微软自家官方网站www.microsoft.com的经营是个非常有趣的话题,尤其是这么一个大型网络是如何在提供高速数据传输的同时保障自身安全的?Jeff Alexander近日就从微软运营小组那里获得了一些“内幕资料”,主要是关于微软是如何自己使用IIS、Windows Server 2008和防火墙的。

1、其实www.microsoft.com根本没有使用防火墙,而且今后也不会安装,因为不处理HBI数据,无需记录外部登陆情况。

(more…)

2007-05-24

.NET Cache

Filed under: .NET,架构 — hunter @ 3:19 pm

一些cache常见资料

 http://kingmax5421.spaces.live.com/blog/cns!993bdd5bccb6cc83!230.entry

摘要: 介绍缓存的基本概念和常用的缓存技术,给出了各种技术的实现机制的简单介绍和适用范围说明,以及设计缓存方案应该考虑的问题(共17页)

1         概念
1.1   缓存能解决的问题
· 性能——将相应数据存储起来以避免数据的重复创建、处理和传输,可有效提高性能。比如将不改变的数据缓存起来,例如国家列表等,这样能明显提高web程序的反应速度;

· 稳定性——同一个应用中,对同一数据、逻辑功能和用户界面的多次请求时经常发生的。当用户基数很大时,如果每次请求都进行处理,消耗的资源是很大的浪费,也同时造成系统的不稳定。例如,web应用中,对一些静态页面的呈现内容进行缓存能有效的节省资源,提高稳定性。而缓存数据也能降低对数据库的访问次数,降低数据库的负担和提高数据库的服务能力;

· 可用性——有时,提供数据信息的服务可能会意外停止,如果使用了缓存技术,可以在一定时间内仍正常提供对最终用户的支持,提高了系统的可用性。

1.2   理解状态
在深入介绍缓存技术之前,需要对状态有一个认识,因为缓存可以说是状态管理的框架。理解状态的含义和它的一些特性——比如生存期和生存范围——对决定是否缓存和选择合适的缓存技术有很大帮助。状态是指一些数据,在应用系统某个时间点上,数据的状态和条件。这些数据可能是永久性的存储在数据库中,可能是只在内存里停留一会,也可能是按照某个逻辑存活(比如多长时间后释放),它的应用范围可能是所有用户可访问,可能是单个用户有权限;

1.2.1  状态的生存期
生存期是指数据保持有效性的时间区间,也就是从创建到移除的时间间隔。通常的生存期有以下几种:

·永久状态Permanent State——应用程序使用的永久数据;

·进程状态Process State——只在进程周期内有效;

·会话状态Session State——和特定的用户会话有关;

·消息状态Message State——处理某个消息的时间内有效;

(more…)

2006-09-10

系统演进之路(2)

Filed under: 架构,电子商务 — hunter @ 3:09 am

随着业务逐渐复杂,我们发现原有的开发模式效率极其低下,尤其是纯粹业务处理的APP层,做异步处理时,状态机非常难以维护,在此基础上,我们开发出了 app platform, db platform等公共组件

xxx platform其实非常类似一个ejb 容器,开发人员已经可以把精力集中在业务逻辑上了,从网络层收发数据报、协议封解包上脱离了出来

但是效率还不够高,异步情况下,还是存在状态机的情况,尤其是当后期我们准备OO化整体设计的时候,这种模式就会导致设计的非常dirty,不易测试,我们需要一个POCO的模型!

系统演进之路

Filed under: 架构,电子商务 — hunter @ 2:30 am

早期为了赶进度,使用了最拿手的c/c++混合的进程模型

关注点主要在分布式的APP和DB架构上,提出了dbroute,appinterface等节点,以便水平扩展服务器来分摊压力

在应对web session的问题上,使用了分布式的session解决方案

这个阶段最大的收获是:

1. 分层不能过多

2. 业务复杂之后,原来的c风格开发模式的颗粒太大,会导致分工不均

3. 监控体系没有做好,压力上来之后,对优化方向没有理论指导

« Newer PostsOlder Posts »

Powered by WordPress