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

标签: 团队 微服务 | 发表时间:2021-06-28 16:20 | 作者:大卫
出处:http://weekly.dockone.io

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

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

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

恐怖开始

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

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

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

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

微服务的亮点在哪里?

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

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

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

我现在该怎么办?

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

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

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

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

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

但我如何扩大规模呢?

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

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

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

原文链接: https://mp.weixin.qq.com/s/DXsAdZOc76ycCAkiF-yN8Q

相关 [团队 微服务] 推荐:

Uber 一团队正从微服务转向宏服务-InfoQ

- -
也许在某个丛林深处的某个地方,有一个未被发现的部落还没有对微服务下定决心,但我很怀疑这一说法. 因为人们对微服务的态度是非爱即恨. 这两者之间并没有什么太多的中间地带. 所以,当 Uber 这样的公司的一支团队宣布从微服务转向其他东西时,这意味着什么. 想想看,你对 Uber 这家公司是怎么看的. 但从软件的角度来看,Uber 一直是个“好公民”.

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

- - DockOne.io
微服务听起来很棒,每一个团队可以彼此独立工作而不影响其他团队. 你也可以在同一项目中使用不同的技术. 它们如此稳定,所以,你的产品会有极好的扩展. 在 2021 年,不应该把任何应用作为单体来构建,对吧. 很遗憾,微服务并非在每一种环境下都可以发挥作用,在盲目使用之前,你必须确定它们提供了你所需要的价值.

爱奇艺视频后台从“单兵作战”到“团队协作”的微服务实践

- - DockOne.io
系统越做越大,功能越加越多,我们是否有如下经历:. 一次小的需求,评估由此产生的影响成本超过开发需求本身. 系统几经交接或升级,接口文档丢失或跟代码严重不符. 每天疲于排查线上问题和修复线上数据,没有精力代码优化. 由于创建/开发/部署新服务的成本,不断的将无关的功能添加到臃肿的服务. 线上服务一个功能或者中间件的中断,导致整个系统不能提供服务.

团队

- Lorna - 坏脾气的小肥
我最近心情起落比较大,如果把时间线再拉长一点,则是去年多自负,今年多自责. 冷静下来的时候也会想,我能不能做得更好. 每一个团队都有它的长处,有它的短处,对于团队的缺陷首先要问自己几个问题:. 1、有没有激励大家全心全意地认同和投入这个项目. 2、有没有分工合理,使每个人认同和投入自己的任务. 3、他的缺陷是否可以通过工作指导、严格督促,在半年或一年时间里自我完善.

初识微服务

- - ITeye博客
微服务架构越来越火,有必要学习一下. 软件开发过程中碰到什么问题. 一个简单的应用会随着时间推移逐渐变大. 在每次的sprint中,开发团队都会面对新“故事”,然后开发许多新代码. 几年后,这个小而简单的应用会变成了一个巨大的怪物. 一旦你的应用变成一个又大又复杂的怪物,那开发团队肯定很痛苦. 敏捷开发和部署举步维艰,其中最主要问题就是这个应用太复杂,以至于任何单个开发者都不可能搞懂它.

谈微服务架构

- - 人月神话的BLOG
其实在前面很多文章谈到SOA,特别是系统内的SOA和组件化的时候已经很多内容和微服务架构思想是相同的,对于微服务架构,既然出现了这个新名称,那就再谈下微服务架构本身的一些特点和特性. 从这个图可以看到微服务架构的第一个重点,即业务系统本身的组件化和服务化,原来开发一个业务系统本身虽然分了组件和模块,但是本质还是紧耦合的,这关键的一个判断标准就是如果要将原有的业务系统按照模块分开部署到不同的进程里面并完成一个完整业务系统是不可能实现的.

微服务性能模式

- - 互联网 - ITeye博客
前言:基于微服务系统越来越普遍. 下面我们就来看看五种常见的特定微服务性能的挑战,以及如何应解他们. 背景:在IT界微服务架构为基础的系统越来越多, 每一个应用系统都集成了不同的组件和服务,几乎所有的特定业务应用程序都需要集成一个或更多的应用服务. 但是一个综合性系统集成不同的服务这无疑是一个巨大的挑战.

微服务与架构师

- - 乱象,印迹
因为工作的关系,最近面试了很多软件架构师,遗憾的是真正能录用的很少. 很多候选人有多年的工作经验,常见的框架也玩得很溜. 然而最擅长的是“用既定的技术方案去解决特定的问题”,如果遇到的问题没有严格对应的现成框架,就比较吃力. 这样的技能水平或许适合某些行业,但很遗憾不符合我们的要求. 软件架构师到底应该做什么,又为什么这么难做好,这都是近来的热门问题,我也一直在和朋友们讨论.

从Excel到微服务

- - 乱象,印迹
Excel很老,Excel很土,Excel一点也不sexy;微服务新,微服务很潮门,微服务很高大上. 那么,Excel和微服务有什么关系. 上个月看了篇文章,The Unbunlding of Excel. 作者认为,对于初创公司(尤其是非“纯IT”初创公司)来说,Excel几乎包办各种工作. 想做轻量级的CRM,可用Excel.

微服务拆分之道

- - DockOne.io
微服务在最近几年大行其道,很多公司的研发人员都在考虑微服务架构,同时,随着 Docker 容器技术和自动化运维等相关技术发展,微服务变得更容易管理,这给了微服务架构良好的发展机会. 在做微服务的路上,拆分服务是个很热的话题. 我们应该按照什么原则将现有的业务进行拆分. 接下来一起谈谈服务拆分的策略和坚持的原则.