1.以快速的产品雏形面向市场。
现在很多互联网产品还没有上线就已挂了。或者说上线后没有什么流量,产品就下线夭折了。在这个产品雏形阶段我们尽量选择
成熟的框架,传统的企业架构模型,但也要做到功能模块分包清晰,代码组织结构,controller,business,dao这三层清晰,为以后项目的重构奠定基础。笔者在3年前也经历过一些互联网创业公司,那个时候scrum开发过程管理还不流行。在公司对自己想定位的产品发展思路还不是太清晰时,只会是业务需求来驱动技术架构。
2.技术框架在产品中是什么?
有时候我看到身边朋友不断刻苦专研各种技术,各种技术技能也许只对程序猿在面试具有一部分含金量。其实对我们产品在市场中,客户眼里。不是已技术来确定价值。
技术框架在产品也只是一个tools,采用开源框架对构建产品架构具有几个优势,1.开发成本低,大量开发人员深入掌握该技术,容易上手,可以更多关注业务。2.稳定性高,每次产品上线后都会经历一个生产各种问题阶段。对于开源技术同类问题解决方法网上有很多同例。最近几年我们采用开源框架还是基于spring,mybatis,mysql,nosql,cache,Jquery还是基于这些。但是我们面临的是一个大数据时代,在架构设计的思想上有了很大的变化。。
3.怎么提供一个优秀产品架构?
当产品有一定市场基础后,我们就要思考怎么把产品架构设计成一个高性能,大数据,弹性,扩展性好的Cloud Service。SaaS (Soft as s Service)这种产品模式基本被很多公司所使用。引入微服务分布式架构,微服务的有几大从开发到运行维护的优点。
常见单体式应用的几大缺点:
1.到项目后期功能来越复杂,app变的庞大,不利于单一团队的敏捷开发,维护。笔者曾经亲身经历一个运营5年巨大复杂单体应用的开发维护,该app有一个baseVersion,根据不同site定制需求,后台采用继承overwrite来扩展定制化。前端则采用include方式,不同site提供不同subPage,采用ant编译工具,构建不同site进行替换。第二问题,加上运营维护已经n年了,开发人员不断的流失,对于后期加入该项目人员,学习成本非常高,也非常容易出错。
2.
单体式应用在不同模块发生资源冲突时,扩展将会非常困难,例如需要多cpu,大内存,
3.
单体式应用另外一个问题是可靠性。因为所有模块都运行在一个进程中,任何一个模块中的一个bug,比如内存泄露,将会有可能弄垮整个进程。
4.单体应用不利于应用新的技术,没有进程的隔离,害怕version confilct。
微服务架构的好处:
1.
首先,通过分解巨大单体式应用为多个服务方法解决了复杂性问题。减少团队学习成本,沟通成本。一个团队人数太多就难于管理。
2,
第二,这种架构使得每个服务都可以有专门开发团队来开发,也隔离技术选择性的风险。对于后期提供服务,可以采用一些新技术。
3.第三,微服务架构模式是每个微服务独立的部署。开发者不再需要协调其它服务部署对本服务部署升级的影响。
4.最后,微服务架构模式使得每个服务独立扩展。根据需求选择不同machine,multi cpu,big memory, ssh hardDish。
这次就聊这么多,希望后期能聊些具体工作中实际案例分析,设计问题分享。