## 方案一(保守方案) * 利用laravel框架封装RESTful(相对RPC更通用)风格的api,实现微服务。 * 利用nginx或者第三方服务,实现服务器集群和负债均衡。 * 利用redis做缓存服务。 * 利用redis(或者第三方的度列服务)提供消息服务。 * 利用阿里云提供的API网关服务,提供监控告警,安全检测,流量控制等。 * 利用docker实现自动化部署。 * 利用第三方推荐引擎,提供推荐服务器。 * 利用第三方搜索引擎,提供搜索服务。 * 利用第三方存储引擎,提供支援存储服务。 优点:技术比较普及,上手门槛低,学习成本低,容易把控。 缺点:如果未来用户量超过千万级,可能就需要再次重构系统。 * * * ## 方案二、使用PHP-MSF类似的框架,实现微服务。 优点:适合高并发的大型服务架构。提供更高效的流量吞吐能力,节省硬件成本。 缺点: 框架本身不成熟,必然有很多坑需要踩。 学习成本较高。 市面上懂这个技术或者有能力掌握这个技术的人比较少。 * * * ## 方案三、利用Swoole重新封装一套微服务框架 优点:自主研发,可按自身需要来最小化研发。 缺点:对技术研发能力要求比较高,一般技术封装出来达不到要求,无法和方案一和方案二的技术架构相提并论,考虑不周全的地方在所难免。 * * * ## 方案四、利用其他开发语言(java go等)的成熟微服务架构搭建(超出能力范围) 优点:架构成熟,可以直接招聘这方面的人才(在重庆还是不好招)。 缺点:不但要求技术人员有能力,还要考虑能不能招到人了。 * * * >以上方案都是针对微服务(服务层),应用层怎么做完全可以根据技术人员的喜好来。 ### 个人建议: 主要的瓶颈不在技术架构上面,而是"**在不断变化的业务需求中,软件架构既要能满足业务需要,又要保持自生不被污染**”,“如何来治理才是关键“,这对技术能力是一大考验。 无论是对框架的研发或者对架构的治理,都需要人才和资金的配合。在公司没有能力或者没有预算的时候(不适合创业公司),不建议做太复杂的软件架构研发。 方案一是我目前能够掌控的,对技术人才要求也不是很高,容易招到人,建议使用此方案。 其他方案虽然更能兼容未来,但是对我们来说还太远,我认为用户量还没有达到千万级,就没有必要上这样的系统。