17611538698
webmaster@21cto.com

只有 1% 的人需要微服务

架构 0 807 2023-02-07 10:24:50

图片

导读:只有 1% 的人需要微服务。而当今有一些技术团队为了微服务而微服务,平添很多重复杂性,成本大于效能多倍。

本文言简意赅,发人深省,告诉我们如何调整。

图片


微服务,只有年收入 20 亿美元的公司才需要。

这是个肯定句,是经过多层的数据研究,公司到达此规模,才有充分的理由采用微服务架构。

之前是什么状态?

单体式架构演化为基于服务的模块化单体式架构,然后才演化为宏服务、迷你服务与微服务。

这是为什么?

付出最少努力的解决方案,是提供适应和发展业务能力的首选解决方案。

什么是微服务架构?


微服务架构就像沙漠中的一粒沙子,虽然很小,但聚集在一起,就会变得非常庞大。


微服务的关键特征包括:

  • 小而集中

  • 执行非常细微的功能

  • 只操作需要的数据

  • 服务层上进行协作

  • 通常按反应方执行

  • 数据按比例解耦


如果微服务做得好,它们将拥有完全自动化的配置流程,这是纯正的云原生,在各个层都会有很好的解耦。

但它们存在一些问题,需要做以下权衡:

  • 业务流程更难以映射

  • 服务协作很困难

  • 数据状态难以协调

  • 集成要复杂得多

  • 自动化成本更高

  • 复杂性更难控制

  • 可观察性是一个挑战


减少这些权衡需要一种渐进的方法,来让事情变得更小,同时处理分发的额外复杂性。对于我们大多数人来说,当公司的年收入不到 20 亿美元时,并不需要微服务特性。

架构如何帮助业务?


许多组织考虑转向微服务架构,希望很快赶上最新趋势的潮流。

独立于技术架构,企业希望在速度兼具质量的范例中实现增长:

  1. 为用户传递价值

  2. 快速测试新的想法

  3. 可在短时间内适应

  4. 保持可控性

  5. 支持增加流量

  6. 有利可图

从该列表中,下一阶段是确定技术如何成为业务限制的因素,以明确区分问题与可能的解决方案。

所有解决方案通常都需要关键功能的高可用性、更多的模块化,以更好地适应更多的变化以及在小范围内测试想法的能力。

不同的是限制因素,这取决于上下文:

  • 哪个范围必须改变很多?

  • 是否有关键区域不稳定或存在风险?

  • 哪些部分累积了更多的复杂性?

  • 哪里达到协作限制?

  • 哪些资源可以更改?


这些问题是定义从初始架构所需的最小架构演变的起点,可能并不用改变那么多。

架构与业务一起成长


软件行业发展到社会技术生态系统的概念,认识到人、流程、组织、文化和技术之间的联系。

这种相互依赖性需要每个领域保持一致,使其朝着正确的方向发展,以最小的努力发展业务。

基于该模型,应避免的问题实例是:

  • 只有3 名软件工程师的微服务架构;

  • 拥有 500 名开发人员的模块 ,但缺少共享支持

  • 每个软件团队在没有共享支持的情况下完成 50% 的运行任务


该列表还在继续。

我们对 50 多家公司的研究揭示了以下的宏观模型:

  1. 单体:收入为 0-200 万美元,10 个 FTE (全职员工

  2. 单体模块化:2-2000 万美元的收入,最多 50 个 FTE

  3. 基于服务:20-2 亿美元的收入,最多 500 个 FTE

  4. 从宏服务到迷你服务:2 亿美元至 20 亿美元的收入,最高 5000 FTE

  5. 迷你服务到微服务:超过 5000 个 FTE ,收入 > $20亿美元。


请看如下图片:

图片


分析还显示,声称要实施微服务的公司实际上是在实施基于服务或宏服务的架构。

例如,数字电子商务上下文中的“购物车”服务是宏服务而不是微服务,因为它是模块化的,具有与其它应用程序的显式接口,但仍在相同的功能和技术范围内执行多种业务功能。

关键的技术差异在于服务的粒度更高,服务之间共享数据而不是外部解耦。

以最小的努力调整生态系统


在业务发展的不同阶段,不同的架构需要不同的社会技术生态系统。


目标与技术无关——它与支持业务适应和快速增长的最小一致性有关。


在日常工作中可能没有那么花哨的流行语,但更高的效率和软件交付将有所作为。


因此,首先要为自己的业务做出正确的选择,同时“单体模块化”和“最小架构”再次成为主流。


它们均是质量工程的一部分。如果本篇文章对你有用,请点赞 👏


作者:大雄


评论