问Max建议下游呼叫进行微服务互传。

EN

理智的东西会有所不同。

• 如果您的服务隐藏在响应性UI后面，则可以等待。
• 另一方面，如果它阻止用户执行另一项任务，则这是一个问题。

期望值

确定您的站点/服务必须有多大的响应性。用一种可测量的方式把它记下来。

80% are within Xms, 95% are within Yms, ... 100% are within Zms

用当前的系统负载或一天中的时间来打破这种预期可能是有意义的。

• 你的系统应该如何处理x，000个用户，如果那里有y，000呢？
• 您的系统应该如何在上午8点到晚上8点之间运行？

您可能希望得到更具体的：

• 最大并发用户，以及更多的东西都被认为是例外服务。
• 服务退化:为了保持响应性，牺牲响应质量。即。不要返回带有用户名和徽章的统计信息。
• 红线进程:以牺牲其他功能为代价来维护功能。即。优先处理订单而不是浏览评论和评论。

收集数据

运行几个客户端(selenium，或自定义的web请求脚本)，这些客户端可以使用某种分发模式来平页或一组页面。试着让它看起来像偷看负载，或一般的日子。测量客户端的响应时间。

如果是80% are within Xms, 95% are within Yms, ... 100% are within Zms，那么你很好。否则，找出是什么在减缓这组请求。

还要注意服务的退化，和红色的衬里。如果服务质量下降过大，或者红线比其他特性占优势，那么缩短响应时间是没有帮助的。

实验

现在您已经明确地知道了哪些类型的请求太慢、太差，或者需要更多的资源，并且在什么负载下，可以找到改进它的方法。

也许：

• 硬件，如缓存，代理，负载平衡器。
• 前端更改以避免或延迟加载数据，可能是分页。
• 通过组合、优化或拆分服务来进行后端更改。

收集更多的数据，你是做得更好还是更糟？

验证

一定要确保你的实验在生产中有效。

要做到这一点，您需要在生产中进行良好的监控。把你以前看到的和现在看到的比较一下。质量明显提高了吗？

混沌工程

只有当你成熟了这个系统，并且相信它会好起来。尝试设计一个负载模式，并观察这些指标是否符合您的期望。

利用针对测试系统设计的客户端脚本。显然，在使用哪些测试时要挑剔，这里不需要破坏您的系统。

也要事先提醒大家注意实验方法。别让你自己的队伍惊讶。如果他们对音阶或目标感到不舒服，就听他们说。缩小测试范围，使测试更严格，慢慢建立信心。