推荐书籍

Netty进阶之路

1. 分布式服务框架原理与实践
2. 亿级流量网站架构核心技术
3. 读性能优化
4. 阿里diamond配置设计架构
5. 缓存设计
6. 选举机制
7. 基于对等节点提供服务
8. 一致性算法：ZAB、Raft、Paxos
9. 了解鹰眼的系统架构
10. 命令行设计模式、声明式设计模式
11. Istio官方文档中文版本、Service MEsh中文社区

第一章 云原生

1.1 互联网架构变迁

1.1.1 互联网架构核心问题

• 海量用户

• 产品迅速迭代

• 7×24不间断服务

• 流量突增

• 业务组合复杂

1.1.2 从集中式架构到分布式架构

1. CAP原理

2. 自动化运维

3. 解放交付的DevOps

1.1.3 从分布式架构到云原生架构

1. 新纪元的分水岭-容器技术

• 镜像+分发

2. 新纪元的编排与调度系统

• Kubernetes,Mesos,Swarm等为云原生应用提供强有力的编排与调度能力，它们是云平台上的分布式操作系统

• Borg系统的理念

• Kubernetes面向云原生Paas平台，Mesos面向大数据+编排调度，Swarm是面向容器的

3. 架构设计的变革-微服务

配置管理，服务发现，负载均衡，弹性扩缩松容，分布式调用追踪，日志中心，自愈能力

1.2 什么是云原生Cloud Native

1.2.1 概述

1. 云原生应用即专门为在云平台和运行而设计的应用

2. 云原生是一种设计模式，它要求云原生应用具备可用性和伸缩性，以及自动化部署和管理能力，可随处运行，并且能够通过持续集成、持续交付工具提升研发，测试以及发布的效率

3. 云原生体系，两组词语形容应用：无状态，有状态

1.2.2 云原生与十二要素

1. 基准代码Codebase

• git svn

2. 依赖 Dependencies

• 显示声明第三方依赖

3. 配置Config

• 将配置存储至环境变量

4. 后端服务 Backing Services

• 将后端服务作为松耦合的资源

• 后端服务是指应用程序所依赖的通过网络调用的远程服务

5. 构建，发布，运行

6. 进程Process

• 将应用作为无状态的进程运行

7. 端口绑定 Port Binding

• 通过端口绑定对外发布服务

8. 并发 Concurrency

• 能够通过水平伸缩应用程序进程来实现并发

9. 已处理 Disposability

• 可以快速启动和优雅关闭应用

10. 开发环境与线上环境等价 Dev/Prod等价

• 要保持开发环境与线上环境等价

• 推荐使用Jenkins等持续集成工具来缩短生产代码与代码库中的代码不一致时间，并且采用自动化部署的方式避免操作差异

11. 日志logs

• 使用事件流处理日志

• 进程的输出事件流由运行环境截获，运行环境会将所有输出事件流整合在一起，然后发送给一个或者多个的最终处理程序，用于查看或者长期存档

12. 管理进程 Admin processes

• 将后台管理任务当做一次性进程运行

1.2.3 十二要素进阶

1. 优先考虑API设计

2. 通过遥测感知系统状态

3. 认证和授权

1.2.4 云原生与CNCF

1. 应用定义与开发层

• 数据库与数据分析

• 流式处理

• 软件配置管理

• 应用定义

• 持续集成/持续交付

2. 编排与治理层

• 调度与编排

• 分布式协调与服务发现

• 服务管理：远程通信，反向代理，服务治理

3. 运行时层

• 云原生存储

• 容器

• 云原生网络

4. 供应保障层

• 宿主机管理工具

• 基础设施自动化工具

• 容器仓库

• 镜像安全

5. 云设施层

6. 观察分析

7. 平台

第2章 远程通信

2.1 通信方式

2.1.1 通信协议

1. 传输层协议

2. 应用层协议

• http：http2.0的多路复用；https://http2.akamai.com/demo

-长连接与短连接

2.1.2 I/O模型

1. 阻塞与非阻塞

判断阻塞I/O与非阻塞I/O时应该关注程序是否在等待调用结果

2. 同步与异步

2.1.3 java中的I/O

2.2 序列化

2.2.1 文本序列化

2.2.2 二进制java序列化

2.2.3 二进制异构语言序列化

• protobuf框架

2.3 远程调用

2.3.1 核心概念

2.3.2 java远程方法调用

1. 核心机制

2. 开发流程

3. 局限性

2.3.3 异构语言rpx框架gRPC

第3章 配置

3.1 本地配置

local 配置文件

3.2 配置集中化

可以参考阿里的diamond配置服务的架构设计

3.3 配置中心和注册中心

1. zookeeper、etcd同时支持注册中心和配置中心
2. 配置中心三个要素：快速传播、变更稀疏、环境相关

• 快速传播：在分布式场景下，各个服务节点需要得到一致的数据，一旦发生改变要求集群中的所有节点同时感知变更。
• 变更稀疏
• 环境相关：开发环境、测试环境等

3.4 读性能

1. 集中式缓存：每次客户端进行访问都可以获取最新的数据，缺点是并未缓解配置中心的访问压力
2. 本地缓存：缺点是存在多分，数据的一致性和更新的及时性受到一定的影响

3.5 变更实时性

1. 多副本的情况下采用两种常见方式：监听、定时同步
2. 定时同步：定时job、设置缓存失效时间

3.6 可用性

1. 服务冗余：服务冗余是可用性的基本策略
2. 数据冗余可以采用基于主节点提供服务和基于对等节点提供服务两种

• 基于对等节点提供服务：集群中的每个节点都是对等的，都可以提供服务和处理请求数据。在访问量非常大的情况下，有效分流客户端的访问请求
• 基于对等节点提供服务实现方案
  1. 缓存：冗余的是数据，不是服务；可以成为离线模式

3.7 数据一致性

第4章 服务治理

4.1 服务发现

4.1.1 服务发现概述

1. 服务发现模块需要有服务注册、服务查找、服务健康检查以及服务变更通知等关键功能。
2. 服务信息注册、心跳检查、服务消费方拉取最新信息。
3. 具备高可用性的注册中心除了具备多节点部署的能力，还需要在分布式场景下具备自我治愈和调整的能力。

4.1.2 ZooKeeper

1. zookeeper是基于CP的系统
2. Zab：ZooKeeper Atomic Brodcast，原子广播协议
3. Paxos算法：基于消息传递的高度容错的一致性算法
4. Zab协议规定，消息传递需要遵循可靠递交、完全有序和因果有序这三条规则
5. 集群角色：leader、follower、observer
6. 会话：TCP长链接
7. znode节点：持久节点、临时节点
8. znode节点：支持顺序属性

4.1.3 Eureka

4.2 负载均衡

4.2.1 服务端负载均衡

1. 四层负载均衡：基于ip、port的负载均衡
2. 七层负载均衡：能够充分理解应用层协议的意义，使转发更灵活

4.2.2 客户端负载均衡

1. Ribbon

4.3 限流

4.3.1 限流算法

1. 计数器限流：主要用于限制服务器端资源而并非客户端请求
2. 漏桶算法：主要用于控制其他系统的回调洪峰
3. 令牌桶算法：

4.3.2 限流实现方案

1. 客户端限流:Guava中有实现方案
2. 服务端限流：Spring Cloud Zuul
3. 接入端限流：

4.3.3 限流维度和粒度

4.4 熔断

4.4.1 概述

4.4.2 熔断器模式

4.4.3 Hystrix

第5章 观察分布式服务

5.1 层次划分

1. 基础设施层、工具层、应用环境层

5.2 核心概念

1. 日志、指标、追踪

5.3 分布式追踪

5.3.1 概述

5.3.2 常见解决方案

1. Apache Zipkin
2. OpenTracing

5.4 应用性能管理与可观察性平台

1. 分布式追踪
2. 非侵入式的语言探针
3. 轻量化
4. 低延迟分析

5.5 Apache SkyWalking

5.5.1 项目定位

5.5.2 SkyWalking 5 核心架构

1. 探针层
2. 分析层
3. 可视化层

5.5.3 SkyWalking 5 公开案例

5.5.4 SkyWalking 6 可观察性分析平台

第6章 侵入式服务治理方案

6.1 Dubbo

6.1.1 Dubbo 概述

6.1.2 核心流程

image.png

6.1.3 注册中心

image.png

6.1.4 负载均衡

6.1.5 远程通信

6.1.6 限流

6.1.7 治理中心

1. dubbo-admin

6.1.8 监控中心

1. dubbo-admin

6.1.9 DubboX的扩展

6.2 Spring Cloud

6.2.1 概述

6.2.2 开发脚手架Spring Boot

6.2.3 服务发现

6.2.4 负载均衡

6.2.5 熔断

6.2.6 远程通信

第7章 云原生生态的基石Kubernetes

7.1 Kubernetes

1. Kubernetes架构图

   
   
   1.
2. etcd:协同存储、负责保存整个集群的状态，通常部署奇数个节点以保证高可用
3. API：提供资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等
4. controller manager：负责维护集群的状态，执行故障检测、自动扩展、滚动更新等操作
5. Scheduler：负责资源调度，按照预定的调度策略将pod调度到相应的机器身上。
6. Kubelet：作为工作节点负责维护容器的生命周期，同时也负责对容器存储接口、容器网络接口进行管理
7. 容器运行时（Docker）：负责镜像管理
8. Proxy：负责提供集群内部的服务发现和负载均衡
9. 其他组件：CoreDNS、Ingress Controller、Prometheus、DashBoard、Federation

7.2 分层设计理念以及架构模型

1. 分层架构设计

   
   
   分层架构
2. Nucleus：Kubernetes核心、负责对外提供API构建高层应用，对内提供插件式应用执行环境
3. Application Layer：负责部署、路由，可部署的应用包括无状态应用、有状态应用，批处理任务、集群应用等，路由的类型主要有服务发现、DNS解析
4. Governance layer：负责自动化以及策略管理
5. 接口层：主要包括kubectl命令行工具、客户端sdk等用于客户端操作的库，以及集群联邦等使用工具
6. 云原生生态系统：接口层之上的负责容器集群管理调度的生态系统
7. Kebernetes内部：包括CRI（容器运行时接口）、CNI（容器网络接口）、CSI（容器存储接口）、镜像仓库、云供应商、身份供应商

7.3 设计哲学

1. 声明式设计模式vs命令行设计模式

7.4 Kubernetes中的原语

7.4.1 Kubernetes 中的对象

1. 对象是Kubernetes的持久化条目
2. 对象描述了以下信息：运行的容器化应用以及node位置、与应用表现相关的策略（重启、升级、容错等策略）
3. 常见队形：资源对象、存储对象、策略对象、身份对象

7.4.2 对象的期望状态与实际状态

1. Kubernetes对象中包括两个嵌套字段：spec（期望状态）和status（实际状态）

7.4.3 描述kubernetes对象

1. Pod是kubernetes中基本调度单位

7.4.4 服务发现与负载均衡

1. service：直接使用Service提供集群内部的负载均衡，并且借助云供应商提供的负载均衡器将集群服务暴露给外部
2. Ingress：依然使用Service提供集群内部的负载均衡，但是要自定义负载均衡器让外部客户端访问集群服务
3. Custom Load Balancer：采用自定义负载均衡器替换Kube-Proxy

7.4.5 安全性与权限管理

1. 隔离类型：网络隔离、资源隔离、身份隔离（kebernetes的资源隔离层次图在P189）

7.4.6 Sidecar设计模式

1. 某些情况下，需要启动一个旁侧容器来复制非功能需求，比如拦截流量进行审计，将应用程序的功能划分为单独的进程，这种方式被称为Sidecar模式

7.5 应用Kubernetes

7.6 Kubernetes 与云原生态

7.6.1 下一代云计算标准

7.6.2 当前存在问题

7.6.3 未来趋势

第8章 跨语言服务治理方案Service Mesh

8.1 Service Mesh概述

8.1.1 Service Mesh的由来

8.1.2 Service Mesh的定义

1. 服务网格是一个基础设施层，用于处理服务间通信。现在云原生应用有着复杂的服务拓扑结果，服务网格负责在这些拓扑结构中实现请求的可靠传递。在实践中，服务网格通常被实现为一组轻量级网络代理，他们与应用部署在一起，对于应用程序是透明的

8.1.3 Service Mesh 详解

1. 单个服务调用
2. 多个服务调用
3. 大量服务调用
4. Service Mesh服务网格定义：抽象、功能、部署、透明

8.2 Service Mesh 演进历程

8.2.1 远古时代的案例（P201）

8.2.2 微服务时代的现状（P201）

8.2.3 侵入式框架的痛点：门槛高、功能不全、无法跨语言、升级困难

8.2.4 解决问题的思路

8.2.5 Proxy模式的探索

8.2.6 Sidecar模式的出现

8.2.7 第一代Serivce Mesh

8.2.8 第二代Service Mesh

8.3 Service Mesh的市场竞争

8.3.1 Service Mesh的萌芽期

8.3.2 急转直下的Linkerd

8.3.3 波澜不惊的Envoy

8.3.4 背负使用的Istio

8.3.5 背水一战的Buoyant

8.3.6 其他参与者

8.3.7 Service Mesh的国内发展情况

8.4 Istio

8.4.1 Istio概述

1. Istio功能：连接、控制、保护、观测
2. Istio的设计目标

• 最大化透明度
• 增量
• 可移植性
• 策略一致性

8.4.2 架构和核心组件

1. 从逻辑上来讲，Istio分为数据平面和控制平面
2. 数据平面：是以Sidecar方式部署的智能代理，Istio默认的集成是Envoy。数据平面用来控制微服务之间的网络通信以及和Mxier的通信
3. 控制平面：负责管理以及控制数据平面，控制数据平面行为，如代理路由流量、实施策略、收集遥测数据、加密认证等。控制平面包含Pilot、Mixer、Citadel三个主要组件。

4. Istio的整体架构

   
   
   Istio的整体架构
5. Envoy：提供服务发现、负载均衡、健康检查、熔断、高级路由、基于百分比的流量切换、加密和认证、故障注入
6. Mixer：负责提供策略控制和遥测收集的组件

• check：前置条件检查
• Qutoa：能够在多维度上分配和释放资源
• Report:遥测报告

7. Pilot：向Envoy sidecar发送服务发现信息和各种流量管理以及路由规则