从0开始学微服务学习笔记

版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/sinat_32197439/article/details/84105434

1到底什么是微服务

• 单体应用
  • 部署效率低
  • 团队协作开发成本高
  • 系统高可用性差
  • 线上发布变慢
• 什么是服务化
  • 单体应用中通过jar包依赖产生的本地方法调用，改成通过RPC远程方法调用
• 什么是微服务
  • 服务拆分力度更细
  • 服务独立部署
  • 服务独立维护
  • 服务治理能力要求高
    #2单体走向微服务#
• 单体迁移到微服务遇到的问题？
  • 服务如何定义
  • 服务如何发布与订阅
  • 服务如何监控
  • 服务如何治理
  • 故障如何定位
    #3微服务架构#
• 基本组件
  • 服务描述
    • 服务如何对外描述？
    • 服务名叫什么？
    • 调用这个服务需要提供哪些信息？
    • 调用这个服务返回的结果是什么格式的？
    • 该如何解析？
  • 注册中心
    • 解决服务的发布与订阅
      • 提供者登记
      • 消费者获取地址 发请求
  • 服务框架
    • 服务通信采用什么协议？
    • 数据传输采用什么方式？
    • 数据压缩采用什么格式？
  • 服务监控
    • 指标收集
    • 数据处理
    • 数据展示
  • 服务追踪
    • 服务调用情况
  • 服务治理
    • 单机故障
    • 单IDC(互联网数据中心)故障
    • 依赖服务不可用
      #4如何发布与引用服务#
• 方式
  • restful api
    • 跨语言
  • xml
  • idl文件
    • 跨语言平台调用
    • Thrift协议
    • gRPC协议
      #5如何注册与发现服务#
• 注册中心原理
  • 服务提供者RPC server
  • 服务消费者 RPC Client
  • 服务注册中心 Registry
• 注册中心实现方式
  • 注册中心API
    • 服务注册接口
    • 服务反注册接口
    • 心跳汇报接口
    • 服务订阅接口
    • 服务变更查询接口
  • 集群部署
    • 集群部署保证高可用性
    • 分布式一致性保证数据一致性
  • 目录存储
  • 服务健康状态监测
  • 服务状态变更通知
  • 白名单机制
    #6如何实现RPC远程服务调用#
• 服务消费者
  • 客户端
• 服务提供者
  • 服务端
• 调用过程
  • 成一次 RPC 调用，就必须先建立网络连接。建立连接后，双方还必须按照某种约定的协议进行网络通信，这个协议就是通信协议。双方能够正常通信后，服务端接收到请求时，需要以某种方式进行处理，处理成功后，把请求结果返回给客户端。为了减少传输的数据大小，还要对数据进行压缩，也就是对数据进行序列化
• 客户端和服务端如何建立网络连接？
  • HTTP通信
    • 基于TCP/IP协议
  • Socket通信
    • 运行于客户端 clientSocket
    • 运行于服务端 serverSocket
    • 步骤
      • 服务器监听
        • serverSocket bind()绑定端口，调用listen()实时监控网络状况，等待客户端的连接请求
      • 客户端请求
        • clientSocket connect()函数 向serverSocket绑定的地址端口发起请求
      • 连接确认
        • 服务端监听或收到客户端的连接请求时，调用accept()响应客户端请求，并建立连接
      • 数据传输
        • 建立连接后，客户端调用send() 服务端调用receive()函数，服务端处理完请求后，服务端调用send()客户端调用recevice()得到返回结果。
    • 异常情况
      • 链路存活检测
        • 客户端定时发送心跳检测给服务端，连续N次或者超出规定时间没有回复则认为链路已经失效
      • 断连重试
        • 等待固定时间发起重连
• 服务端如何处理请求？
  • 同步阻塞BIO
  • 同步非阻塞NIO
  • 异步非阻塞AIO
  • 建议采取业界开源框架 Netty Mina
• 数据传输采用什么协议？
  • Http协议
  • Dubbo协议
• 数据该如何序列化和反序列化？
  • 编码与解码就是序列化与反序列化
  • 常见序列化方式
    • 文本类
      • xml
      • json
    • 二进制
      • PB
      • Thrift
  • 使用考虑因素
    • 支持数据结构的丰富程度
    • 跨语言支持
    • 性能{压缩比与序列化速度}
      #7如何监控微服务调用#
• 监控的对象是什么？
  • 用户端监控
  • 接口监控
  • 资源监控
  • 基础监控
• 具体监控哪些指标？
  • 请求量
    • 实时请求量QPS 每秒查询次数
    • 统计请求量PV 一段时间内用户访问量
  • 响应时间
    • P99=500ms 意思是 99% 的请求响应时间在500ms以内，它代表了请求的服务质量，即 SLA。
  • 错误率
    • 一段时间内调用失败的次数占调用总次数的比率来衡量
• 从哪些维度进行监控？
  • 全局维度
  • 分机房维度
  • 单机维度
  • 时间维度
  • 核心维度
    • 核心与非核心部署隔离，分开监控
• 监控系统原理
  • 数据采集
    • 分类
      • 服务主动上报(代码中加入收集逻辑)
      • 代理收集(日志文件–>解析–>上报)
    • 考虑点
      • 采样率 采集数据的频率
      • 动态采集
  • 数据传输
    • 传输方式
      • UDP
      • Kafka
    • 数据格式十分重要
      • 二进制协议
        • 最常用的就是 PB 对象，它的优点是高压缩比和高性能，可以减少传输带宽并
          且序列化和反序列化效率特别高
      • 文本协议
        • 最常用的就是 JSON 字符串，它的优点是可读性好，但相比于 PB 对象，传输占
          用带宽高，并且解析性能也要差一些
  • 数据处理
    • 数据聚合维度
      • 接口维度
      • 机器维度
    • 持久化数据库
      • 索引数据库 ES
      • 时序数据库 OpenTSDB
  • 数据展示
    • Dashboard
  • 扩展
    • skywalking是一款优秀的支持java语言的监控系统
    • 错误率是个很重要的业务指标
      #8如何追踪微服务调用#
• 服务追踪的作用
  • 优化系统瓶颈
  • 优化链路调用
  • 生成网络拓扑
  • 透明传输数据
• 原理
  • 调用链：通过全局ID将分布在各个服务节点的同一次请求串联，还原所有调用关系
  • 基本概念
    • traceId
      • 标识某一次具体请求ID
    • spanId
      • 标识一次RPC调用在分布式请求中的位置{0 0.1 0.1.1 0.2}
    • annonation
      • 业务自定义埋点数据
• 服务追踪系统实现
  • 数据采集层
    • 数据埋点
      • cs
      • sr
      • ss
      • cr
  • 数据处理层
    • 实时数据处理
      • 采用Storm,调用链路数据的实时查询主要是通过Hbase，使用traceID作为RowKey，能天然的把一整条调用链聚合在一起，提高查询效率。
    • 离线数据处理
      • Mapreduce Spark批处理，存储使用Hive
  • 数据展示层
    • 调用链路图
    • 调用拓扑图
      #9微服务的治理手段有哪些？#
• 常用服务治理手段
  • 节点管理
    • 注册中心主动摘除机制
      • 服务提供者心跳汇报，超时摘除
    • 服务消费者摘除机制
      • 如果服务消费者调用服务提供者节点失败，就将这个节点从内存中保存的可用服务提供者节点列表中移除。
  • 负载均衡
    • 随机算法
      • 均匀
    • 轮询算法
      • 权重
    • 最少活跃调用算法
      • 性能理论上最优，选择链接数最小的
    • 一致性hash算法
      • 相同参数的请求总是发到同一服务节点
  • 服务路由
    • 路由规则
      • 就是通过一定的规则如条件表达式或者正则表达式来限定服务节点的选择范围
      • 原因
        • 业务存在灰度发布的需求
        • 多机房就近访问的需求
          • 一般可以通过 IP 段规则来控制访问，在选择服务节点时，优先选择同一 IP 段的节点
      • 路由规则配置
        • 静态配置
          • 消费者本地存放调用的路由规则
        • 动态配置
          • 路由规则存在于注册中心，服务消费者请求注册中心来更新配置
  • 服务容错
    • FailOver
      • 失败自动切换
      • 幂等
    • FailBack
      • 失败通知，根据返回消息决定策略
    • FailCache
      • 失败缓存 隔一段时间发起请求
      • 幂等
    • FailFast
      • 快速失败 非核心业务
        #10Dubbo框架里的微服务组件#
• Dubbo
  • 服务的发布与引用
  • 服务的注册与发现
  • 服务调用
  • 服务监控
  • 服务治理
    #11服务发布和引用的实践#
• XML 配置方式的服务发布和引用流程
  • 服务提供者定义接口
  • 服务提供者发布接口
  • 服务消费者引用接口
• 坑
  • 服务发布预定义配置
  • 服务引用定义配置
  • 服务配置升级
    #12如何将注册中心落地？#
• 注册中心如何存储服务信息
  • 服务信息 Cluster
    • 节点信息
    • 请求失败重试次数
    • 结果是否压缩
  • 分组 Node
    • 机房
    • 核心与非核心
    • 测试环境与线上环境
  • 服务名 Service
• 注册中心是如何工作的
  • 服务提供者注册流程
    • 首先查看要注册的节点是否在白名单内？如果不在就抛出异常，在的话继续下一步。
    • 其次要查看注册的 Cluster（服务的接口名）是否存在？如果不存在就抛出异常，存在的话继续
      下一步。
    • 然后要检查 Service（服务的分组）是否存在？如果不存在则抛出异常，存在的话继续下一步。
    • 最后将节点信息添加到对应的 Service 和 Cluster 下面的存储中
  • 服务提供者反注册流程
    • 查看服务的分组是否存在
    • 查看服务的节点是否存在
    • 删除存储在service和cluster中的节点信息
    • 更新Cluster的sign值
  • 服务消费者查询流程
    • 本机内存中查找
    • 本地快照中查找
  • 服务消费者订阅变更流程
    • 本地保留Cluster的Sign
    • 隔断时间调用getSign()对比 不一致拉取最新的并更新
• 注册与发现的几个问题

  • 多注册中心

    • 服务消费者要具备在启动时，能够从多个注册中心订阅服务
    • 服务提供者在启动的时候，要能够同时向多个注册中心注册服务

  • 并行订阅服务

  • 批量反注册服务

    • 僵尸节点

  • 服务变更信息增量更新

    • 增量更新方式 注册中心只返回变化的那部分节点信息，尤其在只有少数节点信息变更时
      #13开源服务注册中心如何选型？#
• 主流解决方案
  • 应用内注册与发现
    • SDK
    • Eureka
      • Eureka Server：注册中心的服务端，实现了服务信息注册、存储以及查询等功能
      • 服务端的 Eureka Client：集成在服务端的注册中心 SDK，服务提供者通过调用 SDK，实现服务
        注册、反注册等功能
      • 客户端的 Eureka Client：集成在客户端的注册中心 SDK，服务消费者通过调用 SDK，实现服务
        订阅、服务更新等功能
  • 应用外注册与发现
    • Consul
      • Consul:注册中心的服务端，实现服务注册信息的存储，并提供注册和发现服务
      • Registrator:一个开源的第三方服务管理器项目，它通过监听服务部署的 Docker 实例是否存
        活，来负责服务提供者的注册和销毁
      • Consul Template:定时从注册中心服务端获取最新的服务提供者节点列表并刷新 LB 配置（比
        如 Nginx 的 upstream），这样服务消费者就通过访问 Nginx 就可以获取最新的服务提供者信息
• 考虑因素
  • 高可用性
    • 集群部署
    • 多IDC部署
  • 数据一致性
    • CAP理论
      • CP
        • Zookeeper
      • AP
        • Eureka
        • 服务注册中心对可用性的要求高于一致性 只要保证最终的一致性就好
          #14开源RPC框架如何选型#
• 分类
  • 特定语言平台绑定
    • Dubbo java
      • 4大角色
        • 服务消费者
        • 服务提供者
        • 注册中心
        • 监控系统
      • Dubbo SDK
      • 调用框架
        • 通信框架
          • Netty
        • 通信协议
          • 私有Dubbo协议，还支持 RMI 协议、Hession 协议、HTTP 协议、Thrift 协议等
        • 序列化与反序列化
          • Dubbo、Hession、JSON、Kryo、FST
    • Motan java
      • 功能模块
        • register
        • protocol
        • serialize
        • transport
        • cluster
    • Tars c++
    • spring cloud java
  • 平台语言无关
    • gRPC
      • 通信协议采用HTTP2
      • IDL使用ProtoBuf
      • 多语言支持
    • Thrift
      #15如何搭建一个可靠的监控系统#
• 实现方案
  • 集中式日志解决方案
    • ELK Elasticsearch、Logstash、Kibana 三个开源软件产品首字母的缩写
      • Logstash 数据收集与传输
      • ElasticSearch 数据处理
      • Kibana 数据展示
      • Beats (发送到LogStash)
        • 数据源
          • Packetbeat： 网络数据流量
          • Topbeat： 收集系统进程 cpu 内存使用情况
          • Filebeat： 收集文件数据
          • Winlogbeat： 收集Windows 日志 数据
  • TICK 时序数据库解决方案
    • Graphite
      • Carbon
      • Whisper
      • Graphite-Web
    • TICK
      • Telegraf、InfluxDB、Chronograf、Kapacitor 四个软件首字母的缩写
    • Prometheus
      #16如何搭建一套适合你的服务追踪系统？#
• 实现
  • 埋点数据收集
  • 实时数据传输
  • 链路数据展示
• 实现方案
  • OpenZipKin
    • Collector
    • Storage
    • API
    • UI
  • Pinpoint
    • Pinpoint Agent
    • Pinpoint Collector
    • HBase Storage
    • Pinpoint Web UI
• 选型对比
  • 埋点探针支持平台的广泛性
  • 系统集成的难易程度
  • 调用链路的精准度
    #17如何识别服务节点是否存活#
• Zookeeper管理注册节点
  • 注册中心摘除机制
  • 网络频繁抖动会可能会摘除节点
• 解决方案
  • 心跳开关保护机制
    • 设置开关
  • 服务节点摘除保护机制
    • 设置阈值比例 不能摘除超过阈值比例的节点 20%
  • 静态注册中心
    • 心跳机制设置在服务消费者端 存储某个服务的可用节点
      #18如何使用负载均衡算法？#
• 引入原因
  • 考虑调用的均匀性
  • 考虑调用的性能
• 常见算法
  • 随机算法
  • 轮询算法
  • 加权轮询算法
  • 最少活跃连接算法
  • 一致性hash算法
  • 自适应最优选择算法
    • 比重
    • 时长 1min
      #19如何使用服务路由#
• 服务路由
  • 服务消费者在发起服务调用时，必须根据特定的规则来选择服务节点，从而满足某些特定的需求
• 应用场景
  • 分组调用
  • 灰度发布(金丝雀部署)
  • 流量切换
  • 读写分离
• 服务路由的规则
  • 条件路由
  • 脚本路由
• 服务路由的获取方式
  • 本地配置
    • 存储服务消费者本地
  • 配置中心管理
  • 动态下发
    • 服务治理 数据中心出问题 切换消费者访问IDC
      #20服务端出现故障时该如何应对？#
• 故障分类
  • 集群故障
    • 限流
      • QPS
      • 工作线程数
    • 降级
      • 动态开关
        • 新增的业务
        • 依赖的服务或者资源
      • 一级 二级 三级 依次变大
  • 单IDC故障
    • 流量切换
      • 基于DNS解析的流量切换
      • 基于RPC分组的流量切换
  • 单机故障
    • 最频繁
    • 自动重启 采集 接口耗时阈值
    • 重启比例 不超过10%
      #21 服务调用失败时有哪些处理手段？#
• 调用失败处理手段
  • 超时
  • 重试
  • 双发
    • 备份请求
  • 熔断
    • Hystrix断路器
      • 关闭
      • 打开
      • 半打开
    • 滑动窗口
      #22 如何管理服务配置？#
• 如何管理
  • 本地配置
    • 把配置当作代码同等看待，随着应用程序代码一起发布
    • 把配置都抽离到单独的配置文件当中，使配置与代码分离
  • 配置中心
    • 存储结构
      • Group {K V}
    • 配置注册功能
      • 对外提供接口
    • 配置反注册功能
      • 对外提供接口
    • 配置查看功能
    • 配置变更订阅功能
• 应用场景
  • 资源服务化
  • 业务动态降级
  • 分组流量切换
• 开源配置中心与选型
  • Spring cloud config
    • git
    • 手动拉取
  • DisConf
  • Apollo
    • 基于spring boot
      #23 如何搭建微服务治理平台？#
• 基本功能
  • 与服务打交道的统一入口
  • 服务管理
    • 服务上下线
    • 节点添加/删除
    • 服务查询
    • 服务节点查询
  • 服务治理
    • 限流
    • 降级
    • 切流量(IDC)
  • 服务监控
    • 整体监控
    • 某一具体服务监控
  • 问题定位
    • 服务监控发现
    • 追踪具体某一次请求定位
  • 日志查询
    • ELK
  • 服务运维
    • 发布部署
    • 扩缩容
• 如何搭建微服务治理平台
  • Web Portal层
    • 前端展示
    • 服务管理界面
    • 服务治理界面
    • 服务监控界面
    • 服务运维界面
  • Api层
  • 数据存储DB层
    • 用户权限
    • 操作记录
    • 元数据
      #24 微服务架构该如何落地？#
• 如何落地
  • 组建合适的技术团队
  • 从一个案例入手
  • 做好技术取舍
  • 采用DevOps
  • 统一微服务治理平台
    #25 微服务为什么要容器化#
• 微服务为什么要容器化
  • 带来的问题
  • 解决本地 测试 生产的环境隔离
  • Docker容器
    • 封装软件运行环境
    • 本质是linux操作系统的进程
    • Docker镜像
      • 不仅打包应用程序还打包其所有依赖的环境，甚至可以包含整个操作系统
      • 解决环境不一致的问题
    • 提高测试运维的工作量
• 实践
  • 镜像分层
    #26 微服务容器化运维：镜像仓库和资源调度#
• 微服务容器化的运维
  • 面向容器的新型运维平台 容器运维平台
  • 组成
    • 镜像仓库
      • 存储镜像存储与访问
      • Docker镜像仓库地址 满足个人或小团队开发测试
      • 自己搭建
        • 权限控制
          • 登陆访问
          • 项目划分
        • 镜像同步
          • 一主多从 主从复制 树型
          • P2P 蜻蜓
        • 高可用性
          • 部署在多个IDC
    • 资源调度
      • 如何对接各个不同的集群，统一管理来自不同集群的机器权限管理、成本核算以及环境初始化等操作
      • 服务部署的集群
        • 物理机集群
          • 集群-服务池-服务器
        • 虚拟机集群
          • OpenStack
        • 公有云集群
          • 快速灵活
    • 容器调度
    • 服务编排
      #27 微服务容器化运维：容器调度和服务编排#
• 容器调度
  • 调度系统
    • Docker Swarm
    • Google Kubernetes
  • 解决问题
    • 主机过滤
      • 存活过滤
      • 硬件过滤
    • 调度策略
      • 解决容器创建时选择哪些主机最合适的问题，给主机打分
      • Swarm
        • spread,选择资源使用最少的节点 出现故障 影响的主机少
        • binpack,选择资源使用最多的节点 节省资源避免资源碎片化
      • 常见场景
        • 各主机的配置基本相同，并且使用也比较简单，一台主机上只创建一个容器。这样的话，每次创建容器的时候，直接从还没有创建过容器的主机当中随机选择一台就可以了
        • 在某些在线、离线业务混布的场景下，为了达到主机资源使用率最高的目标，需要综合考量容器中跑的任务的特点，比如在线业务主要使用 CPU 资源，而离线业务主要使用磁盘和 I/O资源，这两种业务的容器大部分情况下适合混跑在一起
        • 还有一种业务场景，主机上的资源都是充足的，每个容器只要划定了所用的资源限制，理论上跑在一起是没有问题的，但是某些时候会出现对每个资源的抢占，比如都是 CPU 密集型或者 I/O 密集型的业务就不适合容器混布在一台主机上
• 容器编排
  • 服务依赖
    • Docker Compose yaml
  • 服务发现
    • 基于Nginx的服务发现
      • HTTP服务
    • 基于注册中心的服务发现
      • RPC服务
  • 自动扩缩容
    • 根据容器的 CPU 负载情况来设置一个扩缩容的容器数量或者比例，比如可以设定容器的 CPU 使用率不超过 50%，一旦超过这个使用率就扩容一倍的机器
      #28 微服务容器化运维：微博容器运维平台DCP#
• 整体架构
  • 基础设施层
    • 存放容器镜像的镜像仓库 核心基础组件
    • 监控服务的监控中心
    • 容量评估系统以及容器创建后，
    • 服务发现组件
  • 主机层
    • 完成资源的调度
    • 主机创建
    • 成本管理
    • 配置初始化
  • 调度层
    • 在可用主机上创建容器
  • 编排层
    • 对服务进行整合以对外提供服务
    • 服务依赖
    • 服务发现
    • 自动扩缩容
      #29 微服务如何实现DevOps？#
• 什么是 DevOps？
  • CI 持续集成
    • 开发完成代码开发后，能自动地进行代码检查、单元测试、打包部署到测试环境，进行集成测试，跑自动化测试用例
  • CD 持续交付
    • 代码测试通过后，能自动部署到类生产环境中进行集成测试，测试通过后再进行小流量的灰度验证，验证通过后代码就达到线上发布的要求了，就可以把代码自动部署到线上。
• 实践方案
  • Jenkins
  • GitLab
    • gitlab-ci.yml
    • 持续集成
      • 代码检查
      • 单元测试
      • 持续集成 Kubernetes
    • 持续交付
      • 目的 保证最新代码在生产环境正常运行
      • 如何从线上生产环境中摘除两个节点
      • 如何观察服务是否正常
    • 持续部署
      • 把在类生产环境下运行通过的代码自动的发布到线上所有节点中去
        #30 如何做好微服务容量规划#
• 复杂度
  • 服务数量众多
  • 服务接口变现差异巨大
  • 服务部署的集群规模大小不一
  • 服务之间存在依赖关系
• 容量规划系统
  • 作用
    • 根据微服务部署集群的最大容量和实际运行的负荷，来决定微服务是否扩缩容及扩缩机器数量
  • 关键点
    • 如何做好容量评估
      • 压测
        • 选择合适的压测指标
          • 选择系统类指标
          • 选择服务类指标
            • 接口高于某个阈值的比例
        • 压测获取单机最大容量
          • 单机压测
            • 日志回放
            • TCP copy
          • 集群压测(更合理)
            • 不断摘除线上集群节点，增加单机的流量
            • 区间加权
        • 实时获取集群的运行负荷
    • 如何做好调度决策
      • 水位线
      • 扩容
        • by数量
        • by比例
      • 缩容
        • 隔时间 按比例缩
        • 采集5个点 3个点满足 缩
          #31 微服务多机房部署实践#
• 多机房负载均衡
  • 就近原则
  • 按需分配流量
• 多机房数据同步
  • 数据存储
    • 缓存层
    • 数据库层
  • 主从机房架构
  • 独立机房架构
    • WMB消息同步组件
      • reship
        • 负责把本机的写请求分发给一部分其他机房
      • collector
        • 负责从别的机房读取写请求，然后把请求给本机房的处理机
      • MCQ消息队列
      • RPC调用
• 多机房数据一致性
  • 消息对账机制
    • 唯一 requestId
      #32 微服务混合云部署实践#
• 跨云服务如何实现负载均衡？
  • SLB和Nginx
• 跨云服务如何实现数据同步？
  • 私有云与公有云直接的网络隔离
    • VPN网络或者专线
  • 数据库能否上云
    • 数据的隐私性
• 跨云服务如何实现容器运维？
  • 跨云的主机管理
    • DCP中采取主机 - 服务池 - 集群”模式
  • 跨云服务实现
  • 跨云弹性扩容
    • DNS层
    • Nginx层
  • 跨云服务编排
    • 依赖
      #33 下一代微服务架构Service Mesh#
• 服务网格
• Service Mesh
  • 是一种新型的用于处理服务与服务之间通信的技术
  • 以轻量级的网络代理的方式与应用的代码部署在一起
• 原因
  • 跨语言调用的需要
  • 微服务容器化，云原生应用服务治理的需要
• 两个实现点
  • 轻量级的网络代理叫 SideCar，转发服务之间的调用
  • 基于 SideCar 的服务治理也被叫作Control Plane，向 SideCar 发送各种指令，以完成各种服务治理功能
• 实现原理
• SideCar
  - 服务消费者A–>Side CarA(正向代理)—>Side CarB(反向代理)—>服务提供者B
  • 关键点
    • 服务消费者发出的请求如何通过正向代理转发以及服务提供者收到的请求如何通过反向代理转发
  • 实现
    • 基于 iptables 的网络拦截
    • 采用协议转换的方式
• Control Plane
  • 服务发现
  • 负载均衡
  • 请求路由
  • 故障处理
  • 安全认证
  • 监控上报
    #34 Istio：Service Mesh的代表产品#
• 整体架构
  • Proxy
    • 应用间的调用通过proxy转发
    • 采用Envoy
    • 特征
      • 性能损耗低
      • 可扩展性高
      • 动态可配置
  • Control Plane
    • 与proxy通信
    • 基本组件
      • Pilot
        • 流量控制
        • Rules API
        • Envoy api
        • 抽象模型层
        • 平台适配层
        • 如何实现流量控制
          • 服务发现与负载均衡
          • 请求路由
          • 超市重试
          • 故障注入
      • Mixer
        • 策略控制yaml
          • 服务调用进行速率限制
          • 服务调用进行访问控制
        • 日志收集
        • 两级缓存结构
          • Proxy 端的本地缓存
          • Mixer 的本地缓存
      • Citadel
        • 保证服务之间访问的安全
          • Citadel 里存储了密钥和证书
          • 通过 Pilot 把授权策略和安全命名信息分发给 Proxy
          • Proxy 与 Proxy 之间的调用使用双向 TLS 认证来保证服务调用的安全
          • 由 Mixer 来管理授权和审计
            #35 微博Service Mesh实践之路(上)#
• 问题
  • 中间链路损耗大
  • 全链路扩容难
  • 混合云部署难
• Yar协议
  #36 微博Service Mesh实践之路(下)#
• Weibo Mesh技术细节
  • Motan-go Agent
    • SideCar
    • Filter Chain
    • High Available
    • Load Banlance
      • 负载均衡 集成Random算法
    • EndPoint
      • 封装请求
    • Serialize
      • 序列化模式
    • Server模块
      • 实现不同类型Server
  • 统一服务治理中心
    • 服务注册与发现
    • 监控上报
    • 动态流量切换与降级
    • 自动扩缩容
  • 收益
    • 跨语言服务调用
    • 统一服务治理能力
    • 业务无感知的持续功能更新能力