Zipkin

1. zipkin基础介绍: 分布式追踪系统 概念： tranceID: 请求全局处理标识 spanID: 请求在单个服务流转处理标识 ParentID: 子服务中显示父服务ID(spanID)，主要用于构建服务调用链路 数据传输到Zipkin方式： http kafka Scribe Zipkin构成组件： collector: zipkin校验、保存、索引接收的追踪数据 storage: zipkin 数据存储（Cassandra、mysql、ES、内存等，支持扩展） search: zipkin 数据检索服务（WEB UI） WEB UI: 数据追踪展示UI,默认没有认证 2. 环境部署 参考官网下载： zipkin quickstart 3. 使用案例 3.1 maven 依赖引入 <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter

问题场景： 一周前正常，现在不正常，通过curl 访问单个工程能显示链路。如果通过网关入口访问不显示。 回顾： 一周前将spring cloud的zuul网关改成gateway 排查： 看elk日志，gateway将 traceId 打印出来，但是工程没有配置zipkin。 猜测： gateway将 traceId传入到后端服务，但是没有将记录传入到zipkin存储。 解决： 将gateway配置zipkin，链路显示正常 来源： oschina 链接： https://my.oschina.net/xiaominmin/blog/4297703

0、前言 微服务架构现在是个热门话题，微服务的高可用性自然也是企业非常关注的。眼下互联网的架构秘籍三板斧“高可用可扩展，缓存提速，消峰减流去并发”，在微服务架构体系中有着不一样的诠释。 在微服务中消息队列不仅用来消峰，还可以通过消息队列来解决微服务之间的多耦合，把同步调用转化为异步调用，减少调用链路，提升系统稳定性。 单体应用拆分为独立的多个无形中增加了系统的响应时间，可以通过本地缓存、分布式缓存相结合的方式来弥补性能的损耗。 以前通过内部接口调用的方法变成RPC调用多个服务，服务与服务之间还有依赖关系，每个服务接口响应时间也都不一样，简单的设置单个接口的超时时间已解决不了问题，可通过服务定级，哪些服务不能出问题，哪些服务允许有异常，采用降级、熔断的方式来解决问题，以达到系统的高可用。 以上这三种方式如能合理运用，微服务的高可用性大大提升，所以说缓存、队列、熔断降级成了微服务架构中的新三板斧。 以下是相关技术应用中的一些难点解答，供大家参考。 1、微服务架构中有哪些技术手段必须在设计阶段就需要规划进去? 互联网的三板斧：熔断、消息队列、缓存，这个必须有要考虑进入，另外为了提高响应时间，并行化操作也需要提前考虑。 熔断：保障服务高可用的重要手段，用户的请求将不再直接访问服务，而是通过线程池中的空闲线程来访问服务，如果线程池已满，则会进行降级处理，用户的请求不会被阻塞

通过keytool生成jks文件： 运行下面的命令生成私钥，姓名国家啥的可以不填 keytool -genkey -alias ffzs-jwt -keyalg RSA -keysize 1024 -keystore ffzs-jwt.jks -validity 365 -keypass ffzs00 -storepass ffzs00 在上面的命令中，-alias选项为别名，-keypass和-storepass为密码选项，-validity为配置jks文件的过期时间（单位：天）。 获取的jks文件作为私钥，是如何解密JWT的呢？这时就需要使用jks文件的公钥。获取jks文件的公钥命令如下： keytool -list -rfc --keystore ffzs-jwt.jks | openssl x509 -inform pem -pubkey 输入密码之后生成公钥可私钥 auth端修改： 这个不重要，我们将生成的ffzs-jwt.jks文件放到resources目录 修改jwtTokenEnhancer方法如下，通过jks文件获取公钥来生成token @Bean protected JwtAccessTokenConverter jwtTokenEnhancer ( ) { KeyStoreKeyFactory keyStoreKeyFactory = new

grafana 7.0 最近发布了，添加了对于分布式追踪（opentracing）的展示支持，同时界面ui也有调整 以下是一个简单的试用 环境准备 docker-compose 文件 version: "3" services: grafana: image: grafana / grafana: 7.0.0 ports: - "3000:3000" jaeger: image: jaegertracing / all - in - one: 1.18 environment: - "COLLECTOR_ZIPKIN_HTTP_PORT=9411" ports: - "9411:9411" - "5775:5775/udp" - "6831:6831/udp" - "6832:6832/udp" - "16686:16686" 配置 demo 项目 clone 代码 git clone https: //github.com/luoyjx/opentracing-demos.git 运行 参考node 项目运行就可以了，注意部分端口需要修改不然会有冲突的问题 查询效果 说明 grafana 的功能是越来越强大了，我们可以基于分布式追踪以及prometheus metrics 实现一个比较统一的dahsboard监控系统 参考资料 https://grafana.com/blog

都 2020 年了 还没用过 微服务 吗？ 面试的时候高并发回答的总是不能让面试官满意？ 一个互联网项目究竟有多少细节？ 网上搜了一堆秒杀系统方案，究竟真实的线上电商该怎么做？ 那么你缺乏这两个字 实 战 消除痛点、解决面试、积累实战经验 欢迎你参加马士兵教育 微服务与高并发 训练营 本号粉丝： 免 费 两天你将学到 快速 · 上手微服务，了解各个组件的作用 极简 · 从点到面，内容绝不拖泥带水 实战 · 构建微服务项目 架构 · 高并发系统中组件解析与选型 健壮 · 互联网项目常用中间件服务 做到 · 从传统项目转向微服务互联网系统架构 吊打 · 面试官，独家解析淘宝网秒杀系统需求 马士兵是谁？ 马士兵 马士兵老师，清华大学， 推动Java生根中国 ， 推动大数据生根中国 ， 推动AI生根中国 ，视频课程下载次数累计数 27000万次 。 训练营时间： 7月29日-7月30日，20:00 开营前：发放预习的基础资料 长按扫码，领预习资料，入群学习 遇到扫码频繁，请再次识别 福利较大，限前200人 第一天：快速上手SpringCloud微服务系统架构+常用中间件服务 SOA、Webservice、Dubbo、SpringCloud究竟什么是微服务？ 单体应用向微服务异构平台架构演变 SpringCloud微服务组件生态体系 从零开始构建微服务项目各组件应用场景及代码实现

目录 前言 一、常用指标 响应时间 并发数 QPS TPS 二、夺命三高 高并发 高性能 高可用 三、常见招式 分流 缓存 队列 CDN 池化 扩容 熔断 限流 降级 分层 部署分级 日志监控 查询优化 读写分离 分库分表 前言 冰冻三尺非一日之寒，葵花宝典也不是一天写出来的，系统设计也如此，好的架构是不断演进的。 一般来说能用单块架构解决的问题，尽量不要采用分布式。 分布式虽然可以提高系统的响应能力，也带来了更高的复杂性，如果团队技术人员水平hold不住的话，反而会产生更多问题，例如问题难以定位、系统性能下降、某种业务实现困难或无法实现等问题。 以下内容由伟大的诗人chenqionghe整理，light weight baby~ 一、常用指标 响应时间 直观反应系统快慢，一般控制在200ms以内，超过1s用户已经能感觉到慢了 并发数 同时处理请求的数目 QPS 每秒查询请求数 TPS 每秒执行事务数，着重反应写 二、夺命三高 没错，就是高血压、高血糖和高血脂，开玩笑啦~ 高并发 通过设计让系统能接收更多的用户并发请求，承担更大的流量。 一般考查并发数、QPS和TPS。 示例：庐山百龙霸，并发百龙 高性能 一般指服务响应时间快 用户视角。APP、浏览器上能直观感受快 开发视角。响应延迟低，系统吞吐量大，并发处理能力强 运维视角。基础设施配置高，CPU多核心，内存容量大 示例

CREATE TABLE IF NOT EXISTS zipkin_spans ( `trace_id` BIGINT NOT NULL, `id` BIGINT NOT NULL, `name` VARCHAR(255) NOT NULL, `parent_id` BIGINT, `debug` BIT(1), `start_ts` BIGINT COMMENT "Span.timestamp(): epoch micros used for endTs query and to implement TTL", `duration` BIGINT COMMENT "Span.duration(): micros used for minDuration and maxDuration query" ) ENGINE=InnoDB ROW_FORMAT=COMPRESSED; ALTER TABLE zipkin_spans ADD UNIQUE KEY(`trace_id`, `id`) COMMENT "ignore insert on duplicate"; ALTER TABLE zipkin_spans ADD INDEX(`trace_id`, `id`) COMMENT "for joining with zipkin_annotations"; ALTER

Istio 1.6.3 发布了。Istio 是一个由谷歌、IBM 与 Lyft 共同开发的开源项目，旨在提供一种统一化的微服务连接、安全保障、管理与监控方式。具体来说，Istio 是一个开源服务网格平台，它确保微服务在处理故障时以指定的方式相互连接。 更新内容 修复了监视资源被删除后，操作员无法重新创建的问题 修复了Istio因消息崩溃的问题： proto.Message is *client.QuotaSpecBinding, not *client.QuotaSpecBinding 添加了对 k8s.v1.cni.cncf.io/networks 注释的支持 更新了 SidecarInjectionSpec 以从 .Values.global 读取 imagePullSecret 更新了水平分割以跳过解析主机名的网关 修复了 istioctl experimental metrics ，仅将错误响应代码标记为 erros 更新了 istioctl analyze 以对输出格式进行排序 更新了网关以使用 proxyMetadata 更新了 Prometheus Sidecar 以使用 proxyMetadata 启用 gateway.runAsRoot 时从 PodSecurityContext 中删除了无效的配置 升级更新 从已有版本升级，运行： istioctl