新建分布式系统时的八条假设

• 网络是稳定的
• 传输的延迟是零
• 带宽是无穷大
• 安全的
• 拓扑不会改变
• 只有一个系统管理员
• 传输数据的成本是零
• 整个网络是同构的

错误是不可避免的

软件工程的本质

• 提高服务的sla 多少个9的系统可用性（高可用的系统 自动化的运维）
• 能力和资源重用或复用 （模块和运行环境、资源）
• 过程的自动化（生产流水线和运维自动化）

• 分布式多层的系统架构
• 服务化的能力供应
• 自动化的运维能力

分布式、服务化、自动化部署、高可用、敏捷以及分层开放的特征

并且可以和IaaS 实现良好的联动

• 服务化是本质
• 分布式是根本特性
• 自动化是灵魂

• 流量调度层
• 运维管理
• 运营管理

面临的主要问题

• 分布式系统的硬件故障发生率更高 运维流程自动化
• 良好设计服务
• 容量的可伸缩性
• 使用标准的协议
• 流程的优化
• 管理各个服务的容量
• 分布式存储 事务变得复杂
• 测试和查错的复杂度增大
• 系统的吞吐量变大 响应时间会变长

解决方案

• 监控系统
• 依赖链
• 重构 服务化

分布式系统 流量与数据调度

流量调度 很多与服务治理混为一谈

更是外部接入层的事情

• 自动进行流量调度 无需人工干预的情况下 提升系统的稳定性

• 应对突发事件

• 服务流控

• 流量控制

• 流量管理

• 高性能

• 扛流量
• 业务逻辑
• 服务化

API gateway 目前是陈皓老师的创业方向

状态数据调度

分布式事务一致性的问题

数据冗余的方法 数据分区 每个区也需要进行数据冗余处理

• ms方案
• mm方案
• 两阶段和三阶段提交方案
• paxos方案

基本上是基于两阶段的提交的变种 通过业务补偿

状态数据调度

• 目前是两阶段提交
• 底层存储通过算法模型来解决
• 分布式存储系统解决

全栈监控

全栈系统监控的东西 像是我们的眼睛

• 全栈监控
• 关联分析
• 跨系统调用的串联
• 实时报警和自动处置
• 系统性能分析

基础层 CPU 内存等

中间层 nginx、redis

应用层 http访问的吞吐量

• 日志数据结构化
• 监控数据格式标准化
• 统一的监控平台

• 统一的日志分析

• 关注于整体应用的SLA

• 关联指标聚合
• 快速故障定位

最佳实践是谷歌家的dapper 开源实现是zipkin

业务的日志采集

服务治理

可能混淆了流量调度等其他内容

• 服务关键程度
• 服务依赖关系
• 服务发现
• 整个架构的版本管理
• 服务应用生命周期全管理

没有依赖就没有伤害

微服务是服务依赖最优解的上限

spring boot开了好头

zipkin 服务调用跟踪系统

• provision 新的服务
• ready
• run
• update
• rollback
• scale 在伸缩当中
• destory
• failed

• 底层资源的伸缩
• 服务的自动化部署
• 服务的健康检查
• 服务发现的注册
• 服务流量的调度

宠物模式 救活
奶牛模式 重新生成一个实例

分布式的技术栈

增加系统容量 提高系统的可用性

• 大流量处理
• 关键业务保护

提高整体架构的吞吐量 服务更多的并发和流量

提高系统的稳定性 让系统的可用性更高

• 加缓存
• 负载均衡
• 异步调用
• 数据镜像
• 数据分区

初期是读写分离 后期是分库分表

稳定性

• 服务拆分
• 服务冗余
• 降级限流
• 高可用架构

• 高可用运维

• 服务治理

• 架构软件管理
• devops
• 自动化运维
• 资源调度管理
• 整体架构监控
• 流量控制

docker k8s

五个关键技术

• 全栈系统监控
• 服务/资源调度
• 流量调度
• 状态/数据调度
• 开发和运维的自动化