架构师训练营第四周学习总结

发布于: 2020 年 07 月 01 日

第四周的内容主要介绍了典型的大型互联网应用架构,并做了一些案例分析。贯穿始终的一个关键词是“问题”。老师不止一次的强调,发现问题比找到解决方案更重要。之后讲述的架构设计也是如此,为了应对出现的问题从而出现了相应的解决方案。

提高系统性能的方法有两个方向,一是垂直伸缩,一是水平伸缩。

二者各有优劣,垂直伸缩初始阶段接近线性,超过临界点后趋于指数增长。水平伸缩初始阶段成本更高,超过临界点后趋于线性增长。

互联网架构演化

0. 单一服务器

这就像我之前学习Angular+Play时在自己电脑配置的架构。

  1. 应用数据分离

之后在将Angular+Play的项目部署到AWS上时,除了没有文件服务器,也实现了应用数据分离。

  1. 使用缓存

最近业余时间做的一个前端项目使用了一些本地缓存。

  1. 应用服务器集群

  1. 数据库读写分离

  1. 反向代理与CDN

  1. 分布式文件系统与分布式数据库系统

  1. NoSQL与搜索引擎

  1. 业务拆分

  1. 微服务与中台化

  1. 大数据与智能化

大音希声,大象无形。

互联网架构模式

分层与分割

核心要素:高性能、高可用、可伸缩、可扩展、安全

互联网架构技术

将如上结构应用到之前的架构图

之后的课程讲述了一些实际公司的例子,包括这些公司的架构设计,进一步印证了这些架构的可行性和试图解决的问题。

从互联网架构演化的第三步开始,就基本上完全没有接触过了,而且现在的工作还是传统软件项目。回想上一份工作是一家互联网初创公司,当时只关心和自己有关的内容,并没有对整体的架构进行把握。现在看来,那家公司的架构并不算复杂,不同的业务有不同的应用服务器集群,而所谓集群,大概也是由2-3台服务器构成的。所以使用Nginx主要是将请求按照业务进行分发。

各部分业务之间几乎不存在交集,所以没有消息队列进行消息传递。不过微服务的架构是有的,其中用户模块和脚本运行模块是两个主要的微服务。只能由内部系统访问,服务于应用服务器和数据分析。

数据库采取简单的主从数据库模式,不过由于访问量不高没有进行读写分离,从服务器作为备份以防万一。试图引入NoSQL数据库来简化一些在关系型数据库中十分复杂的数据,不过听说主要负责的开发离职后,逐渐移回了MySQL。

此外,还有一点之前提的不多的内容在那家公司也很重要,由于是数据驱动的产品,有一个很大的部分是数据的抓取、清洗、预处理最后存入数据库。我在离职前负责了不少这方面的工作,但是因为早期这部分由数据科学家负责,各部分耦合度很高,逻辑都在几个庞大的Python脚本中。在我开始负责后,进行了有限度的重构,主要只是将一些公共逻辑提取出来增加重用,但是由于不同用户的数据格式含义之间总有一些微妙的区别,所以即使提取公共逻辑也十分困难。没有进行大规模重构的原因一个是不希望承担潜在的风险,一个是数据科学家仍需要参与,担心大规模重构会增加他们的理解成本。

但是现在再看这个问题,重构应该会减轻所有人的工作而不是增加,更好的解耦和模块化会使代码更容易理解而不是更难,而且很明显我自己在当时也不具备相应的实力去进行重构。这里其实也可以应用垂直伸缩和水平伸缩的逻辑,不进行重构看似只是保持线性增长,但是当复杂性超过临界点时,维护成本会急剧上升。重构则是需要一开始就付出更多的努力,而且效果不明显,但是当复杂性继续上升时,维护成本会趋于线性,并且方便多人协作。

发布于: 2020 年 07 月 01 日 阅读数: 27
用户头像

whiter

关注

还未添加个人签名 2020.05.29 加入

还未添加个人简介

评论

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