看京东系统架构师如何让笨重的架构变得灵巧

随着业务的复杂性增大、系统吞吐量增长,所有功能统一部署难度加大,各个功能模块相互影响,使系统变的笨重且脆弱;因此需要对业务进行拆分、对系统进行解耦、对系统内部架构升级,来提升系统容量及健壮性。

接下来主要分两部分介绍:系统拆分与结构演变;

系统拆分

系统拆分从资源角度分为:应用拆分和数据库拆分;

从采用的先后顺序可分为:水平扩展、垂直拆分、业务拆分、水平拆分;

图1 系统分解原则

1、水平扩展

水平扩展是最初始的解决的手段,也是系统遇到瓶颈的首选方案,主要从以下两个方面扩展:

  • 应用加实例,搞集群,把系统吞吐量扩上去。
  • 数据库利用主从进行读写分离,数据库其实是系统最应该保护的资源。

2、垂直拆分

垂直拆分才是真正开始拆分系统,主要是从业务功能角度拆分。如拆出用户系统、商品系统、交易系统等。为了解决拆分后各个子系统之间相互依赖调用的问题,这时会引入服务调用治理。系统复杂度有所加大,但系统基本解耦,稳定性相对提高,做好降级就能避免因其它系统功能异常导致系统崩溃。

业务对应的库也会按照对应的业务进行拆分出用户库、商品库、交易库等。

3、业务拆分

业务拆分主要是针对应用层面按功能特点拆分,如交易拆分出:购物车、结算页、订单、秒杀等系统。然后根据业务的特点,针对性做处理,如秒杀系统,由于同时参加秒杀的商品有限,可以提前把商品信息加载到JVM缓存中,自身减少外部调用提高性能,同时商品系统也减轻压力。

数据库拆分也可以分为几步:垂直分表、垂直分库、水平分表、水平分库分表;

垂直分表是指大表拆多张小表,可以根据字段更新或查询频次拆分;

图2 商品表拆分

垂直分库是指按业务拆库,如拆出订单库、商品库、用户库等

水平分表是解决数据量大,把一张表拆成多张表;

水平分库分表是更进一步拆分表;

图3 分库分表

4、水平拆分

服务分层,系统服务积木化,拆分功能与非功能系统,以及业务组合的系统,如最近比较火的大中台或前台拆分;中台为积木组件,承担服务功能输出。前台更多的是组合积木服务,及时响应业务发展,如在电商网站单品页能看见主图、价格、库存、优惠券或推荐等信息,都是组合各积木组件呈现。

数据库也可以进行冷热数据分离;过期或过季商品可以归档,比如诺基亚3210手机,早已经停产且没有销售;用户查看订单时,更多的只是查看最近1、2年信息,2年前数据查看量少,在存储设计时可以区别处理。

原文出处:https://mp.weixin.qq.com/s/-wIC6yPifSEfT_Yybi4pTg?utm_source=tuicool&utm_medium=referral

结构演变

结构演变主要是随着系统复杂度增加及对性能要求提高而不得不做的系统内部架构升级;

早期系统基本是应用直联数据库,但在系统进行拆分后,功能本系统不能单独完成,需要依赖其它系统,就出现远程调用;

图4 早期应用结构

随着自身系统的业务发展,对性能要求高,而数据库一定程度上成为瓶颈,就会引入缓存及索引,分别解决key-value及复杂检索;索引加缓存现在已经成为解决高并发的基本方案,但在实施过程会有所区别;

14年对3亿热数据的系统升级时,技术选型为solr+redis,考虑到数据量过大,数据在solr中只存index,而结果只存并返回主键id,再通过id从redis中读取数据,redis也不存放全部数据,数据设置过期时间,若未命中redis,回源数据库查询并反写redis;主要考虑资源与性能的平衡,solr的存储减少及IO性能提高,结果数据只在redis存放一份,redis的数据经过运行大部分是热数据;当然现在也流行ES+Hbase组合。

图5 增加缓存及索引

对于频繁使用的数据,从集中缓存读取,不一定达到性能要求,可以考虑把数据入JVM缓存,如类目信息,类目是电商系统基本数据,数据量不多,调用量大;

个别情况下,使用ThreadLocal做线程内缓存也是种有效手段,但需要考虑数据清除及有效性;

在修改商品信息时,业务对商品信息的校验有名称长度、状态、库存及各业务模式等,而为了参数的统一校验方法参数为商品编号,导致各校验方法都需要读取一次商品,使用线程缓存可以解决该问题,性能提高了尽20ms,读取商品每分钟减少近万次;

图6 增加本地缓存

有时所依赖系统性能不太稳定,避免出现因第三方系统影响系统,把依赖的服务进行数据闭环,与Dao一样当成系统的数据源;如商品系统强依赖商家系统的商家信息服务,若商家服务不稳定,商品系统一半服务都不稳定,采取对商家信息缓存一份,降低外部风险,把风险控制在自己手上;

图7 远程服务进化成数据源

用户体验最近越来越重视,系统响应时间性能要求也越来越高,异步化是很好的一种选择:消息中间件;电商下单就是个很好的案例,在用户点击下单时,服务端不直接保存数据,给订单系统发送消息,就直接返回支付页面,在用户支付过程中,订单系统异步进行数据保存;

业务层、数据层的范围越来越宽泛,业务层可以分为基础服务与组合服务;数据层分为数据源与索引缓存;依赖的技术或中间件需要有效的结合,用于解决系统所遇到各种问题。

图8 复杂的结构

在此我向大家推荐一个Java架构群 :725633148 里面会分享一些资深架构师录制的视频录像:(有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化、分布式架构)等这些成为架构师必备的知识体系 进群马上免费领取,目前受益良多!

最后

系统结构慢慢变复杂,稳定性、健壮性逐渐提高;技术选择都需要结合业务痛点、技术储备以及资源情况,否则就有些不切实际,泛泛而谈;

以上是近几年自己经历的技术变革及升级的总结,后续可以针对个别点进行详细分享。

系统拆分的最后是微服务,结构的演变是技术的升级。

原文地址:https://www.cnblogs.com/aa475968700/p/9238918.html

时间: 2024-11-04 00:36:12

看京东系统架构师如何让笨重的架构变得灵巧的相关文章

系统架构师-基础到企业应用架构-业务逻辑层

一.上章回顾 上章我们主要讲述了系统设计规范与原则中的具体原则与规范及如何实现满足规范的设计,我们也讲述了通过分离功能点的方式来实现,而在软件开发过程中的具 体实现方式简单的分为面向过程与面向对象的开发方式,而目前更多的是面向对象的开发设计方式.并且我们也讲述了该如何通过设计手段去分析功能点及设计分离 点,应该如何在设计的过程中分析的角度及如何去满足设计规范与原则.首先我们通过下图来回顾下上章要点: 二.摘要 本文将已架构的方式去分析分层结构中的业务层的设计,如何写出来内聚度,高耦合的业务逻辑层

系统架构师-基础到企业应用架构-系列索引

系统架构师-基础到企业应用架构-索引 系统架构师-基础到企业应用架构系列会从,系统架构的起源.发展.架构师必备的基础知识与技能.如何把架构应用到企业应用中去.整个系列计划30篇左右,每 一篇都是自己在系统架构过程中的总结和经验,每一篇我都会抱着认真的态度去完成,宁缺毋滥的原则.希望本系列看完之后不但能够帮助看过这个系列的人对系统架 构有深刻的认识,并且能够掌握系统架构中的必备知识,应用到自己的工作中去,更可以共同提高大家的个人能力.本系列希望能够抛砖引玉,希望大家能够多提出宝 贵意见. 前篇 1

系统架构师-基础到企业应用架构-系统设计规范与原则[上篇]1

一.上章回顾 在上篇中我们讲解了几类UML2.0语言新推出的建模图形,总体来说通过这些图形能更详细的将某类信息表达出来.在这里我们简单回顾上篇讲解的内容. 上图中已经简单介绍了上章讲述的内容,具体内容请看:系统架构师-基础到企业应用架构-系统建模[下篇]. 二.摘要 本章将主要的简单介绍在系统架构中的设计模式及相应规范准则.并结合相应的代码来说明如何遵循系统架构中的一些基本的设计规范及准则.而我们将在本文介 绍几类常用的设计规范,我们先来看看结构化设计的二个基本原则: 当然既然提出了基本的准则,

系统架构师-基础到企业应用架构-服务层

一.上章回顾 上篇我们主要讲解了系统架构中的四种架构模式,并且分析了四种架构模式的实现及应用场景,那么先来回顾下架构中的业务逻辑层的使用及总结.  如果大家对图中讲述的内容不明白或者说是不深入那么可以参考上篇讲 解的内容:系统架构师-基础到企业应用架构-业务逻辑层. 二.摘要 本文将已架构的方式去分析分层结构中的服务层的设计,如何设计出来满足我们说的业务需求及设计规范的服务层将是我们的目标,可能我想大家在项目架构的 过程中可能有些同仁,没有用到该层,或者说是采用的是常用的分层结构的设计,而没有把

系统架构师-基础到企业应用架构-企业应用架构

一.上篇回顾 我们先来回顾下上篇讲解的内容,我们前面的几节分别讲述了,业务逻辑层.数据访问层.服务层.表现层,我们了解了这些分层的职责和分层之间的大概的关联 关系,本篇可能主要是简单的介绍下企业应用的几类模式,结合这几个分层直接的交互来完成系统功能的构建.我们还是先对我们学习的四个分层的职责和功能做个大 概的回顾,我们先来看看下图来回顾下我们讲述的内容. 我想通过上图,大家能回忆起我们讲述的相关内容,然后整理好自己的思路,我们本文将会针对这几个分层进行相应的模式的讲解,并且会结合实例来说明企业应

系统架构师-基础到企业应用架构-系统建模[中篇](下)

一.上章回顾 首先.我们先来回顾下,上篇讲解的内容,加深下印象.上篇我们主要讲解了3个建模图形分别是:顺序图(序列图).组件图.状态图. 具体功能描述如下图:这里不详细解释,如果不清楚请看:系统架构师-基础到企业应用架构-系统建模[中篇](上) 由于全部放在一篇中篇幅太长了,所以分开讲解. 二.摘要 本文主要讲解:UML建模图中的活动图.部署图等 上图中就是本章要讲解的内容,本质将仔细的剖析,部署图与组件图的关系与区别,活动图与状态图的关系与区别. 三.本章内容 1.上章回顾. 2.摘要. 3.

系统架构师-基础到企业应用架构-系统建模[中篇](上)

一.上章回顾 上篇文章主要简单的介绍了建模中使用的标准建模语言UML的相关内容,包括用例图与类图的使用方法及如何建模.相信大家对UML建模语言已经有了初步的认 识,还请大家谨记UML不同的建模图形的用处.比如,用例图主要用来描述系统的功能需求.类图主要用来描述实体间的关系.谨记这些就可以帮助我们在系统架构的 过程中深入的分析. 首先向大家道歉,上篇中有部分描述错误的地方,可能对大家造成一定的错误引导.  这是上篇给出的图,我描述的是组合关系. 特别更正为:  这是正确的结果.箭头指向聚合类.描述

系统架构师-基础到企业应用架构-数据访问层

一.上章回顾 上篇我们简单讲述了服务层架构模式中的几种,并且讲解了服务层的作用及相关的设计规范,其实我们应该知道,在业务逻辑层中使用领域模型中使用服务层才 能发挥出最大的优势,如果说我们在业务逻辑层还是使用非领域模型的模式话,服务层的作用仅体现在解耦作用.其实在业务逻辑层采用领域模型时,我们前面说的持 久化透明的技术,其实我们可以通过服务层来做,我们在服务层中处理领域对象信息的持久化操作.当然本篇可能不会深入讨论持久化透明的具体实现,后面会单独开 篇来讲述,我们先来回顾下上篇讲解的内容:  上图

系统架构师秘籍(三)架构视角和关注点

上次的博文中,我们介绍了一下软件架构的基本概念,接下来我们介绍一下如何来架构一个软件系统. 当我们开始进行系统架构设计的时候,通常会考虑以下几点: 所设计的软件体系结构的主要功能要素是什么. 如何将这些要素与其他系统关联. 哪些信息需要存储.管理和展示. 要实现这些功能要素需要什么硬件和软件. 所设计的软件体系结构提供什么样的特性和能力. 开发.测试.支持.培训环境都需要做什么. 考虑上述问题的时候,我们从哪些层面来考虑呢?那就是架构视角和关注点两个层面. 架构视角 架构视角是从一个或多个角度对