8年Java老司机讲解——微服务架构VS单体架构

微服务架构在软件行业已成为一中发展趋势,微服务架构与传统的单体软件架构代表着IT产业处理软件开发方式的一个根本性转变。那么微服务架构与传统的单体架构相比,有何区别呢?我们从以下几点来看:

一、单体架构

单体架构,是指将开发好的项目打成war包,然后发布到tomcat等容器中的应用。

假设你正准备开发一款与Uber和滴滴竞争的出租车调度软件,经过初步会议和需求分析,你可能会手动或者使用基于Spring Boot、Play或者Maven的生成器开始这个新项目,它的六边形架构是模块化的 ,架构图如下:

 

应用核心是业务逻辑,由定义服务、领域对象和事件的模块完成。围绕着核心的是与外界打交道的适配器。适配器包括数据库访问组件、生产和处理消息的消息组件,以及提供API或者UI访问支持的web模块等。

尽管也是模块化逻辑,但是最终它还是会打包并部署为单体式应用。具体的格式依赖于应用语言和框架。例如,许多Java应用会被打包为WAR格式,部署在Tomcat或者Jetty上,而另外一些Java应用会被打包成自包含的JAR格式,类似的,Rails和Node.js会被打包成层级目录。

这种应用开发风格很常见,因为IDE和其它工具都擅长开发一个简单应用,这类应用也很易于调试,只需要简单运行此应用,用Selenium链接UI就可以完成端到端测试。

单体式应用也易于部署,只需要把打包应用拷贝到服务器端,通过在负载均衡器后端运行多个拷贝就可以轻松实现应用扩展。在早期这类应用运行的很好。

单体架构存在的问题:

复杂性高

以某个百万行级别的单体应用xxx为例,整个项目包含的模块非 常多,模块的边界模糊、依赖关系不清晰、代码质量参差不齐、 混乱地堆砌在一起,整个项目非常复杂。每次修改代码都心惊胆 战,甚至添加一个简单的功能,或者修改一个Bug都会带来隐含 的缺陷。

 

技术债务

随着时间推移、需求变更和人员更迭,会逐渐形成应用程序的技术债务, 并 且越积越多。“不坏不修”,这在软件开发中非常常见,在单体应用中这种 思想更甚。已使用的系统设计或代码难以被修改,因为应用程序中的 其他 模块可能会以意料之外的方式使用它。

 

部署频率低

随着代码的增多,构建和部署的时间也会增加。而在单体应用中,每次功能 的变更或缺陷的修复都会导致需要重新部署整个应用。全量部署的方式耗时 长、影响范围大、风险高,这使得单体应用项目上线部署的频率较低。而部 署频率 低又导致两次发布之间会有大量的功能变更和缺陷修复,出错概率 比较高。

 

可靠性差

某个应用Bug,例如死循环、00M等,可能会导致整个应用的崩溃。

 

扩展能力受限

单体应用只能作为一个整体进行扩展,无法根据业务模块的需要进行伸缩。 例如,应用中有的模块是计算密集型的,它需要强劲的 CPU ;有的模块则是 IO 密集型的,需要更大的内存。由于这些模块部署在一起,不得不在硬件 的选择上做出妥协。

 

阻碍技术创新

单体应用往往使用统一的技术平台或方案解决所有的问题,团队中的每个成 员都必须使用相同的开发语言和框架,要想引人新框架或新技术平台会非常 困难。例如,一个使用 Struts 2构建的、有100万行代码的单体应用,如 果想要换用 Spring MVC ,毫无疑问切换的成本是非常高的。

 

二、什么是微服务?

微服务的概念源于2014年3月Martin Fowler所写的一篇文章“Microservices”。

 

微服务架构是一种架构模式,它提倡将单一应用程序划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。每个服务运行在其独立的进程中,服务与服务间采用轻量级的通信机制互相沟通(通常是基于HTTP的RESTful API)。

每个服务都围绕着具体业务进行构建,并且能够被独立地部署到生产环境、类生产环境等。另外,应尽量避免统一的、集中式的服务管理机制,对具体的一个服务而言,应根据业务上下文,选择合适的语言、工具对其进行构建。

微服务是一种架构风格,一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署,各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下,每个任务代表着一个小的业务能力。

 

1、微服务架构优势

l 复杂度可控

在将应用分解的同时,规避了原本复杂度无止境的积累。每一个 微服务专注于单一功能,并通过定义良好的接口清晰表述服务边 界。由于体积小、复杂度低,每个微服务可由一个小规模开发团 队完全掌控,易于保持高可维护性和开发效率。

 

l 独立部署

由于微服务具备独立的运行进程,所以每个微服务也可以独立部 署。当某个微服务发生变更时无需编译、部署整个应用。由微服 务组成的应用相当于具备一系列可并行的发布流程,使得发布更 加高效,同时降低对生产环境所造成的风险,最终缩短应用交付 周期。

 

l 技术选型灵活

微服务架构下,技术选型是去中心化的。每个团队可以根据自身 服务的需求和行业发展的现状,自由选择最适合的技术栈。由于 每个微服务相对简单,故需要对技术栈进行升级时所面临的风险 就较低,甚至完全重构一个微服务也是可行的。

 

l 容错

当某一组建发生故障时,在单一进程的传统架构下,故障很有可 能在进程内扩散,形成应用全局性的不可用。在微服务架构下, 故障会被隔离在单个服务中。若设计良好,其他服务可通过重试、 平稳退化等机制实现应用层面的容错。

 

l 扩展

单块架构应用也可以实现横向扩展,就是将整个应用完整的复制 到不同的节点。当应用的不同组件在扩展需求上存在差异时,微 服务架构便体现出其灵活性,因为每个服务可以根据实际需求独 立进行扩展。

 

2、微服务架构示例

 

三、微服务架构VS单体架构

1.分工不同

以前我们通常是一个有规模的团队围绕一个单体应用工作,可能是一人一个模块;微服务架构可以为软件开发提供不同的方法,把传统模式下的单体应用拆分成独立的服务,从而可以单独开发、单独部署、单独维护,在微服务架构下可能是一人一个系统。

 

2. 存储方式不同

单体架构所有的模块都共用一个数据库,存储方式比较单一,微服务每个模块都可以使用不同的存储方式(比如有的用redis,有的用mysql等),数据库也是单个模块对应自己的数据库。

 

3.部署方式不同

在单体应用中,每次功能 的变更或缺陷的修复都会导致需要重新部署整个应用。微服务架构服务可独立部署,并且可以独立于其他服务进行扩展,如果部署得当,基于微服务的架构可以帮助业务避免欠下技术债务,以及大幅提高效率的重大价值。

 

4.容灾不同

当某一组建发生故障时,在单一进程的传统架构下,故障很有可 能在进程内扩散,形成应用全局性的不可用。在微服务架构下, 故障会被隔离在单个服务中。好的微服务可以隔离故障避免服务整体down掉,坏的微服务设计仍然可以因为一个子服务出现问题导致连锁反应。

 

5. 开发模式不同

单体架构所有的模块开发所使用的技术一样,开发模式比较受限,微服务每个模块都可以使用不同的开发技术,开发模式更灵活。

 

为了提升效率,强化技术创新,微服务已受到越来越多的开发者的青睐。

发布了78 篇原创文章 · 获赞 240 · 访问量 5万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 技术黑板 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览