从单体到微服务再合并，我们找到了平衡点
云栖号资讯：【点击查看更多行业资讯】
在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！
有人说，程序员总是对好的东西如数家珍，对不好的东西置若罔闻。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。
后来，我们花了很多时间重构微服务，让所有的微服务都用上同样的技术。因为一些库依赖了某些特定的技术，而我们的一些微服务无法使用它们。另外，技术多样性会给新加入的开发人员增加难度。
本地开发问题
随着微服务数量的增多，在开发时就需要在本地运行更多的服务。应用程序的容器化确实帮了我们一些忙，但相比之前，我们不可避免地遇到了更多本地开发问题。
找到平衡点：合理大小的服务
在转向微服务两年之后，我们开始合并微服务。一些微服务被合到了单体中，其他的则合并成较大的服务。在一年中我们总共移除了 9 个微服务。
当然，并不是说我们所有的微服务都是失败的。例如，我们的票据服务与计费及其他几个服务合在一起，有着清晰而稳定的边界。有四个微服务被合并到了“Gadgets”服务中，而这个服务成了与核心领域模型无关的工具的聚集地。
大小合理的服务承担着相当大的责任，大多数功能开发都可以在单个服务中完成。它们足够大，不会给我们增加太多的基础设施维护负担。服务边界清晰，避免团队在开发过程中彼此影响。
如果你的公司正在考虑迁移到微服务架构，那么要注意划分服务边界，并考虑使用大小合理的服务。
【云栖号在线课堂】每天都有产品技术专家分享！
课程地址：https://yqh.aliyun.com/live立即加入社群，与专家面对面，及时了解课程最新动态！
【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK
原文发布时间：2020-06-23
本文作者：Per-Andre Strømhaug
本文来自：“infoq”，了解相关信息可以关注“infoq”
