解决方案:王通：SEO算法演变与破解

　　解决方案:王通：SEO算法演变与破解

　　我喜欢把复杂的事情简单化，所以我只分享最重要的四点：

　　1. 内容质量控制

　　2.关键词的布局

　　3.链接结构优化

　　4.浏览轨迹优化

　　2-1。内容质量控制

　　内容质量控制始终是搜索引擎算法的首要目标。什么样的内容会吸引搜索引擎？

　　答：自然会吸引用户到搜索引擎！从SEO的角度来看，网站的内容和编辑如何规划？

　　1. 原创 内容的性质：

　　搜索引擎最喜欢原创 内容，但是搜索引擎如何判断原创 内容呢？简单分析，结果自然会有。

　　A. 如果你的 网站 有内容，而其他的 网站 没有，那么它就是你的 原创。

　　B、你的网站有一些内容，其他的网站也有，那么搜索引擎需要分析，可以从收录的时间开始，<中的链接文章 等，只做分析判断。

　　在这方面，谷歌比百度要好，而百度还是有网站权重高的优势。

　　2、内容格式丰富：

　　纯文本的内容肯定不如图文出名，同时非网页格式的文档在搜索结果的排名上也有优势。比如无论你在谷歌还是百度搜索：SEO期刊都是直接排在PDF文档前面的。

　　3、内容转发次数：

　　百度推出了“百度分享”功能，直接统计一个网页的分享次数，在一定程度上可以作为一个网页热度的重要因素。

　　4. 对网站内容评分：

　　我们在谷歌上搜索的时候，经常会发现谷歌已经抓取了用户最想看的所有内容，甚至“星评”都被索引了。

　　对排名非常不利的内容策略：

　　1. 网站中有​​大量重复内容

　　

　　2、网站的内容是纯采集

　　3.内容更新频率波动太大

　　2-2。关键词 的布局

　　一个网页应该在6个地方合理出现关键词，这样关键词在网页中出现的频率就会非常自然合理。这6个地方是：

　　1. 标题

　　2.元

　　3. H1

　　4.乙

　　5. 替代

　　6.链接

　　2-3。链接结构优化

　　搜索引擎蜘蛛对网页的爬取总是依赖于超链接的爬取，所以链接结构优化主要分为两部分：

　　1.建立外部链接

　　2.内链优化

　　2-4。浏览轨迹优化

　　任何关注百度的人都会发现，百度的广告越来越聪明，尤其是百度联盟广告。它不再根据网页内容匹配广告，而是根据用户浏览行为展示吸引用户的广告。这说明了一个重要的问题，百度要记录和分析用户的浏览轨迹。

　　然后，从浏览行为分析的角度，也可以判断网页的热度。

　　例如：

　　1. 跳出率

　　2.浏览时间

　　3. 浏览深度

　　4.点击率

　　

　　5. 其他行为

　　是可以判断的。上一段我做了一个测试，后来证明这方面确实对排名有影响。

　　从2007年到2016年，我讲了10年的SEO，共进行了100场培训。上次培训的价格是每人27800，然后我就停了这门课。

　　最近，很多人还是想学SEO。为了响应同学们的要求，我特地开设了【SEO赚钱培训微信班】

　　1. SEO算法破解：

　　教你快速分析任何搜索引擎算法的思路，快速破解算法。

　　2.高级SEO策略

　　教大家一起使用搜索引擎排名的算法规则，整合创意策略做SEO，从而实现长期排名。

　　3.如何通过SEO赚钱

　　学习方法的目的是为了赚钱，所以同时我会传授三种利用SEO快速赚钱的方法和思路，并提供超值的模板。

　　如果按照之前的规则，新的阶段应该是28,800

　　不过为了让更多人学习，只收5000元/人

　　付款后请联系我的助理：tongwang009 将立即赠送以下珍贵礼物：

　　1.《SEO赚钱秘籍》电子书

　　2.《手机网站SEO教程》电子书

　　3.《网站诊断分析报告》模板

　　4.《网站优化执行计划》模板

　　价值巨大，不用多说。课程结束后，微信社区将提供长期支持！

　　课程时间：国庆期间抽出1~2晚在微信群上课，让讲课记录长期保存，讲课讲课不受时空限制。

　　学习绝活，关注童哥

　　解决方案:美团高性能终端实时日志系统建设实践

　　您是否经常遇到需要在线排查日志，却联系不上用户上报日志的情况？或者你是否经常陷入因为存储空间不足而无法写入日志的尴尬境地？本文介绍美团如何从0到1构建高性能终端实时日志系统，彻底解决日志丢失和全写问题。希望能给大家带来一些帮助和启发。

　　2 设计实现

　　3 稳定性保证

　　4 登陆结果

　　5 未来计划

　　1 背景 1.1 洛根简介

　　Logan是美团面向终端的统一日志服务。已经支持移动App、Web、小程序、IoT等多终端环境。具有日志采集、存储、上传、查询和分析能力，帮助用户定位研发问题，提高排查效率。同时，Logan也是业界较早开源的大型前端日志系统，具有写入性能高、安全性高、日志防丢失等优势。

　　1.2 洛根工作流程

　　为了方便读者更好地理解Logan系统的工作原理，下图是Logan系统的简化工作流程图。主要分为以下几个部分：

　　图1 Logan 系统工作流程 1.3 为什么需要实时日志？

　　如前所述，虽然这种“本地存储+主动上报”的模式解决了大前端场景下的基本日志使用需求，但随着业务复杂度的不断增加，用户对日志的要求也越来越高。当前Logan架构存在的问题越来越突出，主要表现在以下几个方面：

　　在某些场景下，日志上报是有限的：由于用户在网页端和小程序上的一般使用场景是完成后离开，当在线出现问题时，他们会联系用户主动上报日志。整个处理周期长，有可能错过最佳Check时间。

　　缺乏实时分析和报警能力：目前缺乏实时分析和报警能力。用户多次提到要监控在线异常日志，当有符合规则的异常日志时，会收到告警信息。

　　缺乏全链路跟踪能力：目前多终端日志分散在各个系统中。研发人员在定位问题时需要手动关联日志，操作非常不便。美团内部缺乏通用的全链路跟踪解决方案。

　　针对以上痛点，我们提出构建Logan实时日志，旨在提供统一的高性能实时日志服务，满足美团不同业务系统上传日志到云端的需求在这个阶段。

　　1.4 什么是Logan实时日志？

　　Logan实时日志是服务于移动App、Web、小程序、IoT等终端场景的实时日志解决方案。旨在提供高扩展、高性能、高可靠的实时日志服务，包括日志采集、上传、处理、消费、投递、查询和分析能力。

　　图 2 Logan 实时日志产品功能图 2 设计与实现 2.1 总体架构

　　图3 Logan实时日志整体架构图

　　如上图所示，整体架构主要分为五个部分，分别是：

　　2.2 采集 终端

　　通用采集端架构，解决跨平台复用

　　采集终端SDK​​用于终端侧日志采集，需要在多种终端环境下实现。但由于终端和平台众多，技术栈和运行环境的不一致，多终端的开发和维护成本会比较高。因此，我们为核心逻辑复用设计了一套通用的采集端侧架构，具体平台相关代码单独适配。我们目前在微信、MMP、Web、MRN终端上线，逻辑层代码已经完全复用。采集终端架构设计图如下：

　　图4 采集 SDK架构图

　　

　　关键模块介绍：

　　磁盘缓存+报表恢复，防止日志丢失

　　为了方便读者更好地理解终端上的log采集流程，下面将具体介绍采集终端的流程设计。采集端初始化API开始调用时，首先创建Logger、Encryptor、Storage等实例对象，并异步拉取环境配置文件。初始化完成后，首先查看是否有放置成功，但是报告失败的日志，如果有则立即开始上传过程。正常调用日志写入接口时，会将原创日志加密并添加到当前上报组中。当某个上报事件（时间、号码、导航等）被触发时，当前上报组中的所有日志都会被添加到上报队列中并开始上传。

　　图 5 采集 SDK 流程图 2.3 数据访问层

　　对于实时日志系统，接入层需要满足以下要求： （1）支持公网域名上报；(2) 支持高并发处理；(3) 实时性高，延迟分钟级；(4) 支持向Kafka消息队列发布数据。

　　经过对比，美团统一日志采集通道满足上述要求，因此我们选择统一日志采集通道作为接入层。采集 客户端SDK通过独立的公有域名上报日志后，采集通道将日志数据聚合后下发到指定的Kafka消息队列中。如果读者公司没有类似的日志采集渠道，可以参考以下流程搭建实时日志系统的接入层。

　　图6 接入层流程图 2.4 数据处理层

　　在数据处理框架的技术选型上，我们考虑了三种方案，即传统架构（Java应用）、Storm架构、Flink架构。这三种方案不同维度的对比数据如下：

　　表1 技术选型对照表

　　综合来看，传统架构虽然成熟度和灵活性都不错，但在扩展性、容错性和性能方面都不能满足系统需求，而Flink架构和Storm架构则具有出色的扩展性和容错性。但是 Flink 架构在延迟和吞吐量方面表现更好，所以我们最终选择使用 Flink 架构作为数据处理框架。

　　Flink：业界领先的流计算引擎，具有高吞吐、低延迟、高可靠、计算准确等优势，对事件窗口支持良好。它是业内许多公司首选的流计算引擎。

　　在日志处理流程的设计中，日志数据经过接入层处理后下发到汇总主题，再通过Flink作业的逻辑处理分发到下游。处理流程如下图所示：

　　图7 日志处理层流程图

　　聚合日志数据的处理和分发取决于实时计算平台的实时运算能力。底层使用Flink数据处理引擎，主要负责解析日志数据，解密日志内容，拆分到下游。

　　元数据解析：通过实时作业能力，将原创日志数据解析为 JSON 对象数据。

　　内容解密：对加密内容进行解密，这里使用非对称协商计算出一个对称加密密钥，然后解密。

　　服务维度拆分：通过topic字段将日志分发到属于各个业务系统的topic，从而实现业务日志相互隔离。

　　数据自定义处理：根据用户自定义的处理语法模板，实时消费和处理从服务主题到自定义主题的数据。

　　2.5 数据消费层

　　对于大多数用户来说，Logan实时日志所提供的日志采集、处理、检索能力可以满足大部分的需求。但是在和用户沟通的过程中，我们发现还是有一些更高阶的需求，比如指标监控、前后端链路系列、离线数据计算等等，所以我们统一交付Logan的标准化日志到Kafka流处理平台，并提供一些通用的数据转换能力，方便用户按需访问不同的第三方系统。数据消费层设计如下图所示：

　　图8 数据消费层设计图

　　数据消费层的一些典型应用场景：

　　网络全链路跟踪：在这个阶段，前端和后端的日志可能分布在不同的系统中。前端日志系统主要记录代码级日志、端到端日志等，后端日志系统记录链接关系和服务时间。和其他信息。通过Logan实时日志开放的数据消费能力，用户可以根据自己的需要将多终端日志串联起来，实现全网链路追踪。

　　指标聚合统计&告警：实时日志也是一种实时数据流，可以作为指标数据上报的载体。如果日志数据接入数据统计平台，可以实现指标监控和告警。

　　

　　离线数据分析：如果在某些需求场景下需要长期的数据存储或离线分析，可以将数据导入Hive进行实施。

　　2.6 日志平台

　　日志平台的核心功能是为用户提供日志检索支持。日志平台提供用户ID、自定义标签、关键字等多种检索过滤方式。在日志底层存储架构的选择方面，Elasticsearch目前在业界被广泛使用。考虑到计费和运维成本的关系，美团已经有了可以使用的统一框架，所以我们也选择了Elasticsearch架构。同时，我们也支持通过单独的接口层适配其他存储引擎。日志查询流程如下：

　　图9 日志查询流程设计图

　　Elasticsearch：它是一个分布式开源搜索和分析引擎。它具有访问成本低、可扩展性高、性能接近实时等优点。比较适合数据量大的全文检索服务，比如日志查询。

　　3 稳定性保证 3.1 核心监控

　　为了衡量端点实时日志系统的可用性，我们开发了以下核心 SLA 指标：

　　表 2 核心 SLA 指标表

　　除了核心指标的监控，我们还搭建了全程监控仪表盘，涵盖了部分上报成功率、域名可用性、域名QPS、作业吞吐量、平均聚合记录数等重要观察指标. QPS、作业吞吐量等配置底线报警。当线路出现异常时，可以第一时间发现并处理。

　　3.2 蓝绿发布

　　实时日志取决于实时作业的处理和计算能力。但目前实时作业的发布和部署还不能无缝衔接，中间可能存在真空。重新启动作业时，需要先停止原来的作业，然后再启动新的作业。如果出现代码故障或系统资源不足，都会导致作业无法启动，从而直接面临消息积压严重、数据延迟增加的问题，这对于实时日志系统来说是难以承受的。

　　Blue Green Deployment 是一种平滑过渡的发布模型。在蓝绿发布模式下，应用首先被分成两个相等的蓝绿组。蓝色组发布新的产品代码并引入一点在线流量，绿色组继续运行旧的产品代码。新产品代码上线运行，观察没有问题后，开始逐步引入更多的线上流量，直到所有流量都访问新的蓝组产品。因此，蓝绿发布可以保证整个系统的稳定性，并且可以在产品发布的早期发现并解决问题，确保其影响可控。

　　目前，美团针对实时作业有不同的蓝绿部署方案。由于Logan连接业务系统的实时日志多，数据量大，综合考虑，我们决定实现一套适合当前系统的蓝绿。部署场景。为了保证系统的稳定性，在作业运行过程中，启动另一个相同的作业，当新作业运行没有问题时，完成新旧作业的切换。蓝绿发布流程图如下：

　　图10 蓝绿发布流程图

　　使用蓝绿部署后，彻底解决了资源不足或参数错误导致上线失败的问题，平均部署切换时间保持在1分钟以内，基本避免了发布带来的日志消耗延迟。

　　4 登陆结果

　　Logan的实时日志在建设初期就受到了各业务的广泛关注。截至2022年第三季度，洛根实时日志接入并上线的业务系统已达20多个，包括美团小程序、精选商户、餐饮SaaS等大型业务。以下是业务系统接入的一些典型使用场景，供大家参考：

　　核心链路恢复：道家C端小程序使用Logan实时日志程序，在程序核心链路中记录关键日志和异常日志。当网上有客户投诉时，可以查看实时日志，第一时间定位问题。项目启动后，客户投诉平均定位时间由之前的10分钟缩短至3分钟以内，排查效率显着提升。

　　内测阶段故障排查：某企业平台前端项目因2.0改版而发生较大变化，因此在内测阶段使用Logan实时日志增加更多调试日志，方便定位线上问题。项目上线后，每次故障排除不仅节省了用户上报日志的10-15分钟时间，还杜绝了因存储空间不足而无法获取用户日志的情况。

　　日志数据分析：美团到门店的团队使用Logan实时日志分析前后端交互过程中的请求头、请求参数、响应体等数据是否符合标准化规范。经过一个多月的试运行，一期版本共覆盖300+前端页面和500+前端接口，共发现1000+规范问题。

　　5 未来计划

　　经过半年的建设和推广，Logan实时日志已经完成了系统基础能力的搭建，可以满足用户对实时日志的基本需求。但不支持日志数据的深度处理和清洗、日志统计、告警等高级需求。因此，为了更好地发挥日志的价值，提高终端故障排查效率，Logan实时日志有以下方案：

　　6 本文作者

　　洪坤、徐波、陈诚、绍兴等均来自美团-基础技术部-前端技术中心。

　　参考阅读：

　　本文由高可用架构转载。技术原创和架构实践文章，请通过公众号菜单“联系我们”投稿。