链路追踪概念
什么是链路追踪, 用来解决什么问题
用户行为链路, 如: 浏览页面, 观看视频, 购买商品, 收藏, 评论等等行为
服务流程链路, 快速定位异常: 用户发起退货, 迟迟没收到退回的商品, 哪个链条出了问题?
大数据 ai 画像, 一个链条下非业务的动态行为数据, 才是最贴近用户的素材
服务追踪的基础出发点 - 记录足迹
入口处生成链路标识 traceid
传递 traceid 参数给下层业务方法
各方法内部记录访问信息
使用 TreadLocal 来传参数
ThreadLocal, 很多地方叫做线程本地变量, 也有些地方叫做线程本地存储, 其实意思差不多. 可能很多朋友都知道 ThreadLocal 为变量在每个线程中都创建了一个副本, 那么每个线程可以访问自己内部的副本变量.
思考: 使用 TreadLocal 来传参数
如何让 traceid 的传递不侵入业务?
尽量少侵入业务代码
不需要开发人员来维护
MDC -----Mapped Diagnostic Context
与当前线程绑定 ---- Threadlocal
放数据 --- MDC.put(traceid,aaa)
取数据 --- MDC.get(traceid)
日志格式 ----%X{traceId}
分布式调用来了?
看看 dubbo 里的 rpc 调用
Dubbo 使用 filter
Dubbo 高阶 ---spi 扩展机制
完美, 优雅地解决掉了 rpc 的透传问题!
微服务
软件架构是一个包含各种组织的系统组织, 这些组件包括 web 服务器, 应用服务器, 数据库, 存储, 通讯层), 它们彼此或和环境存在关系. 系统架构的目标是解决利益相关者的关注点
微服务是指开发一个单个小型的但有业务功能的服务, 每个服务都有自己的处理和轻量通讯机制, 可以部署在单个或多个服务器上. 微服务也指一种种松耦合的, 有一定的有界上下文的面向服务架构. 也就是说, 如果每个服务都要同时修改, 那么它们就不是微服务, 因为它们紧耦合在一起; 如果你需要掌握一个服务太多的上下文场景使用条件, 那么它就是一个有上下文边界的服务, 这个定义来自 DDD 领域驱动设计
相对于单体架构和 SOA, 它的主要特点是组件化, 松耦合, 自治, 去中心化, 体现在以下几个方面
一组小的服务
服务粒度要小, 而每个服务是针对一个单一职责的业务能力的封装, 专注做好一件事情.
独立部署运行和扩展
每个服务能够独立被部署并运行在一个进程内. 这种运行和部署方式能够赋予系统灵活的代码组织方式和发布节奏, 使得快速交付和应对变化成为可能.
独立开发和演化
技术选型灵活, 不受遗留系统技术约束. 合适的业务问题选择合适的技术可以独立演化. 服务与服务之间采取与语言无关的 API 进行集成. 相对单体架构, 微服务架构是更面向业务创新的一种架构模式.
独立团队和自治
团队对服务的整个生命周期负责, 工作在独立的上下文中, 自己决策自己治理, 而不需要统一的指挥中心. 团队和团队之间通过松散的社区部落进行衔接.
本文到这里就结束了, 喜欢的朋友可以帮忙转发和关注一下, 感谢支持!
图文看得不是很懂? 没关系现在关注专栏: Java 架构技术进阶. 里面有大量 batj 面试题集锦, 还有各种技术分享, 如有好文章也欢迎投稿哦. 微信公众号: 慕容千语的架构笔记. 欢迎关注一起进步. 原教程讲解可以加 qun:908676731, 获取. 会有审核, 需要备注才会通过
来源: http://www.jianshu.com/p/8016382419dc