此篇介绍一下微服务架构中经常遇到的一些维护方面的问题。
微服务带来的新问题
微服务架构虽然解决了一些单体应用的旧问题，但也引入了新的问题：
- 微服务架构将整个应用分散成多个服务，定位故障点变得困难；
- 服务数量变多，导致稳定性下降，并且其中一个服务故障可能导致整个系统挂掉；
- 服务数量变多，部署和管理的工作量变大；
- 开发方面：如何保证各个服务在持续开发的情况下仍然保持协同合作；
- 测试方面：服务拆分后，几乎所有功能都会涉及多个服务，测试变得更加复杂。
微服务的维护手段
监控：发现故障
全链路跟踪：定位故障
要实现链路跟踪，每次服务调用会在HTTP的HEADERS中记录至少记录四项数据：
- traceId：traceId标识一个用户请求的调用链路，具有相同traceId的调用属于同一条链路。
- spanId：标识一次服务调用的ID，即链路跟踪的节点ID。
- parentId：父节点的spanId。
- requestTime & responseTime：请求时间和响应时间。
关于链路跟踪的理论依据可详见Google的 Dapper。
