「 从0到1学习微服务SpringCloud 」01 一起来学呀!

有想学微服务的小伙伴没?一起来从0开始学习微服务SpringCloud,我会把学习成果总结下来,供大家参考学习,有兴趣可以一起来学!如有错误,望指正!

Spring 、SpringBoot、SpringCloud三者关系

SpringBoot基于spring来构建的,可以说是简化spring 的使用，开发起来无需被配置困扰，能够快速构建Spring应用,可以专注业务开发

SpringBoot是基于SpringCloud构建的,它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发

Spring Boot可以离开Spring Cloud独立使用开发项目，但是Spring Cloud离不开Spring Boot，属于依赖的关系。

什么是微服务

微服务是一个种架构风格。将整个系统按照业务划分成多个模块,每一个模块即一个微服务,如下图(物流系统微服务划分):

微服务有以下特点

• 一系列微小的服务共同构成

• 每个服务都有自己独立的进程

• 每个服务为独立的业务开发

• 独立部署

• 分布式管理

单体架构

单体架构另一种架构风格,比较原始的架构。将所有功能都部署在一个web容器中运行的系统。项目打包后，所有服务都在同一个war包中,部署在一个web容器中,共用一个数据库。如下图：

单体架构VS微服务

|

单体架构	微服务
优点	1.容易测试
2.容易部署	1.单一职责,逻辑清晰:每个服务即一个业务模块,逻辑清晰,让人容易理解

2.简化部署:修改了某个服务的代码,无需整个系统重新构建部署,只需要单独构建部署某个

3.灵活扩展:某部分业务请求压力大,则可通过扩展某块服务,因此具有更好的扩展性

4.技术异构:因为微服务间松耦合，不同的微服务可以选择不同的技术栈进行开发。同时，在应用新技术时，可以仅针对一个微服务进行快速改造，而不会影响系统中的其它微服务，有利于系统的演进。

5.高可靠:微服务间独立部署，一个微服务的异常不会导致其它微服务同时异常 |

| 缺点 | 1.开发效率低

2.代码维护难 

3.部署不灵活 

4.稳定性不高 

5.扩展性不够 | 1.复杂度高:需要考虑被调用方故障、过载、消息丢失等各种异常情况，代码逻辑更加复杂

2.运维复杂:系统由多个独立运行的微服务构成，需要一个设计良好的监控系统对各个微服务的运行状态进行监控。运维人员需要对系统有细致的了解才对够更好的运维系统

3.无法避免的重复工作:少部分共用功能无法提取成微服务时，各个微服务对于这部分功能通常需要重复开发，或至少要做代码复制，以避免微服务间的耦合，增加了开发成本。

4.影响性能:由于服务拆分开来，部署到不同的平台或网络，可能会引起微服务间的调用延迟问题，服务间的调用延迟可能带来整体系统的响应缓慢问题；

5.微服务不是银弹 |

单体架构和微服务架构各有各的有优缺点,使用哪种架构,还需根据具体项目背景及需求决定

其中,在以下几点中的,不适合使用微服务:

• 开发周期长,迭代稳定:若旧项目比较稳定,不考虑使用微服务,成本太高

• 并发量低,可用性要求不高:一些用户量低的内部系统,比如OA系统

• 复杂度较小:使用微服务就是杀鸡用牛刀

• …

分布式和集群

再来说说分布式和集群架构,微服务架构一定是分布式架构。

分布式是指将不同的业务分布在不同的地方。

而集群指的是将几台服务器集中在一起，实现同一业务。

引用网上的例子：

小饭店原来只有一个厨师，切菜洗菜备料炒菜全干。后来客人多了，厨房一个厨师忙不过来，又请了个厨师，两个厨师都能炒一样的菜，这两个厨师的关系是集群。为了让厨师专心炒菜，把菜做到极致，又请了个配菜师负责切菜，备菜，备料，厨师和配菜师的关系是分布式，一个配菜师也忙不过来了，又请了个配菜师，两个配菜师关系是集群

SpringCloud是什么

• SpringCloud是一个开发工具集合,含有多个子项目

• 利用SpringBoot的开发便利

• 主要进一步基于Netflix开源组件的进一步封装

• SpringCloud简化了分布式开发

SpringCloud核心组件架构图如下:

之后我们将一步一步地去学,敬请期待一下节内容!

如果觉得不错，请给个「好看」

分享给你的朋友！

THANDKS

• End -

一个立志成大腿而每天努力奋斗的年轻人

伴学习伴成长，成长之路你并不孤单!