前言
以后，微服务架构在很多公司都曾经落地施行了，上面用一张图简要概述下微服务架构设计中罕用组件。不能说曾经应用微服务好几年了，后果对微服务架构没有一个整体的认知，一个只懂搬砖的程序员不是一个好码农。
流量入口 Nginx
在上图中能够看到，Nginx 作为整个架构的流量入口，能够了解为一个内部的网关，它承当着申请的路由转发、负载平衡、动静拆散等性能。作为一个外围入口点，Nginx 必定要采纳多节点部署，同时通过 keepalived 来实现高可用，从而保障整个平台的高可用。
举荐一个开源收费的 Spring Boot 实战我的项目：
https://github.com/javastacks/spring-boot-best-practice
网关
网关是在 Nginx 后的另外一个外围组件。它承当着申请鉴权，路由转发，协定转换，流量监控等一系列性能，上图中网关是采纳 spring Cloud Gateway 来实现业务网关的性能，在网关选型中，咱们还有其余的抉择，比方 Zuul1,Zuul2,Kong 等等，这些计划都有本人的劣势和局限性，咱们能够依据本人他们的特点来抉择到底选用哪一个计划。对于网关的深刻理解，能够参见之前的系列文章网关那点事，这里不做赘述。
上图中，Spring Cloud Gateway 上面有 jwt 和 OAuth2，其实这两个就是基于 token 的认证鉴权，个别互联网我的项目中，在登录模块都是反对微信或者 qq 登录，这就是用到 OAuth2 的受权登录。想深刻理解 Oauth2 相干细节，能够参考之前的 Oauth2.0 客户端服务端示例等系列文章。
业务组件
从下面的架构图中能够看到，网关之后就是咱们的业务组件了，能够了解就是拆分之后的微服务了，比方电商平台常见的账号服务、订单服务、发票服务、收银台服务等等。服务组件之间通过 Feign 来进行 http 调用，Feign 集成 Ribbon 来实现客户端侧负载平衡。具体的服务畛域划分，服务限界上下文的设定，这就另外的常识了，如果想做好服务划分，DDD 畛域驱动设计这块能够深刻理解下。
服务注册核心
不论是基于 Dubbo 实现的 SOA，还是基于 Spring Cloud 拆分的微服务架构，服务注册核心都是必须的，咱们把所有的服务组件都注册到注册核心，进而实现服务的动静调用。常见能实现注册核心性能的有 Zookeeper,Eureka,Nacos,Zookeeper 在 Dubbo 中应用比拟多，目前公司服务微服务架构是基于 Eureka 的，Eureka 如同目前不保护了。个别新的平台倡议间接集成 Nacos，Nacos 除了能做注册核心来应用，也能够作为分布式配置核心来应用，比 Sping Cloud Config 更好使。
缓存和分布式锁
在图中左下角，咱们能够看到 Redis 组件，咱们能够把 Redis 作为缓存来应用，把一些查问慢，使用率高的热点数据做缓存解决，能疾速进步接口响应工夫。同时 redis 在微服务中的一大应用场景就是分布式锁，传统的 Sychronized 和显示 Lock 锁显然是不能解决分布式并发问题。
为了保障 Redis 的高可用，能够采纳哨兵部署，不是三个 redis 节点，一主二从，同时部署三个哨兵节点，来实现故障转移，防止单点问题，如果 Redis 存储的数据量很大，达到了单节点的 Redis 的性能瓶颈，咱们也能够用 Redis 集群模式来实现分布式存储。
数据长久层
不论单体服务，还是微服务，数据长久层都是必须的，咱们是选用互联网我的项目常常应用的 mysql 作为 DB，为了保障服务读写效率以及高可用性，咱们主从拆散模式，同时实现读写拆散，来保障 mysql 的读写性能。
随着业务量增长，单表的数据量达到性能瓶颈之后，咱们就要采纳分库分表来对数据库表进行程度拆分和垂直拆分了，具体如何进行正当的拆分，以及技术选型，这些和我的项目现有的表结构设计是非亲非故的，要思考后续的可拓展性，不能短期拆了一时爽，后续业务量增暴涨之后，服务器的性能不足以维持数据库的性能时，这时候要拆分服务器部署了。当然，个别企业的数据量级达不到那样的量级。
结构型数据存储
mysql 比拟善于存储关系型数据，我的项目中有须要存储结构性数据的场景，比方存储 JSON 字符串，这种场景通过 mysql 来存储显然事不适合的。个别咱们会采纳 Elasticsearch 或者 MangoDB 来进行存储，如果业务中须要检索性能，更倡议应用 Elasticsearch。Elasticsearch 反对 DSL，有比拟丰盛查问检索性能，甚至能实现 GIS 空间检索性能。
消息中间件
后面说到，微服务架构中，服务之间同步调用是通过 Feign 来实现的，那服务间的异步解耦就要通过 MQ 来实现了。尽管咱们能够通过多线程来实现异步调用，然而这种异步调用不反对长久化，可能会造成音讯失落，所以个别都集成 RabbitMq 或者 RocketMq。
日志收集
在微服务架构中，通过一个组件，比如说订单服务都是多节点分布式部署，每个节点的 log 日志都是存储在节点本地，如果要查问日志，咱们难道要登录到各个节点找到对应的日志信息？这种查看日志必定是不行的。所以个别会引入 ELK 来做日志收集，和可视化展现查问。
- Logstash 用来做日志收集工作，通常在 Logstash 前会加一个 Filebeat，由 Filebeat 来收集日志，Logstash 做数据转换工作。
- Elasticsearch 做数据存储，以及生成索引数据，便于 Kibana 做检索。
- Kibana 做数据的展现，以及查问检索性能，咱们通过检索关键词就能疾速的查问到想要日志信息。
任务调度核心
我的项目中常常会用到定时性能，单体利用中，咱们应用 sping 自带的 Schedule，或者应用 Quartz 即可，在分布式应用中，咱们就要集成分布式定时器，比方 Quartz(Quartz 配合数据库表也是反对分布式定时工作的)，还有 Elastic-Job、XXL-JOB 等等。
Elastic-job 当当网基于 quartz 二次开发的弹性分布式任务调度零碎，功能丰富弱小，采纳 zookeeper 实现分布式协调，实现工作高可用以及分片。Elastic-Job 是一个散布式调度的解决方案，由当当网开源，它由两个互相独立的子项目 Elastic-Job-Lite 和 Elastic-Job-Cloud 组成，应用 Elastic-Job 能够疾速实现分布式任务调度。
XXL-JOB 是一个分布式任务调度平台（XXL 是作者徐雪里姓名拼音的首字母），其外围设计指标是开发迅速、学习简略、轻量级、易扩大。将调度行为形象造成“调度核心”公共平台，而平台本身并不承当业务逻辑，“调度核心”负责发动调度申请。将工作形象成扩散的 JobHandler，交由“执行器”对立治理，“执行器”负责接管调度申请并执行对应的 JobHandler 中业务逻辑。因而，“调度”和“工作”两局部能够互相解耦，进步零碎整体稳定性和扩展性。
分布式对象存储
我的项目中常常会有文件上传性能，比方图片，音频视频。在分布式架构中，咱们将文件存储在节点服务器上显然是不行的，这时候，咱们就须要引入分布式文件存储。常见计划有 MinIo、阿里的 OSS（免费），阿里 FastDFS 等等。
MinIO 是一款基于 Go 语言发开的高性能、分布式的对象存储系统。客户端反对 Java、Net、Python、Javacript、Golang 语言。
FastDFS 是一个开源的轻量级分布式文件系统，它对文件进行治理，性能包含：文件存储、文件同步、文件拜访（文件上传、文件下载）等，解决了大容量存储和的问题。特地适宜以文件为载体的在线服务，如相册网站、视频网站等等。
起源：blog.csdn.net/qq_28165595/article/details/128169770
更多文章举荐：
1.Spring Boot 3.x 教程，太全了！
2.2,000+ 道 Java 面试题及答案整顿 (2024 最新版)
3. 收费获取 IDEA 激活码的 7 种形式（2024 最新版）
感觉不错，别忘了顺手点赞 + 转发哦！