![[总结]全链路分布式追踪系统经验](http://www.mobabel.net/wp-content/themes/hueman/assets/front/img/thumb-medium-empty.png)
[总结]全链路分布式追踪系统经验
微服务中台技术解析之全链路分布式追踪系统实践 用了3年CAT，这次我想选择SkyWalking，老板反手就是一个赞！ 全链路监控神器Skywalking，就是这么秀！
Category: Design Patterns
[转]40张图看懂SkyWalking分布式追踪系统原理及实践
40张图看懂SkyWalking分布式追踪系统原理及实践 不论是 CPU，内存，还是响应时间，使用 SkyWalking 带来的性能损耗几乎可以忽略不计。 接下来我们再来看 SkyWalking 与另一款业界比较知名的分布式追踪工具 Zipkin, Pinpoint 的对比（在采样率为 1 秒 1 个，线程数 500，请求总数为 5000 的情况下做的对比）,可以看到在关键的响应时间上， Zipkin（117ms）,PinPoint（201ms）远逊色于 SkyWalking（22ms）
[转]有赞百亿级日志系统是怎么设计出来的?
日志平台为集团所有业务系统提供日志采集、消费、分析、存储、索引和查询的一站式日志服务。 主要为了解决日志分散不方便查看、日志搜索操作复杂且效率低、业务异常无法及时发现等等问题。 随着有赞业务的发展与增长，每天都会产生百亿级别的日志量（据统计，平均每秒产生 50 万条日志，峰值每秒可达 80 万条）。日志平台也随着业务的不断发展经历了多次改变和升级。 本文跟大家分享有赞在当前日志系统的建设、演进以及优化的经历，这里先抛砖引玉，欢迎大家一起交流讨论。
[汇总]日志开发经验
Spring Boot 服务监控，健康检查，线程信息，JVM堆信息，指标收集，运行情况监控等！ Spring Boot是如何实现日志的？ 阿里巴巴不允许工程师直接使用Log4j和Logback的API！ 3种常见的数据脱敏方案 一个注解搞定接口返回数据脱敏
[转]如何用Zipkin做好分布式追踪？
现代微服务架构由于业务系统模型日趋复杂，分布式系统中需要一套链路追踪系统来帮助我们理解系统行为，明确服务间调用。最近作者请到了 Zipkin 项目的主要开发维护人员 Adrian Cole 来介绍有关 Zipkin 项目的细节内容，可以让大家了解到如何在分布式追踪系统中用好 Zipkin。Adrian 一直在从事云计算相关开源项目的开发，是开源项目 Apache jclouds 和 OpenFeign 的创始人。最近几年，他专注于分布式跟踪领域，是 OpenZipkin 项目的主要开发维护人员。Adrian 目前在 Pivotal Spring Cloud OSS 团队工作。在加入 Pivotal 之前，他还在 Twitter，Square，Netflix 工作过。
[转]基于CQRS的架构在答题PK小游戏中的实践案例
1. 1. 前言 领域驱动设计（Domain-Driven Design，下文简称 DDD）在微服务时代成为了风口话题，而在 DDD 领域，我们常常看到命令查询与职责分离（Command and Query Responsibility Segregation，下文简称 CQRS）架构的身影。CQRS 架构由于本身只是一个读写分离的思想，实现方式多种多样。比如数据存储不分离，仅仅只是代码层面读写分离，也是 CQRS 的体现；然后数据存储的读写分离，Command 端负责数据存储，Query 端负责数据查询，Query 端的数据通过 Command 端产生的 Event 来同步，这种也是 CQRS 架构的一种实现。本文介绍的是后者这种实现方式的 CQRS 架构在研发实时答题 PK 系统中的实践，此外，我们还会引入事件溯源（Event Sourcing）模式，本文认为结合事件溯源模式，可以更好发挥 CQRS 架构的价值。
[转]最佳日志实践 v2.0
1. 0. 缘起 大约在三年前，我曾经写过一篇 最佳日志实践，还被码农周刊选为那年的 最受欢迎技术干货 之一。当时我任职于网易杭州研究院的存储平台组，主要做网易对象存储（NOS）的开发和部分运维工作。由于网易云音乐，易信等几个重要产品陆续上线，业务压力剧增，我们的系统在前前后后大约半年的时间里，出现了大大小小各种事故。通过不断总结事故原因、不断地优化代码、进化部署架构，才使整个系统逐渐稳定下来。那个时候组里人常常开玩笑说，我们采用的是TDD的开发模式，只是这个TDD不是测试驱动开发（Test Driven Development），而是悲剧驱动开发（Tragedy Driven Development）。
[转]最佳日志实践 v1.0
1. 前言 日志用来记录用户操作、系统运行状态等，是一个系统的重要组成部分。然而由于日志并非系统核心功能，通常情况下并不受团队的重视。在出现问题需要通过日志来定位时，才发现日志还存在很多问题。 日志记录的好坏直接关系到系统出现问题时定位的速度，同时可以通过对日志的观察和分析，提前发现系统可能的风险，避免线上事故的发生。 我们在开发和运维NOS（网易对象存储，Netease Object Storage）的过程中，对整个系统的日志进行了分析优化，积累出一些经验，归纳如下。
[转]微服务架构设计模式
如今，微服务架构已经成为了现代应用开发的首选。虽然它能够解决大部分的程序问题，但是它并非一颗百试不爽的“银弹”。 在采用这种架构之前，我们应当事先了解可能出现的各种问题及其共性，预先为这些问题准备好可重用的解决方案。 那么，在开始深入讨论微服务的不同设计模式之前，让我们先了解一下微服务架构的一些构建原则： 可扩展性 可用性 弹性 独立、自主性 去中心化治理 故障隔离 自动调配 通过 DevOps 实现持续交付 在遵循上述各条原则的同时，我们难免会碰到一些挑战。下面我们来具体讨论可能出现的各种问题、及其解决方案。
![[汇总]AI经验](http://www.mobabel.net/wp-content/themes/hueman/assets/front/img/thumb-small-empty.png)
