老史聊架构：当当网架构优化的几点心得

我想这两天大家或多或少有在看李克强总理的政府工作报告，我也在电视旁愣着算是看完了全程，看完有个感受想反馈，要是总理的报告能和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的人来说，前面没有多少人走过这条路，没有借鉴之处，真的不知道十几、二十年后，我们的未来会是什么样？我们这些年的摸索，也是给后来者趟路，现在刚毕业的二十多岁的年轻人，就能看到未来的方向，知道自己十年之后大概会是什么样的，但我们真的一直都不知道。

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

嘉宾介绍