小米网技术架构变迁实践.docxVIP

小米网技术架构变迁实践 张涛 2021-12-29 第一代的小米网架构格外简约，如图1所示。 图1 第一代小米网架构 我们实现了一个最基本的电商网站基本组件：在线销售系统、订单处理系统、仓储和物流系统，其中物流只对接了兄弟公司凡客的子公司如风达（现已独立）。全部的业务系统共用一个数据库。这样运转了几个月，发觉网站访问量越来越大，当有新品销售时，面对突然激增的大量访问，数据库压力陡增，形成后端业务系统几乎无法使用。 2021年上半年，在小米网运转半年多后，我们打算将业务系统进行拆分，首先将销售系统剥离，之后逐渐将越多越多的子系统拆分。拆分后各业务系统相对独立，各自使用本人的数据库，这样就完善处理了不同系统抢占数据库资源的问题，也让模块更清楚，程序员也能专注于本人担任的业务系统的开发，如图2所示。 图2 拆分业务系统 这种结构随着小米网子系统的增多，只运转了几个月，我们就发觉灾难开头显现了：我们需要维护的接口越来越多。系统间接口调用图变成了图3这样。 图3 系统间接口调用图 这张网越来越简单，从而使系统越来越难以维护，问题层出不穷。为了让各子系统尽量解耦，我们开发了小米网异步消息服务系统（Notify），让它作为全部子系统异步通信的两头人，全部子系统只需与两头人通信，接口标准化，将网状结构变为星状结构，大大降低了系统间通信成本，提高了开发效率，如图4所示。 图4 小米网异步消息服务系统（Notify） 此时，我们各子系统的网络架构也进行了相应的升级，大体分三层：调度层、业务层、数据库。在调度层，我们次要使用LVS、HAProxy做流量转发和毛病转移；业务层则五花八门，不同言语，不同框架百花齐放；数据层次要使用MySQL、NoSQL存储及缓存服务（Redis和Memcache）。 经过以上改造，我们从结构上，让整个流程更清楚了。然而，流量在连续增大，特殊是小米网的爆品格外多，由于供应链及硬件产业特性，导致新品上市时供应量无法满足用户需求，用户的热忱又远超我们的期望。大量恳求导致前端销售系统的数据库开头告急。我们急需实行一种方案，将峰值抹平。我们是一家电商网站，在买卖时会有大量在线联机事务处理，对数据全都性要求极高，所以经过争辩，我们打算接受淘宝开源的数据库两头件产品Cobar来实现数据库的水平切分。一共部署了32个实例，按用户ID实现数据的均匀读写，每个实例都做了MM双主高可用实现，如图5所示。 图5 接受淘宝开源的数据库两头件产品Cobar 这种架构保证了我们日常的在线销售稳定运转无压力，但是，每逢严重产品发布时，仍旧要面对数百万QPS的抢购并发压力。不光是对数据库，对前端的应用程序服务器一样形成巨大的冲击。非抢购时间和抢购时间的流量差距可达几十倍到上百倍，假如我们按抢购峰值流量部署服务器，那将是一笔巨大的硬件资产铺张。在这个背景下，我们组织特地的人员开发了小米网的大型秒宰系统：BigTap。其实道理很简约，大家都去银行办过业务，在银行窗口排队的多，但是我们几乎很少看到有人在银行的取号机面前排过队。大秒系统其实就是充当银行的取号机的角色。它的业务规律格外简约：判定用户能否合法，合法则给这个用户购买资历，用户抢购成功；不合法则拒绝用户恳求，抢购失败，如图6所示。 图6 小米网的大型秒宰系统BigTap 由于平常不抢购，大秒系统没有任何流量，所以，我们将大秒系统全体迁移至AWS云上，抢购前一天，将系统扩容，抢购后，将服务器再下架，实现完善伸缩，大大节省了成本。 除了大秒系统以外，我们还额外开发了众多小米网特色服务以支撑本人的业务。其中之一就是基于Redis和Twitter开源的Twemproxy开发的小米通用缓存服务（内部代号MCC），集群中单节点达到14万QPS，支持自动分片，热加载，全Redis协议支持。由于MCC支撑了小米网全业务线的缓存服务，所以我们还将此服务设计成双机房高可用架构，如图7所示。 图7 小米双机房架构（图中M表示主Redis实例，S表示从Redis实例） 常态下，双机房同时工作，读写机房1的主和从实例。机房2的Mi-Twemproxy也读写机房1的主从实例。当机房1毛病时，只需修改机房2的Mi-Twemproxy读写机房2的从实例，并将此实例提升为主实例。当机房2消灭毛病时，不需要做任何改动。不足之处是当机房1消灭毛病时，机房2短期内只要一个主实例工作，无冗余。 在搭建电商网站中，我们还要时辰考虑的一个业务问题是：如何尽快地将货物售出，实现最快的库存周转，同时还要有好的购物体验，在这个问题上，库存系统的设计是一个很大的挑战。我们尝试考虑过很多电商的做法：按仓库库存卖商品。这种设计的好处是：仓与仓之间不用调拨，省去物流费用。缺点是，可能某个仓库存过高卖不出，某个仓又缺货，导致用户无法下单购买。最终导