写点什么

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

  • 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:0820820
用户头像

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

关注

评论

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

在CSDN的六载时光,由你来决定今年的博客之星

谙忆

九个最容易出错的 Hive sql 详解及使用注意事项

五分钟学大数据

sql 大数据 hive

专科出身,2年进入苏宁,5年跳槽阿里,论我是怎么快速晋升的?

Java 学习 程序员 面试

区块链与物联网融合发展的机遇与挑战

CECBC

人工智能

电动汽车的小历史及汽车方面的一个基础概念 (28天写作 Day5/28)

mtfelix

28天写作 电动汽车

潘建伟团队再登Nature:建成全球首个集成量子通信网,全长4600公里

京东科技开发者

云计算

来玩一玩Linux常见命令!

程序员的时光

Linux 程序员 28天写作

Java 程序经验小结:避免使用float和double表示精确数据

后台技术汇

28天写作

案例研究之聊聊 QLExpress 源码 (四)

小诚信驿站

刘晓成 小诚信驿站 28天写作 QLExpress源码 聊聊源码

一文搞懂参数传递原理

Java 编程 程序员

技术er,你还特立独行坚持技术的优雅性么?

三石

28天写作 技术与业务

赛博时代,拿什么盛放对逝者的思念?

脑极体

【计算机内功修炼】四:进程切换与线程切换的区别

码农的荒岛求生

线程 进程 进程线程区别

精选算法面试-优先队列

李孟聊AI

算法 队列 28天写作

9条消除if...else的锦囊妙计,助你写出更优雅的代码

苏三说技术

Spring Boot 中的项目属性配置

武哥聊编程

Java springboot SpringBoot 2 28天写作

创业失败启示录|校园微生活(故事篇 2)

阿萌

创业 28天写作 创业失败启示录 青城 人生故事

静态代理,jdk动态代理以及Cglib区别

Java架构师迁哥

SD-WAN:网络走向业务

JiangX

创业 投资 网络 28天写作 SD-WAN

《价值》- 投资分析(4)

石云升

零售 28天写作 价值 投资分析

Python 条件判断

赵开忠

Python 28天写作

面试被问AQS、ReentrantLock答不出来?这些知识点让我和面试官聊了半小时!

Java鱼仔

Java 面试 并发 JUC

[3/28]保障研发反应开发需求

L3C老司机

量化交易机器人系统开发|市值管理系统开发搭建

W13902449729

量化交易机器人系统开发 市值管理系统开发搭建

Lock锁 精讲

伯阳

Java 多线程 lock lock锁

人生苦短,开发用云 | 如何优雅完成程序员的侠客梦?

阿里巴巴云原生

人工智能 阿里云 Serverless 程序员 云原生

一致性Hash算法Java版实现

Silently9527

Java 后端 一致性Hash算法

Experience Never Gets Old

三只猫

28天写作

市值管理机器人系统开发|量化策略交易系统开发搭建

W13902449729

市值管理机器人系统开发 量化策略交易系统开发搭建

什么是TACACS?

甲方日常 84

句子

工作 随笔杂谈 日常

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