小米Notify系统的设计及其演化和升级变迁

摘要：本文首先介绍小米网系统架构的发展变化，然后介绍Notify系统的设计，最后介绍Notify系统的演化与升级变迁。希望能给各位的工作带来一些启发与指导。
　　为了适应业务的高速发展，小米网的系统架构经历了很多次变更。在此过程中，为了给各个子系统解耦合，同时保证最终一致性原则的实现，我们建立了自己的异步消息系统——
　　Notify异步消息系统。
　　小米网架构发展
　　小米网的发展大致可以分为三个阶段：初创阶段、发展阶段、完善阶段。
　　1. 初创阶段
　　当小米推出自己的第一部手机时，为了减少渠道成本，我们开始推行电商直销的商业模式，与此同时，开始建设小米电商网站。最开始，小米的业务特点是：
　　SKU（商品品类）单一；订单量巨大；瞬时访问量巨大。
　　后两点是在最初设计系统时完全没有想到，因为当前我们并没有预料到小米手机会如此受欢迎和供不应求。
　　在这个阶段，快速上线是第一目标，因为团队需要快速配合公司的手机销售计划。所以一开始小米网的架构设计比较简单，并没有考虑高并发和大数据的情况。当时系统从立项到上线仅两个多月时间，并且只由三名工程师开发完成。
　　
　　图1 小米电商初期的系统架构
　　从图中可以看出，系统架构只有两个Web服务器与一个DB服务器，两台Web服务器互为主备，所有的业务功能集成在一个系统中。当时的架构设计仅能支持简单的电商功能，我们预测每年的手机销量能到30万就已经很好了。但是计划永远赶不上变化，很快小米电商就遇到了第一个大问题：系统耦合度很高，导致当抢购活动开始时，其他业务都会受到影响。
　　2. 发展阶段
　　为了解决上面的问题，需要对小米网的架构进行修改，把各种业务系统拆成独立的子系统。这一时期小米电商的系统架构发展的特点是：
　　业务系统的拆分，小米负责处理抢购请求的大秒系统就是在这一阶段诞生的，将抢购业务带来的系统压力完全隔离开来，确保在抢购活动时小米的其他业务可以不受影响；小米的系统结构SOA（面向服务的软件结构）化，小米各系统之间的通信采用接口方式来实现，甚至我们开发了一套通信协议，叫做X5协议，来规范接口的开发与调用。
　　这一阶段小米网的架构如下图所示：
　　
　　图2 小米电商发展阶段的系统架构
　　从图2可以看出，前端与后端系统完全独立出来，当前端进行抢购活动时，后端的客服、售后、物流三大服务系统不会受到任何影响。图2中所列举的子系统只是小米网中的一小部分较为主要的系统，还有很多业务没有列举出来。
　　这种系统架构可以确保系统之间不会受到影响，但是接口的稳定性就成了一个至关重要的问题。这种系统架构几乎所有的接口都是同步接口，意思就是说一个业务调用这些接口如果不成功，业务也无法成功。如果出现网络问题或者接口BUG，就会导致大量业务失败。但事实上，并非所有的接口都必须做成同步性的，有些业务比如订单系统把订单信息发给仓储系统生产，就对同步性的要求不是很高，可以考虑使用异步方式来解决。为了解决这个问题，小米网架构下一步的演化就是建立一个异步消息队列系统。