微服务架构
认识微服务
随着互联网行业的发展，对服务的要求也越来越高，服务架构也从单体架构逐渐演变为现在流行的微服务架构。
单体架构
概念
单体架构是一种传统的软件架构模式，它将整个应用程序作为一个单一的、紧密集成的单元来开发、部署和管理。在单体架构中，应用程序通常由三个主要组件组成：
- 用户界面层（Presentation Layer）： 这一层负责处理用户的请求和呈现结果。通常包括Web界面、移动应用程序界面等。
- 业务逻辑层（Business Logic Layer）： 这一层包含应用程序的核心功能和业务逻辑。它处理来自用户界面的请求，执行相应的业务逻辑，并将结果返回给用户界面。
- 数据访问层（Data Access Layer）： 这一层负责与数据存储进行交互，包括数据库、文件系统等。它处理与数据相关的操作，如读取、写入、更新和删除数据。
在单体架构中，这三个组件通常部署在同一个运行时环境中，共享同一个数据库和资源。这种紧密集成的设计使得单体应用部署、测试和维护相对简单，适用于小型和中小型项目。
优缺点
-
优点：
- 简单易理解：整个应用程序作为一个单一的单元部署，易于理解和维护。
- 开发速度快：由于应用程序是单个单元，因此开发和测试速度通常较快。
- 部署简便：单体应用部署简单，只需将整个应用程序部署到目标环境中即可。
-
缺点：
- 可扩展性差：单体应用的扩展性受限，随着功能的增加和用户量的增加，很难进行水平扩展。
- 耦合度高：所有组件都紧密耦合在一起，一个组件的修改可能会影响其他组件，导致维护困难。
- 技术选型受限：由于应用程序整体采用同一技术栈，因此在需要使用新技术或语言时，可能需要对整个应用程序进行重构。
微服务架构
概念
微服务架构是一种分布式系统架构模式，它将应用程序拆分为多个独立的、自治的服务单元，每个服务单元都可以独立部署、扩展和管理。在微服务架构中，每个服务单元都是围绕着特定的业务功能进行组织的通常包含以下特点：
- 服务单元化（Service Unitization）： 应用程序被拆分为多个小型服务单元，每个服务单元都专注于实现一个特定的业务功能或服务。
- 分布式部署（Distributed Deployment）： 不同的服务单元可以独立部署在不同的物理或虚拟服务器上，彼此之间通过网络通信进行交互。
- 自治性（Autonomy）： 每个服务单元都是自治的，具有自己的数据存储、业务逻辑。它们可以使用不同的编程语言、框架和技术栈。
- 松耦合（Loose Coupling）： 不同服务单元之间通过API进行通信，彼此之间相对独立，修改一个服务单元不会影响其他服务单元。
微服务架构通过将应用程序拆分为多个小型服务单元，提高了系统的灵活性、可伸缩性和可维护性，适用于大型和复杂的项目。
优缺点
-
优点：
-
高度可扩展：微服务架构将应用程序拆分为多个独立的服务，每个服务都可以独立部署和扩展，提高了系统的可伸缩性。
-
松耦合：各个微服务之间通过API进行通信，彼此之间相对独立，修改一个微服务不会影响其他微服务，降低了系统的耦合度。
-
技术多样性：每个微服务可以使用适合自身需求的最佳技术栈，提高了灵活性和开发效率。
-
容错性高：由于微服务之间相互独立，一个服务的故障不会影响整个系统的运行，提高了系统的可用性。
-
-
缺点：
-
分布式系统复杂性：微服务架构涉及到多个分布式服务，需要解决分布式系统的复杂性问题，如服务发现、负载均衡、容错机制等。
-
部署和运维成本高：由于微服务数量较多，部署和管理这些微服务需要更多的人力和资源，增加了运维成本。
-
微服务组件
出现原因
随着服务数量的增加，微服务架构也带来了一系列复杂性问题，如服务发现、负载均衡、配置管理、容错处理等问题。Spring Cloud提供了一系列组件和工具，帮助开发人员解决这些复杂性，使得构建微服务架构应用更加简单和高效。
- 服务注册与发现： 在微服务架构中，服务的数量通常会动态变化，需要实现服务的注册与发现，使得服务能够自动地被发现和调用。Spring Cloud提供了服务注册与发现的解决方案，例如通过Netflix的Eureka组件实现。
- 负载均衡： 微服务架构中的服务通常会部署在多个实例上，需要实现负载均衡来分发请求，以保证系统的高可用性和性能。Spring Cloud提供了负载均衡的解决方案，例如通过Netflix的Ribbon组件实现。
- 配置管理： 在微服务架构中，服务的配置通常会分散在多个服务中，需要实现统一的配置管理，以便实现配置的集中管理和动态更新。Spring Cloud提供了配置管理的解决方案，例如通过Spring Cloud Config组件实现。
- 断路器和容错处理： 在微服务架构中，由于服务之间的依赖关系，一个服务的故障可能会导致整个系统的故障。因此，需要实现断路器和容错处理机制，使得系统能够在部分服务故障的情况下依然保持可用。Spring Cloud提供了断路器和容错处理的解决方案，例如通过Netflix的Hystrix组件实现。
Nacos
Nacos（全称：Dynamic Naming and Configuration Service）是阿里巴巴开源的一款易于使用的动态服务发现、配置管理和服务管理平台。它提供了一组简单易用的特性，包括服务发现、服务健康监测、动态配置管理等功能。
服务注册与发现
- 服务注册： 当一个微服务启动时，它会向Nacos注册自己的信息，包括服务名称、IP地址、端口号等。这样，其他服务就可以通过Nacos获取该服务的信息，从而发现并调用它。
- 服务发现： 当一个服务需要调用另一个服务时，它可以向Nacos发起服务发现请求，Nacos会返回目标服务的地址信息给调用方。这样，调用方就可以通过获取到的地址信息直接调用目标服务，实现服务间的通信。
- 服务实例管理： Nacos不仅可以管理服务的注册信息，还可以管理服务的实例信息。它可以实时监控服务的健康状态，并提供服务实例的增删改查等管理功能。当服务实例发生变化时，例如新增、删除或状态变化，Nacos会及时更新服务列表，确保服务发现的准确性和实时性。
- 负载均衡： Nacos可以根据服务实例的负载情况和状态信息，动态地进行负载均衡。当一个服务有多个实例时，Nacos会根据负载情况自动选择合适的实例进行请求转发，以保证系统的性能和可用性。
配置中心及动态配置管理
- 配置存储： Nacos提供了一个集中式的配置存储系统，开发人员可以将应用程序的配置信息存储在Nacos中，例如数据库连接信息、日志级别、缓存配置等。
- 动态配置管理： Nacos支持动态配置管理，意味着开发人员可以在运行时动态地修改应用程序的配置，而无需重新启动或重新部署应用程序。这使得配置的修改变得非常灵活和便捷，可以更快地响应需求变化或故障情况。
- 配置分组和命名空间： Nacos支持配置的分组和命名空间，可以将不同环境（如开发、测试、生产）的配置信息进行分组管理，同时也支持多租户的配置管理，为不同的用户或团队提供独立的配置空间。
- 配置版本管理： Nacos提供了配置版本管理功能，可以对配置进行版本控制和历史记录，开发人员可以方便地查看和回滚配置的历史版本，以确保配置的稳定性和可追溯性。
健康检查机制
- 健康检查间隔： Nacos允许设置健康检查的间隔时间，即服务实例进行健康检查的频率。较短的健康检查间隔可以使得系统能够更快地发现服务实例的异常情况，但也会增加系统的负载。
- 健康检查超时： 开发人员可以设置健康检查的超时时间，即服务实例进行健康检查的最大响应时间。如果服务实例在超时时间内未能完成健康检查，Nacos会将该实例标记为不健康。
- 健康检查阈值： Nacos支持设置健康检查的阈值，即服务实例在连续多少次健康检查中失败后被标记为不健康。通过设置合适的健康检查阈值，可以减少误报，提高系统的稳定性。
- 健康状态上报： 当服务实例完成健康检查后，会将检查结果上报给Nacos。如果服务实例被标记为不健康，Nacos会触发相应的处理逻辑，例如从服务列表中移除不健康的实例或进行服务实例的重启。
服务和元数据管理
Nacos能让你从微服务平台建设的视觉管理数据中心的所有服务及元数据，包括管理服务的描述、生命周期、服务的静态依赖分析、服务的健康状态、服务的流量管理、路由及安全策略。
Spring Cloud Gateway
Spring Cloud Gateway的设计目标是提供一个统一的API入口，为微服务应用程序提供基于路由的访问，同时还支持常见的负载均衡、安全、监控等功能。Spring Cloud Gateway支持多种路由策略，包括基于路径、基于服务、基于请求参数等。它还支持动态路由，可以根据运行时的情况动态地添加、删除或更新路由规则。
应用
- 路由：
- 通过路由规则，Gateway能够将接收到的请求准确地转发到后端相应的微服务，实现请求的分发与服务的解耦
- 安全控制：
- 实施身份验证、授权、访问控制等安全策略。它可以集成OAuth、JWT等认证机制，对请求进行身份验证；实施基于角色、权限的访问控制；还可以进行IP黑名单、请求频率限制、请求内容校验等安全措施，保护后端服务免受恶意攻击和滥用。
其他中间件
缓存
Redis是由C语言编写的开源、基于内存、支持多种数据结构、高性能的Key-Value数据库。
特点
- 速度快
- 基于内存的读写操作，没有磁盘IO的性能开销
- 采⽤单线程去处理⽹络IO请求以及指令的执⾏，避免多线程的竞争以及上下⽂切换的开销
- 对于每种数据类型都进⾏了优化，⽐如使⽤skiplist来提升查找效率
- 持久化
- Redis可以通过
RDB和AOF两种方式将数据持久化到磁盘上，其中这两种方式的区别如下：- RDB：是在指定的时间间隔内将内存中的数据通过异步生成数据快照并且保存到磁盘中。
- AOF：相对于
RDB方式，AOF方式的持久化更细粒度，把每次数据变化（写、删除操作）都记录AOF文件中，其中AOF又可以配置为always即实时将记录写到AOF文件中，everysec每隔一秒将记录写到AOF文件中，no由系统决定何时将记录写到AOF文件中。
- Redis可以通过
- 多种数据结构
- 分别是String（字符串），Hash（哈希），List（列表），Set（集合），Zset（即Sorted Set有序集合）
- https://blog.csdn.net/qq_53195681/article/details/135363559?spm=1001.2014.3001.5501
- 支持多种编程语言
- Redis支持多种语言，诸如Ruby,Python, Twisted Python, PHP, Erlang, Tcl, Perl, Lua, Java, Scala, Clojure等。
- 功能丰富
- 根据提供的数据结构，可以完成一些功能的封装，如分布式锁、延时队列、消息队列等
- 主从复制
- 在集群环境中，可以根据配置，自动完成主机和从机的数据统一。
使用注意
- 使用规范，如key的命名、DB的选择、大key的处理
- 常见的问题，如缓存的自动加载；大数据量时，缓存雪崩、穿透、击穿的问题
消息队列
Kafka 是一个开源的、分布式的消息发布订阅系统，Kafka 设计用于处理大量实时产生的数据流，常被用作企业级的流处理平台和消息中间件。其核心特点是高吞吐量、低延迟、可扩展性和持久性，适用于构建实时数据管道、流处理应用程序以及作为微服务间的消息传递机制。
生产者与消费者
- 生产者（Producer）：负责发布消息到指定的主题。生产者可以选择将消息发送到特定的分区，也可以让 Kafka 自动分配。生产者支持批量发送和压缩消息以提高效率。
- 消费者（Consumer）：
- 独立消费者：直接从主题的分区中拉取消息，自行管理消费进度（即偏移量）。
- 消费者组（Consumer Group）：一组消费者订阅同一主题时形成消费者组。Kafka 确保组内每个消息只被一个消费者消费，实现负载均衡和故障恢复。消费者组内部的消息消费遵循“分区所有者”模式，每个分区在同一时刻仅由一个消费者实例消费。
使用场景
-
削峰填谷，提高系统稳定性
-
整合ELK，进行日志的处理
-
数据集成与传输
ELK
ELK 是一个首字母缩写词，代表 Elasticsearch, Logstash, Kibana 这三款开源软件产品的组合。这些产品共同构成了一个强大的日志管理和数据分析平台，专门用于收集、存储、搜索、分析以及可视化大规模分布式系统的日志数据和其他类型的时间序列数据。以下是每个组件及其在 ELK Stack 中的作用：
Elasticsearch
Elasticsearch 是一个高度可扩展、实时的分布式搜索引擎和分析引擎，基于 Apache Lucene 构建。它主要用于存储和检索数据，尤其是对全文搜索、结构化搜索和复杂聚合查询有高性能需求的应用场景。Elasticsearch 采用 NoSQL 数据模型，以 JSON 格式存储文档，并通过 RESTful API 提供接口。
Logstash
Logstash 是一个数据收集引擎，负责从各种来源摄取（ingest）数据，对其进行过滤、转换和丰富，然后再输出到指定的目的地（如 Elasticsearch）。Logstash 可以通过插件机制连接众多输入源（如文件、syslog、数据库、API等）、执行复杂的事件处理逻辑，并将处理后的数据发送到多个输出目标。关键特性包括：
- 数据摄取：支持多种输入插件，能够从不同的日志文件、消息队列、网络端口等源头收集数据。
- 数据处理：包含一系列过滤器插件，用于解析日志格式、提取关键字段、去除噪音数据、进行地理信息解析等。
- 数据输出：能够将经过处理的数据推送到多种目的地，最常见的是 Elasticsearch，但也包括其他数据库、消息队列、文件系统等。
Kibana
Kibana 是一个基于 Web 的数据可视化和分析工具，专为与 Elasticsearch 配合使用而设计。它允许用户以交互方式探索、搜索、分析存储在 Elasticsearch 中的数据，并通过构建丰富的图表、仪表板和可视化报告来呈现结果。Kibana 的核心功能包括：
- 数据发现：提供直观的界面，让用户能够搜索、筛选和浏览 Elasticsearch 中的数据，进行实时的日志分析。
- 可视化创建：内置多种图表类型（柱状图、折线图、地图、饼图等），用户可以通过拖拽式界面快速创建数据可视化。
- 仪表板：支持将多个可视化组件整合到一个仪表板中，便于集中监控和对比分析不同数据集。
- 时间序列分析：特别适合处理时间戳数据，能够按时间窗口进行滚动、缩放和平移，以便观察数据随时间的变化趋势。
- 告警与通知：可设置数据阈值触发告警，并通过电子邮件、Slack 等渠道发送通知。
通过 Elasticsearch 实现数据存储与检索、Logstash 负责数据收集与预处理、Kibana 则提供数据可视化和交互式分析界面。
CI/CD
CI/CD是持续集成（Continuous Integration）与持续交付（Continuous Delivery）的结合，是一种软件开发流程和实践方法。
工具
-
Docker：
-
Docker是一种容器化平台，允许开发人员将应用程序和所有相关的依赖项打包到一个独立的、可移植的容器中。这使得应用程序在不同环境中的部署变得更加简单和可靠。
-
Docker与虚拟机的对比
-
Docker运行流程（简化）
-
-
Kubernetes (K8s)：
- Kubernetes是一个开源的容器编排引擎，用于自动化应用程序的部署、扩展和管理。Kubernetes可以管理多个Docker容器，并提供了许多功能，如自动伸缩、负载均衡、服务发现等，帮助简化和优化容器化应用程序的部署和管理。
-
Jenkins：
- Jenkins是一个开源的持续集成和持续交付工具，用于自动化软件开发过程中的构建、测试和部署。Jenkins提供了丰富的插件和可扩展性，可以与各种版本控制系统、构建工具和部署工具集成，支持灵活的CI/CD流水线的定义和管理。
-
Rancher：
- Rancher是一个开源的容器管理平台，用于简化Kubernetes的部署、操作和管理。Rancher提供了友好的用户界面、多集群管理、安全性、监控和日志等功能，帮助企业更轻松地使用Kubernetes来构建和管理容器化应用程序。
-
GitLab：
- GitLab是一个基于Git的开源代码托管平台，提供了代码仓库管理、问题跟踪、持续集成、持续交付等功能。GitLab内置了CI/CD功能，可以通过配置CI/CD流水线来自动化构建、测试和部署应用程序。
CI/CD流水线的大体执行流程如下：
代码托管与版本控制:
- GitLab: 作为源代码管理系统，开发者在这里提交代码、管理分支、发起合并请求（Pull/Merge Requests）。GitLab 提供了内置的 CI/CD 功能，可通过 .gitlab-ci.yml 文件定义自动化构建、测试和部署任务。
- 持续集成 (CI)
- Jenkins: 监听 GitLab 上的代码变更事件（如 push、merge）。 Jenkins 服务器接收到事件后，按照预定义的配置文件启动相应的构建作业。
- 构建与镜像制作:
Docker: 在 CI 作业中，使用 Docker 将应用及其依赖打包成 Docker 镜像。这通常通过 docker build 命令结合 Dockerfile 完成，确保每次构建都能生成一个可移植、可重复部署的应用容器镜像。 - 镜像存储与管理:
成功构建的 Docker 镜像被推送至GitLab 内置的 Container Registry，供后续部署阶段使用。
环境管理与应用部署: - 持续部署 (CD):
- Jenkins Pipeline: 当 CI 作业成功完成后，触发 CD 阶段。此时，可以使用 GitLab 的 CI/CD 管道或者 Jenkins Pipeline 自动将新构建的镜像部署到 Kubernetes 集群。
- Rancher 监控: 监控部署后应用的健康状况、资源使用情况等指标。提供集群及应用层面的监控视图，方便快速定位问题。
- GitLab / Jenkins 集成通知：通过邮件、Slack、Microsoft Teams 等渠道发送构建和部署状态的通知。
简化流程：
- 开发者在 GitLab 上编写和提交代码。
- Jenkins 依据事件触发 CI 作业，使用 Docker 构建应用镜像并推送到镜像仓库。
成功构建后，CD 流程启动，更新 Kubernetes 配置并部署新镜像到目标环境（由 Kubernetes 或 Rancher 管理）。- 监控系统跟踪应用状态，及时发出告警，同时向开发团队提供部署反馈。
7万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
