自定义博客皮肤VIP专享

*博客头图:

格式为PNG、JPG,宽度*高度大于1920*100像素,不超过2MB,主视觉建议放在右侧,请参照线上博客头图

请上传大于1920*100像素的图片!

博客底图:

图片格式为PNG、JPG,不超过1MB,可上下左右平铺至整个背景

栏目图:

图片格式为PNG、JPG,图片宽度*高度为300*38像素,不超过0.5MB

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+
  • 博客(11)
  • 收藏
  • 关注

原创 微服务系统SAAS化方案思考(基于现状少改动)(未实施)

方案1:共享数据库,共享数据架构方案2:共享数据库,独立数据架构方案3:独立数据库根据系统现状和业务规划选择合适的方案,如果不同租户有共享也有独立数据库的,可以考虑根据租户id配置,把租户id和redis、数据库配置在租户资源表中,请求可以根据资源表路由到不同资源库中。我们是针对现有系统saas改造,要减少代码调整,数据库使用公司客户端组件,如果希望sql无改造可能较复杂或解析拼接租户id影响性能,我们系统选择共享数据共享数据架构的方式,故最终的改造方案:1.rpc接口层增加租户注解,把租户

2021-11-03 19:26:56 978 1

原创 微服务与分布式的一些设计原则(转)

微服务设计原则第一条:要领域驱动设计,而不是数据驱动设计,也不是界面驱动设计。微服务设计首先应建立领域模型,确定逻辑和物理边界以及领域对象后,然后才开始微服务的拆分和设计。而不是先定义数据模型和库表结构,也不是前端界面需要什么,就去调整核心领域逻辑代码。在设计时应该将外部需求从外到内逐级消化,尽量降低对核心领域层逻辑的影响。第二条:要边界清晰的微服务,而不是泥球小单体。微服务上线后其功能和代码也不是一成不变的。随着需求或设计变化,领域模型会迭代,微服务的代码也会分分合合。边界清晰的微服务,可

2021-11-03 19:11:38 435

原创 查询接口返参配置化组件设计(适用定制信息查询)

组件引入的业务背景系统存储的信息需要被很多系统的不同业务场景调用,外围的业务场景需要的返参信息不完全一样,针对业务模块等开发了一些接口,这些接口返回的参数较多,外围根据需要获取需要的返参字段;同时有些外围的返参一些要求或者调用量很大,对性能要求较高的,这部分场景还需要定制专门的接口服务;最终导致需要维护的接口梳理较多,维护成本较高(每个接口都需要维护接口文档、概设详设文档、以及针对每个接口的监控告警等配置…)。针对上面的背景提出了返参配置化的解决思路,解决的问题:灵活定制返参字段,减少非必要信

2021-11-02 19:54:30 505

原创 Redis缓存功能组件设计、缓存热点问题

目录一、Redis缓存功能组件介绍二、Redis缓存查询加载、有数据更新的处理流程。三、Redis缓存结构设计注意点,逻辑过期设计思路。四、Redis缓存大数据快速清理工具设计。五、Redis热点缓存预热一、Redis缓存功能组件介绍本文主要记录系统使用Redis缓存的实现思路,解决电商平台常见的一些问题,集成通用的redis组件能力。功能模块涉及:Redis组件逻辑架构简单介绍 Redis缓存查询加载、有数据更新的处理流程。 Redis缓存结构设计注意点,逻辑过期

2021-05-11 20:07:52 825 1

原创 公共配置更新-ehcache组件实现

目录一、针对业务场景二、组件能力优缺点:三、组件实现思路一、针对业务场景目前互联网使用分布式数据库,对于业务配置信息会搭建一个公共库存储,业务中对公共配置大量的读操作可能会产生DB性能瓶颈,所以针对公共库的查询使用Ehcache+Redis二级缓存方案提升并发性能问题,我们系统中提供一套通用的处理方案,对后续接入的配置只需要调用方法即可,无需关注后续处理链路。二、组件能力优缺点:1、开发低嵌入,修改配置后,无需考虑所有机房、应用机器是否都要清理Ehcache缓存和Red.

2021-05-11 19:43:39 202

原创 系统异常日志规范的一种实践

日志的重要性就不赘述了,本编文章是介绍系统业务异常日志打印规范的一种实现,日志打印的方式、日志级别等支持配置化,灵活控制日志输出。一.背景不管你是普通的开发人员还是系统负责人,日常工作中最重要的两件事:业务需求开发、系统稳定性,把这两点做好才是一个合格的开发人员。系统异常日志的治理是提升系统稳定性很重要的一步,系统异常治理也可以发现调用方系统问题,推动外围修复,优化调用链路。系统的...

2020-05-05 17:52:38 747

原创 记一次业务系统拆分的数据迁移及系统切换事项

一.迁移背景老系统使用商业化软件,同时包含模块较多,架构无法支撑,维护成本高等考虑,需要根据业务模块拆分多个系统,新系统支持水平扩缩容 ,rcp框架等,新系统基本上包含常用的技术栈(wildfly、mysql、mycat、redis、ehcache、mq、kafka、zookeeper、hive、spark、rpc、多活等)。老系统使用的db2,需要迁移50亿+数据。数据迁移包括两步:1...

2020-05-01 19:55:21 1342

原创 分布式定时任务秒级调度解决方案

定时任务秒级调度方案 1、任务抢占 业务系统新增调度表控制并发,uts调度会到调度表取需要执行的任务,取到任务之后更新任务表该条任务的状态,防止任务并发执行,处理完成之后将状态更新到处理状态。 2、循环执行 对于实时性要求较高的任务,等待指定时间之后继续取任务执行,不返回任务调度平台,做到秒级调度 3、减少uts平台强依赖 uts平台只配置触发U...

2020-04-01 20:38:53 1268

原创 一种简单的业务数据监控告警设计方案

设计方案背景:随着业务的不断丰富,为了提高系统的性能,大量的采用异步处理的形式,使得产生了较多的待处理数据。准确而又及时的监控这些庞大复杂业务场景产生的业务数据便成了重要的任务。 针对每个业务场景或者异步待处理表,都需要使用JOB定时去监控并及时告警通知到相关人员处理,而这种任务需要有开发工作量并且不同表之间只有少量的区别。重复而又必要的监控需求,导致系统代码量和代码重复度上升、大量JOB又...

2020-03-27 21:43:52 5402

原创 数据库事务和redis最终一致性的解决方法

一:一致性问题及两种处理方案事务同时操作db和redis,在高并发等场景下,可能会遇到db和redis存储数据不一致的问题,遇到这种问题应该怎么解决?根据使用场景提供了几种简单处理方案:单系统中事务处理,事务提交后延迟再删除一次redis,保证数据库数据和redis最终一致性。 多活系统,A机房,B机房,A、B机房数据是底层binlog同步的,独立搭建的应用和redis集群,有业务场景可...

2019-05-28 20:30:05 6533 1

原创 高并发场景下快速生成连续编号一种方法

一、使用场景介绍 分布式系统架构,在业务高并发场景下,如何快速生成连续的会员号,我们系统使用的是mysql+redis的实现方案。 目标:全局唯一,生成编号连续 支持高并发 高可靠,容错单点故障 适用业务场景:连续会员编号生成。二、实现流程三、功能点介绍 1、mysql表结构设计: seq_num ...

2019-05-21 20:27:53 3908

空空如也

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

提示
确定要删除当前文章?
取消 删除