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

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



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

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



互联网架构演化

0. 单一服务器

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

1. 应用数据分离

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

1. 使用缓存

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

1. 应用服务器集群

1. 数据库读写分离

1. 反向代理与CDN

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

1. NoSQL与搜索引擎

1. 业务拆分

1. 微服务与中台化

1. 大数据与智能化

大音希声，大象无形。



互联网架构模式

分层与分割

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



互联网架构技术

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

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



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

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

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

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

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