背??景事情源于我们在做框架选型的时候，分析了业务需要的技术栈，发现我们需要的框架只需要包含路由、数据库、Redis、日志就可以满足需求.让我们讨论然后开始选择框架。选型讨论有些人在选框架的时候更喜欢使用Laravel、Yii等功能丰富的框架。这些框架提供的功能完全可以满足业务需求。但反对意见认为，这些框架的学习成本都比较高，新人接手不容易，而且性能较差，很多功能用不到；而其他人更喜欢使用Slim和Yaf。框架提供基础路由，其他功能组件通过lib加载，实现各种组件的按需加载。没有冗余特征，学习成本比较小。这个解决方案也有很多反对意见。每个组件能否很好的和框架结合，每个lib都有自己的API风格，学习成本不小。以及如何保证各个lib的稳定性。在这样的情况下，就有了构建一个满足各方需求的框架的想法。团队希望框架只包含常用的功能组件，Event、Behavior、Broadcasting、Notification等很少用到的功能尽量不要，减少不必要的学习成本；为了支撑几千万的业务PV，希望框架的性能足够好；同时希望框架的可维护性好。对于一些特殊的场景，框架可以提供很好的可扩展性，将一些功能集成到框架中。最后讨论决定自己开发一个框架，于是开始了整体框架的设计。设计框架首先是底层框架。设计底层框架的首要问题是如何管理框架的所有类及其依赖关系。相对于成熟的方案，有两种方案：依赖注入和基于组件的设计。由于考虑到后续各个组件的单元测试，所以选择了依赖注入的方案。功能组件其次是框架的核心组件。框架包含的基础功能组件包括数据库、鉴权、日志、Session、Cookie、Redis等，对这些组件的封装有两种选择。可以使用外部开源的composer组件，也可以自己实现，因为不同composer库的API风格不一致，很多库需要的文件太多，所以决定自己实现这些核心组件。易用性需要完成一件事。许多功能丰富的框架提供了多种方法。开发功能时，方法A和方法B都可以使用。有时用户可能会感到困惑，应该使用哪一个；并且随着业务的迭代，在使用上会出现各种异同。因此，我们更愿意只提供单一的方法，以减少用户选择的混乱，同时提供系统的可维护性。扩展框架包括常用的基础组件。为了支持一些特殊组件的使用，框架集成了composer，并提供了基于组件的扩展能力。综上所述，经过三个多月的开发，框架已经开发成熟，可以在多个产品中使用；框架的某些部分可能需要不断优化，欢迎大家提出各种Issues。我们的目标是打造一个国产的，优秀的PHP框架。最后直接列出框架和开发手册。:)BetePHP：https://github.com/betephp/be...中文手册：http://betephp.com/zh/
