【微服务】微服务初步认识 - 微服务技术如何学习

微服务（1）

文章目录

【微服务】（1）
1. 微服务相关技术栈
2. 微服务学习路线
3. 认识微服务架构
3.1 单体架构
3.2 分布式架构
3.3 微服务(架构)
3.4 微服务(架构)治理落实相关的SpringCloud、SpringCloudAlibaba和阿里巴巴的Dubbo提供的服务治理方案
3.5 SpringCloud
3.6 总结

【微服务】（1）

1. 微服务相关技术栈

在这里插入图片描述

微服务只是分布式架构中的一种，而SpringCloud只是解决了服务拆分时的服务治理问题，至于其他的分布式的更复杂的问题并没有明确的给出解决方案，所以微服务不仅仅包含SpringCloud，还包含一些其他的~

对于SpringCloud相关的微服务(架构)治理工作（大概了解，先不关注原理）

服务拆分
- 每一个服务单元我们称之为一个微服务；一个微服务的多个实例称之为集群
- （实例代表的含义就是此微服务逻辑的实现业务的对象，是一个实体，而微服务是一个业务，是虚的）
- 这样就降低耦合度，方便管理与开发、维护、更新…

注册中心

由于调用关系复杂，所以通过人力来解决是不太现实的

而引入注册中心：

每个服务都需要向注册中心“注册”，注册中心就会记录每一个服务信息（ip、端口、干啥业务…）
一个服务调用另一个服务的话，就是找注册中心“要”，“拉取”对应服务的信息

配置中心

每个服务都有配置文件，难道我们要逐个修改吗？

配置中心可以进行配置管理：

之后要修改配置，找配置中心，他会通知相关微服务，进行配置的热更新

服务网关

用户发来的请求，咋知道访问哪个服务呀，这个时候就需要一个指路人：服务网关（并且，对用户身份啥的也有一些检验）

最后服务作用于数据库

这里数据库写成一个，画是这么画，但是现实是一个服务对应一个数据库，数据库也有集群…以后再说，这里先放心~

SpringCloud基础上，微服务还涉及分布式缓存：

放在内存运行，提高效率，减少数据库压力…
分布式应对高并发等等…

在这里插入图片描述

海量数据，复杂搜索，统计分析还需要用到分布式搜索：

在这里插入图片描述

异步通信的消息队列组件MQ：

利用异步通信，提高吞吐能力
- 异步的概念不多说，不懂的可以去查

在这里插入图片描述

便于排查问题的分布式系统监控链路追踪和日志服务：

在这里插入图片描述

由于微服务的数量巨大，需要持续集成：

自动化编译的Jenkins
自动化生成打包生成镜像的docker
自动化部署的kubernetes和rancher

在这里插入图片描述

这些东西结合起来，才是完整的微服务技术栈！

而这蕴含什么知识点，我们要怎么学习这些知识呢？

2. 微服务学习路线

差不多这些：

分类后：

整理后：

分不同的篇章：实用、高级、面试

在这里插入图片描述

所以微服务专栏加上本文预计十三篇以上的文章，敬请期待！

除了图中的内容，还会结合案例进行讲解！

3. 认识微服务架构

随着互联网行业的发展，对服务的要求也越来越高，服务架构也从单体架构逐渐演变为现在流行的微服务架构。这些架构之间有怎样的差别呢？

3.1 单体架构

单体架构：将业务的所有功能集中在一个项目中开发，打成一个包部署。

在这里插入图片描述

单体架构的优缺点如下：

优点：

架构简单
部署成本低

缺点：

耦合度高（维护困难、升级困难）

并且，在同一个项目里，代码量庞大，光是打包部署就要花不少的时间，效率低

开发的过程中这些模块之间，代码你中有我，我中有你，耦合度高，边界模糊，改一处动万处！

耦合度高是不适合大型项目开发的！

而大项目一定会做分布式架构~

3.2 分布式架构

分布式架构：根据业务功能 对系统做拆分，每个业务功能模块 作为独立项目开发，称为 一个服务。

在这里插入图片描述

分布式架构的优缺点：

优点：

降低服务耦合

有利于服务升级和拓展

在其中一个服务修改，并不会直接影响其他服务~

缺点：

服务调用关系错综复杂，并且一个服务可能有一个集群，也就是多个机器来维护
目前的集群，浅显的认知为**“一个服务的多个一模一样的不同实例的集合，而这个集合就是集群”**，例如支付功能服务，这些不同的实例，功能都一样，都有对应的接口，只不过工作性能有区别，至于这些“打工仔”，任务如何分配？就涉及微服务架构相关知识了~

分布式架构虽然降低了服务耦合，但是服务拆分时也有很多问题需要思考：

服务拆分的粒度如何界定？
- 哪些业务在一起呢？
服务集群地址和配置管理如何维护？
- 用地址访问一个集群、一个集群中的某个实例？
- 不同服务，有不同的配置文件，我们难不成逐一修改？
- 写死？肯定不行！上线改一下，代码不就不能用了！所以得支持动态的，方便维护的！
服务之间如何实现远程调用？
- 这可是跨服务的，怎么远程调用别的模块？例如订单模块调用支付模块…
服务健康状态（是否崩溃、宕机…）如何感知？
- 我怎么保证我能访问到好的服务机器呢

在这里插入图片描述

因此，人们需要制定一套行之有效的标准规范来约束分布式架构！

近几年应用最广泛的无非就是，微服务方案了~

3.3 微服务(架构)

微服务架构是一种经过良好的架构设计的分布式架构方案，微服务架构特征：

单一职责： 微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责
自治： 团队独立、技术独立、数据独立，独立部署和交付（一个独立团队对一个服务的开发交流更加方便迅速）
- 并且不同团队用得不是同一个技术也无所谓，因为独立自治
面向服务： 服务提供统一标准的接口，与语言和技术无关（暴露接口）
隔离性强： 服务调用做好隔离、容错、降级，避免出现级联问题

对于用户相关模块，尽可能的细分，降耦合，方便后续添加更多功能服务

每个服务相互独立，并且数据独立（一个服务就对应一个数据库

（基于分布式架构的独立性的进一步体现，更加独立了！）

例如积分服务就不能直接影响用户服务的数据库，而是得调用用户服务的接口，这样就解耦合了，也降低数据库污染和降低漏洞的出现，因为别的服务对这个业务也有一套完整的“验证”，危险系数比直接影响数据库的要低~）

用户请求需要调用对应接口，通过服务网关，调用到正确的接口（因为他们部署独立，找到正确的接口并访问就需要这个入口，也就是服务网关）

不知道你有没有在学校做过团队合作的程序项目，如果不是微服务，是不是拼装代码一系列的问题接踵而至？头皮发麻？配置相关的问题也层出不穷？代码耦合高，都拉丝了？
微服务就没有这个烦恼~

微服务的上述特性其实是在给分布式架构制定一个标准，进一步降低服务之间的耦合度，提供服务的独立性和灵活性。做到高内聚，低耦合。

是不是之前自以为的代码高内聚低耦合，在微服务面前简直是小儿科😀

因此，可以认为微服务是一种经过良好架构设计的分布式架构方案 。

而微服务架构，是一种开发结构，一种开发思想，一种标准，一种良好的大项目开发方案，后面用到的技术栈是对此架构实现的"对症下药"！

两者之间是常见的“思想与落实”的区别
而我们要实现这么一个架构，就要有对应的技术，在使用技术的同时，不忘微服务架构的初心（也就是上面几点），因为微服架构务并不是一个强制的，不代表你不遵循他，你的项目就运行不了，他并不会从开发过程上限制你不单一职责，不自治，不面向服务，不隔离性强…

微服务架构方案较于普通的分布式架构

优点：

拆分粒度更小、服务更独立、耦合度更低

缺点：

架构更加复杂，运维、监控、部署难度提高，也就是方案落地困难

这个方案只是“纸上谈兵”

方案该怎么实现与落地？选用什么样的技术栈？

全球的互联网公司都在积极尝试自己的微服务落地方案。

其中在Java领域最引人注目的就是SpringCloud、SpringCloudAlibaba和阿里巴巴的Dubbo提供的服务治理方案了。

3.4 微服务(架构)治理落实相关的SpringCloud、SpringCloudAlibaba和阿里巴巴的Dubbo提供的服务治理方案

而他们大体都是以下模式来实现微服务治理，只不过具体用到的中间件和技术栈有所不同：

服务信息管理问题 - 注册中心
环境配置管理问题 - 配置中心
用户请求方向问题 - 服务网关

（大概了解即可，后面结合相关中间件和技术来理解他们怎么解决问题的）

在这里插入图片描述

对比几种微服务技术：

在这里插入图片描述

在微服务学习过程，我们以SpringCloudAlibaba为主

SpringCloudAlibaba以SpringCloud为基础的扩展，兼容很多SpringCloud的东西，所以用起来有点像SpringCloud

所以学习SpringCloudAlibaba相当于学习了SpringCloud

也兼容了Dubbo

阿里巴巴把自己的Dubbo也整合进来，有一些扩展的东西，例如Nacos，Dubbo，Sentinel…

（Nacos支持Dubbo协议调用，也支持Feign协议调用…）

以下是四种企业微服务架构落地情况：

学习SpringCloudAlibba，其实就能面对这前三类种情况啦

最后一种这种很老的技术体系，如果遇到这么老的项目，你的SpringCloudAlibaba的技能就被缴械了，你只能累一点，用Dubbo开发咯，最好就是跟0🔪建议技术升级为SpringAlibaba + Dubbo，代码不用动，换以下中间件啥的就行啦