当当网的技术架构设计和解决方案

个人简介 史海峰，当当网电商平台架构师，技术委员会成员。2001年毕业于北京化工大学计算机科学与技术专业，曾在神州数码、亚信联创长期从事电信行业业务支撑系统集成工作，参与中国移动、中国联通多个项目，具有丰富的大型业务系统研发实施经验。2012年加入当当网，负责总体架构规划、技术规范制定和技术预研推广，善于把握复杂业务需求，提出创新性解决方案，参与了近年当当网多个重点项目的方案设计，如招商平台重构、尾品汇、礼品包装、一品多促销、区域促销码、虚拟捆绑、纸电打通、手机专享价、入驻天猫二期等，在项目中对系统架构进行持续改造优化。负责技术委员会组织管理工作，发掘最佳实践、推动技术革新，组织内外部技术交流。

全球架构师峰会（International Architect Summit，下简称ArchSummit）是由InfoQ中文站主办的一次全球性架构师峰会。ArchSummit专门针对架构师人群，讲述与架构和架构师相关的各方面趋势、技术和案例。这也是继QCon之后，InfoQ中文站主办的又一次高端技术盛会。

   

1. 大家好，我在ArchSummit大会现场，今天很高兴邀请到当当架构师史海峰接受我们的采访，首先请海峰介绍一下自己吧。

史海峰：大家好，我是2012年加入当当网的，负责电商平台的系统架构。我之前主要是在做电信行业的集成，也是关注比较复杂业务的耦合，以及整个技术体系的实现。我在当当这边主要负责的是这几部分，一个是对整个技术体系的规范的确立以及执行，还有是整个技术的架构规范，我认为在架构这个层面必须要关注的东西，架构怎么去指导设计。对于一些比较重大的项目要参与设计具体的解决方案。我还要做一些落地的事情，包括一些技术的预研，一些推广，还有一些对外的技术交流。

   

2. 我们近年来看到越来越多的中型电商也在开始向大型互联网公司和软件公司看齐，学习技术规范化的一套体系，而它们以前的技术发展都相对比较野蛮务实的路子，有点像从野战军变成正规军一样，你能介绍一下当当网开始做这件事情的一个背景吗？

史海峰：这个也是一个自然而然的事情，原来公司人比较少，其实规范就是靠领导，或者是靠部门，各个部门自己有一套规范，这样的话公司运转起来是没有太大问题的。如果说技术团队已经上规模了，比如说几百人，甚至像很多公司现在已经上千人、上万人，这就必须要有一套规范化的东西来降低大家沟通的成本，对于运营维护和持续开发成本也是需要我们考虑的。如果没有规范，回头再去看，可能一套系统或者一个软件很多人都已经做过了，每个人的风格可能都不一样，对于接手的后来者就是一个很头疼的问题。比如说我们的订单系统，现在有400万行代码，如果有一套比较成熟的体系把它承接过来，就算我们把代码降低到百万行，如果不是一套遵循着某种原则， 百万行代码也很难维护的。所以大的技术体系的建立必须要有规范，才可能逐步、平稳地过渡，否则就会逐渐失控。很多人可能有一个问题，觉得规范管得太多，管得太严，管得太死，所以我们的规范也是在逐步一点点建立，而不会说上来就给一个特别强的规则。

   

3. 请介绍一下招商重构这个项目的情况吧。

史海峰：好。大概在2007年我们就做了一些招商平台的入驻，这个功能当时还比较简单，而且团队的负责的人也不多。后来随着商家入驻，业务增长越来越快，整个的承载量就扛不住了，出了很多问题，架构非常常见的问题就是原有的架构已经不能去承载现有业务的增长。比如有些系统一开始设计时，承载的是百万级的，现在业务量变成千万级，这个架构就必须调整。在2012年，我们做了一个开放平台的重构，这个重构从8月份开始立项，真正重构完成大概过了半年的时间，最后是做迁移，又迁移了好几个月。我们把重构作为一个独立的项目来做，并不是说做完一点就替换一点，最后是把整个系统重做了一遍，然后上线时是按照商家来迁移数据，然后切流量。对原有的系统影响要少一些，我们一开始是把所有原有的功能点整个梳理了一遍，这个过程是由产品来牵头，技术相对来说要考虑怎么把原有的那些东西落实下来，甚至发现原有的架构上的那些问题，这次怎么解决它，这个是我们前期准备的过程，把这些东西都搞定了，再去考虑将来的一些前瞻性的东西，将来业务扩展应该支持哪些东西，这个我们也借鉴了亚马逊或者京东当时的一些模式，怎么去接更多的商家，来做不同的对接方式。这个在前期我们都考虑了，但是后期做的时候其实是做了一些减法，因为不可能把这些东西无限扩大，你一开始去梳理业务，去搞一些未来需求的调研是可以扩展的，但是落地时就要做一些减法，所以做减法时我们就在架构上保留了原有的这种设计上要考虑的东西，在功能上其实没有做太多额外的东西，就把原来的功能承接过来，然后去实现它。这个过程后续就是用一套体系把它整个做起来，而且当时是第一个用Java去实现的比较大的一个系统，当时也是遇到了很多问题，这个团队也是加班加点做了好几个月，的确比较辛苦。后来系统做完之后就涉及迁移，两套系统是新旧并行，并行之后新的上面没有任何业务，怎么来切业务呢？把一些商家的数据迁移过来，跟这些商家先提前打好招呼，他们迁移过来数据之后，再让他们第二天登录一个新的界面，新入口，操作的东西就完全隔离开，后面对接的其他系统其实是没有变化的，所以只是前面分开两个系统，而且是在登录的层面，数据管理都隔离开。这样对于多个流程中的耦合不会有太大的影响，因为是完全一套新的。只不过就是商家需要培训，需要有一个前期的准备工作，整个的迁移过程还是比较平稳的，毕竟这是一个比较友好的方案。

   

4. 能不能介绍一下当当内部发掘最佳实践的一些经验？这些最佳实践又是如何推广的？

史海峰：是这样的，今年我们搞了一个技术委员会组织，这是一个半官方的组织，我们希望它不具备更高的官方的色彩，更倾向于让技术的人员接受它。以这种半官方的组织来组织一些新技术的调研或兴趣化的实践。如果用官方的方式来比赛，看谁做得最好，拿过来大家用一用，大家可能觉得是敝帚自珍似，觉得我的拿出来之后别人觉得不好怎么办。我们用这种半正式的，不是特别官方的方式去收集，如果你觉得自己做的东西是一个相对来说有一定的通用性，你可以把它拿出来分享一下。首先来分享一下，接下来再推广一下，如果别人觉得这个东西挺好用，我可以来找你了解一下，如果真的想去用，你可以来支持我。这是一个比较线下的，不是那种特别强的推广方式，这个方式大家会更容易接受一些，也不用担心更多的风险责任。比如说我们之前发现了一些生产环节上的问题，以前启动应用的时候，发现日志不全，但又担心太全之后，启动系统之后影响性能或者占用太多的磁盘空间。我们就做了一个小的调整，就是做了一个开关，在启动系统的时候是打一个高级别的日志，一旦应用启动完成，日志级别就会降低，这个其实是一个很小的技巧，跟业务逻辑是没有关系的，是可以推广使用的，只不过做的人做完了就完了，未必会把它拿出来，而最佳实践的方式就是，我们召集大家来，看看大家有没有这些小东西可以拿出来共享，哪怕它很小，但是这就是一点点积累起来的东西，大家都可以拿出来说。如果没有太多可说的，那你就把代码贴出来，写一个说明，感兴趣的人就去看，然后推广。我觉得这是一个氛围，最佳实践大家都希望，第一，我有好东西，想拿出来给大家看看。第二，我想看看别人有什么好东西，如果这个氛围建立起来之后，就会形成一个良性的循环，但是这个过程中也会有一些可能适用性不是很强的，但是我觉得可以接受，肯定要有一个筛选的过程。

   

5. 最后请介绍一下你在明年的一些规划吧。

史海峰：主要说一些关于架构这个层面的吧，我们现在还是在持续的对架构的演化做一些规划的东西，但是明年其实是一个落地的过程，不管是在系统的业务的架构层面，还是说技术层面，都是要有一个落地。业务层面是这样的，我们会要求各个系统去匹配成熟度，看看哪些方面不满足，然后提出自己的优化计划。我们要从技术这个层面去推动各个系统不断完善自己已有的架构，我们不能一直忙着实现那些业务需求，忽视了原有架构的优化，把资源都耗在了满足需求的层面，这就会造成一个恶性的循环。一开始既然不优化，用最快的方式，比如说用一些临时方案，用一些原有架构不太支持的方式，先凑合着把需求实现了，接下来业务会不断用这种方式要求你，不断要求你在短时间内完成他们想要的需求，接下来的问题就是，如果一直都满足他们的要求，架构就会越来越散，而且越来越重，贴了很多狗皮膏药一样的东西，这样的话再做新的东西就会有很多包袱，就很难再轻易的满足他的需求，还不如一开始就把这个东西想清楚，然后做好扩展性，新的需求就比较容易实现，这就是一个良性的循环，良性的循环就是不断在这个过程中打基础，去调整架构，这个是各个系统明年要关注的事情，我们会投入更多的资源去做这种系统架构的优化。 还有一件事情，就是技术层面的，我们现在在做几件事情。一件事情是应用框架，我们要做一个在Java上统一的开发框架，预计在明年过年前，有一个可用的版本，我们会逐步用它来替代各个现有的部门自己衍生出来的东西。而且我们会对通用的东西做一些很好的封装，不管是日志、监控这些东西，避免大家再去做这种比较基础化的东西，浪费人力资源。其实做这种通用的东西就是为了节省资源，提高效率，降低成本。另外我们还会推进虚拟化，比如说一些公用的偏重于PaaS平台的东西，比如说缓存的平台，或者说是消息的平台，就是在技术层面夯实架构的体系基础，再考虑上面怎么去支持更灵活的应用架构，以上是我们更关注的两大方面。其他的还是日常的工作了。