63

为什么微服务从未被技术雷达“采纳”?

 5 years ago
source link: https://insights.thoughtworks.cn/microservices-adopt/?amp%3Butm_medium=referral
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

如今,微服务在许多组织中发挥着重要作用。自从James Lewis和Martin Fowler发表了那篇 开创性的文章 后,微服务也随之声名鹊起。此后,Sam Newman也撰写了相关著作并举办了许多讲座,ThoughtWorks、Netflix和Google的人,还有许多 其他 组织和个人也纷纷发表文章,进一步推动了微服务的发展势头。微服务很快就进入了 ThoughtWorks技术雷达 的Trial(试验)环,但一直以来,微服务都未进入Adopt(采纳)环。这篇文章便是想探讨一下,为什么微服务一直没有为技术雷达所“采纳”。

Adopt环有意把标准设置得很高

首先,一起回想一下雷达上“试验”环和“采纳”环的定义。“试验”意味着相应技术已经可以供企业在自己的系统中进行尝试。表示我们在已经或多或少地将该技术投入生产,而且相信该技术是稳定的,知道如何以及在何处使用该技术。而进入雷达“采纳”环意味着,我们认为在适用的情况下这种技术是首选解决方案。例如,对于数据库, Neo4J 就是一种进入了“采纳”环的图形数据库。这并不意味着所有数据都应该放入图形数据库中,而是意味着当你想使用图形数据库,Neo4J就是理想之选。

考虑到上述定义,我们为何不将微服务或微服务架构放入“采纳”环?毕竟,微服务经常作为各种会议和文章热议的话题,也有越来越多的组织正在转向采用这种架构风格,ThoughtWorks团队已经成功地将微服务用于许多项目。

我们未将微服务放入Adopt环,有多种原因。一部分原因在于“采纳”环的定义,另一部分原因则在于微服务本身。我们先从技术雷达的特定问题谈起。

将某种技术放入“采纳”环是一种非常强烈的表态。我们不希望在考虑做出这种建议时,存在太多让我们举棋不定的因素。将某种技术放入“采纳”环意味着,我们确信对于一些显而易见的情况来说,采用这种技术是正确的选择。在考虑微服务时,虽然它有一些明显的优点,但同时存在 成本 问题。对成本与效益的权衡因组织而异;组织的成熟度、领域和其他因素可能会影响可用的开发资源。从这个方面来讲,我们不能做出采用微服务的建议,技术雷达对于“采纳”的定义不应当模棱两可。

更重要的是,另一方面,将某种技术放入“采纳”环就要求,这项技术应该可以在各种成熟度范围内的客户和一般企业之中普遍采用。例如,如果某种技术适用于初创企业,但不适用于大型企业,就不应该放入“采纳”环,一个突出的例子是技术公司广泛应用的分布式版本控制系统。我们没有将这种系统纳入到“采纳”环,因为当时许多企业仍在努力采用基本的源控制。我们认为从一无所有到分布式版本控制的飞跃太大了,不能做出采用该系统的强烈建议。我们最终还是 将Github放入了Adopt环中 ,但那是几年之后了。

并非所有组织都适合采用微服务

最后,正如 Martin Fowler在一篇关于微服务的文章 中所指出的,在考虑采用微服务之前,需要在持续交付和基础设施自动化实践等方面达到一定的成熟度(也许不需要太高)。然而,对于许多组织而言,要达到这种成熟度仍然力所难及。微服务会增加操作负担,因为有更多东西需要监控和生成警报,还有更多东西需要部署。在这方面,全面的自动化和持续交付实践至关重要。

此外,微服务架构还具有一些在单体式应用程序中完全不可能出现的错误模式。微服务系统本质上是分布式的,业务流程通常通过多项微服务的交互来完成。在单体式应用程序中,这些业务流程通常在同一流程边界内执行,从而可以执行传统事务并能确保全部执行或全部不执行。虽然我们可以为所有这些问题提供解决方案,但不可忽视的是,微服务方法确实会引入这些问题并需要处理。因此,需要在微服务方法增加的灵活性和单体式方法的简单性之间进行权衡(这种权衡很常见),尤其是在单体式应用程序结构完善的情况下,从灵活性中获益不多的应用程序不适宜采用微服务架构。

微服务架构的关键设计决策是在服务之间设置边界。虽然 有界上下文 肯定能为设置适当边界位置提供有效指导,但是仍然存在选择,而选择错误会使系统变得更复杂。对于某个新领域而言,边界的设定会比较模糊,因此在未进一步明确领域和适当上下文之前,有理由暂不开始采用微服务架构。

微服务对企业来说仍然非常重要!

现在,你可能想知道我们为什么推荐微服务架构,或者我们是否仍然推荐此架构。灵活性、独立的可扩展性、不断演进的特性、强大的封装仍然是微服务不可不说的优点。这些优点已经在其他文章中进行了详尽的阐述。我们仍然坚定使用微服务架构,以扩展我们对这种架构的理解,并继续探索解决本文所提到问题的工具和方法。实际上,来自ThoughtWorks的Zhamak Dehghani最近发表了 一篇关于将单体式应用程序分解为微服务的文章 。但是,该方法的成本和缺点以及执行该方法所需达到的组织成熟度水平正是微服务很可能永远无法进入“采纳”环的原因。

本文翻译自ThoughtWorks全球首席技术官Rebecca Pasrsons的 《Microservices in Adopt? 》一文。Rebecca将在3月15日来到技术雷达十周年峰会现场,与众位国际软件巨匠一同讲述技术领域的十年趋势变革。点击阅读原文即可享受限时七折票!


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK