很多小伙伴都希望松哥能够完成一个微服务实战项目。其实松哥讲过很多次微服务技术。有图文和视频教程，但是真的很欠缺。一个项目，所以想等TienChin项目完成，小伙伴们也来做一个微服务项目。今天想从架构的角度和小伙伴们聊聊微服务。不谈具体的技术点，我们先来看看如何设计一个微服务项目。1.单体版TienChin松哥目前正在录制的TienChin项目是一个前后端分离的单体项目，使用SpringBoot+Vue3。那么TienChin单机版有什么特点呢？下面我就从优缺点两个方面来和大家分析一下。先来看一张简单的架构图：可以看到虽然是一个单一的项目，但是为了方便开发，项目也被细分为很多不同的模块。项目中的适配器可以分为两类：入站适配器：是外部系统调用我们的系统，RESTAPI和Vue网页都是入站适配器，外部系统通过这两个接口调用我们的系统。Outboundadapter：这个主要是我们系统内部调用外部系统的方式。比如我们的项目需要用到MySQL、Redis等，那么就是通过outboundadapter来实现的。1.1优点开发简单：卷起袖子用任何IDE开始编写。简单测试：项目启动后，可以直接使用POSTMAN等工具对项目界面进行测试。简单部署：项目开发完成后，打包成jar或者war直接部署即可。简单水平扩展：当项目并发能力不足时，可以方便的结合Nginx等负载均衡工具进行水平扩展。可见，从整体上看，个别项目的优势还是非常明显的。1.2缺点然而，缺点也很明显。项目越来越复杂。首先，项目不能一直这么简单。我们的项目还是细分了很多不同的模块。随着时间的推移，这些模块将变得越来越复杂。修改每一个BUG都要细心，一根毛都会牵一发而动全身。并且随着项目组人员的离职/入职，新人的加入会让项目变得更加复杂。每一次bug修复或新功能的添加都会让项目变得更加“不可预测”。开发进度越来越不可控。随着系统越来越复杂，我们不得不派出额外的人力参与这个项目的开发，以推进项目的进度。这么多人的协调又是一个问题。而且随着项目越来越大，每次编译运行都要几分钟、十几分钟甚至更长时间，这会严重拖慢我们的项目进度。发布周期太长。单个项目的发布周期可能很多小伙伴都难以忘怀。上映那天犹如大敌，大家加班加点。等项目上线就没有问题了。所有数据都OK。此时可能是凌晨三点。已经四点了，大家拖着疲惫的身躯下班了。正是因为每次发布都是一件大事，所以一般的单体项目是不会频繁发布的（频繁我是说每天发布一次），发布周期一般都比较长。扩展困难当系统的不同模块对资源的要求不同时，我们不方便做有针对性的硬件扩展。举个简单的例子，有一个模块需要大量的计算，我们希望为它提供更好的CPU；有一个模块需要更多的内存，我们需要将它扩展到更大的内存。但是由于所有模块都打包在一起，我们只能针对当前服务器做各种硬件升级，而不能针对某个模块做具体的硬件升级。过时的技术栈不易更新。单体项目相信还有一个特点很多小伙伴都看过，那就是技术栈普遍比较老。这也是因为一个项目做久了，就很难回头了。如果要升级基础框架的版本，往往牵一发而动全身，更别提从传统SSM切换到SpringBoot的超级繁琐工作了。所以，对于大多数个别项目来说，在立项的那一刻选择了哪个技术栈，选择了哪个版本的技术，以后基本上这个项目就是这个版本。从上面的介绍可以看出，单一项目的优势很明显，但是劣势也很明显。而这些缺点都可以通过微服务来解决。2.TienChin的微服务版本如果TienChin项目是微服务版本怎么办？让我们看一个简单的架构图。画了一个简单的图之后，我来解释一下：首先，我们基本上是按照业务来划分服务的。每个服务都有自己独立的数据库，运行自己的库。假设在leadmanagement中，需要调用商机管理，不能直接操作商机库，必须调用商机管理服务中提供的RESTAPI，使用这个RESTAPI来操作库。所有服务都有一个统一的入口Gateway。如果前端是手机APP或小程序，则通过网关访问系统。有一个后台管理WebUI项目，提供相应的网页操作。大致就是这个样子。那么这个微服务版本的TienChin相比之前的单版本TienChin有哪些优势呢？易维护第一点，项目拆分成微服务后，每个服务都比较小，项目的维护也比较容易。一个相对较小的项目将在IDE中启动得更快。可以有一个非常小的团队负责项目的维护。业务可自由扩展，扩展非常方便，可根据业务特点选择合适的硬件。比如这个服务很耗内存，那就增加内存；如果另一个服务消耗CPU，则选择性能好的CPU等。解耦后容错性更强通过使用服务降级和断路器等微服务组件，我们可以为每个微服务实现更强的容错性。一项服务失败不会影响其他服务。例如，合约管理发生内存泄漏，不会影响商机管理服务。更容易采用新技术之前我们在讲单体项目的劣势之前，提到了单体项目的技术栈更新非常困难。现在切换到微服务之后，新的技术栈的切换其实变得非常容易。每个微服务都可以根据当前项目情况选择是否使用最新的技术栈，如果一个微服务在切换最新技术栈的过程中遇到问题，不会影响到其他微服务。只有当前服务会受到影响。由于每个微服务基本上都是通过RESTAPI进行交互，你甚至可以使用不同的开发语言来开发不同的微服务。比较友好的CI/CDCI/CD是DevOps的一部分，但是在以前的单体项目中，当项目比较大的时候，实现持续交付/持续部署的难度越来越大，而微服务使得大规模项目可以轻松实现CI/CD。现在，我们每个服务都有自己独立的团队，独立的代码仓库，独立的自动化部署流水线，互不干扰，如下图所示：现在，每个服务都可以独立实现服务的上线和部署，结合DevOps，可以非常轻松地发布，再也不用像以往发布单个应用时有敌对情绪了。经过这样的划分，工程师也可以专注于业务开发人员，提供更多有价值的功能，而不是像消防员一样每天忙于救火。好了，通过这么简单的文章和图片，希望大家对微服务有一个基本的了解。当然，微服务并不是“银弹”，微服务架构也存在问题。兄弟继续分享给朋友们。
