生产环境中保持微服务井然有序的五大措施

架构和设计 DevOps 开发 分布式系统 体系结构

摘要：

Takipi公司的Alex Zhitnitsky撰文介绍了在生产环境中提高微服务部署成功率的五大措施。在文章中他们分享了不同领域技术人士共同的顾虑，就算无法真正解决这些问题，至少能够让我们就这些共同问题达成一致。

正文：

本月初，Takipi公司的Alex Zhitnitsky撰写了生产环境中保持微服务井然有序的五大措施一文（好吧，“井然有序”这个词并非他的原话）。他结合我们几个月前报道过的小组讨论成果与用户反馈，向大家介绍了在生产环境中使用微服务可能遇到的主要问题以及这些问题的解决方法。这些内容的侧重点在于分布式调试，以及为了使其成为一种易于驾驭的方式所能采取的方法。他谈到的第一个问题是监控：

监控是一种明智的做法。系统会逐渐变得高度碎片化，为了对系统的运行状况获得更全面的了解，人们对集中式监控和日志会产生越来越高的需求。

Alex谈到了在最新一期播客节目中所涉及的一个场景，这个场景中需要对有问题的版本进行回滚，这就要确定相应的微服务，并确定进行回滚可能会对其他服务产生的影响。他认为：

结论1：如果你认为对单层（Monolith）体系结构进行监控已经很困难，微服务的监控要比这个难十倍，需要事先做好极为充分的规划和更大的投入。

对于第二个问题，Alex谈到了我们已经从Sam Newman和Adrian Cockcroft等人处多次听到的一种观点：

单层体系结构的日志文件很可能已经分散在不同位置，就算心里想着“单层”，但最终依然可能会使用多个不同技术层，并可能将日志保存在不同地方。微服务则会让日志进一步分散。现在如果需要调查有关某些用户事务的场景，为了理解实际发生的一切，你可能需要从不同位置获取所有服务的全部日志。

这就产生了他的下一个结论：

结论2：微服务的目标就是将所有东西拆分为零散组件。但这种做法的副作用之一是运维规程和监控工作也需要分别应用给每个服务，进而导致无法发挥“整体系统”的强大之处。通过恰当的工具以统一方式管理这一切已成为此时最大的挑战。

第三个问题引述自Leslie Lamport对于分布式系统的定义中的一句话：“分布式系统是指某台我从未听说过的计算机也能导致我的程序崩溃的体系。”或者按照Alex的说法：“一个服务引发的问题，会造成其他地方出现连锁反应。”那么这个结论也就不言自明了：

结论3：对于单层体系，遇到问题后通常你会知道需要调查哪些方面，微服务使得人们难以确定问题根源以及要从哪里拿到所需数据。

在分布式系统中，“确定问题根源”这一需求进一步产生了下个问题，此时日志可以提供一定的帮助，但日志只是解决方案的一部分：

大部分情况下，你寄希望于日志文件中获得的前几位变量数据，但这些可能根本无法解决你的问题。这些信息只能让你继续追查下一条线索，进而需要进一步深入这样的“魔法世界”，继续运行更多日志语句。随后部署改动，期待着问题能够重现或永不再现，因为… 有时候仅仅添加一条日志语句似乎就能解决问题。这类似于墨菲法则的一次糟糕的大逆转。

这也产生了我们的下一个结论：

结论4：如果微服务中一个问题的根源涉及到多个服务，就很有必要使用一个集中的根源检测工具。

Alex提到的最后一个问题是版本管理和服务之间的循环依赖。同时他也提到了在检查依赖性时需要注意的两个问题。

1，如果服务之间存在循环依赖，一旦某个事务卡在循环中，就很容易产生分布式堆栈溢出错误。2，如果两个服务共享同一个依赖项，并且使用会影响到这些服务的方式更新了其他服务的API，那么就需要同时对这三个服务进行更新。这就造成了另一种问题，例如：要先更新哪个服务？如何确保所有服务能顺利地完成更新？

相互独立的服务越多意味着可移植性越高，不同服务可以使用互不干涉的发布周期，但同时这样做也会增加整个系统的复杂度，尤其是在可再生性（Reproducibility）方面。那么这就引出了我们的第五个，也是最后一个结论：

结论5：在微服务体系结构中，更容易产生依赖性问题所导致的错误。

很高兴看到在生产环境中运用微服务的人就此展开的讨论，更让人高兴的是，很多人已经就其中的一些核心问题和解决这些问题的常见方法达成了一致。