Netflix当年遇到的问题
Netflix (流媒体)
- 最初是一家以发行DVD为主营业务的公司
- 2007年将主营业务模式转变为在线租赁和视频站，以适应互联网化的大趋势
- 2008年起，公司即遇到了层出不穷的各类稳定性、扩容等问题
- 2008年8月， Netflix 主要数据库的故障导致了三天的停机
- 2009年后，流量激增下，这种问题更加严重
如何根据用户的增长不断的扩容？ 系统的扩容小于用户的速度、自己的硬件故障 网络故障 都可能导致系统不可用
亟待解决的核心问题：扩容、性能、可用性
netflix探索到的解决方案
Public cloud — scalability, agility, sharing 资源敏捷
- 上公有云
- 跨区域容灾
- 不需要搭建基础设施
- scalability 整体的业务能力得到敏捷性的提升
Micro-services — separation of concerns 业务敏捷
- 大单体 ---> 小单体 维服务化
- 关注点分离
- 每个小团队按照契约接口
De-normalized data — separation of concerns
- 非范式化的数据 - 格式化的数据(例如 SQL数据库) - 支持事务能力 但是非金融业务不强求事务 - 扩展 可用性受到局限 - 半格式化 - 无需使用事务的数据 - 非格式化
Chaos Engines — anti-fragile operations
- 混沌工程 为了反系统脆弱性
- 找出系统短板的一种工具
- SRE最高级的阶段
Open source by default — agility, sharing 开发敏捷
- 开源软件二次开发 然后 再是自主开发
- 开源社区 软件的可靠性 不亚于小型商业公司的软件
- 尽可能用开源
Continuous deployment — agility, immutability 部署敏捷
- 微服务模型下 必须要持续部署
- 微服务模型下 必然要执行的一种模式
- 部署上线不需要运维工程师的介入
- 可以使用的发布模式 金丝雀发布 蓝绿发布
- 持续发布 研发自己来控制 代码的检查 构建 打包 推送 部署上线 不应该运维介入
DevOps — high trust organization, sharing
- 强调文化
Run-what-you-wrote — anti-fragile development 资源敏捷 业务层敏捷 开发敏捷 部署
- 持续发布的延伸
- 研发自己负责线上代码的稳定性 要求代码健壮
- 出现问题就需要打补丁 热修复
- 上线的稳定性 需要自保
- 到逼研发 写的代码足够稳定 要求健壮代码
- 一旦不稳定 需要打补丁 热修复hotfix
扩容解决方案 — 上云
- 当时云计算市场并没有多大的选择空间，很容易想到，Netflix基本没有悬念地会选择AWS
- 自2011年起，Netflix逐步将其系统迁移到了 AWS 上
- 节约了87%的成本
上云之后的艰难决策 - 微服务化
- 系统重构：分布式、微服务化 消除单点
- 挑战：全新的安全、运维和组织模型
spring cloud netfix 开发框架
- 快速构建微服务化的体系系统
- 消除了单点故障 但是更考验安全 运维
分布式系统的可用性问题
- 微服务的每一个环节都可能出现问题, 随时可能发生的级联故障 特别是在链路上
- 局部不可用可能会触发多米诺骨牌效应 系统雪崩 整体可用性的不可控
- 需要一套微服务治理系统
- 增强服务的可用性 通用的每个服务都需要在网络层级 确保自己可用的能力
提升可用性的策略（反脆弱）：弹性处理局部故障
快速失败（Fail Fast）和 故障转移（Failover） fail back 故障移回
- 超时并重新请求，由调度器将请求发往另一副本（冗余）
- 客户端发起请求后 有负载均衡器（自己去做超时重试）
- 负载均衡器也可能是单点
- 微服务治理系统解决的问题 网络层面 增强服务的可用性 每个服务需要在网络层面上确保可用性提供的能力
优雅降级
- 所有副本都故障时，“熔断”上游服务，当前应用以“降级”形式继续提供服务
- 非核心服务不可用时, 通过降级 例如返回空
- 核心服务 降级不是理想的解决方案
- 故障转移的前提:
- 微服务需要有多副本
- 如果所有副本不可用 这个时候降级
- 整个请求的链路上 核心服务不可用了 这个时候降级没用了
金丝雀发布 和 蓝绿发布
- 变更是导致脆弱更重要的原因
- 任何服务上线新版本时都应该基于灰度模式进行
- 确保尽可能降低版本发布时的风险
- 两个不同版本的 全量环境
- 有状态服务
基于公有云的跨地域问题
- 公有云也可能存在问题 出现服务问题
- 为了避免自己绑定公有云服务商 需要做主备 双活 两地三中心 异地容灾
数据持久性 重复利用云能力
- 将非必须的RDBMS 转换为 分布式的NoSQL系统
- 并借助于S3的快照进行数据备份 充分应用云能力
检测系统可用性：混沌工程 chaos monkey
- 最初的实现：随机终止在生产环境中运行的 EC2 实例，以快速了解正在构建的服务是否健壮，有足够的弹性，可以容忍计划外的故障等
- 自我测试薄弱环节的测试能力
- 机房里面扔一只猴子
应用监控 分布式监控
运维模型
集中式 --》分布式
- 以前：运维团队按照周期 发布变更
- 现在：需要根据自己的需求 变更发布 做持续发布了
- 演进到了微服务 很多的小部件组合成了大的系统 每个部件之间通过接口契约互相协作
- 微服务的背景 去中心化治理 每一个部件
发布模型
- 基于AMI（Amazon Machine Image）的红黑部署
- 重新打一个镜像 重新发布一个虚机
- 日常会有人上去私自修改参数 日积月累后 没有办法维护了 所以每次变更重新打镜像
- 不考虑数据持久性问题
- 要想变更 必须要发布
- 重新打一个镜像 重新发布一个虚机
- “不可变基础设施” ：每次变更都要通过发布进行， 不允许通过SSH等连接到主机上进行变更操作
- 后续有了容器技术 比虚机模型 轻量多了
渐进式发布
- 发布第一批后 立刻纳入监控系统
- 第一波流量过来以后
- 监听响应成功率 例如5xx小于5% 那就可以上下一批
- 监控日志关键字 errorcode
- 监控告警
团队的演进
预算
- 早期 由运维部门管理预算和容量 早期
- 演进 由开发团队提供自服务的系统，并借助工具完成可视化 自己确定人效和预算
日程编排
- 早期 由运维部门管制发布日程编排
- 演进
- 分布式的DevOps模型
- 研发和运维的协作 进入了DevOps模式
- SRE负责创建工程 并分享最佳实践 给研发 和运维团队
- 运维人员的核心职责 SRE 系统稳定性
数据库维护
- 早期 由Oracle DBA管理的几个数据库
- 演进 devops工程师维护几十个 nosql cassandra集群
数据科学：
-
早期 基于SQL查询进行数据分析
-
演进 Hadoop工程师基于PIG/Python构建ETL
最终的架构图 生于云 长于云
现在的云原生 架构不一定是奈飞 但是思路一定是这样的
容器技术和Spring Cloud框架的诞生
Netflix以上故事发生的时间点：2013年之前
2013年这一年
因不想不被公有云厂商绑定，OpenStack项目的展正如火如荼
VMWare、EMC和通用资本合资成立Pivotal公司
- VMWare将所有的Spring项目都转入了Pivotal公司，同年12月，Pivotal发布Spring框架4.0
- 2009年，Vmware收购运行着Java社区最热火的框架Spring的公司SpringSource，以及PaaS供应商Cloud Foundry
- 随后的2014年，Pivotal发布Spring Boot 1.0
- 用来简化新Spring应用的初始搭建以及开发过程
- 它能够让基于Spring的开发、测试、配置、部署和监控都变得更加简便
- 2014年10月，Pivotal发布了第一个Spring Cloud版本
- 一系列框架的有序集合
- 它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务注册和发现、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署
- Spring Cloud只是抽象模型，是规范，Netflix的实现Spring Cloud Netflix是其早期最重的实现之一
Docker开源项目诞生
- 创造性的使用Image技术，将“系统容器”带入了“应用容器”时代
- 几乎是从根本上，解决了IaaS时期“跨云难（虚拟机和镜像迁移、共享等）”的问题
Spring Cloud介绍
解决了什么问题？
- 构建微服务后 服务之间的通信 存在延迟
- 网络抖动 微服务之间的通信怎么可靠
- 微服务治理
- 分布式 8大悖论
Spring Cloud关心的要素
从运维层面考虑的 更偏向运维层面
- 配置管理 分发
- 自动扩缩容 自愈
- 调度部署
- 分布式链路跟踪
- 集中式指标日志收集
- 集中式日志系统
- 服务安全
- 容错
- 服务韧性
- api网关
- 负载均衡
- 服务发现
Spring Cloud netflix项目
2018年后就不维护了
需要一种手段 确保服务之间的网络通信是可靠的
国内使用的多的是Spring Cloud alibaba
