【架构师训练营 1 期】第四周作业及学习总结

学习总结：本周涉及的知识点较多，干货很足。从很多细小的点引发了我许多方面的思考，其中一方面是对照了我们公司目前的系统架构，发现很多环节值得细细地盘一下、好好借鉴一下，比如数据库瓶颈，比如业务系统的冗杂、业务变更造成的牵连太多、以及怎样进行微服务化演进、怎样不影响现有业务的前提下平滑地进行业务拆分等等。另一方面是从这几节课程的学习和思考中，让我发现自身缺乏的知识点，并回顾了一些已经遗忘的知识点，让我重新结合工作中碰到的问题……让我真正的一点点摸到了改造架构的感觉，甚至是有希望自己来尝试。李老师从维基百科的架构设计、淘宝网的架构演进过程、到宅米网的架构升级迭代，不仅了解了互联网巨头的发展轨迹，也给我开拓了很多思路，让我对公司系统架构产生了一些新的想法，甚至多了一点激情，真是受益匪浅。

（"知识点总结"和"课后作业"结合在一起，如下）



课后作业：一个典型的大型互联网应用系统使用了哪些技术方案和手段，主要解决什么问题？

（如下）



一、技术方案的思考

1、建立分布式缓存

其中主要采用Redis主从(一主多从或者级联结构)复制方案(全量同步和增量同步)。

主要解决的问题：当访问量增大时，频繁查询数据库会导致DB服务器计算资源紧张，查询效率降低，影响用户体验。引入缓存可大幅提高查询效率，而分布式缓存则可以分摊缓存服务器的IO压力，从而有效减少对DB直接的IO操作，让DB有更多资源去处理其他"关键"的业务数据（如更新交易金额、交易状态）。



2、搭建应用服务器集群

由多台服务器部署相同的应用构成，通过负载均衡来调度服务器，也是水平伸缩的一种实现方式。

主要解决的问题：在高并发场景下，通过多台应用服务器分摊并发请求，减小单一服务器压力，从而提高整个系统对高并发请求的处理能力。(在架构演进的过程中，再逐步对业务进行拆分，每个服务都可以拆分为独立的一个系统，部署为一个集群)



3、数据库读写分离

主(读写)从(只读)分离(一主多从)，通过主从复制保持数据同步。

主要解决的问题：在大部分应用中，"读"占了大部分资源，而"写"占得小。为了保障DB服务器的资源分配合理且互不影响，将读和写进行分离，采用一主多从的方式，分摊主库的压力，提高"读"的能力，充分的利用主从服务器的资源。降低数据处理对整个系统造成的影响，从而提升整个系统的并发能力。



4、CDN+反向代理

其主要是访问静态资源时的一种缓存机制。如果CDN中没有缓存数据，则会把请求发给反向代理服务器，如果反向代理服务器也没有缓存数据，则继续通过负载均衡分发给应用服务器。

主要解决的问题：让绝大部分请求通过CDN直接返回，小部分请求通过反向代理服务器返回，剩下的请求才会通过负载均衡分发到应用服务器处理。即能从就近的"缓存节点"消化掉绝大部分的请求(静态资源)，相当于从源头就把大量的请求过滤了，从而减轻应用服务器的处理压力，进而提升整个系统的并发处理能力。



5、分布式文件系统和分布式数据库系统

使用分部署关系数据库，将数据库进行分片处理。

主要解决的问题：将数据库进行分片处理(使用多台DB服务器处理同一批(组)数据)，通过数据库集群，分摊每个数据库节点的读写压力，提升数据库写操作的处理能力以及数据库存储能力，从而提升整个系统的并发处理能力。同理，将文件分片处理，从而提升分布式文件系统的读写能力。



6、NoSQL和搜索引擎

通过建立NoSQL(处理"海量"数据)和搜索引擎提高查找效率。

主要解决的问题：缓解分布式数据库对于复杂查询的效率及压力(比如模糊查找)，和缓解关系型数据库(Mysql)对于"海量数据"的局限性，通过NoSQL+搜素引擎来提高"海量"数据的查找能力和查询效率，进一步减轻Mysql的负担，从而提高整个系统的并发处理能力。



7、业务系统拆分

将每个业务拆分到不同的集群（尽可能保持业务职责的单一性）。

主要解决的问题：随着业务的增加，业务变得越来越多，系统变得越来越庞杂。所以将每一种业务拆分到不同的服务器集群，减小业务变更、新增业务或业务模块故障对其他模块或整个系统造成的影响，同时让开发和维护变得简单，让扩容(水平伸缩)变得更灵活，从而应对业务的快速发展。（各服务之间可以通过RPC、HTTP进行调用，也可以通过异步消息队列进行通信）



8、微服务化及中台化

抽取共用的服务拆分成独立的微服务集群。

主要解决的问题：和上面业务系统拆分密切相关，是解决业务系统的庞杂、高耦合、难维护、难扩展、牵一发动全身、故障牵连等问题。抽取出公用的服务，拆分成各独立的集群，各公共服务(基础服务)由微服务来提供，应用服务器只需处理自身的业务逻辑，将这些公用的基础的服务统一起来就构成了所谓的中台。从而能够适应更多更复杂更通用的产品需求调用。



9、大数据、智能化

主要解决的问题：针对不同的用户提供不同的服务(即提供个性化的服务)。通过构建大数据平台，进行数据的挖掘和智能分析，从而更精准的服务(推荐)于每一个用户，比如：今日头条的推荐系统。



二、架构模式的思考

1、分层

在横向维度上切分成几个部分，每个部分负责一部分相对单一的职责，通过上层对下层依赖和调用组成一个完整的系统。

(例如：MVC—>MVP、MVVM)，在实际工作中分层还需结合实际场景考虑复用性、便于分工、避免跨层调用、逻辑一贯等等。



2、分割

在纵向方面进行切分，对每个业务中的功能模块再进行分割(同样可以部署在不同的服务器)，从而更好的解耦，更利于独立的开发、部署、维护和扩展。

例如：在一个叫车系统中，订票模块可以独立拆分，派单、抢单模块可以独立拆分，支付模块也可以独立拆分，拆分成各个子系统并部署在不同的集群等等。



3、分布式

分布式应用和服务、分布式静态资源、分布式数据和存储、分布式计算。

结合上一点"分割"的模式对业务系统进行拆分，同时进行"动静分离"，将静态资源和动态数据分别建立独立的集群，不同的业务数据库也有独立的集群。



4、集群

将独立部署的服务集群化，即多台服务器部署相同的应用构成一个集群(每台服务器承担的职责是一样的)，通过负载均衡共同对外提供服务。

避免单一服务器宕机，而对业务造成影响，提高整个系统的高可用。



5、缓存

将数据存放在距离计算最近的位置以加快处理速度(类似CPU)，CDN、反向代理、本地缓存、远程缓存)

主要是对静态资源的缓存机制，"就近"拿数据，效率高。减少对应用服务器的IO压力。

比如：淘宝、京东的商品图片。



6、异步

好处是提高系统可用性、加快网站响应速度、消除并发访问高峰。

比如：消息队列。



7、冗余

避免服务器(节点)宕机时，其他服务器(节点)的数据冗余备份可以继续提供服务，从而保障系统高可用运行。

比如：定时任务备份或多节点主从复制备份，最大程度减小宕机造成的影响。



8、自动化

无人值守的情况下，自动监控、自动扩容、从而自动维持系统正常运行。



9、安全

身份认证、数据传输加密、敏感信息过滤。



三、架构能力的思考

1、高性能

影响用户请求的所有环节都可以进行性能优化（如以上分析）。



2、高可用

在互联网分布式系统中主要手段是冗余（其他：做集群，多节点容灾）。



3、可伸缩

可以灵活向集群中增加或减少新服务器，衡量伸缩性：需要容易、短时间、无差别。NoSQL数据库伸缩性更友好，分布式关系型数据库较伸缩困难。



4、可扩展

关注功能性的需求，衡量可扩展性：增加新业务(产品)时，对现有业务透明无影响，不需要改动或很少改动既有业务，不同业务(产品)间低耦合，即一个业务(产品)改动，对其他产品无影响、不受牵连。可扩展性架构的主要手段是事件驱动架构和分布式服务(微服务)。



5、安全

保护系统不受恶意访问和攻击，保护重要数据不被窃取，当安全事故发生时应有可靠的应对策略或预案。



四、结合典型互联网架构总览参考（如图）



架构总览参考说明：

一、前端架构：

1、APP、WEB(公众号、小程序)开发技术

2、浏览器及HTTP优化技术

3、CDN(内容分发网络)

4、动静分离(缓存静态内容，域名入口分离)

5、图片服务

6、反向代理

7、DNS



二、网关及应用层架构

1、网关架构

2、负载均衡

3、动态页面静态化

3、业务拆分



三、服务层架构

1、微服务框架

2、分布式消息队列

3、分布式缓存

4、分布式一致性(锁)服务



四、存储层架构

1、分布式文件

2、分布式关系数据库

3、NoSQL数据库



五、后台架构

1、大数据平台

2、搜素引擎

3、推荐引擎

4、数据仓库



六、运维与安全

1、数据采集与展示

2、数据监控与报警

3、攻击与防护

4、数据加密与解密



第四周——课后作业及学习总结，END！