本周的课程学习了互联网架构中面临的挑战以及应运而生的架构技术，架构模式。作为总结，这里拿之前遇到的一个面试题来分析总结。

一、曾经的面试题

问题：一个系统中会包含如下的场景，让你来设计架构会选择分布式还是单体？

• 验证逻辑

• 计算逻辑

• 服务依赖，比如 Service A -> Service B -> Service C

• 系统通知服务，当某个事件发生后需要通知各个需求方（订阅方）

解答：

这几个场景在大多数系统中其实都会遇到，如果作为一个新系统的设计我需要拿衡量架构成功的目标来分析。

1. 系统快速迭代，

就需要业务组件之间解耦、拆分。不至于某个业务的改动导致整个系统的部署

如上几种场景并非必然的需要耦合在一起。根据业务划分，可以拆分开来，独立部署。

2. 高性能，

• 场景一业务验证

如果是简单的CPU(If/else)逻辑验证, 尽量在设计层面把容易出错或概率大的提前，减少后续校验。

如果有业务数据依赖，考虑是否需要数据或者规则缓存在本地。缓存的数据量大的话，可能还要考虑分布式缓存。

• 场景二计算逻辑

对于单次请求来说，算法很重要。

对于高并发，单个服务器CPU在单位时间内的服务请求书是有限的。这个时候作为不依赖于上下问的计算实例就可以大量部署，通过负载均衡把请求分发到不同实例来处理，增加处理能力。

• 场景三 服务依赖

a. 服务A，B, C 本身的实现性能是一个要素。

b. 同时，A, B, C是否是完全独立的业务，如果不是最好作为单体的一部分实现。本地调用的性能会比远程调用好的多。

c. 如果必须单独部署，考虑远程调用的方式使用一些网络编程框架来替代原生的http 调用来降低时延。

d. 如果请求/响应涉及大量数据传输，对请求/响应内容编码做压缩处理.

3. 高可用

• 通过服务实例冗余来避免单点故障的影响。

• 通过框架或程序实现心跳检测或监控，当出现某个实例失效时可以快速剔除或者人工介入处理。

4. 可伸缩

程序的设计实现应该是无状态的，这样在服务层面就可以做到多实例部署。在集群环境没有达到极限的情况下可以增加服务实例。

5. 可扩展

这个更多需要去了解业务，做好业务模块的划分。另外场景4服务通知，对于不需要强耦合的模块通过消息中间件实现消息通知。当一个模块有改动时，并不完全依赖于另一个模块去改动部署。

6. 安全

一方面我们的应用一般都是建立在企业防火墙之后的。

对于正常的业务访问，我们还需要有合法性验证机制。这个时候应用网关可以起到认证和校验的辅助作用。同时对所有服务的访问做过滤和统一监控。



二、系统架构总结



三、互联网架构与技术总结