转眼已经 2020，距离微服务这个词落地已经过去好多年!(我记得 2017 年就听过这个词)。然而今天我想想什么是微服务，其实并没有一个很好的定义。
图片来自 Pexels
为什么这样说?按照微服务的定义：
微服务架构就是将一个庞大的业务系统按照业务模块拆分成若干个独立的子系统，每个子系统都是一个独立的应用，它是一种将应用构建成一系列按业务领域划分模块的，小的自治服务的软件架构方式，倡导将复杂的单体应用拆分成若干个功能单一、松偶合的服务，这样可以降低开发难度、增强扩展性、便于敏捷开发，及持续集成与交付活动。
根据这个定义，不难看出其实就是对复杂的业务系统统一做逻辑拆分，保持逻辑上的独立。
那么逻辑上独立，一个服务这样做真的就好吗，如何界定：小、独，还有要做一个事情，完成单一的业务，单一的功能要拆分出来，为了独立而独立会不会导致拆的过细?
不同人有不同的见解，我们今天一起探讨微服务的过去和未来。
微服务缘起
在没有微服务之前，我们最早的架构模式就是 MVC 模式，把业务逻辑分为：
- 表示层
- 业务逻辑层
- 数据访问层
MVC 模式随着大前端的发展，从一开始的前后端不分离，到现在的前后端分离逐渐演进。
这种演进好的一点是剥离了不同开发语言的开发环境和部署环境，使得开发较为便利，部署更直接。
然而问题是：这种模式仍然是单体应用模式，如果有一个改动需要上线，你不得不因为这个改动去考虑更多，因为你无法估量在这么大体量的代码中你的一个改动会不会引发蝴蝶效应。
另外很重要的一点就是移动互联网时代的到来，引发了用户数几何倍数暴增，传统的单体应用模式已经无法支撑用户量暴涨的流量冲击，互联网人不得不做出加机器的无奈之举。
然而发现有的时候加机器都无法搞定问题，因为逻辑调用过于耦合导致调用链复杂。
继而出现精简调用流程，梳理调用路径的举措，于是演变出微服务这个概念。
其实在没有微服务这个词出现之前， 我们也是这样干的，只是干的不彻底而已。
比如说有一个信贷系统，分为贷前，贷中，贷后三步：
在微服务未出现之前，我们大多是单体应用，基本上一个工程包含所有，无所不能，所以很臃肿。上述这些模块应该都是在一个工程中，但是按照业务做了代码上的拆分。
另外就是 RPC 框架横空出世，如果有服务上的拆分，比如不同部门之间调用对方提供的服务，那么八九不离十肯定定义的是 HTTP 接口，因为通用。但是某些时候大家又怕 HTTP 接口性能差，关键服务不敢用。
微服务出现之后，大家觉得按照模块分别部署好像是这么回事，同时默默在心里嘀咕，以前我只用发布一个工程，现在倒好，可能有个改动涉及 3 个服务，我一个小小的改动就要发布 3 次，是不是增加了工作量。
另外我以前都不用调接口的，现在依赖了一堆别的系统，系统调用这么复杂，万一别的系统有问题，我岂不是就被耽搁了!
在这种质疑中大家虽有抱怨但是也没有放弃赶时髦，微服务开展的如火如荼，用户中心独立部署，风控系统单独成型，支付中心全公司统一独立，财务系统不再各个业务各自为战而是统筹公司各个业务线统一规划。
按照业务抽象独立之后，大家发现好像是这么回事，用起来真香。虽然每次需要别的模块的时候就需要找对应模块进行接入，但是业务逻辑上清晰了呀，如果出了问题，不是自己的，那就是别人的，甩锅很方便的(笑)。
如何做微服务
因为微服务是功能粒度上的拆分，必然导致拆分之后的模块变多。
针对模块与模块之间的通信与维护，又演变出如下问题：
- 模块与模块之间如何通信
- 每个被拆分的微服务如何做负载均衡
- 服务如何做注册，如何做发现
- 服务之间调用如何做限流，服务调用失败如何做降级，流量异常如何做熔断
- 服务调用是否可以做统一的访问控制
针对这些问题，业界也在发展中慢慢演进出几套通用的框架。
理想中微服务框架应该具备这样的能力：
基于上述微服务框架应该具备的能力，我们来分析目前可以落地的微服务框架的具体实现。
目前国内用的最多的无外乎是两套框架：
- Dubbo
- Spring Cloud
Dubbo 大家都很熟悉，从开源到无人维护再到重新冲击 Apache 顶级项目。
但是 Dubbo 更加准确来说是一个分布式服务框架，致力于提供高效的 RPC 远程服务调用方案以及 SOA 服务治理方案。说白了就是个分布式远程服务调用框架。
Dubbo
从 Dubbo 官网给的图来看 Dubbo 的整体架构：
模块注解：
- Provider：暴露服务的服务提供方。
- Consumer：调用远程服务的服务消费方。
- Registry：服务注册与发现的注册中心。
- Monitor：统计服务的调用次数和调用时间的监控中心。
- Container：服务运行容器。
从上图中不难看出 Dubbo 功能还是很明确的：服务注册于发现，服务监控。
另外 Dubbo 也提供服务治理功能：
Dubbo 提供了集群容错的能力，在管理后台可以快速的摘除失败的服务。
从我们上面提到的一整套微服务应该提供的功能看，Dubbo 只是提供了服务注册与服务发现的功能。不可否认在这一项功能中，Dubbo 做的是非常优秀的。
Spring Cloud
Spring Cloud 基于 Spring Boot，为微服务体系开发中的架构问题，提供了一整套的解决方案：服务注册与发现，服务消费，服务保护与熔断，网关，分布式调用追踪，分布式配置管理等。
①服务注册与发现
目前 Spring Cloud 支持的服务注册组件有：
- Consul
- Eureka
Consul 不是 Spring 官方的项目，需要单独部署，Eureka 被 Spring 官方收录，本身属于 Spring Cloud 体系中。
下面列出可以被用作注册中心的组件，他们的特性对比：
Consul 官网中介绍了 Consul 的以下几个核心功能：
- 服务发现(Service Discovery)：提供 HTTP 与DNS 两种方式。
- 健康检查(Health Checking)：提供多种健康检查方式，比如 HTTP 状态码、内存使用情况、硬盘等等。
- 键值存储(KV Store)：可以作为服务配置中心使用，类似 Spring Cloud Config。
- 加密服务通信(Secure Service Communication)。
- 多数据中心(Multi Datacenter)：Consul 通过 WAN 的 Gossip 协议，完成跨数据中心的同步。
Consul 需要单独部署，而不是与 Spring 集成的组件。
Eureka 是 Spring Cloud NetFlix 默认的服务发现框架，但目前 2.0 版本已闭源，只剩下 1.9 版本的处于维护状态。
Eureka 使用尽力而为同步的方式提供弱一致的服务列表。当一个服务注册时，Eureka 会尝试将其同步到其他节点上，但不提供一致性的保证。
因此，Eureka 可以提供过时的或是已不存在的服务列表(在服务发现场景下，返回旧的总比什么也不返回好)。
如果在 15 分钟内超过 85% 的客户端节点都没有正常的心跳，那么 Eureka 就会认为客户端与注册中心出现了网络故障(出现网络分区)，进入自我保护机制。
此时：
- Eureka Server 会保护服务注册表中的信息，不再删除服务。这是由于如果出现网络分区导致其他微服务和该 Eureka Server 无法通信，Eureka Server 就会判定这些微服务失效，但很可能这些微服务都是健康的。
- Eureka Server 仍能接受新服务的注册和查询请求，但这些数据不会被同步到其他节点。
- 当网络恢复时，这个 Eureka Server 节点的数据会被同步到其他节点中。
优点：Eureka Server 可以很好的应对因网络故障导致部分节点失联的情况，而不会像 ZK 那样如果有一半不可用的情况会导致整个集群不可用。
②服务网关
微服务的拆分导致服务分散，如果一个大的业务要对外提供输出，每个服务单独对外提供调用对接入方不友好并且调用也会很复杂。
所以出现了网关，网关主要实现请求的路由转发，负载均衡，统一校验，请求过滤等功能。
目前社区主流的网关有三个：
- Zuul
- Kong
- Spring Cloud GateWay
Zuul：是 Netflix 公司的开源项目，Spring Cloud 在 Netflix 项目中也已经集成了 Zuul，依赖名叫：spring-cloud-starter-netflix-zuul。
Zuul 构建于 Servlet 2.5，兼容 3.x，使用的是阻塞式的 API，不支持长连接，比如 Websockets。
我们现在说的 Zuul 指 Zuul 1.x，Netflix 最新的 Zuul 2.x一直跳票，所以 Spring Cloud 在 Zuul 2.x 没有出的时候依靠社区的力量发展出了新的网关组件：Spring Cloud Gateway。
Zuul 的核心功能就是基于 Servlet 提供了一系列的过滤器：
- 身份认证与安全：识别每个资源的验证要求，并拒绝那些与要求不符的请求。
- 审查与监控：在边缘位置追踪有意义的数据和统计结果，从而带来精确的生产视图。
- 动态路由：动态地将请求路由到不同的后端集群。
- 压力测试：逐渐增加指向集群的流量，以了解性能。
- 负载分配：为每一种负载类型分配对应容量，并启用超出限定值的请求。
- 静态响应处理：在边缘位置直接建立部分响应，从而避免其转发到内部集群。
Spring Cloud Gateway：构建于 Spring 5+，基于 Spring Boot 2.x 响应式的、非阻塞式的 API。
同时，它支持 Websockets，和 Spring 框架紧密集成，开发体验相对来说十分不错。
Spring Cloud Gateway 是基于 WebFlux 框架实现的，而 WebFlux 框架底层则使用了高性能的 Reactor 模式通信框架 Netty。
总体来说，Spring Cloud Gateway 与 Zuul 功能差别不大，最大的出入是在底层性能的提升上。
Zuul 本身是基于 Servlet 容器来实现的过滤，Servlet 采用的是单实例多线程的处理方案，Servlet 会为每一个 Request 分配一个线程。
如果当前线程比较耗时那么会一直等到线程处理完毕才会返回。所以说 Zuul 是基于 Servlet 之上的一个阻塞式处理模型。
同步阻塞模型对于网关这种比较在意响应耗时和调用频繁的组件来说，必然会引发一些性能问题，所以 Zuul 2 已经做出了改良，从 Zuul 2 开始已经使用 Netty。
但是不幸的是 Spring 官方已经对它的更新频率感到失望，所以纵然更新了也没有被选用。
Spring Cloud Gateway 底层基于 Webflux。Webflux 模式替换了旧的 Servlet 线程模型。
用少量的线程处理 request 和 response io 操作，这些线程称为 Loop 线程。
Webflux 的 Loop 线程，正好就是著名的 Reactor 模式 IO 处理模型的 Reactor 线程，如果使用的是高性能的通信框架 Netty，这就是 Netty 的 EventLoop 线程。
所以整体来看，Spring Cloud Gateway 的性能要比目前在用的 Zuul 高。但是 Webflux 的编程方式可能大家不是很能接收。
③服务降级
降级限流在微服务中属于银弹，一般不用，一旦用上那就是拯救宇宙般存在。
目前业界通用的降级限流工具主要有三款：
- Hystrix
- Sentinel
- Resilience4j
Hystrix 的关注点在于以隔离和熔断为主的容错机制，超时或被熔断的调用将会快速失败，并可以提供 Fallback 机制。
Hystrix 是元老级别的存在，但是在 2018 年 11 月 Netflix 官方宣布停止更新(就是这么不靠谱，说跳票就跳票)。虽然停止更新，但是社区又推出了新的替代工具：Resilience4j。
Resilience4j 的模块化做的比较好，将每个功能点(如熔断、限速器、自动重试)都拆成了单独的模块。
这样整体结构很清晰，用户也只需要引入相应功能的依赖即可;另外 Resilience4j 是针对 Java 8 和函数式编程设计的，API 比较简洁优雅。
同时与 Hystrix 相比，Resilience4j 增加了简单的限速器和自动重试特性，使用场景更加丰富。
相比 Hystrix ， Resilience4j 的优势在于：
- 针对 Java 8 和函数式编程设计，提供函数式和响应式风格的 API。
- 增加了 rate limiting 和 automatic retrying 两个模块。其中 rate limiting 引入了简单的速率控制实现，补充了流量控制这一块的功能。
- 而 automatic retrying 则是封装了自动重试的逻辑，简化了异常恢复的流程。
Resilience4j 属于一个新兴项目，社区也在蓬勃发展。总的来说，Resilience4j 是比较轻量的库，在较小较新的项目中使用还是比较方便的。
但是 Resilience4j 只包含限流降级的基本场景，对于非常复杂的企业级服务架构可能无法很好地 cover 住。
同时 Resilience4j 缺乏生产级别的配套设施(如提供规则管理和实时监控能力的控制台)。
Sentinel 是一款面向分布式服务架构的轻量级流量控制组件，主要以流量为切入点，从流量控制、熔断降级、系统自适应保护等多个维度来帮助用户保障服务的稳定性。
Sentinel 的核心思想：根据对应资源配置的规则来为资源执行相应的流控/降级/系统保护策略。在 Sentinel 中资源定义和规则配置是分离的。
用户先通过 Sentinel API 给对应的业务逻辑定义资源，然后可以在需要的时候动态配置规则。
整体功能对比：
从上面的参照看，Sentinel 的功能相对要多一些，但是多并不意味着所有，合适的才是最好的，对于你用不到的功能，简单才是美丽。
④统一配置中心
统一配置中心概念的提出也是伴随着微服务架构出现才出现，单体应用的时候所有的配置都可以集成在服务之中，多应用的时候如果每个应用都持有一份配置可能会有相同配置冗余的情况。
如果一共有 2000 台机器，其中一个配置发生更改，是否要登录每一台机器重新更改配置呢。
另外，更多的配置必然会带来管理上的混乱，如果没有集中管理的地方必然会越来越乱。
分布式配置管理的本质基本上就是一种推送-订阅模式的运用。配置的应用方是订阅者，配置管理服务则是推送方。
其中，客户端包括管理人员 Publish 数据到配置管理服务，可以理解为添加/更新数据;配置管理服务 Notify 数据到订阅者，可以理解为推送。
配置管理服务往往会封装一个客户端库，应用方则是基于该库与配置管理服务进行交互。
在实际实现时，客户端库可能是主动拉取(pull)数据，但对于应用方而言，一般是一种事件通知方式。
选型一个合格的配置中心，至少需要满足如下四个核心需求：
- 非开发环境下应用配置的保密性，避免将关键配置写入源代码。
- 不同部署环境下应用配置的隔离性，比如非生产环境的配置不能用于生产环境。
- 同一部署环境下的服务器应用配置的一致性，即所有服务器使用同一份配置。
- 分布式环境下应用配置的可管理性，即提供远程管理配置的能力。
Diamond：最开始我接触过的配置中心是淘宝的 Diamond，Diamond 中的数据是简单的 Key-Value 结构。应用方订阅数据则是基于 Key 来订阅，未订阅的数据当然不会被推送。
Diamond 是无单点架构，在做更新配置的时候只做三件事：
- 写数据库
- 写本地
- 通知其他机器到数据库拉更新
本地的设计就是为了缓存，减少对数据库的压力。作为一个配置中心，高可用是最主要的需求。
如何保持高可用，Diamond 持有多层的数据存储，数据被存储在：数据库，服务端磁盘，客户端缓存目录，以及可以手工干预的容灾目录。
客户端通过 API 获取配置数据，按照固定的顺序去不同的数据源获取数据：容灾目录，服务端磁盘，客户端缓存。
Diamond 除了在容灾上做了很多方案，在数据读取方面也有很多特点。客户端采用推拉结合的策略在长连接和短连接之间取得一个平衡，让服务端不用太关注连接的管理，又可以获得长连接的及时性。
使用 Diamond 的流程如下：
发布配置
读取配置
Diamond Server 是无中心节点的逻辑集群，这样就能避免单点故障。
Diamond 的同质节点之间会相互通信以保证数据的一致性，每个节点都有其他节点的地址信息，其中一个节点发生数据变更后会响应的通知其他节点，保证数据的一致性。
为了保证高可用，Client 还会在 App 端缓存一个本地文件，这样即使 Server 不可用也能保证 App 可用。
Client 不断长轮询 Server，获取最新的配置推送，尽量保证本地数据的时效性。
Client 默认启动周期任务对 Server 进行长轮询感知 Server 的配置变化，Server 感知到配置变化就发送变更的数据编号，客户端通过数据编号再去拉取最新配置数据;否则超时结束请求(默认 10 秒)。
拉取到新配置后，Client 会通知监听者(Message Listener)做相应处理，用户可以通过 Diamond#addListener 监听。
但是 Diamond 一般用途是做 KV 存储，如果用来做配置中心，他提供的能力不是太符合。
可以看到早期的配置中心处理的东西还是比较简单，那个时候业务没有那么复杂，读取配置和更新配置没有那么多花样，持久化存储和本地缓存，长连接更新就可以。但是现在的配置中心随着技术的发展承担的作用可能更多。
Spring Cloud Config：作为 Spring 官方提供的配置中心可能比较符合外国人的习惯。
Spring Cloud Config 将不同环境的所有配置存放在 Git 仓库中，服务启动时通过接口拉取配置。
遵循 {ServiceID}-{profile}.properties 的结构，按照 Profile 拉取自己所需的配置。
当开发者修改了配置项之后，需要结合 Spring Config Bus 将配置通知到对应的服务，实现配置的动态更新。
可以看到，Spring Cloud Config 已经具备了一个配置中心的雏形，可以满足小型项目对配置的管理，但仍然有着很多局限性。
配置使用 Git 库进行管理，那么 Git 库的权限如何来判断?不同环境的安全性也得不到保障。
配置的添加和删除，配置项的汇总，也只能通过 Git 命令来实现，对运维人员也并不友好。
Apollo(阿波罗)：是携程框架部门研发的开源配置管理中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性。
Apollo 支持四个维度管理 Key-Value 格式的配置：
- Application(应用)：实际使用配置的应用，Apollo 客户端在运行时需要知道当前应用是谁，从而可以去获取对应的配置;每个应用都需要有唯一的身份标识 – appId，应用身份是跟着代码走的，所以需要在代码中配置。
- Environment(环境)：配置对应的环境，Apollo 客户端在运行时需要知道当前应用处于哪个环境，从而可以去获取应用的配置。
- Cluster(集群)：一个应用下不同实例的分组，比如典型的可以按照数据中心分，把上海机房的应用实例分为一个集群，把北京机房的应用实例分为另一个集群。
对不同的 Cluster，同一个配置可以有不一样的值，如 ZooKeeper 地址。
- Namespace(命名空间)：一个应用下不同配置的分组，可以简单地把 Namespace 类比为文件，不同类型的配置存放在不同的文件中，如数据库配置文件，RPC 配置文件，应用自身的配置文件等。
应用可以直接读取到公共组件的配置 Namespace，如 DAL，RPC 等;应用也可以通过继承公共组件的配置 Namespace 来对公共组件的配置做调整，如 DAL 的初始数据库连接数。
Apollo 配置中心包括：
- Config Service：提供配置获取接口、配置推送接口，服务于 Apollo 客户端。
- Admin Service：提供配置管理接口、配置修改发布接口，服务于管理界面 Portal。
- Portal：配置管理界面，通过 MetaServer 获取 Admin Service 的服务列表，并使用客户端软负载 SLB 方式调用 Admin Service。
上图简要描述了 Apollo 的总体设计，我们可以从下往上看：
- Config Service 提供配置的读取、推送等功能，服务对象是 Apollo 客户端。
- Admin Service 提供配置的修改、发布等功能，服务对象是 Apollo Portal(管理界面)。
- Config Service 和 Admin Service 都是多实例、无状态部署，所以需要将自己注册到 Eureka 中并保持心跳。
- 在 Eureka 之上我们架了一层 Meta Server 用于封装 Eureka 的服务发现接口。
- Client 通过域名访问 Meta Server 获取 Config Service 服务列表(IP+Port)，而后直接通过 IP+Port 访问服务，同时在 Client 侧会做 Load Balance、错误重试。
- Portal 通过域名访问 Meta Server 获取 Admin Service 服务列表(IP+Port)，而后直接通过 IP+Port 访问服务，同时在 Portal 侧会做Load Balance、错误重试。
- 为了简化部署，我们实际上会把 Config Service、Eureka 和 Meta Server 三个逻辑角色部署在同一个 JVM 进程中。
客户端设计：
上图简要描述了 Apollo 客户端的实现原理：
- 客户端和服务端保持了一个长连接，从而能第一时间获得配置更新的推送。
- 客户端还会定时从 Apollo 配置中心服务端拉取应用的最新配置。这是一个 Fallback 机制，为了防止推送机制失效导致配置不更新。
客户端定时拉取会上报本地版本，所以一般情况下，对于定时拉取的操作，服务端都会返回 304 - Not Modified。
定时频率默认为每 5 分钟拉取一次，客户端也可以通过在运行时指定 System Property: apollo.refreshInterval 来覆盖，单位为分钟。
- 客户端从 Apollo 配置中心服务端获取到应用的最新配置后，会保存在内存中。
- 客户端会把从服务端获取到的配置在本地文件系统缓存一份，在遇到服务不可用，或网络不通的时候，依然能从本地恢复配置。
- 应用程序从 Apollo 客户端获取最新的配置、订阅配置更新通知。
配置更新：前面提到了 Apollo 客户端和服务端保持了一个长连接，从而能第一时间获得配置更新的推送。
长连接实际上是通过 Http Long Polling 实现的，具体而言：
- 客户端发起一个 Http 请求到服务端。
- 服务端会保持住这个连接 60 秒，如果在 60 秒内有客户端关心的配置变化，被保持住的客户端请求会立即返回，并告知客户端有配置变化的 Namespace 信息，客户端会据此拉取对应 Namespace 的最新配置。
如果在 60 秒内没有客户端关心的配置变化，那么会返回 Http 状态码 304 给客户端。
- 客户端在收到服务端请求后会立即重新发起连接，回到第一步。
考虑到会有数万客户端向服务端发起长连，在服务端使用了 async servlet(Spring DeferredResult)来服务 Http Long Polling 请求。
⑤调用链路分析
服务调用链路分析在微服务中是幕后至关重要的使者，试想几百个服务掺杂在一起，你想捋出谁先调用了谁，谁被谁调用，如果没有一个可监控的路径，光凭脑子跟踪那得多累。
基于这种需求，各路大神们集中脑汁展开遐想弄出一套分布式链路追踪神器来。
在介绍调用链监控工具之前，我们首先需要知道在微服务架构系统中经常会遇到两个问题：
- 跨服务调用发生异常，要求快速定位当前这次调用出问题在哪一步。
- 跨服务的调用发生性能瓶颈，要求迅速定位出系统瓶颈应该如何做。
打个比方说我们有两个服务：订单中心，库存中心。用户下单，先去查询库存系统，那么调用链路分析系统对于一个下单查询服务应该记录什么呢?
我们造出如下一张调用链路请求记录表，表字段如下：
表字段说明：
- id：自增 id
- span_id：唯一 id
- pspan_id：父级 span_id
- service_name：服务名称
- api：api 路径
- stage：阶段/状态
- timestamp：插入数据时的时间戳
上表中的 stage 中的状态解释为：
- CS(Client Sent 客户端发送)：客户端发送一个请求，表示 Span 的开始。
- SR(Server Received 服务端接收)：服务端接收请求并开始处理它。(SR - CS)等于网络的延迟。
- SS(Server Sent 服务端发送)：服务端处理请求完成，开始返回结束给服务端。(SR - SS)表示服务端处理请求的时间。
- CR(Client Received 客户端接收)：客户端完成接受返回结果，此时 Span 结束。(CR - CS)表示客户端接收服务端数据的时间。
根据这个表我们就能很快的分析上面提到的两个问题：
如果以上任何一步有问题，那么当前调用就不是完整的，我们必然能追踪出来。
通过每一步的调用时间进行分析，我们也必然知道阻塞在哪一步，从而对调用慢的地方进行优化。
现有的分布式 Trace 基本都是采用了 Google 的 Dapper 标准。
Dapper 的思想很简单，就是在每一次调用栈中，使用同一个 TraceId 将不同的 Server 联系起来。
一次单独的调用链也可以称为一个 Span，Dapper 记录的是 Span 的名称，以及每个 Span 的 ID 和父 ID，以重建在一次追踪过程中不同 Span 之间的关系。
对于一个特定的 Span，记录从 Start 到 End，首先经历了客户端发送数据，然后 Server 接收数据，然后 Server 执行内部逻辑，这中间可能去访问另一个应用。执行完了 Server 将数据返回，然后客户端接收到数据。
在整个过程中，TraceId 和 ParentId 的生成至关重要。首先解释下 TraceId 和 ParentId。
TraceId 是标识这个调用链的 Id，整个调用链，从浏览器开始放完，到 A 到 B 到 C，一直到调用结束，所有应用在这次调用中拥有同一个 TraceId，所以才能把这次调用链在一起。
既然知道了这次调用链的整个 Id，那么每次查找问题的时候，只要知道某一个调用的 TraceId，就能把所有这个 Id 的调用全部查找出来，能够清楚的知道本地调用链经过了哪些应用，产生了哪些调用。但是还缺一点，那就是链。
基于这种需求，目前各大厂商都做出了自己的分布式追踪系统：
- 目前国内开源的有：阿里的鹰眼，美团的 CAT，京东的 Hydra，还有广为人知的个人开源 Apache 顶级项目 SkyWalking。
- 国外的有：Zipkin，Pinpoint。
Spring Cloud Sleuth+Zipkin：Spring Cloud Sleuth 实现了一种分布式的服务链路跟踪解决方案，通过使用 Sleuth 可以让我们快速定位某个服务的问题。
简单来说，Sleuth 相当于调用链监控工具的客户端，集成在各个微服务上，负责产生调用链监控数据。
通过 Sleuth 产生的调用链监控信息，让我们可以得知微服务之间的调用链路，但是监控信息只输出到控制台始终不太方便查看。
所以我们需要一个图形化的工具，这时候就轮到 Zipkin 出场了。Zipkin 是 Twitter 开源的分布式跟踪系统，主要用来收集系统的时序数据，从而追踪系统的调用问题。
Spring Cloud Slueth 聚焦在链路追踪和分析，将信息发送到 Zipkin，利用 Zipkin 的存储来存储信息。
当然，Zipkin 也可以使用 ELK 来记录日志和展示，再通过收集服务器性能的脚本把数据存储到 ELK，则可以展示服务器状况信息。
Pinpoint：数据分析非常完备。提供代码级别的可见性以便轻松定位失败点和瓶颈，对于执行的 SQL 语句，都进行了记录。
还可以配置报警规则等，设置每个应用对应的负责人，根据配置的规则报警，支持的中间件和框架也比较完备。
Pinpoint 是一个完整的性能监控解决方案：有从探针、收集器、存储到 Web 界面等全套体系。
Pinpoint 提供有 Java Agent 探针，通过字节码注入的方式实现调用拦截和数据收集，可以做到真正的代码无侵入，只需要在启动服务器的时候添加一些参数，就可以完成探针的部署。
对于这一点，Zipkin 使用修改过的类库和它自己的容器(Finagle)来提供分布式事务跟踪的功能。
但是，它要求在需要时修改代码。Pinpoint 是基于字节码增强的方式，开发人员不需要修改代码，并且可以收集到更多精确的数据因为有字节码中的更多信息。
相对来说，Pinpoint 界面显示的更加丰富，具体到调用的 DB 名，Zipkin 的拓扑局限于服务于服务之间。
SkyWalking：和 Pinpoint 有一种既生瑜何生亮的感叹。
SkyWalking 逻辑上分为四部分：
- 探针(SkyWalking-agent)
- 平台后端(oap-server)
- 存储(es)
- 用户界面(apm-webapp)
探针基于不同的来源可能是不一样的(原生代理，SDK 以及 Zipkin，Jaeger 和 OpenCensus )，但作用都是收集数据、将数据格式化为 SkyWalking 适用的格式。
平台后端是一个支持集群模式运行的后台、用于数据聚合、数据分析以及驱动数据流从探针到用户界面的流程。
平台后端还提供了各种可插拔的能力，如不同来源数据(如来自 Zipkin)格式化、不同存储系统以及集群管理，你甚至还可以使用观测分析语言来进行自定义聚合分析。
存储是开放式的，你可以选择一个既有的存储系统，如 ElasticSearch，H2 或 MySQL 集群(Sharding-Sphere 管理)、也可以选择自己实现一个存储系统。
用户界面对于 SkyWalking 的最终用户来说非常炫酷且强大、同样它也是可定制以匹配你已存在的后端的。
总结
以上是微服务全链路过程中需要经历的阶段，当然还不包括发布系统的搭建，底层数据治理能力。
所以提倡微服务可以，但是真的做起来不是所有公司都能做得到。小公司能做到服务拆分但是相应的配套设施不一定能跟上，大公司有人有钱有时间，才能提供这些基础设施。
微服务的路任重道远，搭起来一套完整的设施并用于生产环境还是挺有挑战，新的一年希望我能够在践行微服务的路上走下去，只有走的完整才是微服务，走的不完整对于开发人员来说，那就是过度开发，就是灾难。
