极客视点
极客时间编辑部
极客时间编辑部
113244 人已学习
免费领取
课程目录
已完结/共 3766 讲
2020年09月 (90讲)
时长 05:33
2020年08月 (93讲)
2020年07月 (93讲)
时长 05:51
2020年06月 (90讲)
2020年05月 (93讲)
2020年04月 (90讲)
2020年03月 (92讲)
时长 04:14
2020年02月 (87讲)
2020年01月 (91讲)
时长 00:00
2019年12月 (93讲)
2019年11月 (89讲)
2019年10月 (92讲)
2019年09月 (90讲)
时长 00:00
2019年08月 (91讲)
2019年07月 (92讲)
时长 03:45
2019年06月 (90讲)
2019年05月 (99讲)
2019年04月 (114讲)
2019年03月 (122讲)
2019年02月 (102讲)
2019年01月 (104讲)
2018年12月 (98讲)
2018年11月 (105讲)
时长 01:23
2018年10月 (123讲)
时长 02:06
2018年09月 (119讲)
2018年08月 (123讲)
2018年07月 (124讲)
2018年06月 (119讲)
时长 02:11
2018年05月 (124讲)
时长 03:16
2018年04月 (120讲)
2018年03月 (124讲)
2018年02月 (112讲)
2018年01月 (124讲)
时长 02:30
时长 02:34
2017年12月 (124讲)
时长 03:09
2017年11月 (120讲)
2017年10月 (86讲)
时长 03:18
时长 03:31
时长 04:25
极客视点
15
15
1.0x
00:00/06:03
登录|注册

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

讲述:丁婵大小:8.31M时长:06:03
你好,欢迎收听极客视点。
有人说,程序员总是对好的东西如数家珍,对不好的东西置若罔闻。2015 年,当微服务炒作开始飞起,每个人都在议论它的好处:弹性、伸缩性、易于部署、清晰的边界。然而它的一些缺点和潜在风险也不可忽视,放弃微服务重回单体的企业不在少数。国外一家中小企业 Managed By Q 也从单体转向了微服务,不过他们最后在二者之间找到了一个平衡点。
最近,该公司的软件工程师安德烈·斯特罗姆豪格(Per-Andre Strømhaug)分享了他们从单体到微服务再到合并的历程,InfoQ 对其进行了翻译,供你参考。

从单体到微服务的历程

我于 2017 年加入公司,当时我们的团队大约有 20 名工程师,我们的应用程序是一个部署在 ECS 上的 Django 单体。
在过去两年里,我们开发了很多新服务,看着服务数量增长是一件令人感觉良好的事情。毕竟,我们赶上了现代化开发实践的步伐。除此之外,相比单体,开发这些小型服务让我们感觉更好。

收割微服务的好处

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

1. 清晰的边界

哪些东西应该由谁负责,几乎没有留下模棱两可的余地。这让团队专注于自己的服务,不会让问题恶化。

2. 更小的测试集

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

3. 更快地部署

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

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

有时候,某个服务的 CI/CD 管道出了问题会影响到其他新代码的部署或者会导致 Bug 被发布到生产环境,我们不得不暂停部署,一直等到问题被修复。但如果是开发微服务,其他团队的问题不会影响到你的部署。

5. 更简单更低的依赖风险

如果只是对某个服务做出变更,在做出变更时就不会那么可怕了。所以,相比单体,我们的很多微服务都可以保持最新状态。

微服务的缺点

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

1. 需要维护更多的基础设施

每多一个新服务,就会增加一些基础设施。依赖也需要更新,而且需要更新依赖的地方越来越多。基础设施团队在项目上花了很多时间,为每一个服务重复着枯燥无味的工作。

2. 无人照看的服务

小型的服务容易被人忽略,在运行起来之后,基本上会被搁在一边,最后就会过时。
一个微服务如果半年没有被动过,人们一般就不太会去修改它,其中有 90% 的修改都是依赖更新或基础设施更新。也就是说,我们给自己增加了额外的维护负担。

3. 更慢的功能开发

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

4. 依赖库

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

5. 技术大杂烩

微服务带来的一个好处是“技术多样性”,但它最后会变成一个问题。我们的单体是用 Django 开发的,而我们的部分微服务使用了 Flask。单体使用 Celery 处理异步任务,而部分微服务使用了 RabbitMQ。有一个微服务使用了 DynamoDB,而其他微服务使用了 Postgres。
后来,我们花了很多时间重构微服务,让所有的微服务都用上同样的技术。因为一些库依赖了某些特定的技术,而我们的一些微服务无法使用它们。另外,技术多样性会给新加入的开发人员增加难度。

6. 本地开发问题

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

找到平衡点:合理大小的服务

在转向微服务两年之后,我们开始合并微服务。一些微服务被合到了单体中,其他的则合并成较大的服务。在一年中我们总共移除了 9 个微服务。
大小合理的服务承担着相当大的责任,大多数功能开发都可以在单个服务中完成。它们足够大,不会给我们增加太多的基础设施维护负担。服务边界清晰,避免团队在开发过程中彼此影响。
以上就是 Managed By Q 的微服务实践经验,如果你的公司正在考虑迁移到微服务架构,那么要注意划分服务边界,并考虑使用大小合理的服务。
原文链接:
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
该免费文章来自《极客视点》,如需阅读全部文章,
请先领取课程
免费领取
登录 后留言

精选留言

由作者筛选后的优质留言将会公开显示,欢迎踊跃留言。
收起评论
大纲
固定大纲
从单体到微服务的历程
收割微服务的好处
1. 清晰的边界
2. 更小的测试集
3. 更快地部署
4. CI/CD 问题的影响范围更小了
5. 更简单更低的依赖风险
微服务的缺点
1. 需要维护更多的基础设施
2. 无人照看的服务
3. 更慢的功能开发
4. 依赖库
5. 技术大杂烩
6. 本地开发问题
找到平衡点:合理大小的服务
显示
设置
留言
收藏
41
沉浸
阅读
分享
手机端
快捷键
回顶部