架构
文章平均质量分 90
无心六神通
金融科技系统架构师
展开
-
【笔记】高并发-秒杀架构实战-Redis实现
【笔记】高并发-秒杀架构实战-Redis实现原创 2024-09-01 17:43:03 · 286 阅读 · 0 评论 -
1 企业架构资产的价值
企业架构资产并不是一套静态的固定资产,它是一个企业的“孪生”,它用结构化的方式最大程度还原出一个企业本该有的样子,从规划的秒级反馈,到落地的秒级更新。最大限度让规划、变更和落地变得紧密。秒级的架构资产更新,让这“企业孪生”变为可能。免责声明:本文内容仅表明作者本人观点,并不代表Thoughtworks的立场。原创 2024-07-23 16:05:21 · 1183 阅读 · 0 评论 -
8核16G的CentOS服务器,Spring boot undertow如何优化参数提高并发,电商项目
对于运行在8核16GB内存的CentOS。原创 2024-06-11 19:41:17 · 466 阅读 · 0 评论 -
RocketMQ之存储架构
与「固定频率刷盘」比较相似,唯一不同点是,当前刷盘策略是响应中断的,即每次有新的消息到来的时候,都会发送唤醒信号,如果刷盘线程正好处在500ms等待期间的话,将被唤醒。整体来看,文件预热后的写入操作,确实能带来性能上的提升,但是如果在系统压力较大、磁盘吞吐紧张的场景下,势必导致broker抖动,甚至请求超时,反而得不偿失。不响应中断,固定500ms(可配置)刷盘,但刷盘的时候,如果发现未落盘数据不足16K(可配置),那么将进入下一个循环,如果满16K的话,会将所有未落盘的数据落盘。此处补充说明下,不论是。原创 2024-06-04 08:41:08 · 1015 阅读 · 0 评论 -
高并发架构系列:Kafka、RocketMQ、RabbitMQ的优劣势比较
在高并发业务场景下,典型的阿里双11秒杀等业务,消息队列中间件在流量削峰、解耦上有不可替代的作用。之前介绍了MQ消息队列的12点核心原理总结,以及如何从0到1设计一个MQ消息队列,以及RPC远程调用和消息队列MQ的区别。原创 2024-05-31 05:32:36 · 612 阅读 · 0 评论 -
RocketMQ如何保证消息的可靠性?
本文从消息流转的整个过程分析了RocketMQ如何保证消息的可靠性,消息发送通过不同的重试策略保证了消息的可靠发送,消息存储通过不同的刷盘机制以及多副本来保证消息的可靠存储,消息消费通过至少消费成功一次以及消费重试机制来保证消息的可靠消费,RocketMQ在保证消息的可靠性上做到了全链路闭环,最大限度的保证了消息不丢失。。原创 2024-05-31 05:26:07 · 702 阅读 · 0 评论 -
深入理解内存映射:mmap映射的背后原理以及和共享内存的差异
内存映射(Memory Mapping)是一种将文件内容映射到进程的虚拟地址空间的技术。在这种机制下,文件可以被视为内存的一部分,从而允许程序直接对这部分内存进行读写操作,而无需传统的文件 I/O 调用。这种方法不仅简化了文件操作,还提高了处理效率。mmap是实现内存映射的关键系统调用。它创建了文件内容和进程地址空间之间的直接映射,使得文件的一部分或全部可以直接映射到进程的地址空间中。这样,文件的读写就变得像内存访问一样高效。原创 2024-05-31 05:18:30 · 888 阅读 · 0 评论 -
解密秒杀系统架构,不是所有的系统都能做秒杀!
所以,很多所谓的秒杀系统,存在着秒杀的业务,但是称不上真正的秒杀系统,原因就在于他们使用的是同步的下单流程,限制了系统的并发流量。之所以上线后没出现太大的问题,是因为系统的并发量不高,不足以压死整个系统。原创 2024-05-19 19:48:30 · 1138 阅读 · 2 评论 -
微服务平台
微服务平台(Tencent Service Framework,TSF)是一个围绕着应用和微服务的 PaaS 平台,提供应用全生命周期管理、数据化运营、立体化监控和服务治理等功能。微服务平台拥抱 Spring Cloud 、Service Mesh 微服务框架,帮助企业客户解决传统集中式架构转型的困难,打造大规模高可用的分布式系统架构,实现业务、产品的快速落地。针对原生 Spring Cloud 应用与 Mesh 方式零成本接入。微服务平台以腾讯云中间件。原创 2024-05-15 16:51:53 · 872 阅读 · 0 评论 -
微众银行 TiDB HTAP 和自动化运维实践
基于这些度量指标,我们再通过决策引擎去得到一个最优的治理策略。我们的决策可以分成两部分,原创 2024-03-26 10:35:17 · 591 阅读 · 0 评论 -
TiDB 在微众银行核心批量场景的实践
核心批量场景,数据同步必须做到数据不丢、不错,所以应用也内嵌了数据 checksum 的逻辑,比如在 MySQL 入库时先对数据进行分片,然后把各个分片的 checksum 值写到表里面,再通过 DM 同步到下游 TiDB,最后应用在跑批期间从 TiDB 把各个分片加载出来,然后再跑一遍对应分片的 checksum,再对上下游的 checksum 值进行比对,通过这样的校验机制以确保数据的一致性。最终通过数据和应用的协同优化,达到整体具备的水平扩展能力。原创 2024-03-25 10:54:47 · 987 阅读 · 0 评论 -
微众银行单元化架构
互联网行业的发展带来数据爆炸性的增长,传统银行现在也在慢慢走互联网化和服务在线化,比如手机银行APP,原来很多业务需要到线下网点去办理,现在手机很行上就可以办理成功,所以带来的数据量的也指数级的增长,原来中心化的架构,比如单机存储或是用共享存储的方式,不管是性能还是容量上可能都没办法承载这种爆炸性的增长。我们可以看到这张图里,有包括腾讯、阿里、华为这种大厂的数据库产品,也包括目前开源比较流行的产品,还包括一些传统的厂商产品,可以说真的是百花齐放的时代,这在五六年前都是不可想象的。原创 2024-03-24 09:33:24 · 2037 阅读 · 0 评论 -
微众银行数据库架构演进及 TiDB 实践经验
TiDB 是一个很优秀的分布式关系型数据库产品。对银行场景来说,灰度和上线的节奏没有互联网行业那么快,随着 TiDB 产品的日趋成熟,我们正在更多适合的场景试用 TiDB,也会有更多的经验和大家分享。本文根据胡盼盼、黄蔚在 TiDB TechDay 2019 北京站及深圳站上的演讲整理。原创 2024-03-23 15:49:35 · 954 阅读 · 0 评论 -
支付系统(一) 架构样例
复式记账: 复式记账是与单式记账相对称的一种记账方法。这种方法的特点是对每一项经济业务都要以相等的金额,同时记入两个或两个以上的有关账户。通过账户的对应关系,可以了解有关经济业务内容的来龙去脉;通过账户的平衡关系,可以检查有关业务的记录是否正确。账务处理,分为内外两个子系统,外部子系统是单边账,内部子系统走复式记账。对账处理: + 渠道对账单下载 + 格式标准化 + 本地交易记录准备 + 轧帐 + 平帐。利用消息机制来实现跨系统的事务处理,避免数据库锁导致的性能问题。原创 2024-03-23 15:45:10 · 1020 阅读 · 0 评论 -
银行技术架构(三) 货币
这些国债,美联储买了,支出一万亿美元之后,美联储的资产那里多了一万亿国债的债权,整体资产负债表是平衡的,只不过规模扩大了而已,这就叫。反过来,美联储停止QE,降低美国的国债规模,那市面上的美元就会消失,美联储的资产和负债也会同时减少,这就叫。比如贷款,只要有信用,就可以发货币,国家对外靠外汇抵押,对内没有抵押物,但是个人有,个人的抵押同样可以创造信用,为人民币增信。同理,股市最大的作用,也是抵押增信,股市的市值扩大了,股权抵押就值钱了,有股权做抵押,央行就可以理直气壮的放款,增加全国的货币供应。原创 2024-03-23 15:43:52 · 1026 阅读 · 0 评论 -
银行技术架构(一) 支付清算体系
中国的支付清算有两套体系那么分别来看一下这者这两种方式。原创 2024-03-23 15:42:38 · 2515 阅读 · 0 评论 -
银行技术架构(二) 业务模式与银行账户
备付金缴存影响甚远,支付机构依靠备付金赚取利润的时代一去不复,二联的模式不但从信息流形成了强监管,更是从资金流上实现了根本的控制,同时对三方支付和商户的业务模式也带来了不小的冲击,支付机构备付金利润全面减少,与银行议价能力降低,同时,支付成本的上浮导致支付公司逐渐开始对C端的资金收转付等服务开始收费,降低自身成本。,其他账户得以产生的前提;网联和银联再接收完业务后,对应支付机构的额度账户,实时增加和减少额度,来表示业务完成,然后每一小时,将所有银行数据打包发回给支付机构,支付机构可以自行拆解银行核对业务。原创 2024-03-23 15:40:55 · 1160 阅读 · 0 评论 -
网商银行×SOFAStack:首家云上银行的微服务架构实践与演进
网商银行构建了微服务架构下的全链路压测能力,通过 SOFAStack 中间件提供的能力对真实业务流量和模拟压测流量进行有效的安全隔离,让用户在无感知前提下进行系统压力预演,在真实线上生产环境中模拟用户规模、业务场景和交易请求量级,有针对性地进行系统调优,资源调整,是对生产环境的一次高仿真模拟考试。网商银行全业务三地五中心异地多活的架构体系,提供了跨机房、跨地域的可伸缩、高可用的服务计算能力,能够做到弹性资源分配与全局流量管控,具有海量数据处理和计算能力,有效地提升了网商银行业务连续性保障水平。原创 2024-03-23 15:36:16 · 627 阅读 · 0 评论 -
从0到10亿,微信后台架构及基础设施设计与实践
摘要:微信后台业务类型众多,包括即时通信,社交网络,金融支付等等。本次分享着重讨论如何在海量用户场景下,后台架构设计中的共性部分如高可用、强一致、快速迭代等等,微信是如何在不断变化的背景下设计统一的架构与基础设施来解决核心难题。本文根据许家滔老师在2018年10月17日【第十届中国系统架构师大会(SACC2018)】现场演讲内容整理而成。 回顾微信发展历程2011年,我们发布了第一版微信,2012年,推出视频聊天功能。如今,微信的活跃用户数已经达到10亿。后台涉及到的技术很多,我这边主要原创 2024-03-23 15:31:43 · 1107 阅读 · 0 评论 -
企业架构设计方法与实践
TAM涵盖产品、运营、服务、保障等纵向业务,以及市场销售域、产品管理域、客户管理域、服务管理域、资源管理域、供应商/合作伙伴域、企业管理域等多领域需要的应用功能参考,这些多维的应用功能地图为定义和复杂的应用系统提供了一个范例。整个设计过程的内容比较多,这里只做简要说明,这里仅展示几个核心的领域,比如用户域、会员域、营销域、订单域、商品域、库存域,里面的实体、值对象、领域服务及领域事件等仅展示部分内容。其次,我们初步分析出一些领域,包括店铺域、商品域、库存域、营销域等。图例:企业ABC的核心领域模型。原创 2024-03-23 15:20:53 · 725 阅读 · 0 评论 -
企业级-数字化转型-架构驱动设计-总纲
本文主要从架构驱动设计探讨引导企业级的数字化转型实践。原创 2024-03-10 13:22:36 · 1254 阅读 · 1 评论 -
业务架构-虚拟案例-商业银行
实际业务场景比该示例要复杂得多,但是通过这个简单的模拟案例,我们可以认识到如下几点结论。1)业务架构设计并没有简单的衡量标准。2)设计思路和关注点对架构方案有很直接的影响。3)架构设计需要反复进行迭代,虽然这不是我们所情愿的,但是实际操作中这是不可避免的。4)基于第3点,架构师的经验很重要,可以减少反复次数,尤其是关键设计的反复迭代。架构设计是一个不断精炼和确认的过程,上文提到的过程对于业务人员而言并不难理解,因此,需要架构人员、技术人员在设计过程中努力“培养”客户,创造一个深度融合的机会。原创 2024-02-24 15:19:20 · 916 阅读 · 0 评论 -
业务架构-设计难点
企业级业务模型的建设离不开标准化过程,因为做企业级模型需要,以期在设计上实现“以更少支持更多”,这是大多数企业级系统建设或者企业级转型工程的目标,希望能够同时,这个愿望是非常美好的。实现这一目标时,业务架构设计所面临的最大难点——。原创 2024-02-24 13:40:58 · 846 阅读 · 0 评论 -
业务架构-设计过程
分析完企业战略、组织结构,是不是就该进入业务流程分析了呢?先别急,业务流程分析,特别是对于具有多条不同业务线的企业而言,是一种垂直式的分析。如果直接开始进行业务流程分析,那就走上了竖井式开发的老路,就算拥有共同的战略目标,也未必能够建得出企业级的业务架构和业务系统来。,因此,展开垂直的业务分析之前,必须,这样才能将企业需要的业务能力进行分类汇集,从而产生合理的业务架构。原创 2024-02-23 21:08:48 · 978 阅读 · 0 评论 -
业务架构-设计
在开始讲述业务架构设计之前,本篇首先介绍一下业务架构的一般实现过程,以便读者对此有个整体印象。业务架构是。其一般实现过程包括两个不断交替上升的过程。其中,设计过程为从企业战略分析出发,(既可能是企业自身业务与技术水平发展产生的主动能力需求,也可能是科技导致的业态变化、竞争压力产生的被动能力需求);再通过方式,构建(即),并在分析过程中,将能力需求放入能力布局中,并以此在业务层面落地战略、检验战略的可行性,甚至调整战略。原创 2024-02-23 19:26:53 · 1339 阅读 · 0 评论 -
业务架构-业务模型
业务架构是战略、流程、组织等业务元素的结构化表达,因此,说起业务架构,自然离不开结构化表达的基本方式——。原创 2024-02-23 18:56:01 · 1265 阅读 · 0 评论 -
业务架构-IT架构-关系
TOGAF框架将业务架构视为IT战略的一部分,但事实上,业务架构应当是企业战略而非IT战略的一部分,它不同于通常意义上的业务需求,而是企业业务战略的实现方法。因此,业务架构范围是可以大于IT架构范围的,。IT架构则是用于企业信息化建设的,是企业战略的系统实现部分。二者之间的关系,用灵魂与容器来形容也许更为恰当。,没有灵魂,只有容器是没有生机的,所以,技术人员需要关注业务和业务架构。业务架构与IT架构的关系业务架构可从企业战略出发,按照企业战略设计业务及业务过程,原创 2024-02-23 15:15:33 · 1125 阅读 · 0 评论 -
业务架构-定义-作用
也就是说,业务架构与其他架构一样,其目的也是要降低复杂度,从更好地规划和实现系统,因此TOGAF将业务架构归属于IT战略部分。但是从实践经验来看,业务架构更突出的特点是影响了参加过企业级业务架构设计工作的业务人员,他们的逻辑思维能力、结构化能力、企业级观念和意识都发生了明显的改变,所以,应当将业务架构从IT战略中独立出来,更多地面向业务人员,以。当然,业务架构要想真正承担起这一职责,还,对业务人员更友好,并且坚持使用业务架构方法做企业级需求管控,否则,“熵增”一定会将已经建好的架构秩序回归到混沌状态。原创 2024-02-23 14:57:05 · 882 阅读 · 0 评论 -
业务架构-发展历程-FEA-DODAF
前者的体系由5个参考模型组成:绩效参考模型(PRM)、业务参考模型(BRM)、服务构件参考模型(FRM)、数据参考模型(DRM)和技术参考模型(TRM),该方法应用于美国电子政务领域,着眼于跨部门、跨机构提升业务效率,虽然没有明确的业务架构定义,但是很好地应用了业务架构的思维。CV-5 能力与机构发展映射模型。SveV-3a 服务-系统矩阵。SveV-3b 服务-服务矩阵。SveV-c 服务事件跟踪模型。CV-7 能力与服务映射模型。PV-1 项目与机构关系模型。PV-3 项目与能力映射模型。原创 2024-02-23 14:25:03 · 477 阅读 · 0 评论 -
业务架构-发展历程-TOGAF
可以明确看到业务架构阶段的交付物,这些内容也清楚地说明了业务架构在软件工程中的位置。业务架构是将企业的业务战略转化为日常运作的渠道,业务战略决定业务架构,其包括业务的。可能是政府部门、一个完整的公司、公司部门、单个处/科室,或者是通过共同拥有权连接在一起的地理上疏远的。1995年,大名鼎鼎的TOGAF登场了,这个在企业架构市场中占据了半壁江山的架构模型明确提出了。来理解、分析、设计、构建、集成、扩展、运行和管理信息系统,复杂系统集成的关键,是。TOGAF将企业定义为有着共同目标集合的组织的聚集。原创 2024-02-23 11:54:14 · 498 阅读 · 0 评论 -
高性能-10倍性能提升全过程
由于用户进来后先要登录并且绑定账号,实际压力先到Passport部分,在这个过程中最开始单机TPS只能到500,经过N轮优化后基本能达到5400 TPS,下面主要是阐述这个优化过程- docker bridge网络性能问题和网络中断si不均衡 (优化后:500->1000TPS)- 短连接导致的local port不够 (优化后:1000-3000TPS)- 生产环境snat单核导致的网络延时增大 (优化后能达到测试环境的3000TPS)原创 2024-02-18 17:36:21 · 732 阅读 · 0 评论 -
高可用-接口限流-常用算法-实践
一开始桶是空的,系统按固定的时间(rate)往桶里添加令牌,直到桶里的令牌数满,多余的请求会被丢弃。令牌桶算法中流量的流入速率是不限制的,流出速率也是没有强制限制的(令牌消耗瞬间峰值是桶的大小),但是令牌的产生和积攒需要时间,因此既支持一定程度突发流量,又能满足总体限流的目标。只是它没有对时间窗口做进一步地划分,所以只有1格;固定时间窗口算法的劣势就在于其只关心时间段内的总访问次数,而忽略了瞬间集中请求的问题,换而言之,这种统计方法的粒度太粗了,然而我们无法保证请求在时间段内的分布是平均的。原创 2024-02-18 17:05:19 · 798 阅读 · 0 评论 -
高可用-性能测试-入门
性能测试一般情况下都是由测试这个职位去做的,那还需要我们开发学这个干嘛呢?了解性能测试的指标、分类以及工具等知识有助于我们更好地去写出性能更好的程序,另外作为开发这个角色,如果你会性能测试的话,相信也会为你的履历加分不少。这篇文章是我会结合自己的实际经历以及在测试这里取的经所得,除此之外,我还借鉴了一些优秀书籍,希望对你有帮助。原创 2024-02-13 18:52:47 · 932 阅读 · 0 评论 -
高可用-超时-重试-详解
超时机制说的是当一个请求超过指定的时间(比如 1s)还没有被处理的话,这个请求就会直接被取消并抛出指定的异常或者错误(比如连接超时(ConnectTimeout):客户端与服务端建立连接的最长等待时间。读取超时(ReadTimeout):客户端和服务端已经建立连接,客户端等待服务端处理完请求的最长时间。实际项目中,我们关注比较多的还是读取超时。一些连接池客户端框架中可能还会有获取连接超时和空闲连接清理超时。如果没有设置超时的话,就可能会导致服务端连接数爆炸和大量请求堆积的问题。原创 2024-02-13 18:51:46 · 803 阅读 · 0 评论 -
高可用-服务限流-详解
针对软件系统来说,限流就是对请求的速率进行限制,避免瞬时的大量请求击垮软件系统。毕竟,软件系统的处理能力是有限的。如果说超过了其处理能力的范围,软件系统可能直接就挂掉了。限流可能会导致用户的请求无法被正确处理,不过,这往往也是权衡了软件系统的稳定性之后得到的最优解。现实生活中,处处都有限流的实际应用,就比如排队买票是为了避免大量用户涌入购票而导致售票员无法处理。原创 2024-02-13 18:50:43 · 882 阅读 · 0 评论 -
高可用-冗余设计-详解
举个例子:哨兵模式的 Redis 集群中,如果 Sentinel(哨兵) 检测到 master 节点出现故障的话, 它就会帮助我们实现故障转移,自动将某一台 slave 升级为 master,确保整个 Redis 系统的可用性。和传统的灾备设计相比,同城多活和异地多活最明显的改变在于“多活”,即所有站点都是同时在对外提供服务的。对于服务来说,冗余的思想就是相同的服务部署多份,如果正在使用的服务突然挂掉的话,系统可以很快切换到备份服务上,大大减少系统的不可用时间,提高系统的可用性。原创 2024-02-13 18:49:49 · 946 阅读 · 0 评论 -
高可用-系统设计-指南
高可用描述的是一个系统在大部分时间都是可用的,可以为我们提供服务的。高可用代表系统即使在发生硬件故障或者系统升级的时候,服务仍然是可用的。一般情况下,我们使用多少个 9 来评判一个系统的可用性,比如 99.9999% 就是代表该系统在所有的运行时间中只有 0.0001% 的时间是不可用的,这样的系统就是非常非常高可用的了!当然,也会有系统如果可用性不太好的话,可能连 9 都上不了。原创 2024-02-13 18:48:57 · 775 阅读 · 0 评论 -
高性能-CDN-内容分发网络-详解
CDN全称是 Content Delivery Network/Content Distribution Network,翻译过的意思是内容分发网络。内容 :指的是静态资源比如图片、视频、文档、JS、CSS、HTML。分发网络 :指的是将这些静态资源分发到位于多个不同的地理位置机房中的服务器上,这样,就可以实现静态资源的就近访问比如北京的用户直接访问北京机房的数据。所以,简单来说,CDN 就是将静态资源分发到多个不同的地方以实现就近访问,进而加快静态资源的访问速度,减轻服务器以及带宽的负担。原创 2024-02-13 18:41:59 · 918 阅读 · 0 评论 -
高性能-负载均衡-详解
负载均衡指的是将用户请求分摊到不同的服务器上处理,以提高系统整体的并发处理能力以及可靠性。负载均衡服务可以有由专门的软件或者硬件来完成,一般情况下,硬件的性能更好,软件的价格更便宜(后文会详细介绍到)。下图是《Java 面试指北》open in new window「高并发篇」中的一篇文章的配图,从图中可以看出,系统的商品服务部署了多份在不同的服务器上,为了实现访问商品服务请求的分流,我们用到了负载均衡。原创 2024-02-13 18:40:58 · 925 阅读 · 0 评论 -
高性能-读写分离-分库分表-详解
读写分离主要是为了将对数据库的读写操作分散到不同的数据库节点上。这样的话,就能够小幅提升写性能,大幅提升读性能。我简单画了一张图来帮助不太清楚读写分离的小伙伴理解。一般情况下,我们都会选择一主多从,也就是一台主数据库负责写,其他的从数据库负责读。主库和从库之间会进行数据同步,以保证从库中数据的准确性。这样的架构实现起来比较简单,并且也符合系统的写少读多的特点。分库就是将数据库中的数据分散到不同的数据库上,可以垂直分库,也可以水平分库。垂直分库。原创 2024-02-13 18:39:54 · 905 阅读 · 0 评论