归根结底一句话：高并发系统的演进应该是循序渐进，以解决系统中存在的问题为目的和驱动力的。
martin fowler好像曾经说过，能使用单体解决的问题，就不要采用分布式。不能为了技术而技术，采用分布式固然可以分流用户请求，提高系统的响应能力，但同样也带来了复杂性。软件开发最终的目的是商业利益。非常赞成老师的观点，罗马城不是一天就建立起来的。架构的工作应该是阶段性，解决阶段性系统的复杂性。如果单体跑的很好，或者通过scale up方式在成本可控的情况能解决就不要想着诗和远方，因为系统内部的进程间调用，肯定比不同物理机的进程之间调用要快。
之前做的创业项目也是遇到盲目优化的问题，系统最核心的撮合结算服务，刚开始只能100次每秒，后来为了优化到百万级，花了大量时间研究各种方案，做了大量的性能测试，耽误了很长时间推向市场，结果最终优化到了不到一万tps，但后面真正上线的结果可能不到也就100tps，所以真正的需求是市场需求，不是一开始就冲着最牛逼的方案搞，线上的需求远比一开始的预想复杂，没足够的资源和动力，绝对不要折腾，不过时刻准备好可能会出现的瓶颈是必要的，免得半夜宕机，慌得一比
架构设计的过程中要识别每个阶段的复杂度，有针对的做架构设计。避免过度设计带来的成本上升。
1.技术在不断演进，演进的目的和内驱动力是解决当前系统存在的问题，过早过度设计大多只会延误系统的发展。一切都以实际情况和需要出发，一步步优化，一步步演进，个人能力提升也是同样的道理。
2.高并发系统设计通用方法:水平拓展，缓存，异步。这只是指导思想，如何更巧妙的运用才是最具魅力的。