将遗留系统分解为微服务：第 2 部分

在当今不断发展的技术环境中，从整体架构向微服务的转变对于许多企业来说都是一项战略举措。这在报销计算系统领域尤其重要。正如我在上一篇文章第 1 部分应用 Strangler 模式将遗留系统分解为微服务-CSDN博客中提到的，让我们探讨如何有效管理这种转变。

整体挑战

想象一个场景，您有一个大规模的整体系统 - 可能是一个庞大的 C# 控制台应用程序或一个广泛的 SQL Server 存储过程。该系统的任务是执行报销计算，通常通过 SQL Server 中安排的批处理过程过夜运行。虽然功能强大，但这种单一方法通常会带来可扩展性、灵活性和维护方面的挑战。

转向微服务

迁移到微服务的目标是将这个大型、复杂的系统分解为更小、更易于管理的组件。向微服务架构的过渡旨在利用云的优势，包括可扩展性、资源优化和成本效益。

迁移步骤

1. 理解系统

首先从现有的整体应用程序定义数据模型，以了解其工作流程、依赖关系以及报销计算过程的关键组件。该系统的源数据通过837 文件 ，这是医疗保健索赔信息的标准化电子格式。提取该文件并通常通过另一个加载过程将数据加载到数据库中以用于报销计算。例如，837 文件中的一些数据模型可能如下所示：

public class Patient
{public string Name { get; set; }public DateTime DateOfBirth { get; set; }public string Address { get; set; }public string Gender { get; set; }public string PatientId { get; set; }
}public class Provider
{public string Name { get; set; }public string Address { get; set; }public string NPI { get; set; }public string TaxID { get; set; }public string RenderingProvider { get; set; }
}public class Claim
{public string ControlNumber { get; set; }public DateTime ServiceFromDate { get; set; }public DateTime ServiceToDate { get; set; }public string TypeOfBill { get; set; }public string AdmissionType { get; set; }public string DischargeStatus { get; set; }public List<string> DiagnosisCodes { get; set; }public List<string> ProcedureCodes { get; set; }
}public class Insurance
{public string PayerName { get; set; }public string PayerAddress { get; set; }public string PayerId { get; set; }public string SubscriberInformation { get; set; }public string SubscriberId { get; set; }public string CoordinationOfBenefitsData { get; set; }
}public class ServiceLine
{public string RevenueCode { get; set; }public DateTime ServiceDate { get; set; }public int ServiceUnits { get; set; }public decimal ServiceCharges { get; set; }public List<string> ServiceModifiers { get; set; }
}

2. 识别微服务

将整体流程分解为更小的、逻辑上独立的服务。每个微服务应代表报销计算的特定方面，例如输入验证、计算逻辑和输出生成。在许多情况下，医疗报销系统可能涉及多个微服务协同工作以提供端到端功能。以下是一些可能成为综合医疗报销系统一部分的微服务：

出于演示目的，我将提供报销计算服务的简化实现。假设患者信息、程序详细信息和费用表数据是从各自的微服务中检索的，并作为输入传递到此服务，Reimbursement.web 层 ：

using Microsoft.AspNetCore.Mvc;
using Reimbursement.Service;namespace Reimbursement.Controllers
{[Route("api/[controller]")][ApiController]public class ReimbursementController : ControllerBase{private IReimbursementService _reimbursementService;public ReimbursementController(IReimbursementService reimbursementService){_reimbursementService = reimbursementService;}[HttpPost("calculate")]public ActionResult<decimal> CalculateExpectedReimbursement(Patient patient, Procedure procedure, FeeSchedule feeSchedule){try{decimal expectedReimbursement = _reimbursementService.CalculateExpectedReimbursement(patient, procedure, feeSchedule);return Ok(expectedReimbursement);}catch (Exception ex){return StatusCode(500, $"Internal server error: {ex.Message}");}}}
}

报销服务层：

using System;namespace Reimbursement.Service
{public class ReimbursementService : IReimbursementService{public decimal CalculateExpectedReimbursement(Patient patient, Procedure procedure, FeeSchedule feeSchedule){// Check if the patient and procedure existif (patient == null || procedure == null){throw new ArgumentNullException("Patient and Procedure must be provided.");}// Check if the feeSchedule existsif (feeSchedule == null){throw new ArgumentNullException("FeeSchedule must be provided.");}// Calculate the expected reimbursementdecimal expectedReimbursement = feeSchedule.Fee; // Basic reimbursement logic// You can add more complex reimbursement calculations here based on patient data and rulesreturn expectedReimbursement;}}
}

医疗报销系统中微服务的确切组成和架构可能会根据应用程序的特定需求和规模而有所不同。上面列出的服务是可以成为此类系统一部分的组件示例，它们可以通过 API 或消息队列相互交互以执行端到端报销流程。

3. 云端批处理

使夜间批处理适应云环境。这可能涉及利用云原生服务来执行计划任务，确保流程可靠且可扩展。CalculationService 也可以通过用户界面手动触发，以防用户仅需要为特定帐户重新运行，以便可以在批处理以外的地方重用该服务。

结论

将复杂的单一报销计算系统迁移到微服务并将其部署在云中是一个变革性的步骤。这种方法不仅使系统现代化，而且在可扩展性、资源利用率和成本节约方面带来了显着的好处，使系统与现代云功能保持一致，并且业务目标。

---

作者：Greg Hall

更多技术干货请关注公号【云原生数据库】

squids.cn，云数据库RDS，迁移工具DBMotion，云备份DBTwin等数据库生态工具。

irds.cn，多数据库管理平台（私有云）。