![](https://img-blog.csdnimg.cn/20190918140213434.png?x-oss-process=image/resize,m_fixed,h_224,w_224)
他山之石
文章平均质量分 82
他山之石,可以攻玉
刘都都
当你不再需要通过别人的认可来证明自己的时候,你就真的强大了。
展开
-
Go实现通过ssh和gorm代理连接内网mysql数据库
Go实现通过ssh和gorm代理连接内网mysql数据库,值得注意的是,如果是服务的话, defer dial.Close() 这个代码要不放在这个位置,而是服务关闭的时候转载 2022-06-15 15:19:50 · 2195 阅读 · 2 评论 -
分布式之数据库和缓存双写一致性方案解析
为什么写这篇文章?首先,缓存由于其高并发和高性能的特性,已经在项目中被广泛使用。在读取缓存方面,大家没啥疑问,都是按照下图的流程来进行业务操作。但是在更新缓存方面,对于更新完数据库,是更新缓存呢,还是删除缓存。又或者是先删除缓存,再更新数据库,其实大家存在很大的争议。目前没有一篇全面的博客,对这几种方案进行解析。于是博主战战兢兢,顶着被大家喷的风险,写了这篇文章。先做一个说明,从理论上来说,给缓存设置过期时间,是保证最终一致性的解决方案。这种方案下,我们可以对存入缓存的数据设置过期时.转载 2021-08-28 00:47:03 · 229 阅读 · 3 评论 -
你们公司有做过数据迁移吗,行业中常见的数据迁移方案,了解下,每个人技术人必备的技能
互联网金融行业发生了翻天覆地的变化,相对应的金融科技也在不断的更新和迭代,每次有新的软件系统出炉的时候,就是老的软件系统命运终结的开始,老的项目当然不会束手就擒,它也会做最后的挣扎,当你从它身上迁移用户或者商户的时候,它会给你带来很多麻烦,比如说,它会临时罢工、出现资金损失等等不可忽视的问题,因此,迁移是个大任务,有的时候迁移并不亚于开发一套新系统的难度,甚至可以说是有过之而无不及。哪些场景需要迁移我们总结了各种需要迁移的场景。字段迁移原来设计的字段大小不能满足现在业务的需求,直接在原表上扩转载 2020-05-21 23:11:54 · 4081 阅读 · 0 评论 -
MAC OS安装Composer + Laravel
Laravel 框架使用 Composer 来管理其依赖性安装composer使用 curl 指令下载:curl -sS https://getcomposer.org/installer | php或是沒有安裝 curl ,也可以用 php 指令下载:php -r "readfile('https://getcomposer.org/installer');" | php当你下载了 composer.phar 后,可以将它放在目录中,但每次当你建立新目录时,你必須再复制一个副本到新目录中,这样转载 2020-06-02 15:10:43 · 637 阅读 · 1 评论 -
海量服务之道全图
转载 2020-09-14 11:52:45 · 599 阅读 · 1 评论 -
架构设计中常见的队列延时,都有哪些设计方案呢,一起来看看吧
一、延时队列的应用什么是延时队列?顾名思义:首先它要具有队列的特性,再给它附加一个延迟消费队列消息的功能,也就是说可以指定队列中的消息在哪个时间点被消费。延时队列在项目中的应用还是比较多的,尤其像电商类平台:1、订单成功后,在30分钟内没有支付,自动取消订单2、外卖平台发送订餐通知,下单成功后60s给用户推送短信。3、如果订单一直处于某一个未完结状态时,及时处理关单,并退还库存4、淘宝新建商户一个月内还没上传商品信息,将冻结商铺等。。。。上边的这些场景都可以应用延时队列解决。二、延时队列的转载 2021-01-11 11:55:32 · 449 阅读 · 1 评论 -
作为技术人员,经常遇到没有接触过的技术,有时是点滴的小技能,有时可能是大的一个研究课题,那么我们如何进行技术研究呢?
像外行一样思考,像专家一样实践日本的金出武雄先生在《像外行一样思考,像专家一样实践》一书中,用浅显易懂的语言传达了他在科研领域的一些经验,值得我们学习。像外行一样思考,像专家一样实践指 的是我们进行最初的设想时只要像普通人那样进行一般的思考就可以了,但是一旦确定了想法,真正要做的话,就要像专家一样缜密、彻底的进行调查和研究,将其 实现从现状出发,进行逻辑推理,最终去下结论和实现。最近有好几个人问我同一个问题,每次看别人的东西总是习惯于在还不知道如何使用时就会不自主的深入到 思考别人如何实现上,这种在考虑问转载 2021-01-15 17:11:39 · 977 阅读 · 1 评论 -
关于架构设计,这些思维模型,都了解吗,一起来看看吧,关于架构设计思维比能力重要!!!
动机万事万物逃脱不出“不易、简易、变易”这三个层次,演绎法认为“道生一、一生二、二生三、三生万物”,而归纳法也可以认为“万物合三,三合二、二合一、一合道”。本文的目的之一是通过归纳法找出分布式系统架构设计最为本质的“道”,使之可以用于解读各式各样的分布式系统架构设计。从应用领域来看分布式系统可以分为三大类:分布式计算、分布式存储以及分布式调度,本文做的是从这三大领域的”变易”中找出“不易、简易”,“以”不变“应”万变“,从而抽象出一种分布式架构思维使之可以应用于这三大领域的架构设计。架构思维模型转载 2021-01-17 16:42:40 · 1194 阅读 · 1 评论 -
分布式架构设计、什么是高可用,如何保障高可用
一、什么是高可用高可用HA(High Availability)是分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计减少系统不能提供服务的时间。假设系统一直能够提供服务,我们说系统的可用性是100%。如果系统每运行100个时间单位,会有1个时间单位无法提供服务,我们说系统的可用性是99%。很多公司的高可用目标是4个9,也就是99.99%,这就意味着,系统的年停机时间为8.76个小时。百度的搜索首页,是业内公认高可用保障非常出色的系统,甚至人们会通过www.baidu.com .转载 2021-01-21 22:25:16 · 1132 阅读 · 0 评论 -
领域驱动实践之基本理论总结与分析
目录领域驱动实践总结一:基本理论总结与分析一、领域驱动设计两大设计:战略设计和战术设计(一)战略设计1.出发角度与目标2.实现方式:事件风暴与模型确立(用例分析、场景分析和用户旅程分析)3.用三步来划定领域模型和微服务的边界(二)战术设计1.出发角度与目标2.实现方式:DDD 分层架构、整洁架构、CQRS 和六边形架构等 (我们采用DDD 分层架构)3.代码模型强调两点:聚合之间的代码边界一定要清晰+一定要有代码分层的概念二、理解和分析领域+子域+核心域+通用域.转载 2021-01-24 23:35:19 · 544 阅读 · 0 评论 -
微服务架构体系的深度治理,微服务架构不缺少的一环!!!
微服务模式下,庞大的服务节点数量、日趋复杂的服务分层、离散的组织协同、扁平化的管理模式让服务治理的广度、深度、难度都达到前所未有的程度。单纯依靠微服务框架层面的治理是远远不够的,需要构建贯穿研发、测试、运维、管理各领域的立体式的深度治理体系。本文整理自天弘基金(余额宝)移动平台技术总监兼首席架构师李鑫在 QCon 全球软件开发大会(北京站)2019 上的演讲,他基于自身多年微服务治理的实践经验及感悟,全面地介绍了如何构建完备的微服务治理的指标体系及治理模型,并通过自动化的线上线下一体的“度量”及“管控”这两转载 2021-02-04 00:05:17 · 983 阅读 · 0 评论 -
架构整洁之道, 看这一篇就够了!
一、软件系统的价值架构是软件系统的一部分,所以要明白架构的价值,首先要明确软件系统的价值。软件系统的价值有两方面,行为价值和架构价值。行为价值是软件的核心价值,包括需求的实现,以及可用性保障(功能性 bug 、性能、稳定性)。这几乎占据了我们90%的工作内容,支撑业务先赢是我们工程师的首要责任。如果业务是明确的、稳定的,架构的价值就可以忽略不计,但业务通常是不明确的、飞速发展的,这时架构就无比重要,因为架构的价值就是让我们的软件(Software)更软(Soft)。可以从两方面理解:当需求变更时转载 2021-02-05 00:12:31 · 755 阅读 · 0 评论 -
dubbo go中的TPS Limit设计与实现 滑动窗口、固定窗口有什么区别?
前言Apache Dubbo是由阿里开源的一个RPC框架,除了基本的RPC功能以外,还提供了一整套的服务治理相关功能。目前它已经是Apache基金会下的顶级项目。而dubbogo则是dubbo的go语言实现。最近在dubbogo的todo list上发现,它还没有实现TPS Limit的模块,于是就抽空实现了这个部分。TPS limit实际上就是限流,比如说限制一分钟内某个接口只能访问200次,超过这个次数,则会被拒绝服务。在Dubbo的Java版本上,只有一个实现,就是DefaultTPS转载 2021-03-05 00:51:41 · 515 阅读 · 2 评论 -
海量用户标签系统之存储架构设计(Bigmap算法)
背景我们在日常的工作中经常遇到这种场景对一个用户添加许多的标签信息方便对用户身份进行搜索和精细化运营ps:本文我们不考虑用户身上的标签是怎么来的,只讨论用户已经拥有标签的情况下怎么进行存储需求分析我们给用户做标签的目的是为了支持更加精细化的运营,算是用户画像的一部分,用户的标签来源可能跟消费,登录,浏览等记录都有关系我们要做的是可以根据用户身上已经存在的标签,筛选出来符合我们需求的用户我们可以在大量的标签中查找具有某一些标签的用户,或者获取某用户身上的所有标签我们如果要满转载 2021-03-27 21:38:20 · 4385 阅读 · 3 评论 -
应用架构设计“着火”&“防火”经验之谈
资源是有限的着火点:系统设计的时候总是估摸不到会有大数据量从远端传输过来(例如处理Http请求时,对于大附件内容的处理,全部装载到内存,结果资源耗尽。从搜索引擎或者DB或者缓存里面拉数据,没有分页,结果内存被吃尽。Socket无限建立连接,结果linux的文件句柄被耗尽。)防火点:对业务场景中资源的分配与申请需要做到上限控制,以及达到上限以后的逻辑处理(排队,丢弃,告警)。可以采取一些滑动窗口设计来将不需要过多处理的内容分段直接送入下一个处理管道中。依赖是未知的着火点:事务.转载 2021-03-28 16:19:54 · 306 阅读 · 0 评论 -
稳定性之故障应急处理流程
一 概述尽管我们可以通过稳定性体系建设,来避免出现生产系统故障。但是仍然无法彻底避免一点风险都不会产生,当稳定性风险产生后,怎么快速协调组织,缩短故障时长,科学的流程就非常重要了。好在我们现在就开始思考的话,我们还有充足的时间去设计各个环节,并让参与的同学充分的锻炼,从而做到训练有素,为故障恢复争取宝贵的时间。二 结构化问题解决对于问题解决有很多结构化解决方法,尤其是各种专业的咨询公司,这些流程值得我们借鉴。结合软件系统的生产环境故障来描述的话,一个典型的结构化问题解决步骤如下: 问题转载 2021-05-22 22:04:25 · 412 阅读 · 0 评论 -
面对系统的稳定性、我们如何做好系统稳定性建设?
1.背景介绍在移动互联网时代,用户群的积累比之前更容易,但同样,也会因为糟糕的用户体验,而快速流失用户,哪怕是号称独一无二的12306网站,也在不断优化系统来提升用户体验;而在后移动互联网的物联网时代,软件工程师需要和硬件工程师配合,来保证提供的服务稳定和可靠。对,我们的产品就是为了实现用户价值,并提供非凡用户体验!如果说良好用户体验是增长的基础,那么良好的操作性、稳定的使用体验就是用户体验的基础,排除掉软件可操作性(这一块需要依靠专业的设计师),剩下的就是客户端(这里的客户端包括各种小程序、WebAp转载 2021-05-28 11:35:25 · 2407 阅读 · 0 评论 -
作为研发工程师,不可不知的运维技能武器库,这些你知道吗
Bootstrapping:Kickstart、Cobbler、rpmbuild/xen、kvm、lxc、Openstack、 Cloudstack、Opennebula、Eucalyplus、RHEV配置类工具: Capistrano、Chef、puppet、func、salstack、Ansible、rundeck监控类工具: Cacti、Nagios(Icinga)、Zabbix、基于时间监控前端Grafana、Mtop、MRTG(网络流量监控图形工具)、Monit性能监控工具: ds..转载 2021-06-18 16:29:14 · 253 阅读 · 1 评论 -
Mysql 导出 sql的执行结果到 csv文件
需求: 1. 执行某 SQL 的结果; 2. 将结果导出到 csv文件; 3. 通过命令行执行;解决方案mysql -A db_name -h host_name -u user_name -p -ss -e "SELECT * FROM table_name LIMIT 100;" | sed 's/\t/","/g;s/^/"/;s/$/"/;s/\n//g' > apps.csvsed 部分内容可以省略-A 指定数据库;...转载 2021-04-15 12:01:52 · 1360 阅读 · 0 评论 -
服务超时时间如何设置、如何对超时时间治理、超时设计原则一文揭秘!
微服务是⼀种分布式架构,系统内各部分(服务)被部署为单独的应用程序,并通过某种远程访问协议进⾏通讯。分布式应⽤的挑战之⼀就是如何管理远程服务的可用性和它们的响应。本⽂主要探讨服务的响应时间对系统的影响和应对。上图是简化的微服务调用链路过程,为清晰阐述三个相关方,图中的客户端被限定为用户端(如移动端应用、浏览器页面等),服务端被区分为服务消费方(网络调用中客户端)和服务提供方(网络调用中服务端)。⼤部分服务既为服务消费方,⼜为服务提供方,如处于调⽤链路中间的业务服务,大概率需要去整合数据,..转载 2021-07-14 23:11:18 · 4470 阅读 · 0 评论 -
稳定性之重试,如何优雅地重试,防止系统雪崩
背景在微服务架构中,一个大系统被拆分成多个小服务,小服务之间大量 RPC 调用,经常可能因为网络抖动等原因导致 RPC 调用失败,这时候使用重试机制可以提高请求的最终成功率,减少故障影响,让系统运行更稳定。重试的风险重试能够提高服务稳定性,但是一般情况下大家都不会轻易去重试,或者说不敢重试,主要是因为重试有放大故障的风险。首先,重试会加大直接下游的负载。如下图,假设 A 服务调用 B 服务,重试次数设置为 r(包括首次请求),当 B 高负载时很可能调用不成功,这时 A 调用失败重试 B转载 2021-07-15 23:14:41 · 746 阅读 · 0 评论 -
分布式链路追踪 之 Skywalking 设计理念&核心原理
摘要对大型分布式系统进行监视,可视化和故障排除是一项重大挑战。当今使用的一种常见工具是分布式跟踪系统(例如Google Dapper)[1],它基于跟踪数据检测拓扑和度量。当今拓扑检测的一大局限性在于,只能根据给定的时间窗口的跟踪数据来推断服务之间的依赖关系。这会导致更多的延迟和内存使用,因为在高度分布式的系统中,每个客户端和服务端追踪信息都必须在数百万个随机RPC请求中进行匹配。更重要的是,如果客户端和服务器之间的RPC持续时间长于先前的设置时间窗口或跨越两个窗口,则它可能无法匹配。在本论文中,我转载 2021-08-05 22:53:25 · 1665 阅读 · 1 评论