Skip to content

Latest commit

 

History

History
405 lines (360 loc) · 33.5 KB

高并发-分布式-微服务.md

File metadata and controls

405 lines (360 loc) · 33.5 KB

高并发-分布式-微服务

CAP

CAP 定理，又被称作布鲁尔定理，它指出对于一个分布式计算系统来说，不可能同时满足以下三点：

  • Consistency：数据一致性
  • Availability：服务可用性
  • Partition tolerance：服务分区容错性

例如：Zookeeper 保证 CP，Eureka 保证 AP

RPC

  • Dubbo
  • gRPC
  • RMI（Remote Method Invocation）
  • Feign

分布式服务注册与发现

  • Zookeeper
    • Zookeeper 分布式服务框架是 Apache Hadoop 的一个子项目，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等（Dubbo、Hadoop 等）
    • 提供了树结构的文件存储和通知机制
    • zookeeper 维护一个类似文件系统的数据结构，每一个子目录项都被称作为 znode，能够自由的增加、删除
    • znode 有四种类型：
      • PERSISTENT-持久化目录节点：客户端与 zookeeper 断开连接后，该节点依旧存在
      • PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点：客户端与 zookeeper 断开连接后，该节点依旧存在，只是 Zookeeper 给该节点名称进行顺序编号
      • EPHEMERAL-临时目录节点：客户端与 zookeeper 断开连接后，该节点会被删除
      • EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点：客户端与 zookeeper 断开连接后，该节点被删除，只是 Zookeeper 给该节点名称进行顺序编号
    • 主要有三个角色：
      • Leader：负责进行投票的发起和决议，更新系统状态
      • Learner：
        • Follower：接收客户端请求并返回结果，在选举过程中参与投票
        • Observer：可以接收客户端请求，并将请求转发给 Leader 节点，Observer 不参与投票，只同步 Leader 的状态，Observer 的目的是为了扩展系统，提高读取速度
      • Client：请求发起方
    • Watcher：可以对 ZK 的某个 Node 添加 Watcher，该 Node 发生任何变化，都会通知 Watcher 的添加者
    • 分布式锁：利用 ZK 同一个 Node 不能重复创建的机制，来实现分布式锁的功能
    • 为了保证事务的顺序一致性，zookeeper 采用了递增的事务 id 号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上 了 zxid。实现中 zxid 是一个 64 位的数字，它高 32 位是 epoch 用来标识 leader 关系是否改变，每次一个 leader 被选出来，它都会有一个 新的 epoch，标识当前属于那个 leader 的统治时期。低 32 位用于递增计数
    • 为了保证分区容错性，zookeeper 是要让每个节点副本必须是一致的
      • Leader 服务器将客户端的 request 请求转化为事物 proposal 提案，同时为每个 proposal 分配一个全局唯一的 ID，即 ZXID
      • leader 服务器与每个 follower 之间都有一个队列，leader 将消息发送到该队列
      • follower 机器从队列中取出消息处理完(写入本地事物日志中)毕后，向 leader 服务器发送 ACK 确认
      • leader 服务器收到半数以上的 follower 的 ACK 后，即认为可以发送 commit
      • leader 向所有的 follower 服务器发送 commit 消息
    • 为什么 Zookeeper 只满足 CP
      • 进行 leader 选举时集群不可用，当 Leader 节点因为网络故障与其他节点失去联系时，剩余 Follower 节点会重新进行 leader 选举，选举期间整个 zk 集群都是不可用的，因此不保证服务可用性
      • ZK 会将接收到的请求预先放在一个队列中，然后用单线程从队列中依次取出请求进行处理，如果同时有两个写请求，第二个会失败，因此不保证服务可用性
  • Nacos
  • Eureka

分布式配置中心

  • Spring Cloud Config
  • Apollo
  • Nacos
  • Disconf

分布式权限验证

  • Spring Security
  • Apache Shiro

分布式网关

  • Spring Cloud Gateway
  • Zuul

分布式服务监控

  • Zabbix
    • 介绍地址
    • Linux 下开源监控系统简单介绍：
      • cacti：存储数据能力强，报警性能差
      • nagios：报警性能差，存储数据仅有简单的一段可以判断是否在合理范围内的数据长度，储存在内存中
      • zabbix：结合上面两种工具的优点，又可以存储数据，又可以报警
    • 简介
      • Zabbix 是一个企业级的开源分布式监控解决方案，由 C 语言编写而成的底层架构（server 端和 agent 端），通过 C/S 模式采集数据，通过 B/S 模式在 web 端展示和配置
      • Agent 端：主机通过安装 agent 方式采集数据，网络设备通过 SNMP 方式采集数据
      • Server 端：通过收集 SNMP 和 agent 发送的数据，写入 mysql 数据库，再通过 php+apache 在 web 前端展示
    • 工作原理
      • Agent 安装在被监控的主机上，Agent 负责定期收集客户端本地各项数据，并发送至 Zabbix Server 端
      • Zabbix Server 收到数据，将数据存储到数据库中，用户基于 Zabbix WEB 可以看到数据在前端展现图像
      • 当 Zabbix 监控某个具体的项目，该项目会设置一个触发器阈值
      • 当被监控的指标超过该触发器设定的阈值，会进行一些必要的动作，动作包括：发送信息（邮件、微信、短信）、发送命令（SHELL 命令、Reboot、Restart、Install 等）
    • 工作模式
      • 主动模式：由 agent 端主动收集信息发送给 server 端 工具是 zabbix_sender
      • 被动模式：由 server 端主动拉取信息 工具是 zabbix_get
    • 角色组件
      • Zabbix agent：负责部署在被监控主机上，把被监控主机的数据传送给 zabbix server
      • Zabbix server：负责接收 agent 发送的信息，组织配置信息，统计配置信息和操作数据等
      • Zabbix database： 用于存储 zabbix 的所有配置信息，监控数据的数据库
      • Zabbix web： zabbix 的 web 界面，管理可以通过 zabbix 的 web 界面管理 zabbix 配置以及查看 zabbix 的监控信息，可以独一部署在一台服务器上
      • Zabbix proxy：分布式环境中使用，zabbix proxy 代表 server 端管理该区域中的信息收集，最终统一发往 zabbix server
    • 通讯方式
      • agent：通过专用的代理程序进行监控
      • ssh/Telnet：通过远程控制协议进行通讯
      • SNMP：通过 SNMP 协议与被监控对象进行通讯，路由器和交换机支持
      • SNMP，其实也是一种 agent
      • IPMI：通过 IPMI 接口进行监控，通过 IPMI 硬件接口监控，电压，温度，风扇，和电源状态
      • JMX：通过（java management extensions Java 管理扩展）监控 JVM 虚拟机
    • 监控体系架构
      • 在实际监控架构中，zabbix 根据网络环境、监控规模等分了三种架构： server-client 、master-node-client、server-proxy-client 三种
        1. server-client 架构：也是 zabbix 的最简单的架构，监控机和被监控机之间不经过任何代理 ，直接由 zabbix server 和 zabbix agentd 之间进行数据交互。适用于网络比较简单，设备比较少的监控环境
        2. server-proxy-client 架构：其中 proxy 是 server、client 之间沟通的一个桥梁，proxy 本身没有前端，而且其本身并不存放数据，只是将 agentd 发来的数据暂时存放，而后再提交给 server 。该架构经常是和 master-node-client 架构做比较的架构 ，一般适用于跨机房、跨网络的中型网络架构的监控
        3. master-node-client 架构：该架构是 zabbix 最复杂的监控架构，适用于跨网络、跨机房、设备较多的大型环境 。每个 node 同时也是一个 server 端，node 下面可以接 proxy，也可以直接接 client 。node 有自已的配置文件和数据库，其要做的是将配置信息和监控数据向 master 同步，master 的故障或损坏对 node 其下架构的完整性
  • Metrics
    • Gauges：最简单的度量指标，只有一个简单的返回值
    • Counters：计数器，Counter 只是用 Gauge 封装了 AtomicLong
    • Meters：Meter 度量一系列事件发生的速率(rate)，例如 TPS
    • Histograms：Histogram 统计数据的分布情况。比如最小值、最大值、中间值，还有中位数、分位值等
    • Timers：Timer 其实是 Histogram 和 Meter 的结合， histogram 某部分代码/调用的耗时， meter 统计 TPS

分布式事务

分布式事务的实现主要有以下 5 种方案：

  1. XA 方案
    • 两阶段提交，使用事务管理器来协调管理所有数据库，每个数据库都 OK 了再统一提交，严格依赖数据库，性能低
  2. TCC 方案
    • Try、Confirm、Cancel，每个服务都提供实际操作和回滚的两个接口，任何一个服务出现错误，则回滚之前的全部操作，严格依赖代码逻辑
  3. 本地消息表
    • A 和 B 系统都维护一个本地消息表，A 系统操作成功后通过 MQ 发送消息给 B 系统，B 系统操作成功后修改 B 和 A 系统的两个系统的消息状态，A 会定时扫描消息表，将未处理的消息重复通过 MQ 发送给 B 系统，确保 B 系统操作成功
  4. 可靠消息最终一致性方案
    • RocketMQ 的事务消息
  5. 最大努力通知方案
    • A 系统本地事务执行完之后发送消息到 MQ，通知服务消费 MQ 并记录到数据库中，然后定时轮询调用 B 服务，直到 B 服务的操作执行成功

分布式文件系统

  • HDFS
  • TFS（Taobao FileSystem）
    • TFS 是淘宝开源的一个高可扩展、高可用、高性能、面向互联网服务的分布式文件系统，在阿里广泛应用
    • 适合小文件存储（不超过 1M）
    • TFS 集群由 NamServer 和 DataServer 组成，以 block（通常为 64M，可配置）为单位存储和组织数据
    • 架构
      • NameServer
        • NameServer 主要管理维护 Block 和 DataServer 相关信息,包括 DataServer 加入、退出、心跳信息、 block 和 DataServer 的对应关系建立、解除
        • 正常情况下，一个块会在 DataServer 上存在， 主 NameServer 负责 Block 的创建，删除，复制，均衡，整理， NameServer 不负责实际数据的读写，实际数据的读写由 DataServer 完成
        • NameServer 采用了 HA 结构，通过主备实现高可用
      • DataServer
        • DataServer 主要负责实际数据的存储和读写
        • TFS 会将多个小文件存储在同一个 block 中，并为 block 建立索引，以便快速在 block 中定位文件
        • 每个 block 会存储多个副本到不同的机架上，以保证数据的高可用
    • 写入流程：
      • 客户端向 nameserver 发起写请求，nameserver 根据 dataserver 上的可写块，容量和负载加权平均来选择一个可写的 block，并返回该 block 所在的多个 dataserver 列表（选择一个作为写入的 master）
      • 客户端向 master dataserver 开始数据写入操作，master server 将数据传输为其他的 dataserver 节点，只有当所有 dataserver 节点写入均成功时，master server 才会向 nameserver 和客户端返回操作成功的信息
    • 读取流程：
      • 根据 TFS 文件名解析出 Block ID 和 block 中的 File ID
      • 向 nameserver 发送查询请求得到 Block ID 所在的 dataserver 地址
      • 通过发送 Block_ID、File_ID 和 offset 为参数的读请求到对应的 dataserver，dataserver 会根据本地记录的信息来得到 File ID 所在 block 的偏移量，得到文件内容
  • FastDFS
    • FastDFS 是一个 C 语言编写的分布式文件系统，由淘宝开发平台部资深架构师余庆开发
    • 解决了大数据量存储和负载均衡等问题，适合存储中小文件（建议范围：4KB < file_size <500MB）
    • 结构
      • 跟踪服务器（Tracker Server）
        • 主要做调度工作，起到均衡的作用，负责管理所有的 存储服务器（Storage Server） 和 组（group），每个 storage 在启动后会连接 跟踪服务器 Tracker，告知自己所属 group 等信息，并保持周期性心跳
      • 存储服务器（Storage Server）
        • 存储服务器，主要提供容量和备份服务；以 group 为单位，每个 group 内可以有多台 存储服务器 storage server，数据互为备份
      • 客户端（Client）
        • 作为业务请求的发起方，通过专有接口，使用 TCP/IP 协议与跟踪器服务器或存储节点进行数据交互
    • 存储策略
      • 为了支持大容量，存储节点（服务器）采用了分卷（或分组）的组织方式
      • 存储系统由一个或多个卷组成，卷与卷之间的文件是相互独立的，所有卷的文件容量累加就是整个存储系统中的文件容量
      • 一个卷可以由一台或多台存储服务器组成，一个卷下的存储服务器中的文件都是相同的，卷中的多台存储服务器起到了冗余备份和负载均衡的作用
      • 在卷中增加服务器时，同步已有的文件由系统自动完成，同步完成后，系统自动将新增服务器切换到线上提供服务
      • 当存储空间不足或即将耗尽时，可以动态添加卷，只需要增加一台或多台服务器，并将它们配置为一个新的卷，这样就扩大了存储系统的容量
  • Ceph
    • Ceph 是一个使用 C/C++ 语言编写的统一的分布式存储系统，设计初衷是提供较好的性能、可靠性和可扩展性
    • Ceph 项目最早起源于 Sage 就读博士期间的工作（最早的成果于 2004 年发表），并随后贡献给开源社区
    • 接口类型
      • Object：有原生的 API，而且也兼容 Swift 和 S3 的 API
      • Block：支持精简配置、快照、克隆
      • File：Posix 接口，支持快照
    • 核心组件
      • Monitor：一个 Ceph 集群需要多个 Monitor 组成的小集群，它们通过 Paxos 同步数据，用来保存 OSD 的元数据
      • OSD：OSD 全称 Object Storage Device，也就是负责响应客户端请求返回具体数据的进程。一个 Ceph 集群一般都有很多个 OSD
      • MDS：MDS 全称 Ceph Metadata Server，是 CephFS 服务依赖的元数据服务
      • Object：Ceph 最底层的存储单元是 Object 对象，每个 Object 包含元数据和原始数据
      • PG：PG 全称 Placement Grouops，是一个逻辑的概念，一个 PG 包含多个 OSD。引入 PG 这一层其实是为了更好的分配数据和定位数据
      • RADOS：RADOS 全称 Reliable Autonomic Distributed Object Store，是 Ceph 集群的精华，用户实现数据分配、Failover 等集群操作
      • Libradio：Librados 是 Rados 提供库，因为 RADOS 是协议很难直接访问，因此上层的 RBD、RGW 和 CephFS 都是通过 librados 访问的，目前提供 PHP、Ruby、Java、Python、C 和 C++支持
      • CRUSH：CRUSH 是 Ceph 使用的数据分布算法，类似一致性哈希，让数据分配到预期的地方
      • RBD：RBD 全称 RADOS block device，是 Ceph 对外提供的块设备服务
      • RGW：RGW 全称 RADOS gateway，是 Ceph 对外提供的对象存储服务，接口与 S3 和 Swift 兼容
      • CephFS：CephFS 全称 Ceph File System，是 Ceph 对外提供的文件系统服务
    • 优点：
      • 高可用
        • 摒弃了传统的集中式存储元数据寻址的方案，采用 CRUSH 算法，数据分布均衡，并行度高
        • 考虑了容灾域的隔离，能够实现各类负载的副本放置规则，例如跨机房、机架感知等，副本数可以灵活控制，没有单点故障，自动管理
        • 支持故障域分隔，数据强一致性。多种故障场景自动进行修复自愈
        • 能够支持上千个存储节点的规模，支持 TB 到 PB 级的数据
      • 高可扩展性
        • 去中心化，扩展灵活
        • 随着节点增加而线性增长
    • 缺点：
      • 易用性差，维护难度高
      • 性能隐患：
        • 文件需要先写日志，再写入文件系统，降低了吞吐量
        • IO 次数多，一个 IO 需要经过多个模块才能完成，每个模块之间都涉及到队列和线程切换，部分模块在对 IO 进行处理时还要进行内存拷贝，导致整体性能不高
        • Ceph 最开始是为 HDD 设计的，没有充分考虑全 SSD，甚至更先进的 PCIe SSD 和 NVRAM 的情况 NVRAM。导致这些硬件的物理性能在 Ceph 中无法充分发挥出来，特别是延迟和 IOPS，受比较大的影响
  • GridFS
    • GridFS 是一种存储大型文件的文件规范，是 MongoDB 的二进制数据存储在数据库中的解决方案
    • GridFS 将文件分成多个块（chunks）（每个 chunks 默认大小为 256kB），每个块作为一个单独的文档
    • GridFS 使用两个文档来存储文件，一个用来存储文件本身的块，另外一个用来存储分块的信息和文件的元数据（metadata），默认对应的集合分别为 fs.chunks 和 fs.files
    • 优点：
      • 高可用，可以存储上百万的文件而无需担心扩容性，GridFS 会自动平衡已有的复制，对文件存储做故障转移或者是横向扩展比较容易
      • 易用性强：当用户查询 GridFS 中的文件时，客户端或者 driver 将会重新按序组装这些 chunks。用户可以 range 查询文件，也可以获取文件的任意部分的信息
    • 缺点：
      • 查询时需要先匹配 metadata，再去获取文件，增加了复杂度，不适合存储小文件
      • 无法修改文档。如果要修改 GridFS 里面的文档，只能是先删除再添加
  • MinIO
    • MinIO 是一个用 Golang 开发的对象存储服务
    • 它兼容亚马逊 S3 云存储服务接口，非常适合于存储大容量非结构化的数据，例如图片、视频、日志文件、备份数据和容器/虚拟机镜像等，而一个对象文件可以是任意大小，从几 kb 到最大 5T 不等
    • Minio 使用纠删码 erasure code 和校验和 checksum 来保护数据免受硬件故障和数据损坏，即便丢失一半数量（N/2）的硬盘，仍然可以恢复数据
    • 纠错码介绍(erasure code)
      • 纠删码是一种恢复丢失和损坏数据的数学算法， Minio 采用 Reed-Solomon code 将对象拆分成可变数据块和奇偶校验块
    • 优点：
      • 数据保护: 采用纠错码 erasure code 防止多节点或者驱动器异常，采用 bit rot 来进行数据保护。一个分布式的 Minio 集群最小需要 4 块盘(其实是纠错码要求最小 4 块)来驱动整个集群，当分布式集群启动后，纠错码会自动启动
      • 高可用: 多节点组成的分布式 minio 可保证服务的高可用(一个 N 节点的分布式 Minio,只要有 N/2 节点在线，数据就是安全的。不过需要至少有 N/2+1 个节点才能创建新的对象)
      • 一致性保障: MinIO 在所有的 IO 操作中都严格遵循 read-after-write 和 list-after-write 一致性模型

Serverless

  • 简介
    • Serverless 俗称无服务器架构，最初在 2010 年被提出
    • 2014 年 AWS 推出了 lambda 服务，把 Serverless 产品化，并收到了很好的效果
    • 微软、Google 和 IBM 看到后，也分别在 2016 年推出了自己的 Serverless 产品：Azure function、GCP 和 OpenWisk
    • 阿里云和腾讯云也分别在 2017 年推出了自己的 Serverless 产品
    • 无服务器并不代表 Serverless 真的不需要服务器，只不过服务器的管理以及资源分配部分对用户不可见，由平台开发商维护，用户只需要关注业务逻辑的开发即可
    • Serverless 不是具体的一个编程框架、类库或者工具，它是一种软件系统架构思想和方法
    • 它的核心思想是用户无须关注支撑应用服务运行的底层资源，比如：CPU、内存和数据库等，只需要关注自己的业务开发即可
  • 架构
    • 基础设施层：底层计算资源，一般使用 Docker 容器技术
    • 资源管理层：集群监控、故障转移、自动扩缩容等技术
    • 认证和授权系统：保证函数的安全
    • 接入层：主要用来触发 Function 的调度和分配
    • 架构层：主要用来做一些流程上的调度
    • 外围的工具系统：DevOps 支持，日志、监控、告警支持等

微服务定义

  • 微服务 (Microservices) 是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通信
  • 目前的主流微服务框架：Spring Cloud， Service Fabric，Linkerd，Envoy，Istio 等

网络通信的发展

  1. 原始通信时代
    • 通信需要底层能够传输字节码和电子信号的物理层来完成，服务需要自己处理网络通信所面临的丢包、乱序、重试等一系列流控问题
  2. TCP 时代
    • TCP 协议的出现，解决了网络传输中通用的流量控制问题，将技术栈下移，从服务的实现中抽离出来，成为操作系统网络层的一部分
  3. 第一代微服务
    • 在 TCP 出现之后，机器之间的网络通信不再是一个难题，以 GFS/BigTable/MapReduce 为代表的分布式系统得以蓬勃发展
    • 这时，分布式系统特有的通信语义又出现了，如熔断策略、负载均衡、服务发现、认证和授权、quota 限制、trace 和监控等等
  4. 第二代微服务
    • 为了避免每个服务都需要自己实现一套分布式系统通信的语义功能，一些面向微服务架构的开发框架出现了，如 Twitter 的 Finagle、Facebook 的 Proxygen 以及 Spring Cloud 等等
    • 这些框架实现了分布式系统通信需要的各种通用语义功能：如负载均衡和服务发现等，因此一定程度上屏蔽了这些通信细节，使得开发人员使用较少的框架代码就能开发出健壮的分布式系统
  5. 第一代 Service Mesh
    • 虽然微服务框架本身屏蔽了分布式系统通信的一些通用功能实现细节，但开发者却要花更多精力去掌握和管理复杂的框架本身，而且开发框架通常只支持一种或几种特定的语言，这违背了微服务与语言无关的设定
    • 因此以 Linkerd，Envoy，Ngixmesh 为代表的代理模式（边车模式）应运而生，这就是第一代 Service Mesh
    • 它将分布式服务的通信抽象为单独一层，在这一层中实现负载均衡、服务发现、认证授权、监控追踪、流量控制等分布式系统所需要的功能，作为一个和服务对等的代理服务，和服务部署在一起，接管服务的流量，通过代理之间的通信间接完成服务之间的通信请求
  6. 第二代 Service Mesh
    • 第一代 Service Mesh 由一系列独立运行的单机代理服务构成，为了提供统一的上层运维入口，演化出了集中式的控制面板，所有的单机代理组件通过和控制面板交互进行网络拓扑策略的更新和单机数据的汇报。这就是以 Istio 为代表的第二代 Service Mesh

ServiceMesh

  • 介绍地址
  • 简介
    • 服务网格（Service Mesh）是处理服务间通信的基础设施层
    • 它负责构成现代云原生应用程序的复杂服务拓扑来可靠地交付请求
    • 在实践中，Service Mesh 通常以轻量级网络代理阵列的形式实现，这些代理与应用程序代码部署在一起，对应用程序来说无需感知代理的存在
  • 优点：
    • 屏蔽分布式系统通信的复杂性(负载均衡、服务发现、认证授权、监控追踪、流量控制等等)，服务只用关注业务逻辑
    • 真正的语言无关，服务可以用任何语言编写，只需和 Service Mesh 通信即可
    • 对应用透明，Service Mesh 组件可以单独升级
  • 缺点：
    • Service Mesh 组件以代理模式计算并转发请求，一定程度上会降低通信系统性能，并增加系统资源开销
    • Service Mesh 组件接管了网络流量，因此服务的整体稳定性依赖于 Service Mesh，同时额外引入的大量 Service Mesh 服务实例的运维和管理也是一个挑战

Istio（服务网格路由）

  • Istio 是一个开放平台，提供统一的方式来集成微服务，管理跨微服务的流量，执行策略和汇总遥测数据
  • Istio 的控制面板在底层集群管理平台（如 Kubernetes，Mesos 等）上提供了一个抽象层
  • 核心组件：
    • Envoy - 每微服务器的 Sidecar 代理，处理集群中的服务间和服务到外部服务的入口/出口流量。代理形成安全的微服务网格，提供丰富的功能，如服务发现，丰富的 7 层路由，熔断器，策略执行和遥测记录/报告功能
    • Mixer - 由代理和微服务使用的集中式组件，用于执行策略，如鉴权，限流，配额，认证，请求跟踪和遥测收集等
    • Pilot - 负责在运行时配置代理的组件
    • Citadel - 负责证书颁发和轮换的集中式组件
    • Node Agent - 负责证书颁发和轮换的每节点组件
    • Galley - 用于在 Istio 中验证，摄取，聚合，转换和分发配置的中央组件

Docker&Kubernetes（K8s）

Docker

  • 介绍地址
  • Docker 是 DotCloud 公司 2013 年 3 月开源的、基于 Go 语言开发，可以将任何应用包装在 Linux Containers（Linux 容器，缩写为 LXC）中运行的工具
  • 基于 Docker 的沙箱环境可以实现轻型隔离，多个容器间不会相互影响
  • Docker 可以自动化打包和部署任何应用，方便地创建一个轻量级私有 PaaS 云，也可以用于搭建开发测试环境以及部署可扩展的 web 应用等
  • Docker 相对 VM（虚拟机）的优势
    • VM 的缺点：
      1. VM 运行自身操作系统会占用较多的 CPU、内存、硬盘资源
      2. VM 是完整的操作系统，一些系统级别的操作步骤，往往无法跳过，比如用户登录
      3. 启动操作系统需要多久，启动虚拟机就需要多久。可能要等几分钟，应用程序才能真正运行
    • Docker 不同于 VM，只包含应用程序以及依赖库，基于 libcontainer 运行在宿主机上，并处于一个隔离的环境中，这使得 Docker 更加轻量高效，启动容器只需几秒钟之内完成
  • Docker 的主要用途：
    1. 提供一次性的环境。比如提供单元测试环境、测试中间件环境
    2. 提供弹性的云服务。因为 Docker 容器可以随开随关，很适合动态扩容和缩容
    3. 组建微服务架构。通过多个容器，一台机器可以跑多个服务，因此在本机就可以模拟出微服务架构
  • Docker 是 CS 架构，主要由下面三部分组成：
    • Docker daemon: 运行在宿主机上，Docker 守护进程，用户通过 Docker client(Docker 命令)与 Docker daemon 交互
    • Docker client: Docker 命令行工具，是用户使用 Docker 的主要方式，Docker client 与 Docker daemon 通信并将结果返回给用户，Docker client 也可以通过 socket 或者 RESTful api 访问远程的 Docker daemon
    • Docker hub/registry: 共享和管理 Docker 镜像，用户可以上传或者下载上面的镜像，官方地址为https://registry.hub.docker.com，也可以搭建自己私有的Docker registry
  • 核心概念：
    • Docker image
      • Docker 把应用程序及其依赖，打包在 image 文件里面（Docker 命令或者 Dockerfile 形式打包）
      • 只有通过这个文件，才能生成 Docker 容器
      • image 文件可以看作是容器的模板，Docker 根据 image 文件生成容器的实例
      • 同一个 image 文件，可以生成多个同时运行的容器实例
      • 为了方便共享，image 文件制作完成后，可以上传到仓库（Docker hub/registry）
    • Docker container
      • 容器是 Docker 的运行组件，启动一个镜像就是一个容器
      • 容器是一个隔离环境，多个容器之间不会相互影响，保证容器中的程序运行在一个相对安全的环境中
  • Docker 网络
    • Docker 默认使用 birdge 桥接方式与容器通信
    • 启动 Docker 后，宿主机上会产生 docker0 这样一个虚拟网络接口， docker0 不是一个普通的网络接口， 它是一个虚拟的以太网桥，可以为绑定到 docker0 上面的网络接口自动转发数据包，这样可以使容器与宿主机之间相互通信
    • 每次 Docker 创建一个容器，会产生一对虚拟网络接口，它会绑定到 docker0 上，由于所有容器都绑定到 docker0 上，容器之间也就可以通信

Kubernetes

  • 介绍地址
  • Kubernetes(k8s)最初源于谷歌内部的 Borg，是 Google 开源的 Docker 容器集群管理系统
  • 在 Docker 技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性
  • 核心组件：
    • etcd：保存整个集群的状态
    • apiserver：提供资源操作的唯一入口，并提供认证、授权、访问控制、API 注册和发现等机制
    • controller manager：负责维护集群的状态，比如故障检测、自动扩展、滚动更新等
    • scheduler：负责资源的调度，按照预定的调度策略将 Pod 调度到相应的机器上
    • kubelet：负责维护容器的生命周期，同时也负责 Volume（CSI）和网络（CNI）的管理
    • Container runtime：负责镜像管理以及 Pod 和容器的真正运行（CRI）
    • kube-proxy：负责为 Service 提供 cluster 内部的服务发现和负载均衡
  • 架构：
    • 核心层：Kubernetes 最核心的功能，对外提供 API 构建高层的应用，对内提供插件式应用执行环境
    • 应用层：部署（无状态应用、有状态应用、批处理任务、集群应用等）和路由（服务发现、DNS 解析等）、Service Mesh（部分位于应用层）
    • 管理层：系统度量（如基础设施、容器和网络的度量），自动化（如自动扩展、动态 Provision 等）以及策略管理（RBAC、Quota、PSP、NetworkPolicy 等）、Service Mesh（部分位于管理层）
    • 接口层：kubectl 命令行工具、客户端 SDK 以及集群联邦
    • 生态系统：在接口层之上的庞大容器集群管理调度的生态系统，可以划分为两个范畴
      • Kubernetes 外部：日志、监控、配置管理、CI/CD、Workflow、FaaS、OTS 应用、ChatOps、GitOps、SecOps 等
      • Kubernetes 内部：CRI、CNI、CSI、镜像仓库、Cloud Provider、集群自身的配置和管理等
  • 主要功能：
    • 容器编排、资源调度
    • 服务发现、动态伸缩
    • 负载均衡、动态路由
    • 服务监控

前端页面加速

  • 访问量小的方案：
    • 将网页静态化，将数据提前填充进静态网页模板，保存在 Nginx 中，浏览页面时直接取用静态页面，避免实时访问后端接口
  • 访问量大的方案：
    • 将网页的数据存在 Redis 中，通过 MQ 更新同步数据，Nginx 每次从 Redis 获取数据，缓存到本地，再本地渲染到网页模板中，然后返回给用户

微服务治理策略

  • 服务注册与发现（Eureka、Zookeeper）
  • 服务端负载均衡（Nginx、LVS）
  • 客户端负载均衡（Ribbon）
  • 远程通信（RPC、MQ）
  • 配置中心（Nacos、Spring Cloud Config、Apollo、Disconf）
  • 限流熔断降级（Hystrix、Sentinel）
  • 文档中心（Swagger）
  • 服务安全管理（OAuth、Apache Shiro、Spring Security）
  • 服务编排（Docker & Kubernetes）

持续集成

介绍地址：http://www.ruanyifeng.com/blog/2015/09/continuous-integration.html

Jenkins

Walle