微服务的灾难-拆分

栏目: 后端 · 发布时间: 5年前

内容简介:在之前写事故驱动开发的时候,提到过,在企业中的项目进行开发时,只要是自己方便,一个人可以用拆分和收敛同时作为自己的标准。所以大家都是双标狗。目前业界的微服务方法论一般也没有固定的套路,比如在 《Building Microservice》 一书中,作者也讲到了服务之间协作的时候,可以选择编排(orchestration)和协同(choreography)这两种方式来对服务进行架构。所以在拆分阶段,就没有什么硬性的标准了,每个公司可能风格都有差别,并且都可以阐述出自己的条条以支持自己的架构是“正确”的。显然,

在之前写事故驱动开发的时候,提到过,在企业中的项目进行开发时,只要是自己方便,一个人可以用拆分和收敛同时作为自己的标准。所以大家都是双标狗。

目前业界的微服务方法论一般也没有固定的套路,比如在 《Building Microservice》 一书中,作者也讲到了服务之间协作的时候,可以选择编排(orchestration)和协同(choreography)这两种方式来对服务进行架构。所以在拆分阶段,就没有什么硬性的标准了,每个公司可能风格都有差别,并且都可以阐述出自己的条条以支持自己的架构是“正确”的。

显然,这件事情没有绝对正确的解法。无论哪种拆分方式,都会遇到业务边界的问题。在大企业中,戴着“架构师”头衔的这些架构师们根本就不会管任何实现上的细节。相对较大的业务需求,一般也是一线的 RD 商量怎么进行实现上的拆分。想要达到合适的职责划分,需要多个合作方的所有人都靠谱才行。这个要求实在是有点强人所难。比如在目前的公司内进行了三年多的开发,就和各种类型的人都打过交道。

兢兢业业的人比较多,但也不乏一些完全不负责任的人。有的素质奇差,只会逢迎甩锅,自己模块的职责都搞不清楚。本来自己该做的兜底不做,让所有下游系统给他擦屁股。从应聘要求上来讲,程序员应该是一个注重逻辑能力,编码能力的职业。然而你总发现有些人是没有办法讲道理的(可能是早期的一些能力一般的员工?),在与这些人讨论技术实现时,会陷入无穷无尽的无意义循环。而他能说(逼)服(迫)所有其它人就范的法宝,就是在两个小时的会议中不断地复读自己的观点,而完全不听取任何别人的观点。一旦这样的人在你的某个系统边界上待着,那你所面临的也是持续的痛苦。并且不断地在自己的系统中进行妥协,做那些职责上跟你的系统完全没什么关系的东西。

除去人的问题,业务部门的大多数一线领导是需要有业务上的业绩的。这种业绩怎么来?一般都是揽各种各样的活儿。从设计原则上来讲,逻辑上相同或者类似的代码应该放在一个地方来实现。这个稍微学过一点 SOLID 中的 SRP 原则就应该知道。这样可以避免逻辑本身过于分散,好处是:“一个类(模块)只会因为一个理由而发生变化”,其实就是相同的需求,尽量能够控制在单模块内完成。当然了这是一种理想状态,确实有些情况下达不到这种完美的平衡状态。微服务场景下这种业务边界往往划分都非常糟糕。即使 Domain Driven Design 的观点讲述了再多的上下文划分技巧,你在实际工作中会发现没有多少人把这些思想、原则当回事。他们在划分模块的职责时只考虑这么几点:

  1. 这件事情有没有业务收益,我能不能掺一脚
  2. 如果没有收益,这件事能不能甩给别人,我就不去做了

把业务上的影响全刨去,才会考虑架构上的事情。有些大佬会讲,系统是演化出来,而不是设计出来的,而这些“演化论”的大佬也是不参与一线开发的。你再看看实际的情况,只靠演化,可能演化出合理的系统么?

不可能的,对人的要求实在太高。而且是对所有开发人员要求都高。相对复杂的业务逻辑,在企业的系统中根本没法合理解耦,很多时候实现一套业务流程的代码会随意地散落在多个模块,在你把所有模块的代码都看过之前,你是没法确定哪部分逻辑在哪个模块里的。可以称之为薛定谔的业务逻辑。

这样在模块发生负责人离职或者工作交接时,所有 RD 都会进入非常痛苦的阶段,我只看自己的模块,根本没法理清全局的业务逻辑!对于产品来说也一样,所有逻辑的分布都具有不确定性,在哪里控制我需要去问研发,而研发还要再问其他的研发,其他的研发如果是刚接手,又要去看大量的代码才能确定到底是怎么回事。如果代码写的烂(对于大多数业务系统来说,如果可以去掉),那可能连看都看不懂。就随便胡诌应付过去好了。现实就是如此荒诞。

在所有服务都在单体的时代,我们可以在合适的时间,参考《重构》书里的观点对我们的模块进行重构。重构对系统本身的要求其实也不大,只要测试覆盖率足够,然后是强类型语言,大多数 IDE 对重构支持都很不错了。但演化到微服务的时代,原来很简单的重构就没那么简单了。在 http://xargin.com/disaster-of-microservice-ul/ 中我们提到,开放的 API、消息、数据库中的字段名根本没有办法进行重构,为什么没有办法,因为我们的模块都被切开了,原本在代码中的强联系变成了分布式系统中的弱联系,薛定谔的联系。如果我们想要实现和单体服务一样的重构功能要怎么办?根本实现不了。你至少需要下面这些设施支持才能完成这样的伟业:

  1. 所有其它模块对你都有集成测试,并且有统一的 API 平台管理所有你们之间的“联系”。
  2. 有全局所有模块的“同时重构”工具

这个显然不可能啊,目前业界提出的 API 版本管理,也只是缓解了这种情况,新功能我如果在新版 API 实现,把旧版 API deprecated 掉,这样就可以逼迫用户放弃对我原来版本的依赖,平滑迁移到新版 API 上来。但显然加上版本,也并没有从本质上来解决问题,API 的用户在没有迭代需求的前提下,因为依赖方进行了修改就不得不进行修改,这是额外的工作量。

你也看到了,拆分给我们带来的并不全是好事,当前中大规模公司的开发日常流程,可能最终还是会把系统整体引向一片混沌。


以上所述就是小编给大家介绍的《微服务的灾难-拆分》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

算法基础

算法基础

布拉萨德 / 邱仲潘 / 清华大学出版社 / 2005-7 / 49.00元

本书是关于算法导论的经典教材,书中包括大量例题解答与命题证明。本书是按照算法类型而不是按照应用类型对算法进行介绍,以其清晰的概念讲解赢得专家们的广泛赞誉。本书适用对象广泛。对于学习算法设计与分析的本科生和研究生,本书是优透选教材。对于从事算法计算研究和工程应用的科研人员和工程技术人员,本书也是一本优秀的基础性读物。一起来看看 《算法基础》 这本书的介绍吧!

在线进制转换器
在线进制转换器

各进制数互转换器

图片转BASE64编码
图片转BASE64编码

在线图片转Base64编码工具

正则表达式在线测试
正则表达式在线测试

正则表达式在线测试