Mobabel

Just One Pure ITer

Category: Design Patterns

[转]40张图看懂SkyWalking分布式追踪系统原理及实践 0

Distributed Tracing

[转]40张图看懂SkyWalking分布式追踪系统原理及实践

40张图看懂SkyWalking分布式追踪系统原理及实践   不论是 CPU，内存，还是响应时间，使用 SkyWalking 带来的性能损耗几乎可以忽略不计。 接下来我们再来看 SkyWalking 与另一款业界比较知名的分布式追踪工具 Zipkin, Pinpoint 的对比（在采样率为 1 秒 1 个，线程数 500，请求总数为 5000 的情况下做的对比）,可以看到在关键的响应时间上， Zipkin（117ms）,PinPoint（201ms）远逊色于 SkyWalking（22ms）

[转]有赞百亿级日志系统是怎么设计出来的? 0

Log Aggregation

[转]有赞百亿级日志系统是怎么设计出来的?

日志平台为集团所有业务系统提供日志采集、消费、分析、存储、索引和查询的一站式日志服务。 主要为了解决日志分散不方便查看、日志搜索操作复杂且效率低、业务异常无法及时发现等等问题。 随着有赞业务的发展与增长，每天都会产生百亿级别的日志量（据统计，平均每秒产生 50 万条日志，峰值每秒可达 80 万条）。日志平台也随着业务的不断发展经历了多次改变和升级。 本文跟大家分享有赞在当前日志系统的建设、演进以及优化的经历，这里先抛砖引玉，欢迎大家一起交流讨论。

[汇总]日志开发经验 0

Log Aggregation

[汇总]日志开发经验

Spring Boot 服务监控，健康检查，线程信息，JVM堆信息，指标收集，运行情况监控等！ Spring Boot是如何实现日志的？ 阿里巴巴不允许工程师直接使用Log4j和Logback的API！ 3种常见的数据脱敏方案 一个注解搞定接口返回数据脱敏

[转]如何用Zipkin做好分布式追踪？ 0

Distributed Tracing

[转]如何用Zipkin做好分布式追踪？

  现代微服务架构由于业务系统模型日趋复杂，分布式系统中需要一套链路追踪系统来帮助我们理解系统行为，明确服务间调用。最近作者请到了 Zipkin 项目的主要开发维护人员 Adrian Cole 来介绍有关 Zipkin 项目的细节内容，可以让大家了解到如何在分布式追踪系统中用好 Zipkin。Adrian 一直在从事云计算相关开源项目的开发，是开源项目 Apache jclouds 和 OpenFeign 的创始人。最近几年，他专注于分布式跟踪领域，是 OpenZipkin 项目的主要开发维护人员。Adrian 目前在 Pivotal Spring Cloud OSS 团队工作。在加入 Pivotal 之前，他还在 Twitter，Square，Netflix 工作过。

0

Command Query Responsibility Segregation (CQRS)

[转]基于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 架构的价值。

[总结]日志格式 0

Log Aggregation

[总结]日志格式

1. 概述 统一日志服务使用了分布式跟踪技术来收集和存储分散在各个应用或接口服务的日志，这些日志可用于后续的运维、监控和统计分析。 分布式跟踪技术把每次请求的整个调用链记录下来，可以方便的查看一次请求从客户端到应用服务器到数据库等每个阶段的执行情况，详细参考OpenTracing。

[转]最佳日志实践 v2.0 0

Log Aggregation

[转]最佳日志实践 v2.0

1. 0. 缘起 大约在三年前，我曾经写过一篇 最佳日志实践，还被码农周刊选为那年的 最受欢迎技术干货 之一。当时我任职于网易杭州研究院的存储平台组，主要做网易对象存储（NOS）的开发和部分运维工作。由于网易云音乐，易信等几个重要产品陆续上线，业务压力剧增，我们的系统在前前后后大约半年的时间里，出现了大大小小各种事故。通过不断总结事故原因、不断地优化代码、进化部署架构，才使整个系统逐渐稳定下来。那个时候组里人常常开玩笑说，我们采用的是TDD的开发模式，只是这个TDD不是测试驱动开发（Test Driven Development），而是悲剧驱动开发（Tragedy Driven Development）。

[转]最佳日志实践 v1.0 0

Log Aggregation

[转]最佳日志实践 v1.0

1. 前言 日志用来记录用户操作、系统运行状态等，是一个系统的重要组成部分。然而由于日志并非系统核心功能，通常情况下并不受团队的重视。在出现问题需要通过日志来定位时，才发现日志还存在很多问题。 日志记录的好坏直接关系到系统出现问题时定位的速度，同时可以通过对日志的观察和分析，提前发现系统可能的风险，避免线上事故的发生。 我们在开发和运维NOS（网易对象存储，Netease Object Storage）的过程中，对整个系统的日志进行了分析优化，积累出一些经验，归纳如下。

0

Design Patterns

[转]微服务架构设计模式

如今，微服务架构已经成为了现代应用开发的首选。虽然它能够解决大部分的程序问题，但是它并非一颗百试不爽的“银弹”。 在采用这种架构之前，我们应当事先了解可能出现的各种问题及其共性，预先为这些问题准备好可重用的解决方案。 那么，在开始深入讨论微服务的不同设计模式之前，让我们先了解一下微服务架构的一些构建原则： 可扩展性 可用性 弹性 独立、自主性 去中心化治理 故障隔离 自动调配 通过 DevOps 实现持续交付 在遵循上述各条原则的同时，我们难免会碰到一些挑战。下面我们来具体讨论可能出现的各种问题、及其解决方案。