芝法酱躺平攻略（12）——SpringCloud下的微服务需求和技术分析

芝法酱

已于 2023-01-29 16:32:13 修改

阅读量215

点赞数

分类专栏： spring cloud 微服务架构文章标签：微服务 spring cloud java

于 2023-01-29 03:01:58 首次发布

本文链接：https://blog.csdn.net/hataksumo/article/details/128758955

版权

spring cloud 同时被 3 个专栏收录

1 篇文章 0 订阅

订阅专栏

微服务

1 篇文章 0 订阅

订阅专栏

架构

1 篇文章 0 订阅

订阅专栏

一、Java服务端架构演进

我们知道，Java服务端开发不是一开始就是微服务的。多数情况下，一开始大家都是写的单体，先把基本的功能做出来。而后随着用户量的提升，发现原先的单体架构难以应对，就逐渐拆分。

1.1 单体架构

最早的单体是把应用服务器与数据库服务器放在一起，适用于1千以下日活的产品，也就是1万左右用户。而后的版本把应用服务与数据库服务分开，这种架构，大概可以应对5千日活。
在这里插入图片描述
其实大部分国企的管理小项目，其实都可以用这种架构。毕竟，使用系统的可能只有个几百人。
该架构的有点是，易于集成、开发和部署。

1.2 集群架构

从1.1的右边的架构可以天然的想到，通常数据库服务的承载能力是大于应用服务的，那么我们把应用服务做水平扩展，多个应用服务器对应一个数据库，从而进一步提升服务器的处理能力。再加上缓存服务器，把一些常用的结果缓存在热数据中，进一步提升查询的速度。当然，这也避免了应用程序的单点故障。
小编认为，在开发新项目时，可以默认先使用1.2右边的架构。而应用服务根据行为类型划分成微服务（类似1.4），方便未来的水平扩展。
在这里插入图片描述

1.3 读写分离架构

我们发现，1.2的主要问题是，数据库不能水平拓展。那么，我们增加一个水平拓展即可。
通常的数据库水平拓展思路是做读写分离的主从设计。主数据库负责写入，写入后把数据自动复制到从数据库中，而从数据库则负责读取。
在这里插入图片描述

1.4 服务化-分库分表架构

我们之前的架构都是单体架构，服务端所有功能写道一个应用下（当然，可以分多个模块）。所谓服务的水平拓展，是服务的全量拷贝。但实际上，同一服务的不同接口的访问量可能是数量级的差异。把不同数量级的接口放在一个应用下，或造成资源争抢；在做水平拓展时也无法做到有的放矢。拿传统的电商服务来说，商家上架商品其实是个低频操作，但用户查询商品却是高频操作。如果把这两种接口放在一个服务中，就会导致特定高流量时段，商家上架商品变得卡卡的。
在数据库中，单表数据量超过百万后，会显著降低查询效率。这时通常我们会采取分库分表来解决。
这基本上是互联网项目的通用架构。
在这里插入图片描述

二、服务端架构的取舍

本攻略面向初学者，以讲解知识点为主，故采用1.4的架构。但为了方便开发讲解，一开始仅仅做微服务。而后逐步去做分库分表。
当然在现实开发中，我们应当首先分析需求，预估我的的系统用户大概在什么数量级，峰值的并发量大致在什么数量级，管理和查找的数据大致需要支持到什么数量级，再去决定用什么架构。毕竟开发项目的最终目标是为了赚钱，并且做什么事情也都是有风险的。所以我们在满足基本性能需求的前提下，尽可能的去选用简单的架构，先把功能做出来。而不是先去考虑项目多年后的事情。
一种无脑的方法论是，数据以用户为主的管理系统，无脑采用1.1的架构。面向资源的管理系统，无脑采用1.2架构；遇到性能瓶颈后升级到1.3架构。面向C端的互联网项目，第一版采用1.3架构，但做的时候考虑向1.4的升级。

三、微服务架构的常见需求与解决方案

3.1 服务的负载均衡

其实负载均衡，没有太多好说的。nginx的负载均衡和springcloud-gateway+nacos，正常接入都自带负载均衡功能。
一般说来，默认的负载均衡采用轮询，但也可以通过配置来修改。
具体介绍见后面的文章

3.2 服务间的通信

常见的服务间同步通信策略有openfeign和Dubbo。openfeign是一种短连接的实现，Dubbo是一种长连接的实现。
如果想要异步通信，可以使用异步调用，也可以使用消息队列。
如果需要通信的服务都是自己公司（或团队）的内部服务，可以沟通使他们配合接入的话，无疑使用消息队列是更优的。
但如果需要通信的服务是别人的（或别团队），不太好干预他们的行为，则更推荐使用异步调用。
对于消息队列，如果项目比较小，可以直接使用redis。如果项目较大，可以使用kafka或rocketMQ等。
异步调用推荐使用webclient。
具体介绍见后面的文章