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年了，开发人员不断的流失，对于后期加入该项目人员，学习成本非常高，也非常容易出错。
单体式应用在不同模块发生资源冲突时，扩展将会非常困难，例如需要多cpu，大内存，
3. 单体式应用另外一个问题是可靠性。因为所有模块都运行在一个进程中，任何一个模块中的一个bug，比如内存泄露，将会有可能弄垮整个进程。
4.单体应用不利于应用新的技术，没有进程的隔离，害怕version confilct。
微服务架构的好处：
首先，通过分解巨大单体式应用为多个服务方法解决了复杂性问题。减少团队学习成本，沟通成本。一个团队人数太多就难于管理。
2, 第二，这种架构使得每个服务都可以有专门开发团队来开发，也隔离技术选择性的风险。对于后期提供服务，可以采用一些新技术。
3.第三，微服务架构模式是每个微服务独立的部署。开发者不再需要协调其它服务部署对本服务部署升级的影响。
最后，微服务架构模式使得每个服务独立扩展。根据需求选择不同machine，multi cpu，big memory， ssh hardDish。
这次就聊这么多，希望后期能聊些具体工作中实际案例分析，设计问题分享。
