系统设计系列初衷

System Design Primer：英文文档 GitHub - donnemartin/system-design-primer: Learn how to design large-scale systems. Prep for the system design interview. Includes Anki flashcards.

中文版： https://github.com/donnemartin/system-design-primer/blob/master/README-zh-Hans.md

初衷主要还是为了学习系统设计，但是这个中文版看起来就像机器翻译的一样，所以还是手动做一些简单的笔记，并且在难以理解的地方对照英文版，根据自己的理解在AI的帮助下进行翻译和知识扩展。

应用层

资料来源：可缩放系统构架介绍

首先需要了解下服务层和应用层的概念：

服务层

主要负责处理系统的业务逻辑。服务层为应用层提供功能性的支持，包括数据验证、数据处理、业务流程控制等。服务层通过将底层数据处理和逻辑封装起来，为应用层提供了更高层次的抽象，使应用层可以更方便地使用这些服务。

应用层

是软件系统的最高层次，直接为用户提供功能和服务。应用层包括各种应用程序、客户端和服务器等。应用层通过调用服务层提供的功能，实现了对用户需求的响应和满足。应用层需要关注用户交互、用户体验以及各种应用程序的实现。

关系

服务层和应用层的关系主要体现在以下几个方面：

服务层为应用层提供服务：服务层通过封装底层数据处理和逻辑，为应用层提供了更高层次的抽象。应用层通过调用服务层提供的功能，实现了对用户需求的响应和满足。

应用层依赖服务层：应用层需要实现各种功能和服务，而这些功能和服务很大程度上依赖于服务层提供的支持。服务层设计的好坏直接影响应用层的性能、稳定性和可维护性。

服务层和应用层相互隔离：服务层和应用层在功能上相互独立，它们之间的接口清晰明确。这样，当需求发生变化时，可以灵活地进行调整和修改。服务层和应用层相互隔离的设计有助于提高系统的可维护性和可扩展性。

早期的服务层基于应用层存在，共同部署在同一个平台，共同运维。

而微服务的提出将 Web 服务层与应用层（也被称作平台层）分离，可以独立缩放和配置这两层。添加新的 API 只需要添加应用服务器，而不必添加额外的 web 服务器。

单一职责原则提倡小型的，自治的服务共同合作。小团队通过提供小型的服务，可以更激进地计划增长。

应用层中的工作进程也有可以实现异步化。

微服务

微服务，可以被描述为一系列可以独立部署的小型的，模块化服务。每个服务运行在一个独立的线程中，通过明确定义的轻量级机制通讯，共同实现业务目标。

例如，Pinterest 可能有这些微服务：用户资料、关注者、Feed 流、搜索、照片上传等。

优点

微服务的主要优势包括：

灵活性：微服务可以独立进行开发、测试和部署，从而加快软件开发的迭代速度。同时，每个服务都可以根据实际需求选择合适的技术栈，使得开发者能够更加灵活地应对不同的业务场景。

可扩展性：通过将复杂的应用程序拆分成多个简单的微服务，系统可以在需要时更容易地进行水平扩展。这使得系统能够根据业务需求的变化快速调整资源，提高系统的整体性能。

高可用性：由于每个微服务都是独立的，因此一个服务的故障不会直接导致整个系统崩溃。此外，微服务架构通常采用去中心化的设计，进一步提高了系统的容错能力。

松耦合：微服务之间的通信采用轻量级的 HTTP API，使得服务之间的依赖关系更加松散。这有助于降低系统间的耦合度，使得系统在面对需求变更时更加灵活。

缺点

系统设计系列初衷

System Design Primer：英文文档 GitHub - donnemartin/system-design-primer: Learn how to design large-scale systems. Prep for the system design interview. Includes Anki flashcards.

中文版： https://github.com/donnemartin/system-design-primer/blob/master/README-zh-Hans.md

负载均衡器

来源：可扩展的系统设计模式

说到负载均衡器，首先就是要引入负载均衡的概念

什么是负载均衡

负载均衡（Load Balance）是一种网络优化技术，用于在高并发访问和高负载情况下，分摊网络设备和服务器的工作压力，提高系统的处理能力、吞吐量和可用性。通过将请求流量自动分配给多个操作单元（例如 Web 服务器、FTP 服务器、企业关键应用服务器等），共同完成任务，从而避免单一服务器设备过载，降低系统故障的风险。

负载均衡技术可以有效提高网络设备的利用率，降低硬件投资成本，同时确保用户享受到较高的服务质量和响应速度。在实际应用中，负载均衡通常用于以下场景：

高并发访问：当网站、应用或服务面临大量用户同时访问时，负载均衡可以将请求分发至多个服务器，确保每个服务器的负载适中，避免其中某台服务器过载。

高负载处理：对于计算密集型任务或数据处理任务，负载均衡可以将任务分配给多台服务器，提高整体处理速度，缩短任务完成时间。

服务器故障恢复：当某台服务器出现故障时，负载均衡可以自动将其从服务队列中移除，并将请求分发至其他正常运行的服务器，确保服务的连续性和稳定性。

什么是负载均衡器

负载均衡器（Load Balancer）是一种网络优化设备，用于在多个服务器或网络链接之间分配负载，提高系统的可靠性、可用性和性能。负载均衡器可以有效地解决服务器或网络链路过载问题，保证用户请求能够及时得到响应，从而提高用户体验。

负载均衡器可以根据不同的策略对流量进行分配，例如轮询（Round Robin）、最少连接（Least Connections）和源 IP 哈希（Source IP Hash）等。此外，负载均衡器还具有其他功能，如应用交换、会话保持、状态监控、智能网络地址转换（NAT）、通用持续性响应（GSR）、错误处理、TCP 优化等。有些负载均衡器还集成了防火墙、包过滤和攻击防护等功能。

负载均衡器可以部署在服务器与互联网链接之间，也可以作为两块网络适配器实现。在庞大的网络结构中，集群服务器的使用可能带来流量和负载问题，因此负载均衡技术应运而生。负载均衡器在网络管理中发挥着重要作用，通过它能够关注网络中的哪些方面需要进行优化和改进。

负载均衡器将传入的请求分发到应用服务器和数据库等计算资源。无论哪种情况，负载均衡器将从计算资源来的响应返回给恰当的客户端。负载均衡器的效用在于:

防止请求进入不好的服务器
防止资源过载
帮助消除单一的故障点

负载均衡器可以通过硬件（昂贵）或 HAProxy 等软件来实现。增加的好处包括:

SSL 终结
- 不需要再每台服务器上安装 X.509 证书
Session 留存

通常会设置采用工作─备用或双工作模式的多个负载均衡器，以免发生故障。

负载均衡器能基于多种方式来路由流量:

随机
最少负载
Session/cookie
轮询调度或加权轮询调度算法
四层负载均衡
七层负载均衡

四层负载均衡

四层负载均衡根据监看传输层的信息来决定如何分发请求。通常，这会涉及来源，目标 IP 地址和请求头中的端口，但不包括数据包（报文）内容。四层负载均衡执行网络地址转换（NAT）来向上游服务器转发网络数据包。

七层负载均衡器

七层负载均衡器根据监控应用层来决定怎样分发请求。这会涉及请求头的内容，消息和 cookie。七层负载均衡器终结网络流量，读取消息，做出负载均衡判定，然后传送给特定服务器。比如，一个七层负载均衡器能直接将视频流量连接到托管视频的服务器，同时将更敏感的用户账单流量引导到安全性更强的服务器。

以损失灵活性为代价，四层负载均衡比七层负载均衡花费更少时间和计算资源，虽然这对现代商用硬件的性能影响甚微。

水平扩展

负载均衡器还能帮助水平扩展，提高性能和可用性。使用商业硬件的性价比更高，并且比在单台硬件上垂直扩展更贵的硬件具有更高的可用性。相比招聘特定企业系统人才，招聘商业硬件方面的人才更加容易。

水平扩展的缺点

水平扩展引入了复杂度并涉及服务器复制
- 服务器应该是无状态的:它们也不该包含像 session 或资料图片等与用户关联的数据。
- session 可以集中存储在数据库或持久化缓存
缓存和数据库等下游服务器需要随着上游服务器进行扩展，以处理更多的并发连接。

负载均衡器的缺点

如果没有足够的资源配置或配置错误，负载均衡器会变成一个性能瓶颈。
引入负载均衡器以帮助消除单点故障但导致了额外的复杂性。
单个负载均衡器会导致单点故障，但配置多个负载均衡器会进一步增加复杂性。

反向代理（web 服务器）

资料来源：维基百科

什么是反向代理

反向代理是一种可以集中地调用内部服务，并提供统一接口给公共客户的 web 服务器。来自客户端的请求先被反向代理服务器转发到可响应请求的服务器，然后代理再把服务器的响应结果返回给客户端。

反向代理的好处

增加安全性
提高可扩展性和灵活性
本地终结 SSL 会话
- 免除了在每个服务器上安装 X.509
压缩
缓存
静态内容
- HTML/CSS/JS
图片
视频
等等

负载均衡器与反向代理

当你有多个服务器时，部署负载均衡器非常有用。通常，负载均衡器将流量路由给一组功能相同的服务器上。
即使只有一台 web 服务器或者应用服务器时，反向代理也有用，可以参考上一节介绍的好处。
NGINX 和 HAProxy 等解决方案可以同时支持第七层反向代理和负载均衡。

反向代理的缺点

引入反向代理会增加系统的复杂度。
单独一个反向代理服务器仍可能发生单点故障，配置多台反向代理服务器（如故障转移）会进一步增加复杂度。
微服务的缺点：

复杂性：微服务架构通常比单体架构更加复杂。开发者需要掌握多种技术栈，理解不同服务之间的协作方式，并处理服务之间的通信和数据一致性等问题。

部署和运维成本：由于微服务需要运行在多个进程中，因此它们的部署和运维成本可能会更高。此外，分布式系统的监控、日志管理和故障排查也具有一定的挑战性。

通信开销：微服务之间的通信通常基于 HTTP API，这可能会导致一定的网络开销和延迟。在高并发场景下，通信开销可能成为性能瓶颈。

数据一致性：在微服务架构中，不同服务之间的数据一致性需要特别关注。由于服务之间的数据交互是通过 API 进行的，可能会存在数据同步和事务处理的问题。

安全性：微服务架构中的多个服务可能使得系统更容易受到攻击。开发者需要充分考虑服务的安全防护，以及在分布式环境中应对安全问题的方法。

适用于小型项目：微服务架构在某些小型项目中可能过于复杂，浪费资源和时间。因此，开发者需要根据项目的实际需求和规模来选择合适的架构。

服务发现

像 Consul，Etcd 和 Zookeeper 这样的系统可以通过追踪注册名、地址、端口等信息来帮助服务互相发现对方。Health checks 可以帮助确认服务的完整性和是否经常使用一个 HTTP 路径。Consul 和 Etcd 都有一个内建的 key-value 存储用来存储配置信息和其他的共享信息。

主要流程

服务发现的主要流程如下：

服务注册：当一个微服务启动时，它会将自己的地址、协议和相关的元数据注册到服务注册中心。服务注册中心负责维护一份可用的服务清单，以便其他服务可以查找到它。
服务发现：当一个微服务需要调用另一个微服务时，它会从服务注册中心获取可用的服务清单。根据清单中的信息，调用方服务可以找到被调用方的服务地址和端口，从而进行远程调用。
服务健康检查：服务发现过程中，还需要对服务进行健康检查，以确保调用的服务是正常运行的。服务注册中心可以定期接收服务提供的健康信息，从而实现对服务状态的监控。
服务注销：当一个微服务停止运行时，它会将自己的信息从服务注册中心注销。这样，其他服务在调用该服务时，会发现该服务已不存在，从而避免调用失败的情况。

服务发现在微服务架构中起到了关键作用，它解决了服务之间的定位和通信问题。通过服务发现，微服务可以更加灵活、高效地进行通信和协作，从而提高整个系统的性能和可扩展性。

应用使用微服务

应用层调用具体微服务时，需要经历以下几个步骤：

服务注册：当一个微服务启动时，它会将自己的地址、协议和相关的元数据注册到服务注册中心。服务注册中心负责维护一份可用的服务清单，以便其他服务可以查找到它。
服务发现：当应用需要调用一个微服务时，它会从服务注册中心获取可用的服务清单。根据清单中的信息，应用可以找到需要调用的服务的地址和端口，从而进行远程调用。
服务调用：应用通过 HTTP 或其他协议向微服务发送请求，并将请求的数据传递给微服务。微服务接收到请求后，处理数据并生成响应，然后将响应返回给应用。
响应处理：应用接收到微服务返回的响应，并对响应数据进行处理。如果响应中包含错误信息，应用可以根据错误信息进行相应的处理，例如进行重试或者报错。
异常处理：在服务调用过程中，如果出现网络异常、超时或者其他异常情况，应用需要进行相应的异常处理，以确保系统的稳定性和可靠性。
负载均衡与熔断：为了提高系统的可用性和性能，可以采用负载均衡技术对微服务进行分发。此外，当微服务出现故障时，可以采用熔断机制将其从服务注册中心移除，以避免其他应用调用失败的情况。

通过以上流程，应用可以实现对微服务的调用，从而充分利用微服务架构的优势，提高系统的灵活性、可扩展性和高可用性。同时，在调用过程中，还需要关注服务安全、数据一致性等问题，以确保微服务架构的稳定和可靠。