【3.工程开发】-微服务建设相关

本篇只讲下仅仅因为微服务后，须要改变增长的东西。
可见：服务发现。拓扑。问题定位。监控。
可控：全链路故障演练/压测。配置中心/全流程部署（部署会频繁，扩缩容频繁）
本文服务发现
问题定位/拓扑：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代理接收消息，但不须要知道具体的网络拓扑。