微服务-优缺点/模块介绍

微服务架构是一种将单一应用程序划分为一组小服务的架构模式,强调服务间的独立性和松耦合。与SOA相比,微服务更注重技术的多样性,但其运维成本增加,自动化部署成为挑战。Spring Cloud和Dubbo是常见的微服务框架,API Gateway解决服务查找问题,而面对服务故障,重试、限流、熔断和降级机制是关键。微服务涉及的模块包括持续构建、日志聚合、监控和测试等。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >


分布式:分散压力。
微服务:分散能力。

微服务不是偶然,是多重因素推动下的必然产物 -----<微服务架构与实践>

微服务技术栈

https://blog.youkuaiyun.com/weixin_42358062/article/details/80730782

1-什么是微服务?

微服务架构是一种架构模式,它提倡将单一应用程序划分成一组小的服务,服务之间相互协调、互相配合,为用户提供最终价值。
微服务的目的是有效的拆分应用,实现敏捷开发和部署

主要特征:

  • 粒度小,专注一件事情(单一职责)
  • 单独的进程
  • 服务之间轻量级通信机制(通常是基于HTTP的Restful API).
  • 松耦合,可以独立部署

特征带来优势:

1:提升开发交流,每个服务足够内聚,足够小,代码容易理解;
2:服务独立测试、部署、升级、发布;
3:容易扩大开发团队,可以针对每个服务(service)组件开发团队;
4:提高容错性(fault isolation),一个服务的内存泄露并不会让整个系统瘫痪;
5:etc

双刃剑:

1:开发人员要处理分布式系统的复杂性
2:服务之间的分布式通信问题,IPC进程间通信问题,通信机制需要完备可靠(一对一,一对多)
3:服务的注册与发现问题(两层API geteway,用户-系统,服务之间)
	ZK: 是一个广泛使用,为分布式应用提供高性能整合的服务。
	Apache ZooKeeper最初是Hadoop的子项目,现在已经变成顶级项目。
4:服务之间的分布式一致性问题;服务之间的分布式事务问题
5:数据隔离再来的报表处理问题;
6:服务管理的复杂性,服务的编排;不同服务实例的管理。

2-Differences of 微服务与SOA

微服务是传统SOA的一个子集
微服务,从本质意义上看,还是 SOA 架构。但内涵有所不同,微服务并不绑定某种特殊的技术,在一个微服务的系统中,可以有 Java 编写的服务,也可以有 Python编写的服务,他们是靠Restful架构风格统一成一个系统的。所以微服务本身与具体技术实现无关,扩展性强。

对此,解释SOA
面向服务的架构(SOA)是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互

3-Not suitable for 微服务

微服务可以按照业务功能本身的独立性来划分,如果系统提供的业务是非常底层的,如:操作系统内核、存储系统、网络系统、数据库系统等等,这类系统都偏底层,功能和功能之间有着紧密的配合关系,如果强制拆分为较小的服务单元,会让集成工作量急剧上升,并且这种人为的切割无法带来业务上的真正的隔离,所以无法做到独立部署和运行,也就不适合做成微服务了。

微服务运维成本:每个服务的运维成本指数级增长

1.配置 :配置信息,依赖,端口,数据库地址
2.部署 : 将应用部署到指定的环境中
3.监控与告警 :
4.日志收集

微服务自动化部署部署频率加大,自动部署流水线是挑战

4-微服务框架 framework

  • Spring Cloud:http://projects.spring.io/spring-cloud (现在非常流行的微服务架构)
  • Dubbo:http://dubbo.io ()现在非常流行的微服务架构)
    在这里插入图片描述
  • Dropwizard:http://www.dropwizard.io (关注单个微服务的开发)
  • Consul、etcd&etc.(微服务的模块)

5-API Gateway

用户访问系统的API gateway
* 提供统一服务入口,让微服务对前台透明
* 聚合后台的服务,节省流量,提升性能
* 提供安全,过滤,流控等API管理功能
服务之间的API gateway-IPC进程间通信
* REST(JAX-RS,Spring Boot) 各个语言都能支持,同时能跨客户端,对客户端没有特殊的要 求,只要封装了HTTP的SDK就能调用
* RPC(Thrift, Dubbo) 传输协议更高效,安全更可控
* 异步消息调用(Kafka, Notify)

6- 这么多服务怎么查找?

(服务注册)

服务注册中心是服务发现的核心。
ip和端口号放在注册中心
zookeeper —— 在分布式应用中被广泛使用,高性能的协调服务。
Apache Zookeeper 最初为Hadoop的一个子项目,但现在是一个顶级项目。

(服务发现)

一个服务随时可能下线,也可能应对临时访问压力增加新的服务节点。
服务之间如何相互 感知?服务如何管理?这就是服务发现的问题。
并通过心跳维持长链接,实时更新链接信息。
当服务下线时,ZK会发通知给服务客户端。

在这里插入图片描述

在这里插入图片描述

7-服务挂了

重试机制
限流
熔断机制
负载均衡
降级

8-微服务模块

  • CI持续构建
  • 日志聚合
  • 监控与告警Nagios
  • 持续交付
  • 轻量级通信(同步/异步)
  • 测试

更多概念

RPC远程调用

RPC 的全称是 Remote Procedure Call 是一种进程间通信方式。
它允许程序调用另一个地址空间(通常是共享网络的另一台机器上)的过程或函数,而不用程序员显式编码这个远程调用的细节。即无论是调用本地接口/服务的还是远程的接口/服务,本质上编写的调用代码基本相同。
比如两台服务器A,B,一个应用部署在A服务器上,想要调用B服务器上应用提供的函数或者方法,由于不在一个内存空间,不能直接调用,这时候需要通过就可以应用RPC框架的实现来解决

restful、soap、rpc

(1)restful是一种架构设计风格,提供了设计原则和约束条件,而不是架构。而满足这些约束条件和原则的应用程序或设计就是 RESTful架构或服务。
(2)soap象访问协议是一种数据交换协议规范,
是一种轻量的、简单的、基于XML的协议的规范。SOAP协议和HTTP协议一样,都是底层的通信协议,只是请求包的格式不同而已,SOAP包是XML格式的。

soap

基于xml并封装成了符合http协议,因此,它符合任何路由器、 防火墙或代理服务器的要求。
soap可以使用任何语言来完成,只要发送正确的soap请求即可,基于soap的服务可以在任何平台无需修改即可正常使用。
(3)RPC就是从一台机器(客户端)上通过参数传递的方式调用另一台机器(服务器)上的一个函数或方法(可以统称为服务)并得到返回的结果。
RPC 会隐藏底层的通讯细节(不需要直接处理Socket通讯或Http通讯)
RPC 是一个请求响应模型。客户端发起请求,服务器返回响应(类似于Http的工作方式)
RPC 在使用形式上像调用本地函数(或方法)一样去调用远程的函数(或方法)。

rpc远程调用框架

几种比较典型的RPC的实现和调用框架。
(1)RMI实现,利用java.rmi包实现,基于Java远程方法协议(Java Remote Method Protocol)
和java的原生序列化。
(2)Hessian,是一个轻量级的remoting onhttp工具,使用简单的方法提供了RMI的功能。 基于HTTP协议,采用二进制编解码。
(3)thrift是一种可伸缩的跨语言服务的软件框架。thrift允许你定义一个描述文件,描述数据类型和服务接口。依据该文件,编译器方便地生成RPC客户端和服务器通信代码。
(4)SpringCloud 为开发人员提供了快速构建分布式系统的一些工具,包括配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等。
(4) Dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架,使得应用可通过高性能的 RPC 实现服务的输出和输入功能,可以和 Spring框架无缝集成。

### 微服务架构的优点 1. **易于开发和维护** 每个微服务仅聚焦于单一业务功能,使得其逻辑清晰且代码量较少。这种特性简化了单个微服务的开发与维护工作,从而保持整个应用程序处于可控状态[^3]。 2. **快速启动** 单个微服务由于规模较小,因此相比传统单体应用具有更快的启动时间。 3. **局部修改与独立部署** 当某一微服务发生变更时,无需重新部署整个系统,只需更新受影响的服务即可。这种方式减少了因全局部署带来的风险,并提高了效率[^3]。 4. **技术支持多样化** 在微服务架构下,各组件可以选择最适合的技术栈来满足各自需求。例如,某些模块可能采用MySQL作为存储解决方案,而其他部分则利用Redis缓存数据;或者一部分由Java编写完成,另一些用Node.js实现[^5]。 5. **灵活扩展能力** 可依据实际需要对特定资源(如内存、CPU 或服务器节点)进行精细调整以应对不同压力情况下的性能瓶颈问题[^3]。 6. **增强容错性** 如果某项单独运行的服务出现了异常状况,则不会波及其他正常工作的部件,进而保障整体系统的稳定性并提升用户体验质量[^4]. 7. **促进敏捷迭代** 小型化的设计理念让产品能够更加迅速地响应市场需求变化,加快新特性的上线周期以及修复已知缺陷的速度[^4]. ### 微服务架构的缺点 1. **运维复杂度上升** 随着分解后的子系统增多,相应的管理工作也随之变得更加繁琐艰巨起来。不仅涉及到众多相互关联的部分之间的协调配合事宜,还包括诸如版本控制策略制定实施等方面的内容[^4]. 2. **通讯消耗增大** 各单元之间主要依靠远程调用来交换消息,这就不可避免地引入额外的时间延迟现象,并且一旦网络连接不稳定还可能导致请求失败等问题的发生概率增加[^4]. 3. **难以确保一致性的难题** 跨越多个分离出来的实体执行操作时很难做到完全同步更新所有相关联的数据记录条目,除非采取专门措施比如运用分布式事务处理机制或者其他补偿手段才行得通[^4]. 4. **加大测试负担** 对于包含大量互相依存环节的整体结构而言,进行全面覆盖性质的功能验证变得越来越不容易达成目标,尤其是考虑到每种语言框架都有自己的独特之处之后更是如此[^4]. 5. **初始投入成本高昂** 实施这样一种新型模式之前往往需要花费较长时间去规划蓝图图纸细节安排人员培训课程购置必要硬件设施等等准备工作才能正式启动项目进程[^5]. ```python # 示例代码展示如何通过Docker容器化技术解决部分微服务架构中的运维难点 import docker client = docker.from_env() def deploy_microservice(service_name, image_tag): try: container = client.containers.run( f"{image_tag}", name=f"{service_name}-container", detach=True, ports={'80/tcp': ('localhost',)} ) print(f"Successfully deployed {service_name} with ID: {container.id}") except Exception as e: print(f"Failed to deploy service due to error: {str(e)}") deploy_microservice('example-service', 'myrepo/example:v1') ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值