ASPIRE

服务治理相关资料收集/学习

=Start=

缘由：

这几年微服务的概念比较火，在看了一些文章、检索了一些资料后发现，微服务和SOA、服务治理、配置管理等概念或实现联系紧密，所以要想较为深入细致的理解微服务的概念，先学习它的前置概念知识很有必要，在这里，我先整理一下检索到的「服务治理」相关资料，方便后续参考学习。

正文：

参考解答：

服务化之后，随着规模的扩大，一定要考虑“服务治理”，否则服务之间的依赖关系会乱成麻。

参考链接：

=END=

Docker

,
, ,

《 “服务治理相关资料收集/学习” 》 有 17 条评论

  4. 后端技能树修炼：CAP 定理
    https://mp.weixin.qq.com/s/BlNIXtviCGYPhNpg6mihJg
    `
    CAP 定理表明，任何分布式计算机系统只能同时满足一致性（Consistency），可用性（Availability）和分区容错性（Partition Tolerance）三者中的任意两个。

    由于任何分布式系统任何时候只能同时满足 CAP 定理中的两个属性，因此，我们可以根据这一点将分布式系统分为三类：
    CA 系统：数据在所有节点之间是一致的，我们也可以从系统的任意节点中进行读和写，但节点间通信网络不能出故障
    　　MySQL
    　　MSSQL
    CP 系统：数据在所有节点之间是一致的，而且能够容忍分区出错并防止数据不同步
    　　Google BigTable
    　　Hbase
    　　MongoDB
    　　Redis
    AP 系统：系统中所有节点总是在线的，但无法保证获取到的是最新数据，但只要网络正常，节点间就会进行同步
    　　Cassandra
    　　Voldemort
    　　Dynamo DB
    　　CouchDB
    　　SimpleDB

    要强调一点，CAP 定理关注的是对数据的读写操作，而不是分布式系统的所有功能，它要求分布式系统节点间是互相连接且有数据共享的，例如 Memcache 的集群中节点相互间没有连接和数据共享，因此不是 CAP 定理讨论的对象，同理 ZooKeeper 的选举机制也不是 CAP 探讨的对象。
    `

    回复

  5. 分布式中几种服务注册与发现组件的原理与比较
    http://blueskykong.com/2018/10/05/discovery/
    `
    Eureka、Consul、Zookeeper的基本原理与比较。

    在一个分布式系统中，服务注册与发现组件主要解决两个问题：服务注册和服务发现。
    · 服务注册：服务实例将自身服务信息注册到注册中心。这部分服务信息包括服务所在主机IP和提供服务的Port，以及暴露服务自身状态以及访问协议等信息。
    · 服务发现：服务实例请求注册中心获取所依赖服务信息。服务实例通过注册中心，获取到注册到其中的服务实例的信息，通过这些信息去请求它们提供的服务。

    除此之外，服务注册与发现需要关注监控服务实例运行状态、负载均衡等问题。
    · 监控：微服务应用中，服务处于动态变化的情况，需要一定机制处理无效的服务实例。一般来讲，服务实例与注册中心在注册后通过心跳的方式维系联系，一旦心跳缺少，对应的服务实例会被注册中心剔除。
    · 负载均衡：同一服务可能同时存在多个实例，需要正确处理对该服务的负载均衡。
    `

    回复

  6. CAP 一致性协议及应用解析
    https://mp.weixin.qq.com/s/26x8O1bRzurl84e3nM6TTA
    `
    一、一致性
    1.1 CAP 理论
    C 一致性：分布式环境中，一致性是指多个副本之间，在同一时刻能否有同样的值
    A 可用性：系统提供的服务必须一直处于可用的状态。即使集群中一部分节点故障。
    P 分区容错性：系统在遇到节点故障，或者网络分区时，任然能对外提供一致性和可用性的服务。以实际效果而言，分区相当于通信的时限要求。系统如果不能在一定实现内达成数据一致性，也就意味着发生了分区的情况。必须就当前操作在 C 和 A 之前作出选择

    1.2 CAP不能同时满足的证明
    略

    1.3 常见场景
    CA without P： 在分布式环境中，P 是不可避免的，天灾（某软公司的Azure被雷劈劈中）人祸（某里公司 A 和 B 机房之间的光缆被挖断）都能导致P。
    CP without A：相当于每个写请求都须在Server之前强一致。P (分区)会导致同步时间无限延长。这个是可以保证的。例如数据库的分布式事务，两阶段提交，三阶段提交等。
    AP without C： 当网络分区发生，A 和 B 集群失去联系。为了保证高可用，系统在写入时，系统写入部分节点就会返回成功，这会导致在一定时间之内，客户端从不同的机器上面读取到的是数据是不一样的。例如 redis 主从异步复制架构，当 master down 掉，系统会切换到 slave，由于是异步复制，salve 不是最新的数据，会导致一致性的问题。

    二、一致性协议
    2.1 两阶段提交协议（2PC）
    2.2 三阶段提交协议（3PC）
    2.3 Paxos协议
    2.4 Raft协议

    三、Zookeeper 原理
    3.1 概述
    3.2 基本概念
    3.3 常见的误区
    3.4 选举同步过程
    3.5 同步的过程

    四、使用 Raft + RocksDB 有赞分布式 KV 存储服务

    五、总结
    本文从三个方面介绍了一致性，首先是描述分布架构中的核心理论-CAP，以及其简单的证明。第二部分介绍了 CAP 里面协议，重点介绍了 Raft 协议。第三部分，重点介绍了常用的 zookeeper 原理。

    为了保证数据 commit 之后不可丢，系统都会采用（WAL write ahead log）（在每次修改数据之前先写操作内容日志，然后再去修改数据。即使修改数据时异常，也可以通过操作内容日志恢复数据）

    分布式存储系统中，是假设机器是不稳定，随时都有可能 down 掉的情况下来设计的。也就是说就算机器 down 掉了，用户写入的数据也不能丢，避免单点故障。为此每一份写入的数据，需要在多个副本中同时存放。例如 zk 节点数据复制，etcd 的数据复制。而复制数据给节点又会带来一致性的问题，例如主节点和从节点数据不一致改如何去同步数据。也会带来可用性的问题，如 leader 节点 down 掉，如何快速选主，恢复数据等。好在已有成熟的理论如 Paxos 协议，ZAB 协议 Raft 协议等做为支撑。
    `

    回复

  8. 分布式系统原理介绍
    http://guanzhou.pub/2018/06/04/Distributed/
    `
    1 概念
    1.1 模型
    节点
    异常
    1.2 副本
    副本一致性
    1.3 衡量分布式系统的指标
    2 分布式系统原理
    2.1 数据分布方式
    哈希方式
    按数据范围分布
    按数据量分布
    一致性哈希
    副本与数据分布
    本地化计算
    数据分布方式的选择
    2.2 基本副本协议
    中心化副本控制协议
    primary-secondary 协议
    数据更新基本流程
    数据读取方式
    primary 副本的确定与切换
    数据同步
    去中心化副本控制协议
    2.3 Lease 机制
    基于lease 的分布式cache 系统
    lease 机制的分析
    基于lease 机制确定节点状态
    lease 的有效期时间选择
    2.4 Quorum 机制
    write-all-read-one
    Quorum 定义
    读取最新成功提交的数据
    基于Quorum 机制选择primary副本
    2.5 日志技术
    Redo Log 与Check point
    Redo Log
    Check point
    No Undo/No Redo log
    2.6 两阶段提交协议
    流程描述
    异常处理
    宕机恢复
    协议分析
    2.7 MVCC
    2.8 Paxos协议
    角色
    流程
    例子
    2.9 CAP
    `

    回复

  9. API网关从入门到放弃
    https://github.com/aCoder2013/blog/issues/35
    `
    采用API网关，实现一个API网关接管所有的入口流量，类似Nginx的作用，将所有用户的请求转发给后端的服务器，但网关做的不仅仅只是简单的转发，也会针对流量做一些扩展，比如鉴权、限流、权限、熔断、协议转换、错误码统一、缓存、日志、监控、告警等，这样将通用的逻辑抽出来，由网关统一去做，业务方也能够更专注于业务逻辑，提升迭代的效率。

    通过引入API网关，客户端只需要与API网关交互，而不用与各个业务方的接口分别通讯，但多引入一个组件就多引入了一个潜在的故障点，因此要实现一个高性能、稳定的网关，也会涉及到很多点。
    `

    回复

  10. 服务注册与发现组件 Eureka 客户端实现原理解析
    http://blueskykong.com/2019/09/22/eureka-client/
    `
    在前面的文章介绍了，如何使用服务注册发现组件： Eureka，并给出使用示例。本文在此基础上，将会讲解 Eureka 客户端实现的内幕，结合源码深入实现的细节，知其所以然。客户端需要重点关注以下几点：

    从Eureka Server中拉取注册表信息
    全量拉取注册表信息
    增量式拉取注册表信息
    注册表缓存刷新定时器与续租(心跳)定时器
    服务注册与服务按需注册
    服务实例的下线
    `

    回复

  12. 探探如何三个月完成微服务改造，以及踩过的“坑”
    https://mp.weixin.qq.com/s/y43L9RMa94sca2P5FKrpCA
    `
    第一，我们碰到了哪些问题，为什么需要微服务；
    第二，对微服务的认知；
    第三，微服务实施的过程；
    第四，微服务实施过程中遇到的关于 Go 的坑和解决办法。
    `

    回复

  13. 美团下一代服务治理系统 OCTO2.0 的探索与实践
    https://mp.weixin.qq.com/s/5iHH65DiGJvJjtG28Oserg
    https://tech.meituan.com/2019/12/12/meituan-octo.html
    `
    一、OCTO 现状分析
    OCTO 是美团标准化的服务治理基础设施，治理能力统一、性能及易用性表现优异、治理能力生态丰富，已广泛应用于美团各事业线。关于 OCTO 的现状，可整体概括为：
    · 已成为美团高度统一的服务治理技术栈，覆盖了公司90%的应用，日均调用超万亿次。

    · 经历过大规模的技术考验，覆盖数万个服务/数十万个节点。

    · 协同周边治理生态提供的治理能力较为丰富，包含但不限于 SET 化、链路级复杂路由、全链路压测、鉴权加密、限流熔断等治理能力。

    · 一套系统支撑着多元业务，覆盖公司所有事业线。

    目前美团已经具备了相对完善的治理体系，但仍有较多的痛点及挑战：

    · 对多语言支持不够好。美团技术栈使用的语言主要是 Java，占比到达80%以上，上面介绍的诸多治理能力也集中在 Java 体系。但美团同时还有其他近10种后台服务语言在使用，这些语言的治理生态均十分薄弱，同时在多元业务的模式下必然会有增长的多语言需求，为每一种语言都建设一套完善的治理体系成本很高，也不太可能落地。

    · 中间件和业务绑定在一起，制约着彼此迭代。一般来说，核心的治理能力主要由通信框架承载，虽然做到了逻辑隔离，但中间件的逻辑不可避免会和业务在物理上耦合在一起。这种模式下，中间件引入Bug需要所有业务配合升级，这对业务的研发效率也会造成损害；新特性的发布也依赖业务逐个升级，不具备自主的控制能力。

    · 异构治理体系技术融合成本很高。

    · 治理决策比较分散。每个节点只能根据自己的状态进行决策，无法与其他节点协同仲裁。

    针对以上痛点，我们考虑依托于 Service Mesh 解决。Service Mesh 模式下会为每个业务实例部署一个 Sidecar 代理，所有进出应用的业务流量统一由 Sidecar 承载，同时服务治理的工作也主要由 Sidecar 执行，而所有的 Sidecar 由统一的中心化控制大脑控制面来进行全局管控。这种模式如何解决上述四个问题的呢？

    · Service Mesh 模式下，各语言的通信框架一般仅负责编解码，而编解码的逻辑往往是不变的。核心的治理功能（如路由、限流等）主要由 Sidecar 代理和控制大脑协同完成，从而实现一套治理体系，所有语言通用。

    · 中间件易变的逻辑尽量下沉到 Sidecar 和控制大脑中，后续升级中间件基本不需要业务配合。SDK 主要包含很轻薄且不易变的逻辑，从而实现了业务和中间件的解耦。

    · 新融入的异构技术体系可以通过轻薄的 SDK 接入美团治理体系（技术体系难兼容，本质是它们各自有独立的运行规范，在 Service Mesh 模式下运行规范核心内容就是控制面和Sidecar），目前美团线上也有这样的案例。

    · 控制大脑集中掌控了所有节点的信息，进而可以做一些全局最优的决策，比如服务预热、根据负载动态调整路由等能力。

    总结一下，在当前治理体系进行 Mesh 化改造可以进一步提升治理能力，美团也将 Mesh 化改造后的 OCTO 定义为下一代服务治理系统 OCTO2.0（内部名字是OCTO Mesh）。
    `

    回复

  14. 什么是Service Mesh
    https://mp.weixin.qq.com/s/7q2WfRPwL0YmWoQRusyjwQ
    https://zhuanlan.zhihu.com/p/61901608
    `
    那么到底什么是Service Mesh？
    一言以蔽之：Service Mesh是微服务时代的TCP协议。

    Service Mesh 是一个 基础设施层，用于处理服务间通讯。现代云原生应用有着复杂的服务拓扑，服务网格负责在这些拓扑中 实现请求的可靠传递。

    微服务（Microservices）是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块（Small Building Blocks）为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关（Language-Independent/Language agnostic）的API集相互通信。

    时代0：开发人员想象中，不同服务间通信的方式
    时代1：原始通信时代
    时代2：TCP时代
    时代3：第一代微服务
    时代4：第二代微服务
    时代5：第一代Service Mesh
    时代6：第二代Service Mesh

    第一代Service Mesh由一系列独立运行的单机代理服务构成，为了提供统一的上层运维入口，演化出了集中式的控制面板，所有的单机代理组件通过和控制面板交互进行网络拓扑策略的更新和单机数据的汇报。这就是以Istio为代表的第二代Service Mesh。
    `

    回复

  15. Service Mesh 是什么，我们为什么需要它？
    https://mp.weixin.qq.com/s/Z-7eJC_9E9t1ND14nVz_hw
    https://buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one/
    Service Mesh 风景独好
    https://mp.weixin.qq.com/s/BvdcJN9Hla6DTD1_oi-LaA

    蚂蚁金服 Service Mesh 实践探索
    https://mp.weixin.qq.com/s/543MsQkrtTdIfnfGd7LciA
    `
    Service Mesh 是一个 基础设施层，用于处理服务间通讯。现代云原生应用有着复杂的服务拓扑，服务网格负责在这些拓扑中 实现请求的可靠传递。
    `

    阿里巴巴 Service Mesh 落地的架构与挑战
    https://mp.weixin.qq.com/s/5hrtLGPVwW6lOD8O5J01VA

    Service Mesh在百度网盘数万后端的实践落地
    https://mp.weixin.qq.com/s/y6U8DbyYTL6aE6YEqFVbBA

    Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题
    https://mp.weixin.qq.com/s/7cZWNPcQINtFgFe7WjIWdg

    回复

  16. 开发者必须要了解的架构技术趋势：Service Mesh
    https://mp.weixin.qq.com/s/kKwIQyKQLWRJmh-qM-prmA
    `
    Service Mesh 是干啥的？解决了什么问题？
    简单来讲，Service Mesh 简化了微服务架构中服务间调用复杂度。

    Service Mesh 的核心功能：
    服务间调用的弹性处理：熔断、超时、重试、错误处理、负载均衡、故障转移。
    服务发现：通过专用服务注册表发现服务终结点。
    路由：提供原始的路由功能，不涉及服务中业务相关的路由功能。
    监控：度量、监控器、分布式日志、分布式跟踪。
    安全：传输层安全，key 管理。
    访问控制：基于黑名单、白名单的访问控制。
    部署：原生支持容器，Docker 和 Kubernetes。
    通信协议：HTTP1.x, HTTP2, gRPC, TCP。

    Service Mesh 的主流实现有哪些？
    非常流行的2个开源实现：
    Linkerd
    Istio

    小结：
    Service Mesh 把通用的服务调用需要处理的问题都统一处理了，你可以更加专注于服务自身的业务了，也可以放心的使用不同开发语言。
    但 Service Mesh 也有不足，首先就是增加了系统整体的复杂度，例如增加了 Sidecar、Control Plane，而且服务间的通信不像以前那么直接了，需要经过代理。还有就是成熟度还不是很高，需要大规模线上应用的磨合完善。
    `

    回复

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注