微服务架构基础原理

微服务框架

• ‌6个基本组件：服务描述、注册中心、服务框架、服务监控、服务治理、服务追踪。
• 常用的服务描述方式： RESTful API（http协议）、XML配置（PRC协议）、IDL文件（跨语言服务调用）。
• 注册中心：服务的发布和订阅。
• 服务框架参考标准
  • 通信协议（TCP/UDP四层-HTTP七层）；
  • 数据传输方式（同步/异步-！单连接/多路复用）；
  • 数据压缩。
• 服务监控：
  • 指标收集（QPS、耗时、成功）
  • 数据处理
  • 数据展示（业务报警）
• 服务追踪：问题追踪、故障定位。生成、传递requestid、spanid。‌服务治理、集群。
• http协议包含冗余信息，类比xml。

监控微服务调用

• 监控对象
  • 用户端监控。指监控业务直接对用户提供的功能。
  • 接口监控。指监控业务提供的功能所依赖的具体PRC接口。
  • 资源监控。指监控某个接口依赖的资源。
  • 基础监控。指监控对服务器本身的健康状况。
• 监控指标
  • 请求量。实时请求量用QPS（ Queries Per Second ），统计请求量用PV（ Page View），即一段时间内的用户访问量。
  • 响应时间。可以用一段时间内所调用的平均耗时反映请求的响应时间
  • 错误率。通常用一段时间内调用失败的次数占调用总次数的比率表示。
• 监控维度
  • 全局维度。从整体角度监控对象的请求量、平均耗时以及错误率。
  • 分机房维护。不同机房地域对同一监控对象的各种指标差异很大。
  • 单机维度。机器性能不同导致监控指标差异很大。
  • 时间维度。对同一监控对象、每天同一时刻进行监控。
  • 核心维度。根据业务重要性程度对监控对象进行分级。
• 监控系统原理。监控系统涉及四个环节：数据采集、数据传输、数据处理和数据展示。
• 数据采集。
• 两种常见方式：服务主动上报、代理收集。首要考虑的问题是采样率，即采集数据的频率。采样率决定了监控的实时性和精确度。但采样对系统本身的性能也会有一定影响。
  • 服务主动上报，通过在业务代码或服务框架里加入数据收集代码逻辑，在每一次服务调用完成后，主动上报服务的调用信息。
  • 代理收集，通过服务调用后把调用的详细信息记录在本地日志文件中，然后再通过代理去解析本地日志文件，然后再上报服务的调用信息。
• 数据传输。两种常用方式：UDP传输、Kafka传输。
  • UDP传输,数据采集后通过UDP协议与服务器建立连接，把数据发送到数据处理单元提供的服务器地址。
  • kafka传输，数据采集后擦送到指指定的Topic，然后数据处理单元再订阅对应的Topic。
• 数据传输格式。常见数据格式两种：二进制协议、文本协议。
• 数据处理。
  • 数据处理时对收集来的原始数据进行聚合存储。数据聚合存储通常有两个维度，接口维度聚合、机器维度聚合。接口维度聚合把数据按照接口名维度实时聚合，可得到每个接口的实时请求量、平均耗时等信息。机器维度聚合把数据按照调用的节点维度聚合，即可从单机维度查询每个接口的实时请求量、平均耗时等信息。
  • 数据处理存储。两种常用的数据库：索引数据库（如Elasticsearch）、时序数据库（如OpenTSDB）。
  • 数据展示。如曲线图、饼状图、格子图等。

追踪微服务调用

• 服务追踪的用途:

  • 优化系统瓶颈；
  • 优化链路调用；
  • 生成网络拓扑；
  • 透明数据传输。

• 参考 Dapper, a Large-Scale Distributed Systems Tracing Infrastructure http://bigbully.github.io/Dapper-translation/

• 调用链：通过全局唯一ID将分布在各个服务节点上的一次请求串联，ID记录请求信息、服务器路由、业务埋点数据信息。

• traceId用于表示某一次具体的请求ID，在PRC调用第一层网络生成，并往后传入每一次PRC调用。

• spanId用于标识一次PRC调用在分布式请求中的位置，如0.1、0.2、0.3、0.3.1、0.4。

• annotation用于业务自定义埋点数据，如用户UID。

• 样例报文：traceid=123456，spanId=0.1，appKey=A，method=B.method，start=103，duration=38。

• 追踪系统分为三层：数据采集、数据处理和数据展示。

• 数据采集层注意事务控制、分为CS、SR、SS、CR。（C client，S server，S send，R recieve）。

• 数据处理分为实时数据处理、离线数据处理。实时数据处理采用 Storm 或 Spark Streaming 。采用 OLTP 数据仓库，如 HBase 。离线数据处理采用 MapReduce 或 Spark ，存储用 Hive 。

• 数据展示一般使用调用链路图和调用拓扑图。调用链路图用于故障定位，调用拓扑图用于系统统计，如QPS、平均耗时。

服务治理手段

节点管理

• 注册中心主动摘除机制；如心跳监控，服务提供者定时的主动向注册中心汇报心跳。
• 服务消费者摘除机制；存活探测机制用在服务消费者这一端更合理。

负载均衡算法

• 随机算法;均匀算法，均匀调用量。
• 轮询算法；按照固定权重对服务节点轮询。
• 最少活跃调用算法；内存里维护连接数倒序排列，选择连接数最小节点发起调用。
• 一致性 Hash 算法。相同参数的请求发到同一服务节点。

服务路由

• 服务存在灰度发布的需求。类似尾号限行，针对特定人群测试。
• 多机房就近访问的需求。两种配种方式：1、静态配置，本地存放服务调用路由规则；2、动态配置，路由规则存放在注册中心。

服务容错

• FailOver :失败自动切换。失败或超时后自动从可用服务节点选择下一个节点重新发起调用。适合读请求的场景。
• FailBack :失败通知。调用错误后不再重试，根据失败信息决定后续执行策略；如非幂等的调用场景。
• FailCache :失败缓存。失败后隔断时间继续发起调用。
• FailFast ：快速失败。调用一次失败后不再重试。一般非核心业务的调用。
• 服务容错即服务调用失败自动恢复的手段。一般情况下对于幂等的调用，可以选择 FailOver 或者 FailCache，非幂等的调用可以选择 FailBack 或者 FailFast。

参考

• https://time.geekbang.org/column/115