在低容错业务场景下落地微服务的实践经验

本文涉及的产品
云原生网关 MSE Higress,422元/月
应用实时监控服务-可观测链路OpenTelemetry版,每月50GB免费额度
函数计算FC,每月15万CU 3个月
简介: “健康体检是一个低容错的场景,用户到医院体检,由于 IT 原因导致无法完成预约的项目,会对用户体验造成极大的影响。”——禾连健康 CTO 邓志豪

作者:禾连健康


“健康体检是一个低容错的场景,用户到医院体检,由于 IT 原因导致无法完成预约的项目,会对用户体验造成极大的影响。”

——禾连健康 CTO 邓志豪


禾连健康成立于 2014 年,是一家从体检场景切入的健康管理服务公司。对于医院,禾连提供的是围绕体检检前、检中、检后的一套 SaaS 服务;对于企业,提供的是团体体检、健康管理,李锦记、普华永道都是禾连的客户;对于家庭,提供的则是健康管理 APP。目前,禾连已经覆盖全国 200 多个城市,2000 多家医院。


禾连健康经历了哪些技术发展阶段?


第一个阶段:宏应用。从 0 到 1,迭代速度很快,同时故障也很多,业务需要禾连快速迭代并验证,怎么快怎么来,当时还用过阿里云聚石塔提供的一个容器管理服务,也算是容器化的雏形。总结来看,关注速度,但是会出现技术债务、故障多、达不到业务的预期。


第二个阶段:微服务化。当禾连对接的医院越来越多后,故障也更多了,客户抱怨很大,那时候开发整天在“救火”。随后,禾连开始做模块化的解耦和服务拆分,引入了 Dubbo 和 Nacos,但当时对业务的理解还是不够深刻,服务拆的有问题,导致服务交叉调用非常多,出现几乎所有接口都会调用到的超级服务,对稳定性有害。总结来看,对业务理解不深刻的微服务拆分,治标不治本。


第三个阶段:微服务重构。以横向的订单、落单、数据同步为主,重新梳理了模块和服务,同时部署架构换成了 K8s,并把用于服务治理的一些中间件替换成阿里云微服务引擎 MSE 这类云服务[1],这个时候,整个系统总体就比较稳定了。总结来看,围绕业务来构建微服务,结合云的优势,提升了开发运维效率和线上稳定性。


低容错的体检业务有哪些不一样的技术挑战?


低容错是禾连的业务特点。例如,用户到医院体检,由于 IT 原因导致无法完成预约的项目,会对用户体验造成极大的影响,不仅是体检,其实整个医疗行业都有着低容错的特点。另外,对于大多数人而言,体检的频率一年也就1-2次,是非常低频的场景,因此流量也非常低。而低流量带来的问题是,灰度发布几乎是无效的,甚至全量发布都可能无法发现 bug,有些 bug 会在代码发布一年以后才会被发现。


因此,禾连首先要解决复杂逻辑的问题,必须做模块化、做解耦。


但如果只做业务解耦,那么实现模块化就足够了。例如,如果使用的是 Java 语言,将 Java 模块分为 JAR 包,用 Maven 管理不同依赖即可。但是,早期很多技术架构是通过单一的包支撑不同业务,业务模块多、业务不隔离。没有做微服务拆分时,可能会出现企业业务代码有问题,导致医院容错较低的业务崩溃,这对业务来说,是难以接受的。


因此,禾连直接实现了服务化,将服务拆分开,有公共的基础服务可以调用,不同业务之间不会互相影响。服务化不仅实现了业务解耦,也实现了服务分层,保障履约的核心服务。例如,针对容错率非常低的业务,可以构建专门针对问题场景的保障服务。同时,可以对服务做独立质检,而如果打包在一起则无法做独立的质检。


1.png


服务拆分主要有两种模式,一种为按照业务拆分,一种为按照能力拆分,不同业务可以互相调用。最终,禾连的架构如上图所示。以按照能力拆分为主,按照业务拆分为辅。比如最前端是 web 服务,蓝色块是业务核心迭代的业务服务,底层按照能力拆分订单、支付、消息三种服务。往下一层与业务较远的,比如医院数据同步服务、人工履约服务,是自建的独立服务。


业务迭代最频繁的服务与相对稳定的服务各自区分独立,两边通过 HTTP 打通,业务集群内使用 Dubbo 做 RPC,Nacos 做注册和配置中心,RocketMQ 做异步消息。


微服务演进过程中的实践经验


微服务上,禾连使用的是 Dubbo + Nacos 这套技术栈。


2.png


Dubbo 是一个 基于 Java Interface 的 RPC 框架,对于 Java 程序员而言,只需加简单的注解即可成为微服务,于是在团队中推行。同时,调用几乎不侵入代码,将 @Autowire 改为 @DubboReference 即可注入服务。Nacos 在 Dubbo 的集成非常完善,只需几行配置即可使用,控制面板简单易用,与 Dubbo 一样均为中文社区,对于程序员的门槛更低。


早期,禾连自行搭建社区版 Nacos 曾遇到较大性能瓶颈,当时的 Dubbo2 服务模型基于接口,一个接口、一个函数就会带来一个服务,流量非常大。阿里云的微服务引擎 MSE 帮助禾连扛住了 Dubbo 的压力,它具有良好的兼容性,后续禾连跟随社区升级至 Dubbo 3,解决了 Dubbo 2 服务模型的问题。另外,从内存视角看,MSE 具有出色的调优能力,使业务性能提升 4 倍,降低了资源成本。


禾连服务大量的医院,每个医院的需求不确定、也不尽相同,会存在大量的特性开关。此类开关的操作非常危险,一般由开发人员进行配置,而 MSE 很好地解决了痛点。MSE 的特性开关可以做动态配置,无需重启应用。同时可以一键与 KMS 阿里云密钥管理服务相结合,对数据进行加密存储,但是用户无感知。


3.png


HTTP 网关主要解决协议转换的问题。禾连的 App 前端业务逻辑重,无需做任何结果封装,只要暴露服务能力即可。因此,基于开源的 Apache ShenYu 做了改造,将 HTTP 协议转为 Dubbo ,同时支持 POST/GET,将鉴权和授权逻辑都放至网关。


DevOps 方面,K8s +镜像发布回滚使用了 ACK[2],持续集成使用了云效 CI ,为禾连带来了极高的发布效率,一周最多时会发布 20-30 次,单次发布时间从原先的 2-3 小时降低至 8 分钟内。另外,禾连基于 Dubbo 做了服务隔离,例如,同一个服务可以部署两个版本,代码和使用方式均一致,实例不同。两个服务均有独立内存,一个服务故障时,不会影响到另外一个相同的服务。但该能力目前依然较弱,控制面能力的增强是未来的发展方向。


微服务未来规划


未来,禾连希望能够实现 Service Mesh 的控制面。


4.png


如上图所示,比如服务请求到达时,如果是 req*,则希望它路由至特殊版本 ServiceA* 。请求经过 MQ 之后发出的消息不能被 Service 消息接收,而是应被 Service* 接收,实现全链路的路由能力。目前阿里云的 ASM 提供的 Istio 托管具备以上能力,也提供了基本的 Dubbo 治理能力[3], 后续也将探索在 ASM 中如何进行融合演进。


实现 Service Mesh 的目的是降低测试环境成本。当前,禾连的大集群里有 7-8 套测试环境供各个业务小组使用,每个小组各用一套,互不干扰,但成本过高。如果能实现全链路的路由,每个开发小组只要做服务的测试环境发布,使用打标流量即可实现发布。


5.png


参考目前业界的实践,全链路的灰度路由,可以通过在网关层面识别流量并打标、每个测试环境都有单独的标签;每一跳服务调用传递流量标签,并在每一跳调用时,根据流量标签和对端机器标签做不同策略的匹配路由。最终,禾连可以做到每个环境,只需要部署当前环境修改后的服务,最大限度地重用基线环境的服务,降低了总体成本。


另外,禾连将实现全量 HTTP 网关。从未来趋势看,前端越来越重,无需后端做 web 层,将后端服务直接暴露给前端即可。因此,禾连考虑将所有 web 层替换成 BFF 网关,期待紧密跟进社区的步伐,联合云原生社区一起向前发展。


参考链接:


[1] https://www.aliyun.com/product/aliware/mse


[2] https://www.aliyun.com/product/kubernetes


[3] https://help.aliyun.com/document_detail/214749.html


点击此处,立即前往微服务引擎官网查看更多~

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
2月前
|
运维 持续交付 云计算
深入解析云计算中的微服务架构:原理、优势与实践
深入解析云计算中的微服务架构:原理、优势与实践
98 1
|
2月前
|
消息中间件 API 持续交付
后端开发中的微服务架构实践####
【10月更文挑战第21天】 本文深入探讨了微服务架构在后端开发中的应用,从基本概念出发,详细阐述了微服务的核心优势、设计原则及关键技术。通过实际案例分析,揭示了微服务如何助力企业应对复杂业务需求,提升系统的可扩展性、灵活性与可靠性。同时,也指出了实施微服务过程中可能面临的挑战,并提供了相应的解决方案和最佳实践。 ####
41 3
|
11天前
|
搜索推荐 NoSQL Java
微服务架构设计与实践:用Spring Cloud实现抖音的推荐系统
本文基于Spring Cloud实现了一个简化的抖音推荐系统,涵盖用户行为管理、视频资源管理、个性化推荐和实时数据处理四大核心功能。通过Eureka进行服务注册与发现,使用Feign实现服务间调用,并借助Redis缓存用户画像,Kafka传递用户行为数据。文章详细介绍了项目搭建、服务创建及配置过程,包括用户服务、视频服务、推荐服务和数据处理服务的开发步骤。最后,通过业务测试验证了系统的功能,并引入Resilience4j实现服务降级,确保系统在部分服务故障时仍能正常运行。此示例旨在帮助读者理解微服务架构的设计思路与实践方法。
59 16
|
2月前
|
弹性计算 持续交付 API
构建高效后端服务:微服务架构的深度解析与实践
在当今快速发展的软件行业中,构建高效、可扩展且易于维护的后端服务是每个技术团队的追求。本文将深入探讨微服务架构的核心概念、设计原则及其在实际项目中的应用,通过具体案例分析,展示如何利用微服务架构解决传统单体应用面临的挑战,提升系统的灵活性和响应速度。我们将从微服务的拆分策略、通信机制、服务发现、配置管理、以及持续集成/持续部署(CI/CD)等方面进行全面剖析,旨在为读者提供一套实用的微服务实施指南。
|
2月前
|
存储 监控 API
深入解析微服务架构及其在现代应用中的实践
深入解析微服务架构及其在现代应用中的实践
86 12
|
1月前
|
运维 监控 Java
后端开发中的微服务架构实践与挑战####
在数字化转型加速的今天,微服务架构凭借其高度的灵活性、可扩展性和可维护性,成为众多企业后端系统构建的首选方案。本文深入探讨了微服务架构的核心概念、实施步骤、关键技术考量以及面临的主要挑战,旨在为开发者提供一份实用的实践指南。通过案例分析,揭示微服务在实际项目中的应用效果,并针对常见问题提出解决策略,帮助读者更好地理解和应对微服务架构带来的复杂性与机遇。 ####
|
1月前
|
算法 NoSQL Java
微服务架构下的接口限流策略与实践#### 一、
本文旨在探讨微服务架构下,面对高并发请求时如何有效实施接口限流策略,以保障系统稳定性和服务质量。不同于传统的摘要概述,本文将从实际应用场景出发,深入剖析几种主流的限流算法(如令牌桶、漏桶及固定窗口计数器等),通过对比分析它们的优缺点,并结合具体案例,展示如何在Spring Cloud Gateway中集成自定义限流方案,实现动态限流规则调整,为读者提供一套可落地的实践指南。 #### 二、
73 3
|
1月前
|
负载均衡 Java 开发者
深入探索Spring Cloud与Spring Boot:构建微服务架构的实践经验
深入探索Spring Cloud与Spring Boot:构建微服务架构的实践经验
169 5
|
1月前
|
消息中间件 运维 安全
后端开发中的微服务架构实践与挑战####
在数字化转型的浪潮中,微服务架构凭借其高度的灵活性和可扩展性,成为众多企业重构后端系统的首选方案。本文将深入探讨微服务的核心概念、设计原则、关键技术选型及在实际项目实施过程中面临的挑战与解决方案,旨在为开发者提供一套实用的微服务架构落地指南。我们将从理论框架出发,逐步深入至技术细节,最终通过案例分析,揭示如何在复杂业务场景下有效应用微服务,提升系统的整体性能与稳定性。 ####
50 1
|
1月前
|
监控 安全 持续交付
构建高效微服务架构:策略与实践####
在数字化转型的浪潮中,微服务架构凭借其高度解耦、灵活扩展和易于维护的特点,成为现代企业应用开发的首选。本文深入探讨了构建高效微服务架构的关键策略与实战经验,从服务拆分的艺术到通信机制的选择,再到容器化部署与持续集成/持续部署(CI/CD)的实践,旨在为开发者提供一套全面的微服务设计与实现指南。通过具体案例分析,揭示如何避免常见陷阱,优化系统性能,确保系统的高可用性与可扩展性,助力企业在复杂多变的市场环境中保持竞争力。 ####
52 2