关键词：
单体应用架构在创业型项目里面是非常合适的，毕竟它主要的担当还是在验证创业模式以及迅速功能实现，所以它从开发到部署，在少量开发人员的基础上能非常减少成本，主要是门槛低，开发效率也非常高。到目前为此，这个物联网项目从开发开始到现在线上运行大概经历了5个月左右的时间，订单数据从日订单几百到现在的七八万，在应用层本身来说并没什么压力瓶颈，中间主要升级了数据库RDS的配置，由原来的4核8G升级到了8核16G，对数据库稍微做了些优化，依然跑到很稳定。公司从实施想法开始，到目前半年的时间里面，不断的总结创业思路和改变策略，所以开发的业务变化由不断的“试误型”开始趋向于明确“清晰型”，而且业务垂直方向也越来越深，由自己做投放商急迫需要转型做招商平台城市合伙人，而且广告内容，和线下门店信息推广也在融合，其实和我之前的电商O2O很类似，一开始自己做个简单交易网站卖东西，做着做着就做B2C，B2B平台，其它的商家也进入这个平台开网店，将线下的信息广告推广也融合进来，大概套路都一样，无非是前期自己先验证模式，觉得可行就做平台告诉别人应该怎么怎么做。公司在半年的时间里面也各种融资好几轮，达到了好几千万级别的融资，接着而来的对软件平台的需求和要求也越来越高。想法谁都有，关键是要去实施，互联网游戏的规则就是这样，技术实施永远跟着产品想法的屁股在后面追。
单体应用架构在项目这几个月业务变化频繁，不断迭代的过程中，的确也出现了很多问题。最开始，业务比较简单，你写同一个工程里面写代码，我也在同一个工程里面写代码，测试完毕后，我这边就直接打成个war包(因为线上部署在tomcat的ROOT目录里面，我有时候直接在本地tomcat的ROOT里面解压缩成zip包)，丢到线上服务器，简单方便，速度快的很，这种发包方式我们简称“全量部署”，哪怕你这次改一点点需求只动了一个类里面的一行代码，我也是将所有的代码打包一次，简单业务简单方法处理是没有问题，随着业务需求的累加，并且不断的迭代，这种打包方法隐患慢慢多了起来，有几次线上发包“全量部署”，出现之前OK的功能代码不OK（其实这次发布不涉及到这些功能），细查之，知道开发人员提交了没测试的代码，就算后面非常谨慎和宁愿操作麻烦想保持SVN代码的“纯洁性”，但是风险问题依然存在，后面一段时间，我改用了“增量部署”，就是这次改掉了哪几个类，哪几个文件，在发包文档里面一 一描述，发包的时候只去测试好的测试环境拿下来这几个文件，传到正式环境里面，稍微控了下风险。
当然，单体应用架构本身对应用服务器的性能消耗也没有做到很好的水平扩展，如果后期线上量大，我也只能单台的去升级配置，越到后面升级配置越贵，当然，我们目前的业务还没有这么夸张，但是随着业务的扩展，肯定无法避免这些东西。另外，数据库随着业务的水平扩展，业务的粒度细分，也不可能所有的表都在同一个数据库里面，这个也要求后期提前做好分库分表的架构准备。
我们生在一个微服务四处横行的年代，基本上属于那种不玩单体应用架构，就玩微服务架构，不玩微服务架构，就玩单体应用架构。如果再倒退10年，可能就玩SOA面向服务企业架构，虽然和微服务最终实现的目标差不多，但是SOA表现的方式更多是以系统级别的形式表现，系统与系统的交互，所以更多的是通过传统的webservice的调用来满足按照业务的拆分。好在当今有微服务众多的成熟框架，实现起来更加灵活简单，而且入门也相当简单，更主要的开发起来比SOA更加轻量级。并且这些成熟框架本身集成了微服务中需要解决的基础共用的东西在里面，比如微服注册与发现，路由网关，客户端负载均衡，传输协议等等。话虽如此，但是真正用微服务从头到尾开发过几个项目的开发人员并不多，我们连续好几个月也一直在招聘对微服务，服务化相对熟悉的人，也寥寥无几，来面试的人可能也就是在书上看了些资料，搭建个简单的框架，但是真正沉淀在实际业务场景用微服务开发的人员一直没遇到。
经过再三考虑，我们决定使用springcloud来开发V2.0版本，业务拆分全部微服务化实现，V1.0单体应用架构在这段时间里会小范围维护，集中精力大概用2，3个月时间完成V2.0版本的迭代，脑袋一蒙，后面的大把的坑在等着我们，我们也准备好了打场硬仗。
我的物联网项目平台架构
介绍下目前整个软件开发团队的配套成员技能人数android1ios1前端1美工1java2以上就是我们这个项目的人员搭配，我除了项目上的管理，更多的是在做业务需求，系统架构，平台建设，然后也顶多算半个开发人员参与在写代码。 ... 查看详情
我的物联网项目(十四)分布式事务
2.0平台服务化架构，必然分库，分库又必然面临一个分布式事务处理问题，所以无论是设计还是编码远远比1.0单体应用架构的工作量要大。不过做任何事情，重点不在实施，而是在思路，所以要解决分布式事务问题，还得先想清... 查看详情
我的物联网项目单数据库事务也需谨慎
单体架构模式下的数据库基本都是单数据库，所以应用层通过spring事务控制的本质其实就是数据库对事务的支持，没有数据库的事务支持，spring是无法提供事务功能的。通过spring实现事务的方式也有声明式事务和编程式事务两种... 查看详情
架构初识（一）单体应用架构
...一是希望沉淀一下自己所学的东西，二是希望有人能指出我的不足指出，向大家学习。 第一篇 单体应用架构我会总结出单体架构的优缺点，和一般我在经历过的项目中单体架构所用到的技术，以及我需掌握... 查看详情
一文详解微服务架构(代码片段)
文章目录一文详解微服务架构互联网软件架构演变单体架构集群架构单体架构缺陷集群架构优势分布式架构面向服务架构(SOA)微服务架构微服务架构优点微服务架构缺点完整的微服务架构图服务网格ServiceMesh的定义ServiceMesh架构Ser... 查看详情
我的物联网成长记9物联网平台安全如何破？
【摘要】很多朋友都很关心华为物联网云平台的安全能力，今天它来了。安全的设备接入，稳定放心；安全的数据传输，可靠不怕泄露；安全的数据处理，保护用户隐私。今天我们就将围绕端、管、云和应用的安全能力为大家进... 查看详情
一种基于区块链的物联网架构设计
...无法良好地契合实际应用环境。为了降低基于区块链技术的物联网系统的复杂度，更契合实际应用环境的需求，通过分析现有区块链共识机制，提出一种基于区块链技术的物联网系统架构。首先，该架构将物联网网络内的所有终... 查看详情
我的物联网项目初建团队
今年三月初也是机缘巧合下接触这个项目，说实话也是非常看好这个项目，以前做过企业级项目，互联网项目，但是物联网项目也是第一次接触，相关资料了解了下何为物联网，原来是物物相连的互联网，与传统行业相结合的互... 查看详情
单体架构知识点及单体架构的缺陷
...。单体架构示例图 -单体架构的缺陷-1.复杂性高整个项目包含的模块非常多，模块的边界模糊，依赖关系不清晰，代码质量参差不齐,整个项目非常复杂。每次修改代码都心惊胆战，甚至添加一个简单的功能，或者修改一个BUG 查看详情
我的物联网项目开端
...也做过不同的岗位，其实我给自己的评价是到目前为此，我的骨子里依然是一名技术人员，回忆当初穿着整齐的职业装,安静的坐在工位上，默默无闻由上司分配功能模块，闷头开发模块，然后看着自己的模块被用户使用心里有... 查看详情
我的物联网项目订单系统
订单系统是整个平台的独立的核心业务流程，它本身并不复杂，最初的原始需求如下：1.用户打开app，登录进入主界面。2.点击扫码，扫码摇摇车身上的二维码。3.app显示扣费，摇摇启动。4.用户订单中心显示消费明细，商家订单... 查看详情
我的物联网项目订单系统
订单系统是整个平台的独立的核心业务流程，它本身并不复杂，最初的原始需求如下：1.用户打开app，登录进入主界面。2.点击扫码，扫码摇摇车身上的二维码。3.app显示扣费，摇摇启动。4.用户订单中心显示消费明细，商家订单... 查看详情
我的物联网项目下单渠道
app扫码方式启动摇摇车从一开始就是公司主推并且唯一的下单渠道，目的就是要改变传统的投币方式，甚至改变人们的消费习惯和使用习惯。通过app进行消费，一来和用户保持很强烈的粘度，随着注册用户的增加到后面的大用户... 查看详情
我的物联网项目下单渠道
app扫码方式启动摇摇车从一开始就是公司主推并且唯一的下单渠道，目的就是要改变传统的投币方式，甚至改变人们的消费习惯和使用习惯。通过app进行消费，一来和用户保持很强烈的粘度，随着注册用户的增加到后面的大用户... 查看详情
我的物联网项目推广策略
我参与公司最开始构造的推广策略蓝图，经过不断修改调整，整个流程如下：全部推广人员由外面兼职或者全职人员通过微信注册页面注册登记进来，后台客服人员审核资格后，这些推广人员开始去外面的各种店开始推广，如果... 查看详情
我的物联网项目线下之战
摇摇车这个行业在中国至少已经存在了7，8年以上，这期间也越来越多的投放商加入到这个队伍里面，说明这个行业本身是刚性需求，不要小看这一块钱现金流，如果投放的数量达到一定程度，每天的现金收入是非常可观的。这... 查看详情
我的物联网项目简单分布式调度
定时调度基本在任何平台或多或少的要用到，实现定时调度的功能很简单，我做过的项目中用到更多的是springquartz或者springtask，它们在单机上使用定时任务配置是非常简单的，但是在集群环境中就需要面临一个必须解决的问题... 查看详情
我的物联网项目前期线上事故
一MQTT连接数报警项目上线一个月左右，投放出去的摇摇车数量大概在200量左右，平均每天在线数(听说有些商家精打细算，有小孩需要坐车了才插电，平时都不插电，还有些干脆一直仍在角落懒的管)也就维持在100左右，当时在阿... 查看详情