单体的 TienChin 和微服务的 TienChin 有何异同?

简介: 单体的 TienChin 和微服务的 TienChin 有何异同?

有不少小伙伴希望松哥能整一个微服务的实战项目,微服务这块技术点其实松哥是讲过很多了,图文版的教程视频版的教程都有,不过确实缺乏一个项目,所以我在想等 TienChin 项目搞完之后,和小伙伴们也来一起搞一个微服务的项目。

今天我想从架构的角度来和小伙伴们聊一聊微服务。不聊具体的技术点,就单纯来看看一个微服务项目该怎么设计。

1. 单体版 TienChin

松哥目前在录的 TienChin 项目就是一个前后端分离的单体项目,采用了 Spring Boot + Vue3。那么单体版的 TienChin 具有什么样的特征呢?我从优点和缺点两个方面来和大家分析。

先来看一张简单的架构图:

5bf695ba3d0b67b0dc3fca906a98da1d.png

可以看到,虽然是单体项目,但是为了开发方便,项目也细分为许多不同的模块,项目中的适配器可以分为两大类:

入站适配器:就是外部系统来调用我们的系统,REST API 和 Vue 网页都算是入站适配器,外部系统通过这两个接口来调用我们的系统。

出站适配器:这个主要是我们系统内部调用外部系统的方式,例如我们的项目中需要用到 MySQL、Redis等,那么就通过出站适配器来实现。

1.1 优点

开发简单:随便一个 IDE,撸起袖子就可以开写了。

测试简单:项目启动之后,直接利用 POSTMAN 等工具就可以测试项目接口了。

部署简单:项目开发完成之后,打包成一个 jar 或者一个 war,直接部署就行了。

横向扩展简单:当项目并发能力不足的时候,可以方便的结合 Nginx 等负载均衡工具进行横向扩展。

可以看到,单体项目的优势整体上来说还是非常明显的。

1.2 缺点

然而缺点也是非常明显的。

项目越来越复杂

首先就是项目不可能一直这么简单,我们这个项目中还是细分了很多不同的模块。随着时间的推移,这些模块会变得越来愈复杂。修改每一个 BUG 都要小心翼翼,牵一发而动全身。并且随着项目组中人员的离职/入职,新接手的人会让这个项目更加复杂,每一次 BUG 的修复或者新功能的添加,都会让这个项目变得更加“不可捉摸”。

  1. 开发进度越来越不可控

由于系统越来越复杂,我们不得不增派人手参与到这个项目的开发中,以期推进项目进度。这么多人的协调又是一个问题。并且,随着项目越来越大,每一次编译运行都得数分钟、十几分钟甚至更久,这也会严重拖慢我们的项目进度。

发版周期过长

单体项目发版很多小伙伴可能都刻骨铭心,发版当天如临大敌,所有人都加班,等项目上线运行都没问题,各项数据都 OK,此时可能已经凌晨三四点了,所有人拖着疲惫的身体下班。正是由于每一次发版都是一个大事,所以一般单体项目不太会频繁发版(我说的频繁是指如一天一版这种),发版周期普遍比较长。

难以扩展

当系统不同模块对资源的需求不同的时候,我们想做针对性的硬件扩展也并不方便。

举个简单例子,有一个模块需要进行大量的运算,我们希望能为之提供更好的 CPU;有一个模块需要更大的内存,我们需要扩展更大的内存。

然而由于所有的模块都打包在一起,我们只能针对当前服务器做各种硬件升级,无法针对某一个模块做专门的硬件升级。

过期的技术栈不易更新

我相信很多小伙伴见到的单体项目还有一个特点就是技术栈普遍比较老旧。这也是因为单体项目时间久了之后,积重难返,想要对基础框架做版本升级往往牵一发而动全身,更别提从传统的 SSM 切换到 Spring Boot 上这种超级繁琐的工作了。因此大部分的单体项目,在立项的那一刻选用了什么技术栈、选用了技术的哪个版本,基本上这个项目未来都是这个版本了。

从上面的介绍中小伙伴们可以看到,单体项目优点很明显,然而缺点也是非常明显的。而这些缺点,都可以通过微服务来解决。

2. 微服务版 TienChin

如果 TienChin 项目是微服务版呢?我们来看一张简单的架构图。

746921e3d38f84c9ae70fe8f0dd92c7d.png

简单画了张图,我来解释下:

首先我们基本上是按照业务来划分服务的。每一个服务都有自己独立的数据库,自己操作自己的库。

假设在线索管理中,需要调用商机管理,那不能直接操作商机的数据库,必须去调用商机管理服务中提供的 REST API,通过这个 REST API 来操作库。

所有的服务有一个统一的入口 Gateway,如果前端是手机 App 或者小程序之类的,通过 Gateway 来访问到系统。

有一个后台管理的 Web UI 项目,提供相应的网页操作。

大致上就是这个样子。

那么这个微服务版的 TienChin 跟前面的单体版 TienChin 相比优势体现在哪里呢?

容易维护

首先第一点就是,项目拆分为微服务之后,每个服务相对来说都比较小,项目的维护相对来说也会比较容易。一个比较小的项目,在 IDE 中启动也会比较快。可以有一个很小的团队来负责项目的维护。

服务可以自由扩展

以上图为例,如果某日搞促销活动,线索管理这个服务的并发量比较大,我们可以非常方便的为线索管理模块做横向扩展,如下图这样:

e8bd6c21a95f76581a715fef1981e9e8.png

任何一个服务,如果有需求,都可以非常方便的进行扩展,并且可以根据服务的特点来选择合适的硬件,例如这个服务耗内存,那就加大内存;另一个服务耗 CPU,那就选择一个性能到位的 CPU 等等。

解耦后更强的容错性

通过服务降级、熔断等微服务组件的使用,我们可以实现各个微服务具备更强的容错性。一个服务出故障,并不会影响其他的服务。例如合同管理里边发生了内存泄漏,这个并不会影响到商机管理服务。

更容易采用新技术

之前我们在谈到单体项目的弊端的时候,提到了单体项目的技术栈更新非常不易。现在我们切换成微服务了,新技术栈的切换其实就变得非常容易了。每一个微服务都可以根据当前项目的情况,选择是否采用最新的技术栈,而且一个微服务在切换最新技术栈的过程中,如果不幸发生了问题了,也不会影响到其他的微服务,只会影响到当前的服务。由于各个微服务之间基本上都是通过 REST API 进行交互的,所以,退一万步,你甚至可以使用不同的开发语言来开发不同的微服务。

更友好的 CI/CD

CI/CD 是 DevOps 的一部分,但是在前面的单体项目中,当项目比较大的时候,想做到持续交付/持续部署已经越来越难了,而微服务让一个超大规模的项目可以非常方便的实现 CI/CD。

现在,我们的每一个服务都有自己独立的团队、独立的代码仓库、独立的自动化部署流水线,且互不相扰,如下图这样:

d4ff78e84fe07fd5c3ff07b4c6a555a9.png

现在,每一个服务都可以独立的实现服务的上线和部署,结合 DevOps 可以做到非常轻松的发版,不需要再像以前单体应用发版的时候,如临大敌一样。

这样划分之后,工程师也可以将自己的精力放在业务开发商,提供更多有价值的功能,而不是像一个救火队员一样,每天忙着四处灭火。

好啦,通过这样一篇简单的文章和图片,希望大家对微服务有一个基本的认知,当然,微服务也不是“银弹”,微服务架构也存在问题,这个咱们后面有空了松哥再继续和小伙伴们分享。


相关文章
|
17天前
|
Java 开发者 微服务
从单体到微服务:如何借助 Spring Cloud 实现架构转型
**Spring Cloud** 是一套基于 Spring 框架的**微服务架构解决方案**,它提供了一系列的工具和组件,帮助开发者快速构建分布式系统,尤其是微服务架构。
130 68
从单体到微服务:如何借助 Spring Cloud 实现架构转型
|
2月前
|
Cloud Native Java API
聊聊从单体到微服务架构服务演化过程
本文介绍了从单体应用到微服务再到云原生架构的演进过程。单体应用虽易于搭建和部署,但难以局部更新;面向服务架构(SOA)通过模块化和服务总线提升了组件复用性和分布式部署能力;微服务则进一步实现了服务的独立开发与部署,提高了灵活性;云原生架构则利用容器化、微服务和自动化工具,实现了应用在动态环境中的弹性扩展与高效管理。这一演进体现了软件架构向着更灵活、更高效的方向发展。
|
1月前
|
Dubbo Java 应用服务中间件
服务架构的演进:从单体到微服务的探索之旅
随着企业业务的不断拓展和复杂度的提升,对软件系统架构的要求也日益严苛。传统的架构模式在应对现代业务场景时逐渐暴露出诸多局限性,于是服务架构开启了持续演变之路。从单体架构的简易便捷,到分布式架构的模块化解耦,再到微服务架构的精细化管理,企业对技术的选择变得至关重要,尤其是 Spring Cloud 和 Dubbo 等微服务技术的对比和应用,直接影响着项目的成败。 本篇文章会从服务架构的演进开始分析,探索从单体项目到微服务项目的演变过程。然后也会对目前常见的微服务技术进行对比,找到目前市面上所常用的技术给大家进行讲解。
52 1
服务架构的演进:从单体到微服务的探索之旅
|
23天前
|
消息中间件 运维 Kubernetes
后端架构演进:从单体到微服务####
本文将探讨后端架构的演变过程,重点分析从传统的单体架构向现代微服务架构的转变。通过实际案例和理论解析,揭示这一转变背后的技术驱动力、挑战及最佳实践。文章还将讨论在采用微服务架构时需考虑的关键因素,包括服务划分、通信机制、数据管理以及部署策略,旨在为读者提供一个全面的架构转型视角。 ####
34 1
|
1月前
|
消息中间件 监控 安全
后端架构演进:从单体到微服务####
在数字化转型的浪潮中,企业应用的后端架构经历了从传统单体架构到现代微服务架构的深刻变革。本文探讨了这一演进过程的背景、驱动力、关键技术及面临的挑战,揭示了如何通过微服务化实现系统的高可用性、扩展性和敏捷开发,同时指出了转型过程中需克服的服务拆分、数据管理、通信机制等难题,为读者提供了一个全面理解后端架构演变路径的视角。 ####
52 8
|
4月前
|
监控 负载均衡 API
从单体到微服务:架构转型之道
【8月更文挑战第17天】从单体架构到微服务架构的转型是一项复杂而系统的工程,需要综合考虑技术、团队、文化等多个方面的因素。通过合理的规划和实施策略,可以克服转型过程中的挑战,实现系统架构的升级和优化。微服务架构以其高度的模块化、可扩展性和灵活性,为业务的持续发展和创新提供了坚实的技术保障。
|
5月前
|
存储 消息中间件 运维
微服务和单体应用的优点和缺点
单体应用(monolith application)就是将应用程序的所有功能都打包成一个独立的单元,可以是 JAR、WAR、EAR 或其它归档格式。
141 3
|
6月前
|
Java API 数据库
Java后端架构设计:从单体到微服务的演进
Java后端架构设计:从单体到微服务的演进
|
5月前
|
运维 API 开发者
后端技术演进:从单体应用到微服务架构的转变
在数字时代的洪流中,后端技术的演进标志着软件开发的重大转变。本文将探讨如何从传统的单体应用过渡至微服务架构,这一过程涉及的不仅是代码层面的重构,更是对开发、部署和运维模式的根本变革。我们将深入分析微服务架构带来的优势与挑战,并讨论如何在保持系统稳定性的同时实现平滑过渡。通过具体案例,本文旨在为读者提供一套清晰的指南,帮助他们在面对日益复杂的业务需求时,能够有效地采用微服务架构。
|
5月前
|
Java API 数据库
Java后端架构设计:从单体到微服务的演进
Java后端架构设计:从单体到微服务的演进
下一篇
DataWorks