微服务架构所面临的问题
微服务架构中，服务之间会有错综复杂的依赖关系，例如：一个前端请求一般会依赖于多个后端服务，称为 “1=>N 扇出”。在实际生产环境中，服务往往不是百分百可靠，服务可能会出错或者产生延迟，如果一个应用不能对其依赖的故障进行容错和隔离，那么该应用本身就处在被拖垮的风险中。在一个高流量的网站中，某个单一后端一旦发生延迟，可能在数秒内导致所有应用资源（线程，队列等）被耗尽，造成所谓的雪崩效应（Cascading Failure），严重时可致整个网站瘫痪。另外，微服务架构整个应用分散成多个服务，定位故障点非常困难。
微服务组合
微服务依赖：
综上，微服务架构虽然逻辑设计上看是完美的，但就像积木搭建的华丽宫殿一样，经不起风吹草动。主要有两个方面的问题：
- 微服务架构整个应用分散成多个服务，定位故障点非常困难。
- 微服务数量变多导致其中一个服务出现故障的概率增大，并且一个服务故障可能导致整个系统挂掉，整个系统的稳定性下降。事实上，在大访问量的生产场景下，故障总是会出现的。
为了好好解决这些问题，对故障的处理一般从两方面入手，一方面尽量减少故障发生的概率，另一方面降低故障造成的影响。这些都是微服务框架需要解决的挑战。
调用链跟踪
在微服务架构下，一个用户的请求往往涉及多个内部服务调用。为了方便定位问题，需要能够记录每个用户请求时，微服务内部产生了多少服务调用，及其调用关系，这个叫做调用链跟踪。
近年来随着容器和微服务发展，各种调用链跟踪（链路监控）的产品层出不穷，例如：Jaeger、Zipkin、SkyWalking、 Pinpoint、Elastic APM、CAT 等 ，一般建议参考几个方面：
- 侵入性
- 扩展性
- 性能损耗
- 界面图标
- 业务能否 hold 住
- OpenTracing 标准
要实现调用链跟踪，每次服务调用会在 HTTP 的 Headers 中记录至少记录四项数据：
- traceId：标识一个用户请求的调用链路，具有相同 traceId 的调用属于同一条链路。
- spanId：标识一次服务调用的 ID，即链路跟踪的节点 ID。
- parentId：父节点的 spanId。
- requestTime & responseTime：请求时间和响应时间。
另外，还需要调用日志收集与存储的组件，以及展示链路调用的 UI 组件。
CNCF 推出 OpenTracing 标准，统一了 Trace 数据结构和格式，通过提供平台无关的 API，使得开发人员能够方便的添加追踪系统的实现，建议选型参考这个标准。
如果引入了 Istio，则建议配合 Jaeger，Jaeger 具有部分侵入性，由 Golang 编写，遵循 CNCF 的 OpenTracing 规范。Istio 的 Service Mesh Proxy Envoy，会自动生成 traceID，可以由 Jaeger 收集起来，形成调用链。
如果不引入 Service Mesh，则建议采用 Skywalking，在应用进程内启动一个 Agent，对链路数据收集后发送到 Server 端进行处理。
注意：链路跟踪只能定位到哪个服务出现问题，不能提供具体的错误信息。查找具体的错误信息的能力则需要由日志分析组件来提供。
