xinyin025/learn.lianglianglee.com
1
0
Fork 0
mirror of https://github.com/zhwei820/learn.lianglianglee.com.git synced 2025-09-30 23:26:43 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity
48163c6373
learn.lianglianglee.com/专栏/左耳听风/021 从亚马逊的实践，谈分布式系统的难点.md.html
周伟 48163c6373 y
2022-05-11 18:52:13 +08:00

1801 lines
45 KiB
HTML
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<!DOCTYPE html>
<!-- saved from url=(0046)https://kaiiiz.github.io/hexo-theme-book-demo/ -->
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1.0, user-scalable=no">
<link rel="icon" href="/static/favicon.png">
<title>021 从亚马逊的实践，谈分布式系统的难点.md.html</title>
<!-- Spectre.css framework -->
<link rel="stylesheet" href="/static/index.css">
<!-- theme css & js -->
<meta name="generator" content="Hexo 4.2.0">
</head>
<body>
<div class="book-container">
<div class="book-sidebar">
<div class="book-brand">
<a href="/">
<img src="/static/favicon.png">
<span>技术文章摘抄</span>
</a>
</div>
<div class="book-menu uncollapsible">
<ul class="uncollapsible">
<li><a href="/" class="current-tab">首页</a></li>
</ul>
<ul class="uncollapsible">
<li><a href="../">上一级</a></li>
</ul>
<ul class="uncollapsible">
<li>
<a href="/专栏/左耳听风/000 开篇词 洞悉技术的本质，享受科技的乐趣.md">000 开篇词 洞悉技术的本质，享受科技的乐趣.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/001 程序员如何用技术变现（上）.md">001 程序员如何用技术变现（上）.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/002 程序员如何用技术变现（下）.md">002 程序员如何用技术变现（下）.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/003 Equifax信息泄露始末.md">003 Equifax信息泄露始末.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/004 从Equifax信息泄露看数据安全.md">004 从Equifax信息泄露看数据安全.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/005 何为技术领导力.md">005 何为技术领导力.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/006 如何拥有技术领导力.md">006 如何拥有技术领导力.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/007 推荐阅读：每个程序员都该知道的事.md">007 推荐阅读：每个程序员都该知道的事.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/008 Go语言，Docker和新技术.md">008 Go语言，Docker和新技术.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/009 答疑解惑：渴望、热情和选择.md">009 答疑解惑：渴望、热情和选择.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/010 如何成为一个大家愿意追随的Leader？.md">010 如何成为一个大家愿意追随的Leader？.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/011 程序中的错误处理：错误返回码和异常捕捉.md">011 程序中的错误处理：错误返回码和异常捕捉.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/012 程序中的错误处理：异步编程和最佳实践.md">012 程序中的错误处理：异步编程和最佳实践.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/013 魔数 0x5f3759df.md">013 魔数 0x5f3759df.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/014 推荐阅读：机器学习101.md">014 推荐阅读：机器学习101.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/015 时间管理：同扭曲时间的事儿抗争.md">015 时间管理：同扭曲时间的事儿抗争.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/016 时间管理：投资赚取时间.md">016 时间管理：投资赚取时间.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/017 故障处理最佳实践：应对故障.md">017 故障处理最佳实践：应对故障.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/018 故障处理最佳实践：故障改进.md">018 故障处理最佳实践：故障改进.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/019 答疑解惑：我们应该能够识别的表象和本质.md">019 答疑解惑：我们应该能够识别的表象和本质.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/020 分布式系统架构的冰与火.md">020 分布式系统架构的冰与火.md.html</a>
</li>
<li>
<a class="current-tab" href="/专栏/左耳听风/021 从亚马逊的实践，谈分布式系统的难点.md">021 从亚马逊的实践，谈分布式系统的难点.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/022 分布式系统的技术栈.md">022 分布式系统的技术栈.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/023 分布式系统关键技术：全栈监控.md">023 分布式系统关键技术：全栈监控.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/024 分布式系统关键技术：服务调度.md">024 分布式系统关键技术：服务调度.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/025 分布式系统关键技术：流量与数据调度.md">025 分布式系统关键技术：流量与数据调度.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/026 洞悉PaaS平台的本质.md">026 洞悉PaaS平台的本质.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/027 推荐阅读：分布式系统架构经典资料.md">027 推荐阅读：分布式系统架构经典资料.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/028 编程范式游记（1）- 起源.md">028 编程范式游记（1）- 起源.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/029 编程范式游记（2）- 泛型编程.md">029 编程范式游记（2）- 泛型编程.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/030 编程范式游记（3） - 类型系统和泛型的本质.md">030 编程范式游记（3） - 类型系统和泛型的本质.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/031 Git协同工作流，你该怎样选.md">031 Git协同工作流，你该怎样选.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/032 推荐阅读：分布式数据调度相关论文.md">032 推荐阅读：分布式数据调度相关论文.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/033 编程范式游记（4）- 函数式编程.md">033 编程范式游记（4）- 函数式编程.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/034 编程范式游记（5）- 修饰器模式.md">034 编程范式游记（5）- 修饰器模式.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/035 编程范式游记（6）- 面向对象编程.md">035 编程范式游记（6）- 面向对象编程.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/036 编程范式游记（7）- 基于原型的编程范式.md">036 编程范式游记（7）- 基于原型的编程范式.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/037 编程范式游记（8）- Go 语言的委托模式.md">037 编程范式游记（8）- Go 语言的委托模式.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/038 编程范式游记（9）- 编程的本质.md">038 编程范式游记（9）- 编程的本质.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/039 编程范式游记（10）- 逻辑编程范式.md">039 编程范式游记（10）- 逻辑编程范式.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/040 编程范式游记（11）- 程序世界里的编程范式.md">040 编程范式游记（11）- 程序世界里的编程范式.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/041 弹力设计篇之“认识故障和弹力设计”.md">041 弹力设计篇之“认识故障和弹力设计”.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/042 弹力设计篇之“隔离设计”.md">042 弹力设计篇之“隔离设计”.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/043 弹力设计篇之“异步通讯设计”.md">043 弹力设计篇之“异步通讯设计”.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/044 弹力设计篇之“幂等性设计”.md">044 弹力设计篇之“幂等性设计”.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/045 弹力设计篇之“服务的状态”.md">045 弹力设计篇之“服务的状态”.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/046 弹力设计篇之“补偿事务”.md">046 弹力设计篇之“补偿事务”.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/047 弹力设计篇之“重试设计”.md">047 弹力设计篇之“重试设计”.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/048 弹力设计篇之“熔断设计”.md">048 弹力设计篇之“熔断设计”.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/049 弹力设计篇之“限流设计”.md">049 弹力设计篇之“限流设计”.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/050 弹力设计篇之“降级设计”.md">050 弹力设计篇之“降级设计”.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/051 弹力设计篇之“弹力设计总结”.md">051 弹力设计篇之“弹力设计总结”.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/052 区块链技术 - 区块链的革命性及技术概要.md">052 区块链技术 - 区块链的革命性及技术概要.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/053 区块链技术 - 区块链技术细节 - 哈希算法.md">053 区块链技术 - 区块链技术细节 - 哈希算法.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/054 区块链技术 - 区块链技术细节 - 加密和挖矿.md">054 区块链技术 - 区块链技术细节 - 加密和挖矿.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/055 区块链技术 - 去中心化的共识机制.md">055 区块链技术 - 去中心化的共识机制.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/056 区块链技术 - 智能合约.md">056 区块链技术 - 智能合约.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/057 区块链技术 - 传统金融和虚拟货币.md">057 区块链技术 - 传统金融和虚拟货币.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/058 管理设计篇之分布式锁.md">058 管理设计篇之分布式锁.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/059 管理设计篇之配置中心.md">059 管理设计篇之配置中心.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/060 管理设计篇之边车模式.md">060 管理设计篇之边车模式.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/061 管理设计篇之服务网格.md">061 管理设计篇之服务网格.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/062 管理设计篇之网关模式.md">062 管理设计篇之网关模式.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/063 管理设计篇之部署升级策略.md">063 管理设计篇之部署升级策略.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/064 性能设计篇之缓存.md">064 性能设计篇之缓存.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/065 性能设计篇之异步处理.md">065 性能设计篇之异步处理.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/066 性能设计篇之数据库扩展.md">066 性能设计篇之数据库扩展.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/067 性能设计篇之秒杀.md">067 性能设计篇之秒杀.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/068 性能设计篇之边缘计算.md">068 性能设计篇之边缘计算.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/069 程序员练级攻略（2018）：开篇词.md">069 程序员练级攻略（2018）：开篇词.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/070 程序员练级攻略（2018）：零基础启蒙.md">070 程序员练级攻略（2018）：零基础启蒙.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/071 程序员练级攻略（2018）：正式入门.md">071 程序员练级攻略（2018）：正式入门.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/072 程序员练级攻略（2018）：程序员修养.md">072 程序员练级攻略（2018）：程序员修养.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/073 程序员练级攻略（2018）：编程语言.md">073 程序员练级攻略（2018）：编程语言.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/074 程序员练级攻略：理论学科.md">074 程序员练级攻略：理论学科.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/075 程序员练级攻略（2018）：系统知识.md">075 程序员练级攻略（2018）：系统知识.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/076 程序员练级攻略（2018）：软件设计.md">076 程序员练级攻略（2018）：软件设计.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/077 程序员练级攻略（2018）：Linux系统、内存和网络.md">077 程序员练级攻略（2018）：Linux系统、内存和网络.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/078 程序员练级攻略（2018）：异步IO模型和Lock-Free编程.md">078 程序员练级攻略（2018）：异步IO模型和Lock-Free编程.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/079 程序员练级攻略（2018）：Java底层知识.md">079 程序员练级攻略（2018）：Java底层知识.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/080 程序员练级攻略（2018）：数据库.md">080 程序员练级攻略（2018）：数据库.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/081 程序员练级攻略（2018）：分布式架构入门.md">081 程序员练级攻略（2018）：分布式架构入门.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/082 程序员练级攻略（2018）：分布式架构经典图书和论文.md">082 程序员练级攻略（2018）：分布式架构经典图书和论文.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/083 程序员练级攻略（2018）：分布式架构工程设计.md">083 程序员练级攻略（2018）：分布式架构工程设计.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/084 程序员练级攻略（2018）：微服务.md">084 程序员练级攻略（2018）：微服务.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/085 程序员练级攻略（2018）：容器化和自动化运维.md">085 程序员练级攻略（2018）：容器化和自动化运维.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/086 程序员练级攻略（2018）：机器学习和人工智能.md">086 程序员练级攻略（2018）：机器学习和人工智能.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/087 程序员练级攻略（2018）：前端基础和底层原理.md">087 程序员练级攻略（2018）：前端基础和底层原理.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/088 程序员练级攻略（2018）：前端性能优化和框架.md">088 程序员练级攻略（2018）：前端性能优化和框架.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/089 程序员练级攻略（2018）：UIUX设计.md">089 程序员练级攻略（2018）：UIUX设计.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/090 程序员练级攻略（2018）：技术资源集散地.md">090 程序员练级攻略（2018）：技术资源集散地.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/091 程序员面试攻略：面试前的准备.md">091 程序员面试攻略：面试前的准备.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/092 程序员面试攻略：面试中的技巧.md">092 程序员面试攻略：面试中的技巧.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/093 程序员面试攻略：面试风格.md">093 程序员面试攻略：面试风格.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/094 程序员面试攻略：实力才是王中王.md">094 程序员面试攻略：实力才是王中王.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/095 高效学习：端正学习态度.md">095 高效学习：端正学习态度.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/096 高效学习：源头、原理和知识地图.md">096 高效学习：源头、原理和知识地图.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/097 高效学习：深度，归纳和坚持实践.md">097 高效学习：深度，归纳和坚持实践.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/098 高效学习：如何学习和阅读代码.md">098 高效学习：如何学习和阅读代码.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/099 高效学习：面对枯燥和量大的知识.md">099 高效学习：面对枯燥和量大的知识.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/100 高效沟通：Talk和Code同等重要.md">100 高效沟通：Talk和Code同等重要.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/101 高效沟通：沟通阻碍和应对方法.md">101 高效沟通：沟通阻碍和应对方法.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/102 高效沟通：沟通方式及技巧.md">102 高效沟通：沟通方式及技巧.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/103 高效沟通：沟通技术.md">103 高效沟通：沟通技术.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/104 高效沟通：好老板要善于提问.md">104 高效沟通：好老板要善于提问.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/105 高效沟通：好好说话的艺术.md">105 高效沟通：好好说话的艺术.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/106 加餐 谈谈我的“三观”.md">106 加餐 谈谈我的“三观”.md.html</a>
</li>
<li>
<a href="/专栏/左耳听风/107 结束语 业精于勤，行成于思.md">107 结束语 业精于勤，行成于思.md.html</a>
</li>
</ul>
</div>
</div>
<div class="sidebar-toggle" onclick="sidebar_toggle()" onmouseover="add_inner()" onmouseleave="remove_inner()">
<div class="sidebar-toggle-inner"></div>
</div>
<script>
function add_inner() {
let inner = document.querySelector('.sidebar-toggle-inner')
inner.classList.add('show')
}
function remove_inner() {
let inner = document.querySelector('.sidebar-toggle-inner')
inner.classList.remove('show')
}
function sidebar_toggle() {
let sidebar_toggle = document.querySelector('.sidebar-toggle')
let sidebar = document.querySelector('.book-sidebar')
let content = document.querySelector('.off-canvas-content')
if (sidebar_toggle.classList.contains('extend')) { // show
sidebar_toggle.classList.remove('extend')
sidebar.classList.remove('hide')
content.classList.remove('extend')
} else { // hide
sidebar_toggle.classList.add('extend')
sidebar.classList.add('hide')
content.classList.add('extend')
}
}
function open_sidebar() {
let sidebar = document.querySelector('.book-sidebar')
let overlay = document.querySelector('.off-canvas-overlay')
sidebar.classList.add('show')
overlay.classList.add('show')
}
function hide_canvas() {
let sidebar = document.querySelector('.book-sidebar')
let overlay = document.querySelector('.off-canvas-overlay')
sidebar.classList.remove('show')
overlay.classList.remove('show')
}
</script>
<div class="off-canvas-content">
<div class="columns">
<div class="column col-12 col-lg-12">
<div class="book-navbar">
<!-- For Responsive Layout -->
<header class="navbar">
<section class="navbar-section">
<a onclick="open_sidebar()">
<i class="icon icon-menu"></i>
</a>
</section>
</header>
</div>
<div class="book-content" style="max-width: 960px; margin: 0 auto;
overflow-x: auto;
overflow-y: hidden;">
<div class="book-post">
<p id="tip" align="center"></p>
<div><h1>021 从亚马逊的实践，谈分布式系统的难点</h1>
<p>从目前可以得到的信息来看，对分布式服务化架构实践最早的应该是亚马逊。因为早在 2002 年的时候，亚马逊 CEO 杰夫·贝索斯（Jeff Bezos）就向全公司颁布了下面的这几条架构规定（来自《<a href="https://coolshell.cn/articles/5701.html">Steve Yegge 对 Google 平台吐槽</a>》一文）。</p>
<ol>
<li>所有团队的程序模块都要通过 Service Interface 方式将其数据与功能开放出来。</li>
<li>团队间程序模块的信息通信，都要通过这些接口。</li>
<li>除此之外没有其它的通信方式。其他形式一概不允许：不能直接链结别的程序（把其他团队的程序当做动态链接库来链接），不能直接读取其他团队的数据库，不能使用共享内存模式，不能使用别人模块的后门，等等。唯一允许的通信方式是调用 Service Interface。</li>
<li>任何技术都可以使用。比如：HTTP、CORBA、Pub/Sub、自定义的网络协议等。</li>
<li>所有的 Service Interface，毫无例外，都必须从骨子里到表面上设计成能对外界开放的。也就是说，团队必须做好规划与设计，以便未来把接口开放给全世界的程序员，没有任何例外。</li>
<li>不这样做的人会被炒鱿鱼。</li>
</ol>
<p>这应该就是 AWS（Amazon Web Service）出现的基因吧。当然，前面说过，采用分布式系统架构后会出现很多的问题。比如：</p>
<ul>
<li>一个线上故障的工单会在不同的服务和不同的团队中转过来转过去的。</li>
<li>每个团队都可能成为一个潜在的 DDoS 攻击者，除非每个服务都要做好配额和限流。</li>
<li>监控和查错变得更为复杂。除非有非常强大的监控手段。</li>
<li>服务发现和服务治理也变得非常复杂。</li>
</ul>
<p>为了克服这些问题，亚马逊这么多年的实践让其可以运维和管理极其复杂的分布式服务架构。我觉得主要有以下几点。</p>
<ol>
<li><strong>分布式服务的架构需要分布式的团队架构</strong>。在亚马逊，一个服务由一个小团队（Two Pizza Team 不超过 16 个人，两张 Pizza 可以喂饱的团队）负责，从前端负责到数据，从需求分析负责到上线运维。这是良性的分工策略——按职责分工，而不是按技能分工。</li>
<li><strong>分布式服务查错不容易</strong>。一旦出现比较严重的故障，需要整体查错。出现一个 S2 的故障，就可以看到每个团队的人都会上线。在工单系统里能看到，在故障发生的一开始，大家都在签到并自查自己的系统。如果没问题，也要在线待命（standby），等问题解决。（我在《故障处理最佳实践：应对故障》一文中详细地讲过这个事）。</li>
<li><strong>没有专职的测试人员，也没有专职的运维人员，开发人员做所有的事情</strong>。开发人员做所有事情的好处是——吃自己的狗粮（Eat Your Own Dog Food） 最微观的实践。自己写的代码自己维护自己养，会让开发人员明白，写代码容易维护代码复杂。这样，开发人员在接需求、做设计、写代码、做工具时都会考虑到软件的长期维护性。</li>
<li><strong>运维优先，崇尚简化和自动化</strong>。为了能够运维如此复杂的系统，亚马逊内部在运维上下了非常大的功夫。现在人们所说的 DevOps 这个事，亚马逊在 10 多年前就做到了。亚马逊最为强大的就是运维，拼命地对系统进行简化和自动化，让亚马逊做到了可以轻松运维拥有上千万台虚机的 AWS 云平台。</li>
<li><strong>内部服务和外部服务一致</strong>。无论是从安全方面，还是接口设计方面，无论是从运维方面，还是故障处理的流程方面，亚马逊的内部系统都和外部系统一样对待。这样做的好处是，内部系统的服务随时都可以开放出来。而且，从第一天开始，服务提供方就有对外服务的能力。可以想像，以这样的标准运作的团队其能力会是什么样的。</li>
</ol>
<p>在进化的过程中，亚马逊遇到的问题很多，甚至还有很多几乎没有人会想到的非常生僻的东西，它都一一学习和总结了，而且都解决得很好。</p>
<p>构建分布式系统非常难，充满了各种各样的问题，但亚马逊还是毫不犹豫地走了下去。这是因为亚马逊想做平台，不是“像淘宝这样的中介式流量平台”，而是那种“可以对外输出能力的平台”。</p>
<p>亚马逊觉得自己没有像史蒂夫·乔布斯（Steve Jobs）这样的牛人，不可能做出像 iPhone 这样的爆款产品，而且用户天生就是众口难调，与其做一个大家都不满意的软件，还不如把一些基础能力对外输出，引入外部的力量来一起完成一个用户满意的产品。这其实就是在建立自己的生态圈。虽然在今天看来这个事已经不稀奇了，但是贝索斯早在十五年前就悟到了，实在是个天才。</p>
<p>所以，分布式服务架构是需要从组织，到软件工程，再到技术上的一个大的改造，需要比较长的时间来磨合和改进，并不断地总结教训和成功经验。</p>
<h1>分布式系统中需要注意的问题</h1>
<p>我们再来看一下分布式系统在技术上需要注意的问题。</p>
<h1>问题一：异构系统的不标准问题</h1>
<p>这主要表现在：</p>
<ul>
<li>软件和应用不标准。</li>
<li>通讯协议不标准。</li>
<li>数据格式不标准。</li>
<li>开发和运维的过程和方法不标准。</li>
</ul>
<p>不同的软件，不同的语言会出现不同的兼容性和不同的开发、测试、运维标准。不同的标准会让我们用不同的方式来开发和运维，引起架构复杂度的提升。比如：有的软件修改配置要改它的.conf 文件，而有的则是调用管理 API 接口。</p>
<p>在通讯方面，不同的软件用不同的协议，就算是相同的网络协议里也会出现不同的数据格式。还有，不同的团队因为用不同的技术，会有不同的开发和运维方式。这些不同的东西，会让我们的整个分布式系统架构变得异常复杂。所以，分布式系统架构需要有相应的规范。</p>
<p>比如，我看到，很多服务的 API 出错不返回 HTTP 的错误状态码，而是返回个正常的状态码 200，然后在 HTTP Body 里的 JSON 字符串中写着个：error，bla bla error message。这简直就是一种反人类的做法。我实在不明白为什么会有众多这样的设计。这让监控怎么做啊？现在，你应该使用 Swagger 的规范了。</p>
<p>再比如，我看到很多公司的软件配置管理里就是一个 key-value 的东西，这样的东西灵活到可以很容易地被滥用。不规范的配置命名，不规范的值，甚至在配置中直接嵌入前端展示内容……</p>
<p>一个好的配置管理，应该分成三层：底层和操作系统相关，中间层和中间件相关，最上面和业务应用相关。于是底层和中间层是不能让用户灵活修改的，而是只让用户选择。比如：操作系统的相关配置应该形成模板来让人选择，而不是让人乱配置的。只有配置系统形成了规范，我们才 hold 得住众多的系统。</p>
<p>再比如：数据通讯协议。通常来说，作为一个协议，一定要有协议头和协议体。协议头定义了最基本的协议数据，而协议体才是真正的业务数据。对于协议头，我们需要非常规范地让每一个使用这个协议的团队都使用一套标准的方式来定义，这样我们才容易对请求进行监控、调度和管理。</p>
<p>这样的规范还有很多，我在这就不一一列举了。</p>
<h1>问题二：系统架构中的服务依赖性问题</h1>
<p>对于传统的单体应用，一台机器挂了，整个软件就挂掉了。但是你千万不要以为在分布式的架构下不会发生这样的事。分布式架构下，服务是会有依赖的，于是一个服务依赖链上，某个服务挂掉了，会导致出现“多米诺骨牌”效应，会倒一片。</p>
<p>所以，在分布式系统中，服务的依赖也会带来一些问题。</p>
<ul>
<li>如果非关键业务被关键业务所依赖，会导致非关键业务变成一个关键业务。</li>
<li>服务依赖链中，出现“木桶短板效应”——整个 SLA 由最差的那个服务所决定。</li>
</ul>
<p>这是服务治理的内容了。服务治理不但需要我们定义出服务的关键程度，还需要我们定义或是描述出关键业务或服务调用的主要路径。没有这个事情，我们将无法运维或是管理整个系统。</p>
<p>这里需要注意的是，很多分布式架构在应用层上做到了业务隔离，然而，在数据库结点上并没有。如果一个非关键业务把数据库拖死，那么会导致全站不可用。所以，数据库方面也需要做相应的隔离。也就是说，最好一个业务线用一套自己的数据库。这就是亚马逊服务器的实践——系统间不能读取对方的数据库，只通过服务接口耦合。这也是微服务的要求。我们不但要拆分服务，还要为每个服务拆分相应的数据库。</p>
<h1>问题三：故障发生的概率更大</h1>
<p>在分布式系统中，因为使用的机器和服务会非常多，所以，故障发生的频率会比传统的单体应用更大。只不过，单体应用的故障影响面很大，而分布式系统中，虽然故障的影响面可以被隔离，但是因为机器和服务多，出故障的频率也会多。另一方面，因为管理复杂，而且没人知道整个架构中有什么，所以非常容易犯错误。</p>
<p>你会发现，对分布式系统架构的运维，简直就是一场噩梦。我们会慢慢地明白下面这些道理。</p>
<ul>
<li>出现故障不可怕，故障恢复时间过长才可怕。</li>
<li>出现故障不可怕，故障影响面过大才可怕。</li>
</ul>
<p>运维团队在分布式系统下会非常忙，忙到每时每刻都要处理大大小小的故障。我看到，很多大公司，都在自己的系统里拼命地添加各种监控指标，有的能够添加出几万个监控指标。我觉得这完全是在“使蛮力”。一方面，信息太多等于没有信息，另一方面，SLA 要求我们定义出“Key Metrics”，也就是所谓的关键指标。然而，他们却没有。这其实是一种思维上的懒惰。</p>
<p>但是，上述的都是在“救火阶段”而不是“防火阶段”。所谓“防火胜于救火”，我们还要考虑如何防火，这需要我们在设计或运维系统时都要为这些故障考虑，即所谓 Design for Failure。在设计时就要考虑如何减轻故障。如果无法避免，也要使用自动化的方式恢复故障，减少故障影响面。</p>
<p>因为当机器和服务数量越来越多时，你会发现，人类的缺陷就成为了瓶颈。这个缺陷就是人类无法对复杂的事情做到事无巨细的管理，只有机器自动化才能帮助人类。 也就是，人管代码，代码管机器，人不管机器！</p>
<h1>问题四：多层架构的运维复杂度更大</h1>
<p>通常来说，我们可以把系统分成四层：基础层、平台层、应用层和接入层。</p>
<ul>
<li>基础层就是我们的机器、网络和存储设备等。</li>
<li>平台层就是我们的中间件层，Tomcat、MySQL、Redis、Kafka 之类的软件。</li>
<li>应用层就是我们的业务软件，比如，各种功能的服务。</li>
<li>接入层就是接入用户请求的网关、负载均衡或是 CDN、DNS 这样的东西。</li>
</ul>
<p>对于这四层，我们需要知道：</p>
<ul>
<li>任何一层的问题都会导致整体的问题；</li>
<li>没有统一的视图和管理，导致运维被割裂开来，造成更大的复杂度。</li>
</ul>
<p>很多公司都是按技能分工是，把技术团队分为产品开发、中间件开发、业务运维、系统运维等子团队。这样的分工导致各管一摊，很多事情完全连不在一起。整个系统会像 “多米诺骨牌”一样，一个环节出现问题，就会倒下去一大片。因为没有一个统一的运维视图，不知道一个服务调用是如何经过每一个服务和资源，也就导致我们在出现故障时要花大量的时间在沟通和定位问题上。</p>
<p>之前我在某云平台的一次经历就是这样的。从接入层到负载均衡，再到服务层，再到操作系统底层，设置的 KeepAlive 的参数完全不一致，导致用户发现，软件运行的行为和文档中定义的完全不一样。工程师查错的过程简直就是一场恶梦，以为找到了一个，结果还有一个，来来回回花了大量的时间才把所有 KeepAlive 的参数设置成一致的，浪费了太多的时间。</p>
<p><strong>分工不是问题，问题是分工后的协作是否统一和规范</strong>。这点，你一定要重视。</p>
<h1>小结</h1>
<p>好了，我们来总结一下今天分享的主要内容。首先，我以亚马逊为例，讲述了它是如何做分布式服务架构的，遇到了哪些问题，以及是如何解决的。我认为，亚马逊在分布式服务系统方面的这些实践和经验积累，是 AWS 出现的基因。随后分享了在分布式系统中需要注意的几个问题，同时给出了应对方案。</p>
<p>我认为，构建分布式服务需要从组织，到软件工程，再到技术上的一次大的改造，需要比较长的时间来磨合和改进，并不断地总结教训和成功经验。下篇文章中，我们讲述分布式系统的技术栈。希望对你有帮助。</p>
<p>也欢迎大家分享一下你在分布式架构中遇到的各种问题。</p>
</div>
</div>
<div>
<div style="float: left">
<a href="/专栏/左耳听风/020 分布式系统架构的冰与火.md">上一页</a>
</div>
<div style="float: right">
<a href="/专栏/左耳听风/022 分布式系统的技术栈.md">下一页</a>
</div>
</div>
</div>
</div>
</div>
</div>
<a class="off-canvas-overlay" onclick="hide_canvas()"></a>
</div>
<script defer src="https://static.cloudflareinsights.com/beacon.min.js/v652eace1692a40cfa3763df669d7439c1639079717194" integrity="sha512-Gi7xpJR8tSkrpF7aordPZQlW2DLtzUlZcumS8dMQjwDHEnw9I7ZLyiOj/6tZStRBGtGgN6ceN6cMH8z7etPGlw==" data-cf-beacon='{"rayId":"709977f5186d3cfa","version":"2021.12.0","r":1,"token":"1f5d475227ce4f0089a7cff1ab17c0f5","si":100}' crossorigin="anonymous"></script>
</body>
<!-- Global site tag (gtag.js) - Google Analytics -->
<script async src="https://www.googletagmanager.com/gtag/js?id=G-NPSEEVD756"></script>
<script>
window.dataLayer = window.dataLayer || [];
function gtag() {
dataLayer.push(arguments);
}
gtag('js', new Date());
gtag('config', 'G-NPSEEVD756');
var path = window.location.pathname
var cookie = getCookie("lastPath");
console.log(path)
if (path.replace("/", "") === "") {
if (cookie.replace("/", "") !== "") {
console.log(cookie)
document.getElementById("tip").innerHTML = "<a href='" + cookie + "'>跳转到上次进度</a>"
}
} else {
setCookie("lastPath", path)
}
function setCookie(cname, cvalue) {
var d = new Date();
d.setTime(d.getTime() + (180 * 24 * 60 * 60 * 1000));
var expires = "expires=" + d.toGMTString();
document.cookie = cname + "=" + cvalue + "; " + expires + ";path = /";
}
function getCookie(cname) {
var name = cname + "=";
var ca = document.cookie.split(';');
for (var i = 0; i < ca.length; i++) {
var c = ca[i].trim();
if (c.indexOf(name) === 0) return c.substring(name.length, c.length);
}
return "";
}
</script>
</html>
Reference in New Issue View Git Blame Copy Permalink