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

非常喜欢分布式系统这个专题，后面能不能再写一些。

说下为什么API都返回200，在Body里写错误信息：因为有的运营商会拦截非200请求，然后返回广告😂

耗子哥能不能讲一下作为新手如何去了解分布式 如何实践分布式 特别是对于我们这种公司规模小 可能短时间用不上分布式 但是又想学习的同学 给我们一些建议？

国内按技能分工还是主流，采用分布式服务所产生的问题的确很多。特别是对于电商，业务链条非常长，环环依赖，业务上的沟通协调、排查问题方面要花大把时间。毕竟是各管各的，基本上没谁能对整个业务和技术链条都了解清楚。即便有，那也解决不了全公司的问题。公司大了，在开发语言、通信协议、数据规范都会尽量统一，运维逐步自动化，可视化监控并定义关键指标，同时还需要全链路的监控，这一切看起来非常好。但对于一家从3、5个人发展到几百、上千甚至上万人的时候，谁又曾想公司能壮大如此。即便想到了，在那时候技术也不是重点不会换入那么多资源，那时也不一定能找到愿意加入的技术牛人。因此，在公司高速成长的过程中，技术往往是受不到足够重视的，老板也没那么懂。所以技术上肯定会是比较杂乱的，各种语言，各种协议，各种部署方式，种种的异构在后期想统一的时候肯定是非常困难的，这个标准化的过程对于大多数公司来说将会是持久战。

一说微服务架构，就一把鼻涕一把泪的。从单体结构到分布式，从来就不是一个单纯的技术问题，而是整个团队的思路都要转变，能力都要提升才行。我们从两年前起，开始从单体结构相分布式架构迁移，那一路过来的酸爽，现在闻起来还像泡在醋缸里一样。 最大的体会就是，程序员写服务爽了，实施或运维部署的时候难度一下加大了好多。以前排查问题找一个地方就行，现在各种中间件，各种服务，各种网络问题都要去看 。有一次，我们因为一个配置有问题，导致在特殊语句处理时数据库处理性能严重下降，dubbo全线卡死，最后导致服务全线雪崩，前方工程师没有经验，单纯的重启了服务，于是继续雪崩，就像被ddos攻击了一样。现在客户还各种质疑，“你们说了新架构很牛啊，怎么恢复用了这么久，排错用了这么久”。 每次遇到问题，就添加一类监控，磕磕碰碰的总算活了下来。回想下来，总是大家做了过多好的假设，但大家都知道，该发生的总会发生的。感觉我们现在仍把研发和实施分开，其实问题挺大的。

我记得200在body处理是考虑运营商劫持问题

记得之前一个领导说过，分布式系统不要相信上游系统不出问题，不能因为对方系统问题，把我们给系统影响到，几次线上重大事故都是因此而起

非常不赞同接口直接返回非200错误码？应将服务异常与业务异常区分对待，服务异常使用HTTP错误码，业务异常用返回值中自定义的错误码，并返回相应错误提示。 不知道课主当时遇到的是什么场景，但被课主否定的那种做法在绝大多数情况下是可取的。

耗子哥，本留言可能不完全切合文章内容哈。看了这么久您的文章，结合我自己的工作，忽然意识到了是我自己由于思维上的懒惰或别的原因把工作搞成了“苦力”，想到啥说啥，权当留言了😊。比如:1、假如我负责的模块经历了三次大的迭代，每次包含至少三次小迭代，我几乎从来没有想过做一个自动化的测试程序，做到自动化冒烟（模块对外提供restful接口，像是七牛或阿里云的创建bucket或其他对象存储的接口）。比较极端的例子，针对一个前端抓拍机离线，我的一个模块启用了针对图片上传的socket的keeplive机制，为了做测试，每次我都把那么重的球机搬到工位上，配置完网络，还要对着一段道路监控的录像模拟抓拍，搞得表面上看起来很忙碌，而且搞了很多次，居然没有想过用一个软件的方式去模拟，想来真是惭愧，本来让机器干的活，我自己干了。你说的对，应该尽可能让人控制代码，代码去控制设备。应该想尽一切办法去自动化，提高效率。回到刚才说的迭代，假如有九次迭代，我发版本前都是用别的组写的图形化的demo手动一个功能一个功能挨个手动点击操作，中间浪费了多少时间啊，还不算上代码稍微变动，就要回归冒烟（干久了都有些强迫症倾向了，老怕冒烟过不了被打回）。2、我还发现有些地方做的很不够，侯捷好像说过学从难处学，用从易处用，我自己的理解，比如学习c++，守着stl和boost的宝库，就要多看源码，当然还有其他好的开源软件，这类学习上的大的策略好像没听耗子哥讲过，希望指导以下。还有分布式程序的单元测试，自动化测试什么的，我一直感觉有很多值得挖掘的工程实践上的知识点或者套路。

亚马逊经验： 1.分布式服务的架构需要分布式服务的团队 2.查错不易 3.运维优先，崇尚自动化和简化 4.无专职运维和测试，开发做所有事情 5.内部服务和外部服务一致 分布式系统问题： 1.异构系统不标准 2.故障率大 3.服务间依赖性问题 4.多层架构导致运维难度加大