有不少小伙伴心愿松哥能整一个微服务的实战我的项目，微服务这块技术点其实松哥是讲过很多了，图文版的教程视频版的教程都有，不过的确不足一个我的项目，所以我在想等 TienChin 我的项目搞完之后，和小伙伴们也来一起搞一个微服务的我的项目。
明天我想从架构的角度来和小伙伴们聊一聊微服务。不聊具体的技术点，就单纯来看看一个微服务项目该怎么设计。
1. 单体版 TienChin
松哥目前在录的 TienChin 我的项目就是一个前后端拆散的单体我的项目，采纳了 Spring Boot + Vue3。那么单体版的 TienChin 具备什么样的特色呢？我从长处和毛病两个方面来和大家剖析。
先来看一张简略的架构图：
能够看到，尽管是单体我的项目，然而为了开发不便，我的项目也细分为许多不同的模块，我的项目中的适配器能够分为两大类：
- 入站适配器：就是内部零碎来调用咱们的零碎，REST API 和 Vue 网页都算是入站适配器，内部零碎通过这两个接口来调用咱们的零碎。
- 出站适配器：这个次要是咱们零碎外部调用内部零碎的形式，例如咱们的我的项目中须要用到 MySQL、Redis 等，那么就通过出站适配器来实现。
1.1 长处
- 开发简略：轻易一个 IDE，撸起袖子就能够开写了。
- 测试简略：我的项目启动之后，间接利用 POSTMAN 等工具就能够测试项目接口了。
- 部署简略：我的项目开发实现之后，打包成一个 jar 或者一个 war，间接部署就行了。
- 横向扩大简略：当我的项目并发能力有余的时候，能够不便的联合 Nginx 等负载平衡工具进行横向扩大。
能够看到，单体我的项目的劣势整体上来说还是非常明显的。
1.2 毛病
然而毛病也是非常明显的。
- 我的项目越来越简单
首先就是我的项目不可能始终这么简略，咱们这个我的项目中还是细分了很多不同的模块。随着工夫的推移，这些模块会变得越来愈简单。批改每一个 BUG 都要小心翼翼，牵一发而动全身。并且随着项目组中人员的到职 / 入职，新接手的人会让这个我的项目更加简单，每一次 BUG 的修复或者新性能的增加，都会让这个我的项目变得更加“不可捉摸”。
- 开发进度越来越不可控
因为零碎越来越简单，咱们不得不增派人手参加到这个我的项目的开发中，以期推动我的项目进度。这么多人的协调又是一个问题。并且，随着我的项目越来越大，每一次编译运行都得数分钟、十几分钟甚至更久，这也会重大拖慢咱们的我的项目进度。
- 发版周期过长
单体我的项目发版很多小伙伴可能都刻骨铭心，发版当天如临大敌，所有人都加班，等我的项目上线运行都没问题，各项数据都 OK，此时可能曾经凌晨三四点了，所有人拖着疲乏的身材上班。正是因为每一次发版都是一个小事，所以个别单体我的项目不太会频繁发版（我说的频繁是指如一天一版这种），发版周期广泛比拟长。
- 难以扩大
当零碎不同模块对资源的需要不同的时候，咱们想做针对性的硬件扩大也并不不便。
举个简略例子，有一个模块须要进行大量的运算，咱们心愿能为之提供更好的 CPU；有一个模块须要更大的内存，咱们须要扩大更大的内存。
然而因为所有的模块都打包在一起，咱们只能针对以后服务器做各种硬件降级，无奈针对某一个模块做专门的硬件降级。
- 过期的技术栈不易更新
我置信很多小伙伴见到的单体我的项目还有一个特点就是技术栈广泛比拟老旧。这也是因为单体我的项目工夫久了之后，积重难返，想要对根底框架做版本升级往往牵一发而动全身，更别提从传统的 SSM 切换到 Spring Boot 上这种超级繁琐的工作了。因而大部分的单体我的项目，在立项的那一刻选用了什么技术栈、选用了技术的哪个版本，基本上这个我的项目将来都是这个版本了。
从下面的介绍中小伙伴们能够看到，单体我的项目长处很显著，然而毛病也是非常明显的。而这些毛病，都能够通过微服务来解决。
2. 微服务版 TienChin
如果 TienChin 我的项目是微服务版呢？咱们来看一张简略的架构图。
简略画了张图，我来解释下：
- 首先咱们基本上是依照业务来划分服务的。每一个服务都有本人独立的数据库，本人操作本人的库。
- 假如在线索治理中，须要调用商机治理，那不能间接操作商机的数据库，必须去调用商机治理服务中提供的 REST API，通过这个 REST API 来操作库。
- 所有的服务有一个对立的入口 Gateway，如果前端是手机 App 或者小程序之类的，通过 Gateway 来拜访到零碎。
- 有一个后盾治理的 Web UI 我的项目，提供相应的网页操作。
大抵上就是这个样子。
那么这个微服务版的 TienChin 跟后面的单体版 TienChin 相比劣势体现在哪里呢？
- 容易保护
首先第一点就是，我的项目拆分为微服务之后，每个服务相对来说都比拟小，我的项目的保护相对来说也会比拟容易。一个比拟小的我的项目，在 IDE 中启动也会比拟快。能够有一个很小的团队来负责我的项目的保护。
- 服务能够自在扩大
以上图为例，如果某日搞促销流动，线索治理这个服务的并发量比拟大，咱们能够十分不便的为线索治理模块做横向扩大，如下图这样：
任何一个服务，如果有需要，都能够十分不便的进行扩大，并且能够依据服务的特点来抉择适合的硬件，例如这个服务耗内存，那就加大内存；另一个服务耗 CPU，那就抉择一个性能到位的 CPU 等等。
- 解耦后更强的容错性
通过服务降级、熔断等微服务组件的应用，咱们能够实现各个微服务具备更强的容错性。一个服务出故障，并不会影响其余的服务。例如合同治理里边产生了内存透露，这个并不会影响到商机治理服务。
- 更容易采纳新技术
之前咱们在谈到单体我的项目的弊病的时候，提到了单体我的项目的技术栈更新十分不易。当初咱们切换成微服务了，新技术栈的切换其实就变得非常容易了。每一个微服务都能够依据以后我的项目的状况，抉择是否采纳最新的技术栈，而且一个微服务在切换最新技术栈的过程中，如果可怜产生了问题了，也不会影响到其余的微服务，只会影响到以后的服务。因为各个微服务之间基本上都是通过 REST API 进行交互的，所以，退一万步，你甚至能够应用不同的开发语言来开发不同的微服务。
- 更敌对的 CI/CD
CI/CD 是 DevOps 的一部分，然而在后面的单体我的项目中，当我的项目比拟大的时候，想做到继续交付 / 继续部署曾经越来越难了，而微服务让一个超大规模的我的项目能够十分不便的实现 CI/CD。
当初，咱们的每一个服务都有本人独立的团队、独立的代码仓库、独立的自动化部署流水线，且互不相扰，如下图这样：
当初，每一个服务都能够独立的实现服务的上线和部署，联合 DevOps 能够做到十分轻松的发版，不须要再像以前单体利用发版的时候，如临大敌一样。
这样划分之后，工程师也能够将本人的精力放在业务开发商，提供更多有价值的性能，而不是像一个救火队员一样，每天忙着到处灭火。
好啦，通过这样一篇简略的文章和图片，心愿大家对微服务有一个根本的认知，当然，微服务也不是“银弹”，微服务架构也存在问题，这个咱们前面有空了松哥再持续和小伙伴们分享。