介绍

在阅读这个项目之前，我们需要先了解下项目的设计背景和要解决的业务问题。

设计背景

在此项目诞生之前，HeidiHealth(以下简称Hedi)已经存在并在用的一个单体应用项目来支撑大语言文本生成模型的调用和使用。在其内部融合了整个Heidi的全部业务，比如：文本生成、录音转文字、病人Session管理、EHR资料库、客户关系/团队关系管理、文档/Note/Script处理等等。其囊括了整个Heidi的所有业务逻辑和数据流转。

然而，随着Heidi的业务不断发展壮大，单体应用的架构逐渐显得力不从心。我们发现，单体应用在以下几个方面存在明显的不足之处：

可扩展性差：随着业务的不断发展，单体应用的代码量和复杂度不断增加，导致维护和扩展变得困难。
性能瓶颈：Heidi的其他服务的调用频率和数据量不断增加，单体应用的性能逐渐成为瓶颈，影响了整体系统的响应速度和稳定性。
业务隔离：单体应用将所有业务逻辑和数据流转都集中在一个地方，导致不同业务之间的耦合度过高，难以进行独立的开发和测试。

解决方案

为了解决以上问题，我们决定将Heidi的单体应用拆分成多个微服务。每个微服务负责一个特定的业务逻辑和数据流转，彼此之间通过API进行通信。在第一期，我们希望针对我们的核心业务进行拆分，比如LLM的调用.涉及的主要业务场景是：

文本生成：根据用户输入的文本生成相关的文本内容，比如ASK-AI、文档生成、概要、Note生成等等.
异步任务：将文本生成的请求进行异步处理，避免阻塞主线程，提高系统的响应速度和稳定性。比如：大文本的生成或者录音转文字这种需要消耗大量LLM 资源的场景业务。将其隔离在单独的业务服务中，通过事件驱动和消息队列的方式进行处理可能会更加高效。

新的要求

在拆分LLM为单独的微服务的过程中，我们还需要考虑以下几个方面的要求：

多服务备份机制：通过集成多个LLM服务的API，提供多种备份机制，确保在一个服务不可用时，系统能够自动切换到其他可用的服务。
多种模型支持：支持多种大语言模型的调用，比如OpenAI、Anthropic、Google等，确保系统能够灵活应对不同的业务需求。
高可用和路由切换：通过一定的业务规则和路由策略，确保系统能够在不同的服务之间进行高效的切换和负载均衡，提高系统的可用性和稳定性。
高性能和低延迟：通过异步任务和消息队列的方式，提高系统的性能和响应速度，确保在高并发的情况下，系统仍然能够保持良好的性能表现。
可重试机制：在调用LLM服务时，可能会遇到网络异常、服务不可用等情况，因此需要设计一个可重试机制，确保系统能够在一定的时间内自动重试请求，提高系统的可靠性和稳定性。
高可扩展性：让扩展开发变得更加的简单，甚至可以做到平滑的切换到新的部署平台上，比如从AWS平台如何快速的切换到Azure上。
高可维护性：我们希望代码的可读性和可维护性能够得到提升，避免出现过于复杂的代码逻辑和数据流转，确保系统能够在长期的维护中保持良好的性能和稳定性。

接着让我们来看看如何设计和实现这个微服务的架构吧。