02-微服务基础

nobility 发布于 2025-06-24 00-分布式概念 2367 次阅读


微服务基础

微服务概念

单体应用具有:部署效率低下、团队协作开发成本高 、系统高可用性差的缺点。所以将传统单体应用中的本地方法调用,改造成通过RPC、HTTP产生的远程方法调用,从而将模块从单体应用中拆分出来,独立成一个服务部署,也就是说可以将某个模块单独开发、测试、上线和运维,可以交由专门的团队来做,从而与主模块解耦

微服务是一种架构风格,开发单体应用作为一系列小型服务的套件,其中每个服务都运行中自己的进程中,并且通过轻量级的机制实现彼此间的通信,这通常是HTTP资源API接口,这些服务是围绕着业务功能构建的,并且可以通过完全自动化的部署机制进行独立部署,这些服务的集中式管理做到了最小化(比如docker),每一种服务都可以通过不同的编程语言和数据存储技术

微服务的特点

  • 组件以服务形式来提供:以独立部署的服务来作为一个一个的组件,而不是提供像类库这样的本地调用形式,所以就需要明确组件之间的接口和通讯协议
  • 是产品而非项目:与用户联系更加紧密,要对产品的整个生命周期去负责
  • 轻量级通讯、独立进程:更加倾向于Restful HTTP、RPC、消息队列等
  • 分散治理、去中心化治理:将单体框架中组件拆分为不同的服务,所以在构建时比较分散,这就意味着责任下放,单独的模块就需要专人负责,所以就需要报警机制等监控手段来保证服务的健康
  • 容错性设计:每一个服务都是独立的,所以需要为每一个单独的服务提供日常故障检测
  • 组织架构的调整:从职能团队(前端、后端、DBA、测试)分割为业务团队(支付业务、用户业务)

微服务的优缺点

优点 缺点
服务简单、便于学习和上手,相对容易维护 架构复杂度高,运维成本高
独立部署,扩展灵活 接口可能不匹配
技术栈丰富 代码可能重复

微服务的技术选型

  • SpringCloud:成熟的微服务框架系列,具有众多子项目
  • dubbo:高性能、轻量级的开源Java RPC框架,提供的能力只是SpringCloud的子集,主要提供了三大核心能力:面向接口远程方法调用,智能容错和负载均衡,服务自动注册和发现

区别如下:

Dubbo Spring Cloud
服务注册中心 Zookeeper Spring Cloud Netflix Eureka
服务调用方式 RPC REST API
服务网关 无 Spring Cloud Netflix Zuul
断路器(熔断器) 不完善 Spring Cloud Netflix Hystrix
分布式配置 无 Spring Cloud Config
服务跟踪 无 Spring Cloud Sleuth
消息总线 无 Spring Cloud Bus
数据流 无 Spring Cloud Stream
批量任务 无 Spring Cloud Task
RPC
  • 优点:整体效率比较高,传输同样体量的内容所消耗的网络流量也比较小,速度也会更快
  • 缺点:服务提供方与调用方接口依赖方式太强,因为Dubbo不是一种通用的RPC协议,想要调用时必须要找到对应的依赖,相当于在代码级别进行强依赖;服务对(语言)平台敏感,难以简单复用,必须再额外实现一层代理将RPC接口转换为HTTP才能对外发布

微服务拆分和扩展

拆分

项目开发的初期阶段,主要目标是快速开发和验证想法,后面增加更多的新特性来吸引更多的目标用户

  • 一般当单体项目的同时开发的人员超过某个数字时,比如10个就可以考虑服务化的拆分了
  • 但是如果项目流量不高,压力不大,业务变化不大的情况下无需进行微服务的拆分
  • 对于延迟很敏感的低延迟高并发系统,由于微服务而言通讯时延要比单体应用高,所以也不一定需要拆分

微服务拆分的主要有如下两种方式:

  • 纵向拆分:按照业务纬度进行拆分
  • 横向拆分:按照公共领域拆分

扩展

根据CPU负载程度、特定时间、消息队列长度、业务规则、预测等来决定自动按需分配新的服务实例,从而提高可用性和可伸缩性,达到最佳的使用率,节约成本,服务扩展的三个维度如下:

  • 水平复制:负载均衡多应用(可能存在资源浪费)
  • 功能解耦:微服务的拆解
  • 数据分区:分库分表
加油啊!即便没有转生到异世界,也要拿出真本事!!!\(`Δ’)/
最后更新于 2025-06-24