2.8　协调微服务

将单体系统与基于微服务的系统进行比较时，微服务样样都会“多一点”。单个微服务相对简单，对单个服务进行编写、修改和故障排除要容易一些。但是，对于整个系统而言，跨多个服务进行更改以及问题调试更具挑战性，微服务之间也会发生更多的网络交互，而在单体架构中，这些交互都在同一进程内发生。这意味着要想从微服务中受益，你需要一套严格的方法和最佳实践，以及好用的工具。

一致性与灵活性之间的权衡

假设你有100个微服务，但是它们都很小而且非常相似。它们都使用相同的数据存储（例如，相同类型的关系型数据库），都以相同的方式配置（例如，配置文件），都记录错误和日志到集中式的日志服务器，都使用相同的编程语言（例如Go）实现。通常，系统会处理多个用例，每个用例都将涉及这100种微服务的一部分，在大多数用例中还将使用一些通用微服务（例如，授权服务）。通过编写优秀的文档，你对整个系统的理解可能会容易一些。你可以分别查看每个用例，会发现当系统扩展比如增长到1000个微服务时，当添加更多用例时，系统复杂度仍然在一定的限度内，如图2-2所示。

图2-2　微服务示例

文件和目录是一个很好的类比。假设你按流派、艺术家和歌曲来组织音乐。最初，你拥有3种流派、20位歌手和200首歌曲。然后，你扩展了所有内容，现在拥有10个流派、50个艺术家和3000首歌曲，仍然按流派/艺术家/歌曲的旧层次来组织。在扩展的某个阶段，简单的扩展就会带来新的问题。例如，当你有太多音乐以至于无法都存储在硬盘上时，就需要一个本质上不同的解决方案（例如，将其保存在云中）。微服务也是如此，如果达到超大的互联网规模（如亚马逊、谷歌、Facebook），那么你将需要针对每个方面都设计更加详尽的解决方案。

但是，使用一致的微服务会牺牲很多好处。例如，团队和开发人员可能被迫使用不适合该任务的编程语言，或者甚至对于小型非关键内部服务，他们也必须遵守严格的日志和错误报告操作标准。

你需要了解一致的微服务与多样化微服务的优缺点。从完全一致的微服务到无所不包，其范围是非常广泛的，每个微服务都可以是独一无二的。你的责任是在整个系统范围内找到最佳位置。