文章分类 - 我的物联网项目
摘要：说实话，线上运营不是我们的强项，公司的大部分人对线上的运营想法都有一箩筐，谈起线上运营的内容，都是神采奕奕，滔滔不绝，感觉钱就在眼前，触手可及。我自己也一度认为，平台有了用户，有了流量，做线上的任何内容运营都是水到渠成。我们前面做的任何策略，包括对城市合伙人的各种优惠政策(甚至送钱)，都是为了平台的
阅读全文
摘要：最近平台有人员反应了几个问题： 1.商家充值记录有时候莫名其妙存在充值后的重复数据记录。 2.开发人员无意中提了一次我们的feign负载均衡有时候会负载到两台集群服务器都会执行。 3.定时调度去执行当日表移单要历史表，发现存储过程被调用了两次。 由于这几个问题不是同一时间段出现的，再加上是偶发性的，
阅读全文
摘要：有天项目中某个业务出现了异常，查询相关日志显示如下： ### Error updating database. Cause: com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Lock wait timeout ex
阅读全文
摘要：这一章其实应该在前面就要写到，顺便说下，我写这些文章只是随意写写，并没有太强的先后顺序，可能在写到后面的时候突然想起来，还有些东西前面应该交代的，所以我就补上来，但是整体的先后顺序是没有问题的，后面有时间再重新整理。 订单的编号生成规则1.0的时候，平台用到是UUID32位，简单粗暴，但是2.0平台
阅读全文
摘要：平账一词是在开发摇摇车投币功能出现的，当初目的就是解决，用户一块钱硬币投进去，商家掌管摇摇车钥匙，有随时收取硬币的权限，平台怎么分账？当初的设计方案就是用户投进去硬币，商家线上账户上的可提取资金扣掉分给平台的钱，如果这个商家要是线下投币生意大于线上扫码的生意的话，商家线上账户可提现资金就会出现负数，
阅读全文
摘要：偶尔有反馈说商家充值成功了，但是商家无充值记录和资金账户没有改变，另外也有反馈第三方微信支付在业务高峰期会有不断的回调尝试，更重要的是问题追踪起来比较繁琐，针对这些对设计进行了重新优化，没有太对的细节，具体看图。
阅读全文
摘要：平台无论是城市合伙人，还是商家，都有大量的统计数据的需求，比如统计商家一个月的总金额收入，投币消费总金额，微信扫码消费总金额等。这块的优化也一直在做，大概分为这么几个阶段。 1.实时count统计订单表 1.0平台当初2个月的时间开发完毕并上线用的就是这种方式统计数据。当时的订单量并不大，所有涉及到
阅读全文
摘要：查询优化主要涉及到两块。 1.订单表数据查询优化 订单数据库是单独出来的，每一条记录记录显示都涉及到用户名称(微信号，昵称，app昵称)，商家名称(商家名称，电话)，设备名称(设备编号，车牌号)等。 按照目前的表设计，订单库和用户库，商家库，设备库都独立，表都是通过主键ID进行关联，订单表存放的是u
阅读全文
摘要：我们的摇摇车支持三种消费模式： 1.投币 和传统摇摇车一样，通过一元的硬币来启动摇摇车，公司其实在做这个平台当时的初衷是不做投币的，只做app扫码，一来方便用户，毕竟这几年来流行各种扫码。二来做线上运营，毕竟通过系统和用户的粘度增强。但是在当初摇摇车实际投放中，发现一大部分人群，包括老年人带小孩，以
阅读全文
摘要：城市合伙人平台上线后，对于系统监控最关心的两个事情就是用户和订单，其中以订单最为重心。原因很简单，因为外面很多城市合伙人陆续加入进来，摇摇车的流量入口越来越大，新注册的app用户和启动摇摇车产生的订单越来越多，1.0平台那个时候外面摇摇车大概1000两左右，一天内最大订单数2W左右，2.0平台城市合
阅读全文
摘要：1.0平台没有城市合伙人一说，毕竟是自己运营投放，所以基本也就是运营平台在运维后台的所有数据，包括相关的流程跟踪也是在运营平台。当初1.0前期的整个系统功能如下： 当初在设计城市合伙人这个平台时，也曾经想过干脆在现在的运营平台上改造，其实除超级管理员外，城市合伙人和现有的运营平台所有账号都是平级的，
阅读全文
摘要：做城市合伙人是在公司自营摇摇车投放进入一个鼎盛时期开始的战略目标，这个时候决定做主要原因有二。 1.经过4，5个月时间摇摇车投放的运营，已经验证过这种模式所带来的利润，用老板自己的话来说“你们所关心的是平台本身，我要做的事情是快速复制，不断复制成功”。 2.经过2，3次的融资公司有一定的资金，可以多
阅读全文
摘要：以商家进入商家中心的简单例子来阐述整个系统之间的调用流程。 1.打开商家中心，商家中心页面会检测cookie是否失效,如果失效跳转到sso单点登录页面。 2.sso认证用户和密码成功后，生成token写入redis和cookie。 3.商家中心从cookie获取权限菜单，如果没有，请求统一权限平台。
阅读全文
摘要：项目工程总共分三大块。前端系统用的是vue框架，业务系统用的是微服务框架springcloud，运营系统用的是传统的springMVC框架。 一 前端系统 前端系统主要分为PC端和移动端，分别有商家中心，城市合伙人以及运营平台。 二 业务系统 业务系统主要按模块划分，最终生成不同的jar包分别部署。
阅读全文
摘要：微服务架构无论从业务层面，还是技术层面，要思考和解决的问题很多，其中有三大问题只要用到了微服务架构就必须要面对的，那就是拆分，事务，和查询。 当初规划这个2.0平台用微服务架构本身的目的是将平台以业务模块为中心，分而治之，摆脱1.0平台单体应用架构牵一发而动全身的痛点。每个业务模块独立管理，垂直发展
阅读全文
摘要：我的物联网项目专题移到网站：http://51jdk.com
阅读全文
摘要：2.0平台服务化架构，必然分库，分库又必然面临一个分布式事务处理问题，所以无论是设计还是编码远远比1.0单体应用架构的工作量要大。不过做任何事情，重点不在实施，而是在思路，所以要解决分布式事务问题，还得先想清楚屡清楚怎么去做才是重点之重。 分布式事务处理方法其实大把，无需担忧找不到解决方法，关键是要
阅读全文
摘要：准确的来说，1.0平台的单体应用架构没有互联网项目架构一说，传统的MVC开发模式，简单的小作坊操作流程，对于每个开发人员来说，只需要关注业务的功能模块实现而已。在1.0平台运营的半年时间里面，除了业务本身的需求爆炸性的增长，要求开发的迭代迅速，并且每次升级都不应该伤筋动骨，只是模块化的累加或者在原有
阅读全文
摘要：单体架构模式下的数据库基本都是单数据库，所以应用层通过spring事务控制的本质其实就是数据库对事务的支持，没有数据库的事务支持，spring是无法提供事务功能的。通过spring实现事务的方式也有声明式事务和编程式事务两种，不管哪一种实现起来都比较简单。像一般的业务，类型下面这种方式编程就行： 1
阅读全文
摘要：单体应用架构在创业型项目里面是非常合适的，毕竟它主要的担当还是在验证创业模式以及迅速功能实现，所以它从开发到部署，在少量开发人员的基础上能非常减少成本，主要是门槛低，开发效率也非常高。到目前为此，这个物联网项目从开发开始到现在线上运行大概经历了5个月左右的时间，订单数据从日订单几百到现在的七八万，在
阅读全文
