背景
最近发现好多企业的项目，才开始启动，就说需要用分布式或微服务，需要用多少服务器或者多少虚拟机等，更吓人的是，项目没有在线上运行多久就开始说做中台，特此随笔写写，项目发展和拆分相关的经历。
概述
关于项目的发展和拆分，需要遵循一定的规则（节约成本和高效工作），项目从单体架构到微服务架构，甚至后面服务网格以及新出的未知架构，都可以以成本和高效来衡量项目是否适合。
1.单体架构
首先，单体架构优点是非常显著的，在项目启动的初期，由于业务比较简单，开发人员数量也不多，往往就是坐在一个办公室里就是一整个团队，沟通和交流往往“靠吼”就能非常完美的解决，项目利用构建工具分出小模块，交给具体的开发负责，大家上传的代码都在一个仓库下，大家都看得见，最后运维上线打成一个单一的可运行文件包，在单独一个服务器上运行，甚至有些企业为了节约成本，项目和数据库都在一台服务器上运行（单项目+单库），每天做好数据库的远程备份，如果生产环境出了问题，便从新在部署一次，数据还原成最近备份的，虽然这种方式不算特别的友好，但是确实够节约成本而且效率非常高。
随着用户的增多，部署一个节点可能不足以支撑访问量，最先想到的就是引入缓存来减少数据库的压力，但是并不是所有数据都适合放入缓存，随着压力在次增大，单库始终是性能的瓶颈。然后开发想的办法就是引入读写分离数据库的方法，数据库的压力暂时得到了缓解。除了数据库压力增加，服务器的压力同时也会增加的，于是便引入了负载均衡器，把流量分摊到不同的节点或者服务器上面去，来减小服务器的负载。到此为止都没有对项目进行拆分，所以依然还属于单体范围内。
2.烟囱式架构
随着业务的发展和增加，在原有的单体项目中加入更多的需求功能，会显得越来越困难，此时的项目也越来越臃肿，往往就是牵一发动全身，有些核心业务越来越不敢动，动就是线上bug，开发人员的变动，新加入项目的伙伴，往往熟悉业务和代码就会花上不少的时间，甚至有些开发从入职到离职有些业务都还是未知，上手非常困难。
当项目已经存活到了此时，不得不面临业务拆分的时刻，新的业务线的加入，很多企业采取的方法就是另启动一个单体项目，新的项目与老的项目偶有交互，就这样又度过了一段美好的时光，但是老的项目问题始终还是得解决，为了解决开发效率低以及不断的线上问题，最终还是不得不把老项目的业务进行拆分，拆分成为不同的单体项目，项目之间偶有交互，多项目并行运行，非常形象的像烟囱。此时已经出现了些许的分布式的概念。
3.分布式架构
在烟囱式的架构运行一定时间后，随着业务增加项目之间的调用也越来越频繁，项目与项目之间的调用错综复杂，数据一致性也难以得到保障，此段时期出现了很多分布式的解决方案，最典型的就是SOA和分布式事务，ESB消息总线等的技术。
4.微服务架构
在业务量的增加和和服务的拆分越来越多，服务的治理变得越来越困难，为了解决出现的问题，把分布式的架构在次升级为了微服务，虽然本质属于分布式，但是更是分布式的增强架构。微服务的出现有效的解决了服务治理的问题，例如，服务的地址管理，服务的上线和下线，服务的发现和注册等等。虽然微服务解决了不少的问题，但是驾驭也不算容易，服务粒度的拆分，跨部门之间的交流和沟通，运维发版上线等，驾驭都不好反而弄出更多的问题来。
5.服务网格架构
虽然微服务的出现有效的解决项目之间的交互和治理等问题，但是目前市场上微服务框架往往都是成套的单一的一种语言，例如java的springcloud，框架和语言绑定到一块的，如果其他语言需要加入到服务之间的调用会变得非常困难，为了解决这些问题，服务网格的出现非常好的解决该问题。
总结
对于项目本身的发展和拆分，用一句话概括就是：随着业务的增加对项目进行水平和垂直拆分，达到节约成本提升效率的结果
