写点什么

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

  • 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:583668

评论 1 条评论

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

他来了!袋鼠云大数据基础平台EasyMR正式上线

袋鼠云数栈

未来智安加入中国通信标准化协会成为全权会员

未来智安XDR SEC

01简单架构分析

神奇的叶叔叔

Groovy closure 与Java function转换

FunTester

西部省份数字化需求暴涨 首届828 B2B企业节见证企业数字化新浪潮

科技热闻

微服务框架搭建过五关斩六将—第一关(网关)

为自己带盐

微服务 网关 9月月更

红海竞争下,「社交+」在中东泛娱乐 App 市场的出海新机遇

融云 RongCloud

白皮书 泛娱乐 出海

【云原生 | 从零开始学Kubernetes】十二、k8spod的生命周期与容器钩子

泡泡

Docker 云计算 云原生 k8s 9月日更

行走的Offer收割机!首次公布Java10W字面经,Github访问量破百万

Geek_0c76c3

Java 数据库 开源 程序员 面试题

开源技术公开课丨Taier工作流的介绍

袋鼠云数栈

实战案例,个个是经典,不愧是阿里P7私传“并发编程核心讲义”,竟能讲的如此通透

程序知音

Java 并发编程 多线程 高并发 后端技术

易观分析互联网+慢病管理生态洞察,助力行业升级

易观分析

医疗

Android 开发环境的搭建(Android Studio + 逍遥模拟器)

Android Studio 安卓开发 9月月更

如何查询已经执行过的流程信息?

江南一点雨

springboot workflow flowable

模块一作业

知足🐏

Redis进阶知识点(可学习,可复习,可面试)

钟奕礼

java; 编程、

APICloud可视化编程(二)

YonBuilder低代码开发平台

前端开发 APICloud 多端开发

好的,DFS,也学废了!

掘金安东尼

前端 9月月更

《软件开发的201个原则》思考:7.尽早把产品交给客户

非晓为骁

软件开发201原则

【编程实践】详解MySQL在Python中的使用(1)

迷彩

Python MySQL 数据库 pymysql 9月月更

开源项目丨ChengYing 1.1版本重磅发布:新增超多功能,全新优化体验!

袋鼠云数栈

[iOS研习记]聊聊iOS中的Mach-O

珲少

Jmix 中 REST API 的两种实现

世开 Coding

Java Spring Boot Jmix 少代码 企业级开发

如何使用iMazing监督、配置器功能

淋雨

ios iphone

这些Java基础知识,诸佬们都还记得嘛(学习,复习,面试都可)

钟奕礼

编程 java;

信我,Java面试的苦只吃一次,看完这八股文合集,渣渣也能进大厂

钟奕礼

编程 java;

开发者有话说|要不是家里穷,我也不想当码农

三掌柜

个人成长 个人感悟

面试中经常问到的几个问题,快来看看能答对几道吧(Java)

钟奕礼

java; 编程、

ChunJun&OceanBase联合方案首次发布:构建一体化数据集成方案

袋鼠云数栈

开源直播课丨高效稳定易用的数据集成框架——ChunJun类加载原理与实现

袋鼠云数栈

实用五步法教会你指标体系的设计与加工

袋鼠云数栈

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