个人简介：

📦个人主页：赵四司机
🏆学习方向：JAVA后端开发
📣种一棵树最好的时间是十年前，其次是现在！
🧡喜欢的话麻烦点点关注喔，你们的支持是我的最大动力。

前言：

1.前面已经介绍完了基于Springboot的单体项目介绍，至于项目中的其他功能实现我这里就不打算介绍了，因为涉及的知识点不难，而且都是简单的CRUD操作，假如有兴趣的话可以私信我我再看看要不要写几篇文章做个介绍。

2.完成上一阶段的学习，我就投入到了微服务的学习当中，所用教程为B站上面黑马的微服务教程。由于我的记性不是很好，所以对于新事物的学习我比较喜欢做笔记以加强理解，在这里我会将笔记的重点内容做个总结发布到“微服务学习”笔记栏目中。我是赵四，一名有追求的程序员，希望大家能多多支持，能给我点个关注就更好了。

目录

一：🧸微服务总体介绍

1：什么是微服务

2：为什么需要微服务

二：🧸微服务技术栈

三：🧸项目部署（持续集成）

---

一：🧸微服务总体介绍

1：什么是微服务

        相信很多没了解过微服务的人都会下意思地意识到微服务就是SpringCloud，其实这是不对的，SpringCloud只是微服务的一小部分，微服务涵盖的内容还有很多。简单来说，微服务架构是一种将单个应用程序开发为“一套小型服务”的方法，每个服务“运行在自己的进程中”，并通过轻量级机制(通常是HTTP资源API)进行通信。这些服务“围绕业务功能构建”，并通过全自动部署机制“独立部署”。“这些服务只有最低限度的集中管理”，可能是用不同的编程语言编写的，并使用不同的数据存储技术。

        微服务是一种架构，这种架构是将单个的整体应用程序分割成更小的项目关联的独立的服务。一个服务通常实现一组独立的特性或功能，包含自己的业务逻辑和适配器。各个微服务之间的关联通过暴露api来实现。这些独立的微服务不需要部署在同一个虚拟机，同一个系统和同一个应用服务器中。就拿我前面做的外卖项目来说，单体架构就是将所有代码放在一个项目中，然后部署时候将这个项目部署在一个机器上就好了；而微服务架构就要将项目中不同模块进行拆分，比如拆分成登录模块，下单模块，订单管理模块等等，而每一个模块都是一个独立出来的服务，实现了解耦的作用。

2：为什么需要微服务

        一个事物的出现必然有它出现的理由，那么为什么微服务会出现呢？肯定是为了解决某一些问题才会引入这样的技术。前面说到单体项目是将所有代码放在一个项目并部署在一个机器上，虽然这样做会方便开发，且测试和部署都比较方便，但是这样做的缺点很明显，就是假如后期加入的功能越来越多，项目就会变得很庞大，耦合度很高，代码维护起来会很困难。而且要想整体使用新的技术或者新的框架语言，那是不可能的。

        为了解决上面的问题，后来出现了分布式架构，分布式架构根据业务功能对系统进行拆分，每个业务模块作为独立项目开发，称为一个服务，其优点是降低了耦合度，有利于服务拓展升级。但是这种架构也不是完美的，因为这种拆分涉及到远程调用，其需要考虑如下问题：

• 服务拆分粒度如何
• 服务集群地址如何维护
• 服务之间如何实现远程调用
• 服务健康状态如何感知

        微服务的出现就能解决上面的问题，由于微服务架构将单体应用做了进一步拆分，每个服务都是一个可以独立运行的项目，其职责比较单一，代码量会明显减少，遇到问题也比较容易解决。且微服务每个模块之间的隔离性较强，每个模块都可以使用不同的技术进行开发，开发模式很灵活，因此想要对单个功能模块做出修改不会影响到其他的模块，实现了高内聚低耦合。不仅如此，微服务还是面向服务的，可以实现团队独立、技术独立、数据独立、部署独立。

二：🧸微服务技术栈

        介绍完微服务的基本原理之后，接下来就要了解微服务是怎么实现的，以及是通过哪些技术来实现微服务的，下面我先放一张技术栈总结图以及微服务整体架构图：

        当用户要进行项目访问时候，首先服务网关会对用户做身份校验，校验通过之后会将请求路由到具体服务，当然中间还可以进行负载均衡操作。当一个服务需要调用另一个服务时候，它如何在成百上千的服务集群中快速查找到需要调用的服务呢？这时候就需要注册中心了，注册中心中会记录每一个服务的IP地址以及端口号以及该服务实现的功能等信息，当一个服务需要调用另一个服务时候访问一下注册中心就可以快速定位到需要访问的服务地址。

        由于服务集群会很庞大，要单独对每一个服务进行配置是不太现实的，这就需要引入配置中心来同一进行配置。当服务完成相关业务功能之后，需要访问数据库获取数据，为了加快读取效率，往往会在服务集群与数据库中引入分布式缓存技术，分布式缓存技术就是将数据库中常用的数据加载到内存中以加快读取速度；对于一些复杂的搜索，还需要引入分布式搜索来完成搜索功能，因此数据库要做的操作就是读写操作以及一些事务支持以保证数据的安全性。

        当服务A需要调用服务B，服务B又需要调用服务C时候，整个业务链路就会很长，业务时长就会变成每个服务的执行时长之和，所以性能就会大打折扣。这时候就需要引入消息队列以实现异步通讯，怎么做的呢，简单来说就是当请求访问服务A时候，服务A就会通知服务B和服务C需要完成相应的工作，这时候服务A就可以停止了，这样整个业务链就大大缩短了，执行效率也会大大提升。

        面对如此庞大的服务集群，假如程序出现故障如何快速进行排查呢？这时候就需要引入分布式日志服务以及系统监控链路追踪。分布式日志服务可以统计整个服务集群中的每个服务的运行日志，假如某一服务出现了问题就能通过日志快速进行异常定位。系统监控链路追踪可以对系统中每一个服务节点的状态、CPU的负载等情况，一旦出现问题就可以定位到具体的方法栈信息进行异常定位。

三：🧸项目部署（持续集成）

        单体项目由于所有服务都在一个项目中，因此手动部署起来也不会很麻烦，但是对于微服务项目来说，服务集群中的服务成百上千甚至上万，要全部人工进行部署的话显然是很不现实的，这时候就可以考虑采用自动化部署。

        我们可以采用JenKins等工具对微服务项目进行自动化地编译，然后基于Docker进行打包形成镜像，最后基于K8S或者RANCHER等进行自动部署。