微服务建设相关

本篇只讲下仅仅由于微服务后，需要改变增加的东西。

可见：服务发现。拓扑。问题定位。监控。

可控：全链路故障演练/压测。配置中心/全流程部署（部署会频繁，扩缩容频繁）

本文服务发现

问题定位/拓扑： https://segmentfault.com/a/11...

全流程部署/配置中心/监控： https://segmentfault.com/a/11...

全链路故障演练/压测： https://segmentfault.com/a/11...

更多工程： https://segmentfault.com/a/11...

服务发现过程

服务发现和注册文章： https://www.nginx.com/blog/se... 。这里只讲下公司的应用方案

服务发现

背景：替换原有Thrift要配置所有IP

一个新服务，人工服务注册：创建一个服务发现节点，路由规则配置；流量调度；人工服务摘除；

1.调用方

每台机器上有agent.sdk.兜底文件，实时文件，访问disf先本地实时文件，兜底ip

• 兜底文件的产生：
  1.1代码扫描 与平台配置结果比对，校验
  1.2.编译后生成output/__naming__/__self.json
  1.3.odin构建到disf平台取配置作为兜底文件
  2.部署包根据部署集群，部署自己集群的__naming__/兜底
  ps:打包时会额外做：第一次打包生成__naming__目录,兜底包含所有ip，更新推方式更改扫描检查配置,第二次生成.deploy (部署节点信息,odin根据不同节点打包生成每个集群的ip)
• 实时文件产生
  agent启动时。odin部署系统上线中，启动前会上报集群。到disf-agent。取配置。生成到/home/xiaoju/.service/disf中
  配置变更时。在平台操作，文件直接推送到agent。
  常态运行时，agent定期扫描文件版本上报平台，平台校验后下发版本异常文件到agent
  
• agent与conf长连接（grpc）
  交互过
  
• 自动摘除/发现
  摘除：php类点多服务公用一个端口，一个unregester会导致所有都。上线时会大量的unregester或者exist出现抖动,机器挂掉不会自动摘除，只是返回一个ip列表（只有服务发现。dirpc负责负载均衡，健康检查，自动摘除）
  发现：不自动发现，起了服务不一定要正式到线上

xrpc

功能

内置服务发现 （直接获取endpoint等）

支持多语言多协议

标准化日志输出&监控，标准化服务调用规范（统一提供sdk）

容错机制（故障摘除，过载保护，负载均衡）

代码

1.获取endpoint信息，生成sign等初始

2.server管理服务器，负载均衡，过载保护

以逻辑机房为管理力度，minHealthyRatio等配置，ip/port列表，状态，balancer

• filter 白名单，黑名单，是否跨机房
• 故障摘除
  对节点采取投票，访问失败+1，访问成功-1，票数最低为0；每个节点的票数代表了其健康度，值越大说明越不健康，越小越健康； 投票数超过阈值即被认定为不健康，默认指导配置为10，即一个节点的投票数大于10则被认定为不健康。
  流量调度只在健康节点进行选择，即非健康节点则认为被故障摘除。
  另外节点被标记为非健康的时间超过冷却时长后，下次重新生成健康列表时，则将其当作健康节点对待，即故障恢复。默认指导值为60s。

• 过载保护（只是防止可用节点太少，可用节点被打挂）

  防止大量节点被标记为非健康后，流量打到集中的下游上，设置一个最低健康比例，当健康节点数的占比低于最低比例时，按最低比例挑选健康度最好的节点，构建健康列表，即最小可用度。

  随着业务的不断变迁，理想情况下最小可用度要能根据全链路容量压测进行自动适应。但根据滴滴目前的现状，资源管理还比较粗放，前期这个值可以设置的相对保守。当前最小可用度默认指导配置为0.67，即保证至少有2/3的节点可用，也即最多可剔除对1/3故障节点的访问。

• 负载均衡
  只支持在健康节点之间挑选，当最小可用度不足时，通过非健康节点补充。目前已支持Random、Hash两种调度策略，RR暂不支持。

3.send

4.根据是否成功 vote php是记到apcu(缓存中),不支持就无法投票。这个各自调用方投票记录在不同地方，各自判断，各自摘除。无法相互获取到其他的投票结果。

5.记录log

servicemesh概述

架构上分为数据平面和控制平面两个部分，其中数据平面负责代理微服务之间的通信，具体包含RPC通信、服务发现、负载均衡、降级熔断、限流容错等，数据平面可以认为是微服务框架的通信和服务治理能力独立而成的一个单独的语言无关的进程，并且更注重通用性和扩展性，在Service Mesh中，不再将数据平面代理视为一个个孤立的组件，而是将这些代理连接在一起形成一个全局的分布式网络；控制平面负责对数据平面进行管理，定义服务发现、路由、流量控制、遥测统计等策略，这些策略可以是全局的，也可以通过配置某个数据平面节点单独指定，控制平面通过一定的机制将策略下发到各个数据平面节点，数据平面节点在通信时会使用这些策略。

Istio

以Envoy为基础，将Envoy作为默认的数据平面，同时提供强大的控制平面能力。

控制：

Pilot、Mixer和Security是Istio 的3大核心组件，分别负责Istio配置管理、策略和遥测以及通信安全的实现。

pilot:提供通用的配置管理能力，保证不同平台、不同环境下的配置均能够通过一致的方式对Envoy进行配置和下方,负责Envoy的生命周期管理，启动Envoy，然后监控Envoy的运行状态.启动，调度到其他节点等

mixer: 收集遥测统计相关的数据和指标，可以对服务进行全方位的监控,策略控制:对于一些核心资源，需要通过一定的策略，在不同消费服务以及服务的不同实例中进行分配，保证资源能够按照预期进行管理.

数据envoy

是一个用 C++ 编写的云原生高性能边缘代理、中间代理和服务代理，作为专门为微服务架构设计的通信总线。

Envoy作为一个独立进程，设计为和每个应用程序一块运行，所有的 Envoy 形成一个透明的通信网格，每个应用程序发送消息到本地Envoy代理或从本地Envoy代理接收消息，但不需要知道具体的网络拓扑。