【系统设计系列】 应用层与微服务

系统设计系列初衷

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，使得服务之间的依赖关系更加松散。这有助于降低系统间的耦合度，使得系统在面对需求变更时更加灵活。

缺点

微服务的缺点：

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

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

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

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

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

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

服务发现

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

主要流程

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

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

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

应用使用微服务

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

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

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