8场5胜,微服务VS单体架构

越来越多的组织开始放弃单体应用,逐步转向微服务的架构模式–将业务流程分为多个独立的服务。

例如,在一个机票预订中,就可能涉及许多个单独的过程:在航空公司预订机票,付款,并在机票成功预订后向客户发送确认信息。

微服务架构,就是将各个流程按照业务拆分为独立的服务。在上面的示例中,机票预订服务可以被拆分为机票预订,付款和确认,拆分后的微服务可以通过接口相互通信。

那么,微服务与单体应用,究竟有什么不同?

对比1:网络延迟

当涉及微服务时,有一个基本的物理定律在起作用,每当微服务通过网络调用另一服务时,字节就通过网络发送,这涉及将字节转换为电信号或脉冲光,然后将这些信号转换回字节。根据模拟结果,微服务调用的等待时间至少为24ms。如果我们假设实际处理大约需要100毫秒,则总处理时间如下所示:

网络延迟-微服务与单体应用

假设在理想情况下,所有调用执行可以同时发生,并且彼此之间不依赖–这称为扇出模式( fan-out pattern)。下图显示了随着越来越多的调用同时执行,总时间如何减少。

同时执行多个调用意味着总执行时间减少

并行执行所有调用,意味着最长的调用执行完,服务将返回给使用者。

从上图可以看出,单体应用没有网络延迟,因为所有调用都是本地调用。即使在完全可并行化的世界中,单体应用仍会更快。而微服务由于需要多个服务间通信,即使并行调用,也是需要一定的网络延迟。

这一次,单体应用胜利了。

对比2:复杂性

考虑复杂性时,有许多因素在起作用:开发的复杂性和运行软件的复杂性。

由于开发的复杂性,在构建基于微服务的软件时,代码库的大小会快速增长。因为微服务涉及多个源代码,使用不同的框架甚至不同的语言。由于微服务需要彼此独立,因此经常会有代码重复。

另外,由于开发和发布时间不一致,因此不同的服务可能会使用不同版本的库。

对于日志和监控方面,在单体应用中,日志记录就像查看单个日志文件一样简单。但是,对于微服务,跟踪问题可能涉及检查多个日志文件。不仅需要查找所有相关的日志输出,而且还需要以正确的顺序将它们放在一起。

在Kubernetes集群中运行微服务时,复杂度进一步增加。虽然Kubernetes启用了诸如弹性伸缩等功能,但它并不是一个易于管理的系统。要部署单体应用,简单的复制操作就足够了。要启动或停止单体应用,通常只需一个简单的命令即可。还有与单体应用相比,事务还增加了运行微服务架构的复杂性。跨服务的调用,很难保证数据是同步的。例如,执行不当的调用,重试可能会执行两次付款。

这一次,单体应用又胜利了。

对比3:可靠性

在微服务中,如果A服务通过网络以99.9%的可靠性调用B服务(这意味着在1000个调用中,有一个将由于网络问题而失败),这时B调用再C服务,我们将获得99.8%的可靠性。

随着调用时间的延长,可靠性下降

因此,在设计微服务架构时,要考虑网络会在某个时刻断开。微服务提供了一些解决此问题的解决方案。Spring Cloud提供了负载均衡和网络故障处理,诸如Istio之类的服务网格还能够处理多种编程语言的服务。当微服务集群中的服务失败时,集群管理器给出替代方案。这就使得微服务架构具有高度的弹性。

Netflix创建了一个名为Chaos Monkey的工具,该工具可以模拟随机终止虚拟机和容器。微服务的开发者,可以使用Chaos Monkey的工具在测试环境模拟网络断连和网络故障等问题,这样,他们就可以确保系统能够处理生产环境中的停机故障。

单体应用中的所有调用都是在本地完成,因此很少发生网络故障,虽然如此,然而单体应用在云环境却无法满足弹性伸缩的需求。

最后,微服务取得了胜利。

对比4:资源使用

一般来说,微服务会比单体应用使用更多的资源。即使在Docker中运行时,基准测试发现,虽然服务连接数量下降了8%,但是容器编排还将消耗资源,日志聚合和监视也将消耗资源。

但是,微服务使我们可以更聪明地使用资源。由于集群管理器可以根据需要分配资源,因此实际的资源使用量可能要低得多。

在软件中,20%的代码一般会完成80%的工作。如果单体应用的一个实例使用8GB,则两个实例使用16GB,依此类推。使用微服务后,我们可以把单体应用中负责主要职能的20%代码提取成一个服务,因此对于两个实例,我们的RAM使用量为降低到了9.6GB左右。

下图显示了资源使用情况的差异。

随着越来越多的实例在运行,单体应用比微服务需要更多的资源

资源使用率方面,微服务胜利了。

对比5:扩展的精确性

单体应用的扩展有多种办法,运行多个实例,或运行多个线程,或者使用非阻塞IO。对于微服务架构,这三个也都是适用的。

但是,面对客户端越来越多的请求,由于微服务架构更精细,因此扩展单个服务也更加精细。所以,对于微服务来说,扩展既简单又精确。而且,由于微服务的资源消耗较少,又可以节省资源。

相比单体应用,微服务精确的扩展和更少的资源使用,是一个明显的胜利。

对比6:吞吐量

让我们再看一个性能指标–吞吐量。在微服务架构体系中,数据需要在不同服务之间发送,从而会产生一定的开销。如果微服务还不是一个分布式架构,那么他的吞吐量还不如一个单体应用高。

对比7:部署时间

人们选择微服务架构的原因之一就是-能够节省部署时间,满足快速迭代。

由于微服务的职责单一原则,因此对其进行的任何更改都有很明确。然而,修改一个单体应用的功能,可能会“牵一发动全身”。

此外,微服务更易于测试。由于微服务仅覆盖有限的一组功能,因此代码依赖性低,便于编写测试并且运行得快。

还有,微服务的资源消耗较少,并且可以按比例扩展。这就使微服务可以无感知部署,例如,可以先在集群一部分节点上启动微服务的新版本,然后迁移一部分用户到新版本,如果有问题,这可以快速回滚到旧版本。

胜利归功于微服务。

对比8:沟通

在微服务诞生之前,弗雷德·布鲁克斯(Fred Brooks)撰写了开创性的著作《人月神话》,本书的其中一项内容是,沟通渠道的数量随着团队成员的数量而增加。由两个人组成的团队,只有一个沟通渠道。如果有四个人,则最多可以访问六个频道。通信通道数的公式为n(n − 1)/2。由20位开发人员组成的团队拥有190个可能的沟通渠道。将这些开发人员分成两个团队,就可以大大减少沟通渠道的数量。

我们以拥有20个开发人员的团队为例,将其分为四个微服务团队(每个团队五个人),则每个团队有10个沟通渠道。四个团队之间的沟通渠道只有六个。沟通渠道的总数为46,大约占20个人团队的四分之一。

下图显示了,一个大团队的通信渠道数量,和单个微服务团队的通信渠道数量的对比。

因此,将10个以上的开发人员分成几个较小的团队,可以为任何开发项目提供更高的沟通效率。

这是微服务的另一个明显胜利。

谁是赢家?

单体应用获得了3场胜利,微服务获得了5场胜利。

但是,在查看此图表时,请记住它是相对的。微服务并不是解决所有开发问题的万能药。

例如,一个由5个开发人员组成的小型团队可能会倾向于选择单体应用。因为,单体应用不仅更易于管理,同时如果软件产品每秒仅有几个访问量,那么单体应用可能就足够了。

以下是一些迹象,表明微服务架构可能是一个合适的选择:

  • 需要7*24的可靠性
  • 精确的扩展
  • 峰值和正常负载明显不同
  • 超过10个开发人员的团队
  • 业务领域可以被细分
  • 方法调用链路短
  • 方法调用可以使用REST API或队列事件。
  • 几乎没有跨服务的事务

来源:thenewstack.io/microservices-vs-monoliths-an-operational-comparison/

(0)

相关推荐

  • JAVA | 什么是微服务?

    前言 最近公司某个项目的架构越来越庞大,维护起来非常难受.领导提出要把这个项目重构,在工作中需要把原来的项目重构成微服务架构,因此学习微服务相关知识,在这里记录下来,权当笔记的同时也希望能对你有启发. ...

  • .NET Core with 微服务 - 什么是微服务

    今天 以下文章来源于馒哥不光会玩当耐特 ,作者MJZHOU 馒哥不光会玩当耐特这个号主要分享.NET相关知识,但也不光是.NET,也会涉及其他任何技术. 微服务是这几年最流行的架构,说起架构不提微服务 ...

  • 常熟理工学院:微服务无缝嵌入实践教学管理平台 | 封面报道

    实践教学管理工作复杂性分析 实践教学管理工作的复杂性,首先体现在内容上.实践教学管理工作不仅包括很多常规性事务,如实验设备管理.教学资源准备.实践教学过程管理.档案日志管理及其他日常管理,还包括很多临 ...

  • 爱奇艺微服务标准技术架构实践「转」

    原文地址:https://www.infoq.cn/article/AJj3lKQyaKVeA08Bgj9e 背景 为数以亿计的用户提供优质的视频服务的爱奇艺技术产品团队,为了适应业务的快速迭代和创新 ...

  • 一文带你读懂微服务的技术架构体系,微服务不再难!

    前言 大家对微服务是怎么理解的?在大家心里微服务是什么样的?究竟什么是微服务?微服务的组织架构是怎么分层的?下面就给大家介绍一下. 1.什么是微服务 1)一组小的服务(大小没有特别的标准,只要同一团队 ...

  • 一文了解四种软件架构:Serverless架构、微服务架构、分布式架构、单体架构

    如果一个软件开发人员,不了解软件架构的演进,会制约技术的选型和开发人员的生存.晋升空间.这里我列举了目前主要的四种软件架构以及他们的优缺点,希望能够帮助软件开发人员拓展知识面. 一.单体架构 单体架构 ...

  • 单体应用到分布式再到微服务,用户认证和授权机制的演进史

    Web应用和用户的身份验证息息相关,从单一服务器架构到分布式服务架构再到微服务架构,用户安全认证和授权的机制也一直在演进,下文对各个架构下的认证机制做个总结. 单一服务器架构 该架构下后端只有一台服务 ...

  • 学习一下 SpringCloud (一)-- 从单体架构到微服务架构、代码拆分(maven 聚合)

    一.架构演变 1.系统架构.集群.分布式系统 简单理解 (1)什么是系统架构? [什么是系统架构?] 系统架构 描述了 在应用程序内部,如何根据 业务.技术.灵活性.可扩展性.可维护性 等因素,将系统 ...

  • 如何通过分解和增量更改将单体迁移到微服务?

    服务迁移不是一个小更改.你必须搞清楚它是否真的能解决你的问题,否则你可能会创建一个会杀死你的.乱糟糟的实体.单体有不同类型,其中一些可能是有效的,足以满足业务需求.单体不是一个应该被杀死的敌人.微服务 ...

  • “逃离”单体,GitHub的微服务架构实践

    作者 | Sha Ma 出品 | http://03ozy.cn/QhFuJ 本文介绍 GitHub 如何从单体架构迁移到微服务架构,并对其中一些最佳实践做了详细说明. 1旅程开启 GitHub 创建 ...

  • GitHub 从单体到微服务之旅

    转自:InfoQ 作者:Sha Ma 本文作者 Sha Ma 是 GitHub 软件工程部门的副总裁,负责核心平台和生态系统.本文内容是介绍 GitHub 如何从单体架构迁移到微服务架构,并对其中一些 ...

  • 从单体到微服务,这些年架构的演变

    背景 这两年业界最流行的技术架构话题已经从前后端分离,变成了分布式.微服务.DDD了.微服务架构适合所有的公司吗,业务场景演变到了什么地步才需要考虑上微服务呢?毕竟选择技术架构之前应该考虑业务是否与之 ...