『InfoQ』从架构师到唯品会中间件负责人，我对技术的那些思考( 二 )

SaturnSaturn 是一款任务调度系统，它的核心设计理念是任务调度的平台化，在没有 Saturn 之前，唯品会的任务调度实现方式各种各样，并且多数是嵌入到其它类型的应用中去执行，对于任务的发布、扩容、监控、高可用、权限控制都无法集中处理。
Saturn 通过平台化方式统一管理公司全部的任务，并将任务这种应用与在线应用区分开，引进了统一的开发、测试、发布、监控、上线、调度的流程和工具，大大简化了开发的复杂度和线上问题定位的流程。
PallasPallas 是统一检索平台，它的核心设计理念同样是平台化和标准化。
简单来讲，通过引入一系列的管理、使用、配置、监控、发布、运行标准、流程以及配套工具，将检索系统的使用统一化和标准化，并且提供便利的接入和最佳的使用实践。
内部评审主要考虑点在于平台建设的成本和收益，任何项目都要经过这两个“灵魂拷问” 。事实上，无论是任务和检索，由于标准不统一引发的开发、测试、扩容、线上故障的成本在唯品会已经非常高额，平台化建设的要求呼声很高，因此并没有遇到太大的阻力，两个项目的落地称得上是“万众期待” 。
大促前的技术准备一般在大促或者节假日，电商网站流量加持、技术问题容易被放大，尤其是服务端内部挑战：硬件层面的采购、部署；服务器增加对基础架构的挑战等。这些问题基本上大多数团队都遇到过，唯品会每次大促前一个月，都会由大促委员会推进大促相关的技术准备工作：

依据 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 多个集群。自研的数据访问中间件和数据管理服务也全面应用于核心的业务场景。