项目发展期（100<并发<1000）
前文链接：
当业务正常上线后，随着线上业务的成长，初期的架构到达一定的瓶颈，应用产生越来越多的访问量、并发慢慢增加，服务器的CPU、磁盘存储空间压力都会随之增加，这个时候我们就会考虑做一些服务器扩容的工作。
对于网站的入口压力最大的问题就是并发量的负载均衡，通常的QPS的计算方式为二八定律，这个定律适用于一般的所有的业务场景，但实际业务中会有一定出入。例如在股票行业中，每天9.30左右前后15分钟是访问最高点，电商类行业在爆品活动抢购，或者广告高投入时为最高点，而12306在春运时放票特定时间时也是最高点。
当然，如果在业务能力达到春运火车票的体量时，本文也就不再适用了。
先上系统结构图，再进行说明吧！如下图所示：
在负载部分，前文简单提到过ssl证书绑定阿里云SLB服务时会产生访问低效问题，本文建议使用Nginx进行负载和反向代理的处理，对于负载服务器的要求是满足并发要求，CPU和内存较为重要。初期可以将负载均衡部署在主应用服务器，减少服务器成本。https是现有网站的标准配置，在前期可以使用阿里云的免费证书，无费用增加项，如何配置证书现在网上资料较多，本文中不再叙述。
结构图中涉及到的一些组件我将一一进行说明：
日志服务，阿里云的日志服务是相当强大的，同步的方式也有很多，一般的日志存放会习惯性放于日志文件或者缓存当中。曾经在12年时做过一个项目，当初为了做一个广告数据分析系统，采用lua进行日志收集，并存放到redis当中，再按分钟级进行数据读取写入到db中，这样对硬件资源配置非常之高，而且效率其实并不高。在Elasticsearch应用更广之后，大家开始习惯将日志推送到其中，一是便于保存，二是便于查询。并可以搭配Kibana进行日志的查询搜索和二次分析，有兴趣的可进行研究一下。但是在云服务中更推荐使用阿里云的日志服务，成熟的控件，强大的分析机制，数据保存机制，其实都会比elk更加强大和稳定。并且在大数据分析上，日志存放到OSS中后，更是可以接入MaxComputer进行二次分析。
OSS作为日志存放，比传统的云磁盘储存在费用和访问速度上更快，相比于一般的图片服务器，我较为推荐。在后期配合CDN加速上也是神器之一。
MaxCompute是一项大数据计算服务,它能提供快速、完全托管的PB级数据仓库解决方案,使您可以经济并高效的分析处理海量数据。这块内容相当多，如果有兴趣可以去阿里云产品官网查询，后面如果有时间我可以考虑出一套此类的学习教程。
在业务应用最大的压力来源于数据库的读取，这也是服务压力的主因之一，拿PHP开发语言来说，查询mysql的瓶颈尤为严重，并发数一旦过高数据量过大时，查询效率就不能再得到保证。按二八原则，80%应用的业务的访问集中在20%的数据上。比如淘宝买家浏览的商品集中在少部分成交多、评价良好的商品上；百度搜索关键词集中在少部分热门词汇上。既然大部分的业务访问集中在一小部分的数据上，那么如果把这小部分数据缓存在内存中，是不是就可以减少数据库的访问压力了，提升整个网站的数据访问速度，改善数据库的读写性能了呢？答案肯定是的！
网站使用缓存可以分为两种：缓存在应用服务器上的本地缓存和缓存在分布式缓存服务器上的远程缓存。本地缓存的访问速度更快一些但是受应用服务器的内存限制，其缓存的数据量有限，而且会出现和应用程序挣用内存的现象，影响应用程序运行速度，甚至造成服务器死机。远程分布式缓存可以使用集群的方式，
阿里云Redis中其实已经包含了各种节点，主从集群等等。这一步的升级只用将原来云服务器中的redis进行迁移切换到阿里云Redis中，再根据实际储存大小进行选取配置就可以了，所以阿里云Redis适用于远程集群缓存。
如果涉及本地化数据缓存其实也可以在应用服务器搭建应用服务器中搭建本地化缓存，加快缓存读取速度，减小集群缓存压力。
Ps：阿里云多节点会在使用PHP-laravel-Queue中出现问题，请注意避免，原因应该是数据同步的问题。
常见的NoSql缓存有memcache，redis等。PHP的缓存也有Cpcode等等。其它缓存可以根据实际需求开启。
数据库这一部分只用根据应用场景升级配置就行了，可选多节点、集群、储存服务器CPU和硬件，这里就不再啰嗦。
也许有些人会问，为什么在初发展阶段将业务结构设计得如此复杂？
项目在初始阶段是最干净的阶段，很多公司在业务后期进行架构规划，包含数据维护，数据迁移，服务运维，后期如果进行大调整的话所要付出的代价将会非常之大。图中所演示的内容是只提供了一个思路，在实际应用中，只用做到应用与业务分离，组件与组件分离，功能上解耦就能大大降低后期重构或者扩展的成本。