从零开始设计和搭建你的体育赛事比分网站 (3) - 原型与架构设计
上一篇：从零开始设计和搭建你的体育赛事比分网站 (2) - 需求整理
3 原型与架构设计
上一模块中，我们分别从三个部分：需求的收集与划分、需求的分析、需求的放大与汇总，以企业团队中产品经理的角度，分析了如何进行体育赛事比分网站项目的需求整理。
而在这一模块中，就模块而言其实可以分成原型设计和架构设计两个模块来介绍，但是我们侧重于架构设计的介绍，所以将这两部分合并为一个模块。本模块将会分别从快速原型设计和网站架构设计两部分出发，迈出体育赛事比分网站搭建的下一步。
3.1 快速原型设计
网站原型是设计方案的表达，是产品经理、交互设计师的产出物之一，也是项目团队的其他成员的重要参考和评估的依据。网站原型其实也就是页面界别的信息架构、文案设计以及页面交互的综合，是网站功能与内容的示意图。
3.1.1 界定原型范围
在设计网站原型之前，我们需要明确几个关键性问题来界定原型范围：
什么需要原型化？网站的优秀设计，比如复杂的交互、新添加的功能以及流程等；比如为用户提供与众不同的搜索体验时，就需要原型化网站搜索结果，引入多面搜索或添加不离开搜索界面即可预览文档的功能等等；多少网站部件需要原型化？集中添加一些将来80%时间内会使用的20%的功能要素，即原型化一些最常用的关键性功能；设计原型故事场景确定了需要进行原型化的网站区域之后，将他们组合成一个或多个场景，根据原型所模拟的用户体验指定统一的路径；规划原型迭代一开始广泛全面的对网站进行原型化，然后逐步深入到解决方案选定区域的原型化，如此由浅入深逐渐完成整个软件的原型化，加快迭代速度。3.1.2 合适的原型保真度
保真度一般是指原型与最终解决方案的相似程度，他拥有多个维度：
而按照精细程度进行划分，原型的保真度也分为：
选择合适的原型保真度时，通常没有一个确定的答案。大多数网站原型设计都是从绘制草图开始，然后根据系统的复杂程度和保真度的要求，将其转化为高保真的原型。
3.1.3 高效的原型设计工具
根据不同的设计需求，你可以选择和使用不同的原型工具。在这里我举几个常用的工具：
3.2 网站架构设计
在这里我们以支持分布式、高并发、高可用为架构目标进行设计。
3.2.1 网站初级架构
一般网站，刚开始的做法是三台服务器，一台部署应用，一台部署数据库，一台部署NFS文件系统，这是较早之前传统的做法，当并发量高的时候容易出现性能问题。
目前主流的网站架构一般会采用集群的方式，进行高可用设计，至少是下面这样子：
3.2.2 网站容量预估与架构分析
预估步骤一般为：
注册用户数-日均UV量-每日的PV量-每天的并发量；峰值预估：平常量的2~3倍；根据并发量（并发，事务数），存储容量计算系统容量。假设通过预估之后，我们存在几个问题（为了后续介绍优化，这里假设一下）：
需要部署10台web服务器，并且这10台web服务器只有高峰期才会用到，例如抢购，活动等等，存在大量浪费；所有网站应用都部署在同一台服务器，造成应用之间耦合严重，需要进行垂直或水平切分；大量的代码冗余；服务器进行Session同步需要耗费大量的内存和网络带宽；操作数据需要频繁访问数据库。那么根据以上问题，我们可以进行如下的架构优化：
3.2.3 网站架构优化
a. 业务拆分
根据业务逻辑进行垂直切分，可以将我们的体育赛事比分网站划分为：
产品子系统；订单子系统；支付子系统；用户子系统；客服子系统；短信邮件子系统；定时任务子系统；业务拆分的作用：
每个子系统可交由专门的人负责；解决模块之间耦合以及扩展性问题；每个子系统单独部署，避免集中部署导致一个应用挂了，全部应用不可用的问题。根据业务子系统进行等级定义，分为核心系统和非核心系统：
核心系统：产品子系统、订单子系统、支付子系统；非核心系统：评论子系统、客服子系统、接口子系统。等级定义的作用：核心和非核心子系统组合部署，用于流量突然爆发时，对关键应用进行保护，关闭非核心子系统，实现自动降级。
b.应用集群部署
分布式部署：将业务拆分后的应用单独部署，应用直接通过RPC进行远程调用；集群部署：应对高可用的要求，每个应用至少部署两台服务器进行集群部署；负载均衡：高可用系统必须一般应用通过负载均衡实现高可用；分布式服务通过内置的负载均衡实现高可用；关系型数据库通过主备方式实现高可用；c.多级缓存
缓存按照存放的位置，可以分为两种：本地缓存和分布式缓存。在这里我们采用二级缓存的方式进行缓存设计：
一级缓存：本地缓存；二级缓存：分布式缓存；一级缓存，缓存数据字典和常用的热点数据等不可变/有规律变化的信息。二级缓存，缓存需要的所有缓存。当一级缓存过期或不可用时，访问二级缓存的数据。如果二级缓存也没有，则访问数据库。
缓存的比例一般1:4即可考虑使用缓存。根据业务特性可使用以下缓存过期策略：
缓存自动过期；缓存触发过期；d.单点登录
系统分割为多个子系统进行部署之后，我们可以采用Session同步、Cookies、分布式Session方式避免会话管理问题。
在体育赛事比分网站架构设计中，我们可以采用分布式Session，建立完善的单点登录或账户管理系统。流程如下：
用户第一次登录时，将会话信息写入分布式Session；用户再次登录时，调用分布式Session，判断是否有会话信息，如果没有则跳转到登录页；分布式Session一般采用Cache中间件实现，可以使用Redis实现持久化，方便分布式Session宕机后，可以从持久化存储Redis中加载会话信息；存入会话时，可以设置会话保持的时间，比如10分钟，超过后自动超时；e.数据库集群
大型网站需要存储海量的数据，为了达到海量数据存储、高可用、高性能，一般采用读写分离和分库分表的方式进行架构设计。
读写分离一般解决读比例大于写比例的场景，可采用一主一备、一主多备货多主多备方式。
我们将体育赛事比分网站在业务拆分的基础上，结合分库分表和读写分离：
业务拆分后，每个子系统需要单独的库；如果单独的库太大，可以根据业务特性，进行再次分库，比如商品库；分库后，如果表中的数据量很大，则进行分表，一般可以按照ID、时间等进行分表；在分库分表的基础上进行读写分离。f.服务化
将多个子系统公用的功能进行抽取，作为公共服务使用。比如体育赛事比分网站的用户子系统就可以抽取为公用的服务。
g.消息队列
消息队列可以解决子系统之间的耦合，实现异步、高可用、高性能，是分布式系统的标准配置。在体育赛事比分网站中，消息队列主要应用在购物下单、信息发送环节。
用户创建订单后，写入消息队列，返回客户端；短信邮件子系统读取消息队列信息，完成短信与邮件的发送；定时任务子系统读取消息队列信息，检测订单支付状态；
h.其他架构
除了以上介绍的业务拆分、应用集群、多级缓存、单点登录、数据库集群、服务化、消息队列外，还有CDN、反向代理、分布式文件系统等架构技术。
3.2.4 架构总结
本模块中，我们从以下几个方面大概介绍了如何进行体育赛事比分网站的原型与架构设计。下一个模块我们将会介绍如何进行前后端开发，敬请期待！
飞鲸体育数据 —— 球探网12年匠心打造，实时、海量、可靠的体育数据服务
更多技术干货敬请关注：飞鲸体育数据-知乎
