作业 - 架构设计文档 + 总结
前言：架构师之路
作为一个事实的架构师，与真正的资深的架构师的-李智慧老师通过极客大学架构师训练营课程进行了次深度交流，真正理解到了架构的内涵：
架构师是工程师：需要有出色的技术能力，写出一色的好代码d；广泛的知识领域，要了解主流的系统的功能、性能、原理。
架构师是业务专家：架构师本质是桥接业务与技术差距的最重要的角色。不仅需要理解业务过程，还可以给业务建模，对业务进行抽象，分清除业务直接的关系，业务的静态特性，动态的特性。要有前瞻的眼光，洞察环境对于业务的影响，设计松耦合但有不过度设计系统。
架构师是布道者：要把自己的架构思想让老板理解，已获得更好的投资；要让自己的架构方案让团队成员理解，以让自己的方案能够落地。
架构师是学习者：架构师不断的学习，各个领域方面的知识都可以帮助他完成胜任这个角色。
所以架构师就是支柱，是团队的支柱，企业的支柱，也可以是家庭的支柱。
通过架构师训练营的课程，使得对架构师的理解，到达了一个新的高度。
ppt下载：http://note.youdao.com/s/5Ca59v8
1. 架构概要
本系统为支撑公司的同城快递业务而设计，实现用户下单，公司揽件、派单，订单追踪功能线上全流程管理的系统。本文档将系统的概要设计文档，将包括：
系统需求分析
系统顶层架构设计
1.2 功能概要
客户：快递下单，并可以对订单进行追踪
快递员：可以抢单，收单，确认送达。同时，快递员每30秒上报地理位置。
1.3主要场景订单活动
用户填写完订单信息，并完成支付之后，下单过程才算完成。之后快递员才能查看到订单，并进行抢单。
2. 系统部署图与整体设计
客户端：客户用来下单，支付，查看订单状态，客户端会通过https协议，与业务系统，支付系统进行交互，会接受push系统的消息
快递员端：完成快递员的订单流程，通过websocket每隔30秒上报歌会上个人位置。同时可以接受PUSH系统的push消息
业务系统：完成订单的主要流程。
支付系统：对接第三方支付通道。
Push系统：对接第三方消息通道，并实现基于长链接的push消息系统。
支付系统，push系统和订单系统使用同一个mysql实例，不同的database。
订单系统与push系统之间通过mq(kafka）通讯
2.1 用户下单时序
用户填写完订单信息，并完成支付之后，下单过程才算完成。之后快递员才能查看到订单，并进行抢单。
2.2 快递员抢单时序
根据新订单的起始位置，系统发送新的订单信息给一定范围内的快递员。
快递员查看订单的基本信息之后，发起抢单请求。
只有抢单成功的快递员才可以进一步查看订单详细信息，包括了订单起点与终点的详细信息和相关人的连续方式。
2.3 快递员更新位置
快递员上线之后，将每隔30秒上报一次位置状态给服务器。
为了降低上报位置的网络负载，快递员前端通过websocket网关与服务端建立长链接，通过websocket消息反馈位置信息。
订单服务会根据快速员的所在的城市，为每一个快递员建立空间索引，并把空间位置索引存贮到redis中，以供派单的时候使用
订单服务会定时（每10分钟）清理一次长久每一更新位置的空间索引（30分钟）
2.4 订单状态
总体来讲，订单分为三大主要状态：新建，进行中， 完成
进行中除了跟踪正常订单状态之外，用户在订单为揽件前，可以取消订单；
完成状态可以是正常完成，用户取消， 支付超时。
非功能需求接设计
3.1 部署及容量规划
数据库：
mysql 存储最近三个月数据，按月分表存储，定期每天转移到hbase并清理过期数据
订单数据与支付数据分布在不同的库中，上线初期使用同一个实例。
hbase 存储冷数据
Redis:
使用cluster模式，使用3node 2副本，初期每节点1G，后期检测服务器压力进行动态扩容
应用部署：
支付服务 ：初期部署2个节点，运行中根据情况增加部署数量。
push服务：初期部署2个节点，运行中根据情况增加部署数量。
订单服务：初期部署2个节点，运行中根据情况增加部署数量。
4 系统亮点
利用websocket 长链接可以有效的降低上报位置是的overhead
支付服务，push服务，订单服务不存储状态，可以实现横向扩容
数据存储进行冷热分离，避免mysql数据扩无限增大。
还未添加个人签名 2018.10.13 加入
还未添加个人简介
评论