设计

高并发架构设计是指设计一套比较合适的架构来应对请求、并发量很大的系统,使系统的稳定性、响应时间符合预期并且能在极端的情况下自动调整为相对合理的服务水平。

一般而言我们很难用通用的架构设计的手段来解决所有问题,在处理高并发架构的时候也需要根据系统的业务形态有针对性设计架构方案。

本文只是列出了大概可以想到的一些点,在设计各种方案的时候无非是拿着这些点组合考虑和应用。

有很多高并发架构相关的文章都是在介绍具体的技术点,本文尝试从根源来总结一些基本的方法,然后再引申出具体的实现方式或例子。

下面是本文会介绍的16个方面的大纲:
高并发架构设计

阅读更多

一、数据库转型背景

1、传统IT架构的挑战

大型国有银行,整体核心的系统都是大机+DB2这样的传统架构;针对现在的互联网金融业务快速扩张的需求,传统的架构面临着比较大的挑战,主要集中在四个方面:

处理能力;因为工商银行这么大的体量,导致整体系统的规模比较庞大,这种垂直的单一的扩展模式,不具备横向处理能力,处理能力受到限制;

运行的风险;随着很多的业务从网点变成线上,新的业务提出了更高的业务连续性保障,包括7×24小时,传统的架构从架构设计上无法做到这样的支持;

快速交付;传统的开发模式应用内部模块、应用与应用之间的耦合度非常高,使得软件的开发和产品交付周期比较长;

成本控制;大型主机运营成本非常贵,买个机器帮你搞两下就几千万上亿的支出,再加上商业产品的License比较高,银行议价能力又比较低。

在这种情况下进行IT架构转型,整体的诉求是优化应用架构、数据架构、技术架构,建立灵活开放、高效协同、安全稳定的IT架构体系,强化对业务快速创新发展的科技支撑。
工商银行基于 MySQL 分布式企业级解决方案实践

阅读更多

数据量日益增长的今天,尤其是由IT信息时代向DT数据时代的转型期中,数据越来越凸显重要,数据的价值越来越高,也愈加被重视。很多公司都将数据作为企业的核心竞争力,企业的DNA。那么什么是数据呢?

IT时代的IT主要是信息技术,即企业的一切信息例如:企业员工信息,客户信息,产品信息等。信息主要用于描述企业员工、描述客户、产品等,通过信息可以大致了解员工,客户,产品等的基本情况。

DT时代的DT主要是指数据技术。数据是用来准确衡量信息的,例如公司有多少员工,本科以上占比,客户总量,区域客户量等。某种程度上可以这样理解:信息是一种概括的描述,通过信息可以描绘出企业的大概情况,而数据可以精准的描述信息,将信息量化以展示。

当然了,信息和数据的区别上述只是我个人的理解,在我看来,单纯区分二者的区别可能没太大的意义,将二者结合起来,迎合时代浪潮,做好向DT数据时代的过渡才是关键。

数据平台作为企业数据化的一个重要组成因素,必不可少。现在有很多互联网包括传统企业等都在搭建自己的企业数据平台,通过数据平台量化企业各项经营指标,深度剖析企业经营状况,为企业的科学经营提供帮助,进而实现持续盈利的目的。可以说,企业不管是做信息化还是做数据化,都是为了帮助企业科学管理,科学经营决策,都是以实现持续盈利,最大化盈利的目的。

什么是数据平台

我个人的理解是:数据平台是指将公司的所有数据以及关联数据(例如行业数据,竞争对手数据等)进行收集,按照规则处理,并根据特定的主题进行分析,展示,以便准确地剖析企业经营情况,达到指导公司科学经营和决策,并以实现企业持续盈利,最大盈利为目的。一句话,数据平台就是将企业的数据转化为盈利。数据就是金钱,已经越来越成为各个行业各企业的共识。

阅读更多

顶级互联网公司数万节点下 Spark 的 CI 与 CD & CD 灰度发布实践。包含如何维护源代码,如何维护 Release 多版本,开发版与正式版,以及如何实现灰度发布,如何进行 hotfix 等。

因为保密协议,隐去了公司特有内容,只保留通用部分。

一、CI 介绍

持续集成是指及时地将最新开发的且经过测试的代码集成到主干分支中。
十万节点下的Spark灰度发布
持续集成的优点:

快速发现错误:每次更新都及时集成到主干分支中,并进行测试,可以快速发现错误,方便定位错误
避免子分支大幅偏离主干分支:主干在不断更新,如果不经常集成,会产生后期集成难度变大,甚至难以集成,并造成不同开发人员间不必要的重复开发
为快速迭代提供保障:持续集成为后文介绍的持续发布与持续部署提供了保证

阅读更多

以 Hadoop 生态系统为核心构建了整套大数据平台,为整个苏宁集团所有业务团队提供大数据的存储以及计算能力。

在苏宁中台供应链计算等应用场景下,我们基于 Apache Spark 来构建整套零售核心数据计算与分析平台,解决海量数据离线和在线计算时效和性能问题。

苏宁大数据平台和整体框架结构

苏宁大数据平台的整体架构以开源的基础平台为主,辅助以自研的组件。

苏宁大数据平台架构

苏宁大数据平台架构

阅读更多

这个项目通过引入可横向扩展的分布式缓存架构,针对访问频繁的相关表如字典表和三户资料数据,通过应用改造,放到分布式缓存中进行管理,并和数据库互动,大幅降低数据库访问次数,从而达到提高应用效率、降低扩容压力的目的。

项目上线后,实现了应用效率提升和扩容投资降低的目的,实际上线运行情况表明,针对访问最频繁的top 30的表进行缓存处理后,整个数据库访问次数下降30%,关键业务处理性能提升15%。目前40个x86节点,单个节点在30G内存,40个节点分了4个集群,集群内是分片。

一项目实施背景

随着各类业务的发展,对运营商核心OLTP数据库处理能力提出了越来越高的要求,尤其承载核心用户资料数据的crm系统,压力越来越大。传统的性能优化方法,如主机扩容、数据库优化跟不上业务需求压力增长速度,且扩容成本很高,投资巨大。

传统性能优化方法基本基于主机和数据库,但数据库如Oracle方面难以实现横向扩展,扩展能力受限。应用层,可以通过增加服务器数量实现扩容,但是在核心数据库层,由于采取Oracle rac构建,其基于共享存储的机制造成系统io压力越来越集中,io的瓶颈难以通过简单扩容实现,节点数扩展越多,性能下降越明显,同时单台数据库服务器的处理能力也是有限度的,难以无限制的增加,只能通过拆分数据库来进行性能的扩展,但是又增加了数据迁移的难度。

上述背景要求我们寻找一种新的性能优化方法,可以降低核心数据库压力,同时又能实现可扩展的灵活架构方案,从而更好的实现高效低成本。

阅读更多

需要维护大数据集群规模如下:
Hadoop集群规模1300+
HDFS存量数据40+PB,Read 3.5 PB+/天,Write 500TB+/天
14W MR Job/天,10W Spark Job/天,25W Presto/天

此外还需要维护Hadoop、Spark、Hive、Presto等组件,解决公司400+大数据集群用户每天面临的各种问题。

引擎入口统一

目前在饿了么对外提供的查询引擎主要有Presto、Hive和Spark,其中Spark又有SparkThrift Server和Spark SQL两种模式,并且Kylin也在稳步试用中,Druid也正在调研中。各种计算引擎都有自身的优缺点,适用的计算场景各不相同。

从用户角度来说,普通用户对此没有较强的辨识能力,学习成本会比较高。并且当用户可以自主选择引擎执行任务时,会优先选择所谓的最快引擎,而这势必会造成引擎阻塞,或者将完全不适合的任务提交到某引擎,从而降低任务成功率。

从管理角度来说,大数据集群的入口太多,将难以实现统一管理,难以实现负载均衡、权限控制,难以掌控集群整体对外服务能力。并且当有新的计算需求需要接入,我们还需要为其部署对应的客户端环境。

用户使用多种计算引擎

用户使用多种计算引擎

阅读更多

基于 Elasticsearch 的通用搜索是蚂蚁内部最大的搜索产品,目前拥有上万亿文档,服务了上百个业务方。

一、源动力:架构复杂、运维艰难

和大多数大型企业一样,蚂蚁内部也有一套自研的搜索系统,我们称之为主搜。但是由于这种系统可定制性高,所以一般业务接入比较复杂,周期比较长。

而对于大量新兴的中小业务而言,迭代速度尤为关键,因此难以用主搜去满足。

主搜不能满足,业务又实际要用,怎么办呢?那就只能自建了。蚂蚁内部有很多小的搜索系统,有 ES,也有 solr,甚至还有自己用 Lucene 的。

1、业务痛点
Elasticsearch在蚂蚁金服的实践经验
然而业务由于自身迭代速度很快,去运维这些搜索系统成本很大。就像 ES,虽然搭建一套很是简单,但是用在真实生产环境中还是需要很多专业知识的。作为业务部门很难去投入人力去运维维护。

阅读更多

计算广告系统是集智能流量分发、投放、结算、CTR预估、客户关系管理等为一体的大型互联网业务系统,随着微博业务的快速增长,广告系统的复杂度越来越高,成千上万的模块需要不停地进行计算和通信,如何保证这么复杂的系统正常、健康运行是一个巨大的挑战。

微博广告智能监控系统依托两大平台:D+(Data Plus)和Hubble平台。

D+属于商业基础大数据平台,它负责数据采集、存储、计算和分析,并作为底层技术对上层应用提供API数据接口。Hubble(哈勃,其含义是数据如浩瀚宇宙之大,Hubble如太空望远镜,能窥见璀璨的星辰,发现数据的真正价值)平台定位为微博广告智能全景监控、数据透视和商业洞察,与实验平台、效果分析平台、DMP、广告投放后台等共同构成了D+的上层应用生态。

微博广告Hubble平台每日处理TB级别的监控数据和万级别的报警规则,Hubble平台利用机器学习技术进行趋势预测和报警阈值的智能调整,保证商业产品上千台服务器和数百个系统及服务的正常运行。

一、背景介绍

1、监控指标体系

通常,可以用系统处理监控指标的量级(目前已达百万级别)来衡量监控平台的处理能力。这个衡量指标在一定程度上可以反映监控平台的复杂度和能力,但是在实际业务中并不一定需要这么庞大的监控指标体系,很大一部分监控指标是毫无价值或多余的。这些指标要么根本无法真实反映系统或者业务的状态,要么可以直接被其他指标所取代,要么需要结合更多的信息来分析。

阅读更多

百PB级Hadoop集群存储空间治理
现在这个世道,随便什么公司什么人都张嘴闭嘴大数据,连做个几十人的问卷都敢叫大数据调查分析。真是无知者无畏。

但也真有不少公司是真的有足够大的数据量的,也确实是在用心做大数据。这些公司通常规模不小,但盈利不一定理想。就算能稳定盈利,也一定有不小的成本压力。因为,大数据如果真的够大,是真的很费钱。

以这家公司为例,每年的服务器采购成本就已经好几千万,眼看奔着8位数去了。

因此有很强的节省成本的动力。

另一方面,之前我在思考作为公共部门和基础设施部门,在不做业务不赚钱的情况下,怎么体现自己的价值。其中很重要的一点就是,省钱就是赚钱呀,体现在公司收支上效果是差不多的。

在计算资源可复用、可灵活调度的情况下,存储空间往往是带来成本的最重要的原因。这篇文章就简单梳理下这几年我们在数十 PB 到百 PB 级别数据量下对存储空间做的一些治理工作。

阅读更多