项目初期-无架构
以我经历的ToB项目为例，由于高层的业务规划，公司需要发展一个业务方向，那么为了能够让业务快速体验，因此从项目立项到MRD、PRD、技术方案的评审在两三天内就会快速过完，那么技术在应对这种业务需求是我们是没有梳理完整的技术架构，前期技术主要把握的点是把控业务的实现难点和可行性。
因此项目开发时直接套用基础的SpringBoot+SpringCloud的方案开发，要求快速上手开发。
因此针对这种场景我把它定义为无架构时期。该时期整个系统是没有架构可言，只要能够快速上线就是好架构。
项目初期没有架构是正常的，有时为了赶业务的上线时间，技术的前期就是要快速上手开发，快速迭代快速上线，保证业务的快速使用。
项目中期-适应业务
项目前期为了快速发展业务已经完成了快速上线，那么后续就是观察业务的接入量，系统的QPS、TPS、RT等指标是否在可控范围内(不会造成系统宕机的范围)。
中期就是完成接入业务量和扩展业务方向。
项目中期更多的精力是扩展业务上，可能前期业务发展还不错符合预期，那么就会接入更多的业务，获得更大的效益，因此该时期要做的就是快速迭代，系统做到兼容不同的业务。
针对以上扩展业务的场景我把它定义为适应业务时期，该时期整个系统是在核心链路上需要格外关注并增加适当的扩展的，该时期虽然会讲究一些架构的定义但是也是针对核心的链路，该时期最主要的依然是适应快速发展的业务。只要能够接入更多的业务就是好架构。
项目末期-当前架构无法支撑业务的发展，一个需求的变更需要投入的时间/人力成本和资源巨大，影响项目的发展
中期系统接入了大量的业务，整个系统维持业务的运转，为了保证系统的稳定性和高性能可能会增加大量的机器保证系统的稳定。
当项目进入末期时由于系统接入的业务体量巨大，并且前中期没有考虑整个系统的各方面的扩展性会导致后期开发需求时造成开发人员的对系统的上手时间久，需求开发的周期长，投入的人力成本多等问题。
此时系统就遇到了所谓的瓶颈（技术债），并且该瓶颈无法通过加机器加配置的方式解决，这时候就要考虑架构优化。
针对以上的场景我把它定义为架构瓶颈时期，该时期整个架构遇到了难以通过增加机器的方式解决，需要从系统架构上进行优化调整，以解决系统上手困难、开发周期长，人力投入高等问题。
