腾讯比Facebook更会赚钱，但两家公司天花板不同

　　一、基础运行环境

　　针对新产品的开发，必需能够快速搭建一套LAMP架构。那么无外乎选择一个webserver，选择一个php版本，选择一个mysql版本，再选择一个PHP开发框架和选择一些php通用扩展和基础库等。这个过程读者可能觉得已经很快了，能不能更快?

　　选择的过程要求研发同学对相关技术方向有一定的积累，权衡利弊和优先点，又是一番调研和学习。假如有一键安装程序，提供自动化安装webserver，php，mysql，以及携带高机能灵活的php开发框架，并提供尺度化、安全、常用的配置文件，可以大大缩短产品线LAMP系统调研的本钱，缩短工作周期。

　　一键安装四步骤：(1)下载;(2)少量配置;(3)make install;(4)start;(当然有end啦，简朴的运维工具)，运行环境OK。

　　二、业务开发框架

　　社区产品线各自为政，封锁得开发各自的业务逻辑。而事实上，各个产品线之间存在良多通用业务逻辑处理，如session验证、权限判定、参数验证、日志打印等。不同产品线，所有哀求都需要做这些处理，能不能不重复开发?无线业务开发和PC上的业务逻辑有良多的不同，但不同产品线之间也有良多通用性。能不能不重复开发?

　　产品线在内部通常对这些通用逻辑的处理做了一定的抽象，设计为ActionChain的形式或者通过基类的方案。框架将更彻底：将这些所有哀求都要处理的通用逻辑以业务逻辑框架的形式提供，研发同学只需要关注用户哀求专有的逻辑处理。

　　业务逻辑框架继续在一键安装程序中提供，简简朴单就可以获得。

　　原生的PHP业务和模板耦合很深，没有做任何的分层设计，其结果是代码的复用性差。这样的原始的PHP系统现在已几乎消亡。PHP开发框架同一处理路由、渲染、AutoLoad，通用业务逻辑的抽象和基础库的抽象，专有业务MVC分层，已大大加快了产品线业务逻辑的开发。

　　三、通用服务

　　社区产品线存在良多共同的需求，如日志处理、配置文件的处理、字符串处理、数据库交互、网络交互等。这些算法和工具封装成phplib给产品线使用已比较成熟。

　　社区类产品线的业务功能存在良多的通用性，诸如评论功能、Tag功能、挚友功能、图册、任务系统等，在众多社区产品线都有类似的新功能新需求，各自设计开发?

　　这些需求在各产品线的UI上有个性化需求，但是后端实现方案大同小异，具有一定的通用性。功能服务化，提供API接口给不同产品线使用，产品线只需要关注展现逻辑和私有数据的处理逻辑即可，且服务同一运维，降低产品下的系统复杂度。

　　四、垂直拆分子系统

　　那么跟着我们业务的拓展，单个应用内部的ui和module的数目越来越多，Action和Logic(对应MVC中的M层，内部可以再进一步做分层处理，此次不胪陈)的交互，logic和logic之间的交互变得越来越复杂。开发同学需要了解整个应用的逻辑，某个logic的进级，需要排查整个应用下是否存在其他ui或logic的反向依靠。在快速开发的要求下，开发同学对logic之间的相互耦合关系的梳理不清晰，势必引发越来越多的题目，影响项目质量，难以开始开发。

　　单一系统的题目暴露越来越多，就到了系统拆分的时候了。如何拆?按业务逻辑垂直拆分。将功能独立的业务逻辑剥离出来，做成独立的子系统。这个时候还需要考虑业务的通用性，是否可以服务化?应用已有相同需求的通用服务?此时通用业务逻辑封装成通用服务或使用了通用服务，旁路的业务逻辑独立成子系统，如斯一来就将原先单一庞大的系统做了大量减负。完成此阶段的重构后，系统加入变成如下：
 

　　单一系统被拆分成多个APP(APP内部仍旧有横向的MVC分层)，并复用大量的通用服务。如斯一来研发团队在职员分工并行开发上都得到了极大进步。

　　五、跨系统调用框架

　　然而真实的现状，在拆分后的子系统之间并不能完全消除依靠。为了解决多个子系统之间数据依靠的关系，需要一套同一的解决方案：API框架。子系统成为独立的应用(APP)，APP之间存在相互的数据依靠，这些依靠以API的形式对外提供。
　　APP提供的API解决提供接口描述(输入、输出)，处理API的URL，Logic的转发实现。API_LIB同一来治理所有的API接口，并提供同一的API_Server::call接口供调用。完全对上屏蔽内部的转发和实现细节。通常产品线内部为了达到运维的简化和同一，所有的子系统是同机部署的，API接口的会带来额外的网络消耗，以及增大qps。在此部署条件下，API_Server的实现方式可以通过HTTP调用或优化为直接PHPRequire方式实现。上风：

　　(1)框架同一，接口收敛，业务解耦;

　　(2)机能晋升，易用性高，扩展性高;

　　六、UI拆分模型

　　此时独立出来的子系统可以专注做其业务逻辑了，核心的系统也得到减负。但是核心系统的进级更新频率是最高的，业务逻辑也最复杂。到了一定时期，核心系统又变得臃肿，难以维护。此时可以通过一些设计模式来降低程序的可扩展性和可维护性。但即便是如斯，仍是有一定的学习本钱，在一个App内部，开发同学或多或少需要关注其他模块的代码，逐渐发展为进级一点就需要排查良多点。这时候又到了进一步减负的时候。假如减负?分为两部：

　　第一步：异步模型

　　页面渲染分为两个阶段：主题页面数据和其他非主题页面数据。根据页面的不同部门由不同的数据源提供数据。按此逻辑将app进一步做垂直拆分。

　　PHPService是由PHPmodule+一层很薄的UI，返回格局化数据。

　　第二步：同步模型

　　Module做拆分，不同业务逻辑拆分为不同的Module，区分为多个数据源，分别提供不同数据内容，由同一的UI调度不同的数据源后，同一进行渲染页面返回响应。

　　如斯持续减负后，产品线内部的子系统和模块将越来越多，需要维持部署和运维的同一。对团队成员的分工很细，业务理解很专注和深入，合作、并行的效率也会更高，从而使整个开发周期缩短。

　　七、 小结

　　跟着业务逻辑的不端壮大，每个子系统或模块的业务功能假如过于臃肿就需要不断做减分，以保持在可控的规模内。如斯跟着产品的发展，产品线内部的子系统和模块将越来越多，需要维持部署和运维的同一，保持简朴。对团队成员的分工更细，业务理解保持专注和深入，合作、并行的效率也会更高，从而使整个开发周期缩短。