閱讀本文約花費: 13 (分鐘)

2018 年 ArchSummit 全球架构师峰会上，薛珂分享了唯品会基于 ElasticSearch 开发出自己的统一检索平台的话题，很受技术人员关注。2019 年 7 月，薛珂升任唯品会中间件团队负责人，统帅包括服务化、消息服务、数据访问中间件、检索平台、任务调度和数据管道服务等团队。从架构师到团队负责人，经过这一年的历练，在技术上有哪些沉淀，在团队管理上有哪些心得？

InfoQ 就此采访了薛珂，希望向读者展示一个鲜活的技术人，除了技术，还有工作价值的思考。（薛珂也是 ArchSummit 全球架构师峰会 · 2020 深圳站“服务化架构”专题出品人）

1个人发展

从架构师一路走来，到目前唯品会中间件团队负责人，薛珂用更形象的“点线面”方式来描述个人在工作技能上的提升，以及在思考问题的方式方法上的变化。

“点”

初任架构师时，他最开始关注的是“点”，也就是某一个领域的具体问题点，比如解决数据访问层的标准化和治理问题，解决任务的调度和执行问题；

“线”

到后来关注“线性”问题，比如整个服务化体系的共同协作问题，服务化体系要真正发挥作用，要在服务治理、配置管理、开发框架、测试框架、调用链治理和发布系统共同发力，形成有机的整体；

“面”

再到后来站在面上思考问题，比如基础技术的发展趋势，基础技术趋势如何与公司业务发展趋势相契合，再进一步，关注公司当前技术体系所面临的主要技术挑战以及应对策略。

有观点认为，一些技术人转做管理之后，大部分的精力用在了沟通上。而薛珂则认为，技术工作永远是主线，技术工作的内容很多，从技术趋势的研究，新技术方向的学习，基础产品演进方向的思考，到技术方案的选型，再到工具框架的评估，代码规范和开发语言的考虑，差不多 70% 的时间还是在做技术。

而技术工作内容中主要是帮助业务团队解决问题，在唯品会也一样，基础架构团队通常不会直接面对具体的业务问题，他们服务的对象的是业务开发团队。一个基本原则是让业务开发团队专注于业务，把一切技术问题交给基础架构部门。

与业务团队解决问题的协作方式有三个途径：

一是架构评审，架构评审其中一项关键职能是保证公司基础技术产品合适地在业务团队使用；

二是基础技术产品使用上的支持和培训；

三是专家团队，专门负责帮业务团队解决疑难杂症，跟踪处理线上的复杂故障。

每年电商大促活动，都能看到朋友圈里各公司的技术人在忙忙碌碌熬夜加班，那是不是除了大促，他们平时的工作是不是都在为 618/ 双 11 等大促作活动做准备呢？薛珂说，大促是考验基础架构水平和成果最重要的途径，也是基础架构最主要的价值之一；但唯品会目前对大促相关的基础技术准备工作已经相当成熟，所以平时工作会关注在如何提升公司技术体系的工作效率，降低技术复杂度和使用成本。

好的制度是一个公司运转下去的基础。

正如这次疫情期间，唯品会员工多数时间还是远程办公，远程会议；由于团队有良好的沟通协作机制，包括每天的 stand up meeting 和敏捷开发模式，团队的同学职责任务非常清晰，所以这次疫情并没有影响基础研发团队的正常工作。

2技术贡献

2016-2019 年之间，薛珂一直在主导唯品会两项基础平台 Saturn 和 Pallas 的研发、推广以及开源社区的维护。核心设计是最大挑战之一，对于这两项基础平台的核心设计理念，以及当时的评审过程，薛珂也做了介绍。

Saturn

Saturn 是一款任务调度系统，它的核心设计理念是任务调度的平台化，在没有 Saturn 之前，唯品会的任务调度实现方式各种各样，并且多数是嵌入到其它类型的应用中去执行，对于任务的发布、扩容、监控、高可用、权限控制都无法集中处理。

Saturn 通过平台化方式统一管理公司全部的任务，并将任务这种应用与在线应用区分开，引进了统一的开发、测试、发布、监控、上线、调度的流程和工具，大大简化了开发的复杂度和线上问题定位的流程。

Pallas

Pallas 是统一检索平台，它的核心设计理念同样是平台化和标准化。

简单来讲，通过引入一系列的管理、使用、配置、监控、发布、运行标准、流程以及配套工具，将检索系统的使用统一化和标准化，并且提供便利的接入和最佳的使用实践。

内部评审主要考虑点在于平台建设的成本和收益，任何项目都要经过这两个“灵魂拷问”。事实上，无论是任务和检索，由于标准不统一引发的开发、测试、扩容、线上故障的成本在唯品会已经非常高额，平台化建设的要求呼声很高，因此并没有遇到太大的阻力，两个项目的落地称得上是“万众期待”。

大促前的技术准备

一般在大促或者节假日，电商网站流量加持、技术问题容易被放大，尤其是服务端内部挑战：硬件层面的采购、部署；服务器增加对基础架构的挑战等。这些问题基本上大多数团队都遇到过，唯品会每次大促前一个月，都会由大促委员会推进大促相关的技术准备工作：

依据 BI 部门对销售的预估，结合以往促销的销售情况进行容量整体评估；

随后各个技术环节会根据整体容量情况进行拆解，并做相应的压测和提前扩容；

基础架构在每次促销前会做系统性整体复盘，针对可能影响促销的问题推进业务系统的全线升级，一些长时间运行的系统会考虑在促销前提前重启释放内存，核心链路会根据容量上限准备好相关的降级预案并做提前演练。

唯品会的架构演进

唯品会近几年经历最大的架构变化是2014 年开始从 PHP 转换到 Java 体系，引入了服务化架构。随后在 Java 体系的框架内打造了一系列的中间件，来逐步丰富基于 Java 的分布式架构体系。

2018 年，公司进一步引进了云平台，并且逐步与现有的分布式架构进行深度的融合。

从长时间跨度来看，大概 4 年左右会经历一次较大的架构升级。旧架构的改造通常是随着业务的变化和业务系统的升级而逐步替换的。对于唯品会这样的电商公司，业务模式的变化非常快，业务系统的演进频率会远高于架构的升级频率，因此技术团队可以适当在业务系统升级的节奏中加入架构升级的一些措施，算得上是边开车边修车，这是一种线性演进过程。

2014 年的大促 419 活动期间，因为 RabbitMQ 中间件出问题，导致系统出现雪崩效应。那次的教训确实很惨痛，暴露出来一个严重的问题就是对开源产品的认识不足。

薛珂说，当前中间件团队设计中间件，首要考虑的点是开源和自研的权衡。在开源产品的选择方面，只选择主流的、成熟的、社区活跃的、代码质量特别好的开源产品，并且一定要投入足够的资源掌握它的核心源码；例如 Saturn 是在 Elastic Job 的基础上重构而成的，Pallas 是对 ElasticSearch 进行了深度整合和理解后推出的；消息服务 VMS 经过了多年的打磨，最终将全部精力投入在 Kafka 引擎的深度掌握，逐步会抛弃其它引擎。

在工具、框架、技术等方向上，薛珂带领团队开始走自研道路。

目前唯品会有自研的服务化体系，包括 API 网关、服务治理平台、配置中心、分布式协调服务、服务化框架、统一鉴权等，当前承载着唯品会的软件开发架构，3000+ 服务，2 万 + 实例，高峰期调用次数达千亿每小时，QPS 过百万。自研的任务调度平台管理着唯品会全部 14000 多个 Job 的执行和调度。自研的任务调度平台承载着包括商品搜索在内的关键业务，300 多份索引，100 多 T 的数据。VMS 承载着全部异步消息的流转，有 100 多个集群。自研的数据访问中间件和数据管理服务也全面应用于核心的业务场景。

3从行业中获得的想法

安安静静的技术人，一般也都喜欢看书，尤其是 SOHO 办公的这个阶段，薛珂在看两类书，一类是技术类的，目前在系统性地学习机器学习和 NLP，以及经典课程；另一类是关于思维模型，比如《领导力与新科学》、《疯传》、《乔布斯传》等。通过跨学科阅读，可以了解大师关于世界的看法，思考问题的方式，读好书等于跟大师对话，对于解决自己遇到的实际问题是极有启发的。

薛珂以前认为工作的最大意义是赚钱和养家糊口。而现在看得多了，经历得多了，收获多了以后，会更加追求个人价值的体现。个人价值体现最好的方式是通过在工作上的努力最终借助好的平台去实现，把工作要求和个人兴趣结合起来，找到合适的位置，坚持学习和提升，逐步去尝试那些能够影响更多人，更能直接产生社会价值的事情。

纯技术出身的薛珂，总觉得手头有几把刷子心里才更有底气，而且技术上值得探索的地方太多了。所以对于技术和管理的发展规划路径，薛珂很纯粹的说会选择技术路线。另外，他认为技术团队的管理，本身并不是一件特别复杂的事情，因为技术人员大多为人比较简单直接；做技术管理，眼光要站得更高一些，要能够看得到技术趋势和业务趋势，能够看准前进的目标，做出合理的规划，这本身需要有深厚的技术底子做基础，并且思想上要与时俱进。