看京东系统架构师如何让笨重的架构变得灵巧
作者:徐贤军,京东系统架构师,从事架构设计与开发工作,熟悉各种开源软件架构。在Web开发、架构优化上有较丰富实战经历。
随着业务的复杂性增大、系统吞吐量增长,所有功能统一部署难度加大,各个功能模块相互影响,使系统变的笨重且脆弱;因此需要对业务进行拆分、对系统进行解耦、对系统内部架构升级,来提升系统容量及健壮性。
接下来主要分两部分介绍:系统拆分与结构演变;
系统拆分
系统拆分从资源角度分为:应用拆分和数据库拆分;
从采用的先后顺序可分为:水平扩展、垂直拆分、业务拆分、水平拆分;
图1 系统分解原则
1、水平扩展
水平扩展是最初始的解决的手段,也是系统遇到瓶颈的首选方案,主要从以下两个方面扩展:
应用加实例,搞集群,把系统吞吐量扩上去。
数据库利用主从进行读写分离,数据库其实是系统最应该保护的资源。
2、垂直拆分
垂直拆分才是真正开始拆分系统,主要是从业务功能角度拆分。如拆出用户系统、商品系统、交易系统等。为了解决拆分后各个子系统之间相互依赖调用的问题,这时会引入服务调用治理。系统复杂度有所加大,但系统基本解耦,稳定性相对提高,做好降级就能避免因其它系统功能异常导致系统崩溃。
业务对应的库也会按照对应的业务进行拆分出用户库、商品库、交易库等。
3、业务拆分
业务拆分主要是针对应用层面按功能特点拆分,如交易拆分出:购物车、结算页、订单、秒杀等系统。然后根据业务的特点,针对性做处理,如秒杀系统,由于同时参加秒杀的商品有限,可以提前把商品信息加载到JVM缓存中,自身减少外部调用提高性能,同时商品系统也减轻压力。
数据库拆分也可以分为几步:垂直分表、垂直分库、水平分表、水平分库分表;
垂直分表是指大表拆多张小表,可以根据字段更新或查询频次拆分;
图2 商品表拆分
垂直分库是指按业务拆库,如拆出订单库、商品库、用户库等
水平分表是解决数据量大,把一张表拆成多张表;
水平分库分表是更进一步拆分表;
图3 分库分表
4、水平拆分
服务分层,系统服务积木化,拆分功能与非功能系统,以及业务组合的系统,如最近比较火的大中台或前台拆分;中台为积木组件,承担服务功能输出。前台更多的是组合积木服务,及时响应业务发展,如在电商网站单品页能看见主图、价格、库存、优惠券或推荐等信息,都是组合各积木组件呈现。
数据库也可以进行冷热数据分离;过期或过季商品可以归档,比如诺基亚3210手机,早已经停产且没有销售;用户查看订单时,更多的只是查看最近1、2年信息,2年前数据查看量少,在存储设计时可以区别处理。
结构演变
结构演变主要是随着系统复杂度增加及对性能要求提高而不得不做的系统内部架构升级;
早期系统基本是应用直联数据库,但在系统进行拆分后,功能本系统不能单独完成,需要依赖其它系统,就出现远程调用;
图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程序员朋友们加入Java架构开发:744677563
本群提供免费的学习指导 架构资料 以及免费的解答
不懂得问题都可以在本群提出来 之后还会有职业生涯规划以及面试指导
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
CDN为什么这么快
CDN全称:Content Delivery Network或Content Ddistribute Network,即内容分发网络。 CDN设计思路 避让:尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节,使内容传输的更快、更稳定。 检测:通过在网络各处放置节点服务器所构成的在现有的互联网基础之上的一层智能虚拟网络,CDN系统能够实时监测网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求。 分发:根据监测情况重新导向离用户最近的服务节点上。 CDN应用场景 解决因分布、带宽、服务器性能带来的访问延迟问题,适用于站点加速、点播、直播等场景。使用户可就近取得所需内容,解决 Internet网络拥挤的状况,提高用户访问网站的响应速度和成功率。 控制时延无疑是现代信息科技的重要指标,CDN的意图就是尽可能的减少资源在转发、传输、链路抖动等情况下顺利保障信息的连贯性。CDN所有的工作最后都是落在控制上面,所以CDN就像是网络中的CPU。 示例说明: 在网速一定的前提下,CDN就像网络中快递员小哥 而且CDN这个快递员很是聪明 TA不是在用蛮力瞎跑、乱撞...
- 下一篇
支持Dubbo生态发展,阿里巴巴启动新的开源项目 Nacos
贡献Dubbo生态,阿里Nacos开源计划 在上周六的Aliware技术行上海站Dubbo开发者沙龙上,阿里巴巴高级技术专家郭平(坤宇)宣布了阿里巴巴的一个新开源计划,阿里巴巴计划在7月份开启一个名叫Nacos的新开源项目, 在活动演讲中,坤宇介绍了这个开源项目的初衷,他表示 “将通过Nacos项目将阿里巴巴在建设共享服务体系中使用的服务发现、配置及服务管理平台贡献给开源社区,通过打造Dubbo + Nacos的经典组合进一步释放Dubbo在云原生及Service Mesh时代中,在大规模微服务治理、流量治理、服务集成与服务共享等服务平台能力建设上的威力,同时Nacos会非常关注对主流开源社区,如Spring Cloud和Kubernetes云原生体系的无缝对接与支持”。该项目预计在7月中旬之前开放首个测试预览版本,并计划在未来6~
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- Linux系统CentOS6、CentOS7手动修改IP地址
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- CentOS6,CentOS7官方镜像安装Oracle11G
- 设置Eclipse缩进为4个空格,增强代码规范
- CentOS7,8上快速安装Gitea,搭建Git服务器
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- CentOS7,CentOS8安装Elasticsearch6.8.6
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作