【服务治理①】软件架构服务治理的本质，当下最火的微服务到底是什么？利用AIGC学习微服务的第①弹-Toy模板网

这篇具有很好参考价值的文章主要介绍了【服务治理①】软件架构服务治理的本质，当下最火的微服务到底是什么？利用AIGC学习微服务的第①弹。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

一、什么是软件架构中的服务治理

治理讲究战术，自顶向下治理的方式、综合统筹的治理、分而治之的思想。服务治理就是治理服务（来自电源《年会不能停》解释名词的方法 😃），属于过程管理，即从服务的启动到服务的进行再到服务的终止期间发生的全生命周期的数据治理、规则管理、数据监控、安全追溯的过程（自定义de哦）。

微服务架构就是服务治理的一种表现形式。

1.1 软件架构

软件架构对应用功能影像不大，影响的是应用的非功能性需求，也成为质量属性或者其它能力。

1.2 单体架构

泥球模式的作者 Brian Foote 和Joseph Yoder 把这样的软件比喻为 “ 随意架构的、庞大的、草率的、布满了胶带和线路，如同意大利面条一般的代码丛林” 。单体架构的软件随着迭代很容易就成为这样的风格。

【服务治理①】软件架构服务治理的本质，当下最火的微服务到底是什么？利用AIGC学习微服务的第①弹,微服务,dubbo,rpc,微服务,springcloud

1.2.1 单体架构的好处

【服务治理①】软件架构服务治理的本质，当下最火的微服务到底是什么？利用AIGC学习微服务的第①弹,微服务,dubbo,rpc,微服务,springcloud

1.2.2 单体架构的弊端

过度的复杂性，单体程序随着时间的推移，功能越来越复杂，涉及到的开发人员越来越多，对其维护和开发变得很困难；
开发速度缓慢，代码量太多，启动、开发、编译费时费力；
开发到部署的时间长；
难以扩展；
可靠性不高；
对老旧技术栈依赖深。

二、为什么需要微服务架构

软件架构扩展立方体
【服务治理①】软件架构服务治理的本质，当下最火的微服务到底是什么？利用AIGC学习微服务的第①弹,微服务,dubbo,rpc,微服务,springcloud

X轴扩展
Z轴扩展
Y轴扩展

X、Z轴方向的扩展保证了软件的可用性和吞吐量，但没有解决日益增长的开发问题和=应用复杂性。

2.1 微服务架构优势

服务治理在微服务架构中提得多，从单体结构转向微服务架构的主要原因在于应对现代复杂、快速变化的业务需求时，单体架构暴露出的一系列挑战和限制。以下是转向微服务架构的主要优势：

独立部署：在单体架构中，任何一个部分的修改或更新都可能需要重新部署整个应用，而在微服务架构中，每个服务都可以独立开发、测试、构建和部署，提高了部署效率和迭代速度。
可扩展性：微服务架构允许对各个服务进行独立水平扩展，即可以根据各服务的实际负载情况来分配资源，无需因为某个模块的性能瓶颈而整体扩容。
技术异构：团队可以选择最适合每个服务的技术栈，避免了单体应用中“一揽子”技术决策带来的局限性。
高可用性：单一服务的故障不会导致整个系统瘫痪，增强了系统的容错性和韧性。
敏捷开发与持续集成：微服务支持小型自治团队独立负责一个服务，有利于实现快速响应变更，提升开发效率和业务创新能力。
易于理解与维护：每个微服务专注于完成特定业务功能，代码量较小，更易于理解和维护。
更好的资源隔离：微服务架构有助于资源的有效利用和成本控制，避免资源浪费。

这些优势也是单体应用存在的问题。

2.2 微服务架构

微服务是一种架构模式，也是模块化的一种形式，它提倡将单一应用程序划分成一组小的服务，每个服务运行在其独立的自己的进程中，服务之间互相协调、互相配合，为用户提供最终价值。

微服务架构模式存在于前、后端服务的设计和实现过程中。后端我们较为熟悉。

2.1.1 微服务通用架构图

此处的微服务通用架构图指的是后端微服务架构。图中描述的是基于Spring Cloud产品绘制的架构图。图中只用到的部件主要来自阿里，也写出了可替换的部件。

【服务治理①】软件架构服务治理的本质，当下最火的微服务到底是什么？利用AIGC学习微服务的第①弹,微服务,dubbo,rpc,微服务,springcloud
可编辑的源文件参见这里。
PS：后续架构图中前端部分可以增加相关部件图。

【服务治理①】软件架构服务治理的本质，当下最火的微服务到底是什么？利用AIGC学习微服务的第①弹,微服务,dubbo,rpc,微服务,springcloud

2.1.2 微服务架构组成

2.1.2.1 注册中心Nacos

Nacos官方文档，文档介绍相当详细。这里就简单地介绍这个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。用了该平台后，能够简化服务发现、配置管理、服务治理及管理的解决方案，让微服务的发现、管理、共享、组合更加容易。

除了基本的功能外，Nacos通过SPI机制利用插件扩充其功能。

插件一览表

插件名称	描述	版本推荐
鉴权	验证谁是否能够对某个东西进行某种操作，因此Nacos在设计鉴权插件时，将鉴权信息主要抽象为身份信息，资源和操作类型3类主要概念。	2.1.0+版本
配置加密	保证用户敏感配置数据的安全	老版本暂时不兼容，目前只基于2.x版本进行了改造，推荐版本 > 2.0.4
多数据源	现在的多数据源插件通过SPI机制，将SQL操作按照数据表进行抽象出多个Mapper接口，Mapper接口的实现类需要按照不同的数据源编写对应的SQL方言实现; 现在插件默认提供Derby以及MySQL的Mapper实现，可直接使用；而其他的数据源则需要用户使用数据源插件进行加载。	2.2.0+版本
轨迹追踪	Nacos 的轨迹追踪不同于一般意义的链路追踪，主要目的是追踪和记录一些Nacos的相关操作，如服务注册、注销、推送、状态变更等，并非追踪微服务间的相互访问链路，如需要监控追踪服务间的相互访问，请使用对应的链路追踪项目。	2.2.0+版本
反脆弱	反脆弱是对访问服务端的某种资源的频率和次数达到一定程度时进行的限制访问的策略，用于保护服务端在高压情况下能快速拒绝请求，防止过多的资源访问导致服务端资源耗尽引起的大面积不可用。	2.3.0+版本
配置变更	支持通过SPI注入配置变更插件，允许用户通过自定义插件的方式，对配置变更前，和变更完成后分别执行一些自定义逻辑，如格式校验，白名单校验，webhook等。	2.3.0+版本
自定义环境变量	可通过SPI机制注入自定义环境变量实现插件，在插件中自定义nacos的配置，并按照您期望的方式进行处理（如数据库密码加密）。	2.2.0+版本

2.1.2.2 路由器Spring Cloud Gateway

这里我们不把Spring Cloud Gateway部件称为网关，把它视为路由器更好理解。
其功能有：
在微服务架构中，Spring Cloud Gateway作为API网关，扮演着至关重要的角色，其重要性体现在以下几个方面：

统一入口：
- Spring Cloud Gateway作为微服务架构的统一入口点，所有客户端请求首先经过网关，简化了外部调用接口，实现了服务消费者与内部服务之间的解耦。
- 所有对外提供的API和服务可以通过网关进行统一管理和暴露，便于进行安全策略、流量控制和认证授权等操作。
路由转发：
- Gateway能够根据预先定义的规则进行智能路由，将请求透明地分发到后端不同的微服务实例上。这使得微服务之间的调用关系对于外部用户而言是隐藏的，并且可以根据服务版本或者路径等条件动态路由。
安全性增强：
- 网关可以整合多种安全机制，例如集成OAuth2、JWT等进行身份验证和授权，同时还可以实施IP黑名单、白名单策略、频率控制等安全措施。
流量控制与熔断：
- Gateway支持各种过滤器链，可用于限流、熔断、重试等高级流量控制功能，从而保护后端服务免受过载冲击，保证服务的整体稳定性。
协议转换与适配：
- 在不同微服务之间可能存在协议不一致的问题，网关可以承担协议转换的角色，确保前后端交互的一致性。
监控与日志聚合：
- 网关层可以集中处理访问日志、跟踪请求链路，并对接监控系统，便于对整个系统的运行状态进行实时监控和问题排查。
服务编排与服务降级：
- 在复杂场景下，网关可以进行服务编排，组合多个服务响应客户端请求，同时也能在服务出现问题时执行服务降级策略，确保核心业务不受影响。

这个看起来就和Nginx功能类似。二者侧重点不同罢了。

2.1.2.3 接口调用客户端Feign

在微服务架构中，Feign 是一个用于简化服务间 HTTP 调用的声明式伪客户端。它的核心作用和意义体现在以下几个方面：

简化服务调用：
- 使用 Feign 时，开发者只需定义一个接口，并在接口方法上添加注解，以描述目标服务的 RESTful API。这样，服务间的调用就像调用本地方法一样简单，极大地简化了服务间交互的代码编写。
统一的服务发现与负载均衡：
- Feign 默认集成了 Ribbon，这意味着它可以自动利用服务注册中心（如 Eureka）进行服务发现，并在内部进行负载均衡选择目标服务实例，无需显式处理服务器列表和轮询逻辑。
声明式编程：
- 通过注解，可以直接指定请求方法、路径、参数映射等，从而将复杂的 HTTP 请求细节抽象化，使代码更加简洁且易于阅读和维护。
插件化与可扩展性：
- Feign 支持自定义编码器和解码器，允许开发者针对不同的数据格式（如 JSON、XML 等）进行定制；同时，它还可以和其他中间件（如 Hystrix，用于熔断和降级处理）配合使用。

工作原理：

当通过 Feign 定义的接口进行调用时，Feign 会利用 Java 动态代理机制生成一个代理对象，这个代理对象会在运行时拦截接口方法调用，将其转换为对应的 HTTP 请求。
方法的参数会被序列化为请求体或查询参数，根据注解配置决定请求方法、URI、Header 等属性。
发送请求后，Feign 会等待接收 HTTP 响应，并将响应内容反序列化为接口方法期望的返回类型。
如果配置了熔断器或其他策略，Feign 还能确保在遇到远程服务不可用或超时时能够优雅地处理异常，提高系统的稳定性。

2.1.2.4 分布式调度任务框架XXL-JOB

Sentinel官方文档
Sentinel 是面向分布式、多语言异构化服务架构的流量治理组件，主要以流量为切入点，从流量路由、流量控制、流量整形、熔断降级、系统自适应过载保护、热点流量防护等多个维度来帮助开发者保障微服务的稳定性。
【服务治理①】软件架构服务治理的本质，当下最火的微服务到底是什么？利用AIGC学习微服务的第①弹,微服务,dubbo,rpc,微服务,springcloud

2.1.2.5 分布式调度任务框架XXL-JOB

官网介绍
在其1.3章节有充分的介绍，该框架已经被多家知名公司使用，其可靠性经过验证。
【服务治理①】软件架构服务治理的本质，当下最火的微服务到底是什么？利用AIGC学习微服务的第①弹,微服务,dubbo,rpc,微服务,springcloud

2.1.2.6 链路追踪SkyWalking

Apache SkyWalking 是一个针对微服务架构、云原生环境和大数据平台设计的应用性能监视（APM）和可观测性分析平台。其主要功能包括服务追踪、性能指标收集、分布式系统拓扑分析以及故障诊断等。
【服务治理①】软件架构服务治理的本质，当下最火的微服务到底是什么？利用AIGC学习微服务的第①弹,微服务,dubbo,rpc,微服务,springcloud

2.1.3 理性认识微服务

正如克里斯·理查森在《微服务架构设计》一书中提了5点忠告，告诉我们要正确认识微服务。

要记住微服务不是解决所有问题的万能 “银弹” 。
编写整洁的代码和使用自动化测试至关重要，因为这是现代软件开发的基础。
关注微服务的本质，即服务的分解和定义，而不是技术，如容器和其他工
具。
确保你的服务松耦合，并且可以独立开发、测试和部署，不要搞成分布式单体(Distributed Monolith)，那将会是巨大的灾难。
也是最重要的，不能只是在技术上采用微服务架构。拥抱DevOps的原则和实践，在组织结构上实现跨职能的自治团队，这必不可少。

三、扩充知识：微前端

在前端设计中，虽然不存在专门的“微服务框架”，但是微服务架构对前端设计有着一定的影响。以下是一些与前端设计相关的微服务概念和实践：

API Gateway：在微服务架构中，通常会使用 API 网关来作为前端和后端服务之间的接口。API 网关可以负责请求路由、负载均衡、认证授权等功能，从而简化前端与多个微服务之间的交互。
服务拆分与前端组织：微服务架构鼓励将功能拆分成独立的服务。在前端设计中，可以借鉴这种思想，将大型的前端应用拆分成独立的模块或组件，每个模块负责一部分功能，提高代码的可维护性和可扩展性。
前后端分离：微服务架构通常采用前后端分离的模式，即前端和后端通过 API 进行通信。这种模式使得前端可以独立于后端进行开发和部署，提高了开发效率和灵活性。
无服务器架构（Serverless）：虽然 Serverless 不等同于微服务，但它与微服务有相似之处，即将功能分解成更小的单元。在前端设计中，可以结合 Serverless 技术，如云函数等，实现更灵活的前端功能扩展。
微前端：微前端是一种类似于微服务的设计理念，它将一个大型的前端应用拆分成多个小型的子应用，每个子应用可以独立开发、部署和运行。微前端架构有助于提高大型前端项目的可维护性和团队协作效率。

微前端技术在大型的互联网公司应用很广泛。

微前端框架有Single-spa、qiankun、micro-app和wujie-micro等。

微前端是一种架构模式，它允许将一个大型的前端应用拆分成多个小型的子应用，每个子应用可以独立开发、部署和运行。这种架构模式有助于提高大型前端项目的可维护性和团队协作效率。目前，有几个流行的微前端框架可供选择，具体如下：

Single-spa：它是最早的微前端框架之一，以其兼容性强和维护成本低而受到欢迎。它支持多种前端技术栈，并允许开发者将多个单页面应用聚合在一起。
qiankun：由蚂蚁金服团队开发，它是一个基于微前端理念的框架，旨在帮助开发者更好地实现应用的拆分和集成。
micro-app：来自京东零售团队，这个框架提供了一套解决方案，用于在微前端架构中管理和部署子应用。
wujie-micro：由腾讯无界低代码团队开发，它也是一个微前端框架，旨在简化子应用的集成和管理过程。

四、其它出色的微服务典范产品——Apache Dubbo

Dubbo的流行可以追溯到2008年，当时由阿里巴巴开源，迅速在中文社区中获得关注。以下是Dubbo流行的一些关键时期和因素：

阿里巴巴内部使用：在Dubbo开源之前，它已经在阿里巴巴内部得到了广泛的应用，处理了大量的服务调用，因此在真实的高并发、高可用性环境中经过了长期的检验。
开源社区的支持：Dubbo的开源使得更多的开发者能够接触到这个框架，并且由于其高性能和易用性，逐渐在社区中积累了一定的口碑。
服务化架构趋势：随着服务化架构的兴起，越来越多的企业开始将原有的系统拆分成多个微服务，Dubbo作为RPC框架，提供了服务间通信的解决方案，因此得到了快速推广。
性能和稳定性：Dubbo在性能和稳定性方面表现出色，这使得它在金融、电商等对稳定性要求极高的行业中得到了广泛应用。
丰富的生态和社区：Dubbo拥有一个活跃的社区，不断有新的功能和优化被提交到主分支，同时也有大量的文档和教程帮助新手学习和使用。
跨语言支持：虽然Dubbo主要是为Java服务之间的调用设计的，但它也支持其他语言的客户端，这使得它能够覆盖更广泛的使用场景。
企业认可：许多大型企业，特别是中国的互联网和金融公司，选择Dubbo作为其内部服务调用的标准，进一步推动了Dubbo的流行。
国际化：随着Dubbo的国际化进程加快，越来越多的国际开发者开始了解和使用Dubbo，使其成为全球范围内知名的开源项目之一。