点击“技术领导力”关注∆ 每天早上8:30推送
作者| Mr.K 编辑| Emma
来源| 技术领导力(ID:jishulingdaoli)
本文整理自,阿里高级技术专家 王晶昱,在技术大会上的分享的《淘宝技术发展历程和架构经验》。
淘宝的整个发展过程,技术架构演进历程,以及演进过程中的思考,对我们是有借鉴意义的,尤其是正处在快速发展期的系统。架构如何演进、如何更好的对业务支撑、如何设计数据存储方案等等。以下是正文:
01
淘宝前期的技术架构
淘宝早期,上百人维护一个核心工程,会造成代码冲突问题特别严重,项目团队之间协同代价高。人员更新速度比较快,代码交接比较困难,源代码膨胀很快。
这个阶段在使用JBoss服务器、Spring框架、OR-Mapping框架等,也开始用到一些cache、分布式文件系统。
(本文图片来源@阿里中间件团队)
02
淘宝前期技术发展的问题
主要有三个问题:
1.业务支持缓慢,所有东西交叉盘绕在一起。
2.数据孤岛。数据库总是被不明来源的SQL查挂,同类数据格式不统一,无法形成合力。
3.数据库能力达到上限。无法支撑海量数据,及巨量读写请求。
数据库CPU90%以上,每年down机最少一次,连接数不够用。
维护人员多,团队职责不清,数据无法共享,团队各自为战。
小型机数据库压力过大连接数,单点系统风险很高。
03
淘宝3.0架构应运而生
淘宝3.0架构的特性:
服务化(SOA) 。系统专业化分工,减少学习成本。拆分出了第一个业务服务中心:用户中心 (UIC),在2008年初上线,标志着淘宝分布式架构的一个里程碑。接着,千岛湖项目上线,包括交易中心(TC) ,类目属性中心(Forest)。以及五彩石项目,包含:店铺中心(SC) ,商品中心(IC) ,评价中心 (RC)。
组织结构支持。在组织架构上也随之改变,按职能拆分成:服务中心团队、中间件团队、垂直产品团队,分式上更加精细化。
数据库拆分。可按需扩容、尽可能对业务透明、用代理模型减少连接数,选择恰当的切分维度。按业务场景的需要进行拆分,比如:订单表按用户维度、时间维度进行表拆分,数据异构等等,都是在这个时期开始做的。
04
淘宝3.0技术架构全景图
淘宝3.0技术架构,从用户场景来看,用户发起一个请求,透过CDN层,到达Web应用层,在IDC内部这些请求,通过EDAS分发到各个业务服务中心,如商品中心、用户中心等等。这些应用会访问OCS缓存服务、OSS文件存储服务。
通过数据库访问层,SQL查询被路由到各分库、分表当中,部分查询调用搜索引擎opensearch。
这个技术架构,支撑着天猫、淘宝、国际、聚划算等事业群,以及他们下面的具体业务线,如高德、阿里健康、钉钉等。
05
淘宝服务化系统的演进
淘宝服务化系统的演进,包括:
服务化架构。把应用打散拆分,能力和业务内聚形成统一服务能力单元。
自动化、高可靠。任何节点、链路夹在昂,能够自动检测,优化确保高可用。
去中心化,线性扩展。服务能力,随着资源增加微服务级线性性能和扩容。
数据化运营。服务运行实时监控,数据积累可视化,提供系统优化基础。
异步化,最终一致性。高性能消息服务框架、系统应用尽量无状态化,确保最终一致性。
使用成熟组件。使用在生产环境中证明过的可靠成熟组件,用户量翻倍,系统复杂度也会翻倍。
06
淘宝服务化架构
服务化特征。系统由服务单元组成,服务能力开放,数据共享,团队垂直化。
优势。业务支撑更敏捷,利于数据分析与挖掘,无数据孤岛,技术引领无限可能
07
系统架构去中心化,线性扩展
特征:整个系统无单点,系统中所有角色可单独扩缩,故障影响小。
优势:应用更稳定、扩展性好。
08
异步化,最终一致
流程异步化,去锁,并行,最终一致。
降低延迟,提升用户体验;系统解耦合,提升开发效率;部分替代分布式事务功能。
09
使用成熟基础组件
选择用户广泛的产品,选择经过4~6年左右的稳定期的软件,规避销售主导的软件产品。
保证项目按期支付,保证项目上线后的系统稳定,出现问题以后有充分的掌控力
10
运维工作自动化
运维自动化,水平扩展自动化,部署自动化,故障处理自动化。云计算的基本属性,人不能随着机器增加而增加。
11
数据化技术运营
具有亿级数据的分钟级计算能力、 成熟的数据化运维/运营工具 、 技术、管理、运营有数据化运 营的方法论和意识的特征。具有 改善可量化,更科学、1分钟内故障确切定位位置、 “不能比我们的客户更晚知道 我们不可服务“的优势。
12
阿里关键技术组件介绍
主要包括:企业级分布式应用服务(EDAS),阿里分布式数据库服务(DRDS),阿里分布消息服务(ONS)。
企业级分布式应用服务(EDAS),包括对各个服务化组件,进行链路监控治理,服务调用是否健康,故障自恢复等。
分布式数据库(DRDS),可无限线性扩容的分布式数据库,最大节点数超过500台机器,容量、吞吐 线性增长。
可运维的分布式数据库,分布式DDL语句支持,平滑流畅的控制台体验,各类MySQL 图形工具兼容。
兼容复杂MySQL语法的分布式数据库,分布式跨机Join,跨机分页聚合,多机嵌套查询,MySQL函数兼容性支持 ,在多个政务类场景中应用广泛。
分布式消息通知系统(ONS),通过消息将业务系统解耦,持久化消息,100%可靠;支持集群订阅;支持事务消息。
12
本文小结
一、淘宝前期技术发展的三个问题:
业务支持缓慢,所有东西交叉盘绕在一起。
数据孤岛。数据库总是被不明来源的SQL查挂,同类数据格式不统一,无法形成合力。
数据库能力达到上限。无法支撑海量数据,及巨量读写请求。
二、淘宝3.0架构的特性:服务化(SOA) 、组织结构支持、数据库拆分。
三、淘宝服务化系统的演进,包括:
服务化架构。把应用打散拆分,能力和业务内聚形成统一服务能力单元。
自动化、高可靠。任何节点、链路夹在昂,能够自动检测,优化确保高可用。
去中心化,线性扩展。服务能力,随着资源增加微服务级线性性能和扩容。
数据化运营。服务运行实时监控,数据积累可视化,提供系统优化基础。
异步化,最终一致性。高性能消息服务框架、系统应用尽量无状态化,确保最终一致性。
使用成熟组件。使用在生产环境中证明过的可靠成熟组件,用户量翻倍,系统复杂度也会翻倍。
如果觉得本文对您有帮助,请点在看、分享朋友圈,感谢您的支持!
-END-
关注“技术领导力”公众号
用故事讲技术,有趣,有料!
想加入社区,跟100位互联网大咖学习?
请在公众号中回复:“加群”
大家在看:
1.迷信中台是一种病,得治
2.微信架构总监:10亿日活场景下的微服务架构
3.雷军、张小龙:为何高手的努力深入而轻松
4.阿里VP李飞飞:下一代云原生数据库技术
5.马化腾和张一鸣的灰度思维是什么?
6.我是如何在独角兽公司做业务中台、数据中台?
喜欢就点在看!