浅谈web应用成长的三个阶段

<?php/** * 前言 *     在开始之前首先要明确的是这里所说的都是基于MVC模式的php应用，但是又不完全是MVC，因为这里还有一个业务层。关于MVC * 每个人都有自己的看法，有的是将业务写在控制器层（肥控制器瘦model），有的是写在model层（肥model瘦控制器）， * 但是这里我们的业务有专属的分层（Business层），业务层对控制器和model的隔离，是对具体业务的完整封装。Model层负责的是对 * 数据库表模型的操作，包括增删改差和数据的校验等，使用ORM模型或者ActiceRecord。Controller层负责的是用户访问的控制，收集 * 用户的请求数据调用对应的业务，根据业务处理的返回信息向用户返回对应的结果，而不用关心业务层具体的实现。业务层用来实现对 * 具体业务的封装，根据不同的业务类型大致分两类，一类是DataProvider（数据提供者）专门负责提供各种数据【注：包括缓存获取数据】， * 一类是BusinessHandler(业务处理程序)对具体业务的封装。业务处理程序一般是一个公开的方法，也可以是一个类将复杂的业务分步骤 * 进行封装，提供公开的方法供Controller调用。 *//** * 第一阶段： *      最初你的项目可能全都在一个目录下，通过不同的目录进行区分，多个子应用之间共享model或者业务层，通过这样来达到业务的 * 复用，一个比较好的情况是：控制器里不会出现model的调用，而是直接调用业务方法，这个方法有确定的参数和返回值，将具体的业 * 务封装起来，而业务中不会出现对session，cookie等的调用，数据以参数的形式传入，在业务中只是负责对数据层的调用完成整个业务， * 这时候只需要三个人就能完成对应用的开发，一个人写前端页面，一个人写具体的业务，另一个人负责调用业务与前端完成交互。 * 这是一种分层模式，如果没有一套好的代码规范每个人可以以自己的理解开发自己负责那一层的规范，即使某一层不合格后面也可以 * 对这一层进行单独重构和优化而不是对整个项目。如果项目比较大，有较多的数据库表，有较多的业务，这时候可以将整个项目按照 * 业务模块去划分让不同的开发人员去完成不同的业务模块，这样又保证了业务模块的规范性，如果这个模块不合格也只是对这个模块 * 进行处理，而不用对整个业务层处理。 *      一般情况我们会对业务层进行规范，传入参数的规范，返回值的规范，甚至是对业务模型写法的规范，业务模型封装的规范， * 这些规范将大大提高团队配合的效率，降低互相之间交互的成本，对于一个团队是非常有必要建立一套这样的规范，随着团队的扩大 * 你会越发感觉到这种规范的重要性。 *      对于一个拥有多个子应用的程序，这种做法将会省去对业务的重复开发从而达到业务的复用，保持了业务的一致性，让业务 * 便于维护。我们不选择控制器的复用是因为每一端的具体业务不同，返回结果的方式和方法不同，处理请求的方式方法不同，如果复用 * 控制器中将会有很多流程分支语句来控制业务走向，而且控制器本来就比较简洁，对于整个业务来说它就像路由一样。 *//** * 第二阶段： *      当业务发展到一定的程度，升级配置或者增加服务器所带来的收益已经跟不上业务的需求的时候，你可能需要考虑将应用部署 * 到不同的服务器上去了，你可能要用子域名来管理子应用和或者模块，但是又希望业务层不用重新开发，这时候就需要对项目进行切割。 * 将子应用分散到不同的服务器，单独将业务层部署到一台服务器。由于业务层和model层都是独立的，就可以为这些业务直接写一套接口， * 子应用将会通过调用接口的方式来调用业务，这样就以最小的变动保证了业务层的稳定。而切割出来的子应用依然是使用控制器， * 在控制器中调用业务方法，只是这时候业务方法的实现就仅仅是发起一个curl请求，去请求业务的接口完成一个请求。我们会发现控制器 * 没有发生修改，业务也没有发生修改，而是利用业务层的副本进行修改让他们从直接调用业务变成发出一个curl请求调用业务。然后 * 对业务层的请求方法进行抽象，对接口进行异常处理就轻松的完成了项目的切割。 *      为了保证业务服务器的安全我们直接将它放在内网只能让应用服务器请求，数据库也是只有业务服务器才能进行连接， * 而外部的请求就不能对业务造成危害，获取数据也可以在这里直接加上缓存。可能部分数据需要多个数据库，或者多个类型的数据库 * 聚合产生，这里可以采用定时任务去产生然后放到redis或者memecache中缓存起来让业务方法直接获取。 *      在一些对安全性要求比较高的应用，比如金融等等的发展到这个阶段的时候就可以将业务层转为java开发，从而平滑的提升程序的 * 安全性和性能。这样就变成了一个php做前端，java做后台的应用，在性能和开发效率达到了一个平衡。 *      在这个阶段我们可以将静态资源也独立出来，专门放在一个静态资源服务器，或者也可以将静态资源放到云端进行管理。云端的数据 * 往往是有多个备份的，这意味着安全性得到了很大的保障，有些也提供了对图片资源的处理，和对资源访问的控制。开启CDN加速后 * 网站的速度又将获得一个极大的提升，而我们的应用服务器的压力也得到了有效的缓解。 *//** * 第三阶段： *      当网站有了比较多的访问量的时候，单台服务器已经很难支撑大并发，这个时候可以考虑使用负载均衡来提升应用的抗并发能力， * 根据应用的访问量定制大小不同的应用集群。如果业务层的规划很好不需要重新开发，这时就可以根据业务模块放到不同的业务服务器集群。 * 而数据库和缓存的压力可以通过主从读写分离的方案进行升级，当然这些都是基于你的项目有一个不错的基础，清晰的分层结构，合理的 * 数据库设计，和良好的代码规范。一个相反的案例就是随着项目的成长每到一个阶段都要对项目重新进行开发，甚至对数据库重新设计， * 这样带来的就是大家一直在赶项目，一直在加班，一直在测试，一直在改bug。 *//** * 尾声： *      笔者是一个php程序员，没有丰富的经验和资历，只是结合自己做项目的经历和在项目中的观察和总结来谈谈自己对网站应用开发 * 中的见解和认识。由于对没有经历过大型的项目，所以对第三阶段也不好说太多，只是按照自己的所想简单的表达出来。文中没有提一些 * 技术上的细节及实现方案或者具体的例子，可能导致表达不清楚，所以就总结了几个关键字：分层、切割、平滑扩展。希望可以对那些 * 曾经和我一样纠结的人一些借鉴，互相学习，共同进步。 */