共计 2545 个字符，预计需要花费 7 分钟才能阅读完成。
本篇只讲下仅仅由于微服务后，需要改变增加的东西。
可见：服务发现。拓扑。问题定位。监控。
可控：全链路故障演练 / 压测。配置中心 / 全流程部署（部署会频繁，扩缩容频繁）
本文服务发现
问题定位 / 拓扑：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 代理接收消息，但不需要知道具体的网络拓扑。
