有一个观点已经被说烂了：使用 MQ 可以帮助业务系统解耦。
想法很简单，在业务状态流转时，如果没有 MQ，那么其它系统想要知道状态变了，那就需要核心流程系统去主动做通知。
比如电商系统里订单从创建到处理中状态切换了，客服系统需要知道，风控系统需要知道，用户系统也需要知道。
这里的通知通过 RPC 来进行，下游系统需要的数据可以在这次 RPC 里携带上，也可以在请求的时候让下游系统自己去查。
下游系统增加的时候，核心业务的代码也需要修改，比如新做了一个积分系统，现在订单状态流转积分系统也想知道。
核心系统需要不停地增加调用关系来迎合下游新增的业务方需求。这些边边角角的计算逻辑和订单系统本身没啥关系，但是因为下游需要拿到这些数据，我们就需要自己用 RPC
去调用下游的接口。这确实不太合理。
当下游系统发生事故时，
今年不少业务开发像突然被开了光一样开始讲 nocode 和 lowcode，可以看出现今的互联网可能真的是编不出什么好故事了。
在之前的文章里，我们已经讲过自动化、平台化和中台化了，不管业务模式怎么变，企业内总还是有一些局部系统最终能够把开发模式沉淀下来，变成拖拖拽拽就可以进行变更的“网页制作大师”系统。
像阿里这样的公司，中台落地并迭代多年以后，核心业务的流程变化其实并不会有太多的编码任务，从内部资料来看，套用以往的业务模式，改改配置或者上上活动，基本不需要程序员去做开发了。
不管我们在哪个公司，只要我们按照《在业务系统中寻找技术含量》这篇文章的思路去做系统，最终一定能够将大部分繁琐的重复劳动做到自动化。二八定律，就是可以将那 80%
的重复劳动用界面化、系统化、流程化的手段完全消灭掉。剩下的 20%
Fail at Scale 是 Facebook 2015 年在 acm queue 上发表的一篇文章。主要写了常见的线上故障和应对方法，内容还是比较实在的。
"What Would You Do If You Weren't Afraid?" 和 "Fortune Favors the Bold." 是 FB
公司信条，挂墙上那种。
为了能在快速变更的系统中使 FB
的系统稳定，工程师们对系统故障进行了一些总结和抽象，
The Tail at Scale，是 Google 2013 年发表的一篇论文，大规模在线服务的长尾延迟问题。
要知道怎么解决长尾问题，先要理解长尾延迟是个什么问题，在开发在线服务的时候，我们都知道要关注服务的 p99/p999
延迟，要让大部分用户都能够在预期的时间范围内获得响应。
下面是一个不同响应时间的请求数分布图：
大部分系统也都遵循这种分布规律，现在互联网的系统规模比较大，一个服务依赖几十上百个服务的情况都是有可能的。单一模块的长尾延迟会在有大量依赖的情况下，在服务粒度被放大，《The
Tail at Scale》论文里给出了这样的例子。
> 考虑一个系统，大部分服务调用在 10ms 内响应，但
偶尔讲讲工具，放松一下。
现在写技术文章不但要写技术细节，图还得画的好看。对于表达思路和架构来说，图确实挺直观的，这篇文章介绍一下常见的绘图工具。大家可以看自己的喜好自行选择。
在早期写 golang-notes 的时候，想要向那些写 RFC 文档和早期的 unix 大神们致敬，所以比较喜欢 ascii
图，这种图的好处是你可以直接将图表内嵌在文档内部，不需要有附件。有利于单文件传播。
用来画 ascii 的图工具有不少。
textik
textik 是一个在线项目：https://textik.com，可以直接在线绘制 ascii
