备案域名购买

老域名出售,已备案域名查询,老域名注册,已备案域名交易,买老域名,二手老域名,出售老域名,上饶网站建设

主页 > 设计架构

高并发网站的设计架构的一些通用性原则及技巧

设计高并发架构需要注意的一些因素与要点:
1,负载均衡架构
    首先网站前端需要采用负载均衡群集解决用户高并发的响应,目前常用方法包括 a、squid反向代理,这也是各大网站常用的方法,包括sohu、sina…;b、DNS轮循;c、采四层硬件设备,包括google、baidu使用这种方式。。。对于lvs,小频道或不重要应用可以尝试使用,对于大流量、实时性要求高的网站目前还不成熟。

2,高性能中间件选择、优化
    中间件选择、优化非常重要,当服务流量大于一定承度时,性能的稍微提升,对于整体硬件成本控制、服务的整体性能提升都是非常可观的。对于web server 目前常用的属apache,但apache 多进程(线程池)架构有一些缺点,进程频繁生成\注销系统开销大,特别当流量大时更是明显,对于应用逻辑简单的可以考虑lighttpd 采用单进程+epoll并发模式,效率高,但对多CPU支持有问题,但可采用启多服务解决这个问题;如果由于应用架构原因必须使用apache,可考虑apache module 性能比普通CGI成倍提升。。。其它原则,包括各中间件各版本测试、包括性能、安全上的考良,找到平衡点,不要太关注某一点因素,导致整体架构上出现隐患,另外一点非常重要,那就中间件的参数优化,这些方面大家可以google、baidu上找找,比较多,但有个原则那就是需要根据服务器实际资源情况进行优化,如httpd最大进程数设多大合适呢?有些朋友,就随手来个2048,觉得这样肯定不会再出现httpd由于进程阀值过低导致拒绝服务,但这有个隐患,因为生成进程,是需要硬件资源的,当进程数达到一定承度,可能服务器内存会溢出,导致服务器crash,特别是内存消耗量大的应用。这样的案例很多,需谨记
3,扩展性问题
     扩展性对于高速发展期间的网站非常重要,大家可以经常在网上看到某某网站的发展励途,那简直就是一部进化史,过程曲折而痛苦~~。因此成熟的经验就非常重要了,扩展性可以从两个方面来看:网络系统上的扩展性及应用本身的扩展性,首先在网络上需层次分明,尽量扁平化,全网冗余不能存在故障点,尽量按业务类型进行划分网络结构(pv大小、优先级)防止互扰,重要的一点:网络设计中,简单就是美~~,在不影响扩展性的前提下,不要搞得太复杂;网络硬件资源、机架位、IDC都需提前至少半年进行规划,这些规划的重要依据是公司业务发展的前景评估,这就体现公司的战略眼光了,包括是否需要外地IDC(依用户群体而定)。。。;另外,选一个好点的IDC是非常必要的,否则就得疲于IDC迁移了,北京地区好IDC还是不少的:皂君庙(有点老了。)、土城、联通、酒仙桥、爱立信、互联世纪、奥运官方机房数字北京据说马上也能入驻了。。。当然了,有钱也能像google一样自已搞个IDC,国内谁有这个实力?
     另一点就是应用本身的扩展性了,原则其实很简单,应用设计时应尽量确保应用的层次化、采用高性能的中间件、逻辑复杂及大数据量交互的功能尽量做成独立模块\后台、cache层、数据库分层(读/写操作分离),不要图前期简单直接将功能全部揉进前端CGI中,这很致命,随时都可能会遇到性能瓶颈、而且毫无扩展性。。。
      当以上两点很好的解决后,现在唯一的问题就是每半年根据业务的PV增涨、新业务发展,预购服务器了。。。;当然了,对现有架构优化,性能提升才是根本解决之道,特别是现在全球经济不景气,大家都不好过,这就是运维工程师的责任了,优化再优化!
4,应用设计、开发中的注意点
    架构层设计好后,应用层设计就是我们重点关注对象了,这也是一个项目成功的关键,好的设计主要体现在:性能(高并发承载能力)、可扩展性、可维护、安全性(数据完整性、应用稳定性、前端应用安全如SQL注入。)、模块冗余、负载均衡等等,技术点:线程池、epoll、TCP(长/短)连接的选择、功能模块的细化及后台化、模块冗余/负载均衡考虑(可扩展性)、高频数据cache缓存、数据分层、应用单故障点的解决(数据唯一性问题)等。
    有两点要注意:(1)应用设计时要允分考虑服务器、硬件设备甚基于IDC的不可靠性;也就是说我们在应用设计时需要考虑到应用运行过程中,随时都可能会有1~2台服务器或更多服务器出现故障情况(网络故障、灾难、攻击、停电(整个IDC全挂)),
    如google GFS就是一个典型,我们不能将应用的稳定性寄托于硬件的稳定上,特别是门户型公司大部份采用的都是X86普通机型,服务器crash是家常便饭、随时随刻(当总量到一定量级时),所以我们在做应用架构设计时需允分考虑这些问题发生时的对策,做到允分的冗余/负载均衡(这两点可统一),如多IDC间通过智能CDN的流控、单IDC应用模块多节点冗余/负载均衡等,即使某些应用由于特殊原因无法做到这点,也需允分考虑应急预案。好的设计在这些突发情况下可以做到不用人工干预,当然难度也很大。记得李开复在北大演讲时说过:google一个IDC同时故障800台机器,不会影响到任何应用的正常响应;(2)大流量应用/模块中能不使用数据库就不要使用数据库.
5,数据库问题
    如数据库缓存,在高并发高处理的时候,在整个应用程序下,缓存是全局共享的,然而在我们进行修改的时候就,如果两个或者多个请求同时对缓存有更新的要求的情况下,应用程序会直接的死掉。这个时候,就需要一个好的数据并发处理策略以及缓存策略。
    数据库的死锁问题,死锁在高并发的情况下的出现的概率是非常高的.还有就是考虑图片服务器分离,数据库集群和库表散列,镜像等
6,用户分地域优化问题
     这就根据某个地域用户集中访问进行相应的设制策略.等服务了。

标签:高并发网站  设计架构  通用性原则  技巧  zhushican发布于2014/8/17围观评论:0

回顶部