聊架构:当当网架构优化的几点心得

2016-03-13 17:20    阅读:

您当前的位置:山西做网站 > 网站建设 > 建站常识 >

  我想这两天大家或多或少有在看李克强总理的政府工作报告,我也在电视旁愣着算是看完了全程,看完有个感受想反馈,要是总理的报告能和PPT搭配着讲就更好了:)政府工作报告里大篇幅回顾了2015年的工作,当时恰好在策划聊聊架构下周的内容,突然灵感一现,为何我们本期的内容不以去年的变化和趋势为切入点,谈谈架构的优化了?于是乎,便和当当网的史海锋老师策划了本期内容。

  欢迎关注聊聊架构微信号,获取更多精彩架构内容,下周我们将会发布《架构漫谈》系列文章的电子书,敬请期待!

  随着移动互联网的进一步普及,网上消费购物比例不断提高,电商网站的系统规模随业务快速增长,承载每天数以万计的交易已经是主流电商网站的常态。

  几年前618、双十一、双十二标志着电商进入促销常态化和大规模活动化阶段,前两年则是主打无线APP购物,那么2015年,电商行业在业务模式上呈现出了哪些特征?我觉得可以简单总结为4点。

  渠道拓展

  移动互联网时代,流量入口愈加分散,催生出诸多导购引流的APP,电商公司需要具备对接多种渠道的能力,还要结合技术趋势,开通微信公众号,甚至是入驻其他零售平台、分销平台,打造更多的垂直频道,充分吸引流量。

  实时交互

  随着大数据实时计算技术的成熟,当用户在线时,根据用户画像和行为进行实时交互,结合业务活动提供精准的个性化即时服务,不浪费每一毫秒,提升客户体验,提高客户粘性。

  功能聚合

  在每一个用户打开的界面提供尽可能多的功能和信息,典型的是单品页,现在堆满了各种链接,显示能够使用哪些礼券、有哪些种促销和服务,甚至商品副标题也会嵌入活动链接。竭尽所能利用流量,提高转化。

  精细运营

  营销越来越复杂,对运营的要求相应提高,运营人员必须了解每一个操作之后的效果是否符合预期,摸索对于不同的季节、地区、时段、客户群体、商品品类最有效的营销手段。

  架构优化实践

  在这样的背景下,当当网通过以下几个方面来适应变化,并推进架构优化。

  第一,对技术部组织架构进行调整。

  将原来的职能化组织中的产品、研发和测试部门按照产品线进行整合,转型为Unit化,以加强同一产品线不同职能团队之间的配合协作,沟通更高效,团队更为聚焦。

  这样的组织结构更易于应用敏捷,与实施敏捷的前提同理,产品线拆分建立在系统架构解耦基础之上,在这一点上,系统架构与组织架构异曲同工且相辅相成。解耦越充分,系统边界越清晰,模块越小,越适合敏捷团队,能够快速响应业务需求。

  业务相近的产品线组成一个产品研发部,这样多数的小型需求在部门内就可以解决,面对紧急项目还可以灵活使用人力资源,并为员工创造接触更多类型业务需求的机会。

  第二,系统分层依赖。

  随着业务逻辑越来越复杂,系统越来越多,相互依赖也越来越多。比如我的当当中就聚合了安全中心、用户、账户、订单、收藏夹、推荐等多维度的信息,需要调用多个系统服务。经过讨论,决定将用户交互层面的前端页面与原有的后端系统拆分,并入前端的产品线,以便为用户提供更好的服务。

  而后端系统之间的依赖关系也需要更为精细的分层定义,对于促销系统,需要会员系统、订单系统、价格系统提供基础数据;对于运费系统需要商品信息和配货数据,而在精准定位销售区域的前提下,库存只是配货的基础数据,配货系统负责判断是否有货,Promise则根据配货结果计算预计送达时间。

  调整系统之间的关系是很难的,牵一发而动全身,但重构是契机,2015年,对于电商的核心系统交易和促销进行了重构,同时价格、配货、运费等系统也进行了较大调整,从而使系统间依赖问题得到了明显改善。

  第三,服务化。

  微服务为互联网行业的服务化指明了方向,也坚定了我们进行服务拆分和解耦的决心。

  原有的架构以系统为维度,服务归属于明确的系统,而系统的划分一般以业务功能为聚合,随着业务的发展,新的业务功能层出不穷,总会有一些打破原有的系统边界,给架构提出难题。

  服务化,不仅是指系统将能力通过服务对外提供,更重要的是服务本身就是承载业务功能的单元,如果有组合了多个逻辑难以归入某系统的服务,不必纠结,作为独立的业务模块开发就是了,以服务为单元,系统架构更加扁平,简单清晰。

  微服务架构中,服务粒度会更小,服务治理的需求更加迫切,更需要技术手段解决,比如分布式服务框架,当当使用的是基于Dubbo二次研发的DubboX,以及结合ddframe实现的服务调用监控。

  去年的容器技术爆发,为微服务架构实施提供了有力工具,当当内部也在部分系统使用了Docker。

  微服务大势所趋,秉承SOA理念,在服务治理中心的基础上,将系统弱化,提供更多的基础服务,提高了系统的复用性和灵活性。

  第四,平台化。

  平台化包括两个维度,技术平台化和系统平台化。

  技术平台化是指在技术层面建立统一的体系,包括根据行业特点进行技术选型,使用稳定可靠的技术组件。

  当当从2012年开始将原有的.net平台向Java平台迁移,从封闭到开源,应用电商行业的主流技术栈,到2015年,基本完成了技术转型,主要后端业务系统都转移到Java平台。

  经过数年的积累,2015年当当架构部研发了Java应用开发框架ddframe,目的是分离技术和业务,封装技术细节,将应用开发人员的精力集中在业务开发上。

  随后再接再厉,当当架构部又推出了用来替代TBSchedule的分布式作业调度框架Elastic-Job。并将之开源,基于JDBC的分布式数据库中间件Sharding-JDBC也在开发中。

  统一的技术栈,能够复用技术资源,持续积累整体的研发能力,为做精做专提供更好的基础条件。

  系统平台化是指搭建基础平台,包括测试平台、分布式服务平台、自动化运维平台、监控平台、缓存集群、消息中间件平台、大数据处理平台、项目管理系统、日志平台、问题跟踪系统等。

  基础平台是各业务系统有机协作的基础,保证了整个技术架构的全面可控,能够降低系统运维复杂度,是大型电商系统不可或缺的组成部分,良好的基础平台是技术实力和管理能力的双重体现,而多数公司更注重业务,会在基础平台建设方面欠下许多技术债务。

  2015年,当当搭建了自动化运维平台Pangu、监控平台Radar,重构了项目管理系统,Redis集群管理平台也在搭建中。

  第五,核心系统重构。

  在电商业务发展的快节奏之下,核心系统持续迭代是常态,而且基本两、三年以上,就需要考虑重构,否则难以支撑业务的快速变化。

  另外,系统重构集中梳理业务逻辑和系统依赖,整理统一的文档,剔除无用功能,归并多个版本,甩掉历史包袱重新设计架构,适度的前瞻性设计使系统在一定周期内具备业务扩展性。

  2015年,当当完成了交易系统和促销系统进行了重构。

  交易系统在2015年10月底完成新老版本切换。重构耗费约1500人天,重构代码17万行,全部切换至Java开源技术架构,为公司节约大量成本,并进行了架构优化,整体性能平均提升25%,经受住了双十一和双十二的考验。

  在当当,有一些“类促销”业务,从广义上可以归入促销范畴,但业务与数据均不属于促销系统,在促销系统重构设计中,我们考虑将这类业务逐渐回收;另外,促销系统能不能承担一些营销的功能?带着这两点考虑,在促销基础上进一步抽象出活动模型。

  打造内部应用框架

  当当技术部现在是按照产品线划分的,一个产品线的产品、开发、测试都在一个部门,但像项目管理、运维、架构这些技术体系中公用的部分是独立的部门。架构部里主要分成三部分,一个是架构与规范,一个是性能测试,一个是基础应用系统研发。

  我们花了比较多的精力在技术架构上,去年我们在Dubbo上做了二次开发,做了DubboX并且对外开源,业界反馈还不错,包括很多来面试的人都知道。

  我们的技术体系、核心业务系统明确的方向是Java,去年年底,我们开始做一个基于Java的应用开发框架,DDFrame,用它去对接一些核心组件,包括SOA、作业调度、缓存、消息队列、数据库、配置中心等,现在已经发布了2.0版本。虽然受限于资源,进度比较缓慢,但我们一直在做这件事,未来也会慢慢完善这个框架,使其成为技术体系的核心。

  架构师并非必需品?

  我在上大学的时候学的就是计算机,但没学过系统架构方面的课,也没听说过架构师,之前做项目的时候也很少有专门的架构师角色。一般来讲,系统比较简单的话,并不一定要有架构师,当系统更为复杂,才需要有人在更高的视角上去关注整体性的东西,这也是系统规模不断发展的结果。 所以,我们可以认为,架构师并不是一个必需品,甚至不同公司架构师的职责都不太一样,并没有一个非常明确的定义,但整体来讲,架构师需要关注整个体系中方方面面的东西,还需要去解决一些关键性的技术难点,并需要有更为长远的考虑,这个是共识。

  架构师与工程师之别

  架构师与工程师之间的差别并不在于年纪 ,而是在于视角的不同以及各方面积累的差别。

  首先是意识。作为架构师,不能仅仅关注怎么去实现一个功能,还得去琢磨为什么这么做、怎样才能做得更好、应该在什么场景采用什么样的技术方案等问题。另外还得去关注测试、部署、项目管理的方式等方面,甚至要去了解用户的需求、公司业务的需求。如果一直考虑这些事情,时间长了、经验多了,就会有比较好的整体概念或视图在脑中,综合素质会得到提升,明白功能只是最基本的,系统的可用性、稳定性、可扩展性更为重要。

  其次是积累。IT技术一直在演进,全世界无数人的不断研究与实践成就了技术的提升与进化。作为技术人,需要关注当前最新的技术、架构、解决方案、技术理念等,理念可以用不同的技术来实现,也一个不断进化的过程。而作为架构师,承担的是更重要的角色,他的决定会影响到更大的团队或体系,所以就需要有足够多的相关知识和技能,以及足够广的视角,而这些都需要架构师平时不断的积累。我每年大概会看20多本书,技术相关的大概一半,另一半主要是社科类、经济、历史、管理之类的,对提高架构思维很有帮助。

  再次是责任感。之前提到,架构师承担的是更重要的角色,他的决定会影响到技术选型、系统架构、具体实现的方案甚至系统发展的方向,所以架构师需要有很强的责任感,要对技术团队负责,需要发挥自己的影响力,做很多沟通、协调、支持的工作。

  最后是兴趣。在我看来,人是受限于他的性格、兴趣、天分这些因素的,会不自觉地去靠近他更喜欢、更擅长的方向。所以,到底是当工程师还是架构师,或者其他角色,也是要看兴趣的,有的人就是喜欢解决技术难题,就是喜欢具体的模块实现,不想牵扯太多精力去考虑其他的方面,那么也不见得非要当架构师,只是分工不同,业界也有技术专家、研究员这样的角色。

  架构与管理相通

  之前架构师大会上经常有人说,没有最好的架构,只有最合适的架构。确实如此,作为架构师,很多时候,技术上的东西可能跟程序员差不多,但差别就在于能不能以更大更广的视角去看待问题,而非仅从自身角度出发。

  视角变大之后,所要关注的东西就会变多,变量、变数也会更多,很难理想主义,很多时候都需要做出妥协或者说平衡,到最后就会发现,架构和管理在很多时候是相通的。

  管理是在一个有限资源、确定时间点、明确目标的情况下,尽可能达成目标,过程中需要考虑轻重缓急,需要随时调整以适应现实变化,以完成目标为首要考量。

  架构也是如此,需要考虑的是宏观上的方向性的问题,是各个部分之间的平衡关系,是如何配合才能达成最佳效果,而非仅仅是短期目标而达成,也不必纠结于细节的完美。

  这些年,管理、架构都发展出了很多的理论,虽然行业、环境一直在变,但却也不能直接断定它们是不是合适,需要学习的是其中的思维方式,具体的问题具体分析。

  IT是条不归路

  有这样的感慨是因为IT行业发展实在是太快了,覆盖的领域也越来越广。前两天刚好面试了一个候选人,40多岁,传统IT领域的,能力很不错,在原来公司也做到了挺高的职位,但他不熟悉现在互联网主流的东西,面对的也是不同维度的需求,思路对不上,就很难符合我们的要求。每次见到这样的老大哥,心里都有很悲凉的感觉。

  IT人的能力和价值是基于技术的,一旦跟不上技术进化的脚步,或者当初所选的领域成为夕阳领域,职业道路就会面临转折。这也是我之前换工作的原因之一,一直在原来的公司干下去的话,真的会失去竞争力,很有危机感。

  尤其对我们这一代做IT的人来说,前面没有多少人走过这条路,没有借鉴之处,真的不知道十几、二十年后,我们的未来会是什么样?我们这些年的摸索,也是给后来者趟路,现在刚毕业的二十多岁的年轻人,就能看到未来的方向,知道自己十年之后大概会是什么样的,但我们真的一直都不知道。

  不过,既然选择了这一行,就只能持续关注行业发展,不断提升自己,多学习、勤思考,努力走出一条路来。

  嘉宾介绍

  史海峰,当当网架构师,技术委员会成员,EGO会员。

  2001年毕业于北京化工大学计算机科学与技术专业,曾在神州数码、亚信联创长期从事电信行业业务支撑系统集成工作,参与中国移动、中国联通多个项目,具有丰富的大型业务系统研发实施经验。

  2012年加入当当网,负责总体架构规划、技术规范制定和技术预研推广,善于把握复杂业务需求,提出创新性解决方案,参与了近年当当网多个重点项目的方案设计,在项目中对系统架构进行持续改造优化。负责技术委员会组织管理工作,发掘最佳实践、推动技术革新,组织内外部技术交流。

点击立刻咨询