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

有不少小伙伴希望松哥能整一个微服务的实战项目，微服务这块技术点其实松哥是讲过很多了，图文版的教程视频版的教程都有，不过确实缺乏一个项目，所以我在想等 TienChin 项目搞完之后，和小伙伴们也来一起搞一个微服务的项目。,今天我想从架构的角度来和小伙伴们聊一聊微服务。不聊具体的技术点，就单纯来看看一个微服务项目该怎么设计。,松哥目前在录的 TienChin 项目就是一个前后端分离的单体项目，采用了 Spring Boot + Vue3。那么单体版的 TienChin 具有什么样的特征呢？我从优点和缺点两个方面来和大家分析。,先来看一张简单的架构图：,,可以看到，虽然是单体项目，但是为了开发方便，项目也细分为许多不同的模块，项目中的适配器可以分为两大类：,入站适配器：就是外部系统来调用我们的系统，REST API 和 Vue 网页都算是入站适配器，外部系统通过这两个接口来调用我们的系统。,出站适配器：这个主要是我们系统内部调用外部系统的方式，例如我们的项目中需要用到 MySQL、Redis等，那么就通过出站适配器来实现。,可以看到，单体项目的优势整体上来说还是非常明显的。,然而缺点也是非常明显的。,首先就是项目不可能一直这么简单，我们这个项目中还是细分了很多不同的模块。随着时间的推移，这些模块会变得越来愈复杂。修改每一个 BUG 都要小心翼翼，牵一发而动全身。并且随着项目组中人员的离职/入职，新接手的人会让这个项目更加复杂，每一次 BUG 的修复或者新功能的添加，都会让这个项目变得更加“不可捉摸”。,由于系统越来越复杂，我们不得不增派人手参与到这个项目的开发中，以期推进项目进度。这么多人的协调又是一个问题。并且，随着项目越来越大，每一次编译运行都得数分钟、十几分钟甚至更久，这也会严重拖慢我们的项目进度。,单体项目发版很多小伙伴可能都刻骨铭心，发版当天如临大敌，所有人都加班，等项目上线运行都没问题，各项数据都 OK，此时可能已经凌晨三四点了，所有人拖着疲惫的身体下班。正是由于每一次发版都是一个大事，所以一般单体项目不太会频繁发版（我说的频繁是指如一天一版这种），发版周期普遍比较长。,当系统不同模块对资源的需求不同的时候，我们想做针对性的硬件扩展也并不方便。,举个简单例子，有一个模块需要进行大量的运算，我们希望能为之提供更好的 CPU；有一个模块需要更大的内存，我们需要扩展更大的内存。,然而由于所有的模块都打包在一起，我们只能针对当前服务器做各种硬件升级，无法针对某一个模块做专门的硬件升级。,我相信很多小伙伴见到的单体项目还有一个特点就是技术栈普遍比较老旧。这也是因为单体项目时间久了之后，积重难返，想要对基础框架做版本升级往往牵一发而动全身，更别提从传统的 SSM 切换到 Spring Boot 上这种超级繁琐的工作了。因此大部分的单体项目，在立项的那一刻选用了什么技术栈、选用了技术的哪个版本，基本上这个项目未来都是这个版本了。,从上面的介绍中小伙伴们可以看到，单体项目优点很明显，然而缺点也是非常明显的。而这些缺点，都可以通过微服务来解决。,如果 TienChin 项目是微服务版呢？我们来看一张简单的架构图。,,简单画了张图，我来解释下：,大致上就是这个样子。,那么这个微服务版的 TienChin 跟前面的单体版 TienChin 相比优势体现在哪里呢？,首先第一点就是，项目拆分为微服务之后，每个服务相对来说都比较小，项目的维护相对来说也会比较容易。一个比较小的项目，在 IDE 中启动也会比较快。可以有一个很小的团队来负责项目的维护。,以上图为例，如果某日搞促销活动，线索管理这个服务的并发量比较大，我们可以非常方便的为线索管理模块做横向扩展，如下图这样：,,任何一个服务，如果有需求，都可以非常方便的进行扩展，并且可以根据服务的特点来选择合适的硬件，例如这个服务耗内存，那就加大内存；另一个服务耗 CPU，那就选择一个性能到位的 CPU 等等。,通过服务降级、熔断等微服务组件的使用，我们可以实现各个微服务具备更强的容错性。一个服务出故障，并不会影响其他的服务。例如合同管理里边发生了内存泄漏，这个并不会影响到商机管理服务。,之前我们在谈到单体项目的弊端的时候，提到了单体项目的技术栈更新非常不易。现在我们切换成微服务了，新技术栈的切换其实就变得非常容易了。每一个微服务都可以根据当前项目的情况，选择是否采用最新的技术栈，而且一个微服务在切换最新技术栈的过程中，如果不幸发生了问题了，也不会影响到其他的微服务，只会影响到当前的服务。由于各个微服务之间基本上都是通过 REST API 进行交互的，所以，退一万步，你甚至可以使用不同的开发语言来开发不同的微服务。,CI/CD 是 DevOps 的一部分，但是在前面的单体项目中，当项目比较大的时候，想做到持续交付/持续部署已经越来越难了，而微服务让一个超大规模的项目可以非常方便的实现 CI/CD。,现在，我们的每一个服务都有自己独立的团队、独立的代码仓库、独立的自动化部署流水线，且互不相扰，如下图这样：,,现在，每一个服务都可以独立的实现服务的上线和部署，结合 DevOps 可以做到非常轻松的发版，不需要再像以前单体应用发版的时候，如临大敌一样。,这样划分之后，工程师也可以将自己的精力放在业务开发商，提供更多有价值的功能，而不是像一个救火队员一样，每天忙着四处灭火。,好啦，通过这样一篇简单的文章和图片，希望大家对微服务有一个基本的认知，当然，微服务也不是“银弹”，微服务架构也存在问题，这个咱们后面有空了松哥再继续和小伙伴们分享。