自从百度出了“抓取异常”检查后，很多站长都发现了网站总是频繁出现“异常提示”，那么最常见的问题有网站出现50X类型错误、抓取DNS以及抓取超时错误，网站出现这些错误的时候怎么办呢?本文提供网站“抓取异常”问题的解决方案供大家了解，希望对大家有所帮助和启发一、出现50X类型错误：这样的链接其中一个共同的特点是?并非向搜索引擎展示的存在了504、500、502的问题，当打开后，全部都是正常的。那么蜘蛛为什么会报错提醒呢?出现此类型的问题100%是因为服务器造成，而对于某一个状态码的含义，请百度直接搜索后，交给技术来进行解决。如果技术还是解决不了，那么建议更换一下服务器了。二、抓取出现DNS错误很多小白发现网站打不开了就会找服务商，但是却忽略了一个点：域名DNS服务器同样也会出现问题啊!当网站出现问题后，第一时间应当确定到底是什么问题。如果是DNS问题，建议立即更换DSN。友情提示一点：DNSPOD被广泛使用，笔者近期监测免费节点存在一些超时，也在此提醒DSNPOD着手解决。另外很多站长目前喜欢用“一些云加速”，不过笔者同样要说的是：目前不少所谓的云加速并不成熟，尤其是那些免费的，前期做的很好，后期得到用户了，就糟糕透顶了。友情提示：如果你的网站没有遭遇猛烈攻击，请不要使用所谓的云加速，追求花样，更容易害了自己。而域名DSN方面目前万网(阿里)做的是最稳定的。三、出现抓取超时问题在A5营销的SEO诊断中，我们格外的注重用户体验，其中有一点是非常重要的：用户打开页面的速度，页面如果不能在第一时间打开页面，那么就会丧失掉访问资格，而跳到其他网站上去。而蜘蛛呢?同样如此，如果无法第一时间抓取，就会出现抓取超时问题了。而这个抓取超时，往往是因为带宽不足，以及页面太大而引发的，而页面方面我们建议：A：尽量在不影响图片质量的情况下，对图片进行压缩，上传的时候就进行了压缩。B：减少如JS脚本文件类型的使用，或者进行合并。C：页面长度进行控制，尤其是网站首页。D、内链数量，一个页面内的内链数量通常不建议超过500条。其实吧，选择一套成熟的程序建站，一家稳定的IDC，只要你的网站规模不是特别大，基本上这些问题是避免的。怕就怕想花最少的钱，还要最得到最好的服务。以上就是对网站“抓取异常”问题的解决方案全部内容的介绍，更多内容请继续关注站三界导航!
被Facebook以10亿美金收购的著名手机照片分享应用Instagram最近吸引了无数人的眼球，Instagram联合创始人MikeKrieger说他们用了8周时间打造了最初的Instagram，但现在的系统肯定已经今非昔比。Instagram技术团队曾发表过一篇文章，介绍了Instagram背后的技术，日前MikeKrieger在名为ScalingInstagram的演讲里，又介绍了更多细节，让人们能了解到5名技术人员是如何支撑起整个系统的。一张照片上传的过程是这样的：1.采用同步的方式写入媒体数据库2.如果照片上有地理位置标签，则以异步的方式将照片提交给Solr进行索引3.将照片的ID加入每个关注者的列表里，该列表保存在Redis之中4.在显示Feed时，选取一小部分照片ID，在Memcached里进行查询5.在设计系统时，Instagram的设计哲学是简单、为最小化运维负担进行优化并监控一切内容;其核心原则是保持简单，不要重复发明轮子，尽可能使用经过验证、稳定可靠的技术。由于只有5名技术人员(其中仅2.5名后端工程师)，精力有限，选择Amazon的云服务是个不错的选择。目前他们使用了超过100个EC2实例用于提供各种服务，运行的操作系统是Ubuntu11.04，之前的一些版本在高流量时表现不够稳定。在负载均衡方面，他们使用Amazon的ElasticLoadBalancer实现负载均衡，后端运行了3个Nginx实例，SSL只到ELB上为止，降低了Nginx上的CPU负载。DNS和CDN分别由Amazon的Route53和CloudFront提供，所有的照片都存放在S3上，目前已经有几TB的规模了。用于处理请求的应用服务器运行于AmazonHigh-CPUExtra-LargeInstance之上，由于他们的请求更多是CPU密集型的，因此这能更好地平衡CPU与内存。采用的开发框架是Django，WSGI服务器是Gunicorn，通过Fabric在所有机器上进行并行部署，一次部署仅需几秒钟。用户信息、图片元数据、标签等大部分数据存储在PostgreSQL中。实践中发现Amazon的网络磁盘系统单位时间内寻道能力不行，所以有必要将数据尽量放到内存中。创建了软RAID以提升IO能力，使用的Mdadm工具进行RAID管理。管理内存中的数据，vmtouch这个小工具值得推荐。PostgreSQL设置为Master-Replica方式，流复制模式。利用EBS的快照进行数据库备份。使用XFS文件系统，以便和快照服务充分配合。使用repmgr这个小工具做PostgreSQL复制管理器器。连接池管理，用了Pgbouncer。ChristophePettus的文章包含了不少PostgreSQL数据库的信息。应用程序在连接数据库时，由Pgbouncer建立连接池。目前，Instagram的数据按照用户ID进行分片，某些分片可能会超出物理节点的容量上限，为此他们将数据分成了很多个逻辑分片，映射到少数几个物理节点之上;当一个节点被填满之后，可以将某些逻辑分片移到别的节点上，以缓解该节点的压力。随着数据量的增长，以后他们也会进行垂直分区，DjangoDBRouter能让一切轻松不少。Instagram也大量使用Redis来存放复杂的对象(对象的大小做了一定的限制)，用于主Feed、活动Feed、会话系统及其他相关系统。因为要将Redis的所有数据都放在内存里，此处同样也用了High-MemoryQuadrupleExtra-LargeInstance，并对数据做了分片。当Redis实例的请求达到4万/秒后，它渐渐成为了瓶颈，于是Redis也做了主从复制，副本的数据会经常导出到磁盘上，通过EBS快照进行备份。除了Redis，他们还使用Memcached来做缓存，目前运行了6个实例，应用服务器通过pylibmc和libmemcached进行连接。虽然Amazon提供了ElasticCache服务，但该服务的价格并不便宜，相比之下，还是运行自己的Memcached实例比较划算。异步任务队列使用的是Gearman，目前有大约200个工作进程来处理各种任务，比如把照片分享到Twitter和Facebook，通知用户有新照片等等。Pyapns已经处理了十亿的推送通知，非常稳定，他们还自己开发了基于Node.js的node2dm，用于向Android设备发送推送通知。监控方面，Instagram使用Munin以图形化的方式呈现整个系统的运行状况，还通过Python-Munin定制了一些插件，用来显示业务数据;网络守护进程Stated可以实时收集数据并做汇总;Dogslow会监控进程，一旦发现运行时间过长的进程，便会保存该进程的快照，以便后续分析，比如响应时间超过1.5秒的请求，通常都是卡在Memcached的set()和get_many()方法上。对于Python的错误，只要登上Sentry就能实时获取错误信息。HighScalability上还根据整理Instagram团队软件工程师MikeKrieger的演讲整理了一些值得借鉴的经验，比如：1.找那些你熟悉的技术和工具，在简单的使用场景里先做一些尝试2.不要使用两个工具来处理同样的任务3.事先准备降级方案，以便在需要时降低负载4.不要过度优化，或者希望能事先知道站点要扩展，对于一个初创的社交站点而言，没什么扩展性问题是解决不了的5.如果一个办法不行，赶快换下一个
2014年Twitter发布了Answers，至今移动社区产生了惊人的使用量，让Twitter感到兴奋不已。现在Answers每天处理50亿次会话，并且这个数量在持续增加。上亿设备每秒向Answers端点发送数以百万计的请求。在你已经阅读到此处的这段时间里，Answers后台收到并处理了一千万次分析事件。其中的挑战是如何利用这些信息向移动开发者提供可靠的、实时的、有实际价值的洞见（视角）去了解他们的移动应用。在高层，Twitter依靠组件解耦、异步通信、在应对灾难性故障时优雅地服务降级等原则来帮助架构决策。Twitter使用Lambda架构将数据完整性和实时数据更新结合起来。在实践过程中，Twitter需要设计一个能够接收并保存事件、执行离线和实时计算且能将上述两种计算结果整合成相关信息的系统。这些行为全部都要以百万次每秒的规模执行。让Twitter从第一个挑战开始：接受并处理这些事件。事件接收在设计设备-服务器通信的时候，Twitter的目标是：减少对电池和网络使用的影响；确保数据的可靠性；接近实时地获取数据。为了减少对设备的影响，Twitter批量地发送分析数据并且在发送前对数据进行压缩。为了保证这些宝贵的数据始终能够到达Twitter的服务器，在传输失败随机退避后以及达到设备存储达到上限时，设备会进行重传。为了确保数据能够尽快到达服务器，Twitter设置来多个触发器来使设备尝试发送：当程序运行于前台的时候，事件触发器每分钟触发一次；一个消息数量触发器和程序转入后台触发器。这样的通信协议导致设备每秒发送来数以万计压缩过的有效载荷。每一个载荷都包含数十条事件。为了能够可靠的、易于线性伸缩的方式去处理载荷，接收事件的服务必须极度简单。这个服务使用GO语言编写，这个服务使用了亚马逊弹性负载均衡器（ELB），并将每一个消息负荷放入一个持久化的Kafka队列。存储Kafka是一个持久存储器，因为它把收到的消息写入磁盘并且每个消息都有多份冗余。因此一旦Twitter知道信息到了Kafka队列，Twitter就可以通过延迟处理、再处理来容忍下游延迟和下游失败。然而，Kafka不是Twitter历史数据的永久真理之源——按照上文提到的速度，仅仅是几天的数据，Twitter也需要数以百计的box来存储。因此Twitter把Kafka集群配置为将消息只保留几个小时（这些时间足够Twitter处理不期而至的重大故障）并且将数据尽快地存入永久存储——亚马逊简易存储服务（AmazonS3）。Twitter广泛地使用Storm来进行实时数据处理，第一个相关的Topology就是从Kafka读取信息并存储到AmazonS3上。批量计算一旦这些数据存到了S3上，Twitter可以使用亚马逊弹性MapReduce（AmazonEMR）来计算Twitter的数据能够计算的任何东西。这既包括要展示在客户的仪表盘上的数据，也包括Twitter为了开发新功能而开发的实验性的任务。Twitter使用Cascading框架编写、AmazonEMR执行MapReduce程序。AmazonEMR将Twitter存储到S3上的数据作为输入，处理完毕后，再将结果存入S3。Twitter通过运行在Storm上的调度topology来探测程序执行完毕，并将结果灌入Cassandra集群，这样结果就能用于亚秒级查询API。实时计算迄今，Twitter描述的是一个能够执行分析计算的持久的容错的框架。然而，存在一个显眼的问题——这个框架不是实时的。一些计算每小时计算一次，有的计算需要一整天的数据作为输入。计算时间从几分钟到几小时不等，把S3上的输出导入到服务层也需要这么多时间。因此，在最好情况下，Twitter的数据也总是拖后几个小时，显然不能满足实时和可操作的目标。为了达成实时的目标，数据涌入后进行存档的同时，Twitter对数据进行流式计算。就像Twitter的存储Topology读取数据一样，一个独立的StormTopology实时地从KafkaTopic中读取数据然后进行实时计算，计算的逻辑和MapReduce任务一样。这些实时计算的结果放在另一个独立的Cassandra集群里以供实时查询。为了弥补Twitter在时间以及在资源方面可能的不足，Twitter没有在批量处理层中而是在实时计算层中使用了一些概率算法，如布隆过滤器、HyperLogLog（也有一些自己开发的算法）。相对于那些蛮力替代品，这些算法在空间和时间复杂度上有数量级的优势，同时只有可忽略的精确度损失。合并现在Twitter拥有两个独立生产出的数据集（批处理和实时处理），Twitter怎么将二者合并才能得到一个一致的结果？Twitter在API的逻辑中，根据特定的情况分别使用两个数据集然后合并它们。因为批量计算是可重现的，且相对于实时计算来说更容错，Twitter的API总是倾向于使用批量产生的数据。例如，API接到了一个三十天的时间序列的日活跃用户数量数据请求，它首先会到批量数据Cassandra集群里查询全范围的数据。如果这是一个历史数据检索，所有的数据都已经得到。然而，查询的请求更可能会包含当天，批量产生的数据填充了大部分结果，只有近一两天的数据会被实时数据填充。错误处理让Twitter来温习几个失效的场景，看一下这样的架构在处理错误的时候，是如何避免宕机或者损失数据，取之以优雅地降级。Twitter在上文中已经讨论过设备上的回退重试策略。在设备端网络中断、服务器端短时无服务情况下，重试保证数据最终能够到达服务器。随机回退确保设备不会在某区域网络中断或者后端服务器短时间不可用之后，不会压垮（DDos攻击）服务器。当实时处理层失效时，会发生什么？Twitter待命的工程师会受到通知并去解决问题。因为实时处理层的输入是存储在持久化的Kafka集群里，所以没有数据会丢失；等实时处理恢复之后，它会赶上处理那些停机期间应该处理的数据。因为实时处理和批处理是完全解耦的，批处理层完全不会受到影响。因此唯一的影响就是实时处理层失效期间，对数据点实时更新的延迟。如果批处理层有问题或者严重延迟的话，会发生什么？Twitter的API会无缝地多获取实时处理的数据。一个时间序列数据的查询，可能先前只取一天的实时处理结果，现在就需要查询两到三天的实时处理结果。因为实时处理和批处理是完全解耦的，实时处理不受影响继续运行。同时，Twitter的待命工程师会得到消息并且解决批处理层的问题。一旦批处理层恢复正常，它会执行那些延迟的数据处理任务，API也会无缝切换到使用现在可以得到的批处理的结果。Twitter系统后端架构由四大组件构成：事件接收，事件存储，实时计算和批量计算。各个组件之间的持久化队列确保任意组件的失效不会扩散到其他组件，并且后续可以从中断中恢复。API可以在计算层延迟或者失效时无缝地优雅降级，在服务恢复后重新恢复；这些都是由API内部的检索逻辑来保证的。Answer的目标是创建一个仪表盘，这个仪表盘能够把了解你的用户群变得非常简单。因此你可以将时间花费在打造令人惊叹的用户体验上，而不是用来掘穿数据。
创建链接是最有效的搜索引擎优化技巧之一，因为高质量的链接可以给你的网站带来可观的流量。链接是搜索引擎衡量一个网站权重的重要指标之一，丰富、优质的外链可以帮助你提高网站权重，从而很容易被搜索引擎所收录，进而可以帮助你网站提升排名。然而，错误的使用链接往往会对你的网站产生负面影响，损害你的网站排名。下面我们给大家分享在创建链接时需要注意的5大禁忌。使用付费链接许多网站站长创建链接时会使用付费链接，这些链接也许在一开始的时候会起到一定的作用，但是这种方式会增加你的网站被谷歌惩罚的风险，影响到你的网站排名，这样通常会适得其反。相比自然链接，付费链接给你的网站带来的是低质流量。为此我们建议你避免使用这样的链接，并尽可能地创建高质量的和网站内容相关的链接，来提高你的网站流量和排名。使用不适当的锚文本使用锚文本是网站站长在创建链接特别是外部链接时，需要考虑的一个重要的因素。锚文本告诉搜索引擎你的链接内容是什么，使用锚文本有利于增加你的网站流量。但是如果你使用同一个锚文本来创建多个链接，很有可能你的链接将会被视为垃圾链接，导致你网站受到处罚，这将严重影响你的网站流量和你的网站排名。因此，当你在编辑锚文本时应该避免出现像“点击这里”或“查看更多”这样的链接文字，因为这看上去太刻意了。你使用的锚文本应该是和你的网站内容相关联的内容，并且是自然而然地植入到相关内容中。你可以利用一些工具分析你的锚文本是否得当，如MajesticSEO，RavenTools，Ahrefs，CognitiveSEO，OpenSiteExplorer和SEOSpyGlass等它们将为你的链接建设有很大的帮助。使用来自限制网站的链接另一个你需要避免的错误是使用来自限制网站的链接。有些网站是没有被搜索引擎收录的，如果你使用来自这种网站的链接，你的网站很有可能会受到惩罚，这对你的网站的伤害是非常大的。所以在创建链接的时候，你应确保该网站链接已经被百度和其他主要的搜索引擎收录。如果你想知道某个网站是否被被百度收录，你可以使用收录查询工具。你只需要打开这个工具，粘贴你想要链接到的网站的URL。如果这个网站是被收录的，那么它就会给出这个网站的链接，说明这个链接你是可以使用的。把你的链接放在已经有许多其他链接的网页上所有的网站站长都希望通过创建链接使他们的网站获得流量。为此他们利用插件比如CommentLuv把他们的链接放在博客评论中。这听起来是一个增加网站曝光率的好办法，但是你把你的链接放在一个已经有大量其他链接的网站上，这并非明智的做法。试想一下，当你面对这么多的链接，你会去一一阅读这些评论并点击这些链接进去访问他们的网站吗?应该是不会吧。因此，你在分享链接时，最好把它放置在一个链接数量低于1000的网站平台上。此外你应该确定在这个平台上用户之间是有互动的，而且你的评论是有价值的。如果你是在论坛或者问答网站上进行推广，尽量选择回答回帖数、答案不超过10条的问题，而且确保你的帖子和答案是与问题相关且有益的。只有这样，别人才会看到你的回答并且点击回答中的链接去访问你的网站。使用没有ALT文本的图像链接有的网站站长喜欢使用图像链接。但是，如果你在创建图像链接的时候忽略或者忘记加入ALT文本，这将是致命的错误，因为ALT文本可以把你想传达的信息准确地传递给你的读者，也使你的图像链接更容易进入网站。没有ALT文本的图像链接是没法进入网站的，这自然也就达不到增加网站流量的目的。为了使你的图像链接有效，你也需要创建一个有效的ALT文本，你应该确保ALT文本内容准确、简洁，不冗余或有短语。
一般情况下，初级程序猿无非是用企业站CMS居多，少数部分会接到一些简单的行业站。首先，你要弄清楚你现在是属于哪个级别，如果是什么都不懂的，就想直接弄一个CMS，包括模板也不修改的，只替换个LOGO的，那么恭喜你，随便找一个演示模板不错的CMS，直接下载，安装，后台修改一下配置，OK，一个网站出来了。那么随之带来的问题是，以后如果你们老板想要加功能，修改个布局，你就等着哭吧。如果你是会DIVCSS，并且对PHP还有一点基础的话，当然PHP水平没有那么高，那么你可以找一个标签调用方便的CMS，比如,ShuipFCMS,DEDECMS，TWcms等就够用了。(DEDECMS现在漏洞太多了，不建议大家再使用了。)如果你是进阶中的PHP新手的话，你要选择一个cms框架标准的CMS，主要是MVC架构的CMS，比如,PHPCMS,DUXCMS.因为MVC大家都知道二次开发确实比较方便。如果你是做项目，那么一般情况下选择的是PHP框架，比如,CI,THINPHPL,CANPHP，YII等框架，当然你喜欢什么模型你自己选择。如果是一些小弄的项目的话，可以找一些项目模型，比如，DUXADMIN。选择CMS的时候，也建议大家选择有后台的CMS，这样，不至于得不到技术帮助，并且流行的CMS,论坛都有活跃的用户来回答你的问题，否则，有一些CMS作者一时心血来潮做的CMS，过一段时间由于时间或者工作等问题，项目坚持不下去了，你有问题也没有渠道问呀。在这里给大家推荐几款CMS，一款是PHPCMSV9,V9出自盛大团队，这个后台够硬吧，性能也是挺不错，二次开发也不错，并且还是MVC，模板标签调用也挺方便的，并且在模板中也可以直接写PHP语句。是做企业站还是门户站不二之选。还就是一个就是企业站的CMS，名叫DUXCMS，这个CMS以简洁著称，你安装一次你就会深深的喜欢上它，并且它还支持多语言，也是基于MVC架构，扩展起来也方便，有简单的会员中心，总之，值得使用。
Netflix是一家在线影片租赁提供商，该公司连续五次被评为顾客最满意的网站，在过去的7年中，Netflix流媒体服务从偶尔有数千用户在线观看发展到了数百万用户平均每月观看超过20亿个小时的规模。Netflix之所以能够如此成功，离不开对用户行为数据的收集与分析，那么Netflix会收集哪些数据，这些数据会用来做什么，其处理架构又是什么呢？事实上，当用户开始在Netflix的网站上观看电影或者电视节目的时候，Netflix的数据系统会创建一个“观看会话（view）”，描述该会话的所有事件信息都会被收集起来。该观看会话数据架构能够应对从用户体验到数据分析的诸多场景，其中最主要的场景有三个：用户看了哪些视频？系统需要知道每一个用户的所有观看历史，以便于为用户推荐相关的视频内容，同时在页面上的“最近观看”一栏中显示观看历史。用户所看的内容对于用户兴趣的衡量，产品和内容的决定非常重要。用户从哪里离开了视频？对于每一个电影或者电视节目，Netflix会记录每一个用户都看到了哪里，从哪个时间点离开的。这使得Netflix的用户能够在同一个或者另一个设备上继续观看视频。当前帐户现在还在观看哪些视频？家庭成员间的帐户共享使得任何人可以在任何时候观看自己喜欢的视频，但是这也意味着当帐户同时在线数超限的时候，必须要有人放弃观看。针对这种场景，Netflix的观看会话数据系统会收集每一个会话的周期性信号以便于决定某个成员是否还在观看相关视频。这些场景的实现离不开强大而稳定的数据处理系统，Netflix目前的系统架构由早期的单数据库应用程序演变而来，当时的主要需求是能够低延迟地为用户提供视频服务，同时还能够处理来自于数百万Netflix流设备的快速增长的数据集。在过去3年多的时间里，Netflix一直在不断地改进该架构，现在这套系统每天能够处理千亿左右的事件。当前的架构图如下：整个架构最主要的接口是观看会话服务，它分为有状态层和无状态层两部分。有状态层在内存中存有所有活动视图的最新数据。通过对用户帐户ID进行modN的模运算，数据被简单地划分为N个有状态的节点。当有状态的节点上线的时候，系统会通过一个位置选择流程决定哪部分数据属于它们。所有的持久化数据都存储在Cassandra中，在Cassandra之上有一个Memcached用来保证低延迟的读取路径，但是采用这种方式会话数据有可能会过时，同时如果一个有状态的节点出现了错误，那么1/n的浏览数据将不能读写。无状态层的引入正是为了解决这一问题，它提升了系统的可用性，当有状态的节点无法访问的时候，该层会将过时的数据反馈给用户。但是即使是做了诸多改进，以上架构依然存在一些缺陷：虽然有状态层使用一个简单的、服从热点分布的分片技术，但是Cassandra层并不服从这些热点；同时，如果将其从一个AWSRegion移动到多个AWSRegion上运行，那么必须定制一种机制来实现分布在不同Region上的状态层之间的状态通信，极大地增加了系统的复杂性。对于观看会话服务，它封装了会话数据的收集、处理和提供功能，随着系统的演变，功能的增多，该服务的责任也越来越多，增加了运维的难度。虽然Memcached提供了非常好的吞吐量和延迟特性，但是使用一种能够为一等数据类型和操作（例如append）提供原生支持的技术能够更好地满足相关需求。为了扩展系统满足下一个数量级的需要，Netflix正在重新思考自己的基础架构，新系统在设计时考虑的主要设计原则包括：可用性比一致性更重要。微服务。对于有状态架构中柔和在一起的组件，根据它们的主要目的分离成单独的服务——或收集、处理或提供数据。将状态管理功能托管到持久化层，让应用程序层无状态，同时组件之间通过事件队列解耦。混合持久化。使用多种持久化技术，利用每一种方案的优势。使用Cassandra实现高容量、低延迟的写。使用Redis实现高容量、低延迟的读。遵循以上原则的新架构实现如下：当然，这个架构图也仅仅是Netflix目前的设计图，至于实现到何种程度了，我们还未可知。Netflix表示对关键系统进行重新架构以使其能够扩展到下一个数量级是一项非常困难的工作，需要长时间的开发、测试和验证，同时迁移也不是那么容易。但是以这些架构原则为指导，Netflix相信他们正在构建的下一代系统能够满足自己大规模、快速增长的需要。
视觉设计有一个天然的困难，因为视觉风格是一个很主观的感受，所以设计师很难说服领导和其他人认可这种感受。如果恰巧你的设计和需求方的审美一致那都好说，但是如果不一致，那就有设计师好受的了。另外视觉设计也很难被衡量评判，也许团队都认为设计的不错，但是有什么客观的证据去证明这个设计真的就是对的吗?所以视觉设计师这个职业上升天然就有一道坎。但是更可悲的是，我发现很多设计师并没有很努力去改进这种状态，因为长期的压抑和抱怨，很多设计师更乐忠于学习技巧工具和新的设计风格，而不是对设计方法和设计流程探索研究。设计成果是否能帮助项目不重要，设计的够不够屌、能不能拿得出手、能否被同行表扬才是最重要的。所以我今天想分享一个很古老也很基础的设计流程，当我们团队在遇到视觉设计难题的时候，我们往往会试着通过这个方法找到灵感和把方案顺畅的推进下去。一、确定情感关键词所谓情感关键词，就是我们产品的视觉所要表达的情感感受，这是从0到1要做视觉设计的第一步。前几个月我们团队支持公司一个新孵化的社交App，为它进行整体的视觉风格设计和定义，但第一步我们不是埋头开始，而是拉上产品的PM们和研发运营各方面leader一起来讨论产品的『情感关键词』是什么，在当时我们所有团队成员之间讨论确认了这三个问题：1)我们的产品要解决的目标是什么?2)我们面对的主要用户群是怎样的?3)我们希望用户在使用我们时，产生怎样的情绪感受?这些问题会扯出很多主观表达，设计师同学一边听大家讨论一边把听到的关键词记在黑板上。比如我们是想做年轻人的视频社交产品，我们就会记下诸如好玩、热情、丰富、可爱、二次元等各种情感关键词，这都是团队成员希望这个产品成为的样子。但是在做视觉设计的时候收集的目标不能太多，于是征求大家建议后，我们把优先级不高的去掉，把重复的感受合并，最后确认了我们产品的情感关键词是：阳光、温暖、年轻。也就是说，接下来我们做App的视觉设计，就应该做出阳光、温暖和年轻的感觉。二、情绪板有了关键词事情还不是那么简单，因为大家会对同一情感会有不同的认知，比如你认为的阳光是蓝天白云，而我认为的阳光是绿树草地，这就会导致后续视觉设计在颜色偏好上会有争议。所以我们必须要靠情绪板，把每个人对情感的抽象理解具象成实际可定义的元素。因为当时我们只有一个设计师，所以号召大家一同参与，布置任务去帮我们在网上找一些符合阳光、温暖和年轻的各种图片来。这样的找寻工作要筛选好几轮，比如早期大家找的图片会有两个问题：1)表达不够准确，不够普遍，比如一位同学找了个秋天落叶的照片会让人觉得不是温暖而是萧条，有争议;2)不够直接，比如有一位同学找了个妈妈烧饭的场景，从而联想到温暖的感受，但是我们觉得这也太隐晦了。情绪板上的图片就是需要让人不经思考，一眼看到就能感受到情感关键词。上图就是最后筛选出来的『情绪板』啦，经过3轮的Review我们从300张图片中找出了不到100个最终确认的图。那这个情绪板对我们到底有什么用呢?1，图片上出现的颜色、元素和感觉，就是我们接下来做视觉设计的时候可以用到的。比如那种阳光和温暖的暖色和高饱色调，小花小鸟光斑元素，都是可以直接被借鉴在界面里的;2，因为团队都一起参与帮忙了，所以可以帮助统一”审美观”(你懂的);3，在做情绪板的过程中设计师本身也在跟着思考和完善自己的感觉;三、脑爆概念设计有了情绪板设计师心中就已经有了很多想法，而且之后的推进成功率也大了很多，但是这个时候也不太适合马上精细的做方案，而是用头脑风暴的方法做概念设计。1，用头脑风暴的方法做设计是指，主要目标不是为了马上确定方案，而是尽可能多的收集创意和想法(如何用正确的方法做头脑风暴)。不然设计师会很快陷入细节而错过很多精彩的设计点子，而在后续推进的时候其他人也一定会质疑和提出各种反对方案，让设计师反复验证和修改，所以我们一开始就要打开脑洞。2，而所谓的概念设计，就是不用那么靠谱和精细，表达大概感觉和意思就可以了，关键在于创意和想法而不是细节。也是因为当时人力不足，所以我号召了部门里其他设计师以参加游戏的形式来帮忙脑爆，大家利用工作之余帮我们做一些效果图，可以尽情发挥自己的脑洞。而且不用很精细，图标网上扒一扒，界面摆的乱一些也没有关系，但是最重要是一定要依据我们的『情感关键词』和『情绪板』来开展。这次同事的热情参与超出了我的想象，虽然所处不同的项目也不是他们的分内工作，但是因为大家平时都深陷各个项目做细节，做个新产品风格还能随心所欲的发挥是很多人都乐意的，于是短短3天内，我们就收集到了50多不同风格的App设计方案。有了方案就需要评审，最初的评审我们就是互相解释设计想法和给点建议，大家互不批判，发现有趣的点子就让对方修改一下，以把他的想法表现的更明确一些。而最终的评审就是有点相亲会的感觉了，我们拉上了所有的设计师，产品的PM和各leader，还有公司内可能潜在的目标用户，对方案进行投票。但是这个投票的规则不是纯凭自己喜好，而是了解背景后，大家投出自己认为最符合『情感关键词』和『情绪板』的设计方案。<大家依据关键词和情绪板的目标选出最符合的方案，再分析和筛选。最后如上图，根据评审我们选出了票数最高的三个不同风格的方案，理论上我们认为这三个方案都是正确的、内部达成一致、且都符合我们在『情感关键词』和『情绪板』分析时『阳光温暖年轻』的设计目标。但是三个是不同风格各有千秋，而且我们都挺喜欢的，要怎么抉择呢?最后就要试探一下用户的感觉了。四、用户验证毕竟之前的工作全部都是建立在设计师理论推断和我们一帮大老头子的感觉上，再怎么装，我们也不是目标用户，所以用户验证是视觉设计最后的关键一步。第一个是定量研究，我们把选出的三个方案放在问卷里，通过猎豹清理大师的渠道发放出去。因为猎豹清理大师在全球有几亿用户，而且广告平台可以选出性别、年龄、国家等不同的用户脸谱，所以我们花了一个周末就回收了一千多份反馈。有一些反馈是很有意思的，比如女生更喜欢方案2那种整体白色的界面，而方案1的红色界面，在巴西这种火辣辣的热情国家就会更受欢迎一些，或者是在比较低龄(15岁以下)更受欢迎一些。最后根据各方面的数据还有我们的目标年龄和国家市场定位，我们选择了方案二作为确定的方向。第二个是定性研究，找不同的用户实际和他们去聊，这件事情看起来很难但是其实不用搞得那么复杂。我们就是让团队成员在微信上发给各种弟弟妹妹亲戚朋友的孩子们看。还有很巧的事情是咱们有个设计师是基督徒，在他们教会上可以接触到很多在北京的外籍年轻人，通过与他们交流也收集了很多反馈。定性研究里我们不但可以获得目标用户的倾向，还可以知道背后的原因是什么。比如当时用户告诉我们为什么不喜欢1，是因为现在的小孩其实都不希望自己被当成小孩，稍微上初中的就不会再用那么可爱的元素来粉饰自己了，会希望自己变得看起来更像20多岁的成熟女性。当然，因为他们本质上还是小孩，虽然故意装但是还是会在细节上透露出一些孩子的心理诉求。经过用户验证后我们的想法就更明确了，加上之前的一步步推演我们确定了方案2就是我们整个App最终的设计风格方向，当然这不是最终效果图，而是确定了后我们的设计师就会根据整个方向去完善细节输出，真实的定稿还需要考量很多因素。总结『确定情感关键词->情绪版->脑爆概念设计->用户验证』以上就是一套我们团队做新产品视觉设计的完整流程，在经过这么一套折腾后有什么实际意义呢?1)首先就是我们非常自信的认为我们的设计方向是正确的;2)因为整个过程领导和产品研发都参与了，设计过程的推演步骤大家非常清楚，所以后期的设计执行也基本上没有了障碍，大家都很信任设计同学的感觉;3)流程里的产出物我们不但只是用在做界面上，后来我们还打印张贴在了产品经理和研发的工区周围，有点”洗脑”的感觉，让他们时刻记住”我们的用户就是这样的”，我们产品就是要做出”这样的感觉”;另外就是大家肯定会有一个很大的疑问就是关于时间成本的问题，这样设计看起来好慢哦，我平常没有那么久的时间，而且看起来要做好多东西，我就一个人怎么办?1)首先我们整体做下来就差不多2周的时间，我觉得2周对于一件这么重要的事情是值得投入的吧，而且一边让大家共同参与，一边还有阶段性产出，团队的人都很支持我们的时间投入;2)设计过程应该短而快，就像我一直强调的，不要陷入细节，不要过于强迫症的专业，以合适的方法从粗犷到精细;3)这次项目除了我外就只投入了一个视觉设计师，做一套界面一个有经验的视觉设计师就够了，但是正确的构思一个风格却不是一个人能做到的。所以我们都是号召群体的力量，发挥大家共同参与和交流，而设计师做到核心的流程的梳理和把控就好了，当好一个导演。最后发表一下我自己的感悟，以前我一直比较迷茫设计这么主观的工作如何优化，貌似除了不断提升自己的感觉和经验也没有什么办法了，面对撕逼也无可奈何。设计管理者的价值似乎也只能是安排下项目，做做指点。但是后来我发现设计其实是有一套方法论的，而且还能是一套理性客观的方法论。比如进行创意的头脑风暴，学习和利用数据，处理产品经理不成熟的需求，分解设计目标，让不同性格的设计师合作等。希望在这个浮躁的行业里与其去争论大道理，我经常整理的方法论干货可以真正帮到大家。
互联网在不断加速与迭代，这种变化与日俱培，每时每刻都在影响着我们的行为，如何每家每户谁还有个微信，这种聚变的力量在无形中变的越来越快。那么对于大批新站长还有很多老站长来说，2020年网站还能如何生存?这个问题恐怕对于新站长更加在意这样的话题，毕竟对于老司机，这似乎已经不成问题。为什么?这中间又有什么区别?还是有什么神奇之处?一.神奇的豹子我们都知道豹子是陆上速度最快的，每小时可跑上百公里，但是有这么高的速度，就有非常之快的心跳心率，如果让豹子跑上几个小时，那么后果会非常严重的，会立马死亡，这很可怕。这就好比一些新站长就像这种神奇的豹子，实际上大部份站长可能就是这么短的时间，很神奇。而老司机们早已洞察千秋，市场在变化，老司机们也在不停的换车，你懂的。二.生存的窑变那么2020年该怎么做?对于网站这种PC和移动同时兼备的平台来说，不管是企业还是个人的，都是想通过网站来制造生存机会，但是事实上，大部份朋友都弄反了，早些年我们可以通过网站来进行生存，甚至发家致富，自从2014-2016这期间，网站爆发年，网站增重速度极快，什么样的网站都有，那些年还容易，但是随着时间的推移，现在网站的竞争度越来越大，门槛越来越高。难度自然越来越大。如何做?1.钻研力什么钻研力?这点其实很明白，那么在哪些方面发力呢?重点突破就是你的产品、服务、内容，万变不离其踪，这些内容尽管已经被说烂了，那是实事上很多企业或个人的，产品研发力、服务质量、内容质量，都并没有做到足够的钻研力，如果能钻研到七成那也不错了，实事上大部份只钻研到了四到五成，而且这些不具什么竞争力。那又如何做到真正的钻研力呢?2.优化力对于网站来说，如果本质上的东西做的足够好，像产品或服务就已经在市场上能够受到用户的青睐的话，那么像网站优化、移动优化、APP优化，这些都是需要企业具有相对应的优化人才的，即使招来一个万能的，那么多人才储备也是可以的，就是要集一个人才，然后进行其它能力延伸，在这方面做的足够好的，再做好时代配备，发挥正确的姿势就完美了。但是这恐怕是一件相当困难的事情，实事上是有的。你觉得呢?3.营销力对网站来说，优化远远不够的，这已经不是第一遍在说起这件事情了，营销力不仅仅是流量的问题，更重要的是如何让流量有效，这件事情一些大佬级的人物恐怕已经研究了一二十年或更久的都有了，为什么不去学习学习呢? 三.反转力量回归上面的话题，简行自媒提到说到弄反了，这恐怕是一些人自己弄反了，也就是说，网站的已经由主要的位置变成辅助地位，这恐怕是未来一些站长不愿意面对的一个事实，事实上事实有可能在发生，或许这只是简行自媒的一个误判，请见凉，但是如果你的网站没有足够的流量的话，要么下足功夫做好流量公关，如果流量也不行，那么战略就有问题了，在上面如何反转它的位置，这件事情，那么你得反思反思是不是你的产品本身就有问题呢?或者你自己有没有在试用你的产品呢?
有盆友问起注册/登录的体验，结合网上各路高人的分享，于是我总结了一些自己对如何在注册和登录时提高用户体验的一些发现或看法，若观点有不对的地方，望大家批评指正，欢迎大家的分享与交流~ 1.别让用户一进网站就注册 有些网站/应用一进来就要注册才能浏览，认为游客会因此而注册成为其用户。不料，我个人遇到一进网站就得注册的都不注册，选择直接离开(对某产品已非常了解除外)，不知道大家是否有相同体验?偶尔注册的网站天天给我发邮件或推送短信，烦透了!至于个人信息是否被他们卖了，这个还要另说(据调查发现国内很多用户会有这个担忧)。 也有许多网页/应用为了能够留住一些游客，会在非注册的情况下允许用户浏览，在需要账户信息时才提醒用户注册或是登录。 下图为Twitter网页端： 而新浪微博网页端改版前并没考虑到这一点。以下为新浪微博网页端登录界面的改版前和改版后，大家可以对比看看~ 改版前 改版后 但这里需要留意，强社交类应用可能无需过多考虑这点，比如facebook的客户端和QQ客户端。因为这类应用属于好友社交类，但微博属于关注和浏览类的。 下图为facebook和QQ的登陆界面： 2.可跳过引导页直接注册/登录 某些时候我们是某个产品的老用户，不再需要给新手用户准备的引导页，因此提供直接登录的快捷方式是有必要的。下图为印象笔记的注册登录界面： Behance登录&注册页，兼顾了新用户、老用户和游客模式~ 3.别让用户重复填写相同内容 想必大家都经历过：注册某网页/应用时被要求填写邮箱地址两次或重复输入密码。其实大可不必。因为用户大多会记得自己常用的邮箱和密码。若邮箱或密码输入有误时可实时反馈，或者用其它更好的方式解决(下面也会提到)，再多此一举填写两次反而容易导致用户流失。 看看一些值得参考的表单设计： 4.突出必填项 作为用户，最好是无可选字段,可填可不填的都不填，甚至最好不要出现。如果一块信息毫无意义，那么只会浪费用户的时间。不过对商家就不同了，搜集必要的信息更能促进业务成功。 如果在注册表单里面有可选字段，那么我们就要强调必填字段。通常一个小标志例如星号*就足够了。它可以让用户自觉发现并填写必须填的字段。 5.输入时自动填充/自动读取常用账号 我们在登录/注册时，经常需要输入账号和密码。这时候，简化或缩短用户输入时间是各网页/应用优化体验的的方式，来看看它们是怎么做的~ 6.手机客户端提供密码切换可见性 我们输入密码时，密码默认加密状态，但由于手机键盘较小，易误操作，切换密码可见是非常方便的功能。 下图为支付宝和京东的登录界面： 7.提供第三方快捷登录 有时候使用某个软件，我们想快捷的登录。采用第三方授权登录的方式非常的高效。 来看看在这方面做得比较到位的产品： 8.科学友好的提示 相必大家都知道注册/登录时提示的重要性，来看看用户体验哪家强，栗子举起来~ 下图是Twitter手机客户端和豆瓣客户端登录页，Twitter点击密码输入框时就有相应的提示，减少了出错的可能;而豆瓣是无提示的，直到提交时才弹出错误提示，而且弹出一两秒就消失了，对像我这种阅读比较慢的人来说真是苦恼(PS：截个图截了一万次才成功)。 9.巧妙的实时反馈 实时的验证会给用户及时的提醒，减少用户在最后提交时报错带来的挫败感。 下图为Twitter在注册时对用户名的要求和手机号码有效性的验证： 10.需求化或情感化的文案引导 很多时候，访问者转换成用户，这个关键任务落在了再普通不过的“注册”按钮的肩上，而这个可怜的按钮在产品开发中却往往得不到任何考虑和关注。 我们经常重复看到许多网站一样的元素时，已习惯性忽略这些元素，无论这些注册按钮的颜色怎么变，最多只是颜色更显眼一些。但访客对网页是浏览，不会细阅。他们很可能轻易错过关于免费试用或是产品能提供的主要价值或好处的部分。当然，这也说明产品错过了访问者转为用户的机会。 一起来看看这方面做得比较优秀的网站是怎么做的~ 他们都有一个共性，那就是抓住用户心理的同时，与产品紧密联系在一起，直接展示出注册后会给予的好处，鼓励访客采取行动。 以上只是国内外的一小部分栗子，一方面与国际接轨，学习优秀的设计，另一方面列举大家熟悉的产品，方便交流~(PS：具体问题具体分析，不能一概而论。以上观点若有误，请大家批评指正~)
Twitch是一个面向视频游戏的实时流媒体视频平台，由JustinKan和EmmettShear联合创立，它是Justin.tv旗下专注于游戏相关内容的独立运营站点。根据其内部分析师透露，Twitch每月的访问量超过3800万，有超过2000万个游戏玩家汇聚到这个平台，每个访问用户在网站的日平均停留时间为1.5小时。网站支持28个国家和地区的语言，包括中文简体和繁体。Twitch的直播模式完全不同于YouTube等点播批处理方式，直播对技术要求更高更难，这也是目前国内电视直播还依赖有线网络的原因，而互联网上的电视直播业务在直播效果上要大打折扣，而Twitch则是在利用互联网技术实现流畅不间断直播上探索了一条成功道路。Twitch直播视频和是YouTube的批处理视频不同是：后者将所有视频存储在磁盘上，稍后根据要求进行重播，而直播视对频视频存储写和视频读播放是同时进行的，因此需要一个完全不同的体系架构。下面是其技术堆栈：Usher-这是其核心系统，用来实现对视频流播放的业务逻辑服务器Twice-可定制的web缓存系统(http://code.google.com/p/twicecache/)XFS-文件系统将视频以秒为单位存储该系统中，HAProxy-软件负载平衡.LVSstack和ldirectord-保证高可用性.RubyonRails-应用服务器Nginx-web服务器PostgreSQL-存储用户和其他元数据MongoDB-用于存储用户操作事件实现内部分析MemcachedDB-用于处理高密集写操作如浏览数量Syslog-ng-日志服务RabitMQ-用于job系统.Puppet-用于构建服务器.Git-源码控制.Wowza-Flash/H.264视频服务器,许多定制的模块使用Java编写S3-smallimagestorage.跟着YouTube等一众厂商的脚步，现在连游戏直播服务Twitch也"开始"弃用Flash改用HTML5了。根据官网的消息，Twitch目前已经完成了第一步骤，先将旧的Flash模块改成了HTML5+Javascript的组合，重新设计了播放控制界面。既然说到这是第一步，这代表了其实Twitch的视频本身还是以Flash为基础的架构，所以接下来才是要渐渐地将播放器完全置换为从里到外都是HTML5基础。新的界面已经可以在Channel页面上看到，并且已经逐步地向使用者开始推送，所以看到界面变得比较不同可别以为走错网站了喔。有一个问题就是：为什么视频直播那么困难？好像只需要大量的带宽，让这一切在内存中，围绕流进行视频组合就可以了，其实没那么简单。是什么让视频直播有如此这样的挑战力？1.视频不能像打嗝一样存在中断,如果视频超过网络容量哪怕几分之一秒，每一个观众在同一时刻将看到屏幕上显示“正在缓冲...“。拥有网络容量是非常重要的。2.需要CDN实现溢流overflowUsher会处理这个逻辑，一旦用户量超过最大容量，新的播放者将被发往CDN服务器。3.当观众快速发现任何问题就会立即交谈聊天。用户期望能够优雅地处理这些问题。他们必须等到一台服务器上的每个人观众完成浏览后才能让这台服务器维护模式。这是一个非常缓慢的维护过程。会话必须从未中断。通常的网站可以有许多错误只是很少人会注意到，而直播系统则不同。下面看看Twitch如何应对这些挑战？他们最大的问题是控制快闪的人群，所谓快闪人群，就是当很多人在同一时间想看同样的事情。这是一个庞大的传入流量。因此，他们需要创建一个方法来在所有的视频服务器和数据中心之间实现实时适应性负载。该机制是Usher。Usher是一个他们开发的软件，用来管理负载平衡授权和播放等其他业务逻辑。Usher对每个流视频都要计算出有多少服务器在发送它们，这样确保最佳负载。它实时决定如何在这些服务器之间复制流，复制依据的规则有：所有服务器的单独负载优化的延迟一个流在哪些服务器上用户的IP地址，这样能够分辨用户来自哪个国家根据路由route数据库寻找离用户IP最近的ISP.根据请求来自的数据中心，试图将这个请求发往同一个数据中心的视频服务器。使用这些优化指标可以引导优化每个发往服务器的请求，以保证更好的延迟和性能优化。他们还有很多的监控调校表盘和非常细粒度的控制。每个服务器可以充当一个边缘服务器（该服务器的视频直接发送到观众）和源服务器（视频从一个广播流进该服务器）。基于一个流可适用一台服务器或网络中的每台服务器上的负载策略，不断进行动态的调整。服务器之间复制流的连接如同树形结构，流的数量不断被取样，如果某个流的新增浏览有快速增加，这个流就会被复制到其他服务器，这个过程不断重复，构建出一个树形(banq注：根据构造定律树形是最有效生命系统特征)，最终可能涵盖了某个网络中所有服务器，这个过程每三秒执行一次。整个视频流从其源服务器到拷贝到其他服务器直至复制到用户都时刻在内存中，其中没有任何磁盘存储。使用RTMP协议（视频流播放协议），每个流都需要一个独立的会话，这会带来昂贵的开销，但是广播多播和P2P技术没有使用，很多下游的ISP不支持多播，只是利用多播在内部服务器进行视频复制，内部带宽相当廉价，但是也没有太多好处，因为无法细粒度控制在服务器间复制。Usher根据HTTP请求，决定哪个服务器来处理请求的视频，而视频服务器一般是被动的，Usher在其之前控制整个服务器的拓扑结构。视频流不是来自磁盘，视频是归档存储在磁盘，源服务器会被挑选出来处理一个上传进来的新的视频流，记录这个流在本地磁盘，每一秒视频被保存和归档，归档存储服务器是使用XFS文件系统。架构能够处理数千个并发流视频传入写。每个视频流缺省保存7天，视频文件可能跨磁盘分区保存。从其他重量协议迁移到HTTP流协议是快乐的，能够使用现有技术进行很好地扩展，但是有一个问题必须积极面对，就是延迟和实时性问题，通常人们认为不超过5-30秒就是实时的了，但是这个不适用成千上万人实时通讯交互，不能有1/4秒的延迟。以上是介绍了视频广播复制系统，他们还有一套Web架构，两个架构图如下：
中国互联网举报中心