从单体到微服务再合并，我们找到了平衡点

云栖号资讯：【点击查看更多行业资讯】
在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！

有人说，程序员总是对好的东西如数家珍，对不好的东西置若罔闻。2015 年，当微服务炒作开始飞起，每个人都在议论它的好处：

弹性；
伸缩性；
易于部署；
清晰的边界。

我们公司也从单体转向了微服务，但最后在二者之间找到了一个平衡点。微服务的一些好处是切实存在的，但它的一些缺点和潜在风险也不可忽视。

从单体到微服务

我于 2017 年加入公司，当时我们的团队大约有 20 名工程师，我们的应用程序是一个部署在 ECS 上的 Django 单体。

在过去两年里，我们开发了很多新服务，以下是一个不完整的清单：

票据服务：管理客户票据；
收费服务：管理 Stripe 的收费和支付；
定价服务：管理服务定价；
匹配服务：为企业经理和供应商之间牵线搭桥；
消息服务：管理聊天功能；
通知服务：管理推送通知、应用内通知和邮件；
审核服务：供应商审核客户；
Netsuite 同步服务：将数据同步到 Netsuite；
Salesforce 同步服务：将数据同步到 Salesforce；
Stripe 同步服务：Stripe 和我们的系统之间的一个传输层；
RDS 监控服务：确保我们的 Postgres 数据库正确备份；
Datadog 监控服务：监控 Datadog 代理运行正常；
GitHub 通知服务：在接到 PR 代码评审时可以收到 Slack 通知；
Gadgets：工具套件。

看着服务数量增长是一件令人感觉良好的事情。毕竟，我们赶上了现代化开发实践的步伐！除此之外，相比单体，开发这些小型服务让我们感觉更好。

收割微服务的好处

微服务确实有显而易见的优势。

清晰的边界

微服务提供了清晰的服务边界。哪些东西应该由谁负责，几乎没有留下模棱两可的余地。如果你的团队拥有某个服务，那么与这个服务相关的问题就应该由你的团队负责解决。清晰的边界让团队专注于自己的服务，不会让问题恶化。

更小的测试集

我们的单体需要 5 到 10 分钟才能跑完测试，而微服务只需要几秒钟。

更快的部署

更小的测试集带来了更快的部署速度。我们的单体有一些基于 Selenium 的测试，用于确保仪表盘关键功能运行正常。但有很多服务不是面向用户的，完全可以跳过这些测试，直接把这些服务的部署时间降低了一半。

CI/CD 问题的影响范围更小了

有时候，某个服务的 CI/CD 管道出了问题会影响到其他新代码的部署或者会导致 bug 被发布到生产环境，我们不得不暂停部署，一直等到问题被修复。在开发单体时，所有开发人员的 PR 都必须暂停，等问题得到修复。但是，如果是开发微服务，其他团队的问题不会影响到你的部署。所以，微服务最令人感到幸福的一点是部署速度快。

更简单更低的依赖风险

如果只是对某个服务做出变更，在做出变更时就不会那么可怕了。所以，相比单体，我们的很多微服务都可以保持最新状态。例如，当我们的微服务更新到 Python 3 时，单体仍然在使用 Python 2。很多团队不敢随意更新单体，因为那样可能会影响到系统的其他部分，而他们对这些部分不太熟悉。另外，更新单体的责任应该由谁来担？这个很难说清楚。

微服务的缺点

随着微服务数量的增长，我们开始感到事情不像之前那么顺利了。

需要维护更多的基础设施

每多一个新服务，就会增加一些基础设施。比如，一个 ECS 服务、一个 Postgres 实例或一个 RabbitMQ 实例。CI/CD 的配置也会增加，还需要进行第三方服务（比如 Rollbar/Sentry）配置。依赖也需要更新，而且需要更新依赖的地方越来越多。基础设施团队在项目上花了很多时间，为每一个服务重复着枯燥无味的工作。

无人照看的服务

小型的服务容易被人忽略，在运行起来之后，基本上会被搁在一边，最后就会过时。

一个微服务如果半年没有被动过，人们一般就不太会去修改它，其中有 90% 的修改都是依赖更新或基础设施更新。也就是说，我们给自己增加了额外的维护负担。

更慢的功能开发

如果服务边界没有搞清楚，会显著降低功能的开发速度，这是微服务的一个很大的风险点。开发一个跨多个服务的功能需要做更多的工作，而重构一个跨多个服务的功能是一个噩梦。如果服务边界很清晰，大部分项目只会影响到一个服务。但是，对于初创公司来说，它们的发展方向是不可预测的。一个产品的两个部分在一开始可能是完全独立的，但一年之后可能会变得紧密耦合起来。所以，要完全清晰地定义服务边界不是件容易的事。

依赖库

为了让所有微服务使用同级的依赖，我们需要从单体拉取依赖库，而更新这些依赖库成了我们的一个痛点。更新依赖库需要发布新版本，如果库很重要，需要在很多地方做出更新。

技术大杂烩

微服务带来的一个好处是“技术多样性”，但它最后会变成一个问题。我们的单体是用 Django 开发的，而我们的部分微服务使用了 Flask。单体使用 Celery 处理异步任务，而部分微服务使用了 RabbitMQ。有一个微服务使用了 DynamoDB，而其他微服务使用了 Postgres。

后来，我们花了很多时间重构微服务，让所有的微服务都用上同样的技术。因为一些库依赖了某些特定的技术，而我们的一些微服务无法使用它们。另外，技术多样性会给新加入的开发人员增加难度。

本地开发问题

随着微服务数量的增多，在开发时就需要在本地运行更多的服务。应用程序的容器化确实帮了我们一些忙，但相比之前，我们不可避免地遇到了更多本地开发问题。