免费建站真的就是免费吗?如果你打算免费建站，不妨来看看这篇文章在做决定。虽然现在搞互联网都需要烧钱，但是也有一些人希望不需要投入很多钱就能够让自己拥有一个能够赚钱的网站，而且这些人的数量还不少，所以互联网上开始出现了各种免费的大餐，而且这些免费大餐还会被包装成各种噱头，能够让免费的使用者感觉到能够收益更多，简直是一本万利的买卖，或者是空手套白狼的买卖。互联网上有很多各种各样的产品都有免费的先例，想当初淘宝就是通过免费来获得大量的开店者，并一举打败当初的易趣。而且微软也是通过变相的免费来让自己的系统占据当前操作系统的主流。从这些免费来看，也的确实现了买卖双方的共赢。但是在互联网上的一些免费，更多的却是打着免费的幌子，却变相的让你免费为他打工，最终的结果是那些贪小便宜的人浪费了大把的时间。现在互联网中免费建站就是这种打着免费的幌子，变相的让使用者为最终的幕后者免费打工，结果是提供免费建站服务的人获得更多的利润，当然如果你的运气足够佳，或许还能够分享到这个盈利盛宴中的残羹冷炙，大部分的利润还是被这个免费项目的发起者所获取。之所以如此，是因为免费建站会容易产生下面几个问题。第一，域名和主机空间都会存在问题。一个正规的网站，无论是域名还是空间都需要一定的投入，很难免费获取，但是如果是虚拟主机以及二级域名则通常能免费获得，可是这种免费的域名和网站空间，很难获得百度的青睐，甚至百度认为这样的网站不值得收录。可是一旦有人采用这种免费网站进行运行，随着一定时间高质量内容的发布，最终还会给网站带来一定的权重，只是这种权重太低，对于这样的网站个体通常起不到什么作用，可是如果存在着众多这样的网站，并进行链轮连接到一个一级域名上，最终就是你的努力服务了这个一级域名。这就是说你的工作实际上都是在给这个上级域名的网站在服务。第二，通常是动态网页。为了更加节省建站的时间，这类免费的网站大多属于动态网页，也就是通过建站程序自动生成的网站。这些网站难以进行维护，而且想要让他们免费给你售后通常也非常困难。当你的网站运行不佳，或者想要改变相关的内容时，想要请他们帮忙往往很难。因为为了让你为他们进行服务，他们事先为给你提供相应的建站内容方案，你只有在这些方案的框架下进行运营。这么做的目的，也是为了让你的网站和它主要优化的网站之间存在着一定的相关性，如果你想要运行的网站内容和它优化的目标网站存在着差异，这显然不利于最后的优化结果，所以你想要更改网站内容，提升售后体验，通常也是具有极大的难度。第三，免费让你尝到甜头，然后在坑你。有的免费网站大餐并不是要你为你替他免费的服务，而是通过免费来诱惑你上当，进而让免费的网站变得更贵。比如在网站空间上，往往给你预设的非常小，当你网站想要升级，或者开始有了一定人气想要改变时，那么此时收费往往非常高，如果你不找他们进行升级，那么他们会将你的网站空间上的内容进行冻结，不给你转移出去，否则就需要花费更多的资金来购买。最终的结果你还是花费了更多的钱来进行了网站建设。所以说，免费建站虽然看起来很美，同时也具有很多的诱惑性，特别是一些推出免费建站的项目的宣传语，能够让你感觉到得到了巨大的便宜，基本上不需要投入任何资金就能够让你拥有一个赚钱的利器，这让人自然心动不已，可是当你心动不已的时候，你已经踏入了这个坑。
直奔主题！兄弟组件之间的事件触发，大概思路是通过父级组件交换数据，watch来监听触发事件。场景是父级组件A同时引用两个子级组件B，C。点击B组件中的按钮执行C组件中的事件。第一步：父级组件A methods:{ listChild:function(val){//B组件自定义事件 状态是布尔值 this.playStatus = val; }, btmChild:function(val){//C组件自定义事件 this.btmStatus = val; } } 第二步：子级组件B代码props: ['play'],//接受父级传递的数据 watch:{//监听数据 如果改变执行audioPlay函数，audioPlay在methods中定义 play:'audioPlay' } audioPlay：function(){ this.$emit('playStatus',false);//向父级组件传递参数 } 第三步：子级组件C代码props: ['btmStatus'] ,watch:{ btmStatus:'playList' } 总结就是A组件定义两个值分别传递给B，C。然后B，C组件watch方法监听数据触发事件。以上这篇基于vue兄弟组件之间事件触发(详解)就是小编分享给大家的全部内容了，希望能给大家一个参考，也希望大家多多支持站三界导航。原文链接：http://blog.csdn.net/zhuoganliwanjin/article/details/78890778
自动构建系统是从美团的自动部署系统发展出来的一个新功能。每当开发人员提交代码到仓库后，系统会自动根据开发人员定制的构建配置，启动新的Docker容器，在其中对源代码进行构建(build)，包括编译(如Java、C++和Go)、预处理(如JavaScript和CSS)、压缩(如图片)等操作，生成最终需要上线的程序包。背景和问题美团的代码自动部署系统承载着美团所有业务的代码上线工作。代码部署系统一开始基于简单的Bash脚本，从一个中央主机上通过Rsync和SSH进行文件传输和命令执行。图1代码部署系统架构图代码发布系统经过多番演进，增加了很多功能，但原来的中心式架构仍然保留了下来，见图1。发布者通过Web界面或者RESTAPI控制中控机，中控机负责从Git服务拉取代码，构建应用程序包，然后通过Rsync上传程序包到应用集群，并用SSH执行远程命令。自动部署系统为美团业务的快速发展提供了有力的支撑。由于我们采用了开发人员自助上线的方式，发布操作频繁，工作日每日上线达上千次。图2是过去15个月每个月的发布次数。为了持续优化发布速度，给发布人员提供良好的体验，我们把单次发布平均时间作为发布系统的一项重要的KPI。然而，随着美团业务的迅速扩张，服务增多，发布应用数目也增多，中心化的架构的问题也凸显了出来。问题1：资源竞争多个构建任务同时进行，竞争中控机的资源，影响发布速度。有一次一个应用受到同时进行的某Java类应用发布的影响，通常两分钟的发布变成了十多分钟，严重影响发布体验。如果出现事故需要回滚，就是更严重的问题了。问题2：环境冲突不同应用的构建依赖环境在一台发布机上，需要考虑环境冲突和隔离的问题。例如，Java1.6/1.7共存，应用需要通过JAVA_HOME变量指定使用的Java版本，Maven2/3也存在同样的问题。npm的global包也需要兼容多个应用的构建。问题3：安全隐患应用的构建脚本运行在公共发布机上，脚本的Bug可能会影响到发布机的正常运行。例如某次一个构建脚本里面的sudoservicenginxreload命令，本应是在应用服务器上执行的，但开发人员错误配置到了在发布机上执行的构建脚本里面。解决方案解决上述三个问题，我们首先想到的方案自然是重构为多台中控机的可横向扩展的方式。但由于某些应用的特殊性，改动比较麻烦，所以开始并没有走这个方向(现在已实现多中控机)。那么另外一个思路：能不能把构建过程从中控机分离出来?这个思路受到了TravisCI(https://travis-ci.org)的启发。我们借鉴TravisCI，在代码提交时自动在一个新的环境中触发应用的构建。因此，我们的解决方案可以概括为如下三点：把构建过程放到Docker容器;提交代码时自动触发构建;发布时直接使用构建好的应用包。使用前配置如下：在发布系统配置发布项(build.yml);在Stash配置自动构建服务的URL;在私有Dockerregistry上传定制镜像(可选)。使用过程比较简单，主要有如下几个步骤：开发人员提交代码到Stash;触发自动构建;自动构建根据配置生成任务;在Docker服务器上启动容器完成构建;将构建好的包上传到美团云对象存储服务(MSS);发布时从MSS拉取软件包并发布。每次提交代码时会触发自动构建API。构建任务放进队列里，任务在Docker服务器执行。当发布时就不用再去编译，直接拉取软件包进行发布。从图6、图7两幅图中可以看到在发布过程中直接使用了已自动构建好的文件进行部署。图3自动构建的配置图4发布系统的配置界面图5自动构建架构图图6自动构建的日志图7嵌入了自动构建日志的发布日志为什么没有用虚拟机？美团的虚拟化比较彻底，自动构建也可以用虚拟机而非容器实现。但虚拟机都和业务相关，会长时间保留。其次，虚拟机和CMDB深度结合，创建后会上报基本信息，部署Agent，配置监控项等。此外，虚拟机的创建是比较慢的。综合考虑以上几点，我们使用了Docker而不是虚拟机作为自动构建的基本单元。效果和收益基于Docker容器的自动构建很好地解决了之前提到的三个问题：资源竞争、环境冲突和安全隐患。构建任务移出发布机，构建用Docker服务器可横向扩展，解决了资源竞争问题。每个构建都是独立的镜像，环境冲突问题不复存在。构建脚本运行在独立于发布机的Docker服务器上，对发布机造成的安全隐患自然就消除了。除解决了以上三个问题外，自动构建还显著改善了发布速度。经统计，自动构建任务的平均执行时间是197s，而使用自动构建应用的平均发布时间是99s。如果不使用自动构建，那么这些应用的发布时间就是197s+99s，大约是三百秒。可以看到，自动构建把应用的发布时间缩短了三分之二。总结自动构建是美团对Docker的首次应用。这个应用不是为了用Docker而用Docker的，而是在解决代码部署系统中的问题时，利用Docker很好地解决了我们遇到的问题。该应用只利用了Docker最核心的容器功能，并没有使用Docker集群管理、调度、自动扩容等高级的功能。自动构建的场景非常适合使用Docker。希望本文能够对计划开始使用Docker的公司有所启发。
问答社区网络StackExchange由100多个网站构成，其中包括了Alexa排名第54的StackOverflow。StackExchang有400万用户，每月5.6亿PV，但只用25台服务器，并且CPU负荷并不高。它没有使用云计算，因为云计算可能会拖慢速度，更难优化和更难排除系统故障。StackOverflow仍然使用微软的架构，它非常实际，微软的基础设施能有效工作，又足够廉价，没有令人信服的理由需要做出改变。但这并不表示它不使用Linux，它将Linux用在有意义的地方。它的Windows服务器运行的操作系统版本是Windows2012R2，Linux服务器运行Centos6.4。网站数据库MSSQL大小2TB，全都储存在SSD上，它有11台运行IIS的Web服务器，2台运行HAProxy的负载均衡服务器，2台运行Redis的缓存服务器。StackOverflow是一个IT技术问答网站，用户可以在网站上提交和回答问题。当下的StackOverflow已拥有400万个用户，4000万个回答，月PV5.6亿，世界排行第54。然而值得关注的是，支撑他们网站的全部服务器只有25台，并且都保持着非常低的资源使用率，这是一场高有效性、负载均衡、缓存、数据库、搜索及高效代码上的较量。近日，HighScalability创始人ToddHoff根据MarcoCecconi的演讲视频“ThearchitectureofStackOverflow”以及NickCraver的博文“WhatittakestorunStackOverflow”总结了StackOverflow的成功原因。意料之中，也是意料之外，StackOverflow仍然重度使用着微软的产品。他们认为既然微软的基础设施可以满足需求，又足够便宜，那么没有什么理由去做根本上的改变。而在需要的地方，他们同样使用了Linux。究其根本，一切都是为了性能。另一个值得关注的地方是，StackOverflow仍然使用着纵向扩展策略，没有使用云。他们使用了384GB的内存和2TB的SSD来支撑SQLServers，如果使用AWS的话，花费可想而知。没有使用云的另一个原因是StackOverflow认为云会一定程度上的降低性能，同时也会给优化和排查系统问题增加难度。此外，他们的架构也并不需要横向扩展。峰值期间是横向扩展的杀手级应用场景，然而他们有着丰富的系统调整经验去应对。该公司仍然坚持着JeffAtwood的名言——硬件永远比程序员便宜。MarcoCeccon曾提到，在谈及系统时，有一件事情必须首先弄明白——需要解决问题的类型。首先，从简单方面着手，StackExchange究竟是用来做什么的——首先是一些主题，然后围绕这些主题建立社区，最后就形成了这个令人敬佩的问答网站。其次则是规模相关。StackExchange在飞速增长，需要处理大量的数据传输，那么这些都是如何完成的，特别是只使用了25台服务器，下面一起追根揭底：状态StackExchange拥有110个站点，以每个月3到4个的速度增长。400万用户800万问题4000万答案世界排名54位每年增长100%月PV5.6亿万大多数工作日期间峰值为2600到3000请求每秒，作为一个编程相关网站，一般情况下工作日的请求都会高于周末25台服务器SSD中储存了2TB的SQL数据每个webserver都配置了2个320G的SSD，使用RAID1每个ElasticSearch主机都配备了300GB的机械硬盘，同时也使用了SSDStackOverflow的读写比是40:60DBServer的平均CPU利用率是10%11个webserver，使用IIS2个负载均衡器，1个活跃，使用HAProxy4个活跃的数据库节点，使用MSSQL3台实现了tagengine的应用程序服务器，所有搜索都通过tag3台服务器通过ElasticSearch做搜索2台使用了Redis的服务器支撑分布式缓存和消息2台Networks(Nexus5596+FabricExtenders)2Cisco5525-XASAs2Cisco3945Routers主要服务StackExchangeAPI的2个只读SQLServersVM用于部署、域控制器、监控、运维数据库等场合平台ElasticSearchRedisHAProxyMSSQLOpserverTeamCityJil——Fast.NETJSONSerializer，建立在Sigil之上Dapper——微型的ORMUIUI拥有一个信息收件箱，用于新徽章获得、用户发送信息、重大事件发生时的信息收取，使用WebSockets实现，并通过Redis支撑。搜索箱通过ElasticSearch实现，使用了一个REST接口。因为用户提出问题的频率很高，因此很难显示最新问题，每秒都会有新的问题产生，从而这里需要开发一个关注用户行为模式的算法，只给用户显示感兴趣的问题。它使用了基于Tag的复杂查询，这也是开发独立TagEngine的原因。服务器端模板用于生成页面。服务器25台服务器并没有满载，CPU使用率并不高，单计算SO(StackOverflow)只需要5台服务器。数据库服务器资源利用率在10%左右，除下执行备份时。为什么会这么低?因为数据库服务器足足拥有384GB内存，同时webserver的CPU利用率也只有10%-15%。纵向扩展还没有遇到瓶颈。通常情况下，如此流量使用横向扩展大约需要100到300台服务器。简单的系统。基于.Net，只用了9个项目，其他系统可能需要100个。之所以使用这么少系统是为了追求极限的编译速度，这点需要从系统开始时就进行规划，每台服务器的编译时间大约是10秒。11万行代码，对比流量来说非常少。使用这种极简的方式主要基于几个原因。首先，不需要太多测试，因为Meta.stackoverflow本来就是一个问题和bug讨论社区。其次，Meta.stackoverflow还是一个软件的测试网站，如果用户发现问题的话，往往会提出并给予解决方案。纽约数据中心使用的是Windows2012，已经向2012R2升级(Oregon已经完成了升级)，Linux系统使用的是Centos6.4。SSD默认使用的是Intel330(Web层等)Intel520用于中间层写入，比如ElasticSearch数据层使用Intel710和S3700系统同时使用了RAID1和RAID10(任何4+以上的磁盘都使用RAID10)。不畏惧故障发生，即使生产环境中使用了上千块2.5英寸SSD，还没碰到过一块失败的情景。每个模型都使用了1个以上的备件，多个磁盘发生故障的情景不在考虑之中。ElasticSearch在SSD上表现的异常出色，因为SOwrites/re-indexes的操作非常频繁。SSD改变了搜索的使用方式。因为锁的问题，Luncene.net并不能支撑SO的并发负载，因此他们转向了ElasticSearch。在全SSD环境下，并不需要围绕BinaryReader建立锁。高可用性异地备份——主数据中心位于纽约，备份数据中心在Oregon。Redis有两个从节点，SQL有2个备份，TagEngine有3个节点，elastic有3个节点，冗余一切，并在两个数据中心同时存在。Nginx是用于SSL，终止SSL时转换使用HAProxy。并不是主从所有，一些临时的数据只会放到缓存中所有HTTP流量发送只占总流量的77%，还存在Oregon数据中心的备份及一些其他的VPN流量。这些流量主要由SQL和Redis备份产生。数据库MSSQLServerStackExchange为每个网站都设置了数据库，因此StackOverflow有一个、ServerFault有一个，以此类推。在纽约的主数据中心，每个集群通常都使用1主和1只读备份的配置，同时还会在Oregon数据中心也设置一个备份。如果是运行的是Oregon集群，那么两个在纽约数据中心的备份都会是只读和同步的。为其他内容准备的数据库。这里还存在一个“网络范围”的数据库，用于储存登陆凭证和聚合数据(大部分是stackexchange.com用户文件或者API)。CareersStackOverflow、stackexchange.com和Area51等都拥有自己独立的数据库模式。模式的变化需要同时提供给所有站点的数据库，它们需要向下兼容，举个例子，如果需要重命名一个列，那么将非常麻烦，这里需要进行多个操作：增加一个新列，添加作用在两个列上的代码，给新列写数据，改变代码让新列有效，移除旧列。并不需要分片，所有事情通过索引来解决，而且数据体积也没那么大。如果有filteredindexes需求，那么为什么不更高效的进行?常见模式只在DeletionDate=Null上做索引，其他则通过为枚举指定类型。每项votes都设置了1个表，比如一张表给postvotes，1张表给commentvotes。大部分的页面都可以实时渲染，只为匿名用户缓存，因此，不存在缓存更新，只有重查询。Scores是非规范化的，因此需要经常查询。它只包含IDs和dates，postvotes表格当下大约有56454478行，使用索引，大部分的查询都可以在数毫秒内完成。TagEngine是完全独立的，这就意味着核心功能并不依赖任何外部应用程序。它是一个巨大的内存结构数组结构，专为SO用例优化，并为重负载组合进行预计算。TagEngine是个简单的windows服务，冗余的运行在多个主机上。CPU使用率基本上保持在2-5%，3个主机专门用于冗余，不负责任何负载。如果所有主机同时发生故障，网络服务器将把TagEngine加载到内存中持续运行。关于Dapper无编译器校验查询与传统ORM的对比。使用编译器有很多好处，但在运行时仍然会存在fundamentaldisconnect问题。同时更重要的是，由于生成nastySQL，通常情况还需要去寻找原始代码，而QueryHint和parameterization控制等能力的缺乏更让查询优化变得复杂。编码流程大部分程序员都是远程工作，自己选择编码地点编译非常快然后运行少量的测试一旦编译成功，代码即转移至开发交付准备服务器通过功能开关隐藏新功能在相同硬件上作为其他站点测试运行然后转移至Meta.stackoverflow测试，每天有上千个程序员在使用，一个很好的测试环境如果通过则上线，在更广大的社区进行测试大量使用静态类和方法，为了更简单及更好的性能编码过程非常简单，因为复杂的部分被打包到库里，这些库被开源和维护。.Net项目数量很低，因为使用了社区共享的部分代码。开发者同时使用2到3个显示器，多个屏幕可以显著提高生产效率。缓存缓存一切5个等级的缓存1级是网络级缓存，缓存在浏览器、CDN以及代理服务器中。2级由.Net框架HttpRuntime.Cache完成，在每台服务器的内存中。3级Redis，分布式内存键值存储，在多个支撑同一个站点的服务器上共享缓存项。4级SQLServerCache，整个数据库，所有数据都被放到内存中。5级SSD。通常只在SQLServer预热后才生效。举个例子，每个帮助页面都进行了缓存，访问一个页面的代码非常简单：使用了静态的方法和类。从OOP角度来看确实很糟，但是非常快并有利于简洁编码。缓存由Redis和Dapper支撑，一个微型ORM为了解决垃圾收集问题，模板中1个类只使用1个副本，被建立和保存在缓存中。监测一切，包括GC操。据统计显示，间接层增加GC压力达到了某个程度时会显著的降低性能。CDNHit。鉴于查询字符串基于文件内容进行哈希，只在有新建立时才会被再次取出。每天3000万到5000万Hit，带宽大约为300GB到600GB。CDN不是用来应对CPU或I/O负载，而是帮助用户更快的获得答案部署每天5次部署，不去建立过大的应用。主要因为可以直接的监视性能尽可能最小化建立，可以工作才是重点产品建立后再通过强大的脚本拷贝到各个网页层，每个服务器的步骤是：通过POST通知HAProxy下架某台服务器延迟IIS结束现有请求(大约5秒)停止网站(通过同一个PSSession结束所有下游)Robocopy文件开启网站通过另一个POST做HAProxyRe-enable几乎所有部署都是通过puppet或DSC，升级通常只是大幅度调整RAID阵列并通过PXEboot安装，这样做非常快速。协作团队SRE(SystemReliabilityEngineering)：5人CoreDev(Q&Asite)6-7人CoreDevMobile：6人Careers团队专门负责SOCareers产品开发：7人Devops和开发者结合的非常紧密团队间变化很大大部分员工远程工作办公室主要用于销售，Denver和London除外一切平等，些许偏向纽约工作者，因为面对面有助于工作交流，但是在线工作影响也并不大对比可以在同一个办公室办公，他们更偏向热爱产品及有才华的工程师，他们可以很好的衡量利弊许多人因为家庭而选择远程工作，纽约是不错，但是生活并不宽松办公室设立在曼哈顿，那是个人才的诞生地。数据中心不能太偏，因为经常会涉及升级打造一个强大团队，偏爱极客。早期的微软就聚集了大量极客，因此他们征服了整个世界StackOverflow社区也是个招聘的地点，他们在那寻找热爱编码、乐于助人及热爱交流的人才。编制预算预算是项目的基础。钱只花在为新项目建立基础设施上，如此低利用率的webserver还是3年前数据中心建立时购入。测试快速迭代和遗弃许多测试都是发布队伍完成的。开发拥有一个同样的SQL服务器，并且运行在相同的Web层，因此性能测试并不会糟糕。非常少的测试。StackOverflow并没有进行太多的单元测试，因为他们使用了大量的静态代码，还有一个非常活跃的社区。基础设施改变。鉴于所有东西都有双份，所以每个旧配置都有备份，并使用了一个快速故障恢复机制。比如，keepalived可以在负载均衡器中快速回退。对比定期维护，他们更愿意依赖冗余系统。SQL备份用一个专门的服务器进行测试，只为了可以重存储。计划做每两个月一次的全数据中心故障恢复，或者使用完全只读的第二数据中心。每次新功能发布都做单元测试、集成测试盒UI测试，这就意味着可以预知输入的产品功能测试后就会推送到孵化网站，即meta.stackexchange(原meta.stackoverflow)。监视/日志当下正在考虑使用http://logstash.net/做日志管理，目前使用了一个专门的服务将syslogUDP传输到SQL数据库中。网页中为计时添加header，这样就可以通过HAProxy来捕获并且融合到syslog传输中。Opserver和Realog用于显示测量结果。Realog是一个日志展示系统，由KyleBrandt和MattJibson使用Go建立。日志通过HAProxy负载均衡器借助syslog完成，而不是IIS，因为其功能比IIS更丰富。关于云还是老生常谈，硬件永远比开发者和有效率的代码便宜。基于木桶效应，速度肯定受限于某个短板，现有的云服务基本上都存在容量和性能限制。如果从开始就使用云来建设SO说不定也会达到现在的水准。但毫无疑问的是，如果达到同样的性能，使用云的成本将远远高于自建数据中心。性能至上StackOverflow是个重度的性能控，主页加载的时间永远控制在50毫秒内，当下的响应时间是28毫秒。程序员热衷于降低页面加载时间以及提高用户体验。每个独立的网络提交都予以计时和记录，这种计量可以弄清楚提升性能需要修改的地方。如此低资源利用率的主要原因就是高效的代码。webserver的CPU平均利用率在5%到15%之间，内存使用为15.5GB，网络传输在20Mb/s到40Mb/s。SQL服务器的CPU使用率在5%到10%之间，内存使用是365GB，网络传输为100Mb/s到200Mb/s。这可以带来3个好处：给升级留下很大的空间;在严重错误发生时可以保持服务可用;在需要时可以快速回档。我更愿意把StackOverflow看作是能够运行于大规模数据下，但本身并不算大规模的(runningwithscalebutnotatscale)。意思是我们的网站非常有效率，但至少目前为止，我们的规模还不够“大”。让我们通过一些数字来介绍StackOverflow当前是一个怎样的规模吧。以下是一些核心的数字，来自于不久前在一整天(24小时)内的统计，准确说是2013年11月12日。这是一个典型的工作日，并且只统计了我们活动的数据中心，也就是我们自己的服务器。那些对CDN节点的请求和流量被排除在外，因为它们并不直接访问我们的网络。负载均衡器接受了148,084,833次HTTP请求其中36,095,312次是加载页面833,992,982,627bytes(776GB)的HTTP流量用于发送总共接收了286,574,644,032bytes(267GB)数据总共发送了1,125,992,557,312bytes(1,048GB)数据334,572,103次SQL查询(仅包含来自于HTTP请求的)412,865,051次Redis请求3,603,418次标签引擎请求耗时558,224,585ms(155hours)在SQL查询上耗时99,346,916ms(27hours)在Redis请求上耗时132,384,059ms(36hours)在标签引擎请求上耗时2,728,177,045ms(757hours)在ASP.Net程序处理上(我觉得应该发表一篇文章介绍我们如何快速采集这些数据，以及为什么值得耗费精力去获取它们)注意以上数字包括了整个StackExchange网络，但那并不是我们全部的。除此之外，这些数字也仅仅来自于我们为了检测性能而记录的HTTP请求。“哇，一天有这么多个小时，你们怎么做到的?”我们把这叫做魔法，当然有些人喜欢说成“许多个有多核处理器的服务器”，但我们依然坚持这是魔法。以下是那个数据中心里运行StackExchange网络的设备：4个MSSQL服务器11个IIS服务器2个Redis服务器3个标签引擎服务(任何针对标签的请求都会访问它们，比如/questions/tagged/c++)3个ElasticSearch服务器2个负载均衡器(HAProxy)2个交换机(Nexus5596和FabricExtenders)2个Cisco5525-XASA(可看作是防火墙)2个Cisco3945Router有图有真相：我们不仅仅运行网站，旁边架子上还有一些运行着虚拟机的服务器和其他设备，它们并不直接服务于网站，而是进行部署、域名控制、监控、操作数据库等其他工作。上面列表中的两个数据库服务器之前一直都是用作备份，直到最近才作为只读的负载(主要用于StackExchangeAPI)，于是我们可以不需要太多考虑便继续扩大规模了。Web服务器有两个分别用于开发和存储元数据，运行负载非常低。让我们再来总结一下：核心设备如果除去那些多余的设备，以下是StackExchange运行需要的(保持目前的性能水平)：2个MSSQL服务器(StackOverflow在一台，其他的在另一台，实际上只需一台机器运行还能有富余)2个Web服务器(或许3个吧，不过我有信心2个足矣)1个Redis服务器1个标签引擎服务器1个ElasticSearch服务器1个负载均衡器1个交换机1个ASA1个路由器(我们真该找个机会尝试这个配置，关闭部分设备，看看极限在哪)现在还有一些虚拟机运行在后台，执行一些辅助功能，比如域名控制等等。但那都是些相当低负载的任务，我们就不做讨论了，这里把重心放在StackOverflow本身，看看它是怎样全速加载出页面的。如果你希望更精确全面，可以增加一个VMware虚拟机进来，用于执行所有的辅助工作。这样看来并不需要很多机器，但是这些机器的规格通常在云上难以实现，除非你有足够多的钱。以下是这些“增强型”服务器简要的配置介绍：数据库服务器有384GB内存和1.8TB的SSD硬盘Redis服务器有96GB内存ElasticSearch服务器有196GB内存标签引擎服务器有着我们能买得起的最快的处理器交换机每个端口有10Gb的带宽Web服务器不是很特别，有32GB内存、2个4核处理器和300GB的SSD硬盘有些服务器有2个10Gb带宽的接口(比如数据库)，其他有4个1Gb带宽的20Gb的带宽太多余了?你还真特么说对了，活动的数据库服务器平均只利用了20Gb通道中的100-200Mb。然而，像备份、重建等等操作，根据当前内存和SSD硬盘的情况，可以使带宽完全饱和，所以说这样设计还是有意义的。存储设备我们目前有大约2TB的数据库存储(第一个集群有18块SSD硬盘——总共1.63TB，使用1.06TB;第二个集群由4块SSD硬盘组成——总共1.45TB，使用889GB)，这是我们在云服务器上需要的(嗯哼，又要吐槽价格了吧)，请记住这全部都是SSD硬盘。归功于存储器良好的表现，我们数据库的平均写入时间是0毫秒，甚至超出我们能度量的精度了。算上内存中的数据以及两级缓存，StackOverflow中实际的数据库读写比例是40:60。你没看错，60%是写操作(点此了解读写比)。此外，每个Web服务器都有两块320GBSSD硬盘组成的RAID1。ElasticSearch在每个区块大约需要300GB的容量，由于我们会非常频繁的写入或重建索引，SSD硬盘在这里是更好的选择。值得注意的是我们拥有一个SAN(存储区域网络)连接到核心网络，那就是EqualLogicPS6110X，它有24个可热交换的10KSAS磁盘和2个10Gb的控制器。这个设备仅仅被VM服务器用作共享储存空间以保证虚拟机高度的可用性，但并不实际支撑网站的运行。换句话说，如果SAN挂掉了，在一段时间内网站甚至无法察觉(只有虚拟机中的域名控制器能感知到)。整合到一起这所有的设备在一起是为了什么?性能。我们需要很高的性能，这是一个对我们来说很重要的特性。所有站点的首页都是问题页面，我们内部把它亲切地称作Question/Show(路由的名字)。在11月12日，这个页面平均渲染时间是28毫秒，而我们的要求是至多50ms。为了使用户获得更好的体验，我们尽一切可能缩短页面加载的时间，哪怕只有一毫秒。在和性能有关的问题上，我们所有的开发人员都是“锱铢必较”的，这也有助于我们的网站保持快速响应。以下是一些StackOverflow上热门页面的平均渲染时间，数据还是来自于前面统计的那24小时：Question/Show:28ms(2970万次点击)UserProfiles:39ms(170万次点击)QuestionList:78ms(110万次点击)Homepage:65ms(100万次点击)(这对我们来说已经很慢了，KevinMontrose正在着手修复这个问题)凭借对每一次请求的时间线的记录，我们能够准确观察到页面加载的过程。我们需要这样的数据，否则难道靠脑补来做决定吗?有数据在手，我们就可以这样监控性能：如果你对某个特定页面的数据感兴趣，我也很乐意发布出来。但这里我重点关注渲染时间，因为它表示我们的服务器需要多久来生成一个网页。网络传输速度是一个完全不同的话题了(尽管不得不承认它也有很大的关系)，不过将来我会讲到的。增长空间非常值得一提的是我们这些服务器运行时的使用率都非常低。比如Web服务器的CPU平均使用率为5-15%，内存只使用了15.5GB，网络流量只有20-40Mb/s;而数据库服务器CPU平均使用率为5-10%，使用了365GB内存，以及100-200Mb/s的网络。这使我们能做到几件重要的事情：在网站规模增大时不至于需要马上升级设备;当出现问题时(错误的查询、代码以及攻击等等，无论是什么样的问题)，我们能保持网站始终不挂;在必要的时候降低功耗。这里有个我们Web层的监控项目：利用率如此之低的主要原因是高效的代码。尽管本文的主题并不是这个，但是高效的代码对挖掘服务器的性能也有着决定性的作用。做一件非必要的事情所损失的，居然比无所作为还要多——把这引申到代码中就是说，你需要把它们改进得更高效了。这些损失或者消耗可以是能源、硬件(你需要更多更快的服务器)、开发人员理解代码更困难(平心而论，这个有两面性，高效的代码并不一定那么简单)，以及缓慢的页面渲染——可能导致用户更少地浏览网站其他页面甚至再也不访问你的网站了。低效率代码带来的损失可能比你想象的大很多。
企业建立网站是目前企业发展的新趋势。国家对于各类型企业发展的鼓励政策使得企业之间的竞争越发的激烈，有竞争便会有动力，现实生活中的顾客资源应付不了庞大的企业数量，许多企业也陷入了困境当中。然而互联网的市场虽然是存在虚拟世界当中的，但是对于中国本土的企业来说还是有很大的诱惑力的。于是我国企业为了开拓市场，纷纷加入到了企业网站建设的行列当中。随着互联网的发展，装修行业也与时俱进，网络作为一个营销的媒介，发挥着巨大的作用。装修公司拥有自己的企业网站也已经不再新鲜，什么样类型的网站才是最适合装修公司的?可能很多运营者和企业老板都很想知道。但是在面对不同问题的情况下，都不应该盲目，好的装修公司网站应该能够兼顾用户体验和营销推广的，下面就和小编一起来看看，装修公司网站建设的时候经常出现的几大问题吧。1、个人主义化网站建设总是喜欢说：我喜欢这样的网站、我喜欢这样的导航、我喜欢把这个放在这里。请问装修公司的网站只只针对你看吗?难道你喜欢的用户就都要喜欢吗?2、攀比类企业网站建设：这样的类型的错误是最长见到的，因为很装企老板不喜欢看到同行业的企业超过自己，看到同行的企业有网站，他就会要求部门员工“去给我找一家网站建设公司做一个比他们公司还要好的网站”。你根本都不知道人家哪里好，请问你如何超过对方?3、无计划的企业网站建设：很多企业都是突然间的想法并立刻实施公司的网站建设，没有任何关于网站的策划与应用规划。这样设计师的成稿率非常低，同时企业看到设计样稿更是茫然，最后迟迟无法定稿导致企业网站建设无法继续。4、仿制类网站建设：我喜欢他家的网站，我感觉不错，你按照他家的网站给我做一个吧!每一个网站都有他自己的思路，而且他只适合它专属的公司,模仿对方的网站只能是一个外表的模仿，而最后改版升级都是很大问题，因为你不知道这个网站的特点与设计思路是什么。5、理想化企业网站建设：很多企业看到其他的企业通过网络营销迅速的扩充企业资本与销售渠道，而茫然投入到企业网络营销，并且理想化的认为可以立竿见影见到效益，大量疯狂的投入。企业网站与网络营销都是营销与销售的一种手段，产品销售的好坏与产品本身质量还有很多环节是息息相关的，所以要走企业的大战略，网络并不是那么神奇。6、繁琐类网站好多企业总是感觉网站内容不够充实，栏目不够多，想尽办法的给网站增加栏目，添加内容!本以为用户一进入网站会豁然开朗，但是用户却是眉头紧蹙。因为他不知道产品在那里，不知道如何去浏览页面。企业网站建设一定要有主次与层次之分。7、无体验类网站建设：超大的flash动画、大量的图片、超多的文字，把企业的家底全部一股脑的放在了网站上。用户找企业是获取有价值信息，而不是看小说来了!8、无内容类企业网站：全国50%以上的企业网站都是半年不去更新一次内容的，企业网站作用与目的就是快速展示企业信息，如果不去更新那么就失去了网站的价值。9、过简类网站盲目的最求用户体验，错误的认为好的体验是简单的操作与无内容的一目了然。10、无营销类网站很多企业网站建设后，可能连搜索引擎都没有去登陆，客户不问起公司网站从来不对外宣传。网站只有营销才能对企业产生帮助，他不是什么魔法瓶子，可以自动变出钱来!装修公司网站不仅要兼顾用户体验，更要拥有强大的营销功能，在对网站建设的时候不应该盲目，更应该科学的去分析市场和了解同行，用户在了解装修公司的时候，更重要的是得到装企的帮助，比如报价、设计指导等等，只能从功能上进行完善，才能在服务上给予用户更好的体验。江湖装企营销系统是江湖科技针对装修企业开发的网站系统，网站整合了优秀网页设计师的设计理念，不仅兼顾了网站体验，在功能上也开发了在线报价等系统，可以让用户拥有强大的功能体验，营销功能更上一步。企业网站建设是需要细心、恒心与耐心的。在感知到互联网的新变化的时候，要懂得敏感地捕捉新变化的信息，与时俱进地应用到企业网站的建设上来。当国家出台了相应的政策鼓励企业网站的建设时，就需要趁势而上，使得国家的鼓励政策成为企业征战互联网市场的助力。
近年来，移动互联网发展极为迅速，根据有关权威媒体的统计显示，现在移动互联网上的活跃用户在中国已经达到5亿多，而这个数据相比于PC互联网来说，仅有12%的差距，而且当前的移动互联网的每年的新增用户都要远远大于PC互联网，根据该权威媒体预测，在未来的5年里，移动互联网用户必然会超过PC互联网，由此可见，移动互联网已经成为大势所趋。在这种发展环境下，对于站长而言，除了要做好传统的PC互联网网站之外，一定要加强移动网站的建设。但是移动网站和PC互联网网站之间却存在着显著的差别，两者的建站理念同样差距显著，如果将PC互联网上的网站建设理念生搬硬套的应用在移动网站上，那么结果显然会失败。因为移动网站更多的是服务于移动用户，这些用户在使用移动网站时，更多是利用碎片化时间，因此很难长时间的浏览网站。因此移动网站的设计就需要紧密的结合移动用户的这种使用特点来进行设计，下面就对其涉及到的建站细节进行分析。第一，导航模块的设计。移动网站必须要提供导航模块，而且在导航栏目上还需要简明扼要的阐述对应栏目的内容，注重整站导航按钮以及搜索功能的应用，尤其是导航按钮大小的设计，一定要使之符合手指触摸的习惯，通常大小可以设置成32px*32px。其中px的意思就是像素。第二，优化网站内部架构。因为移动网站上的用户对于时间的要求更加快捷，因此移动网站在架构设计上就需要更多的以节省用户的使用时间为设计理念，尽可能的降低网站内部层次，通常只需要首页加详情页就可，只有特殊的网站才会使用到首页加列表以及详情内容这三个层次。也就是说，移动网站的架构应该比PC网站的架构更加扁平化，这可有利于提升对用户的体验度。第三，优化页面以及字体大小。通常移动网站的页面宽度非常重要，如果页面过宽，就会导致用户在手机或者其他智能终端难以正确的浏览网页内容，通常来说，现在移动网站的宽度大多为480像素，或者是640像素。另外为了更好的适应在不同终端上的显示，还可以采用响应式设计方法，这样网站的页面显示能够结合终端的不同而随之匹配，进而能够提升显示效果。另外由于移动网站上的显示空间相对较小，因此网页上的文字大小也要进行控制，如果太小则不利于用户的浏览，如果太大，那么非常占用页面的空间，所以字号在首页上可以略大，通常可以使用14到18之间，而详细页面的字体大小一般在控制在14至16之间。这样可满足页面和用户阅读的体验。第四，内容设计。由于移动网站非常注重用户碎片化时间的应用，因此移动网站上的内容应该尽可能的减少规模，一般来说，一个屏幕能够完整展示的内容就行，当然对于一些质量度较高的内容，或者具有一定吸引力的内容，能够通过滑动三次来完整展示。当然最好不要超过3次，否用户往往很难有如此高的耐心来看完全文。另外移动网站上的广告设计也要注意技巧，一定要是广告内容和文字内容有着高度的相关性，这样才不利于引起用户的反感。总而言之，移动网站对于广大站长们来说，已经开始进入全面发展时期，当然在发展移动网站时，一定要创新之前的PC网站建设思路，使之能够更好的适应移动网站用户的使用习惯，这样才能够更好的提升移动网站的吸引力，进而在移动互联网端取得成功。以上就是小编带来的构建移动网站需要注意哪些细节要点相关内容的介绍，希望能够帮助到大家!
虽然现在企业进行业务还是通过传统的形式进行，但是想要通过互联网来拓展业务的企业也不在少数，可以说这是信息时代的一个大趋势。那么对于很多中小企业网站建设来说，怎样才能让网站起到理想的效果呢?下面我们不妨一起来了解一下。 第一、一定要对整体市场有一个清楚的分析，对于行业当中的竞争对手也要有充分的了解，并结合自身的情况进行综合的分析。第二、中小企业网站建设还要对建站的目的和功能有一个清楚的定位。要明白搭建网站的最终目的是为了宣传企业、宣传产品还是要进行网络电子商务，又或者是要建成行业的门户网站，要确定网站是属于信息类的还是销售类的或者是客户类的。第三、要按照网站的定位来确定技术解决方案，究竟是用自建的服务器还是用租的虚拟服务器。网站是自己的技术人员开发还是跟别人合作开发又或是委托第三方进行开发，网站的安全性也是必须要注意的。第四、中小企业网站建设还需要总是整个网页的设计。网站的风格、颜色应该与企业的形象和文化是保持一致的，要达到网站建设的规范，文字、图片要进行科学的规划，保持网站页面的整体协调性。避免首页是一种风格，打开内页之后又是另外一种风格。第五、如果网站建设要采用新技术的话，还需要考虑到访问网站的群体是什么类型的，分布在什么地方、年龄层次、网络速度、浏览网页的习惯等等。第六、在进行网页设计的时候还要对网站的结构、标签、排版等进行优化，这样才能得到百度、搜狗等搜索引擎的青睐，从而在搜索结果排名当中能够有一个比较好的排名。第七、还需要确定好网页改版的计划，比如说6个月或者是1年之后就要进行整体的改版。第八、需要对网站进行必要的维护，比如说服务器和硬件的维护，对潜在的问题要进行评估。定时对数据库进行整理，数据的有效运用是网站维护的最为重要的方面，所以对数据库的维护是不能小视的。以上就是关于中小企业网站建设的时候需要注意的几个方面，如果这些方面都没有确定好的话，那么就算企业把网站搭建起来也是达不到想象中的效果的。
基本上大家都在说用户体验，不过这也是必须这么做的。只有满足了用户需求，网站才能够呈现出更多的价值，即为企业带来转化以及提升形象。要想做好用户体验，首先需要针对性做好网站结构，考虑用户的浏览访问行为，越好的网站结构越能够引导用户进入到相关页面，进而达到网站存在于世的本来目的。那么，网站的架构如何做利于用户体验呢?就这个问题，下面小编就详细讲解下。1、通俗易懂良好的网站结构首先需要做到通俗易懂，尤其是在导航设计上。很多时候网站的受众人群比较普通，对于检索的信息并非专业人士显得专业，过于专业化的术语对于普遍用户而言了解甚少，若在主导航中利用的话很难能够起到引导作用。故若能够采用通俗易懂的方式进行阐述的话，其引导力就会更强，促使用户进行下一步行为，真正做到了针对于大众用户，而非“专业人士”。在网站结构设计上是必须针对普通用户进行考虑，采用什么样的文字更能够引导用户行为最重要，而非你认为专业就“专业”，专业是需要靠数据说话的。2、便捷性良好的网站结构还必须体现在便捷性，即提高用户检索信息的效率。就拿网站导航来说吧，如何才能够利用导航让用户最快速的寻找到所需信息呢?这想必也是诸多网站结构设计者经常考虑的问题，对于网站而言，受众非常清晰，可以比喻为患者。对于患者而言，真正在意的无非是了解病种的病因、症状、危害、治疗、护理等，故在主导航设计中应该对此进行细分，并且合理的展现出来，能够让寻找症状或者治疗的患者快速直接的进入相关页面，这样的导航结构才是真正做到了便捷性。当然，其他行业的网站导航设计也必须这样，将树形化结构做到细分，落实到用户最终需求。3、多引导很多时候用户的需求并非能够让网站主产生利益，其主要的原因在于缺少必要的引导或者更多的引导。为什么这么说呢?还是从网站结构上谈谈吧，我们都应该知道营销的方法之一是活动策划，活动策划当然是线上与线下的相互配合，而线上就必须把握好网站，网站必须将对应的活动展示出来。而对于大多数**网站而言，往往仅首页飘忽弹窗。飘忽弹窗而言，用户早已不吃这套叫卖，而且当用户着陆页面是其他页面时，就缺少活动的相应入口了，即没能够其他多引导的作用。对于好的网站导航，需要从用户需求进行合理的引导，当然引导的方向是转化率。网站是用户第一能了解和熟知品牌的工具，网站解决了用户的为题，或者指引性的为客户带来疑问，这对进一步的品牌以及转化率是非常有效的。以上就是小编整理的关于如何构建出色的符合用户体验的网站架构的相关介绍，感谢大家的阅读，更多内容请关注站三界导航网站!
最近很多人反应站三界导航打不开，其实都是因为网页卡住正在等待pos.baidu.com的响应，据说只有去掉百度联盟的广告才行。打开网页浏览器底部会显示正在等待pos.baidu.com的响应，网页卡住打不开，是怎么回事?pos.baidu.com是百度联盟广告的服务器，说明这个网页加载百度联盟广告出现请求异常。那么出现pos.baidu.com卡住怎么办？百度联盟广告展现量是非常大的，百度联盟广告服务器肯定也是做了cdn加速的，一般情况下不会出现这个问题，试试清除浏览器cookies和浏览记录再试。如果不行可能是pos.baidu.com服务器cdn出现了延迟，多强制刷新几次，cdn出现请求异常也不是所有地区会出现网页卡住打不开的情况，过段时间等cdn各个服务器同步了也就好了。如果你的网站总是出现这种情况网页卡住打不开，那只好暂时撤下百度联盟广告代码了。意外还发现一种方法，使用再打开网页，就好了。不过我想这可能还是cdn服务器不同步导致的，连接的服务器访问的cdn服务器不同。
在百度搜索东西的时候常常发现有些前面有百度站点的LOGO，用户第一眼就会感觉这个网站非常专业，因此百度站点的LOGO对网站品牌有一定的影响，但是看了某些申请百度站点logo的文章，发现都需要钱来做实名认证或者是实地认证，当然作为一个站长谁也不想花钱，那么有没有一种免费的方法呢？有！当然有，跟着小编继续看下去你就知道了。 最好的办法就是在百度站长工具的后台去申请站点logo。 什么是站点logo? 只要是在搜索结果中出现了首页结果，就会在结果中展示这一个站点logo站点logo是怎么设置的呢?怎么才能申请到? 没有注册百度站长工具的朋友先去注册一下，然后添加验证你的网站。对新站来说，一般百度是不会考虑给你站点logo的提交权限的。 当你添加好了你的网站后，按照上图的指示，然后去看一下你的网站是否有权限添加站点logo。(针对老站加入百度站长工具验证，我不知道百度是否会进行自动验证网站当前SEO情况给予权限的开通) 如果你有权限提交，恭喜您，接下来按照相关的要求进行提交就可以! 这里我要说明两点： 1、你制作的站点logo尺寸一定要符合121*75px和75*75px，否则提交了会很快打回来，这是个门槛。 2、站点logo的制作要清晰、完整、主题突出，让别人看上一眼就知道这个logo是你的网站，不要随意上传、盗用别人的站点logo。 在你提交审核之后，会有审核中的提示，你在此期间可以进行修改审核，预览，在您进行站点logo上传的时候，当然也可以参考绿框中的提示进行制作，很有帮助! 之前，我给我们公司的网站进行了提交审核，但是没有通过，说是其中的一个75*75px的图片尺寸不对，我上传的是75*76尺寸的，然后我又重新进行了修改提交。 在上周的时候，百度给我发了站点提醒，就是关于站点logo开通的消息，我当天就设置了，然后到8号的时候，我们公司的站点logo就已经通过审核了，在百度搜索结果中已经开始显示我上传的站点logo了! 相信大家看完教程之后都会申请了吧，那么赶紧去申请一个百度站点LOGO吧！
KOL123直播导航 
中国互联网举报中心