AI实践哪家强?来 AICon, 解锁技术前沿,探寻产业新机! 了解详情
写点什么

小团队中微服务的可怕之处

  • 2021-06-01
  • 本文字数:2160 字

    阅读完需:约 7 分钟

小团队中微服务的可怕之处

本文最初发表于 Medium 博客,经原作者 Manuel Reinfurt 授权,InfoQ 中文站翻译并分享。

 

微服务听起来很棒,每一个团队可以彼此独立工作而不影响其他团队。你可以轻松地维护和扩展微服务。你也可以在同一项目中使用不同的技术。它们如此稳定,所以,你的产品会有极好的扩展。在 2021 年,不应该把任何应用作为单体来构建,对吧?

 

很遗憾,微服务并非在每一种环境下都可以发挥作用,在盲目使用之前,你必须确定它们提供了你所需要的价值。我见过几个典型的项目,有 4~6 名开发者,基本上是一个团队。客户想要构建微服务的应用程序,因为它们非常棒。IT 经理同意了,于是团队开始设计应用程序。

 

用户管理?是的,这是一个微服务。访问权限管理?也是微服务。管理和预约?同样是微服务!通过连接到几个第三方 API 来管理和发送订单?这绝对是一个微服务。不错,现在每个人都可以得到一个微服务了!有时候你可能会违反物理学法则,每个人都有多个微服务。

 

恐怖开始

 

当你开始这个伟大的旅程时,你的团队需要确保每一个微服务都可以独立开发。每一个微服务都有它自己的 CI/CD 管道,自己的数据库和自己的版本化 API

 

现在,在启动一个新项目时,你可能只有一个团队。将在同一个团队中构建所有这些微服务。这种情况经常发生:一个人为了实现一个新功能而承担多个微服务。让我们就叫她 Ellie 吧。Ellie 需要在任何地方进行一些调整,同时进行测试。当她遇到问题时,她可以开始对两个微服务进行并行调试,以尝试了解它们之间的通信。如果它实际上是应用程序的一部分,那么 Ellie 就拥有一个更简单的工作环境,并且可以直接在应用程序中进行调试。此外,她还不需要为这些微服务之间的分布式、可能是异步通信编写大量定义和代码。

 

之后,你的应用程序的第一个版本将提供给你的客户。当你更新应用程序并尝试开始滚动更新时,你将面临在某一时间内运行微服务的多个版本。要么它们都与其他版本兼容(这也需要在开发过程中进行一些工作),要么你需要以某种方式优雅地更新它们。

 

在最坏的情况下,你正在构建一个分布式的单体应用。而且,在你的小团队里,你会发现微服务的所有缺点,但是很可能并没有从这些中获益。

 

微服务的亮点在哪里?

 

亚马逊和 Netflix 是最早提到他们使用微服务的大公司之一,他们解释了微服务为何如此有用。亚马逊提出了两个披萨原则,并表示:“如果两个披萨不足以喂饱一个项目团队,那么这个团队可能就显得太大了”。每个团队都应该有自己的微服务,它绝不应该在两个团队之间分割。要获得完全的所有权,团队必须对其组件及其相关的所有东西拥有完全的控制权

 

在单体应用中管理代码和依赖项,面对庞大的软件和数百人的工作,是相当麻烦的。因为微服务与其他所有东西解耦,这是一个完美的方法,可以扩展开发团队的数量。他们可以在自己的微服务上工作,使用已经构建的 API,并扩展现有产品。他们无须与其他 80 个团队中的每个决策保持一致,而且他们可能不必选择相同的技术或保持版本一致。

 

微服务对于管理大型软件来说并不是必需的,而是管理大量使用这些软件的人。

 

我现在该怎么办?

 

但这并不意味着微服务就会陷入混乱。但是,我要你真正思考微服务对你的意义,以及你是否能从中获益。当然,它们可以为你提供许多好处,但同时也增加了许多复杂性。假如这些好处对你无关紧要,你就可以跳过它们。

 

一个很好的软件开发范式是保持简单。既然可以简单地实现相同的结果,为什么还要选择更复杂的方式呢?你只会让它变得更难理解,以后也更难改变。

 

微服务同样如此。既然你的团队必须处理所有微服务,并完全控制应用程序,为何还要增加微服务的复杂性?你的产品可能会增长,但是两周内它并不会成为下一个 Netflix。就像俗话所说的:“过早的优化是万恶之源”,所以不要急着优化!

 

相反,享受一个相当单一的应用程序的好处。尽情享用更快的开发速度,因为你不需要担心改进微服务间的通信,不需要花费更多时间调试和测试微服务间共享通用代码的意义,不需要尝试协调复杂的分阶段微服务发布,甚至不需要在每个微服务上处理巨大的 docker 映像大小和内存需求,因为你正在使用 Spring Boot。

 


你也不需要全心致力于单体或微服务。你仍可以将应用程序划分为有意义的部分 —— 甚至遵循领域驱动设计的指导原则。有了合适的架构,你的代码和模块仍然可以被恰当地解耦,并且你的应用程序符合 12 要素原则。可以在相同的应用程序中运行这些模块,可以共享相同的构建管道,只需部署一个版本即可进行部署。

 

但我如何扩大规模呢?

 

你发布了你的产品,而且非常成功。你希望构建更多功能并适当地扩展。你雇佣并组建了多个开发团队,你是否真的从微服务中获益?现在正是将你的应用拆分到微服务的绝佳时机。

 

若你的应用程序构建正确,且不同模块已经解耦并易于理解,则拆分它们应该不会太困难。是啊,得费点功工夫。当然,你可以从一开始就直接使用微服务来避免这个问题。但是在这种情况下,你也必须从一开始就直接处理复杂的事情,并且拖拖拉拉。

 

保证在适当的时候选择合适的架构并且保持简单。关注代码架构和质量

 

作者介绍:

 

Manuel Reinfurt,InCloud 首席技术官。负责技术领导与新工作。精通 Azure、.NET/C#、云计算开发。

 

原文链接:

 

https://medium.com/incloud-hq/the-horror-of-microservices-in-small-teams-208f6660dd5

2021-06-01 14:583774

评论 1 条评论

发布
用户头像
听君一席话,如听一席话。
2021-10-22 15:05
回复
没有更多了
发现更多内容

Filecoin矿机挖矿APP系统开发

获客I3O6O643Z97

区块链+ 云算力挖矿源码 fil挖矿 fil矿机

基础SQL的实现

卢卡多多

7月日更

推荐大家一个阅读全球计算机论文的好RP

奔着腾讯去

你也许连删库跑路都不会

喵叔

7月日更

《淘宝技术这十年》读后总结

淘宝架构 淘宝技术这十年

VGC算力挖矿APP系统开发

获客I3O6O643Z97

挖矿 #区块链# PHA质押挖矿

数仓架构的持续演进与发展 — 云原生、湖仓一体、离线实时一体、SaaS模式

阿里云大数据AI技术

Alibaba全新出品JDK源码学习指南,面面俱到,没有一句废话

Java 编程 架构 面试

Pomo币挖矿APP系统开发介绍

在线医疗不容错过

anyRTC开发者

音视频 WebRTC 实时通讯 在线医疗

模块二作业

江南巴飞特

Mysql,RedisCluster,Kafka,Mongo笔记分享

鲁米

安装

Ansible Playbook - 03

耳东@Erdong

ansible 7月日更 ansible Playbook

英特尔在异构计算前加了一个“超”字,凭什么?

E科讯

市值管理机器人开发,搭建量化交易机器人

Geek_23f0c3

机器人 市值管理机器人开发 #区块链# 量化机器人

Redis - Cluster - gossip&故障转移

旺仔大菜包

redis cluster

网络攻防学习笔记 Day75

穿过生命散发芬芳

网络攻防 7月日更

又快又全的云IT资源运维软件重点推荐-行云管家!

行云管家

云管平台 云资源 IT资源 IT运维

芒果微视系统软件开发内容

养牛达人APP系统开发资料

IPFS/Filecoin项目的未来趋势怎么样?投资Filecoin挖矿有风险吗?

IPFS fil币 ipfs挖矿 fil挖矿 fil矿机

《持之以恒的从事运动》八

Changing Lin

数据中台发展史

escray

学习 极客时间 7月日更 数据中台实战课

hdfs namenode的故障恢复

五分钟学大数据

hdfs 7月日更

ATS挖矿系统开发案例

疯了吧!这帮人居然用 Go 写“前端”?(二)

尔达Erda

开源 云原生 大前端 PaaS Go 语言

前端通讯协议大比拼:WebSockets和HTTP

devpoint

HTTP websocket HTTP2.0 7月日更

“此苹果非彼苹果”看意图识别的那些事儿

百度大脑

人工智能 飞桨 数据抽取

Kubernetes-技术专题-Spring Boot 2.0和 Docker 的微服务快速指南

码界西柚

容器 k8s 7月日更

爱尚拼购系统软件开发搭建

傻眼了,我粗略造了一个命令执行的绕过方法居然被同事嫖走了

网络安全学海

黑客 网络安全 信息安全 渗透测试 漏洞分析

小团队中微服务的可怕之处_架构_Manuel Reinfurt_InfoQ精选文章