一说微服务架构，就一把鼻涕一把泪的。从单体结构到分布式，从来就不是一个单纯的技术问题，而是整个团队的思路都要转变，能力都要提升才行。我们从两年前起，开始从单体结构相分布式架构迁移，那一路过来的酸爽，现在闻起来还像泡在醋缸里一样。

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

每次遇到问题，就添加一类监控，磕磕碰碰的总算活了下来。回想下来，总是大家做了过多好的假设，但大家都知道，该发生的总会发生的。感觉我们现在仍把研发和实施分开，其实问题挺大的。

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

亚马逊经验：
1.分布式服务的架构需要分布式服务的团队
2.查错不易
3.运维优先，崇尚自动化和简化
4.无专职运维和测试，开发做所有事情
5.内部服务和外部服务一致

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

皓哥，请教两个问题：
1. 异构系统的不标准问题 这个小节提到4个问题：
   软件和应用不标准。
   通讯协议不标准。
   数据格式不标准。
   开发和运维的过程和方法不标准。
软件的开发和运维是服务是属于team内部的，为什么1（软件和应用不标准）和4（ 开发和运维的过程和方法不标准）会成为题呢？
2. 用http定义的状态码，有时候并不能完全描述业务过程中的各种场景。（这应该是 http 200, 但是消息里面有自定义的 error_code 和 error_message的原因。）这个应该怎么破？
3.