初识微服务

微服务开篇之初识微服务

1：什么是微服务

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

❤️❤️❤️❤️❤️❤️❤️❤️❤️❤️❤️❤️❤️❤️❤️❤️❤️❤️❤️❤️❤️

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

2：为什么需要微服务

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

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

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

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

3：微服务技术栈简介

图片来源于黑马 ppt

4：微服务特性

微服务的架构特征：

• 单一职责：微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责
• 自治：团队独立、技术独立、数据独立，独立部署和交付
• 面向服务：服务提供统一标准的接口，与语言和技术无关
• 隔离性强：服务调用做好隔离、容错、降级，避免出现级联问题

优点：

（1）可以使用不同语言或者相同语言的不同版本开发各个模块。

（2）系统耦合性低，各个模块分而治之，独立部署，独立发布，独立维护。

（3）可以更快的相应市场的需求，更符合敏捷开发。

（4）可以对不同模块使用集群策略，哪里有问题治哪里。

缺点：

（1）开发难度更大，系统结构更复杂，运维、监控、部署难度提高。

（2）运行效率低，网络调用成本很大。