在本文中，我们将看看你可以使用哪些策略来更好地了解什么情况下会导致你的微服务崩溃。充分了解它失败的原因将让你有机会去实施更改以提高微服务的稳定性，并有望避免再次发生同样的问题。
不幸的是，如果你找到这篇文章，我没有很多有用的建议，因为你的微服务刚刚崩溃，你拼命想弄明白为什么。通过提前准备支持基础架构和监控，你将能够更好的识别出哪些微服务崩溃以及为什么。正确的准备工作是本文关注的主题，但这里也提供一些提示以便我不会让你停留太久。
在问题的根源确定微服务
在微服务环境中，每个服务可能对其他服务具有多个依赖关系。由于这些依赖关系，一个服务中的故障通常可能会表现为另一个服务的明显故障，仅因为它作为其的依赖关系。识别哪个服务失败是第一步。如果你怀疑某个服务是导致失败的原因，那么验证其所有依赖项都是可操作的并按预期进行响应。
保留证据
在生产环境中，您需要尽快恢复服务并运行。通常这个过程可能涉及到实例化一个新的虚拟机或一个新的机器集群。当任何一项完成后，自动化流程有时可能会破坏以前的实例或集群。如果可能，采取措施保护这些设备。日志文件，内存转储和在故障机器上执行诊断工具将能提供关于导致故障的原因的重要线索。
关键的准备工作
当你阅读这篇文章，为迁移到微服务架构做准备并计划一个全面的支持策略。一个精心设计的微服务架构允许独立的开发团队实现独立的功能并创建高可扩展，松耦合的环境，并支持快速引入新功能。
这些对开发过程带来的好处会导致一个难以使用传统生产监控工具监控的环境。你将需要调研并实现一个应用性能监控工具（APM），该工具允许开发人员了解其应用程序的当前状态，并自动化支持生产系统所涉及的许多过程，并在关键指标在规定的性能限制外时生成警报。
APM通常由安装在微服务机器或容器上的代理组成，并与中央APM服务器或服务器集群通信。在某些情况下，APM代理可能本身作为独立容器运行，特别是对于需要更深入检测的服务。这种方法的优点是它可以将服务的监控与实际服务本身分离开来。即使目标计算机发生故障或意外关闭，它也允许持续分析数据并进行主动监控。
理想情况下，你选择并实施的APM解决方案应包括趋势分析或机器学习，以支持全自动监控。APM工具还应该包含动态基准和规则，并允许用户自定义规则，然后可以在系统降级到无法使用之前用它们生成警报。
最后，APM解决方案应支持实时和历史性的服务可视化，以使开发人员能够了解机器状态，例如内存，处理和网络通信等指标。日志数据的收集，汇总和索引也是综合监控解决方案的重要组成部分。
除了部署全面的APM解决方案外，当你在编写你的微服务时也应该遵循一些开发最佳实践，以便在发生故障时能给那些负责操作的人提供支持和使故障排除更简单。
始终假定系统的各个方面都会故障，即使你的代码是完美的，它仍然依赖于基础架构，相关服务和不可预测的用户输入。当你对应用程序进行编码当以适当方式处理任何依赖性失败，并使源识别更容易的方式进行编码。在合适的地方添加全面的异常处理，描述性日志消息和验证。
在服务之间传递消息或请求时，请将相关令牌或跟踪ID添加到源自同一客户端的所有请求中。当您尝试通过多个服务跟踪客户端的请求时，尤其是在将所有日志聚合到索引日志聚合系统中时，这些令牌非常有用。
最后，以启用容错的方式部署您的微服务。使用基于软件的负载平衡器以及跨多个虚拟机（如果可能的话，在不同的地理位置）分发单个微服务将有助于最大限度地减少用户在其中一个实例发生故障时的停机时间。
要了解有关监控微服务的更多信息，请获取免费电子书：https://www.ca.com/us/info/docker-container-monitoring-essentials.html。
原文链接：https://thenewstack.io/help-my-microservice-crashed-a-guide-for-first-responders/
6月22日正式上课，点击阅读原文链接即可报名。