免费建网站软件下载手机,html转换成wordpress主题,公共资源交易中心官网首页,社区团购小程序怎么做单体应用架构在创业型项目里面是非常合适的#xff0c;毕竟它主要的担当还是在验证创业模式以及迅速功能实现#xff0c;所以它从开发到部署#xff0c;在少量开发人员的基础上能非常减少成本#xff0c;主要是门槛低#xff0c;开发效率也非常高。到目前为此#xff0c;…单体应用架构在创业型项目里面是非常合适的毕竟它主要的担当还是在验证创业模式以及迅速功能实现所以它从开发到部署在少量开发人员的基础上能非常减少成本主要是门槛低开发效率也非常高。到目前为此这个物联网项目从开发开始到现在线上运行大概经历了5个月左右的时间订单数据从日订单几百到现在的七八万在应用层本身来说并没什么压力瓶颈中间主要升级了数据库RDS的配置由原来的4核8G升级到了8核16G对数据库稍微做了些优化依然跑到很稳定。公司从实施想法开始到目前半年的时间里面不断的总结创业思路和改变策略所以开发的业务变化由不断的“试误型”开始趋向于明确“清晰型”而且业务垂直方向也越来越深由自己做投放商急迫需要转型做招商平台城市合伙人而且广告内容和线下门店信息推广也在融合其实和我之前的电商O2O很类似一开始自己做个简单交易网站卖东西做着做着就做B2CB2B平台其它的商家也进入这个平台开网店将线下的信息广告推广也融合进来大概套路都一样无非是前期自己先验证模式觉得可行就做平台告诉别人应该怎么怎么做。公司在半年的时间里面也各种融资好几轮达到了好几千万级别的融资接着而来的对软件平台的需求和要求也越来越高。想法谁都有关键是要去实施互联网游戏的规则就是这样技术实施永远跟着产品想法的屁股在后面追。 单体应用架构在项目这几个月业务变化频繁不断迭代的过程中的确也出现了很多问题。最开始业务比较简单你写同一个工程里面写代码我也在同一个工程里面写代码测试完毕后我这边就直接打成个war包(因为线上部署在tomcat的ROOT目录里面我有时候直接在本地tomcat的ROOT里面解压缩成zip包)丢到线上服务器简单方便速度快的很这种发包方式我们简称“全量部署”哪怕你这次改一点点需求只动了一个类里面的一行代码我也是将所有的代码打包一次简单业务简单方法处理是没有问题随着业务需求的累加并且不断的迭代这种打包方法隐患慢慢多了起来有几次线上发包“全量部署”出现之前OK的功能代码不OK其实这次发布不涉及到这些功能细查之知道开发人员提交了没测试的代码就算后面非常谨慎和宁愿操作麻烦想保持SVN代码的“纯洁性”但是风险问题依然存在后面一段时间我改用了“增量部署”就是这次改掉了哪几个类哪几个文件在发包文档里面一 一描述发包的时候只去测试好的测试环境拿下来这几个文件传到正式环境里面稍微控了下风险。 当然单体应用架构本身对应用服务器的性能消耗也没有做到很好的水平扩展如果后期线上量大我也只能单台的去升级配置越到后面升级配置越贵当然我们目前的业务还没有这么夸张但是随着业务的扩展肯定无法避免这些东西。另外数据库随着业务的水平扩展业务的粒度细分也不可能所有的表都在同一个数据库里面这个也要求后期提前做好分库分表的架构准备。 我们生在一个微服务四处横行的年代基本上属于那种不玩单体应用架构就玩微服务架构不玩微服务架构就玩单体应用架构。如果再倒退10年可能就玩SOA面向服务企业架构虽然和微服务最终实现的目标差不多但是SOA表现的方式更多是以系统级别的形式表现系统与系统的交互所以更多的是通过传统的webservice的调用来满足按照业务的拆分。好在当今有微服务众多的成熟框架实现起来更加灵活简单而且入门也相当简单更主要的开发起来比SOA更加轻量级。并且这些成熟框架本身集成了微服务中需要解决的基础共用的东西在里面比如微服注册与发现路由网关客户端负载均衡传输协议等等。话虽如此但是真正用微服务从头到尾开发过几个项目的开发人员并不多我们连续好几个月也一直在招聘对微服务服务化相对熟悉的人也寥寥无几来面试的人可能也就是在书上看了些资料搭建个简单的框架但是真正沉淀在实际业务场景用微服务开发的人员一直没遇到。 经过再三考虑我们决定使用springcloud来开发V2.0版本业务拆分全部微服务化实现V1.0单体应用架构在这段时间里会小范围维护集中精力大概用23个月时间完成V2.0版本的迭代脑袋一蒙后面的大把的坑在等着我们我们也准备好了打场硬仗。转载于:https://www.cnblogs.com/dgcjiayou/p/7886716.html
