多年来，微服务一直是开源世界的焦点。尽管 Docker、Kubernetes、Prometheus 和 Swarm 等开源技术使组织比以往任何时候都更容易采用微服务架构，但让你的团队在微服务上达成共识仍然是一个困难的挑战。
对于一个强调良好命名的专业来说，我们在微服务方面做得并不好。“微服务”的问题在于，它本身并没有什么“微”之处。有些可能很小，但大小是相对的，而且在不同的组织中没有标准的衡量单位。一家公司“小型”服务可能是 100 万行代码，但在另一家组织中可能要少得多。
有人认为微服务根本不是什么新鲜事物，而是面向服务架构 (SOA) 的品牌重塑，而另一些人则将微服务视为 SOA 的一种实现，类似于 Scrum 是敏捷开发的一种实现。（要了解有关微服务定义的模糊性，请查看即将出版的这本书Microservices for Startups。）当没有精确的定义时，你如何让你的团队在微服务上达成共识？在谈论微服务时，最重要的是确保你的团队有一个共同的起点。模糊的定义没有帮助。这就像在不了解你想要实现的目标或不了解像 Scrum 这样的精确方法的情况下，试图将敏捷开发付诸实践一样。
寻找共同点
了解了过于急切地加入微服务潮流的危险之后，我工作过的一个团队试图不纠结于定义，而是专注于定义我们试图通过采用微服务来实现的好处。以下是我们关注的三个领域以及从微服务实施的每个部分中吸取的教训。
1. 更快地交付软件的能力
我们的主要应用程序是一个大型代码库，由几个小型开发团队试图为不同的目的构建功能。这意味着每次更改都必须尝试满足所有不同群体的需求。例如，一个仅服务于一个群体的数据库更改必须经过其他没有那么多上下文的群体的审查和接受。这是乏味的，并减慢了我们的速度。
不同的开发团队共享同一个代码库也意味着代码不断以非刻意的方式变得更加复杂。随着代码库越来越大，团队中没有人可以拥有它并确保所有部分都组织良好并最佳地组合在一起。这使得部署成为可怕的考验。对我们的应用程序进行一行更改需要部署整个代码库才能推出更改。由于部署我们的大型应用程序风险很高，我们的质量保证流程不断增长，因此，我们部署的次数减少了。
通过微服务架构，我们希望能够分解我们的代码，以便不同的开发团队可以完全拥有各个部分。这将使团队能够更快地进行创新，而无需繁琐的设计、审查和部署流程。我们还希望，由更少的开发人员处理较小的代码库将使我们的代码库更易于开发、测试和保持组织性。
2. 技术选择的灵活性
我们的主要应用程序很大，使用 Ruby on Rails 构建，带有自定义 JavaScript 框架和复杂的构建流程。我们应用程序的几个部分遇到了难以修复的重大性能问题，并拖垮了应用程序的其余部分。我们看到了使用更好的方法重写这些部分的机会。我们的代码库是相互交织的，这使得重写感觉非常庞大且成本高昂。
与此同时，我们的一个前端团队希望摆脱我们的自定义 JavaScript 框架，并使用像 React 这样的较新框架构建产品功能。但是将 React 混合到我们现有的应用程序和复杂的前端构建流程中似乎配置成本很高。
随着时间的推移，我们的团队对被困在一个太大而无法修复或替换的代码库中的感觉越来越沮丧。通过采用微服务架构，我们希望保持单个服务更小意味着用更好的实现替换它们的成本将更容易管理。我们还希望能够为每个工作选择合适的工具，而不是被一刀切的方法所困扰。我们将有灵活性在不同的应用程序中使用多种技术，只要我们认为合适。如果一个团队想要使用 Ruby 以外的其他技术来获得更好的性能，或者从我们的自定义 JavaScript 框架切换到 React，他们就可以这样做。
3. 微服务不是免费的午餐
除了概述我们希望实现的好处之外，我们还确保我们对构建和管理微服务的成本和挑战保持现实态度。开发、托管和管理大量服务需要大量的开销（以及协调大量不同的开源工具）。运行在少量进程上的单个单体代码库可以很容易地转化为跨越少量服务的几十个进程，这需要负载均衡器、消息层和用于弹性的集群。管理所有这些需要大量的技能和工具。
此外，微服务涉及分布式系统，这些系统引入了大量问题，例如网络延迟、容错、事务、不可靠的网络和异步性。
设定你自己的微服务路径
一旦我们定义了微服务的好处和成本，我们就可以谈论架构，而不会陷入关于谁的微服务做得对或错的适得其反的争论。我们没有试图使用其他人对微服务的描述或示例来找到我们的方法，而是专注于我们试图解决的核心问题。
- 在未来的 6 到 12 个月内，拥有更多服务将如何帮助我们更快地交付软件？
- 对于我们系统的某个部分，使用特定工具是否有强大的技术优势？
- 我们是否预见到将来想要用更合适的系统替换其中一个系统？
- 随着我们招聘更多的人，我们希望如何围绕服务构建我们的团队？
- 拥有更多服务带来的生产力提升是否值得可预见的成本？
总而言之，以下是在投入微服务之前调整你的团队的五个建议步骤
- 了解微服务，同时承认没有“正确”的定义。
- 定义一套共同的目标和目的，以避免适得其反的争论。
- 讨论并记录你对采用微服务的预期收益和成本。
- 避免过于急切地加入微服务潮流；对关于如何最好地构建你的系统的创造性想法和激烈的辩论持开放态度。
- 始终扎根于你的团队确定的收益和成本。
专注于确保团队拥有一套具体定义的共同目标来开展工作。讨论和定义你希望通过微服务实现什么比试图确定微服务实际上是什么更有价值。
1 条评论