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

精选留言(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