架构设计的度

    前段时间有个项目，在数据汇总这一步每天都要处理大量数据，为了考虑扩展，上了hadoop，虽然花了不少时间做预研，内部也测试了好久，但因为是初次使用，在上线使用后还是碰到了非常多的问题，系统问题，性能问题，hive bug......
    我们马不停蹄的救火解决问题，在救火的过程中逐渐应用了另一套更轻量级的处理架构，并且在数据暂时没有进一步增长的情况下，替代了hadoop的处理方式。而原定的hadoop变为了备用。虽然现在用的扩展性没有hadoop好，但在一定数据量的情况下，处理能力还是非常高的，并且由于逻辑简单，维护方便，成本反而更低。
    很多时候我们想架构做的很完美，特别是要扩展性通用性要做到很好，但在快速发展的市场上却往往一开始表现还不如稍差一点的架构。虽然在持久战中好的架构会有优势，但如果你一开始就被灭了，那就根本没有机会等到以后展现优势了。最好的产品不一定笑到最后，这点已经被无数次证明了。首先我们要做一个不错的产品抢占市场，等站稳脚跟有了稳定的收入后，再不断完善优化。
    理想是美好的，现实是残酷的。产品做出来是为市场服务的，最终目的是转化为公司的收入。所以要做好架构，不能只考虑技术，还要综合考虑团队、市场、竞争对手等多方面的因素。否则叫好不叫座就只能哭了。
    如何把握好这个度，就要靠经验，特别是失败经验的积累了。