wu-sheng commented on a change in pull request #112: URL: https://github.com/apache/skywalking-website/pull/112#discussion_r469767368
########## File path: docs/zh/blog/2020-08-11-observability-at-scale-skywalking-it-is.md ########## @@ -0,0 +1,99 @@ +## SkyWalking为超大规模而生 +- 作者：吴晟 +- 翻译：董旭 金蝶医疗 +- 原文链接：[Tetrate.io blog](https://www.tetrate.io/blog/observability-at-scale-skywalking-it-is/) + +SkyWalking是Apache的顶级项目，是一个开源的APM和可观测性分析平台，它解决了21世纪日益庞大、分布式和异构的系统的问题。 +它是为应对当前系统管理所面临的困难而构建的： +就像在一个干草堆中可以找到一根针，SkyWalking可以在服务依赖复杂且多语言环境下，获取服务一一对应的指标，以及完整而有意义的性能视图。 + +SkyWalking是一个非常全面的平台，无论你的微服务是否在mesh架构下，它都可以使用轻量级负载提供一致性的监控。 + +让我们来看看SkyWalking是如何演进解决规模可观测性问题的，并从一个纯粹的链路跟踪系统发展成为一个功能丰富的可观测性平台，用于分析每天百亿级跟踪数据。 + +### 为规模而设计 + +SkyWalking诞生时间要追溯到2015年，当时它的主要使用场景是监控中国顶级电信公司、中国联通和中国移动的第一代分布式核心系统。2013-2014年，电信公司计划用分布式系统取代传统的单体架构应用。从第一天开始，支持超大型分布式系统和可扩展性就是SkyWalking首要的设计目标。所以，规模要考虑什么呢？ + +### 拉取vs推送 + +Pull和push模式与数据流的方向有关。如果Agent（探针）收集数据并将其推送到后端进行进一步分析，我们称之为“推送”模式。 +关于拉还是推的争论已经持续了很长时间。可观测性系统的关键是使agent的成本最小化，并使其能普遍适用于不同类型的可观测性数据。 + +Agent将在数据收集后的短时间内发送出去。这样，我们就不必担心本地缓存过载了。一个典型的例子是端点（HTTP的URI，gRPC的服务）度量指标。任何服务都可以轻松地拥有数百个甚至数千个端点。APM系统必须具有这些度量分析能力。 + +此外，度量指标并不是可观测性领域中唯一的东西；跟踪和日志也很重要。SkyWalking设计用于在生产环境中提供100%的采样率跟踪功能。显然，推送模式是唯一的解决方案。 + +同时，使用了推送模式并不意味着SkyWalking不能进行数据拉取。在最近的8.x版本中，SkyWalking支持从Prometheus-instrumented服务获取数据，以减少终端用户的重复性建设。此外，拉模式流行的做法是基于MQ的传输，Kafka消费者是一个比较典型的例子。SkyWalking的Agent端使用推送模式，OAP服务器使用拉取模式。 + +结论：推模式是本机方式（Agent），但拉式模式也适用于某些特殊情况。 + +### 度量指标分析不仅仅是数学计算 + +度量指标依赖于数学理论和计算。Percentile是识别响应慢的一个很好的指标，合理的平均响应时间和成功率是很好的SLO（s）。 +但这些并不是全部。分布式跟踪不仅为跟踪提供了详细的信息，还提供了可以分析的高价值指标。 + +Ops和SRE团队需要提供服务拓扑图，用于NOC仪表板和系统数据流的确认。SkyWalking依靠trace数据，使用STAM（Streaming Topology Analysis Method）方法进行分析拓扑结构。在服务网格环境下，使用ALS（Envoy Access Log Service）进行分析。进行拓扑分析。这种节点（services）和线路（service relationships）的拓扑和度量数据，无法从简单的度量sdk中提取。 + +为了解决端点度量收集的局限性，SkyWalking还需要从跟踪数据中进行端点依赖性分析。端点依赖性分析提供包括上游和下游在内的更重要和更具体的信息。这些依赖关系和度量有助于开发团队将性能问题的边界定位到特定的代码块。 + +### 预计算与查询阶段计算？ + +查询阶段计算提供了灵活性。在分析阶段，预计算可以提供更好、更稳定的性能。回想一下我们的设计原则：SkyWalking是为了一个大规模的分布式系统而设计。查询阶段计算的范围非常有限，大多数度量计算都需要预先定义和预先计算。支持大数据集的关键是在设计阶段减小数据集。预计算允许将原始数据合并到下游的聚合结果中，用于查询，甚至用于警报检查。 + + +指标的TTL（Time To L）是另一个重要的业务使用因素。由于预先计算，查询提供了近似线性的性能，使用类似的查询基础设施，组织可以提供更高的TTL，从而提供显而易见的性能扩展。 + +说到警报，查询阶段计算也意味着警报查询需要基于查询引擎。但在这种情况下，当数据集增加时，查询性能可能不一致。在不同的度量查询中也会发生相同的情况。 + +### 当前案例 + +如今，SkyWalking在许多大型企业的超大规模分布式系统中使用，包括阿里巴巴、华为、腾讯、百度、中国电信以及多家银行和保险公司。上线SkyWalking的公司的流量比银行和电信供应商等传统公司还要多。 + +SkyWalking可以应用于分布式系统各种场景下的一个可观测性平台，这些系统在许多方面都是超大型的： + +- 拉勾网，一个在线招聘平台 + SkyWalking正在观测超过100个服务，500多个JVM实例 + SkyWalking每天收集和分析40多亿个跟踪数据，用来分析性能，包括30万个端点和依赖关系的指标 + 在整个群集中监控>50k流量/秒 + +- 永辉超市，线上服务 + SkyWalking每天分析至少100多亿（3B）的跟踪数据 + SkyWalking较小的部署，每天分析2亿多个跟踪数据 + +- 百度，互联网和人工智能公司，k8s部署 + SkyWalking每天从1400多个pod中收集1T以上的跟踪数据，共120多项服务 + 随着更多服务的增加，规模持续增大 + +- 贝壳找房(ke.com)，腾讯和软银集团控股的中国在线房地产经纪公司 + + 很早就使用了SkyWalking，有两名成员已经成为PMC。 + + Deployments每天收集160多亿个跟踪数据 + +- 阿里云效，阿里云上的DevOps服务 + + SkyWalking每天收集和分析数十亿个span + + SkyWalking使阿里云的45项服务和~300个实例保持稳定 + +- 阿里巴巴天猫， 一个从淘宝剥离出来的最大的B2C电商部门 + + SkyWalking个性化定制版，每天监控数十亿跟踪数据 + + 与此同时，他们基于SkyWalking的Agent技术栈，利用其跟踪和上下文传播能力，正在构建一个负载测试平台。 Review comment: Use different formats in the cases. Please use the local env to check the final format. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
