分页: 2/30 第一页 上页 1 2 3 4 5 6 7 8 9 10 下页 最后页 [ 显示模式: 摘要 | 列表 ]

        Docker的生态日趋成熟,开源社区也不断孵化出优秀的周边项目,覆盖网络、监控、维护、部署、开发等方面。帮助开发、运维人员快速构建、运营Docker服务环境,其中也不乏有大公司的影子,如Google、IBM、Redhat,甚至微软也宣称后续将提供Docker在Windows平台的支持。Docker的发展前景一片大好。但在企业当中,如何选择适合自己的Docker构建方案?可选的方案有kubernetes与CoreOS(都已整合各类组件),另外一种方案为Haproxy+etcd+confd,采用松散式的组织结构,但各个组件之间的通讯是非常严密的,且扩展性更强,定制也更加灵活。下面详细介绍如何使用Haproxy+etcd+confd构建一个高可用及自动发现的Docker基础架构。
一、架构优势
        约定由Haproxy+etcd+confd+Docker构建的基础服务平台简称“HECD” 架构,整合了多种开源组件,看似松散的结构,事实上已经是一个有机的整体,它们互相联系、互相作用,是Docker生态圈中最理想的组合之一,具有以下优势:
      自动、实时发现及无感知服务刷新;
      支持任意多台Docker主宿机;
      支持多种APP接入且打散至不分主宿机;
      采用Etcd存储信息,集群支持可靠性高;
      采用Confd配置引擎,支持各类接入层,如Nginx;
      支持负载均衡、故障迁移;
      具备资源弹性,伸缩自如(通过生成、销毁容器实现);

二、架构说明
        在HECD架构中,首先管理员操作Docker Client,除了提交容器(Container)启动与停止指令外,还通过REST-API方式向Etcd(K/V)存储组件注册容器信息,包括容器名称、主宿机IP、映射端口等。Confd配置组件会定时查询Etcd组件获取最新的容器信息,根据定义好的配置模板生成Haproxy配置文件Haproxy.cfg,并且自动reload haproxy服务。用户在访问业务服务时,完全没有感知后端APP的上线、下线、切换及迁移,达到了自动发现、高可用的目的。详细架构图见图1-1。
点击在新窗口中浏览此图片

图1-1 平台架构图


        为了方便大家理解各组件间的关系,通过图1-2进行架构流程梳理,首先管理员通过Shell或api操作容器,下一步将容器信息注册到Etcd组件,Confd组件会定时查询Etcd,获取已经注册到Etcd中容器信息,最后通过Confd的模板引擎生成Haproxy配置,整个流程结束。
点击在新窗口中浏览此图片

图1-2架构流程图


        了解架构流程后,我们逐一对流程中各组件进行详细介绍。
1、Etcd介绍
        Etcd是一个高可用的 Key/Value 存储系统,主要用于分享配置和服务发现。
          简单:支持 curl 方式的用户 API (HTTP+JSON)
          安全:可选 SSL 客户端证书认证
          快速:单实例可达每秒 1000 次写操作
          可靠:使用 Raft 实现分布式
2、Confd介绍
        Confd是一个轻量级的配置管理工具。通过查询Etcd,结合配置模板引擎,保持本地配置最新,同时具备定期探测机制,配置变更自动reload。
3、Haproxy介绍
        HAProxy是提供高可用性、负载均衡以及基于TCP和HTTP应用的代理,支持虚拟主机,它是免费、快速并且可靠的一种解决方案。(来源百科)

三、架构部署
        平台环境基于Centos6.5+Docker1.2构建,其中Etcd的版本为etcd version 0.5.0-alpha,Confd版本为confd 0.6.2,Haproxy版本为HA-Proxy version 1.4.24。下面对平台的运行环境、安装部署、组件说明等进行详细说明,环境设备角色表如下:
点击在新窗口中浏览此图片

1、组件安装
    1.1 Docker安装
        SSH终端登录192.168.1.22服务器,执行以下命令:

    1.2 Haproxy、confd安装
        SSH终端登录192.168.1.20服务器,执行以下命令:

    1.3 Etcd(v0.4.6)安装
        SSH终端登录192.168.1.21服务器,执行以下命令:

2、组件配置
    2.1 Etcd配置
        由于etcd是一个轻量级的K/V存储平台,启动时指定相关参数即可,无需配置。

        由于etcd具备多机支持,参数“-peer-addr”指定与其它节点通讯的地址;参数“-addr”指定服务监听地址;参数“-data-dir”为指定数据存储目录。
        由于etcd是通过REST-API方式进行交互,常见操作如下:
    1) 设置(set) key操作

    2) 获取(get) key信息

    3) 删除key信息

    更多操作API见https://github.com/coreos/etcd/blob/master/Documentation/api.md。

2.2 Confd+Haproxy配置
        由于Haproxy的配置文件是由Confd组件生成,要求Confd务必要与haproxy安装在同一台主机上,Confd的配置有两种,一种为Confd资源配置文件,默认路径为“/etc/confd/conf.d”目录,另一种为配置模板文件,默认路径为“/etc/confd/templates”。具体配置如下:
创建配置文件目录
# mkdir -p /etc/confd/{conf.d,templates}
(1)配置资源文件
        详细见以下配置文件,其中“src”为指定模板文件名称(默认到路径/etc/confd/templates中查找);“dest”指定生成的Haproxy配置文件路径;“keys”指定关联Etcd中key的URI列表;“reload_cmd”指定服务重载的命令,本例中配置成haproxy的reload命令。
【/etc/confd/conf.d/ haproxy.toml】

(2)配置模板文件
        Confd模板引擎采用了Go语言的文本模板,更多见http://golang.org/pkg/text/template/,具备简单的逻辑语法,包括循环体、处理函数等,本示例的模板文件如下,通过range循环输出Key及Value信息。
【/etc/confd/templates/haproxy.cfg.tmpl】

(3)模板引擎说明
        本小节详细说明Confd模板引擎基础语法与示例,下面为示例用到的KEY信息。

1、base
    作为path.Base函数的别名,获取路径最后一段。
{{ with get "/app/servers/prickly_blackwell"}}
    server {{base .Key}} {{.Value}} check
{{end}}

2、get
    返回一对匹配的KV,找不到则返回错误。
{{with get "/app/servers/prickly_blackwell"}}
    key: {{.Key}}
    value: {{.Value}}
{{end}}

3、gets
    返回所有匹配的KV,找不到则返回错误。
{{range gets "/app/servers/*"}}
    {{.Key}} {{.Value}}
     {{end}}

4、getv
    返回一个匹配key的字符串型Value,找不到则返回错误。
{{getv "/app/servers/cocky_morse"}}

5、getvs
    返回所有匹配key的字符串型Value,找不到则返回错误。
        {{range getvs "/app/servers/*"}}
           value: {{.}}
        {{end}}

6、split
    对输入的字符串做split处理,即将字符串按指定分隔符拆分成数组。
        {{ $url := split (getv "/app/servers/cocky_morse") ":" }}
          host: {{index $url 0}}
          port: {{index $url 1}}

7、ls
    返回所有的字符串型子key,找不到则返回错误。
{{range ls "/app/servers/"}}
   subkey: {{.}}
{{end}}

8、lsdir
    返回所有的字符串型子目录,找不到则返回一个空列表。
{{range lsdir "/app/"}}
   subdir: {{.}}
{{end}}

(4)启动confd及haproxy服务
        下面为启动Confd服务命令行,参数“interval”为指定探测etcd的频率,单位为秒,参数“-node”为指定etcd监听服务主地址,以便获取容器信息。

3、容器配置
        前面HECD架构说明内容,有讲到容器的操作会即时注册到etcd组件中,是通过curl命令进行REST-API方式提交的,下面详细介绍通过SHELL及Python-api两种方式的实现方法,支持容器启动、停止的联动。

    3.1、SHELL实现方法
        实现的原理是通过获取“Docker run ***”命令输出的Container ID,通过“docker inspect Container ID”得到详细的容器信息,分析出容器服务映射的外部端口及容器名称,将以“/app/servers/容器名称”作为Key,“主宿机: 映射端口”作为Value注册到etcd中。其中Key信息前缀(/app/servers)与“/etc/confd/conf.d/haproxy.toml”中的keys参数是保持一致的。
【docker.sh】

docker.sh使用方法:
    1) 启动一个容器
    # ./docker.sh run yorko/webserver:v3(镜像)
    2) 停止一个容器
    # ./docker.sh stop berserk_hopper(容器名)

3.2、Docker-py API实现方法
        通过Python语言调用Docker-py的API实现容器的远程操作(创建、运行、停止),并结合python-etcd模块对etcd进行操作(set、delete),达到与SHELL方式一样的效果,很明显,Docker-py方式更加容易扩展,可以无缝与现有运营平台对接。
        为兼顾到远程API支持,需对docker启动文件“exec”处进行修改,详细见如下:
# vi /etc/init.d/docker

启动容器的程序如下:
【docker_run.py】

停止容器的程序如下:
【docker_stop.py】

注意:
        由于容器是无状态的,尽量让其以松散的形式存在,映射端口选项要求使用“-P”参数,即使用随机端口的模式,减少人手干预。

四、业务上线
        HECD架构已部署完毕,接下来就是让其为我们服务,案例中使用的镜像“yorko/webserver:v3”为已经构建好的LAMP平台。类似的镜像也可以在docker-pub中下载到,开始跑起,运行dockery.sh创建两个容器:

        访问Haproxy监控地址:http://192.168.1.20/admin-status,刚创建的容器已经添加到haproxy中,见图1-3。
点击在新窗口中浏览此图片

图1-3 Haproxy监控后台截图


        1)观察Haproxy的配置文件(更新部分):

        2)访问php测试文件http://192.168.1.20/info.php
点击在新窗口中浏览此图片

图1-4 php测试文件截图


        从图1-4可以看出,获取的服务器端IP为容器本身的IP地址(172.17.0.11),在System环境变量处输出容器名为“598cf10a50a2”的信息。

参考:
http://ox86.tumblr.com/post/90554410668/easy-scaling-with-docker-haproxy-and-confd
https://github.com/AVGP/forrest/blob/master/forrest.sh
        Docker-py作为官方推出的客户端API,功能可以满足我们大部分操作需求,API涉及镜像(images)及容器(CONTAINER)的功能操作,利用docker-py可以轻松开发出Docker的管理平台,以便维护大规模的Docker集群,本文介绍如何通过DockerFile创建一个WEB服务的镜像,再通过远程API对容器进行管理。

一、环境准备
1、环境说明
192.168.1.20 #Docker python API主机
192.168.1.22 #Docker服务主机
2、Docker环境部署(略)
3、修改自启动服务文件,支持远程TCP接口与本地SOCK连接;
# vi /etc/init.d/docker
#service docker restart

二、创建镜像
1、获取最新的centos镜像
# docker pull centos:latest
2、编写Dockerfile(支持apache+ssh服务)
# mkdir /home/Dockerfile/webserver
# cd /home/Dockerfile/webserver
# vi Dockerfile

通过supervisord来维护Docker容器中服务进程,编写supervisord.conf
# vi supervisord.conf

创建镜像,运行:
# docker build -t yorko/webserver:v1 .
注:最后有一个“.”,别遗漏。

镜像生成完毕后运行docker images查看,见下图:
点击在新窗口中浏览此图片

三、编写操作API
登录192.168.1.20服务器
# mkdir /home/test/docker-py
# cd /home/test/docker-py
1、安装docker-py
# wget https://github.com/docker/docker-py/archive/master.zip
# unzip master
# cd docker-py-master/
# python setup.py install
如正常导入模块(import docker)说明安装成功。

2、创建容器docker_create.py

3、运行容器docker_start.py

4、运行
# python docker_create.py
# python docker_start.py
更多API参考https://github.com/docker/docker-py

5、在Docker主机观察结果,见下图:
点击在新窗口中浏览此图片

三、校验服务
1、校验SSH服务
点击在新窗口中浏览此图片

2、校验WEB服务
点击在新窗口中浏览此图片

3、检查数据卷
点击在新窗口中浏览此图片
    Saltstack是一个具备puppet与func功能为一身的集中化管理平台,saltstack基于python实现,功能十分强大,各模块融合度及复用性极高,官方极力推荐作为云计算平台的基础架构。轻松维护成千上万台服务器不是问题,现分享作者基于saltstack实现一个集中化的配置管理平台,以Nginx配置例子展开,涉及salt的grains、grains_module、pillar、States、jinja(template)等,本文适合有salt基础的同学阅读。
一、设备环境说明
    有两组web业务服务器,组名分别为web1group与web2group,设备硬件配置、web根目录存在异常,见下图:
    点击在新窗口中浏览此图片

二、master配置说明
    1、关键配置定义:

    2、定义的文件树结构(具体文件后续说明)
点击在新窗口中浏览此图片

三、自定义grains_module
1)#vi /srv/salt/_grains/nginx_config.py

2)同步grains模块
salt '*' saltutil.sync_all

3)刷新模块(让minion编译模块)
salt '*' sys.reload_modules

4)验证max_open_file key的value
[root@SN2013-08-020 _grains]# salt '*' grains.item max_open_file              
SN2013-08-022:
  max_open_file: 1024
SN2013-08-021:
  max_open_file: 1024
SN2012-07-011:
  max_open_file: 1024
SN2012-07-012:
  max_open_file: 1024
SN2012-07-010:
  max_open_file: 1024

四、配置pillar
    本例使用分组规则定义pillar,即不同分组引用各自的sls属性
1)定义入口top.sls
#vi /srv/pillar/top.sls

2)定义私有配置,本例只配置web_root的数据,当然可以根据不同需求进行定制,格式为python的字典形式,即"key:value"。
#vi /srv/pillar/web1server.sls

#vi /srv/pillar/web2server.sls

3)验证配置结果:
#salt 'SN2013-08-021' pillar.data nginx
SN2013-08-021:
    ----------
    root:
        /data

#salt 'SN2012-07-010' pillar.data nginx
SN2012-07-010:
    ----------
    root:
        /www

五、配置States
1)定义入口top.sls
#vi /srv/salt/top.sls

2)定义nginx配置及重启服务SLS,其中salt://nginx/nginx.conf为配置模板文件位置。
#vi /srv/salt/nginx.sls

3)Nginx配置文件(引用jinja模板)
功能点:
1、worker_processes参数采用grains['num_cpus'] 上报值(与设备CPU核数一致);
2、worker_cpu_affinity分配多核CPU根据当前设备核数进行匹配,分别为2\4\8\其它核;
3、worker_rlimit_nofile参数与grains['max_open_file'] 获取的系统ulimit -n一致;
4、worker_connections 参数理论上为grains['max_open_file'];
5、 root参数为定制的pillar['nginx']['root']值。
#vi /srv/salt/nginx/nginx.conf

4)同步配置
#salt '*' state.highstate
点击在新窗口中浏览此图片
(由于非第一次运行,看不到配置文件比对的信息)

5)验证结果:
1、登录root@SN2013-08-021
#vi /etc/nginx/nginx.conf
点击在新窗口中浏览此图片


点击在新窗口中浏览此图片

2、登录root@SN2012-07-010
#vi /etc/nginx/nginx.conf
点击在新窗口中浏览此图片


点击在新窗口中浏览此图片
      这几天讨论maptail的话题比较多,今天抽空将的部署环境做了一下梳理,供大家作为参考。在线DEMO:http://view.linuxtone.org/

一、效果图
点击在新窗口中浏览此图片

二、安装
1、依赖python2.6~2.7版本模块的支持,python已经是2.6或2.7版本略过此步骤


2、安装nodeJS


3、模板安装maptail
npm install maptail -g
*npm作为一个在线管理NodeJS模块的工具,官方默认托管站https://registry.npmjs.org速度在国内很差,建议使用第三代理;推荐http://registry.npmjs.vitecho.com,使用方法:npm --registry "http://registry.npmjs.vitecho.com" install maptail -g

4、启用maptail监听
cd /var/log/httpd (以apache日志为例,系统支持任一带IP地址的日志格式,会自动匹配出IP规则)
nohup tail -f access.log |/maptail -h 192.168.1.5 -p 8080 &

#开机自启动
echo "/usr/bin/nohup /usr/bin/tail -f /var/log/httpd/access_log|/usr/local/bin/node /usr/local/bin/maptail -h 192.168.1.5 -p 8080 &" >> /etc/rc.local
打开浏览器访问:http://192.168.1.5:8080/
Tags:
      准备在小组内部做一次《HTTP协议分析》的培训,为了不受限于Request header与response header的内容,想更深入了解服务器端是如何响应、处理一个请求的,花了几天时间写了Yorserver,目前基本的功能都实现,功能清单如下:
1、支持自定义response服务及协议版本;
2、支持Expires及max-age的功能;
3、支持多进程或线程开启;
4、支持错误页及默认页配置;
5、支持access_log及error_log配置;
6、支持gzip压缩配置;
7、支持安全套连接服务HTTPS;
8、支持HTTP MIME自定义配置;
9、支持php、perl、python脚本cgi访问;
10、支持配置文件。
(Centos6.*环境测试通过)

一、配置文件说明yorserver.conf


程序截图
1、访问日志
点击在新窗口中浏览此图片
  【IT168 专稿】2012年的春运潮造就了中国铁路客户服务中心12306网络购票系统一夜蹿红,从传统购票方式到电子商务,2012年1月1日开通的12306网络购票系统成为了铁道部改革的重要一步。
  但是随着12306系统的上线,各种关于12306系统的抱怨声也层出不穷,不少人抱怨网上订票系统十分“龟速” 网络运行奇慢,网页不时“崩溃”,平均刷新500次才能购到一张票,而且订票过程十分繁琐,从用户注册到支付成功,要13道“工序”,让人晕头转向等等。
  本来为了让每个归家的人更方便地买到火车票,而12306网上订票系统这个号称斥数千万元巨资建立的电商的表现却难以让人信服,并引发了一些讨论和思考,应该如何建设类似12306网上订票系统这种大型高并发高性能网站呢?IT168记者采访了腾讯架构平台部刘天斯,对于大型高并发高性能网站的建设和优化,他给出了自己的建议。

  12306订票网站存在哪些需求特点和挑战?
  12306订票网站具有分时段、分区域、高并发等特点,如何确保在高峰时段正常提供服务是一个非常大的挑战,放眼春运期间网上订票系统,表现为页面访问延时大、登录异常、支付失败等问题。这其中存在一定客观因素,也不排除对流量预估不准确、架构设计不合理等情况。官方公布日均PV达10亿,在高峰时段有千万PV的访问量,应对如此高的流量需要从带宽、服务器、网络、应用及业务逻辑等进行优化。

  国内的大型网站还包括淘宝、京东、新浪等,12306的访问模式和淘宝、京东存在哪些异同?
  相同点都可以理解成电子商务网站,无论是业务逻辑还是应用特点都非常相似,唯一的差别是12306的流量因时段、区域更为集中,有人说像淘宝、京东搞促销,比如”秒杀”。但”秒杀”的对象往往比较固定,后端可以通过缓存机制或静态化来缓解数据库I/O压力,而12306需要每隔10分钟更新票务信息,同时还要保持与集团其它业务系统对接,这点处理起来更为棘手。

  淘宝、TMall、京东也曾经遭遇宕机事件,这些宕机事件和12306网站崩溃有何异同?
  此类宕机事件原因都是相似的,无非是宽带吃紧或服务器性能出现瓶颈(应用故障、高I/O或业务逻辑异常等)。差异点只有体现在业务层面上,促销活动可以推迟或重新组织,但12306订票系统不行。反之,12306有其它辅助的补救、缓解方案,如电话预定、代售点等,传统的电子商务平台则没有。

  12306订票网站在哪些方面可能存在问题?在以上谈到的问题上是否都有一些相应的优化建议呢?
  个人认为更有价值是体现在数据分析上,如得到宽带数据、用户流量、区域分布、请求特点、应用瓶颈点、服务器的性能指标等等,这些数据对优化、改良现有架构非常有帮助。抛开宽带因素,以下是对12306平台系统架构的几点建议:

  一、前端优化
  具体参考:yahoo前端优化34条规则,针对12306平台,个人建议在没有多运营商链路接入(如BGP)的情况下继续使用CDN进行加速。动、静态应用分离,静态业务使用非12306.cn域名可以减少无用cookie带来的流量。任何一个小细节在高并发下都会被无限放大(截止目前发现平台还是以dynamic.12306.cn域名做静态引用)。查询页面的结果是通过Ajax异步返回填充iframe框架来实现,这对动态CDN加速是一个挑战,因为CDN节点并没有真正缓存页面中主要加速的内容。另外提高验证码的复杂度及多样性,可以缓解刷票机给平台带来的压力。

  二、运用缓存
  缓存最大的好处是减少后端数据存储的I/O压力,从一个普通用户订票轨迹来看,查询读往往是入库写的好几倍,如何减少数据库的读I/O对提高平台的整体性能至关重要,比较流行的缓存技术有针对页面及数据级,页面级缓存有varnish、squid等,如使用CDN,页面级的缓存可以不用考虑,重点将精力放在数据级的缓存规划上,技术方面可以用Nosql来实现,比较成熟的Nosql有memcached、redis、mongodb等。可以根据班次、出发与目的地ID组合或出发日期进行hash分区,这样可以很好地提高缓存命中率,减少后端数据库的压力。

  三、代理层
  引入代理层的目的是拆分业务,目前平台绝大部分功能都共用一组WEB服务器(从域名及URI结构猜测,不一定准确)来对外提供服务,比如登录、注册、车票查询、余票查询、列车时刻表查询、正晚点查询、订单管理等等,只要其中一个功能模块出现堵塞,影响必定是全局性的。一个好的方法是优化、规范各业务URI,在代理层实现业务的划分,可用的技术有Haproxy、Nginx等,如将/otsweb/regitNote/映射到注册组WEB服务器,/otsweb/AppQuery/映射到查询组WEB服务器,/otsweb/Pay/映射到支付组WEB服务器等等,如此一来,当查询业务出现延时堵塞时不会影响到用户支付。

  四、数据库层
  之前接触过一些政府行业的业务,数据库服务器往往都使用一台高端的硬件,比如小型机,在互联网行业,尤其是类似于12306订票系统,这往往是最致命的,理由很简单,在大流量并发下处理能力再强的服务器也吐不出数据,因为受网络I/O、磁盘I/O、业务逻辑等方面的限制,所以必须将数据打散,方案有进行读写分离、分区、分片。主从模式可以很好实现读写分离,大部分数据库都支持这点,除此之外还建议使用分区模式,分区策略可以根据业务特点进行,按地域进行分区是一个好主意,因为每个区域都是一个大分区,还可以从业务层面对它做二级甚至三级的"扩展分区"。需要在细化拆分与运营成本上做好平衡。另外I/O密集的点尽量使用SSD代替。

  五、负载均衡层
  保障一个业务平台的高可用性,采用负载均衡策略必不可少,即使是提供给CDN的源服务器。目前有商用的F5、NetScaler、Radware等,也有开源的LVS,看成本的投入来选择,此处不详细展开讨论。

  六、业务层
  此次12306网站瘫痪事件,业务层面有无优化的空间?12306网站平台是铁道集团在互联网上对外服务的窗口,与电话订票、代售点都是平级的,后端肯定还关联着很多复杂的业务系统,在没有对整个集团业务系统做扩容的前提下(短期内估计不能实现),可以将网站业务平台剥离出来,当然,完全剥离也不太实际,至少可以延长同步、一致性校验的时间。时间的长短随班次的发车时间成正比,因为大部分的用户都是提前一周以上就着手预定车票。

  从百万级、到千万级并发PV的网站,在构架和部署方面会存在哪些差异?
  百万PV到千万是一个级别的提升,设计得再好的架构也很难一步到位,也是随着业务的高速增长,不断积累经验、优化、改良的过程。12306的流量达到千万PV 级,但平台的支撑能力远远没有达到预期。

  一个大型的高并发高性能网站架构需要从哪些层面去考虑?服务器/存储部署方面需要注意哪些问题?哪些技术能够保证整体系统的高并发与高性能?
  设计一个大型高并发网站的架构,首先必须以了解业务特点作为出发点,架构的目的是支撑业务,需要考虑互联互通、负载均衡、网络、开发、缓存、存储、数据库等层面,这些层面看似一个整体,任何一个环节出问题都可能导致整个网站崩溃,所以一个高可用、高并发的平台还少不了监控、开发、运维等角色通力协作。

  部署大型的高并发高性能网站架构需要注意哪些问题?存在哪些挑战?高峰期和低谷期的资源和投入如何平衡?
  部署大型的高并发高性能网站架构需要注意整体的扩展性与健壮性,解决未来海量数据的存储与处理、密集的数据I/O、互联互通、应用的不断迭代、重构以及缓存机制等问题,对于考验一个成功的架构提出了更高的要求,也是未来面临最大的挑战。对于平衡高峰期和低谷期的资源投入,我想云计算的伸缩性更适合解决该问题。

  有人建议使用云计算平台(类似于Amazon之类的)来搭建这类网站,以便提高资源利用率节省成本,您是如何看待的?
  云计算是未来一个趋势,优点不多说,它具有动态伸缩、灵活性强等特点,可以让资源利用最大化,可以更好节约成本,非常适用于12306平台。

  虚拟化(不局限于服务器虚拟化,也可以包括网络虚拟化等)在这类型大型高并发网站建设过程中可以起到什么作用?
  虚拟化是云计算的基石,可以降低企业运营成本,提高资源利用率,个人建议将一些运算量及I/O要求不高的业务迁移到虚拟化,比如web、缓存、代理、中间件服务等应用。在低流量时段可以销毁节点,使物理实体机处于低功耗状态下运行,绿色环保,高峰来临时可以迅速部署上线来提供服务。

人物简介

点击在新窗口中浏览此图片
▲刘天斯,目前就职于腾讯-架构平台部,曾就职于天涯社区,担任架构师/系统管理员,热衷开源技术的研究,包括系统架构、运维开发、负载均衡、缓存技术、数据库、分布式存储及云计算机等领域,擅长大规模集群的运维工作。关注互联网技术发展动向。


原文:http://server.it168.com/a2012/0208/1309/000001309060_all.shtml
Tags: , ,

      受CU管理员的邀请参考“千万级pv高性能高并发网站架构与设计交流探讨帖”主题的交流,发表了一案例与大家分享。

      一个支撑千万级PV的网站是非常考验一个架构是否成熟、健壮(本文不涉及软件架构的层面,有兴趣也可以讨论)。现抛出一个系统层面的架构,不保证是最优的方案,但也许适合你。理由是再优秀的架构都不具备通用性,需要根据每种应用特点针对性来设计。希望起到抛砖引玉的作用,大家多多参与,发表意见。


(点击放大)

架构说明:
1)架构中直接引入软件名称的模块,是个人推荐使用的,如Haproxy、Hadoop等;
2)关于全局负载均衡,看成本投入情况,可以使用商业的产品,如F5-GTM,开源方案便是自搭智能DNS;
3)本地负载均衡方案,可以考虑F5-LTM或成熟的开源解决方案LVS;
4)代理层为什么推荐大家使用Haproxy?Haproxy是一个非常优秀的反向代理软件,十分高效、稳定。国内top 10的互联网公司都有在使用;
5)缓存层可以使用Squid或Varnish,个人更倾向Varnish。配置灵活、运行稳定,提供非常便利的管理接口。为啥在缓存层前面加一层代理?优点非常多,列举如下:
  • 根据应用配置URI路由规则,集中热点来提高后端缓存的命中率;
  • 轻松划分网站频道、版块,更好对应用进步组织、规划;
  • 对URI进行一般性安全过滤,抵御注入攻击;
  • 弹性调配硬件资源,应对突发事件产生大流量;
  • 可回收宝贵的公网IP资源;

6)应用层开源技术方案非常多且成熟,在此不详细描述;
7)数据库层主流开源解决方案Mysql是首选,主从复制(一主对多从)是目前比较靠谱的模式;
8)关于Nosql,应用场景不多说,可参考“给部门做的Mongodb技术交流PPT”文章,redis、memcached等作为热点数据存储、数据库缓存都非常理想;
9)内网DNS扮演的角色非常重要,一定要消灭code中出现的内网IP地址,很大程度减少因IP变更、服务器故障而修改源码的情况,同时也便于维护;
10)内网LB适用在内部WEB接口、多台数据库Slave、多台Nosql Slave、公共服务等应用的负载均衡,可以使用LVS、Haproxy来实现,可用性要求不高的应用可行直接使用Localhost DNS轮询;
11)hadoop适合海量数据的存储与处理,如做网站日志分析、用户数据挖掘等;
12)管理集群,平台的核心,运维的阵地;
      以上粗略介绍了架构的几个组成部分,如大家有对哪块有疑问或感兴趣都可以展开来讨论,也可以通过weibo与我交流:http://t.qq.com/yorkoliu

童真[原创] 不指定

刘天斯 , 2011/07/18 23:40 , My Life , 评论(15) , 阅读(31898) , Via 本站原创

这个盛夏迎来你的480天
烈日炎炎,你给我们的小家带来一阵阵清凉
你成长的一点一滴都是我们热议的话题
你的发呆、欢笑、闹闹、好奇、大叫都那么轻易引起关注
每天你学会说不同的话
每天你在你的世界里都是那么的忙,搬玩具、拆家具、丢衣服、玩弄碗筷、戏水、摔手机... ...


每天带着疲惫的身躯回家,听到你响亮而清晰的一声-爸爸、妈妈
身上的疲惫仿佛已经烟消云散,袭来的是一股股暖流
同时,更多的还有责任
愿幸福、健康、快乐永远伴随你



点击在新窗口中浏览此图片
分页: 2/30 第一页 上页 1 2 3 4 5 6 7 8 9 10 下页 最后页 [ 显示模式: 摘要 | 列表 ]