- 综合排序
- 最热优先
- 最新优先
- 来自专栏CODING DevOps
构建全链路安全能力，守护代码资产安全
本文将就“代码资产的安全性”这一话题展开全面的阐述，尝试从代码管理的生命周期进行全链路分析，读者可以据此来审视自己企业的代码资产安全。 信息安全关注的方面更为全面，代码资产安全只是其中的一部分，而且往往不是最为关注的一部分。 代码资产安全不等于代码安全 代码资产安全不等于代码安全，这不太容易理解。 代码资产管理是围绕代码仓库的 全生命周期管理 代码资产管理的核心是代码仓库。仓库里存放着企业的全部代码，配置文件以及全部历史版本。 守护代码资产安全的核心就是围绕代码仓库的三个关键环节构建起全链路的安全能力，这三个环节分别是检入，存储和检出。 检入安全 检入可以理解为开发者在开发环境上编辑好代码，并且把代码传送到代码仓库的过程。 ，需要从检入，存储，检出三个环节对全链条进行风险分析。
1.1K50编辑于 2021-12-05 - 来自专栏老张的求知思考世界
全链路压测(1)：认识全链路压测
前言 之前断断续续写过一些全链路压测相关的技术文章，很多同学评价还不错。朋友建议我写个系列，基于自己的落地实践经验，对全链路压测做个系统性的梳理总结。 定义：如何理解全链路压测 PS：这里的定义是我基于自己对生产全链路压测的了解和实践总结得来的，仅代表个人观点。 1、什么是全链路压测？ ，数据流转性无法保证，数据多样性也存在部分问题； ---- 那么，要解决差异带来的不稳定因素，最终的选择就是生产全链路压测： 挑战：如何落地生产全链路压测 虽然全链路压测解决了传统压测过程中的种种痛点 流程：生产全链路压测落地实践 生产全链路压测的整个流程，大致可分为三个环节，每个环节的主要事项如下： 能力建设：生产压测能力演变历程 生产全链路压测的本质是能力建设的技术工程，不是一蹴而就。 4、生产只读业务链路压测 只读场景相对来说技术难度没那么大，可以通过这个阶段来做到技术练兵。 5、生产流量数据隔离能力 上面提到了数据安全隔离，这也是生产全链路压测最大的一个技术挑战。
3.6K30发布于 2021-10-14 - 来自专栏老张的求知思考世界
全链路压测(14)：生产全链路压测SOP
——来自百度百科 本篇文章要说的全链路压测SOP，实际上就是我在实践全链路压测的过程中，对实践经验和教训的一个总结。 全链路压测(1)：认识全链路压测 全链路压测(2)：方案调研和项目立项 全链路压测(3)：技术改造和测试验证 全链路压测(4)：全链路压测的价值是什么？ 全链路压测(5)：生产全链路压测实施全流程 全链路压测(6)：确认范围和识别风险 全链路压测(7)：核心链路四问 全链路压测(8)：构建三大模型 全链路压测(9)：容量评估和容量规划 全链路压测(10) ：测试要做的准备工作 全链路压测(11)：聊聊稳定性预案 全链路压测(12)：生产压测必不可少的环节 全链路压测(13)：高可用和性能优化 再加上本篇的生产全链路压测SOP思维导图，就是整个系列的内容。 最后，重申一下我对全链路压测的部分认知： 全链路压测是一个技术工程，而非单纯的测试手段； 全链路压测只适用于部分企业和业务类型，而非一个银弹； 全链路压测的落地并非一蹴而就，需要较好的技术基础设施建设做保障
1K10编辑于 2022-09-02 - 来自专栏老张的求知思考世界
全链路压测(5)：生产全链路压测实施全流程
前言 前面的几篇文章从生产全链路压测的定义，内部立项和技术调研，聊到了测试验证以及全链路压测的对企业业务和技术团队的价值，算是整体上的构建一个认知的概念。 从这篇文章开始，会进入具体的落地实践环节。 这篇文章中，我会介绍生产全链路压测的落地实施全流程，即每个环节要做什么事情。 四大阶段 如果将生产全链路压测作为一个阶段性的技术项目来看，全链路压测从开始到项目结束，需要经过四个阶段。 整体的实施流程图如下所示： 接下来我来为大家解密，生产全链路压测落地实施，在不同的阶段都会做哪些事情。 筹备阶段 确定业务范围 一般来说线上实施线上全链路压测之前，要明确本次压测需要验证的业务范围。 核心业务定义 出问题会影响其他业务链路； 流量较高且出现问题会影响整体业务目标的达成； 核心项目定义 前面提到了生产全链路压测是个复杂的技术项目，那么如何定义这种技术项目呢？
2K40编辑于 2022-04-01 - 来自专栏OSChina
全链路跟踪zipkin
--全链路跟踪 sleuth zipkin --> <dependency> <groupId>org.springframework.cloud</groupId
79120发布于 2020-04-24 - 来自专栏D·技术专栏
EagleEye全链路追踪
RpcID RPCId用链路调用顺序来递增。 阿里云相似产品：Tracing Analysis 效果图： ? image.png
4K10发布于 2020-02-13 - 来自专栏Java学习录
Zipkin全链路监控
Zipkin是SpringCloud官方推荐的一款分布式链路监控的组件，使用它我们可以得知每一个请求所经过的节点以及耗时等信息，并且它对代码无任何侵入，我们先来看一下Zipkin给我们提供的UI界面都是提供了哪些信息 zipkin首页为我们提供了对于调用链路的搜索查询及展示的功能 ? 第二个选项卡里提供了历史数据的导入功能 ? 第三个选项卡里展示了各个微服务之间的关系 ? 我们再次回到首页，我们点开一个调用链路之后就会看到此次链路调用的详情 ? 现在我们点开详情中的一个service，可以看到此次调用在这个微服务中的详细信息。 ?
3.7K00发布于 2019-04-18 - 来自专栏vivo互联网技术
Node.js 应用全链路追踪技术——全链路信息存储
作者：vivo 互联网前端团队- Yang Kun本文是上篇文章《Node.js 应用全链路追踪技术——全链路信息获取》的后续。阅读完，再来看本文，效果会更佳哦。 本文主要介绍在Node.js应用中， 如何用全链路信息存储技术把全链路追踪数据存储起来，并进行相应的展示，最终实现基于业界通用 OpenTracing 标准的 Zipkin 的 Node.js 方案。 2.2 zipkin 架构官方文档上的架构如下图所示：为了更好的理解，我这边对架构图进行了简化，简化架构图如下所示：从上图可以看到，分为三个部分：第一部分：全链路信息获取，我们不使用 zipkin 自带的全链路信息获取 ，我们使用 zone-context 去获取全链路信息第二部分：传输层， 使用 zipkin 提供的传输 api ，将全链路信息传递给 zipkin第三部分： zipkin 核心功能，各个模块介绍如下： 三、Node.js 接入 zipkin3.1 搞定全链路信息获取这个我在 《Node.js 应用全链路追踪技术——全链路信息获取》 文章中，已经详细阐述了，如何去获取全链路信息。
1.2K50编辑于 2023-02-06 - 来自专栏首席安全官
CSO：首席安全官人工智能数据全链路安全指南
隐形供应链：预训练模型、开源库和数据源的供应链风险难以追踪 这意味着CSO必须从被动的”事后应对”转变为主动的”事前设计安全”（Security by Design），并且需要从单纯的技术防守扩展到治理和合规的主导角色 二、 AI数据链路的核心安全要素 数据完整性与投毒防御 Anthropic的研究揭示了数据投毒的惊人简洁性。 （如安全问卷） 溯源可见性：使用Build Attestation等技术记录构建链的完整审计追踪 模型安全与对抗鲁棒性 部署后的模型面临对抗性攻击。 CSO仪表板： 高风险AI系统占比 模型中包含的可识别个人数据占比 平均删除请求处理时间 供应链漏洞修复时间 季度AI安全审计：由跨职能AI治理委员会进行，评估新威胁 优先级 监管受限行业（金融、医疗）的决策模型 极高 立即（周1-2） 处理大量个人数据的模型 极高 立即 客户交互/聊天机器人 中 短期（月1-6） 内部运营优化模型 低 中期（月6-12） 六、数据全链路关键防护点
22910编辑于 2026-01-20 - 来自专栏老张的求知思考世界
全链路压测(7)：核心链路四问
前言 前面的文章介绍了全链路压测的落地实施全流程，其中有个环节我特别提到了它的重要性，同时这也是本篇文章的主题：核心链路梳理。那什么是核心链路？为什么要确定核心链路？如何进行核心链路梳理？ 梳理核心链路的目的又是什么？这篇文章，我会给你答案。 什么是核心链路？ 之前在一些线下沙龙分享或者线上直播时候，很多同学都会问我一个问题：什么是核心链路？好像这个词有种魔法，很难让人去理解。 这么说比较拗口，再直白一些就是：哪些接口会影响用户下单支付，哪些就是核心链路。 下面附一个常见的电商企业核心链路流程图，供大家参考。 为什么要确定核心链路？ 流量模型 我在前面的文章《生产全链路压测实施全流程》中有提高转化技术指标的一个案例，这里再次回顾下： 客单价为500，单日GMV为10亿，那么支付订单量为10亿/500=200W； 假设日常支付订单量为 文末回顾 这篇文章主要聊了全链路压测在备战阶段最重要的一件事，核心链路梳理。其中提到了流量模型相关的内容，下篇文章，我会以全链路压测过程中需要梳理的三大模型为主题，为大家介绍它们。
1.9K21编辑于 2022-04-01 - 来自专栏老张的求知思考世界
全链路压测(4)：全链路压测的价值是什么？
在开始真正的介绍落地实践过程以及相关案例之前，我想和大家聊聊，我对全链路压测的一些认知，即：全链路压测在技术团队中的定位，以及它的价值是什么。 业务和技术是什么关系？ 全链路压测对稳定性保障的价值 聊了这么多，回到文章顶部，我所要表达的内容，全链路压测的价值是什么？ 通过生产全链路压测，可以串联稳定性保障的全流程，解决线上系统稳定性保障面临的种种挑战，它所带来的价值如下： 总结回顾 这篇文章介绍了我对技术和业务关系的理解，线上稳定性保障面临的挑战以及全链路压测在其中的价值 ，通过前面的几篇文章，从认识全链路压测到项目立项以及技术调研和测试验证，我试图从另一个视角来为大家揭秘全链路压测的另一面。 下篇文章，我会为大家介绍，全链路压测落地实践的整体流程。
1.6K20编辑于 2022-01-25 - 来自专栏肉眼品世界
轻松玩转全链路监控
什么是全链路监控？ ，为全链路监控提供了理论指导。 OpenTracing 抽象出一套与编程语言以及业务逻辑无关的接口，对链路追踪领域各类元素的统一管理，从而实现完整的全链路监控。 我们只需要知道，优秀的全链路监控组件会尽可能的遵循 OpenTracing 标准，以获得更好的通用性以及扩展性。 可选方案 ---- 全链路监控组件如何获得链路相关的信息呢？ 构建多语言全链路监控体系 ---- 除了Java语言外，ARMS还提供了PHP探针，PHP应用接入ARMS后，能够拥有和Java应用同样的全链路监控体验。
2K11发布于 2020-12-07 - 来自专栏测试开发架构之路
全链路测试不是银弹
何为全链路测试？ 个人认为，链路可以分为业务链路和调用链路，调用链路主要指从请求发起方到结果返回所途径各种服务/中间件产生的路径，可以理解为单系统下的某一功能模块。 而业务链路则是多个业务关联的场景组合产生的链路调用集合，例如淘宝添加购物车->提交订单->支付这个场景，所以全链路必然包含多个业务关联场景涉及的调用链路。 全链路下自动化成本更高，因为全链路用例涉及到多域的流程编排，处理服务间各种异常重试情况（超时、网络异常）， 各域的输出断言，这无疑大大增加一条用例开发成本。 综上，我们要正确看待全链路测试，不能迷信于全链路测试，觉得全链路测试通过就没啥问题了。 要知道，全链路测试更多从业务角度出发，不能覆盖所有潜在异常场景，二者可以相辅相成，但对于日常自动化回归，我认为做好域内测试自动化才是底盘，全链路自动化没什么必要！
57530编辑于 2022-08-01 - 来自专栏老张的求知思考世界
再谈全链路压测
面临的挑战 除了上面所说的技术层面的问题，要开展全链路压测，还面临如下的几点挑战： ①、由于全链路压测涉及的系统及场景较多，因此需要跨团队沟通、跨系统协调改造，公司体量 越大，这一点难度就越大； ②、全链路压测涉及的系统较多 不过全链路压测的优点也很明显，比如：优化联络薄弱环节可以提高系统的可用性，容量规划可 以节省成本，提高效率。 开展前的准备工作 在开展全链路压测之前，我们需要做哪些准备工作？ 因此需要通过监控分析等手段，得到日常流量场 景、峰值流量场景下各系统的流量以及配比，进行一定的放大，来作为全链路压测的流量参考模 型； ④、数据处理：全链路压测通常在生产环境进行，所以防止数据污染是必须考虑的问题 要开展全链路压测，那么一个合理高效可用的压测管理平台，是很有必要的，参考了很多全链路 压测的设计思路，我个人的想法中全链路压测平台的架构设计，主要由以下几部分组成： ①、Controller：主要任务为压测任务分配 具体的架 构设计图，可参考京东的全链路军演系统ForceBot的架构设计，如下图： ? 完成了上面的工作，接下来就可以开展全链路压测的工作了。
91610发布于 2019-12-02 - 来自专栏CodeGuide | 程序员编码指南
基于JavaAgent的全链路监控五《ThreadLocal链路追踪》
案例简述 Google开源的Dapper链路追踪组件，并在2010年发表了论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure 》，这篇文章是业内实现链路追踪的标杆和理论基础，具有非常大的参考价值。 目前，链路追踪组件有Google的Dapper，Twitter 的Zipkin，以及阿里的Eagleeye （鹰眼）等，它们都是非常优秀的链路追踪开源组件。 链路追踪(Dapper) 当业务程序代码在线上运行时，实例A、实例B、实例C，他们直接可能从上到下依次调用，为了能很好的监控程序的调用链路，我们需要对调用链路进行追踪监控。 测试结果：hi1 链路追踪：7dfd98e8-c474-461c-87b9-1da3bf6072c2 org.itstack.demo.test.ApiTest.http_lt2 测试结果：hi2 链路追踪
2.8K20发布于 2020-07-14 腾讯 EdgeOne 金融行业全链路安全加速解决方案
其核心商业价值在于构建了“安全与性能并重”的一体化服务能力，通过AI驱动的风险识别与全链路合规架构，确保金融核心业务在极端的市场波动与攻击压力下依然保持连续性与数据隐私安全。 交易系统全链路安全场景 痛点： 交易接口滥用、黑产薅羊毛、仿冒终端接入以及非法源站访问。 应用： 针对 API、传输层及源站进行全链路加固，防止数据泄露与篡改。 应用： 提供本地化处理与全链路审计，满足监管与追溯需求。 三、 应用框架和功能介绍 1. 全链路安全： 集成 API 动态防护（AI 识别）、传输层双向认证（mTLS）、SSL Pinning（防证书劫持）及源站可信访问控制（杜绝非法回源）。 合规支撑： 支持金融级合规体系、数据主权与跨境合规保障（按地域调度）、审计与全链路可追溯。 2. 硬核指标与标准 合规认证： 适配 等保三级、ISO 27001、PCI DSS 等主流合规框架。
23010编辑于 2026-02-03OpenClaw 公网部署：全链路安全加固与防入侵指南
以下是基于 2026 年网络环境的实战安全配置清单，拒绝花哨理论，直接上干货。 0. 基础设施选型：安全的第一道防线 在开始敲命令之前，服务器本身的选型和基础安全组配置至关重要。 配置防火墙（UFW / 安全组） 不要依赖服务器内部的软件防火墙，直接在云厂商的控制台配置安全组。 入站规则：仅放行必要的端口（如修改后的 SSH 端口、80、443）。 业务数据安全 数据库不外网开放：Redis、MySQL 等数据库监听地址务必设置为 127.0.0.1，严禁绑定 0.0.0.0，除非你配合了严格的安全组策略。 定期备份：使用脚本定期将 OpenClaw 的配置和数据打包备份到对象存储（COS/S3）中，防止勒索病毒导致数据全丢。 做好以上这几步，你的 OpenClaw 在公网上就具备了企业级的安全水位。 记住，安全没有绝对，只有成本与收益的博弈，增加攻击者的成本就是最好的防御。
1.8K42编辑于 2026-03-06- 来自专栏FunTester
全链路压测流量模型
现在全链路越来越火，各大厂商也纷纷推出了自己的全链路压测测试方案。特别是针对全链路压测流量模型，各家方案都有所不同。最近我看了一些这方面的资料，有一些感悟。分享给大家。 全链路压测流量模型的梳理呢，这里就先不讲了，各家公司自有司情在。因为主要是全链路压测模型的实现，其实实现也对应了流量模型的梳理结果。 首先要对公司业务模型进行梳理，也就是说对公司的业务链路进行梳理。这里的业务链路可能会比较复杂，不是像很多案例中到的了就非常流行畅的一条链路，中间很有可能会出现各种各样的支路。 如果图图形化展示的话，某一条链路应该就是一个树形结构。树形结构的开始是用户的入口页一般就是入口页面的登陆，或者说是首页接口。 将比较复杂的树形结构简单化，或者干脆将以个业务联络分解成n个列有链路。然后分别实现。最终将流量汇聚，就变成了整个业务链路的流量模型实现。
75830发布于 2021-10-08 - 来自专栏飞鸟的专栏
使用Zuul实现全链路追踪
简介 Zuul是Netflix开源的一款API网关，它提供了对请求进行路由、负载均衡、安全认证等功能。 除此之外，Zuul还提供了全链路追踪的功能，通过在请求头中添加相关信息，可以跟踪一个请求从发起到响应的整个过程，帮助我们定位问题。 实现原理 在Zuul中实现全链路追踪需要用到Sleuth和Zipkin，Sleuth是Spring Cloud提供的用于生成和管理Trace Id的工具，而Zipkin是一个分布式跟踪系统，用于收集和查询 tracing表示开启全链路追踪功能，sleuth表示使用Sleuth进行Trace Id的生成和管理，web表示启用Web的相关配置，client表示启用Zuul作为客户端的相关配置。
95820编辑于 2023-04-10 - 来自专栏用户6296428的专栏
有赞全链路追踪实践
全链路追踪系统就是为了解决微服务场景下的这些问题而诞生的。 一般在链路的入口应用中生成traceId和spanId，在后续的各节点调用中，traceId保持不变并全链路透传，各节点只产生自己的新的spanId。 六、总结与展望 全链路追踪系统包含几大部分：链路采集SDK、数据处理服务、用户产品。SDK部分比较偏技术。 用户产品主要考验的是设计者对用户需求的把握，全链路追踪可以做很多事情，产品上可以堆叠出很多功能，怎样能让用户快速上手，简洁而又易用是链路追踪产品设计的一大挑战。 未来一段时间，有赞全链路追踪会围绕以下几个方面继续演进： 赋能有赞云：给有赞云开发者用户提供有容器应用的链路追踪能力； 开源协议支持：数据模型与链路追踪API迁移到OpenTracing协议上，支持更多新语言的快速追踪
1.4K30发布于 2020-08-24
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号