FCon7折倒计时最后一周:日程已上线70%!查看详情>>> 了解详情
写点什么

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

  • 2020-06-23
  • 本文字数:2385 字

    阅读完需:约 8 分钟

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

有人说,程序员总是对好的东西如数家珍,对不好的东西置若罔闻。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://perandrestromhaug.com/posts/monolith-to-microservices-and-back-again/


2020-06-23 15:434263

评论 4 条评论

发布
用户头像
微服务这种架构模式注定只适合业务变化快(超快)、中小规模团队的创业公司。一旦达到中等规模之上(团队和业务边界),那么这种模式在缺乏管理、基础设施支持、运维团队等的支持下,必然与团队失配。抛开技术不说,微服务解决的主要是人和服务的关系,以及如何通过扩展人来扩展业务,关注垂直领域,一旦涉及大规模横向沟通,那么微服务的价值就会越来越低。所以要根据自己的公司状况选择。初创公司,之所以追求快,是因为可能活不过两年,但是大型公司具备几年不死的底气,所以选型自然不同。
2020-11-28 16:50
回复
用户头像
建议看看DDD
2020-11-11 17:44
回复
用户头像
关键信息没说
2020-06-24 16:59
回复
说的很清楚了,根据自己的情况,找到服务大小的平衡点。其他都是浮云,服务边界最重要。
2020-07-15 14:18
回复
没有更多了
发现更多内容

AI简报-模型集成 SAM 和SWA

AIWeker

深度学习 7月月更

在 Polkadot 中进行创建的三种方式 —— 平行链、平行线程、智能合约

One Block Community

区块链 科技

Gartner:无需数据中台,API就能胜任连接前端和后端的工作

雨果

数据中台 API

leetcode 605. Can Place Flowers 种花问题 (简单)

okokabcd

数据结构与算法 贪心算法

盘点波卡生态潜力项目 | 跨链特性促进多赛道繁荣

One Block Community

区块链 科技

java培训4种Map遍历 key-value 的方法

@零度

JAVA开发 map

网络安全网格概念以及特点简单普及

行云管家

网络安全 网络安全网格

游戏有什么用?| 游戏应用价值研究案例征集

易观分析

游戏

华为影像XMAGE:求尽世间像,终见菩提心

脑极体

西山居如何用 ONES 打造游戏工业流水线?|ONES 行业实践

万事ONES

让企业数字化砸锅和IT主管背锅的软件供应链安全风险指北

FinClip

数据库每日一题---第23天:游戏玩法分析 l

知心宝贝

数据库 程序员 算法 后端 7月月更

没有可观测性,DataOps 注定失败|TheNewStack

观测云

一文搞懂│什么是跨域?如何解决跨域?

前端 经验分享 跨域 7月月更

红象云腾大数据基础平台与龙蜥社区操作系统再次完成联合测试

OpenAnolis小助手

开源 操作系统 龙蜥社区 红象云腾 兼容性互认证

全球云市场增势迅猛,数据安全进入法治化的强监管时代

行云管家

云计算 网络安全 数据安全

【容器篇】Docker怎么限制资源使用

技术小生

Docker 7月月更

怎么学习Object.defineProperty | 一篇文章带你们快速学会

bo

JavaScript 前端 7月月更

焱融科技入选北京市 2022 年度“专精特新”,领航混合云文件存储

焱融科技

了解JVM语言

沃德

Java 程序员 7月月更

【用户文章】P4合并实践指南之实例拆解Resolve

龙智—DevSecOps解决方案

P4合并 解决冲突

用对工具,CI事半功倍

龙智—DevSecOps解决方案

ci 持续集成 ⾃动化构建 ⾃动化部署

代码合规性:开发人员使用Helix QAC的5大原因

龙智—DevSecOps解决方案

静态代码分析 Helix QAC 静态代码分析器

直播带货系统源码

开源直播系统源码

软件测试 APP开发 直播系统源码 直播带货系统源码

自定义spring boot starter三部曲之三:源码分析spring.factories加载过程

程序员欣宸

Java springboot 7月月更

大数据培训 Hive 相关知识的全面总结

@零度

hive 大数据开发

C# 使用ToolTip控件实现气泡提示

IC00

C# WPF 上位机 7月月更

波卡创始人 Gavin Wood:波卡治理 v2 会有哪些变化?

One Block Community

区块链 科技

中国人力资源数字化生态图谱-灵活用工市场

易观分析

人力资源产业

MySQL 添加用户并授予只能查询权限

叫练

知识干货:基础存储服务新手体验营

hum建应用专家

数据库

  • 扫码添加小助手
    领取最新资料包
从单体到微服务再合并,我们找到了平衡点_DevOps & 平台工程_Per-Andre Strømhaug_InfoQ精选文章