摘要: 查询优化主要涉及到两块。 1.订单表数据查询优化 订单数据库是单独出来的,每一条记录记录显示都涉及到用户名称(微信号,昵称,app昵称),商家名称(商家名称,电话),设备名称(设备编号,车牌号)等。 按照目前的表设计,订单库和用户库,商家库,设备库都独立,表都是通过主键ID进行关联,订单表存放的是u 阅读全文
posted @ 2018-09-01 18:18 心灵之火 阅读(2410) 评论(0) 推荐(3) 编辑
摘要: 查询优化主要涉及到两块。 1.订单表数据查询优化 订单数据库是单独出来的,每一条记录记录显示都涉及到用户名称(微信号,昵称,app昵称),商家名称(商家名称,电话),设备名称(设备编号,车牌号)等。 按照目前的表设计,订单库和用户库,商家库,设备库都独立,表都是通过主键ID进行关联,订单表存放的是u 阅读全文
posted @ 2018-09-01 18:17 心灵之火 阅读(160) 评论(0) 推荐(0) 编辑
摘要: 我们的摇摇车支持三种消费模式: 1.投币 和传统摇摇车一样,通过一元的硬币来启动摇摇车,公司其实在做这个平台当时的初衷是不做投币的,只做app扫码,一来方便用户,毕竟这几年来流行各种扫码。二来做线上运营,毕竟通过系统和用户的粘度增强。但是在当初摇摇车实际投放中,发现一大部分人群,包括老年人带小孩,以 阅读全文
posted @ 2018-09-01 18:16 心灵之火 阅读(948) 评论(1) 推荐(1) 编辑
摘要: 城市合伙人平台上线后,对于系统监控最关心的两个事情就是用户和订单,其中以订单最为重心。原因很简单,因为外面很多城市合伙人陆续加入进来,摇摇车的流量入口越来越大,新注册的app用户和启动摇摇车产生的订单越来越多,1.0平台那个时候外面摇摇车大概1000两左右,一天内最大订单数2W左右,2.0平台城市合 阅读全文
posted @ 2018-09-01 18:15 心灵之火 阅读(247) 评论(0) 推荐(1) 编辑
摘要: 1.0平台没有城市合伙人一说,毕竟是自己运营投放,所以基本也就是运营平台在运维后台的所有数据,包括相关的流程跟踪也是在运营平台。当初1.0前期的整个系统功能如下: 当初在设计城市合伙人这个平台时,也曾经想过干脆在现在的运营平台上改造,其实除超级管理员外,城市合伙人和现有的运营平台所有账号都是平级的, 阅读全文
posted @ 2018-09-01 18:13 心灵之火 阅读(210) 评论(0) 推荐(1) 编辑
摘要: 做城市合伙人是在公司自营摇摇车投放进入一个鼎盛时期开始的战略目标,这个时候决定做主要原因有二。 1.经过4,5个月时间摇摇车投放的运营,已经验证过这种模式所带来的利润,用老板自己的话来说“你们所关心的是平台本身,我要做的事情是快速复制,不断复制成功”。 2.经过2,3次的融资公司有一定的资金,可以多 阅读全文
posted @ 2018-09-01 18:11 心灵之火 阅读(302) 评论(0) 推荐(1) 编辑
摘要: 以商家进入商家中心的简单例子来阐述整个系统之间的调用流程。 1.打开商家中心,商家中心页面会检测cookie是否失效,如果失效跳转到sso单点登录页面。 2.sso认证用户和密码成功后,生成token写入redis和cookie。 3.商家中心从cookie获取权限菜单,如果没有,请求统一权限平台。 阅读全文
posted @ 2018-09-01 18:10 心灵之火 阅读(174) 评论(0) 推荐(1) 编辑
摘要: 项目工程总共分三大块。前端系统用的是vue框架,业务系统用的是微服务框架springcloud,运营系统用的是传统的springMVC框架。 一 前端系统 前端系统主要分为PC端和移动端,分别有商家中心,城市合伙人以及运营平台。 二 业务系统 业务系统主要按模块划分,最终生成不同的jar包分别部署。 阅读全文
posted @ 2018-09-01 18:09 心灵之火 阅读(146) 评论(0) 推荐(0) 编辑
摘要: 微服务架构无论从业务层面,还是技术层面,要思考和解决的问题很多,其中有三大问题只要用到了微服务架构就必须要面对的,那就是拆分,事务,和查询。 当初规划这个2.0平台用微服务架构本身的目的是将平台以业务模块为中心,分而治之,摆脱1.0平台单体应用架构牵一发而动全身的痛点。每个业务模块独立管理,垂直发展 阅读全文
posted @ 2018-09-01 18:09 心灵之火 阅读(705) 评论(0) 推荐(1) 编辑