假设你负责设计雄安宣武医院的HIS系统架构，该系统需要支持门诊、住院、手术等全流程业务，并具备高可用性和可扩展性。请描述该系统的整体架构设计，包括核心模块划分、高可用方案（如主从复制、集群）、负载均衡策略，并说明选择这些方案的理由。
答案
1) 【一句话结论】
雄安宣武医院HIS系统采用微服务架构，核心模块按业务拆分（门诊、住院、手术），数据库采用分库分表+主从复制+读写分离，应用集群通过Keepalived实现高可用，负载均衡结合Nginx四七层（会话粘性），服务间通信采用gRPC，服务发现用Consul，整体架构兼顾全流程业务支持、高可用性及可扩展性。
2) 【原理/概念讲解】
老师解释核心模块划分：门诊业务拆分为预约服务（医生排班、患者预约）、挂号服务（身份验证、科室选择）、收费服务（费用计算、票据生成）；住院业务拆分为床位管理服务（床位分配、状态调整）、费用结算服务（费用记录、账单生成）；手术业务拆分为排程服务（手术时间安排）、术中管理服务（术中数据记录）。每个微服务独立部署，数据库按业务分库（如门诊库、住院库），按时间/数据量分表（如费用表按月份分表），便于水平扩展。
高可用方案：数据库主从复制（主库写，从库同步，主库故障时通过MySQL binlog位置检查（实时检测主从库日志偏移量）+Keepalived心跳检测快速切换（2-5秒内），从库切换为主库后，需同步后续binlog确保数据一致）；应用服务器集群（Keepalived虚拟IP，多台服务器共享VIP，故障时从服务器接管，保证服务不中断）。
负载均衡策略：前端Nginx四层负载均衡（基于IP/端口分发，速度快，适合静态资源或无状态请求），后端Nginx七层负载均衡（基于HTTP请求头（如cookie）或URL参数，实现会话粘性，避免用户登录后请求被分发到不同服务器导致会话丢失）。
服务间通信：gRPC（基于Protocol Buffers，强类型接口定义，序列化效率高，比RESTful更高效，适合微服务间高频、强类型的调用，如收费服务调用支付服务）；服务发现：Consul（动态注册服务实例，支持健康检查，当服务实例宕机时自动下线，客户端通过Consul获取可用服务列表，实现服务间动态发现，避免硬编码IP）。
类比：患者预约流程中，用户请求通过负载均衡分发到预约服务，服务调用收费服务（gRPC调用），收费服务写入数据库主库（分库分表，如住院库主库），从库同步，返回结果，整个过程通过Consul发现服务，确保服务可用。
3) 【对比与适用场景】
数据库高可用方案对比：
| 方案类型 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 主从复制（读写分离） | 主库负责写，从库同步数据（同步或异步），从库只读 | 同步（实时，延迟低，但写性能下降；异步（延迟高，但写性能高，可能数据丢失） | 门诊挂号、住院费用等读多写少场景 | 主库故障时切换需时间（秒级），异步复制可能数据丢失 |
| 分库分表 | 按业务分库（如按科室分库），按时间/数据量分表（如费用表按月份分表） | 分散数据，避免单库压力，提升写性能 | 住院费用结算（高写）、手术记录（高数据量）等场景 | 需要路由规则，跨库查询复杂，分表后数据一致性维护难度增加 |
| 应用集群（Keepalived） | 多台应用服务器组成集群，共享虚拟IP | 虚拟IP，故障切换（心跳检测），负载均衡 | 应用服务高并发（如门诊预约高峰） | 集群管理复杂，故障切换时间取决于检测机制（需优化） |
负载均衡方案对比：
| 方案 | 定义 | 工作层 | 优点 | 缺点 |
|---|---|---|---|---|
| Nginx（四层） | 基于IP/端口分发流量 | TCP/UDP | 速度快，无状态，适合静态资源 | 不支持会话保持，用户请求可能被分发到不同服务器 |
| Nginx（七层） | 基于HTTP请求内容（如cookie、URL）分发 | HTTP | 支持会话粘性、URL路由 | 配置复杂，处理请求慢于四层 |
| DNS轮询 | 域名解析轮询 | DNS | 无需硬件，简单 | 响应慢，不支持会话，流量分配不均 |
服务间通信协议对比：
| 协议 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| RESTful | 基于HTTP协议，资源化设计 | 无状态，简单，易理解 | 通用场景，如API网关 | 传输效率低，序列化慢 |
| gRPC | 基于HTTP/2，Protocol Buffers序列化 | 强类型，高效，支持流式传输 | 微服务间高频、强类型调用 | 配置复杂，需要定义接口和消息模型 |
服务发现机制对比：
| 机制 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| Consul | 基于K-V存储，支持健康检查 | 动态注册，自动下线，支持多数据中心 | 微服务架构，动态环境 | 需要配置健康检查，确保服务可用性 |
4) 【示例】
门诊预约请求流程（伪代码）：
- 用户请求：
GET /api/prescription?doctorId=101&time=2024-05-20T10:00 - Nginx四层负载均衡分发到门诊预约服务（服务1或服务2）
- 门诊预约服务查询数据库从库（门诊库从库），检查医生空闲状态
- 若空闲，调用收费服务（gRPC调用）：
chargeService.CalculateFee(patientId, doctorId) - 收费服务写入数据库主库（住院库主库，分库分表，费用表按月份分表），从库同步
- 返回预约成功结果（包含预约号、医生信息）
服务发现示例：Consul注册门诊预约服务，健康检查脚本检查服务端口状态（如HTTP 200响应），客户端通过Consul获取服务列表，调用服务。
5) 【面试口播版答案】
面试官您好，我设计的雄安宣武医院HIS系统整体采用微服务架构，将门诊、住院、手术等核心业务拆分为独立微服务，比如门诊服务包含预约、挂号、收费三个子服务，住院服务包含床位管理、费用结算，手术服务包含排程、术中管理，每个服务独立部署，便于按需扩展。高可用方面，数据库采用分库分表+主从复制（按科室分库，按时间分表，主库写，从库读，主库故障时通过binlog位置检查+Keepalived快速切换，从库切换后同步后续日志确保数据一致），应用服务器用Keepalived实现集群，虚拟IP切换，保证服务不中断。负载均衡策略，前端用Nginx四层负载均衡分发流量到后端微服务，后端用Nginx七层负载均衡，通过插入cookie实现会话粘性，避免用户登录后请求被分发到不同服务器导致会话丢失。服务间通信采用gRPC（比RESTful更高效，适合微服务间强类型调用），服务发现用Consul（动态注册，支持健康检查，确保服务可用）。选择这些方案的理由：微服务拆分提升开发效率，分库分表解决高写场景（如住院费用结算）的性能问题，主从复制提升读性能，集群保障高可用，负载均衡实现流量分发，gRPC提升服务间通信效率，Consul保障服务动态发现，整体架构能支持全流程业务，同时具备高可用和可扩展性。
6) 【追问清单】
- 问：微服务拆分的粒度如何确定？比如门诊服务是否应该包含挂号、收费？
回答要点：根据业务复杂度和团队规模，门诊服务拆分为预约、挂号、收费等子服务，每个子服务独立，便于独立开发、测试和部署（如预约服务负责医生排班和患者预约，挂号服务处理患者身份验证和科室选择，收费服务计算费用并生成票据，独立部署可按需扩展，不影响其他业务）。 - 问：主从复制切换的故障检测时间是多少？如何优化？
回答要点：主从复制切换通常需要几秒到几十秒，可通过MySQL的binlog位置检查（实时检测主从库binlog位置差异）缩短检测时间，同时结合Keepalived的监控脚本（如检查主库端口状态），快速检测主服务器故障并切换，优化后切换时间可控制在2-5秒内。 - 问：服务间通信选择gRPC而非RESTful的理由？
回答要点：gRPC基于Protocol Buffers序列化，传输效率高（比RESTful快约3-5倍），支持强类型接口定义，适合微服务间高频、强类型的调用（如收费服务调用支付服务），而RESTful传输效率低，序列化慢，不适合高频调用。 - 问：服务发现Consul的具体作用？如何实现健康检查？
回答要点：Consul用于动态注册服务实例，当服务实例启动时注册到Consul，宕机时自动下线，客户端通过Consul获取可用服务列表，实现服务间动态发现。健康检查通过脚本检查服务端口状态（如HTTP 200响应），确保服务可用。 - 问：分库分表后跨库查询的解决方案？如何保证数据一致性？
回答要点：采用分布式事务（如Seata），通过事务协调器管理分布式事务，实现跨库事务的提交或回滚，保证数据一致性。例如，门诊预约成功后，调用住院费用结算服务，通过Seata的AT模式，确保两个服务的事务原子性，避免数据不一致。
7) 【常见坑/雷区】
- 模块划分过粗：将门诊、住院、手术合并为一个服务，导致扩展困难（如门诊业务增加新功能时，需修改整个服务，影响其他业务）。
- 高可用方案只说主从没提故障切换：只说数据库有主从，但没说明主库故障时如何切换，导致面试官质疑高可用性。
- 负载均衡没考虑会话粘性：只说负载均衡，但用户会话在不同服务器间切换导致登录失效，影响用户体验。
- 数据库只说主从没提读写分离：只说主从复制，但没说明读操作走从库，写操作走主库，导致读压力集中在主库，影响性能。
- 架构缺乏服务治理（熔断、限流）：未考虑服务间调用可能因故障导致级联失败，需要熔断机制防止雪崩效应，限流防止服务过载。
- 服务发现机制不明确：未说明服务如何动态注册和发现，导致服务间调用依赖固定IP，无法适应动态环境。