微服务技术概述

最新推荐文章于 2022-11-16 00:47:40 发布

Fall_Flower

最新推荐文章于 2022-11-16 00:47:40 发布

阅读量1.3k

点赞数 3

分类专栏：微服务文章标签：微服务 java 分布式

本文链接：https://blog.csdn.net/by_zed/article/details/126295419

版权

微服务专栏收录该内容

2 篇文章 0 订阅

订阅专栏

1.微服务的由来

在谈论微服务之前，先来认识一下服务架构：

服务架构可分为单体架构和分布式架构。

单体架构就是将业务的所有功能集中在一个项目中开发，打成一个包部署。优点是架构简单，部署成本低；缺点则是耦合度高，维护升级都很困难。

分布式架构就是根据业务功能对系统做拆分，每个业务功能模块作为独立项目开发，称为一个服务。优点是有效降低服务耦合，有利于服务的升级和拓展，缺点是服务间调用关系错综复杂。

而本章要讨论的微服务，就是一种经过良好架构设计的分布式架构方案 。

微服务有如下几个特征：

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

其实这些特征就是在给分布式制订标准，降低服务间耦合度，提高服务独立和灵活性。

而Java领域微服务的王者就是SpringCloud提供的方案了。

2.微服务技术栈

提到微服务技术，好多人就会想到SpringCloud，但是微服务技术不仅仅包含SpringCloud，下面我将从一个大型单体项目讲起，一步步分析引入微服务技术栈

服务集群

对于一个大型单体项目，微服务要做的第一件事就是拆分，传统的单体架构，所有的业务功能都写在一起，随着业务越来越复杂，代码也越来越多，将来想要升级维护就会很困难。微服务在拆分的时候会根据业务功能模块，把一个单体项目拆分成功能独立的项目，每个项目完成一部分业务功能，将来独立开发和部署，我们将每个独立的项目称为服务，一个大型互联网项目往往包含数百上千的服务，最终形成服务集群

注册中心和配置中心

当一个请求到来的时候，服务a可能会去调服务c，服务c再去调服务e，当业务越来越复杂的时候，服务间的调用关系就会混乱不堪，想靠人去记录和维护是不可能的，这时候就要引出注册中心了

注册中心能记录每个微服务的ip、端口、能干什么事情，这样当一个服务需要去调用另外一个服务时，它不需要去记录对方的ip、端口信息，只需要去注册中心拉取即可。

同时，随着服务越来越多，每个服务的配置文件也越来越多，当我们需要修改时，若一个个修改则太麻烦了，所以再微服务里面还有一个配置中心，它可以统一管理服务集群里面所有服务的配置，如果你需要跟新某个服务的配置，只需要修改配置中心相应配置，它会去通知相关服务去修改配置实现配置的热更新

服务网关

服务跑起来之后，当用户来访问时，究竟去访问哪个微服务呢，这时候就需要一个网关组件，网关组件还能让微服务不对外暴露，不是什么人都能随便访问微服务的

当然，在访问的时候还会去做一些负载均衡。

分布式缓存和分布式搜索

这样，客户访问网关，网关调用微服务，微服务再调数据库集群进行操作。

可是数据库集群再多也不会多过用户，数据库将来肯定无法抗住高并发，因此我们还会加入分布式缓存

以后我们的业务中肯定会涉及查询功能，海量数据的复制搜索和分析，这时候还需要分布式搜索功能。那么数据库以后就主要用来进行写操作和事务类的对安全性要求较高的操作。

消息队列

最后，在微服务中还需要异步通信的消息队列组件：

为什么要消息队列呢，在一个请求到来时，假设调用了服务a，用时10ms，但是服务a调用了服务c，又用时10ms，而服务a在调用c的时候自己也不能再处理新的请求，这样就降低了整体服务效率。消息队列就将服务调用改为了服务通知，服务a在处理完自身的事情后只需要通知服务c，在服务c处理时自己就可以去处理新的请求，这样业务链路变短了，整个服务的吞吐能力也就变强了。所以异步通信可以大大提高服务的并发。