一般来说，在一个集群中运行现代化分布式应用的两个关键组件是：可靠的状态管理和灵活的调度。AmazonECS简化了构建和运行容器化应用的流程，但是如何实现才是AmazonECS真正有意思的地方。今天，我想要探讨AmazonECS架构并阐述这个架构能够做些什么。如下是AmazonECS的基本组件图：我们如何协调（Coordination）集群让我们来谈谈AmazonECS到底做了什么。AmazonECS的核心是集群管理器，它是一个后台服务，能够处理集群协调和状态管理的任务。在集群管理器之上是不同的调度器。集群管理和容器调度是互相解耦的，所以Amazon支持客户使用和创建他们自己的调度器。集群其实就是应用可以使用的计算资源池。而这里的资源池就是根据容器划分的AmazonEC2实例的CPU、内存和网络资源。AmazonECS通过运行在集群中每个EC2实例上的容器代理来协调集群。代理允许AmazonECS与集群中的EC2实例进行通信，并根据用户或调度器的请求来启动、终止和监控容器。代理使用Go语言编写，资源占用少，目前在GitHub上基于Apache协议开源。欢迎大家贡献和反馈。我们如何管理状态为了协调集群，我们的集群上需要有一个SSOT[单一数据源]：集群中的EC2实例，运行在EC2实例上的任务，组成任务的容器，可用/占用资源(例如，网络端口、内存、CPU等)。在获得精确的集群状态信息之前，我们是不可能成功开启和终止容器的。为了解决这个问题，需要在某个地方存储状态，因此现代集群管理器的心脏是键值数据库。这个键值数据库对任何集群输入的和存储于此的信息表现为SSOT。为了保证可靠性和可扩展性，这个键值数据库需要采用分布式来确保持久性和可用性，并规避网络划分和硬件故障带来的影响。也正因为键值数据库是分布式的，确保数据一致性以及正确的进行并发修改会变得更加困难，这种情况在状态持续变化的环境（比如，容器的停止和启动）中尤甚。对此，为了保证多状态修改不会出现冲突，某些形式的并发控制就需要落实到位了。打个比方，假设有2个开发者从某个EC2实例请求剩余的内存以供他们的容器使用，这个时候，只有其中一个容器能够真正得到这些资源，而另一个则会被告知请求未完成。为了实现并发控制，我们采用了Amazon分布式系统的核心原语之一来实现AmazonECS，这是一个基于Paxos的事务日志的数据存储系统，它保存了每一项数据变更的记录。在日志中，任何数据的写入均以事务的形式提交，并对应一个特定顺序的ID。数据当前的值就是日志中记录的那些事务的总和。对于任何数据的读取，得到的都只是日志当前时间点的一个快照。如果写操作是继上次读取操作完成以来最新提交的事务，则判定写操作成功。这种原语允许AmazonECS以乐观锁的形式存储集群的状态信息，对于共享数据经常变动的场景（比如当需要表达诸如ECS之类的计算资源共享池的状态时）而言，这是一种理想的方式。这个架构使得AmazonECS具有高可用性、低延迟和高吞吐量的特点，因为数据存储并未使用悲观锁（译者注：作者自己表述得很含糊，大家参见多版本并发控制MVCC）。通过API访问既然我们有了一个键值数据库，那么我们便能够成功协调集群，并确保所需数量的容器正在运行，因为我们有一种可靠的方法来存取集群的状态。之前提到过，我们解耦了集群管理和容器调度两个模块，因为我们希望客户能够充分利用AmazonECS状态管理的能力。我们已经通过一系列API开放了AmazonECS集群管理器，它允许客户以结构化的方式访问存储在键值数据库中的集群状态信息。通过list命令，客户可以读取托管的集群，特定集群中运行的EC2实例，运行中的任务以及组成任务的容器配置（如任务定义）。通过describe命令，客户可以获取EC2实例的具体信息以及每个实例上的可用资源。最近，客户亦可以启动和停止任何集群中的任务了。近期，我们针对AmazonECS进行了一系列的负载测试，我们希望分享一些性能要点，客户在AmazonECS上创建应用的时候应该会关注它们的。上图显示了一个负载测试的结果，在这次测试中，我们在AmazonECS集群中添加和删除实例，并测量72小时的周期内，调用‘DescribeTask’API时，百分比排列位于第50位和第99位的延迟。你可以看到，尽管集群数量有较大的波动，但是延迟相对而言并没有什么抖动。AmazonECS可以如你所需地进行扩展，不管你的集群规模有多大，且根本无需操作或扩展集群管理器。这组API是客户在AmazonECS上搭建解决方案的基础。调度器只是提供了关于何时、何地以及如何开启和停止容器的逻辑。AmazonECS的架构为分享集群状态而设计，它允许客户根据需要为应用运行各种调度器（如二进制打包、发布等）。这个架构允许调度器查询集群的具体状态，并从通用池中分配资源。乐观并发控制允许调度器无冲突地获取它们所请求的资源。一些客户已经在AmazonECS上创建了各种有趣的解决方案，下面我们来分享一些具体的示例。Hailo——弹性资源池上的定制调度Hailo是一个免费的移动APP，它允许人们招呼一辆认证的出租车到其所在地。Hailo拥有一个全球网络，囊括了超过60000名司机以及一百万以上的乘客。Hailo于2011年成立，从第一天开始就使用了AWS。在过去的几年中，Hailo从AWS单一区域上运行的应用集合演化为贯穿多个区域的微服务架构。之前，每个微服务都跑在静态划分的实例集群上。Hailo遇到的问题是跨分区的资源使用率较低。这个架构并不具备很强的扩展性，并且Hailo也不希望它的工程师关心基础设施的细节或者微服务的部署问题。为此，Hailo决定基于服务优先级以及其它的运行时指标对容器进行调度。后来他们选择了AmazonECS来作为集群管理器，因为ECS可以轻松的管理任务状态并访问集群状态的API。同样，Hailo可以根据自己的需求来定制调度器。Remind——平台即服务Remind是一个web端和移动端应用，使得老师能够给学生发送信息并和家长取得联系。Remind平台上拥有24M用户和超过1.5M的老师。它每月传递150M条信息。Remind起初使用Heroku来运行整个应用设施，从消息推送引擎、前后端API、Web客户端到聊天后台。这些设施中的大部分都以庞大的应用块进行部署。随着用户的增长，Remind希望拥有横向扩展的能力。因此大约在2014年年底，它的工程师团队开始摸索着向基于容器的微服务架构迁移。团队希望基于AWS搭建一个PaaS，确保它能够兼容Heroku的API。一开始，团队期望能有一个开源的解决方案（比如，CoreOS和Kubernetes）来负责集群的管理以及容器的协作，但是由于团队的规模较小，因此他们没有时间来管理集群的基础设施，同时保证高可用性。在简要评估了AmazonECS之后，团队决定在此服务的基础上搭建PaaS。AmazonECS是全托管式的，这使得工程资源能够被集中于开发和部署应用；这里并没有集群需要管理和扩展。在6月份，Remind开源了他们基于ECS的PaaS解决方案，名为“Empire”。凭借Empire，Remind得到了可观的性能提升（例如，延迟和稳定性）以及安全优势。他们接下来几个月的计划是将90%以上的核心设施迁移到Empire。AmazonECS——一个全托管的平台上述只是我们从客户处看到的其中两个用例。AmazonECS架构允许我们提供一个具有高可扩展、高可用、低延迟的容器管理服务。通过API乐观并发（译者注：乐观锁）地访问共享集群状态的能力，使得用户得以按需创建任何定制容器解决方案。我们一直致力于为客户消除重复而繁重的任务。通过AmazoneECS，根本不需要安装或操作集群管理程序，客户理应仅仅专注于开发优秀的应用。Amazon与Google间的容器竞争持续发酵Google容器引擎（GKE）由pod、replicationcontroller和节点组成。pod是一组特定的应用程序逻辑主机模型的容器逻辑分组；replicationcontroller确保特定数量的pod副本任何时候都在运行；节点是加强了容器环境的Google计算引擎虚拟机。GKE基于Google的Kubernetes容器编排平台。Kubernetes1.1版本在1.0版首次亮相之后4个月的11月24号发布，是市场中第一个能够通过水平节点自动伸缩功能来实现自动伸缩节点的产品，这个功能受到用户的高度追捧，从而为许多使用GKE的案例提供了有力的支持。“我们为很多各种类型的项目使用自动伸缩”，DescartesLabs公司的联合创始人和首席云架构师TimKelton如是说。这家公司位于新墨西哥洲，是机器学习方面的初创公司，能够处理PB级别的卫星数据。自动伸缩的pod在处理大型批处理作业时能够派上大用场，Kelton解释道。有时，他的公司处理PB级的数据，这就需要扩展到3000个内核。在Kubernetes的第一个版本（随后很快被GKE合并）中，“这不是核心特性集的一部分”，他说。虽然GKE不支持垂直容器扩展或者节点自动伸缩，但是，根据GKE高级产品经理，同时也主导Kubernetes产品管理的DavidAronchick透露，这些功能很快就是实现。AmazonEC2容器服务（ECS）由服务、任务和实例组成。服务是构成应用程序的任务组，而实例是支持容器的弹性计算云端虚拟机，与GKE中的节点很像。Google的ECS的自动伸缩能力与GKE是相反的：使用亚马逊CloudWatch和亚马逊网络服务Lamda可以实现服务自动伸缩，实例也可以基于CloudWatchmetrics进行自动伸缩，但是任务——等同于pod，属于粗糙逻辑，无法自动伸缩。虽然所有类型的自动缩放都很重要，但是亚马逊用户希望将任务自动伸缩加入ECS中。“运行一个新的实例意味着你要有额外的容量来运行额外的任务，但这并不意味着任何新的任务都将被启动”，ACI信息科技集团副总裁ChrisMoyer如是说。ACI，位于纽约，是一家基于Web的内容聚合技术的公司，也是TechTarget的贡献者。“如果你只是自动伸缩实例，并不能真正帮助你解决额外的负载——你必须真正运行额外的任务来实现扩展。”跨区域冗余在ECS发展过程中，亚马逊优先发展在同一个集群中，针对基于用户需求的任务自动伸缩冗余性，本地跨越可用区域（AZs）的能力，当ECS服务调度启动新的任务时，它也会尝试通过集群中的AZs自动平衡这些任务。“这很重要，因为单个AZ允许失败，所以如果两个任务都允许在同一个AZ中，很容易拖垮你的服务”，Moyer说。据Aronchick介绍，Google可以在GKE中通过命令行接口（CLI）跨多个区域。"实现跨区域非常容易，两三条命令就能搞定"，Aronchick如是说。然而，这就要谈到GKE用户最大的心愿：将跨区域功能改进到Web界面上，包括跨域集群扩展功能。“实现用户界面需要大量工作”，Vendasta科技首席架构师DaleHopkins说，Vendasta为媒体公司设计销售和营销软件。用户界面目前支持集群创建以及其他少数功能。Hopkins说：“扩展集群是不直观的。”互操作性ECS作为一个可扩展平台，旨在融入客户现有的工作流，主要处理代表用户的集群状态。将ECS集成到现有工作流中来兼容客户在用的工具，比如用以高级调度的ApacheMesos。亚马逊还自豪的声称拥有广泛的容器伙伴网络来为亚马逊ECS贡献新特性，比如监视、持续集成和安全。同时，Google已经与一批云端容器合作伙伴合作，这些合作商允许Kubernetes可以通过多个云端供应商被部署——这也是CLI现在的一个功能，Aronchick如是说。去年夏天Kubernetes1.0版本发布时，Google引导了CloudNative计算基金会的成立，基金会成员包括云服务公司，比如IBM和RedHat，以及终端用户如eBay和Twitter。“[附]Kubernetes，其实我可以在亚马逊部署，在Azure上部署，在IBM上部署，也可以部署在我自己的物理硬件上，”Descartes的Kelton说。“这是非常有吸引力的，因为我们有选择。”Google也有一个开源项目，拥有数百提交者和每月数以千计的代码提交，使得Kubernetes可以快速的添加新功能，比如水平pod自动扩展。Google是Kubernetes的创始者，而且Google做了很多杰出的工作壮大了社区，451Research的研究员JayLyman如是说。富者愈富尽管如此，使用老牌和熟悉的次级亚马逊服务来实现集成使得亚马逊ECS特别吸引新的客户。一家总部位于纽约的公司，与一些大的企业就IT项目上进行咨询，计划在两个新项目上使用ECS，据其创始人JohnD'Esposito介绍。驱使我们使用ECS的主要优点是使用现有的、成熟的基础设施服务比如弹性负载平衡、虚拟私有云、身份和访问管理，以及弹性块存储可以实现无缝集成。GKE和ComputeEngine的定价还是对客户非常有吸引力的。除了在以10分钟为单位收费的VM资源的底层，GKE包括免费的Kubernetes主节点——这是特别吸引Vendasta的Hopkins的地方。“直到我可以获得大量机器，我才会给Kubernetes支付额外的费用。对于第一套机器，GKE为我免费提供Kubernetes节点”，Hopkins说。在Kubernetes和容器引擎被引入之前，Hopkins和Kelton都已经在用Google云服务，包括GoogleApp引擎。这样，数据重力就会在他们所选择部署的云端容器上起作用。“我们的大多数数据集是PB级规模的，所以你不能只是移动或复制它们，你必须真正去计算数据”，Kelton说。大多数数据目前存放在Google云平台，虽然Descartes不与AWS的合作伙伴合作。微软AzureContainer服务整装待发虽然Google和亚马逊在云端容器竞争中到目前为止仍处于前沿，但亚马逊最大的竞争对手仍然是微软的Azure，它在有限预览阶段拥有自己基于Linux的云端容器的服务，以及WindowsServer的新版本，今年之后，将支持基于Windows的容器。“我们的大多数客户都是......无论是在Azure或亚马逊，”位于Rochester的HKM咨询公司的合伙创始人ChrisRiley如是说，“微软已经拿到了一些他们正在开发的有趣工具。如果我们看到一个次要的，它很可能Google之前的Azure“。简单性和易用性是很多微软的产品的设计重点，Lumagate的CTOKristianNese介绍，Lumagate是挪威的一家微软Azure系统集成商。“我们现在部署Azure的容器服务，仅仅需要100行代码，”Nese说。“一旦你部署了Azure的容器服务，你实际上部署了23个资源......如果你想手动做到这一点，可能需要数千行代码。”Azure容器服务在预览阶段也支持自动扩展，是一个独立服务形式，被称作VM量表集。Azure还将提供成熟和熟悉的工具来管理容器，如Azure的资源管理器，Nese补充说。
网站的用户体会有哪些呢?在网站建造中又怎样进步用户体会呢?用户体会是一个十分广泛的界说。总的归纳有七个方面。详细的咱们一起来剖析一下。榜首、网站的功能方面。这一个方面主要是从网站的加载速度视点剖析得出的。网站挑选的服务器是不是安稳，在域名解析的时分是不是正常。曾经有做过有关的查询，通常界说为三秒以内为优加载速度，超越三秒，每进步0.1秒，那么网站就会丢失1%的用户。所以说，网站的加载速度不只影响了用户的体会，对网站的SEO优化也有一定程度的影响。第二、网站的视觉效果的规划。网站在颜色的调配上有没有根据网站的定位，网站的个性规划有没有联系网站方针用户的需要，这也是用户是不是情愿留在网站继续拜访的一个关键因素。假如网站的建造人员在颜色的调配上没有极好的见解，那么能够从网上找一些有关的常识进行学习。第三、网站导航的分类规划。网站的用户中，有许多都是没有目的的，在拜访网站的时分，通常都会根据导航的分类进入自个感兴趣的节目阅览。网站的导航在分类规划是不是合理化，分类的标题与对应的内容页是不是对应的，这些对于导航的规划都对网站用户的体会有影响，也会影响用户在网站拜访的时分是不是获取想要的信息。第四、网站的查找功能规划。这个主要是为哪些有清晰目的的用户规划的，例如想要买一件冬装，那么在进入网站后，用户榜首时间即是经过站内查找，查找冬装。而站内查找的规划是不是简单使用，直接影响用户的体会，从而影响网站的营销效果。第五、网站内容对用户体会的影响。网站建造公司都遵从一个道理，即是网站运营中，内容为王。不管是什么类型的网站，内容的中心都是看网站的内容是不是做到了及时的更新，写作的视点是不是正确理性。电商类型的网站的内容更新主要是新品的上架和促销活动的及时上线。网站内容更新及时了，用户每天拜访网站都会有新鲜的内容能够阅览，天然对网站的好感直线上升。第六、网站的交互规划对用户体会的进步。这个方面有三个方面构成：界面的规划、导航的规划、信息内容的规划。界面的规划不只包含了视觉规划，还有功能规划上的完善。而信息内容的规划即是用户在拜访网站的时分能够传递什么样的信息给用户。而用户在接收到这些信息时会知道自个正在进行的使命是什么，或者是下一步将会是什么样的使命。第七、网站的登录方法规划。近来几年在登录方法的规划上，开始趋向多样性，例如，是不是支持微博、QQ、微信等登录方法，这些规划都方便了用户的登录，进步体会。在网站用户体会进步的规划方面，咱们不只仅能够从以上方面做出优化进步，从用户阅览阅览习气中咱们会发现，咱们有许多当地调整后都能进步用户的拜访体会。
很多朋友都会说，建设网站的目的就是为了让网站带来流量，就是让用户访问，就是让企业盈利。这些一点都不错，但是对于搜索引擎优化越来越难做，用户体验要求越来越高，成本控制越来越低，网站投入扎堆的大环境下，我们如何让网站脱颖而出?在这里，笔者认为：做好用户体验，流量自然会到来。网站的用户体验有哪些呢?在网站建设中又怎样提升用户体验呢?用户体验是一个非常广泛的定义。总的概括有七个方面。具体的我们一起来分析一下。第一、网站的性能方面。这一个方面主要是从网站的加载速度角度分析得出的。网站选择的服务器是否稳定，在域名解析的时候是不是正常。曾经有做过相关的调查，一般定义为三秒以内为优加载速度，超过三秒，每提升0.1秒，那么网站就会流失1%的用户。所以说，网站的加载速度不仅影响了用户的体验，对网站的SEO优化也有一定程度的影响。第二、网站的视觉效果的设计。网站在色彩的搭配上有没有根据网站的定位，网站的风格设计有没有结合网站目标用户的需求，这也是用户是否愿意留在网站继续访问的一个关键因素。如果网站的建设人员在色彩的搭配上没有很好的见解，那么可以从网上找一些相关的知识进行学习。第三、网站导航的分类设计。网站的用户中，有很多都是没有目的的，在访问网站的时候，一般都会根据导航的分类进入自己感兴趣的栏目浏览。网站的导航在分类设计是否合理化，分类的标题与对应的内容页是不是对应的，这些关于导航的设计都对网站用户的体验有影响，也会影响用户在网站访问的时候是否获取想要的信息。第四、网站的搜索功能设计。这个主要是为哪些有明确目的的用户设计的，例如想要买一件冬装，那么在进入网站后，用户第一时间就是通过站内搜索，查找冬装。而站内搜索的设计是否容易使用，直接影响用户的体验，从而影响网站的营销效果。 第五、网站内容对用户体验的影响。网站建设公司都遵循一个道理，就是网站运营中，内容为王。不管是什么类型的网站，内容的核心都是看网站的内容是否做到了及时的更新，写作的角度是否正确理性。电商类型的网站的内容更新主要是新品的上架和促销活动的及时上线。网站内容更新及时了，用户每天访问网站都会有新鲜的内容可以浏览，自然对网站的好感直线上升。第六、网站的交互设计对用户体验的提升。这个方面有三个方面组成：界面的设计、导航的设计、信息内容的设计。界面的设计不仅包含了视觉设计，还有功能设计上的完善。而信息内容的设计就是用户在访问网站的时候可以传递什么样的信息给用户。而用户在接收到这些信息时会知道自己正在进行的任务是什么，或者是下一步将会是什么样的任务。第七、网站的登录方式设计。最近几年在登录方式的设计上，开始趋向多样性，例如，是否支持微博、QQ、微信等登录方式，这些设计都方便了用户的登录，提升体验。在网站用户体验提升的设计方面，我们不仅仅可以从以上方面做出优化提升，从用户浏览阅读习惯中我们会发现，我们有很多地方调整后都能提高用户的访问体验。
在大数据已经普及的现在，搜索引擎的算法更新是时时刻刻的，而唯一不变的是用户体验的提升，所以我们无论是在做白帽优化、还是黑帽优化，都要从用户出发。特别是新手对搜索优化误区我总结了一下几个方面： 1、百度快照时间和网站权重没有直接关系网页权重对网站快照更新时间有辅助作用，但网站快照更新时间是根据网站历史更新频率和内容质量来决定的，更新频率越快，蜘蛛抓取就越频繁。另外内容页更新频率是很小的。还有种情况是蜘蛛频率抓取但就是不更新，是因为搜索引擎认为内容质量不值得更新。另百度官方说明无需太在意网页快照。2、搜索指数不等于实际搜索量百度官方明确说明“以网民在百度的搜索量为数据基础，以关键词为统计对象科学分析并计算出各个关键词在百度网页搜索中搜索频次的加权和“，注意是搜索频次，不是单纯搜索量。不过百度指数是实际搜索量很有参考价值的指标。3、Cookie只能记录本网站内的用户信息，并不记录用户在其它网站的操作信息Cookie能记录用户在自己站内的操作信息，但用户跳出网站后的数据是跟踪不到的。很多时候我们登录一些网站后，发现如登录信息和其它的输入数据都在，其实那是各个网站单独保留的用户记录。4、网站设定关键词后排名并不会自己上去包括我自己在内，有很长一段时间以为只要给网站设置了关键词，更新网站优化内外链后这些关键词的排名就会上去。其实现在网站设置的keyword和description搜索引擎在计算相关性时只是可能会参考而已，更逞论影响排名了。网站关键词排名要做上去还是要靠我们特意针对这些词做内链外链等优化的，锚文本越集中关键词排名能力就越好。5、站长工具提供的百度权重价值只限参考站长工具里的数据统计功能确实方便了我们了解网站的综合数据信息，提供的百度权重现在是换友链最重要的指标。但站长工具的百度权重只是词库网等第三方软件通过一些技术得出的结果，并不是百度承认的。百度自己有对网站网页重要价值的类似权值指数的指标。6、Site网站结果数量不等于网站真实收录数，更不等于网站有效收录数很多人把site网站结果数据当作百度对网站真实的收录数，其实site显示的结果只是网站真实收录数量的一部分，网站真正收录数应以百度站长平台的索引数为准。但site数越接近索引数越好，代表质量越高，反之如果索引数比site数量超出很多那就要警惕了，都说这是搜索引擎对网站不友好的表现(内容质量方面)。另，网站收录数不代表有效收录数。有效收录指的是有用户搜索并点击的网页数量，对网站来说，通常没有用户访问的页面都是没作用的。7、搜索引擎蜘蛛没有降权蜘蛛之类的分类以前在网上看过一篇对搜索蜘蛛不同IP段的不同分析，让我一直这样认为(估计和我一样看法的人不在少数吧)，最近在SEO深度解析上看了才知道没这回事。不过价值高的网站会有可能吸引蜘蛛不同的抓取策略。8、搜索引擎对网站URL动静态一样对待以前的看法是动态网站就是错的，但后来才知道一昧的追求静态网址并不正确，网址动态静态无所谓只要不重复就是，另外动态网址也要避免过多的参数。9、对站群过度魔化很多人提起“站群”两字的印象就是作弊(反感对站群毛都不懂只会跟风说作弊的人)。确实，现在绝大多数操作站群的都是作弊(多是灰黑色行业)。但站群并不全是作弊，以前就看过一篇操作站群的方式提供不同地区交通违规查询的站群操作案例，这是能真正解决用户需求的。百度官方都说了要看这类网站对普通用户的价值来做评判。10、现在论坛、博客类留言签名的外链价值只剩引蜘蛛这种情况较多的发生在SEO新手，花大把时间去博客和论坛签名留链接，好处是可以吸引更多蜘蛛访问，坏处是数量多了就是垃圾外链了。所以只在网站刚建立时做下吸引蜘蛛就好，后面还是不做为妙。11、网站备案与否不直接影响网站排名很多人说网站备案与否影响网站排名，还有一篇业内流行度很高的“影响网站搜索引擎排名价值参考因素”表里看到网站备案对排名影响非常高，仅在外链的作用之下，扯淡。百度都说了只会参考而已，网站备案与否影响的是用户对网站的信任度。12、搜索引擎蜘蛛并不会“爬”其实这是一个基础常识。大家习惯了把spider访问抓取网页的过程用“爬”来形容，造成很多人以为蜘蛛是从一个页面爬行到另一个页面。其实蜘蛛是直接访问网页的，原理是spider从抓取到的页面的网址按权值等信息来抓取网页内容，查看网站日志就可知道spider对网站的访问没有refer。13、只关注网站首页，忽视网站其它页面的作用和重要性大多数情况下优化网站时我们只关注首页，内外链锚文本什么的都集中到首页去了。其实在网站刚开始优化时是集中在首页，但后面如果目录和内页的权值提不上去，光靠首页是不行的，很难提升权重和获得排名，就算排上去了也不会坚挺。14、同IP服务器网站惩罚受影响并不大很多人固执认为同一IP服务器的网站受惩罚对网站的影响很大，所以在购买空间时对这点特别关注。其实搜索引擎对这种情况是能识别出来的。当初传出这个说法更多的是为了怕同被受惩罚网站连累攻击而已。15、为增加注册量，网站内容设置成只有注册才可浏览的弊端现在很多网站因各种原因，把内容设置成只有注册用户才可能查看。但搜索引擎蜘蛛和普通用户是一样的，普通和用户看不了的蜘蛛也看不了，蜘蛛爬行不了的当然就不能抓取并收录了。正确的做法是放出一部分内容来方便让蜘蛛抓取。16、网站跳出率和页面反应速度不直接影响网站排名首先是会影响，但不是很大。网站跳出率是统计工具才能知道的，搜索引擎并不知道，只要用户不在打开网站后马上关闭并且在搜索引擎上搜索同一关键词。页面打开速度慢会影响用户体验是一定的，有很多用户会直接关闭网页，但也不会直接影响排名。这两点谷歌纳入了页面排名因素，百度还没有。17、设置了noffollow标签的链接搜索引擎还会抓取要完全禁止的方法就是设置robots文件。Noffollow标签的作用是站长不推荐这个链接，但搜索引擎对所有链接都会抓取。在权重传递上来说是不传递，但另一个说法是只要有用户点击的链接都是有作用的。18、百度竞价并不能提升网站收录和排名很多人说网站做的竞价能提升网站的排名，其实网站排名竞价与否并不提升网站关键词排名和收录。做竞价对SEO的影响是能提升网站曝光率和品牌知名度，通常来讲也没人会把垃圾没价值的页面拿来做竞价。以上是我总结的几个方面，很多新手甚至一些熟手在做优化的过程中容易误解的一些专业知识，所以作为一个优秀的seoer我们不仅仅要不断的学习，而且一定要去实践，用事实说话，理论上的知识点只是一个应用的工具，关键还是在于知识点的理解加实践!以上就是对新手对搜索引擎优化seo误区解读全部内容的介绍，更多内容请请继续关注站三界导航!
今年从2月份开始，做网站运营的站长朋友都发现，收录变慢了，然后逐渐不收录了。遇到问题后，我们要做的不是在这里怨天尤人，而是第一时间去发现问题，从而找到解决的办法。今天就和大家一起来聊聊近段时间网站不收录，我们应该怎么来解决?一、网站不收录的常见原因 一般来说网站不收录就那么几种情况，在这里先教大家定位自己的网站情况属于哪一类，然后再进一步了解解决办法。1、文章内容有问题，多指采集站。这一类型的网站在市场上占比算是很大了，大型站做采集事半功倍，但是中小型(特别是小型站，新站)目前做采集很难活下来。2、频繁改动网站。最常见的就是站长优化一段时间发现没效果，就去改动TDK，本来合理的修改TDK对排名是有帮助的，但很多站长就是不了解自身网站的病因，胡乱修改，导致网站更差。另外一点就是改动模板，小改影响不大，很多是今天看到这套模板还不错就换过来，明天看到那套模板不错就换过去，这种常发生在模板比较多的开源CMS中(如：WordPress、dedecms、Emlog等)。3、robots.txt文件针对搜索引擎蜘蛛的协议文件robots.txt错误设置一般还是比较少见，但是冬镜有时候在某些企业站点中还是看到过，具体关于robots.txt的写法就不多说，个人建议如果自己不太了解robots.txt协议的写法，可以删除robots.txt文件(Ps：robots.txt文件也容易被不法分子利用)。4、服务器主机不稳定。有一部分网站不收录的原因点就在于网站经常打不开，或者加载响应速度超级慢，这个属于硬件配置(不排除有时候是被Doss)需求，要根据自身网站的情况进行调整。二、网站不收录的解决办法有哪些? 上文我们大概列举了一些不收录的原因，我们只要找到当前网站不收录的原因后，对症下药基本上都能快速的解决网站问题。1、内容源问题该怎么解决?内容质量不过关，导致不收录这是大部分站长常犯的一个错误，就是看见别人采集很快就收录了，误以为自己采集也能有那种效果。这里给的建议就是新站前期写高质量的原创文章，新站要注意质量大于数量，我们只要保证每篇文章都收录了，那就比你每天采集十篇、百篇都有效果。2、网站真的不能改动吗?这里肯定是可以改动的，因为运营网站肯定都会涉及到改版网站，或者用户需求发生了一定改变后，我们要及时的调整网站。一部分网站因为改动不当导致网站不收录，我们要学会改动网站样式模板，但不要改变URL地址，网站改版改版之前，最好在百度站长平台进行提交改版申请，改版后搜索引擎多少都是以新站的态度来对待的，所以我们在那段时间一定要保持每天更新高质量原创文章，重新建立搜索引擎的信任。3、robots.txt文件可以不要吗?这一点我在前文也提到过，如果自己确实不懂不知道怎么写，直接删除robots.txt文件更好，不写robots.txt文件代表搜索引擎蜘蛛不需要遵守什么规则，对于整个网站所有目录都是可以爬取的。在实际运营中我们可能不想后台目录、js、图片等被抓取到，所以Disallow就是robots.txt文件中禁止抓取的意思。在这里只能说正确的robots.txt文件要比不写robots.txt文件效果好，偷偷告诉你robots.txt文件可以把网站sitemap地图写进去额!4、服务器主机不稳定该怎么解决?首先我们要排查不稳定是我们自身网站的原因，还是因为服务商的原因。如果是服务商的原因，通过提交提交工单或者和对方客服沟通进行解决;如果是自身网站原因，例如网站流量过大，带宽一直处于满额状态，那么网站也会出现502或者打不开的情况，解决这个问题除了花钱升级带宽就无解了。
之前笔者也和一些较大的公司APP负责人聊过，做移动站到底有没有价值，该负责人表示，他们也不清楚，但是必须做，因为该网站用户下单率是APP和H5站近年达到一半一半的比例，而且H5站的下单率在逐步攀升，且从技术开发门槛到拉新成本到用户的活跃度以及从平台获取流量的难易度都表明，做H5比APP性价比高多了。移动站有这么火爆笔者还是没有想到的，那做移动站的流量从哪里获取呢？由于入口较少，搜索引擎还是流量获取最大的入口，目前搜索引擎移动占比还是百度较大，所以怎么从百度更好的获取移动流量，是做移动站的关键，而最简单的方法就是按照搜索引擎的规则做移动站。笔者找到百度内部人士了解到，移动生态是近几年百度搜索发展的重点，百度搜索2015年底发布『MobileFriendlyV1.0』百度搜索移动友好度标准，目的是让站点更好的配合百度移动搜索获取移动流量，同时优化最终用户搜索、浏览体验。为了加深站点对标准的理解，百度还推出了『移动红黑榜』，通过案例来更清晰明了的解读站点应该如何做才能做到更好的被百度抓取、收录。活动中以『红榜』的豆丁网和黑榜的『道客巴巴』举例，我们看下具体差在哪：首先，豆丁网加载速度快，道客巴巴加载慢于豆丁，这个不用说了，很多权威测试都说过页面加载速度慢会拉低站点各个指标，包括利润、首次点击时间、用户满意度和其它。如果页面慢了一秒，用户就必须要等两秒才能与页面进行交互，过程中如果被打断就很可能中断了访问，搜索引擎也不会青睐这样的站点。第二条是豆丁的导航清晰明确，而道客巴巴导航仅为图片，没有文字标识，用户完全不明白。这表明，文字导航虽然不能像图片导航那样美观，却能同时让百度蜘蛛和用户快速了解网站结构。说到这点其实很多站长站点没有构架好，很容易出现导航复杂化的问题，导航一层嵌套着一层，搜索引擎蜘蛛需要翻越这一层又一层的导航来找到目标的内容页面。这就是在考验搜索引擎蜘蛛的忍耐力，同时也在跟访客较劲，这样是非常得不偿失的。第三条，豆丁内容页上路径清晰，明确标示如何去往上一级或下一级页面，明确下载文档功能，提供了相关文档推荐功能。道客巴巴是内容也没有累死面包屑导航的功能，没有明确提示如何去往上一级或下一级页面，自己都损失了很多流量。理想的网站结构应该是更合理一些，内容相关的网页间互相有链接网站中每一个网页，都应该是网站结构的一部分，都应该能通过其他网页链接到，这样搜索引擎处理起来，会更简单。最后一条，豆丁内容页面排版精良，字号采用了mobilefriendly推荐的14PX,间距设置合理，阅读舒适。而道客巴巴详情页面将文字内容转换为图片，不符合资源易用性影响用户体验，与百度移动友好度标准严重相背。这个问题是站点不能只图方便，在页面上我们推荐站点使用文字而不是flash、图片、Javascript等来显示内容或链接，搜索引擎暂时无法识别Flash、图片、Javascript中的内容，这部分内容无法搜索到，很可能无法被收录，所以为了获取流量，我们不要怕麻烦，还是按部就班的按照标准来做吧。其实移动友好度标准还有很多内容，想做好移动站还是应该多看看，避免跳坑，有不是很了解的站点也可以多关注下百度移动红黑榜这样的系列活动（三月底还会有新的一期活动出来），从实际角度参考一下做的好的站点是如何架构移动网站的，并且，百度移动搜索将来也会对这些『黑榜』违规站点有所动作，内部人士透露『红榜』类站点，将来会获得更多百度其他产品合作机会，而『黑榜』中道客巴巴这样操作的站点，将会收到百度降低网站评分的处罚，毕竟生态的平衡才是百度的目标。以上就是对移动站从搜索引擎获取更多流量的技巧全部内容的介绍，更多内容请继续关注站三界导航！
调查前面说到了，大多数大型网站在收集网站数据的时候，都会利用问卷调查的形式，来调查用户的需求，这种形式收集用户数据是最直观的，但视乎这种形式并不适合小型网站!首先小网站本身流量就少，其次是问卷调查相对复杂，需要填写的内容比较多，可能很多用户不会耐心，最后小型网站通过这种形式拿到准确数据的少，因为用户少，所以数据比例相对没有那么精准了!其实我认为小型网站的调查，应该是通过“是”和“否”这种形式来调查，如果你网站用户量庞大，那可以使用填空题，用户量少，尽量使用选择题，甚至2个答案的选择题。团队讨论改版网站或者要修改网站，我认为重点在团队讨论的结果上，甚至我网站出现一点小改动，我都会通过QQ群等多种形式去与大家一起讨论，需要改什么，应该改什么，如何改等问题。其实讨论的形式我认为QQ群应该是最好的，QQ群集中站长圈的人，通过发出不一样的建议，也你能突出不一致的观点。让设计师和用户都注意到自己的观点可能与其他人的不同，这是非常有益的。统计数据最原始的数据收集方式，也是最靠谱的数据收集方式，比如我们经常可以看到某大型网站的合作页面会写到月浏览量、男女比例、地域比例等基本数据，这些数据大多数来源于统计。而统计工具目前还在继续完善，目前拥有的不再是这几个数据，甚至有访问深度、热力图、页面上下游等工具，几乎完全可以利用这种数据判断一个网站的核心点!所以现在我们很难得看到网站有调查“你是从哪里知道本站的”，因为统计工具的数据可以完全统计出来。关键词工具数据大多数做SEO的都是通过站长工具查询某关键词当天的排名，但是由于网页登陆的在线工具无法记录某关键词前天的数据，所以表示遗憾，但目前市面上也有类似这种软件的形式记录关键词排名的工具，不只是查询关键词的排名情况，还可以直接监控关键词排名的浮动，这种形式收集来的数据，可以完全利用到SEO优化当中来!用户访谈知道我为什么开通草根访谈的栏目吗，当然主要不是为了收集数据，更重要的是让草根也有自己的舞台发展，其次是我也能够在草根身上学习到很多东西，最后才是收集草根身上的数据，通过用户访谈的形式收集数据相对而言工作量大。记得去年在参加一个互联网企业的活动，过去之后基本是把我所有的隐私给问出来了，在我看来他们不是在搞活动，而是试着做用户调研，这一系列的问，都是产品经理在进行!总结：数据其实是网站的核心部分!以上就是对做网站SEO收集数据的方法介绍全部内容的介绍，更多内容请继续关注站三界导航!
前后端分离的背景“前后端分离”显然已不是什么新鲜的话题，Zakas在2013年10月份就曾发表过一篇博客《Node.jsandthenewwebfront-end》讨论Node背景下新时代的前端。毫无疑问，Node的出现给JavaScript语言带来了新的生机，也使得前端开发者有了更多的可能性。前后端分离表面上看似乎是一场“圈地运动”，但实质上前后端分离是为了解决以往开发模式的一些诟病和痛点，同时也是迎合大的行业趋势的明智之举。我所在的美团酒店事业部去年7月份成立，新的业务、新的开发团队，这一切使得我们的前后端分离推进的很彻底。截至目前，前端承载的所有业务和线上服务都是基于Node，生产环境已经有近20台服务器。如此带来的全新前后端协作方式能够让专业的人做专业的事，无论前端后端都能较之前更专注在自己擅长的方面。开发模式、技术栈传统的开发模式只需要专注在多终端的呈现上（浏览器、WebView）。而现在，浏览器只是前端的其中一环，延伸出来的还有Node端的架构、服务的运维能力等。上图是我们目前的服务架构：Nginx位于Node服务之前，用做负载均衡、服务调度、Gzip压缩等。之后便是Node服务，我们通过PM2.5进行Node服务的Cluster部署和负载均衡（充分利用多核优势），同时作为轻量的中间层，负责路由、Controllers、Views、以及视图的渲染，数据的获取通过RESTful的API接口使用JSON格式交互。而后端则只需要负责业务逻辑、数据存储、Models，并为前端提供JSON数据即可。这样改变之后，Node端可以进行首屏渲染等页面加载方面的优化，页面渲染出来之后后续的交互、渲染都交由浏览器端的JavaScript代码来完成，Node端的模板和浏览器端的模板大部分情况下都是相同的，所以我们需要考虑模板重用的问题。我们用Juicer替换了Express框架默认的模板引擎，Juicer是一个高效、轻量的前端(Javascript)模板引擎，效率和易用是它追求的目标。除此之外，它还可以运行在Node.js环境中。通过Juicer，可以解决Node端和浏览器端的模板、Helper复用问题。而且基于前后端分离的工程架构下，前端的代码仓库和后端隔离，前端独立负责前端静态资源文件、模板文件、Controller的维护和发布。按照这样重新定义前后端分工之后，前端可以做的事情较以往更多了，比如微信SDK的接入，因为微信JSSDK的使用需要在服务端进行签名，所以现在我们不需要后端介入，前端完全可以独立完成微信SDK的接入。此外像我们内部和商家端SSO登录逻辑的接入都完全由前端独立完成。技术选型的思考对于前端的技术选型，我们始终保持理性、拥抱的态度。我们不会为了盲目求新而引入新的技术，技术选型是针对我们目前大团队的场景，为了解决以往协作过程中发现的一些痛点和不足。比如引入Node是为了改进前后端的工作流和效率，提升前后端的开发体验。再比如目前我们项目中采用的Angular、React也是针对特定的业务场景，为了提升开发效率、增强代码的可维护性。在我们的业务应用中，面向商家、后台的一些增删改查系统，Angular能够显著的提升开发效率，而React我们目前只是在面向用户的PC端项目中在做一些尝试和实践。带来的挑战这样的分工和架构模式在给前端带来更多可能性、更多便利的同时，也带来了不小的挑战，相比传统的前端角色而言，我们需要更多的关注线上服务的状态，进程内存占用、CPU占用的详细状况，以及线上异常的监控等。在我们拥抱Node的同时，对前端的能力要求是更上一阶的。一段看起来正常的JS代码，在浏览器端和在Node端两种不同的运行环境下，就可能会暴露出一些以往关注不到的问题，比如内存泄露：一个闭包或者一个用于缓存数据的对象，跟浏览器不同，Node对内存泄露十分敏感，因为线上应用有成千上万甚至百万计的流量，所以哪怕是一个字节的内存泄露也会造成内存堆积，从而导致垃圾回收过程耗时增加，应用响应缓慢，知道进程内存溢出，应用重启或崩溃。内存泄露问题的定位以下是我们在生产环境遭遇的一个案例：最近发现线上服务的内存占用在服务重启后会呈线性的增长，进程启动18小时后，内存就已经占用接近1.6G左右，之后不久便会超过V8的内存限制导致服务重启。从图中可以看出，在修复之前内存使用情况一直在随时间进行周期性的波动，波动的原因就是线上Node进程不断的重启导致的。众所周知，在V8的垃圾回收机制下，一般的代码很少出现内存泄露的情况，但是一旦出现内存泄露往往较难排查。但造成内存泄露的本质原因只有一个，就是应当回收的对象没有正常被回收，变成了老生代中的常驻对象。好在借助一些常见的排查工具可以帮助我们定位内存泄露的具体原因：-v8-profiler-node-heapdump-node-mtrace-dtrace-node-memwatch这里我们使用node-heapdump来在模拟访问的条件下生成堆内存的snapshot，并通过Chrome的开发者调试工具对生成的snapshot文件进行分析。通过对比服务刚启动时以及使用AB模拟并发访问一段时间后的heapdump信息可以比较容易的定位到内存泄露的问题点：是因为Juicer默认开启了cache，会默认对编译后的模板进行缓存，因此随着访问的增长和并发请求，cache对象会持续增长且不被回收，于是关闭cache并重新部署上线后线上恢复正常。由于在浏览器的场景中运行时间短，且运行在用户的机器上，即便内存使用过多或者内存泄露，也只会影响到用户的终端。而且运行时间短，随着进程的退出，内存也会随之释放，几乎没有太多内存管理的必要。但在Node端同样的代码就可能会暴露出问题。线上服务的运维和监控前后端分离除了意味着代码仓库的分离、开发协作的分离之外，还涉及到线上服务的独立发布和单独部署。与之俱来的当然是前端如何更好地对线上服务进行更细粒度的运维和监控，我们的SA会更多的关注线上服务的整体指标和可用性，而前端更希望能够细粒度的了解线上Node的进程状态以及异常情况。PM2是一款优秀且开源的Node进程管理工具。我们在PM2的基础上做了一些改造，同时在云端部署了数据收集、数据实时获取的服务，从而形成了我们目前已经应用到线上的Node部署监控平台PM2.5，它可以将线上Node服务进程级别的细粒度信息聚合在云端进行处理和可视化展现，PM2.5能够监控NodeServer和进程的各项指标状态，且可以配置报警并在各终端（Web、iPhone、AppleWatch）展示。PM2.5的服务架构简单介绍下PM2.5的服务架构：生产环境的Node服务通过PM2.5CLI进行部署，PM2.5CLI会持续不断的将Node进程的各项数据上报到PM2.5的云端。云端收到上报的数据后会对原始数据进行处理并存储至MongoDB。而Web端和iOS应用都会通过WebSocket服务从服务端获得实时的数据流，然后通过前端进行可视化的信息展示。PM2.5的内部实现当Node进程通过PM2.5启动时，PM2.5CLI会同云端服务进行握手，握手成功后才会源源不断的进行数据的上报。上报时首先会将数据进行AES256加密，然后使用TCP通信将数据上报到服务器，这里用到了开源的Axon，云端服务器收到数据后会将数据入库存储到MongoDB中，同时会进行监控报警的扫描，如果当前数据符合用户订阅的监控报警条件，则会通过云端的Push服务向iOS客户端推送报警信息。云端同时运行WebSocket服务，为多个终端（Web平台、iOS应用）提供实时数据的推送。这里值得一提的是，PM2.5的客户端是基于React-Native开发，目前已经提交AppleStore正在审核，审核通过后就可以从AppleStore中下载到了，客户端提供了服务和进程基本指标的查看，同时可以配合Web平台的监控报警设置实现7x24小时对服务的监控。其它监控设施的接入为了确保线上服务的可靠、稳定，我们还接入了其它一些监控设施和日志平台，便于对线上的错误和访问日志进行追踪、分析和定位处理。ZabbixZabbix是一种分布式系统监控以及网络监控功能的企业级开源中间件，主要是被运维使用。Zabbix主要用于对服务进行心跳检测、监控服务的各项指标，当某些指标异常或超过设定的阈值时进行短信、大象、邮件的报警。Sentry错误日志收集Sentry是一个错误日志服务器，可以将程序错误的详细情况集中捕获。而且提供各种常见语言的SDK供业务接入。但Sentry在服务器端会有采样，一般不能替代实时错误日志报警的监控。日志监控平台日志监控平台是美团内部的一个日志收集系统，目前美团统一使用flume收集日志，flume具有接收scribe格式日志的能力，而日志监控平台也是以scibe格式日志来收集。日志在整个收集流程中以两种形式存在，分别是原始日志和解析后的日志。目前我们使用日志监控平台主要用于将访问日志的格式化数据上报，之后就可以通过Hive/Presto对访问数据进行查询了。性能监控平台性能监控平台为美团各平台和产品线提供简单易用的、端到端的性能数据服务。同时也提供了各种常见语言的SDK供业务接入。主要用于分析Node端的接口响应，以及浏览器端的页面载入性能。小结以上是美团酒店前端在应用Node进行全栈开发的过程中摸索前行的一些心得，也是引子，主要介绍了我们酒店事业部的前后端分离架构，线上内存泄露问题的排查，和所使用的Node服务监控平台PM2.5，后续我会分享更多我们的Node方面的一些实践，以及PM2.5监控平台的背后实现，希望能对你有所帮助，也欢迎大家能够参与进来共同交流前后端分离和Node相关的技术点。
网站，可以简历理解为一个超文本的word文档，只要会用word那么其实网页编辑也会很简单的。这里我也笼统的介绍一下建站学习步骤。以后有时间我再分讲。方法/步骤首先，我们必须先去了解下网络制作的基本语言HTML，一两个小时就能学个入门。(大家可以看下百科，介绍的就很详细)学习了解下目前流行的网页制作软件，如dreamweaver、frontpage等常用软件，初步了解下，以后边做边学。广泛的上网流量网页，研究下别人的网页代码，简易先从简单的个人网站研究，然后再去看专业的设计网站。也可以通过百度搜索欣赏别人的模版设计。学下别人的排版、配色、概念等。下面学习下网页设计的好搭档adobephotoshop，网页的美感图片是不可或缺的，最好能自己制图。其次就是动画与特效，目前流行的是FLASH。网上也有些免费的Javascript等可以使用。不过不要放太多。网站内存空间或网速会有所拖累。网站基本建成后，就需要找些免费的主页空间。数度快、空间大、域名简单、CGI功能等可作为参考条件。(可以百度搜到)然后可以通过ftp、dreamweaver等工具上传到免费空间就可以了。以上就是新手如何学习建立网站方法介绍，操作很简单的，大家学会了吗?希望能对大家有所帮助!
基本流程服务器&带宽&存储同步源选择,架构选择提供的服务:ftp|http|rsync3.官网获取同步方法或工具,源列表(选择上游源)配置同步工具定时同步(crontable)备份工作,监控与报警,日常维护,优化文档编写(Wiki),SubmitMirrorsList其他0/8.服务器&带宽&存储服务器:Linux,maybewindows?..orz带宽:越大越好(上行带宽太小无法提供更好的服务,下行太小无法及时同步完整(按网络情况分时段同步,同时尽量避开负载高峰))。如果要对外服务,需要一个公网IP,有域名更好。储存:越大越好(如果是对外提供大量服务,家用的硬盘估计撑不了一年)。可考虑用SSD作为cache。1/8.同步源选择,架构选择同步源选择:按需求选择需要的发行版,稳定性第一,多样性第二,满足需求即可。同时也要注意”性价比“(自用镜像无需考虑),例如OpenBSD之类的性价比可能很低,消耗大量的同步流量和磁盘空间可能性价比不是很大,同时例如大学中的镜像站需要网络中心的支持,所以需要考虑到校内用户的支持和热度(学生支持度不够,nc的支持可能也会下降),同时校内有一定热度才好传承,所以如果添加类似Ubuntu的发行版”性价比“会很高。慎重选择上线的发行版(自身资源估计),上线尽量保持稳定。切勿随意更换服务。注意预留足够空间!感谢中大IGI师兄以上给出的建议。推荐:《搭建linuxmirror镜像》架构选择:一个发行版可能保护多种架构,(例如debian:alpha、amd64、arm、armel、hppa、hurd-i386、i386、ia64、m68k、mipsel、mips、powerpc、s390、shandsparc,source,debian现有oldstable,stable,testing,unstable,还有experimental版本),所以需要按需求选择需要同步的架构(因为磁盘空间不是无限的),一般来说就选择i386,amd64,外加source。2/8.提供的服务:ftp|http|rsyncFTP:vsftpd?还有很多,不太了解,囧。HTTP:Webserver建议选择nginx或lighttpd,因为镜像包含大量的静态文件,这两者据说比Apache更有优势,记得cn99挂掉后,将Apache换到nginx了?建议:nginx，lighttpdRsync:为下游提供,例如清华,中科大有开放某些发行版,国内提供rsync的镜像站不多,主要是提供rsync会有很高的IO负载,一般承受不起。如果有意愿提供rsync,google即可。3/8.官网获取同步方法或工具,源列表(选择上游源)同步方法或工具:一般就是Rsync,然后从上游拉东西,可以自己写脚本,也可以用官方提供的工具,例如debian的ftpsync等。切勿使用wget等工具!不能保证文件link等属性,也无法做到增量同步,浪费资源!清华的同步脚本:http://git.tuna.tsinghua.edu.cn/北交Ideal的Mirror工具:https://github.com/ideal/mirror(感谢ideal曾经提供的帮助,有意愿搭建镜像站的同学遇到问题可在Twitter上找到他)Rubygems,PyPI,npm也是同样找寻或自己编写同步脚本后工具,或做反向代理。除了主动拉的,还有是官方主镜像推送到官方其他镜像,例如ArchlinuxARM。ubuntu还有个同步工具apt-mirror上游源:上发行版官网获取MirrorsList,然后找寻提供rsync服务的镜像,选择上游源,一般选择国内,日本,新加坡,台湾等亚太地区的源。注意:官方rsync可能只对指定IP开放(负载问题)4/8.配置同步工具自己写同步脚本:失败邮件报警,同步锁控制,两步同步,其他rsync参数。Rsync教程:读igi的同步脚本:http://www.igigo.net/archives/65使用同步工具:清华的同步脚本:http://git.tuna.tsinghua.edu.cn/北交Ideal的Mirror工具:https://github.com/ideal/mirror/PyPI,Rubygems,npm:读Rubygems和PyPI同步简单教程:http://fangpeishi.com/post/da-jian-pypiji-rubygemsjing-xiang读npm同步教程:http://maskray.me/blog/2012-11-21-tuna-npm-mirror注意:添加同步锁，debian系需要两步同步(先同步pool目录)。5/8.定时同步(crontable)定时同步:把写好的cron脚本丢进/etc/cron.d/《定时自动任务crontab使用教程》注意:/etc/cron.dthefilenamesmustconformtothefilenamerequirementsofrun-parts:theymustbeentirelymadeupoflet‐ters,digitsandcanonlycontainthespecialsignsunderscores(‘‘)andhyphens(‘-’).Anyfilethatdoesnotconformtotheserequirementswillnotbeexecutedbyrun-parts.Forexample,anyfilecontainingdotswillbeignored.ThisisdonetopreventcronfromrunninganyofthefilesthatareleftbytheDebianpackagemanagementsystemwhenhan‐dlingfilesin/etc/cron.d/asconfigurationfiles(i.e.filesendingin.dpkg-dist,.dpkg-orig,and.dpkg-new).(特殊字符只可以使用’‘和’-’,另外以’.’开头的文件会被忽略)crontab脚本中注意path的配置,例如使用rubygems的同步工具碰到rakeabort等问题。6/8.备份工作,监控与报警,日常维护,优化备份:当配置文件发生变化时候利用脚本将其备份到Dropbox.监控与报警:用awk等工具对同步日记进行分析。配置邮件服务程序,例如exim4,在之前的脚本中添加出现异常时候发邮件。(移动139邮箱有短信通知功能)。部署监控程序,例如MUNIN,对磁盘情况,网络情况,负载情况等进行监控,以图表的形式直观呈现出来。日常维护:当出现同步异常失败时(例如:上游down掉了,和上游的网络异常了,磁盘异常等等),需要更换上游或者其他方法。优化:主要是针对镜像站大量的静态文件进行的优化.以及观察监控对流量和负载进行合理分配。7/8.文档编写(Wiki),SubmitMirrorsList文档编写:一个是为了将经验积累,方便传承,同时也是为了方便其他搭建镜像站的朋友。例如建个wiki。Submityourmirrortomirrorslist:当镜像站足够稳定时,可考虑提交到官方mirrorslist,让更多的朋友知道,有小小的成就感也容易鼓励自身和传承。内网的镜像可在内部交流平台公开分享。若是校园镜像站需要注意宣传,以得到更多师生的支持,同时方便传承。8/8.其他如果是在大学内要搭建一个镜像站,需要获取网络中心的支持,可能需要:一颗“耐”心;注意传承问题(校内热度将影响nc对镜像站的支持程度,做好文档,发展好师弟师妹,如果有个Linux协会啥的平台组织最好不过了);找靠谱老师支持(镜像快死掉了的时候,老师可能能救活它),熟悉nc里的老师或领导(解决问题更方便),记得镜像站要帮助宣传nc,记得感谢提供帮助的同学,老师和组织;稳定为先。
中国互联网举报中心