微服务依赖管理的陷阱与模式

文章图片
去年，在QConPlus期间，我分享了我在谷歌工作的10多年里遇到的一些微服务依赖管理中的陷阱和模式。这次演讲不是为了介绍任何特定产品或团队，而是为了分享我自己作为谷歌软件工程师的经验和个人学习成果。
我是基于上述前提登台演讲的。这些场景都有一些关键的顿悟时刻，通过这些瞬间我意识到了微服务环境中的许多方面是何等重要。也有不少遭遇失败或出错的时刻。我精心挑选出了这些故障场景，并告诉大家我做了哪些事情来避免将来发生类似的情况，这样你就可以在你自己的环境中找出可能导致类似故障的迹象。
所有这些场景中我都在与其他工程角色协作。有时我是一名软件工程师，与某位项目经理共事。还有些时候，我是一名站点可靠性工程师，与其他开发人员协作。在最后一个场景中，我基本上在和团队中的所有人配合，目标是构建可靠的服务。
这些场景都对团队中的各种角色大有助益：能否成功构建可靠的微服务环境，不仅取决于某个人或某个单一角色。
每次更改系统时，更改都会影响整个产品的许多部分和组件——这些组件可能是由你的公司、在云中或由第三方提供商运营的。系统更改会产生连锁反应，一直影响到客户一侧：客户恰恰是你每时每刻都要考虑的群体。出于这个原因，你需要从整体的角度来看待系统——这也是我在演讲中试图传达的一部分内容。
在介绍这些场景（以及所有可以从它们中学到的东西）之前，让我们快速了解一下行业是如何从单体服务过渡到微服务，然后再迈出最后一步将服务上云的。我们还将研究各种模式和流量增长、故障隔离，以及如何在每个后端都有不同提示的世界中规划合理的服务级别目标（SLO）。
单体、微服务和云端
我们的旅程（这里我们会使用一个通用服务）从一个二进制文件开始，它最终（且迅速）会演变为包括众多复杂功能的文件，例如数据库、用户身份验证、流量控制、运维监控和HTTPAPI（这样我们的客户就可以在线找到我们）。起初，这个单一的二进制文件只打算运行在一台机器上，但随着业务的增长，我们有必要在多个地理位置复制这个二进制文件，同时为流量增长留出额外的空间。
在复制我们的单体之后不久，有几个原因要求我们将它们解耦为一些单独的二进制文件。或许你可以想到其中一些因素。一个常见的原因与二进制文件的复杂性有关。随着我们向其添加愈加复杂的功能，代码库变得几乎无法维护（更不用说添加其他新功能了）。将单体分解成许多单独的二进制文件的另一个常见原因事关独立逻辑组件的独特需求。例如，我们可能有必要为特定组件增加硬件资源，而不影响其他组件的性能。
像这样的场景最终促成了微服务的诞生：微服务是一组松散耦合的服务，这些服务可独立部署、高度可维护并组织起来形成（或服务）一个复杂的应用程序。在实践中，这意味着我们会部署多个二进制文件并通过网络让它们通信，其中每个二进制文件都实现了自己的微服务，但它们都服务于并代表单一的一个产品。图1展示了一个API产品的示例，该产品解耦为五个独立的微服务（API、Auth、Control、Data和Ops），这些微服务通过网络相互通信。在微服务架构中，网络也是产品的重要组成部分，因此你必须始终牢记这一点。每个服务——现在既是单个二进制文件又是应用程序的一个组件——可以独立增加硬件资源，并且工程团队可以轻松控制其生命周期。