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

用户头像
Lost Horizon
关注
发布于: 2020 年 07 月 01 日
架构师训练营第四周 - 总结

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



要点总结

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

  • 高性能

  • 高可用

  • 可伸缩

  • 可扩展

  • 安全



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

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



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



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



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



用户头像

Lost Horizon

关注

给写代码的人写代码 2017.10.17 加入

Clojure

评论

发布
暂无评论
架构师训练营第四周 - 总结