左耳听风
陈皓
网名“左耳朵耗子”,资深技术专家,骨灰级程序员
立即订阅
40357 人已学习
课程目录
已完结 108 讲
0/6登录后,你可以任选6讲全文学习。
开篇词 | 洞悉技术的本质,享受科技的乐趣
免费
01 | 程序员如何用技术变现(上)
02 | 程序员如何用技术变现(下)
03 | Equifax信息泄露始末
04 | 从Equifax信息泄露看数据安全
05 | 何为技术领导力?
06 | 如何才能拥有技术领导力?
07 | 推荐阅读:每个程序员都该知道的知识
08 | Go语言,Docker和新技术
09 | 答疑解惑:渴望、热情和选择
10 | 如何成为一个大家愿意追随的Leader?
11 | 程序中的错误处理:错误返回码和异常捕捉
12 | 程序中的错误处理:异步编程以及我的最佳实践
13 | 魔数 0x5f3759df
14 | 推荐阅读:机器学习101
15 | 时间管理:同扭曲时间的事儿抗争
16 | 时间管理:如何利用好自己的时间?
17 | 故障处理最佳实践:应对故障
18 | 故障处理最佳实践:故障改进
19 | 答疑解惑:我们应该能够识别的表象和本质
20 | Git协同工作流,你该怎么选?
21 | 分布式系统架构的冰与火
22 | 从亚马逊的实践,谈分布式系统的难点
23 | 分布式系统的技术栈
24 | 分布式系统关键技术:全栈监控
25 | 分布式系统关键技术:服务调度
26 | 分布式系统关键技术:流量与数据调度
27 | 洞悉PaaS平台的本质
28 | 推荐阅读:分布式系统架构经典资料
29 | 推荐阅读:分布式数据调度相关论文
30 | 编程范式游记(1)- 起源
31 | 编程范式游记(2)- 泛型编程
32 | 编程范式游记(3) - 类型系统和泛型的本质
33 | 编程范式游记(4)- 函数式编程
34 | 编程范式游记(5)- 修饰器模式
35 | 编程范式游记(6)- 面向对象编程
36 | 编程范式游记(7)- 基于原型的编程范式
37 | 编程范式游记(8)- Go 语言的委托模式
38 | 编程范式游记(9)- 编程的本质
39 | 编程范式游记(10)- 逻辑编程范式
40 | 编程范式游记(11)- 程序世界里的编程范式
41 | 弹力设计篇之“认识故障和弹力设计”
42 | 弹力设计篇之“隔离设计”
43 | 弹力设计篇之“异步通讯设计”
44 | 弹力设计篇之“幂等性设计”
45 | 弹力设计篇之“服务的状态”
46 | 弹力设计篇之“补偿事务”
47 | 弹力设计篇之“重试设计”
48 | 弹力设计篇之“熔断设计”
49 | 弹力设计篇之“限流设计”
50 | 弹力设计篇之“降级设计”
51 | 弹力设计篇之“弹力设计总结”
52 | 管理设计篇之“分布式锁”
53 | 管理设计篇之“配置中心”
54 | 管理设计篇之“边车模式”
55 | 管理设计篇之“服务网格”
56 | 管理设计篇之“网关模式”
57 | 管理设计篇之“部署升级策略”
58 | 性能设计篇之“缓存”
59 | 性能设计篇之“异步处理”
60 | 性能设计篇之“数据库扩展”
61 | 性能设计篇之“秒杀”
62 | 性能设计篇之“边缘计算”
63 | 区块链技术的本质
64 | 区块链技术细节:哈希算法
65 | 区块链技术细节:加密和挖矿
66 | 区块链技术细节:去中心化的共识机制
67 | 区块链技术细节:智能合约
68 | 区块链技术 - 传统金融和虚拟货币
69 | 程序员练级攻略:开篇词
70 | 程序员练级攻略:零基础启蒙
71 | 程序员练级攻略:正式入门
72 | 程序员练级攻略:程序员修养
73 | 程序员练级攻略:编程语言
74 | 程序员练级攻略:理论学科
75 | 程序员练级攻略:系统知识
76 | 程序员练级攻略:软件设计
77 | 程序员练级攻略:Linux系统、内存和网络
78 | 程序员练级攻略:异步I/O模型和Lock-Free编程
79 | 程序员练级攻略:Java底层知识
80 | 程序员练级攻略:数据库
81 | 程序员练级攻略:分布式架构入门
82 | 程序员练级攻略:分布式架构经典图书和论文
83 | 程序员练级攻略:分布式架构工程设计
84 | 程序员练级攻略:微服务
85 | 程序员练级攻略:容器化和自动化运维
86 | 程序员练级攻略:机器学习和人工智能
87 | 程序员练级攻略:前端基础和底层原理
88 | 程序员练级攻略:前端性能优化和框架
89 | 程序员练级攻略:UI/UX设计
90 | 程序员练级攻略:技术资源集散地
91 | 程序员面试攻略:面试前的准备
92 | 程序员面试攻略:面试中的技巧
93 | 程序员面试攻略:面试风格
94 | 程序员面试攻略:实力才是王中王
95 | 高效学习:端正学习态度
96 | 高效学习:源头、原理和知识地图
97 | 高效学习:深度,归纳和坚持实践
98 | 高效学习:如何学习和阅读代码
99 | 高效学习:面对枯燥和量大的知识
左耳听风
登录|注册

22 | 从亚马逊的实践,谈分布式系统的难点

陈皓 2017-12-14
从目前已经公开的资料来看,分布式服务化架构思想实践最早的公司应该是亚马逊。因为早在 2002 年的时候,亚马逊 CEO 杰夫·贝索斯(Jeff Bezos)就向全公司颁布了下面的这几条架构规定(来自《Steve Yegge 对 Google 平台吐槽》一文)。
所有团队的程序模块都要通过 Service Interface 方式将其数据与功能开放出来。
团队间程序模块的信息通信,都要通过这些接口。
除此之外没有其它的通信方式。其他形式一概不允许:不能直接链结别的程序(把其他团队的程序当做动态链接库来链接),不能直接读取其他团队的数据库,不能使用共享内存模式,不能使用别人模块的后门,等等。唯一允许的通信方式是调用 Service Interface。
任何技术都可以使用。比如:HTTP、CORBA、Pub/Sub、自定义的网络协议等。
所有的 Service Interface,毫无例外,都必须从骨子里到表面上设计成能对外界开放的。也就是说,团队必须做好规划与设计,以便未来把接口开放给全世界的程序员,没有任何例外。
不这样做的人会被炒鱿鱼。
这应该就是 AWS(Amazon Web Service)出现的基因吧。当然,前面说过,采用分布式系统架构后会出现很多的问题。比如:
一个线上故障的工单会在不同的服务和不同的团队中转过来转过去。
每个团队都可能成为一个潜在的 DDoS 攻击者,除非每个服务都要做好配额和限流。
监控和查错变得更为复杂。除非有非常强大的监控手段。
服务发现和服务治理也变得非常复杂。
为了克服这些问题,亚马逊这么多年的实践让其可以运维和管理极其复杂的分布式服务架构。我觉得主要有以下几点。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《左耳听风》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(32)

  • Michael
    耗子哥能不能讲一下作为新手如何去了解分布式 如何实践分布式 特别是对于我们这种公司规模小 可能短时间用不上分布式 但是又想学习的同学 给我们一些建议?
    2017-12-12
    37
  • javaee
    国内按技能分工还是主流,采用分布式服务所产生的问题的确很多。特别是对于电商,业务链条非常长,环环依赖,业务上的沟通协调、排查问题方面要花大把时间。毕竟是各管各的,基本上没谁能对整个业务和技术链条都了解清楚。即便有,那也解决不了全公司的问题。公司大了,在开发语言、通信协议、数据规范都会尽量统一,运维逐步自动化,可视化监控并定义关键指标,同时还需要全链路的监控,这一切看起来非常好。但对于一家从3、5个人发展到几百、上千甚至上万人的时候,谁又曾想公司能壮大如此。即便想到了,在那时候技术也不是重点不会换入那么多资源,那时也不一定能找到愿意加入的技术牛人。因此,在公司高速成长的过程中,技术往往是受不到足够重视的,老板也没那么懂。所以技术上肯定会是比较杂乱的,各种语言,各种协议,各种部署方式,种种的异构在后期想统一的时候肯定是非常困难的,这个标准化的过程对于大多数公司来说将会是持久战。
    2017-12-14
    29
  • 小美
    说下为什么API都返回200,在Body里写错误信息:因为有的运营商会拦截非200请求,然后返回广告😂
    2018-12-10
    2
    23
  • neohope
    一说微服务架构,就一把鼻涕一把泪的。从单体结构到分布式,从来就不是一个单纯的技术问题,而是整个团队的思路都要转变,能力都要提升才行。我们从两年前起,开始从单体结构相分布式架构迁移,那一路过来的酸爽,现在闻起来还像泡在醋缸里一样。

    最大的体会就是,程序员写服务爽了,实施或运维部署的时候难度一下加大了好多。以前排查问题找一个地方就行,现在各种中间件,各种服务,各种网络问题都要去看 。有一次,我们因为一个配置有问题,导致在特殊语句处理时数据库处理性能严重下降,dubbo全线卡死,最后导致服务全线雪崩,前方工程师没有经验,单纯的重启了服务,于是继续雪崩,就像被ddos攻击了一样。现在客户还各种质疑,“你们说了新架构很牛啊,怎么恢复用了这么久,排错用了这么久”。

    每次遇到问题,就添加一类监控,磕磕碰碰的总算活了下来。回想下来,总是大家做了过多好的假设,但大家都知道,该发生的总会发生的。感觉我们现在仍把研发和实施分开,其实问题挺大的。
    2018-06-15
    18
  • 董磊
    记得之前一个领导说过,分布式系统不要相信上游系统不出问题,不能因为对方系统问题,把我们给系统影响到,几次线上重大事故都是因此而起
    2018-06-02
    1
    5
  • sitin
    我记得200在body处理是考虑运营商劫持问题
    2017-12-26
    5
  • 小羊
    亚马逊经验:
    1.分布式服务的架构需要分布式服务的团队
    2.查错不易
    3.运维优先,崇尚自动化和简化
    4.无专职运维和测试,开发做所有事情
    5.内部服务和外部服务一致

    分布式系统问题:
    1.异构系统不标准
    2.故障率大
    3.服务间依赖性问题
    4.多层架构导致运维难度加大

    2018-10-24
    3
  • Silence
    这篇文章很棒
    2017-12-12
    3
  • 国诚
    比如,我看到,很多服务的 API 出错不返回 HTTP 的错误状态码,而是返回个正常的状态码 200,然后在 HTTP Body 里的 JSON 字符串中写着个:error,bla bla error message。这简直就是一种反人类的做法。我实在不明白为什么会有众多这样的设计。这让监控怎么做啊?现在,你应该使用 Swagger 的规范了。

    十分汗颜,好像是这么做的
    2018-11-23
    1
    2
  • FeiFei
    统一接口规范,最好的方式就是直接使用http协议里的错误码。
    出现故障并不可怕,可怕的是不知道需要多久修复。
    故障应该要防患于未然,在开发初期就思考故障出现的原因。除了自己的服务,其他人的东西都不可信。
    2018-09-18
    2
  • 枫晴 andy
    非常喜欢分布式系统这个专题,后面能不能再写一些。

    作者回复: 有的

    2018-04-06
    2
  • bob
    耗子哥,本留言可能不完全切合文章内容哈。看了这么久您的文章,结合我自己的工作,忽然意识到了是我自己由于思维上的懒惰或别的原因把工作搞成了“苦力”,想到啥说啥,权当留言了😊。比如:1、假如我负责的模块经历了三次大的迭代,每次包含至少三次小迭代,我几乎从来没有想过做一个自动化的测试程序,做到自动化冒烟(模块对外提供restful接口,像是七牛或阿里云的创建bucket或其他对象存储的接口)。比较极端的例子,针对一个前端抓拍机离线,我的一个模块启用了针对图片上传的socket的keeplive机制,为了做测试,每次我都把那么重的球机搬到工位上,配置完网络,还要对着一段道路监控的录像模拟抓拍,搞得表面上看起来很忙碌,而且搞了很多次,居然没有想过用一个软件的方式去模拟,想来真是惭愧,本来让机器干的活,我自己干了。你说的对,应该尽可能让人控制代码,代码去控制设备。应该想尽一切办法去自动化,提高效率。回到刚才说的迭代,假如有九次迭代,我发版本前都是用别的组写的图形化的demo手动一个功能一个功能挨个手动点击操作,中间浪费了多少时间啊,还不算上代码稍微变动,就要回归冒烟(干久了都有些强迫症倾向了,老怕冒烟过不了被打回)。2、我还发现有些地方做的很不够,侯捷好像说过学从难处学,用从易处用,我自己的理解,比如学习c++,守着stl和boost的宝库,就要多看源码,当然还有其他好的开源软件,这类学习上的大的策略好像没听耗子哥讲过,希望指导以下。还有分布式程序的单元测试,自动化测试什么的,我一直感觉有很多值得挖掘的工程实践上的知识点或者套路。
    2017-12-14
    2
  • edisonhuang
    分布式架构首先需要分布式的团队架构,分布式架构的查错不容易,一个问题可能要在各个团队中流转,分布式架构减少了测试和运维团队,开发团队做所有的事情,分布式架构讲究运维优先,需要尽可能做自动化部署和运维。分布式架构在一开始就要求服务从外部和内部服务一致性,保证服务从设计开始时就可以被开放出去的。
    分布式服务是从组织到软件工程到相应技术的一次组织和技能的迭代
    2019-06-04
    1
  • Dale
    我们使用分布式最大的痛点在于每次出问题,需要登录到一个个组件看日志,一个接一个,非常消耗人力和时间,缺乏一个分布式组件之间的调用链的全局系统,可以方便的查找调用过程
    2019-01-13
    1
  • godtrue
    很全面,切身有一点感受,链路长了,出问题的地方也多了,参与的人多了,各种各色的开发方式和冲突也会增多,感觉就是怎么管理和调度的问题,网络的联通与否不能保证,那信息的交互就不能保证了,不能保证信息的交互,自然容易生乱,变得越来越复杂。
    2018-12-29
    1
  • 痴痴笑笑(Bruce)
    信息点很多,需要仔细看几遍
    2018-12-26
    1
  • ahnselina
    ”一方面,信息太多等于没有信息,另一方面,SLA 要求我们定义出“Key Metrics”,也就是所谓的关键指标”,耗子哥能根据aws的具体实践,举例说明什么样的指标才是关键指标吗,以前我所在的公司运维一个项目也是列了非常多的监控指标,监控指标多得让我感觉有种找不到重点的感觉
    2018-12-04
    1
  • Geek_fb3db2
    文章中提到的配置管理分层 耗子叔能推荐下解决方案么 另外所有的服务都要抽像接口 会不会升级存在兼容问题
    2018-11-14
    1
  • 成都福哥
    皓哥,请教两个问题:
    1. 异构系统的不标准问题 这个小节提到4个问题:
       软件和应用不标准。
       通讯协议不标准。
       数据格式不标准。
       开发和运维的过程和方法不标准。
    软件的开发和运维是服务是属于team内部的,为什么1(软件和应用不标准)和4( 开发和运维的过程和方法不标准)会成为题呢?
    2. 用http定义的状态码,有时候并不能完全描述业务过程中的各种场景。(这应该是 http 200, 但是消息里面有自定义的 error_code 和 error_message的原因。)这个应该怎么破?
    3.

    2018-10-31
    1
  • 董磊
    防御编程在分布式系统中尤为重要,记得几次线上故障,归根到底还是自己没防御好
    2018-06-02
    1
收起评论
32
返回
顶部