回顾四五年前，围绕微服务架构的观点已经发生了很大的变化。首先，在看到 Netflix、亚马逊和 Gilt.com 等公司的成功故事后，开发人员认为微服务实际上是应用程序开发的一部分，这是炒作阶段。到现在为止，我们已经意识到微服务是另一种架构风格，当它以正确的方式应用于正确的问题时，会取得令人惊讶的成果，但它也有自己的优缺点。

为了了解微服务到底是什么，什么时候应该使用它们，什么时候不应该使用它们，我们采访了 Jaime Buelta，他是 Hands-On Docker for Microservices with Python 一书的作者。在介绍微服务及其好处的同时，Buelta 还分享了一些最佳实践，如果开发人员决定将他们的单体架构迁移到微服务，那么他们应该记住这些最佳实践。

在开始使用微服务之前，Buelta 建议在通用软件架构和 Web 服务方面打下坚实的基础。“在处理微服务及其后续工作时，它们将会非常有用，”他说。

微服务：好处和风险

传统的单体应用程序将所有的功能都封装在一个单元中。相反，在微服务架构中，应用程序被划分为可以单独部署、升级和替换的小型独立服务。每个微服务都是针对单个业务目的而构建的，它使用轻量级机制与其他微服务通信。

Buelta 解释说，“微服务架构是一种构建系统的方式，其中，几个独立的服务按定义好的方式彼此通信（通常通过 Web RESTful 服务）。关键在于每个微服务都可以独立更新和部署。”

微服务架构不仅规定了如何构建应用程序，还规定了如何组织团队。

他补充道，“虽然通常我们使用所涉及的技术来描述（它），但它也是一种组织结构。每个独立的团队都可以完全拥有一个微服务。这使得组织的发展可以不受开发人员冲突的影响”。

微服务的主要好处之一是它可以赋能创新，而不会对整个系统造成太大影响。使用微服务，你可以进行水平扩展、有确定的模块边界、使用多种技术进行并行开发。谈到与微服务相关的风险时，Buelta 说，“采用微服务的主要风险，尤其是当起步于一个单体应用时，是设计的服务不是真正独立的。这将增加服务间通信的开销和复杂性。”

他补充道，“从长远来看，微服务系统的设计需要一个高层次的视角。我对正在朝着这种架构发展的组织的建议是，让某人负责“大局”。你不想只见树木不见森林。”

从单体迁移到微服务

著名作家和软件顾问 Martin Fowler 建议采用“ 单体优先 ”的方法。这是因为，从一开始就使用微服务架构可能存在风险，因为它主要适用于大型系统和大型团队。

Buelta 同意他的观点，“开始考虑进行这种迁移的主要标准是原来的团队规模。对于小型团队来说，这样做是不值得的，因为开发人员了解所有正在发生的事情，并且可以向坐在房间里的人询问任何问题。单体在这些情况下效果很好，这就是为什么几乎每个系统都是这样开始的。”这就是亚马逊的“双披萨团队”原则。该原则规定，如果一个负责微服务的团队两个披萨都不够吃，那么这个团队就太大了。

“随着业务和团队的增长，他们需要更好的协调。开发人员开始经常互相干扰。了解特定代码段的意图比较困难。这时候进行迁移，将功能分隔，获得更好的清晰度，是有意义的。每个团队都可以设定自己的目标，并且基本上可以独立工作，暴露出一个清晰的外部接口。但要想让这一切有意义，就必须有足够数量的开发人员，”他补充道。

微服务迁移的最佳实践

当被问及开发人员在迁移到微服务时可以采用哪些最佳实践时，Buelta 说，“微服务架构成功的关键是每个服务尽可能独立。”

Buelta 解释说，“这里出现的问题是‘如何使服务独立?’发现系统之间的相互依赖关系的最佳方法是从新特性的角度进行思考：如果有一个新特性，是否可以通过修改单个服务来实现？什么样的特性需要协调几个微服务？是常见的需求，还是罕见的需求？没有哪种设计是完美的，但至少有助于做出明智的决定。”

Buelta 建议使用正确的方法做而不是做两次。他补充道，“一旦迁移完成，就很难对微服务的边界进行更改。在项目初期投入的时间是值得的。”

从一个架构模式迁移到另一个架构模式是一个很大的变化。我们问他和他的团队在这个过程中遇到了什么挑战，他说，“最困难的挑战其实是人。它们往往被低估，但转向微服务实际上改变了人们的工作方式。这可不是件容易的事!”

他补充道，“我遇到过这样一些问题，比如必须为开发人员提供足够的培训和支持。特别是，解释一些改变背后的根本原因。这有助于开发人员理解，为什么他们要做出这些让人感到如此沮丧的改变。”

例如，从单体应用迁移的一个常见抱怨是部署时需要协调，而以前是一次单体发布。这需要更多地考虑如何确保向后兼容和最小化风险。这有时不是很明显，需要专门说明。”

关于选择 Docker、Kubernetes 和 Python 作为技术栈

我们问 Buelta，他更喜欢用什么技术来实现微服务。对于语言，他的回答很简单：“对我来说，Python 是一个非常自然的选择。这是我最喜欢的编程语言！”

他补充道，“它非常适合这项任务。它不仅可读性强、易于使用，而且对 Web 开发也有足够的支持。除此之外，它还有一个充满活力的第三方模块生态系统，可以满足任何可能的需求。这些需求包括连接到其他系统，如数据库、外部 api 等。”

Docker 通常被说成是微服务中最重要的工具之一。Buelta 解释了原因，“Docker 允许将应用程序封装并复制到一个便捷的标准包中。这减少了不确定性和环境复杂性。它极大地简化了应用程序从开发到生产的过程。它还有助于降低硬件利用率。你可以在同一个物理机或虚拟机中安装多个具有不同环境、甚至不同操作系统的容器。”

对于 Kubernetes，他说，“最后，Kubernetes 使我们能够协调部署多个 Docker 容器。它迫使你以集群的方式进行思考，同时还需要时刻考虑生产环境。它还允许我们使用代码定义集群，在文件中定义新的部署或配置更改。所有这些都支持我在这本书中描述的 GitOps 之类的技术，将完整的配置存储在源代码控制系统中。这使得任何更改都是明确的、可逆的，因为它们是常规的 Git 合并。它还使得从零开始恢复或复制基础设施变得简单。”

“Docker 和 Kubernetes 有一定的学习曲线，但是完全值得。两者都是非常强大的工具。他们适合于避免生产环境崩溃，”他分享道。

关于多语言微服务

微服务允许你使用不同的技术，因为在理想情况下，每个微服务都由一个独立的团队处理。

Buelta 分享了他对多语言微服务的看法，“多语言微服务很棒！这是它最大的优势之一。典型的例子是将用某种语言编写的遗留代码迁移到另一种语言。可以用一个微服务替换另外一个公开了相同外部接口的微服务，而它们的内部却完全不同。例如，我已经完成了从旧的 php 应用程序到 Python 应用程序的迁移。”他补充说，“作为一个组织，同时使用两个或多个框架有助于更好地理解这两个框架，以及何时使用其中一个框架。”

虽然使用多语言微服务是一个很大的优势，但它也会增加运维开销。Buelta 建议，“不过，需要保持平衡。每次都使用不同的工具，就不能在团队之间共享知识，这不合理。具体的数字可能取决于公司的规模，但一般来说，超过 2 或 3 个应该就需要一个很好的解释，为什么需要在技术栈中引入新工具。保持工具在一个合理的水平也有助于分享知识以及如何最有效地使用它们。”

英文原文:Microservices require a high-level vision to shape the direction of the system in the long term

链接: https://fly63.com/article/detial/8091