一篇带你从零开始学微服务( 四 ) _微服务

核心维度：业务上一般会依据重要性程度对监控对象进行分级，最简单的是分成核心业务和非核心业务。核心业务和非核心业务在部署上必须隔离，分开监控，这样才能对核心业务做重点保障。

服务追踪在调试单体应用时，非常直观容易。但是在微服务架构上，因为一个请求可能会通过不同的服务，而不同的服务又不在一个地方，这使得调试和跟踪变得困难。
所以服务追踪是分布式系统中必不可少的功能，它能够帮助我们查询一次用户请求在系统中的具体执行路径，以及每一条路径的上下游的详细情况，对于追查问题十分有用。
它的核心理念就是调用链：通过一个全局唯一的 ID 将分布在各个服务节点上的同一次请求串联起来，从而还原原有的调用关系，可以追踪系统问题、分析调用数据并统计各种系统指标。

traceId：用于标识某一次具体的请求 ID 。当用户的请求进入系统后，会在 RPC 调用网络的第一层生成一个全局唯一的 traceId，并且会随着每一层的 RPC 调用，不断往后传递，这样的话通过 traceId 就可以把一次用户请求在系统中调用的路径串联起来。
spanId：用于标识一次 RPC 调用在分布式请求中的位置。当用户的请求进入系统后，处在 RPC 调用网络的第一层 A 时 spanId 初始值是 0，进入下一层 RPC 调用 B 的时候 spanId 是 0.1，继续进入下一层 RPC 调用 C 时 spanId 是 0.1.1，而与 B 处在同一层的 RPC 调用 E 的 spanId 是 0.2，这样的话通过 spanId 就可以定位某一次 RPC 请求在系统调用中所处的位置，以及它的上下游依赖分别是谁。
annotation：用于业务自定义埋点数据，可以是业务感兴趣的想上传到后端的数据，比如一次请求的用户 UID 。

小结一下，traceId 是用于串联某一次请求在系统中经过的所有路径，spanId 是用于区分系统不同服务之间调用的先后关系，而 annotation 是用于业务自定义一些自己感兴趣的数据，在上传 traceId 和 spanId 这些基本信息之外，添加一些自己感兴趣的信息。
故障处理系统故障是避免不了的，虽然微服务架构做了服务拆分，不至于像单体架构那样整体崩溃，但由于其整体复杂度也大大提升，故障处理也更加困难。

文章插图

限流顾名思义，限流就是限制流量。通常情况下，系统能够承载的流量根据集群规模的大小是固定的，可以称之为系统的最大容量。
当真实流量超过了系统的最大容量后，就会导致系统响应变慢，服务调用出现大量超时，反映给用户的感觉就是卡顿、无响应。
所以，应该根据系统的最大容量，给系统设置一个阈值，超过这个阈值的请求会被自动抛弃，这样的话可以最大限度地保证系统提供的服务正常。
熔断熔断和限流还不太一样，上面我们可以看到限流是控制请求速率，只要还能承受，那么都会处理，但熔断不是。
在一条调用链上，如果发现某个服务异常，比如响应超时。那么调用者为了避免过多请求导致资源消耗过大，最终引发系统雪崩，会直接返回错误，而不是疯狂调用这个服务。
降级什么是降级呢？降级就是通过停止系统中的某些功能，来保证系统整体的可用性。
降级可以说是一种被动防御的措施，为什么这么说呢？因为它一般是系统已经出现故障后所采取的一种止损措施。
容器化单体应用拆分成多个微服务后，能够实现快速开发迭代，但随之带来的问题是测试和运维部署成本的提升。
而容器技术正好可以很好的解决这些问题，目前最流行的当属 Docker 莫属。

文章插图

微服务容器化运维主要涉及到以下几点：

镜像仓库
容器调度
服务编排

镜像仓库镜像仓库的概念其实跟 Git 代码仓库类似，就是有一个集中存储的地方，把镜像存储在这里，在服务发布的时候，各个服务器都访问这个集中存储来拉取镜像，然后启动容器。
容器调度这个阶段主要是解决在哪些机器上启动容器的问题，特别是规模比较大的公司，一般有物理机集群，虚拟机集群，私有云和公有云。对接这么多不同的平台，难度还是不小的。