【ArchSummit 】会议即将开幕,一起来看架构师在AI时代的“生存法则”总结! 了解详情
写点什么

单体应用与微服务优缺点辨析

  • 2015-04-08
  • 本文字数:1990 字

    阅读完需:约 7 分钟

近日,Java Code Geeks 发表了一篇文章,分析了单体应用与微服务的优缺点,并建议使用微服务重构现有的应用程序。

通俗地讲,“单体应用(monolith application)”就是将应用程序的所有功能都打包成一个独立的单元,可以是 JAR、WAR、EAR 或其它归档格式。单体应用有如下优点:

  • 为人所熟知:现有的大部分工具、应用服务器、框架和脚本都是这种应用程序;
  • IDE**** 友好:像 NetBeans、Eclipse、IntelliJ 这些开发环境都是针对开发、部署、调试这样的单个应用而设计的;
  • 便于共享:单个归档文件包含所有功能,便于在团队之间以及不同的部署阶段之间共享;
  • 易于测试:单体应用一旦部署,所有的服务或特性就都可以使用了,这简化了测试过程,因为没有额外的依赖,每项测试都可以在部署完成后立刻开始;
  • 容易部署:只需将单个归档文件复制到单个目录下。

目前为止,单体应用已经很好地服务了我们,未来无疑还会继续发挥重要作用。但是,不管如何模块化,单体应用最终都会因为团队壮大、成员变动、应用范围扩展等出现问题。下面是单体应用的一些不足:

  • 不够灵活:对应用程序做任何细微的修改都需要将整个应用程序重新构建、重新部署。开发人员需要等到整个应用程序部署完成后才能看到变化。如果多个开发人员共同开发一个应用程序,那么还要等待其他开发人员完成了各自的开发。这降低了团队的灵活性和功能交付频率;
  • 妨碍持续交付:单体应用可能会比较大,构建和部署时间也相应地比较长,不利于频繁部署,阻碍持续交付。在移动应用开发中,这个问题会显得尤为严重;
  • 受技术栈限制:对于这类应用,技术是在开发之前经过慎重评估后选定的,每个团队成员都必须使用相同的开发语言、持久化存储及消息系统,而且要使用类似的工具,无法根据具体的场景做出其它选择;
  • 技术债务:“不坏不修(Not broken,don’t fix)”,这在软件开发中非常常见,单体应用尤其如此。系统设计或写好的代码难以修改,因为应用程序的其它部分可能会以意料之外的方式使用它。随着时间推移、人员更迭,这必然会增加应用程序的技术债务。

而随着业务需求的快速发展变化,敏捷性、灵活性和可扩展性需求不断增长,迫切需要一种更加快速高效的软件交付方式。微服务就是一种可以满足这种需求的软件架构风格。单体应用被分解成多个更小的服务,每个服务有自己的归档文件,单独部署,然后共同组成一个应用程序。这里的“微”不是针对代码行数而言,而是说服务的范围限定到单个功能。微服务有如下特点:

  • 领域驱动设计:应用程序功能分解可以通过 Eric Evans 在《领域驱动设计》中明确定义的规则实现;每个团队负责与一个领域或业务功能相关的全部开发;团队拥有全系列的开发人员,具备用户界面、业务逻辑和持久化存储等方面的开发技能;
  • 单一职责原则:每个服务应该负责该功能的一个单独的部分,这是 SOLID 原则之一;
  • 明确发布接口:每个服务都会发布一个定义明确的接口,而且保持不变;服务消费者只关心接口,而对于被消费的服务没有任何运行依赖;
  • 独立部署、升级、扩展和替换:每个服务都可以单独部署及重新部署而不影响整个系统。这使得服务很容易升级,每个服务都可以沿着《Art of Scalability》一书定义的 X 轴和 Z 轴进行扩展;
  • 可以异构 / 采用多种语言:每个服务的实现细节都与其它服务无关,这使得服务之间能够解耦,团队可以针对每个服务选择最合适的开发语言、持久化存储、工具和方法;
  • 轻量级通信:服务通信使用轻量级的通信协议,例如,同步的 REST,异步的 AMQP、STOMP、MQTT 等。

相应地,微服务具有如下优点:

  • 易于开发、理解和维护;
  • 比单体应用启动快;
  • 局部修改很容易部署,有利于持续集成和持续交付;
  • 故障隔离,一个服务出现问题不会影响整个应用;
  • 不会受限于任何技术栈。

微服务看上去像一枚银弹,可以解决许多软件开发方面的问题。这看上去很美好,但并不易于实现。微服务会极大地增加运维工作量,InfoWorld 在一篇文章中明确指出:

使用微服务,一些技术债务势必从开发转到运维,因此,你最好有一个一流的开发运维团队。

因此,微服务对基础设施提出了一些额外的需求。通常,我们将它们总称为 NoOps ,本质上讲,就是一组服务,提供一个更好的应用程序部署流程并确保其运行,包括服务复制、服务发现、服务恢复和服务监控。

不过,即使具备了上述条件,也并不是说就要抛弃现有的应用程序,在大多数情况下,我们无法做到。因此,我们要构建一种方法,依据它使用微服务重构现有的应用程序。虽然重构过程并不简单,但长远来看,重构一个单体应用可以一次性偿还所有的技术债务。

Netflix 是使用微服务的一个典型代表,它发表了数篇文章( 1 2 3 4 5 6 )分享采用微服务的一些经验,感兴趣的读者可以进一步阅读。


感谢徐川对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们,并与我们的编辑和其他读者朋友交流。

2015-04-08 03:0820896
用户头像

发布了 1008 篇内容, 共 377.0 次阅读, 收获喜欢 342 次。

关注

评论

发布
暂无评论
发现更多内容

高效使用 PyMongo 进行 MongoDB 查询和插入操作

小万哥

Python 程序员 软件 后端 开发

使用AWS CodePipeline自动部署项目到EC2

王坤祥

亚马逊云 亚马逊云科技 EC2 CodePipeline CodeDeploy

从混乱到优雅:基于DDD的六边形架构的代码翻新指南

不在线第一只蜗牛

架构 DDD 框架设计

深入理解Docker:一种革新的容器技术

不在线第一只蜗牛

Docker 容器化 容器化部署

选人与育人,孰先孰后?

凌晞

团队管理

数据库操作入门:PyMongo 和 MongoDB 的基本用法

小万哥

Python 程序员 软件 后端 开发

利用生成式AI的产研流程:创新与效率的完美结合

之家技术

测试 用例 效能 生成式AI 释产能

市场行情回暖、利好月来袭,Web3 广告业领头羊 Verasity 或迎爆发

鳄鱼视界

浅谈研发数字化在汽车之家的落地实践

之家技术

产品 数字化 研发 效能 释产能

Redis分布式锁问题分析与处理方案

郑在暴富中

redis redisson 分布式锁

零代码秒集成打通小鹅通订单支付信息与CRM合同接口

RestCloud

零代码 APPlink

文心一言 VS 讯飞星火 VS chatgpt (135)-- 算法导论11.3 1题

福大大架构师每日一题

福大大架构师每日一题

X2RTC安装教程详解(图文版)

X2Rtc

开源 音视频 RTC 教程分享

轻量级数据中台,大中型企业数字化转型首选

RestCloud

数据中台

Kyligence 入选 Gartner® 2023 客户之声报告,高分获评“卓越表现者”

Kyligence

数据分析 指标平台

Kstry: 业务架构的首选之选

快乐非自愿限量之名

开发工具 业务框架

Milvus 上新!全新 Range Search 功能,可精准控制搜索结果

Zilliz

Milvus Zilliz 向量数据库

多行业用户齐聚,2023 IoTDB 用户大会详细议程更新!

Apache IoTDB

玩转 Cgroup 系列之三:挑战手动管理 Cgroup

小猿姐

cpu 资源管理 Cgroup

Databend 与海外某电信签约:共创海外电信数据仓库新纪元

Databend

推动OpenHarmony在AIDC行业落地,优博讯的技术积累与实践

Geek_2d6073

深入解析 Azure 机器学习平台:架构与组成部分

EquatorCoco

机器学习 azure 机器学习模型

低代码平台是什么?具备哪些特性?

树上有只程序猿

低代码

跨境自建站卖家如何提高谷歌广告质量得分?

九凌网络

做独立站需要用到的十大软件

九凌网络

如何item_get-获得淘宝商品详情api接口

技术冰糖葫芦

API 接口

inBuilder低代码平台新特性推荐-第七期

inBuilder低代码平台

低代码

市场行情回暖、利好月来袭,Web3 广告业领头羊 Verasity 或迎爆发

威廉META

一文带你了解TypeScript 函数

Aion

typescript Vue 前端

桌面便签软件哪个好?10款全球好评的便签软件助你提升效率!

彭宏豪95

效率 在线白板 备忘录 笔记应用 笔记软件

能够导出源代码的低代码平台有哪些?

互联网工科生

低代码 源代码

单体应用与微服务优缺点辨析_架构_谢丽_InfoQ精选文章