【软考高级·系统分析师全链路通关实战】第 37 篇云原生与微服务架构——新技术架构考点本系列定位面向有开发经验、从零备考软考高级「系统分析师」的工程师以《系统分析师教程第 2 版》为主线按「综合知识 → 案例分析 → 论文」三科组织需求工程与 UML 建模深拆60 篇带你从考试小白到三科同过。本篇你将学到云原生四要素容器、微服务、DevOps、持续交付及其相互关系微服务拆分的两种方法按业务能力拆分与 DDD 限界上下文拆分衔接第 32 篇 OOA 的分析类微服务基础设施考点API 网关、服务注册发现、服务网格分布式一致性的最终方案Saga 与事件溯源思想TCC/两阶段提交对比云诊通实战七大业务域 → 服务清单的完整拆分过程大纲指定示范学完本篇你将能回答案例分析中「微服务拆分论证」类题目第 54 篇案例专项的题型之一并为论文新技术主题储备云原生素材。考点热力表知识点综合知识案例分析论文云原生四要素★★★★★微服务拆分方法业务能力/限界上下文★★★★★★★★API 网关与服务注册发现★★★★★★服务网格概念★★★分布式一致性Saga/事件溯源★★★★★★微服务优劣势论证★★★★★★★★一、云原生四要素云原生Cloud Native是让应用天生适配云环境弹性、分布式、可观测的一套技术与方法论体系四要素要素内容解决的问题容器轻量级隔离的运行单元镜像标准化交付环境一致性、秒级启停、密度高微服务细粒度独立部署的服务架构独立演进、按需伸缩、故障隔离DevOps开发运维一体化的文化与工具链缩短「提交→上线」周期持续交付自动化流水线随时可发布高频小步发布降低变更风险四要素的逻辑链微服务是架构形态容器是运行载体持续交付是工程手段DevOps 是组织保障——第 34 篇说「架构是持续演化的骨架」云原生就是让这个骨架能高频安全演化的完整配套。二、微服务拆分从业务域到服务清单2.1 两种拆分方法方法一按业务能力拆分。对照业务域第 03 篇云诊通七大业务域逐域问三个问题这个域的数据是否独立演化这个域的负载特征是否不同这个域的团队是否可以自治三问皆「是」即可成为候选服务。优点是直观缺点是业务域边界粗糙时拆出的服务仍然耦合。方法二DDD 限界上下文拆分领域驱动设计。限界上下文bounded context是一个模型与术语明确、边界清晰的业务适用范围——同一个词在不同上下文里含义不同「订单」在问诊上下文指问诊单在配送上下文指配送单。拆分步骤衔接第 32 篇 OOA从第 32 篇的用例模型与领域模型出发识别领域术语表把「同一术语在不同流程中含义漂移」的地方识别为上下文边界每个限界上下文内统一的领域模型 独立数据 明确的上下文映射关系合作/防腐层等一个限界上下文对应一个微服务的候选「一个服务一个上下文」分析师视角的优势OOA 产出的分析类与领域模型第 32 篇的实体/控制/边界类正是限界上下文识别的输入——需求工程做得扎实拆分就是顺势推导而非拍脑袋。2.2 拆分的判断准则与反模式拆得对不对用三条准则检验①高内聚——一个变更如「随访规则调整」尽量只落在一个服务②数据私有——服务间不直连对方数据库只走接口或事件③团队匹配——一个服务可由一个小团队独立开发部署反向康威定律服务边界要顺着组织沟通边界走。常见反模式分布式单体拆了服务但必须一起发布只是把进程内调用改成了网络调用共享数据库数据不私有改表牵一发动全身过度拆分一个简单查询都要跨五个服务组装。案例题问「微服务改造后反而更慢的原因」答案就在这三条反模式里。2.3 云诊通七大业务域 → 服务清单第 03 篇的七大业务域拆分为如下服务清单本系列后文引用的基准拆分业务域拆分出的服务拆分理由一句话预约挂号booking-service号源与预约、schedule-service排班同步排班依赖 HIS 同步独立演进节奏与预约不同在线问诊consult-service会话、message-service消息通道、video-service视频媒体消息走事件驱动第 35 篇视频媒体负载特征完全不同电子处方与流转prescription-service处方与审方编排强一致核心域独立管控第 34 篇合规留痕驱动药品配送delivery-service配送单与物流对接依赖外部物流故障域要隔离检查检验报告report-service报告获取与推送集成 LIS/PACS读多写少的负载特征复诊随访followup-service随访计划与触达低频批量型负载与实时链路隔离监管上报supervision-service上报任务与补偿重试上报协议随监管政策变化必须独立变更第 31 篇变更案例的教训横切patient-service患者身份与复诊凭证、audit-log-service审计留存共享内核最小化仅身份与审计两块全局一致语义注意最后两行不是所有共享能力都要下沉——第 17 篇分包的「共享内核只放极少数概念」原则在微服务下同样成立只拆 patient 与 audit 两个横切服务避免「公共业务服务」变成新的单体。横切服务支撑域服务核心交易链服务开方-同步强一致处方事件处方事件诊疗事件就诊事件审计事件审计事件审计事件booking-service号源预约consult-service问诊会话prescription-service处方与审方编排message-service消息通道schedule-service排班同步report-service报告delivery-service配送followup-service随访supervision-service监管上报patient-service患者身份audit-log-service审计留存API 网关统一入口-鉴权-限流读图采分点①核心链「预约→问诊→处方」用同步调用强一致下游配送/上报/随访/报告全部事件驱动异步呼应第 35 篇风格论证②audit-log-service 只以事件方式接收虚线不影响主链路性能但保证留痕不丢③patient-service 被核心服务依赖但无反向依赖——依赖单向无环。三、微服务基础设施三件考点3.1 API 网关微服务对外的统一入口请求路由、统一鉴权、限流熔断、协议转换、聚合裁剪。价值客户端不感知内部服务拓扑内部重构不影响外部契约横切关注点认证、限流集中收口。云诊通的多端患者 App/小程序、医生工作台、运营后台统一经网关进入。3.2 服务注册与发现服务实例动态启停弹性伸缩、故障重启调用方不能靠写死地址。机制实例启动时向注册中心注册地址、健康状态调用方查询可用实例列表并做客户端负载均衡实例下线或心跳失败时自动摘除。第 36 篇 UDDI 的「注册-查找-绑定」思想在运行时层面的再现。3.3 服务网格将服务间通信能力服务发现、负载均衡、熔断重试、加密、监控从业务代码中剥离下沉到边车代理sidecar由控制面统一管理——业务进程只管业务逻辑。一句话判定服务网格 网络层下沉的微服务通信基础设施解决多语言多团队下通信治理逻辑重复实现的问题。四、分布式一致性微服务的代价与解法4.1 为什么两阶段提交不常用微服务数据私有每服务独立库跨服务业务如「处方开立→库存锁定→生成配送单」无法依赖单库事务。两阶段提交2PC/XA虽保证强一致但同步阻塞、协调者单点、性能差互联网高并发场景基本不用教材把它列为对比项而非推荐项。4.2 Saga 与事件溯源Saga把长事务拆为一系列本地事务每个本地事务提交后发布事件触发下一步任一步失败则执行先前各步的补偿事务撤销已做动作。特点最终一致、无全局锁、性能好代价是要为每步设计补偿有的业务天然难补偿如「消息已推送」只能道歉不能撤回。事件溯源event sourcing不存「当前状态」而存导致状态变化的事件序列当前状态由事件回放推导。价值天然的全量审计轨迹与云诊通合规留痕驱动因素高度契合——监管检查时可回放任何处方的历史变迁代价查询需要额外投影、事件模式演化管理复杂。delivery-serviceprescription-serviceconsult-servicedelivery-serviceprescription-serviceconsult-serviceSaga 模式逐步本地事务失败补偿最终一致开方请求同步-本地事务1-处方落库事务1提交并发布处方开立事件订阅事件-本地事务2-生成配送单事务2失败执行补偿事务-处方置为配送失败态并通知云诊通论证处方核心链问诊→处方走同步强一致第 35 篇已论证处方→配送→上报走 Saga——失败时配送单可取消、上报任务可重试supervision-service 的补偿重试职责补偿语义完整最终一致可接受。五、微服务的优劣势论证论文骨架素材优势劣势独立部署与伸缩视频服务单独扩容分布式复杂性网络分区、超时重试故障隔离配送服务宕机不影响问诊数据一致性弱需 Saga 补偿技术异构可行视频服务用流媒体栈运维成本陡增监控、链路追踪、注册中心小团队自治、持续交付测试复杂第 48 篇微服务测试四层论文金句「微服务不是免费的午餐它用运维复杂性换取演进速度——判断标准是业务变化频率与团队规模是否已经超出单体的承受力」。云诊通 13 人团队为什么仍拆微服务因为七大业务域变化频率差异极大监管上报随政策变、随访随运营变单体下任何域的变更都要全量回归——这是第 48 篇与论文的论证伏笔。真题风格自测题1. 云原生四要素不包括 。A. 容器 B. 微服务 C. DevOps D. 人工运维2. DDD 中「一个模型与术语明确、边界清晰的业务适用范围」称为 。A. 限界上下文 B. 实体类 C. 用例包 D. 部署单元3. 微服务「数据私有」原则的含义是 。A. 数据必须加密 B. 每个服务拥有独立数据库服务间不直连对方数据库 C. 数据不能备份 D. 所有服务共用一个库4. 「拆分后服务必须一起发布只是把进程内调用改成网络调用」该反模式称为 。A. 分布式单体 B. 管道架构 C. 分层架构 D. 事件溯源5. 微服务架构中承担统一入口、鉴权、限流、路由的组件是 。A. API 网关 B. 消息队列 C. 注册中心 D. 边车代理6. 服务实例启动时向注册中心登记地址并维持心跳其主要目的是 。A. 加密通信 B. 支持动态启停下调用方感知可用实例 C. 压缩数据 D. 生成文档7. 服务网格将服务间通信治理能力发现/熔断/加密下沉到 。A. 数据库层 B. 边车代理与控制面 C. 浏览器 D. 操作系统内核8. 两阶段提交 2PC 在微服务中少用的主要原因是 。A. 无法保证任何一致性 B. 同步阻塞、协调者单点、性能差 C. 不支持数据库 D. 需要专线网络9. Saga 模式保证一致性的方式是 。A. 全局锁强一致 B. 一系列本地事务失败时执行补偿事务最终一致 C. 定时全量对账覆盖 D. 人工介入修复10. 事件溯源的核心存储对象是 。A. 当前状态快照 B. 导致状态变化的事件序列 C. 日志文件副本 D. 配置文件11. 云诊通「问诊→处方」走同步调用而「处方→配送/上报」走 Saga划分依据是 。A. 开发语言不同 B. 前者为强一致核心交易链后者允许最终一致且补偿语义完整 C. 团队人数 D. 数据库品牌12. 关于微服务拆分的团队匹配准则正确的表述是 。A. 服务边界应顺着组织沟通边界走反向康威定律 B. 每个服务配 50 人 C. 服务必须由不同公司开发 D. 团队结构与服务无关参考答案1.D 2.A 3.B 4.A 5.A 6.B 7.B 8.B 9.B 10.B 11.B 12.A第 9/10 题合记Saga本地事务补偿事件溯源存事件不存状态本篇小结知识点核心内容云原生四要素容器载体 微服务形态 持续交付手段 DevOps组织拆分两法按业务能力三问DDD 限界上下文术语漂移处即边界OOA 模型为输入拆分三准则高内聚变更单服务落、数据私有、团队匹配反模式分布式单体/共享库/过度拆分基础设施API 网关统一入口、注册发现动态感知、服务网格通信治理下沉边车一致性2PC 阻塞不常用Saga本地事务补偿最终一致事件溯源存事件序列天然审计云诊通服务清单七业务域拆 11 个服务 patient/audit 两个最小横切服务核心链同步、外围事件驱动微服务论证用运维复杂性换演进速度拆分判据业务变化频率与团队规模超出单体承受力下篇预告第 38 篇系统设计一——概要设计与模块设计从架构到模块概要设计与详细设计的边界、模块设计四原则、内聚耦合七级排序综合必考、人机界面设计三原则以及云诊通结构图与扇入扇出分析示范。如果本篇内容对你有帮助欢迎点赞收藏有任何疑问欢迎在评论区交流。