在很多项目的立项之初经常听领导要求，我们的体系架构要如何如之何，要参考微信、支付宝这些龙头厂商的系统。我就不禁要问，我们考虑到用户规模、复杂度、投入成本、业务实际场景了吗？我们做应用的不是为了架构而设计的，是为了满足业务发展需求而设计的，那么就应该立足现在，适度放眼未来，采用小步快跑、逐步迭代的方式来设计我们的系统架构，这样才能够快速验证、及时调整、节约成本。
我多年前的一个经历就是，老板一上来就要去构建一个千万级用户的复杂系统，导致机房、带宽等成本巨大，研发周期也很长，项目投入巨大，结果运营多年后用户量也只有区区数十万（这样规模的系统运维成本每年只需要数万元而已，而实际投入数百万），而且架构过于复杂，后来重构也付出了巨大的代价。
所以，不要过分强调架构的先进性、长期性，而是要立足核心业务，利用80%精力解决20%关键问题，只留20%精力解决80%周边问题即可，再有不要期望长期不变的体系架构，还有在项目初期阶段充分利用公有云服务能力快速实现业务目标。总之：立足现在、放眼未来、脚踏实地、亦步亦趋、简约而简单。
刚刚看了一篇讲架构演进的文章，写的不错，引用这里以佐证《从新手到架构师，一篇就够：从100到1000万高并发的架构演进之路》。
网友评论