架构师训练营第四周 - 总结

这周讨论了大型互联网应用的架构。首先分析了这类系统面临的挑战，以及技术方案和手段。然后以维基百科、淘宝、宅米、微博为例，分析了这几个系统面对的问题，以及由此推动的架构演化过程。



要点总结

如何衡量一个系统的架构设计

• 高性能

• 高可用

• 可伸缩

• 可扩展

• 安全



系统架构知识是架构师的常识而不是能力

各种架构模式都是在解决某类反复出现的问题时，通过实践而总结出来的，这些模式是架构师工具包里工具，但架构师的能力不是体现在知道多少种模式，而是将这些模式恰当地运用到实际工程项目当中。不仅要考虑技术层面的问题，还要考虑可供调配的资源，除了资金和人员以外，一种重要的资源是时间，当业务需要抢占市场，开强拓土时，时间是个重要的考虑因素，有时甚至是成败的决定性因素（因为网络效应，赢家通吃，这点在互联网应用上尤其突出）。这时一个不“高大上”但能快速上马的架构，可能也是合适的选择。这与做严谨的学术研究是不一样的，架构师做设计时要避免落入“完美”的陷阱当中。



技术架构要为业务服务，架构演化的起因是业务增长、业务转型。具体问题需要具体分析。课堂上举了一个实际系统中的例子，当业务增长达到了200万日交易量时，数据的积累会很快达到 MySQL 可承受的单表容量（单表数据量太大会严重影响性能），这时是否应该马上采取分库分表这种方案呢？在这个案例里，其业务特点是只有最近期的交易才会被经常查询，大于一定天数之前的交易很少被查询，那么可以使用将旧数据迁移到非交易用的数据库中存储（这个案例中使用了MongoDB），平时只在主数据库（MySQL）中查询近期交易，用户偶尔需要查询更早的交易时，应用服务器才转到MongoDB中查询，这样就避免了分库分表对应用的重大重构，节省了大量的时间。



架构设计还有考虑开发团队之间的配合。子系统和模块划分，会反映到团队的划分当中。如果模块间的调用关系错综复杂，团队之间的交流也会陷入混乱，造成推诿责任，各自为政的局面。



架构师这个角色需要具备大局观，架构师除了系统架构知识这些基础“硬件”外，还需沟通、协调、推动、激励这些软技能。