草庐IT

业务中台

全部标签

线上ES集群参数配置引起的业务异常案例分析

一、故障描述1.1故障现象1).业务反馈业务部分读请求抛出请求超时的错误。2).故障定位信息获取故障开始时间19:30左右开始故障抛出异常日志错误日志抛出timeout错误。故障之前的几个小时业务是否有进行发版迭代。未进行相关的发版迭代。故障的时候流量是否有出现抖动和突刺情况。内部监控平台观察业务侧并没有出现流量抖动和突刺情况。故障之前的几个小时Elasticsearch集群是否有出现相关的变更操作。Elasticsearch集群没有做任何相关的变更操作。1.2环境Elaticsearch的版本:6.x。集群规模:集群数据节点超过30+。二、故障定位我们都知道Elasticsearch是一个分

职场日常:测试人员如何快速熟悉新业务?

身处职场,学习新业务在所难免,尤其是测试人员,具备良好的业务知识是我们做好质量保障的前提,不管是职场「新人」还是「老人」,快速熟悉业务的能力都是不可或缺的,这是我们安身立命的根本。但,这样的能力并不是很显性,笔者有着十几年的测试经验,负责过C端、B端和G端的业务,本文尝试梳理出一些快速熟悉新业务的方法,希望能够带给大家一些启发。有两种学习模式在学习新业务时,通常有两种模式:授课式:老师/师兄/师姐带着你学习,言传身教划重点,苦口婆心加考试;自学式:自己看一堆的学习资料、测试沉淀、业务文档,有问题再找人问;授课式是被别人带着走,自学式是按自己的方式走。从人性的角度来讲,显然有人教更好,也更快,直

Activiti,Apache camel,Netflex conductor对比,业务选型

Activiti,Apachecamel,Netflexconductor对比,业务选型1.activiti是审批流,主要应用于人->系统交互,典型应用场景:请假,离职等审批 详情可见【精选】activti实际使用_activiti通过事件监听器实现的优势_记录点滴1076的博客-CSDN博客文章浏览阅读358次。目录:activiti6内容解析流程中心如何建设一.内容解析1.快速入门网址:https://blog.csdn.net/qq877507054/article/details/601430992.核心步骤:画流程图->生成bpmn文件(ACT_GE_BYTEARRY)部署流程图->

所有接口分类 作用详解 物理接口 管理接口 业务接口 逻辑接口

目录接口分类物理接口管理接口业务接口逻辑接口接口分类接口是设备与网络中的其它设备交换数据并相互作用的部件,分为物理接口和逻辑接口两类,其中:物理接口物理接口是真实存在、有器件支持的接口。物理接口分为管理接口和业务接口两种:管理接口管理接口主要为用户提供配置管理支持,也就是用户通过此类接口可以登录到设备,并进行配置和管理操作。管理接口不承担业务传输。设备支持的管理接口如表1所示:表1 各管理接口介绍接口名称接口描述接口用途Console口遵循EIA/TIA-232标准,接口类型是DCE。该接口和配置终端的COM串口连接,用于搭建现场配置环境。Console接口和MiniUSB接口互斥,同一时刻只

谷粒商城-分布式高级篇[商城业务-检索服务]

谷粒商城-分布式基础篇【环境准备】谷粒商城-分布式基础【业务编写】谷粒商城-分布式高级篇【业务编写】持续更新谷粒商城-分布式高级篇-ElasticSearch谷粒商城-分布式高级篇-分布式锁与缓存项目托管于gitee一、商城业务-检索服务确保gulimall-search服务开启注册中心并加入到nacos中gulimall-search服务下:1.1、搭建页面环境1.1.1、动静资源配置动静分离给gulimall-search服务加入依赖Thymeleaf依赖dependency>groupId>org.springframework.bootgroupId>artifactId>spring

Spring Event 业务解耦神器,大大提高可扩展性,刷爆了!

一、前言ApplicationContext 中的事件处理是通过 ApplicationEvent 类和 ApplicationListener 接口提供的。如果将实现了 ApplicationListener 接口的bean部署到容器中,则每次将 ApplicationEvent 发布到ApplicationContext 时,都会通知到该bean,这简直是典型的观察者模式。设计的初衷就是为了系统业务逻辑之间的解耦,提高可扩展性以及可维护性。Spring中提供了以下的事件:二、ApplicationEvent与ApplicationListener应用1.实现自定义事件类,基于 Applic

数据中台实战(00)-大数据的尽头是数据中台吗?

除了支撑集团的大数据建设,团队还提供ToB服务,因此我也有机会接触到一些正在做数字化转型的传统企业。从2018年末开始,原先市场上各种关于大数据平台的招标突然不见了,取而代之的是数据中台项目,建设数据中台俨然成为传统企业数字化转型的首选,甚至不少大数据领域的专家都认为,数据中台是大数据下一站。为啥数据中台是大数据的下站?与数仓、数据湖、大数据平台啥区别?来深入大数据发展史,先从数仓出现讲起,途径数据湖,再到大数据平台,这样才能理解大数据发展的每阶段的问题,深入理解数据中台在大数据发展中的历史定位。1数据仓库商业智能(BusinessIntelligence,BI)诞生在1990s,将企业已有数

数字化转型系列主题:数据中台知识体系

当前,大部分企业不再建设从源数据采集到分析应用的烟囱式系统,更倾向于数据集中采集、存储,并应用分层建设。这种方式一方面有利于应用系统的快速部署,另一方面也保证了数据的集中管理与运营,体现数据的资产、资源属性。笔者根据个人数据中台的工作实践和学习以及思考总结,撰写成本文数据中台知识体系。一.数据中台是什么01定义    数据中台是一套可持续“让企业的数据用起来”的机制,是一种战略选择和组织形式,是依据企业特有的业务模式和组织架构,通过有形的产品和实施方法论支撑,构建的一套持续不断把数据变成资产并服务于业务的机制    数据中台是处于业务前台和技术后台的中间层,是对业务提供的数据能力的抽象和共享的

金融业务系统:Service Mesh用于安全微服务集成

随着云计算的不断演进,微服务架构变得日益复杂。为了有效地管理这种复杂性,人们开始采用服务网格。在本文中,我们将解释什么是ServiceMesh,为什么它对现代云架构至关重要,以及它是如何解决开发人员今天面临的一些最紧迫挑战的。理解ServiceMesh一个ServiceMesh是内置在应用程序中的可配置基础架构层,允许个别服务实例之间进行灵活、可靠和安全的通信。在云原生环境中,特别是在采用容器化的环境中,服务网格在处理服务到服务的通信方面至关重要,为其提供了增强的控制、管理和安全性。为什么需要ServiceMesh?随着应用程序不断发展成为由许多微服务组成的分布式系统,它们常常遇到服务发现、负

“五位一体”的业务安全体系

安全是一个动态的、全过程的保障,单一环节无法有效防护。随着风险威胁的瞬息万变,企业需要建立一个覆盖全流程、多场景的、层层递进的、塔防式的防护体系。因此,一个完整的业务安全体系包含数据、特征、策略、模型、运营,五位一体,缺一不可。第一道防线,数据。拦截已知的风险名单,直接过滤已知风险。数据包含情报、IP黑名单、设备黑名单、手机号码黑名单、账户黑名单等信息,主要用于提供有效的数据校验。通过对所采集到的数据进行分析和处理,直接识别拦截异常、可疑操作账户等。第二道防线,特征。通过全链路的产品,分析操作者行为、习惯、环境、设备等,发现异常行为和异常特征。特征包含设备属性、操作行为、环境属性、网络属性等信