单体应用架构在创业型项目里面是非常合适的，毕竟它主要的担当还是在验证创业模式以及迅速功能实现，所以它从开发到部署，在少量开发人员的基础上能非常减少成本，主要是门槛低，开发效率也非常高。到目前为此，这个物联网项目从开发开始到现在线上运行大概经历了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版本的迭代，脑袋一蒙，后面的大把的坑在等着我们，我们也准备好了打场硬仗。