发帖
雷达卡
[img][/img]
『排队模块 』负责接收用户的抢购请求，将请求以先入先出的方式保存下来。每一个参加秒杀活动的商品保存一个队列，队列的大小可以根据参与秒杀的商品数量（或加点余量）自行定义。排队模块还负责提供一系列接口，如：给已进入队列的用户查询下单状态的接口，给调度模块拉取请求的接口，服务模块回写业务处理状态的接口等。
用户交互
因为我们的系统设计成异步的，因此消费者不再是像以前一样同步地去等待反馈。消费者需要一个途径来获取抢购的状态和进度。我们的主体流程大体上分为几个阶段：
当等待人数大于500人，页面提示：排在您前面的人超过500位；
当等待人数小于等于500人，页面提示：您已挤进第***位；
当等待时间大于等于1分钟，页面提示：剩余时间约*分钟。每次以分钟倒计时。
当等待时间小于1分钟，页面提示：预计剩余*秒。
抢购成功，后续跳转到订单支付页面
【以下为2个PC端页面交互设计示例】
分布式搜索引擎架构实践
应对大流量与高突发性的两个核心需求
『 可扩展 』如何抗住这样的流量，针对这个需求，1号店搜索团队构建了分布式搜索引擎，支持横向扩展；并且针对业务特点做了Routing优化，让搜索的效率更高。
『 快速响应 』流量越大，单位时间内的流量价值就越大，出现问题的损失也就越大，如何做到快速响应变得非常关键。针对这个需求，搜索系统支持自动部署和快速扩容以应对突发流量，索引数据从导入、处理到上线服务会经过层层验证，同时还有监控体系及时发现线上的问题。
分布式搜索引擎
1号店分布式搜索引擎是Lucene/Solr核心的，结合SOA框架Hedwig构建了一层分布式框架，支持搜索请求的分发和合并，并且构建了搜索管理后台，支持多索引管理、集群管理、全量索引切换和实时索引更新。 分布式搜索是为了解决数据增长过程中索引变大和操作时间变长的问题，它将原来的单个索引文件划分成n个切片(shards)，让每个shard都足够小，从而保证索引可以在多台服务器上部署，而且搜索操作可以在较短时间内返回。
如上图所示，分布式搜索中有两个主要组件：Shard Searcher和Broker，其中Shard Searcher与单机搜索引擎类似，基于Lucene/Solr完成基本的搜索任务。Broker负责把针对整个索引的搜索请求转化为针对单个Shard的搜索请求，它把Shard搜索请求分发给各个ShardSearcher，并且把各个Shard的结果进行合并，生成最终的结果。
分布式搜索中，一次搜索所需的资源与它要访问的Shard数和每个Shard要返回的结果数有非常强的关联关系，在Shard数特别多或结果数特别多时可能会碰到一些的内存、CPU资源使用的问题。针对结果数特别多的情况，可以按照业务场景优化，比如如果对排序无要求，就可以每次指定一个Shard进行搜索，搜完这个Shard再换下一个，这样就限制了每次搜索的Shard数，另一方面也可以考虑使用DeepPaging等技术，减少每次Shard搜索的成本。我们下一小节也会介绍1号店主站搜索是如何减少每次搜索Shard数的。
上图中的Broker和Shard Searcher仅仅是概念上的划分，实际部署时有几种选择：
每个节点上都有Broker和部分Shard的Shard Searcher。
Broker单独部署成一个集群，与Shard Searcher隔离。
Broker作为客户端的一部分，和搜索应用一起部署。
我们开始使用的是A方式，后来主站搜索转为C方式，主要是考虑到可以节省一次网络调用（以及请求和结果的序列化开销），另外Broker在客户端也可以更多地使用应用逻辑相关的数据进行更高效的Routing。
自动部署与快速扩容
按照类目进行Sharding和Routing的方式，在带来高效的同时，也带来了管理上的成本。按照类目切分，必然会导致各个Shard的大小不平均，而对应的Routing方案，必然会带来各个Shard的访问量不平均。这两个维度不平均就要求更加复杂的索引部署方案，主要的原则为：
首先根据流量比例和高可用的需求，确定每个Shard的副本数。
然后按照单个节点不能放置同一Shard的多个副本，节点上的承担的流量总和与节点的服务能力成正比。
每个节点上的索引总大小尽量也保持差异最小。
按照流量比例，副本数计算如下：
【部署之后的效果如下图所示】
Shard数增多之后，人工计算部署方案就显得较为复杂，于是我们就把部署方案生成做成了自动化，一个基本的Packing算法就可以完成这个工作。除了初始部署之外，自动部署工具还可以支持节点增加、减少和更换。
在11.11的场景下，这个自动化部署工具也可以支持快速扩容，基本过程为：
Index Server（部署工具界面）计算出扩容之后的部署方案，写入到ZooKeeper。这里的算法与初始部署有些不同，它需要保证现有服务器的Shard尽量不变。
每个Shard Searcher服务器都会监听ZooKeeper上的部署方案，方案改变之后，Shard Searcher会获取新的方案与本地方案对比，进行增减操作。
Shard Searcher从HDFS上获取索引数据，与最近的实时更新数据合并之后，启动索引提供服务。
有了自动扩容工具，11.11容量规划确定之后，新的服务器就可以很快部署上线，也减少了人工操作可能引入的失误等问题。大促期间如果需要紧急扩容，也可以在几分钟内提高整个系统的服务能力。
实时监控体系
应用架构的最大演进－SOA治理
早期的1号店系统，遵循简单的MVC架构，Controller层处理了所有的业务逻辑包括与DB的交互，在系统初期这种Simple的架构方便快捷，成本低业务响应快。但当业务开始变得复杂、人员规模爆发式增长，这种强耦合强依赖带来的弊端就成了巨大的瓶颈，代码耦合度高互相冲突、出错概率和事故概率明显提升，业务需求不能快速响应，SOA治理迫在眉睫，解耦和去依赖成为第一需求，于是Service化成为第一前提。
SOA治理－Service日志即保障
『 Tips 』
做Service规划首要考虑要素：
很多人想的是采用什么RPC框架、采用什么技术，怎么让性能更高；也有人首先想的是业务怎么拆分，怎么才能更合理。
我们首先想到的是如何做监控和问题定位。
高可用不是一步做到的，我们的Service可用性不是一步达到99.9999%的，在这过程中一定会有很多的问题出现，怎么提前发现这些问题、出现问题后如何快速定位，这才是最重要的。这只能依赖日志，这是监控和问题定位的基础。
下单接口业务性强，其对可用、并发、性能的要求作为技术人你懂的。我们就从这个接口开始下手，但我们没有先去分析业务，首先想的是如何定义日志系统，让以后的监控和问题定位更简单更快捷。事实证明这个决定是对的，直到现在1号店的大部分订单相关的监控、预警、问题排查定位等完全依赖这个日志。
日志系统的设计基于以下：一是进数据库、持久化有序化，二是分类化、层次化、错误code唯一。
进数据库、持久化有序化这个大家都理解，我曾经接手过的一个应用系统，一天下来Tomcat的log文件大小超过1G，会让你崩溃的。
分类化、层次化、特别是错误code唯一这个是关键，它是大海航行中的那盏灯塔，让你可以瞬间定位问题位置，它给监控预警带来的好处同样伟大，可以从各个维度去做监控预警。
1号店现在有了很好的SOA中间件 – Hedwig，可支持百亿级的访问请求，它有SOA级别的日志，也很完善。但应用级别的日志我们还是建议各应用系统自己做，它的业务性、个性化是公共架构永远代替不了的。
应用架构演进之落地
『业务垂直拆分 』
从业务角度规划Service，从产品、用户、订单三个维度上对Service进行了规划，构成1号店应用架构上的三架马车，确立了SOA治理的框架基础。
在此基础上，又陆续衍生出促销、积分、支付等众多Service业务，在三架马车中同样会细分至如文描、价格、库存、下单、订单查询等垂直服务。
Service化是前提，Service化完成后，后面可以大刀阔斧地干了，因为业务独立了、DB读写权限收回了，哈，好像整个天下都是我的了。但，得天下易治天下难，真正的大戏在后面。
『读写分流 』
读写分离的重要性不需多讲，除了最简单的读写分离，写可以从应用层面继续细分，读也可以从应用和DB层面再细分，如订单的读写分离：
『 水平拆分 』
早在2013年，1号店实现库存的水平拆分，2014年又一举完成订单水平拆库&去Oracle迁Mysql项目。
订单水平拆库&去Oracle迁Mysql两个重量级的大项目合并为一个项目并完美无缝上线，在经济上时间上节省的是成本，在技术上体现的1号店的整体技术实力和水平。
『 服务逻辑分组 』
物理分离好处明显，但其硬件成本、维护成本高的弊端也显而易见。这时候，我们的大杀器-Hedwig又上场了，有兴趣多来了解下我们SOA中间件-Hedwig，这可是获总裁奖的项目。
Hedwig提供了服务自动注册发现、软负载均衡、节点踢出与复活、服务动态逻辑分组、请求自动重试等众多SOA框架所需的强大功能，支持并行请求、灰度发布，其背后提供的调用链路及层次关系、日志分析、监控预警等更是为SOA治理提供了强大的后勤保障。
『 业务解耦｜异步 』
优化主要在两方面，一是架构上，如使用缓存、单SKU的循环查询改成批量查询等，这个能优化的也并不太多，因为我们的架构整体还是比较合理的；最大的优化还是在业务梳理上，很多地方我们使用了重接口，接口里很多逻辑计算和DB查询，这些逻辑并不是所有的业务场景都需要的，但开发人员为了简单没有将业务场景细分，导致大量不合理的调用，既浪费了服务器资源又严重影响用户体验；同样，很多地方为了一个不重要的展示或逻辑也产生大量不合理的调用，反而影响了核心业务，这些都是最需要优化的，也是优化效果最明显的。
异步本身不是什么高深的技术，关键是哪些业务可以走异步，这更体现架构师的业务理解能力和综合能力。
如下单成功后给用户的消息通知、发票详细信息的生成等都可以异步，我们在这方面做了很多工作，包括和各业务方的大量沟通制定方案等，在不牺牲用户体验又保证业务流程完整的情况下，尽量走异步解耦，这对可用、性能都是极大的提升。
实例：Service服务可用性99.9999%
业务监控应用场景
业务监控首提订单监控，对订单我们从实际订单数据和Service接口调用量两个维度去做监控，保证了监控系统的稳定和准确（监控系统也会出错的），其中下单接口调用量使用的就是Service日志数据。
服务监控应用场景
『 依赖查询 』
『服务监控 』
| [/url] | [url=http://it.dataguru.cn/home.php?mod=spacecp&ac=click&op=add&clickid=2&idtype=aid&id=8425&hash=8f3514e8f42bf6074e764d9bc76e04ab&handlekey=clickhandle] | [/url] | [url=http://it.dataguru.cn/home.php?mod=spacecp&ac=click&op=add&clickid=4&idtype=aid&id=8425&hash=8f3514e8f42bf6074e764d9bc76e04ab&handlekey=clickhandle] |
京公网安备 11010802022788号
