专栏首页洁癖是一只狗分布式服务架构(一)

分布式服务架构(一)

JEE是Java平台企业化的简称,如上就是JEE时代的典型架构,分为web层,业务逻辑层,以及数据存储层,不同层级有自己的职责,每个层级职责单一

虽然JEE对单体应用进行了分层,但是久而久之,随着业务的复杂逻辑迭代增加,以及开发人员的流动,新手可能没有遵循规范,最终还是会导致数据存取之间的耦合性增加,最后导致组件与组件之间难以划分,且大多数还是在一个应用服务器上跑在一个JVM进程中,

MVC框架将用户交互划分为视图,模型和控制器三大块,如上图,

在JEE开始流行还没有完全奠定地为时候,开发软件struts,spring,Hibernate开始流行,很快成为了企业开发的标配(SSH).而SHH时代的架构如下

很明显SSH框架和传统JEE架构类似,可分为三层,实现交互UI接口的Web Mvc层,实现业务员逻辑层Spring层,以及对象关系映射层Hibernate层,每层都比JEE对应的层次简单,更加轻量,不需要开始整个应用服务器即可验证和测试,极大提高了效率这都是spring 的功劳

但是这中架构还是取向于传统的单体应用,业务逻辑耦合在一个项目中。

服务化架构

随着互联网快速突起环境下,传统的架构不能满足海量用户发起的高并发请求,无法突破耦合在一起的模块组件的性能瓶颈,且水平扩展也是很有限。

为了解决上面问题,引入了SOA,俗称服务化,

SOA,将应用之间模块化组件通过定义明确的接口和契约联系起来,接口是采用中立的方式定义,独立于语言开发,硬件,操作系统,通常通过网络通信完成,但不局限与某种网络协议,可以是底层TCP/IP.也可以是应用层的HTTP,也可以是消息队列协议。

而SOA的主流实现有两种,WEB Service和ESB

WEB Service

每个服务对等,并且相互解耦,通过WSDL协议定义的服务发现接口进行访问,并通过SOAP协议进行通信,SOAP协议通常是一种在HTTP或者HTTPS通道上传输XML数据实现协议,但是每个服务都要依赖中心化WEB Service目录发现存在的服务,通过web service目录发现现有服务,并最大限度的重用现有服务。

ESB

ESB是企业服务总线的简称,用于设计和实现网路化服务交互和通信的软件模型,是SOA的另外一种实现。

ESB服务没有中心化服务的服务节点,每个服务提供者都可以通过总线的模型插入系统,总线根据流程的编排负责将服务的输出进行转换并发送给流程要求的下一个服务进行处理。

企业总线是ESB的核心要素,所有服务都可以在总线上插拔,并通过总线的流程编排和协议转接能力来组合实现业务处理能力。

微服务

前面说的SOA服务系统能够分解任务,让每个服务更简单,职责单一,更易扩展,但是不论是Web service服务还是ESB总线,都有一些问题

Web Service

  • 依赖中心化的服务发现机制
  • 使用SOAP通信协议,通常使用XML格式来序列化通信数据,XML格式数据冗余太大,协议太重
  • 服务化管理和治理设施并不完善

ESB

  • ESB虽然是SOA实现的一种,却更多的体现了系统集成的便利性,通过统一的服务总线服务组合在一起,并提供组合的业务流程服务
  • 组合在ESB上的服务本身可能是一个过重的整体服务,或者是传统的Jee服务,
  • ESB通过总线隐藏系统内部的复杂性,但是系统内部的复杂性依然存在
  • 总线本身的中心化的管理模式,系统变更影响范围经常随之扩大

而微服务倡导就是应用可以独立开发,可配置,可运行和维护的子服务,子服务之间通过良好的接口定义通信机制,通常是RestFul风格的api形式来通信,可以使用HTTP或HTTPS通信上传输json格式的数据来实现,HTTP具有跨语言,跨异构系统的优点,当然也可以底层的二进制和消息队列协议等进行交互,每个服务功能自治,且可以使用不同的语言

微服务和传统单体架构的对比

微服务职责单一,独立的服务,每个服务单独运行一个进程,且有自己的数据库,每个服务自治,每个服务可根据需求独立的进行对外水平伸缩。

传统架构运行在单一的jvm进程,整个业务Jvm水平扩展,不能业务组件进行扩展,模块间的依赖将不会氢气,互相耦合,互相依赖是常态

微服务和SOA服务化对比

微服务和SOA是一脉相承,微服务是SOA的延续,SOA理念在微服务架构中任然有效,微服务是在SOA服务化的基础上进行了严谨和叠加。

但是他们却略不一样

  • 目的不同

SOA服务化涉及的范围更广,强调不同的异构服务之间的协作和契约,并强调有效的继承和业务流程编排,而微服务是拆分服务,是服务敏捷开发和部署,减少团队的沟通,更容易扩展

  • 部署方式不同 微服务是每个业务组件可以互相对立部署,而SOA是将业务组件打包一个war包,然后统一在一个应用服务器上
  • 服务粒度不同 微服务拆分成更细粒度的服务,服务之间组合的形式进行处理业务流程,而SOA对粒度没有要求,实践中服务往往是粗粒度的,强调接口契约的规范化,内部可能是更粗粒度的划分

微服务的分解和组合模式

服务代理模式

聚合模式

串行模式

服务分支模式

服务异步消息模式

服务共享模式

微服务容错模式

由于服务之间不再是进程内的调用,而是通过网络进行远程调用,当网络通信不稳定或不可靠,一个服务依赖的服务可能出错,超时或者宕机,如果没有及时发现或隔离问题,没有考虑如何应对这种问题,那个最终可能导致服务雪崩,所以采用哪些措施方案来解决

肠壁隔离模式

正如一艘船遇到意外,而其中一个船舱进了水,我们就希望不会影响其他船舱即船舱之间想不隔离,其他船舱不受影响.

  • 微服务容器分组

将微服务分切灰度分组和准生产环境,生产环境,灰度环境跑一些普通商户的流量,生产环境跑一些vip用户,准生产环境用于测试使用,如果进行大的重构,我们可以充分利用灰度环境进行验证问题。

  • 线程池隔离

往往我在服务中将多个功能在一个服务实例中,这个微服务的不同功能使用同一个线程池,导致一个功能流量增加耗尽线程池的线程,而阻塞其他功能服务

熔断模式

相当于家中的保险丝,当电流过大,自动关闭跳闸,起到保护整个电路系统,

限流模式

计数器

计数器,我们的目的就是在一分钟以内,最高的请求为100个,但是如上图,如果有恶意用户在0:59秒的时候发送了100个请求,在1:00分钟时候也发送了100个请求,此时在一秒钟就要了200个请求,就可能压垮我们的服务

因此我采用滑动窗口的算法,降低这种情况

我们将一分钟分为6个格,每过10秒向前移动一格,每个格都有自己的计数器,当6个格子加载一起超过了限制,就会触发限流,

比如,当0:59到达100请求到了灰色的格子,而1:00的时候又来了100个请求,那么我们的窗口(即6个格子)向右移动一格,滑动窗口的数量为200,大于100个,所以触发了限流

令牌桶

他是通过一个线程在单位时间内生产固定数量的令牌,然后把令牌放入到队列,每次请求需要从桶里拿取一个令牌,拿到令牌后才有资格执行请求调用,否则直接放弃,或者等到拿到令牌在执行,

由于令牌桶有固定大小,当请求速度小于令牌生成速度,令牌桶就会被填满,所以令牌桶能够处理突发流量,也即使短时间内新增的流量系统能够正常处理

漏桶限流算法

主要是控制数据注入网络的速度,平滑网络上的突发流量

漏桶无法处理短时间内的突发流量,漏桶限流算法是一种恒定速度的限流算法

失效转移模式

若服务架构发生了熔断和限流,则应该处理拒绝的请求呢,解决这个问题叫做失效转移模式

  • 采用快速失败策略,直接返回服务错误,让使用方知道发生问题并自行解决问题
  • 使用备份,如果有备份服务,则迅速切换到备份服务
  • 失败的服务可能只是某一台,不是所有,例如发生OOM,这种情况下适合使用failover策略,采用重试的方法来解决,但是这种方法要求服务提供者的服务实现了幂等性

本文分享自微信公众号 - 洁癖是一只狗(rookie-dog),作者:洁癖汪

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2021-06-21

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 分布式系统(微服务架构)的一致性和幂等性问题相关概念解析

    什么是分布式系统?关于这点其实并没有明确且统一的定义。在我看来,只要一个系统满足以下几点就可以称之为分布式系统

    java架构师
  • 分布式系统、微服务架构的一致性和幂等性问题相关概念解析

    什么是分布式系统?关于这点其实并没有明确且统一的定义。在我看来,只要一个系统满足以下几点就可以称之为分布式系统

    lyb-geek
  • 分布式服务架构(二)

    具有ACID的数据库支持强一致性,强一致性代表数据库本身不会出现不一致的线性,每个事务都是原子性,要么成功,要么失败,事物间具有隔离性,且互不影响,而且最终状态...

    小土豆Yuki
  • 再谈分布式服务架构

    在两年前,我曾经设计过一版,高可伸缩服务器架构, 但只进行了理论推演,并没有使用具体业务逻辑验证过。以这两年的经验来看,这个架构不具备可实施性。

    重归混沌
  • 一个分布式服务器集群架构方案

    Java高级架构
  • 微服务架构下分布式事务方案

    微服务倡导将复杂的单体应用拆分为若干个功能简单、松耦合的服务,这样可以降低开发难度、增强扩展性、便于敏捷开发。当前被越来越多的开发者推崇,很多互联网行业巨头、开...

    技术zhai
  • 微服务架构下分布式事务方案

    微服务倡导将复杂的单体应用拆分为若干个功能简单、松耦合的服务,这样可以降低开发难度、增强扩展性、便于敏捷开发。当前被越来越多的开发者推崇,很多互联网行业巨头、开...

    技术zhai
  • 微服务架构 (九): 分布式微服务下的数据一致性

    2016.8.21, 深圳, Ken Fang 微服务都拥有各自的数据库且微服务都是部署在一分布式的环境下的。所以, 微服务间要维持彼此间数据库中的数据的一致性...

    Ken Fang 方俊贤
  • 微服务架构下分布式Session管理

    一、应用架构变迁下的Session管理 1.1 单体架构 1.2 分布式架构 1.3 微服务架构 二、微服务架构下分布...

    yuanyi928
  • 分布式微服务架构概述初探

    微服务架构(MSA)的起源应该要追溯到国外著名架构师Martinfowler于2014年编写的一篇博文中,其中阐述了微服务架构的整体设想。他用这样一句话概述了对...

    IMWeb前端团队
  • Spring Cloud构建微服务架构:分布式服务跟踪(入门)

    通过之前的N篇博文介绍,实际上我们已经能够通过使用它们搭建起一个基础的微服务架构系统来实现我们的业务需求了。但是,随着业务的发展,我们的系统规模也会变得越来越大...

    程序猿DD
  • 架构设计:分布式结构下,服务部署发布

    分布式系统架构下,服务发布是一件很麻烦的事情,特别是在构建自动发布流程和灰度测试的策略两个核心方面。通常情况下如果不涉及数据层面的灰度流程,服务可以灰度上线,或...

    知了一笑
  • 架构解密分布式到微服务:架构实践DIY一个有难度的分布式集群

    本节的目标,是不依赖任何分布式框架和中间件,全程“手工”设计、开发一个有难度的分布式集群MyCluster,以提升自我的硬核架构能力,具体的技术要求如下。

    IT大咖说
  • (四)整合spring cloud云服务架构 - 企业分布式微服务云架构构建

    今天正式给大家介绍了Spring Cloud - 企业分布式微服务云架构构建,我这边结合了当前大部分企业的通用需求,包括技术的选型比较严格、苛刻,不仅要用业界最...

    用户7788846
  • 分布式服务框架 Zookeeper

    转自http://www.ibm.com/developerworks/cn/opensource/os-cn-zookeeper/ 安装和配置详解 本文介绍的...

    老白
  • 分布式服务框架gRPC

    gRPC是Google开发的高性能、通用的开源RPC框架,其由Google主要面向移动应用开发并基于HTTP/2协议标准而设计,基于Protobuf(Proto...

    KevinYan
  • (一)spring cloud微服务分布式云架构 - Spring Cloud简介

    Spring Cloud是一系列框架的有序集合。利用Spring Boot的开发模式简化了分布式系统基础设施的开发,如服务发现、注册、配置中心、消息总线、负载均...

    用户7788846
  • 从单体架构到分布式微服务架构的思考

    单体架构也可叫单体系统或单体应用,是一种把系统所有的功能模块耦合在一个应用的架构方式。

    呆呆
  • 微服务架构有哪些分布式问题?

    微服务架构的技术体系、社区目前已经越来越成熟。在最初系统架构的搭建,或者当现有架构已到达瓶颈需要进行架构演进时,很多架构师、运维工程师会考虑是否需要搭建微服务架...

    CSDN技术头条

扫码关注云+社区

领取腾讯云代金券