微服务部署面临的挑战

以前，我们邀请几位嘉宾讨论了他们在开发微服务时遇到的挑战，比如Fred George或Dustin Huptas和Andreas Schmidt。近日，Usman Ismail参加了一场小组会议，讨论了微服务持续交付面临的挑战，并决定随后详述其中的部分重点内容。他首先讨论了微服务其中一个基本原则的缺点，那允许大型团队通过快速原型和迭代以一种更加敏捷的方式推进（软件）开发：

不过，微服务显著增加了开发团队的运维和工具负担。每个服务都需要一个部署管道、一个监控系统、自动报警、轮流电话值班，等等。对于大型团队，所有这些负担都可以视为提升特性开发效率的合理代价，是创建这些系统值得付出的努力。不过，在小型团队中，如果同一批人负责所有的服务，那么无论如何，为多个项目复制管道都是开销上的浪费。

接下来考虑的是运维负担。在Usman看来，使用微服务或单体架构，如果推出了一个服务或组件的不良版本，就需要回滚系统，而且如果遇到资源限制，则（常常）可以横向扩展。不过，使用微服务，你需要更多的监控和自动化才能检测出哪些服务需要回滚，并确定回滚一个服务对其他依赖它的服务产生什么影响，等等。

如果你有自动报警系统（你真应该有一个），那么你需要把报警信息发给服务所有者，并为多个服务维护一个电话值班时间表。在小型组织中，负责不同服务的人群之间会有很大的重叠。这就是说，我们必须针对这些服务协调时间表，以确保同一个人不会被许多服务钩住，让人们在轮流电话值班之外得到一些喘息。由于这些以及上一节中提到的原因，最好是开始引入多个微服务的开销之前有一个单体架构，并把所有的运维工作安排妥当。

然后当然是微服务一个基本特点——一个在传统单体应用中可能不会提到或者很少提到的特点：分布式。这引发了一个古老的问题，就是在分布式环境中调试，我们过去已经提到过许多次，在微服务这个术语被创造出来以前。原先，Joyent首席技术官Bryan Cantrill探讨过在生产环境中调试微服务。Usman认为，没有一个集中式的微服务日志是一种致命的缺陷：

而且，在规模比较大的情况下，有一个单独的监控系统（比如datadog、grahite）和一个单独的日志聚合系统（比如ELK、loggly或Splunk）是不可行的。在这种规模下，可视化指标和日志数据是一个大数据问题，最好在一个地方解决。

对于小组会议的最后一个重点，Usman提到了部署协调和版本管理。文章认为，微服务和单体应用的其中一个重大差别是前者是一棵服务依赖树，而后者是一个图：

例如，在单体模型中，一个典型的服务栈可能包含一个“Web组件组合（web array）”，它调用一个缓存层、数据库层，可能还有一些独立服务，比如身份验证，等等。在微服务模型中，你会有一个连通图或者服务网络，每个服务都依赖于几个其他的服务。有一点很重要，就是要确保这个图是一个有向无环图（DAG），否则你会陷入依赖地狱，可能还会遇到分布式堆栈溢出错误。

有趣的是，Usman的文章接下来总结了嘉宾们提出的一些指导原则：

参加小组会议的嘉宾，没有哪个人对他们的微服务系统十分满意，也就无法为如何构建这样一个系统提出任何类似指南的东西，不过，我们确实提出了一些经验法则或者一般的指导原则，包括下列这些。

这些原则可以总结为：

所有的建议都是基于来自各类公司的嘉宾们的集体经验。那些建议一直随着时间演变，将来可能会随着经验的日益丰富而继续演变。在某种程度上，Usman最后的评论附和了Vijay Alagarasan去年在演讲“7种微服务反模式”中所讲的内容：

[微服务]并不是解决构建和运行大规模分布式软件基本问题的魔弹。微服务架构迫使你更谨慎地遵循最佳实践和自动化工作流。本次讨论的一个重要结论是，除非你愿意将大量的时间和资源从特性开发工作转到构建和维护一个服务框架上，否则最好避免进入微服务的世界。不过，如果你能够投入时间构建一个很棒的服务框架和工作流，那么你将完成重大转变，成为一个更敏捷、更有生产力的组织。

我们总是在寻求更深入的微服务经验，有好的经验，也有不好的经验，因此，或许你想自己对Usman的工作或讨论作出评判。

本文转自d1net（转载）