「技术分享」微服务开发的幸福感，是如何提升的？

Posted 2023-04-05

参考技术A

阅读原文： 【技术分享】微服务开发的幸福感，是如何提升的?

随着微服务的流行，越来越多公司使用了微服务架构，但由于公司业务的特殊性、技术栈的 历史 原因等，都需要选择一个适合自己公司的服务开发框架，对框架进行规范定义，集成自研组件和系统，让业务迭代实现更快速，让开发人员使用更便捷。

本文将基于SpringBoot，从框架约束、自研中间件集成、强类型客户端、接口文档等多个方面介绍服务框架的设计与实践。

一、背景介绍

公司后端服务是以Java生态为主，有基于Dubbo的RPC服务、基于SpringBoot的HTTP服务两种开发模式，所有服务基于K8S的容器云双机房独立部署，支持双活流量的架构。

结合公司上下文环境、业务规模，综合考虑技术栈统一、服务治理、使用成本等多方面的因素，经过多部 商议，确定将“基于SpringBoot开发HTTP服务”作为主要开发模式。公司每天都有一些新的微服务产生，很多自研组件服务和中间件系统，需要服务开发者单独接入，为了规范和简化后端服务开发者集成应用，一套规范、集成的开发框架就变得非常有必要。

二、基于SpringBoot的服务框架设计

1、如何统一规范框架的使用?

统一规范可以通过默认约定、强制校验、自动内嵌等多种方式来实现，下面将分别举例说明。

统一管理依赖包(默认约定)

基于Maven的依赖包管理，通过Partent统一定义依赖包及版本，默认引入必须的依赖包和插件。创建工程自动生成代码时，默认约定继承Parent，开发者只需引入必要的Starter即可，开发者可以修改继承关系，但不推荐。

依赖包的统一管理，可以避免不同版本包冲突的麻烦，也方便后期公司统一升级依赖包和版本。

统一参数格式(强制校验)

返回参数都继承BaseResponse，请求参数都继承BaseRequest。强制校验接口服务来保证参数规范性，在工程启动时自动检测，不遵循规范的工程将无法正常启动，绕过校验的工程不纳入公司后端体系，很多核心能力均无法正常使用。

统一参数格式，不仅可以同时支持HTTP调用、强类型客户端，同时规避了HTTP接口的滥用，简化规范了错误处理。

统一处理异常(自动内嵌)

通过Spring的RestControllerAdvice可以对全局异常统一捕获，并对异常统一处理。异常处理自动内嵌到核心包中，只要使用该框架，就自动生效。

统一异常处理，不仅规范了异常返回格式，兼容了强类型客户端，日志统一记录，并对返回的异常信息进行脱敏处理。

2、如何简化自研中间件组件和系统的集成?

所有中间件依赖包都在Parent中统一管理，对于自研的通用类组件(比如日志组件、线程池组件、web安全组件、自研的工具类组件等)，默认在Parent中已引入，开发者可以直接使用。

公司有很多自研的中间件组件或系统，或者根据公司环境二次开发过的开源组件，只能按照公司的特定的方式进行接入使用，有一定的接入成本。为了接入更方便，都做成了可插拔的组件，通过Starter方式进行接入。

使用Starter方式，简化了依赖、简化了配置、简化了接入代码。

作为后端服务，核心能力是对外提供服务，或者调用其他服务。如果使用REST方式访问远程HTTP接口，难以将接口管理起来，当接口变动的时候可能需要修改多处。

在技术调研过程中，我们发现SpringCloud提供了OpenFeign来解决这个问题。

3、如何实现强类型的HTTP客户端?

但OpenFeign和我们公司技术环境不一致，加上太多 历史 项目也无法支持OpenFeign，于是我们借鉴OpenFeign思想，基于开源Fegin开发了适合公司环境的ZbjFeign，支持在SpringBoot和普通Spring环境中使用。

4、如何实现文档的统一管理?

公司所有文档都是基于Confluence进行管理的，接口文档也不例外，于是我们也实现了在发布阶段，一键发布接口文档。后台实现也是自动扫描Controller接口元数据，通过模版生成html片段，并提交到Confluence。接口文档中提供了Java强类型客户端调用、HTTP调用两种方式的参考。

Client和文档都有了，接下来我们通过案例看一下如何使用。

三、框架使用案例

1、Starter的使用案例

通过Starter方式使用分布式消息队列 RabbitMq，只需要引入Starter，就可以直接使用了。

第一步:引入依赖Starter。

第二步:消费者监听队列消息。无需做任何配置，具体代码如下。

说明:公司的RabbitMQ是经过二次开发的，不是通过“地址+账号”访问，而是通过申请的业务ID进行访问。

2、强类型客户端使用案例

只需要引入Client包，无需做任何配置，就可以像调本地方法一样调HTTP服务。

第一步:引入Client依赖。

第二步:直接通过强类型进行HTTP接口调用，就像本地方法一样。

说明：客户端包生产时内置了远端服务的域名，如果发生变化可以从自研的配置中心修改。

四、未来框架的思考和展望

最后，给大家分享一下关于未来工作，我们的一些思考与规划，还不太成熟，抛出来和大家探讨一下。

1、服务治理本文未涉及到服务治理相关部分(熔断、限流等)，是因为考虑到解耦、灵活性等多方面因素，我们并没打算像Dubbo或者SpringCloud， 通过代码库方式耦合在应用程序生命周期中，而是从应用生命周期脱 离出来，下沉到基础设施或者网络层，进行统一治理。

2、应用可观测性微服务架构中，故障可能出现在任何地方，做可观测系统已经在我们 计划中，通过日志、链路跟踪、度量等手段，让各数据之间产生更多的关联，使每一次 App 点击所产生的多次服务调用耗时、返回值和参数都清晰可 ，甚至可以下钻到第三方软件调用、SQL请求、节点拓扑、网络响应等信息中。运维、开发和业务人员通过这样的观测能力可以实时掌握软件的运行情况，并获得前所未有的关联分析能力，以便不断优化业务的 健康 度和用户体验。

3、框架持续演进如今，技术与业务都发展非常快，后端框架也会在一定范围内不断升级重构，以适应变化的技术和业务需求。本框架设计都是面向服务接口调用，未来可能也会引入消息驱动设计，处理一些异步化的场景， 甚至重构升级为事件驱动的架构。当然，在业务高速迭代的情况下， 也需要考虑架构演进与业务发展之间的平衡。

希望以上内容能对有需要的人有所帮助

欢迎大家一起探讨交流

阿里云 EDAS 3.0 助力唱鸭提升微服务幸福感

简介： EDAS 3.0 提供的微服务治理，很好的支持了唱鸭 APP 实现微服务应用的发布、监控、管理等日常业务场景。作为运维侧的重要平台和开框架的提供者，EDAS 3.0 帮助用户可以更专注业务。微服务架构升级后，业务具备水平扩展能力，具备支撑千万级 DAU 潜力。

作为国内首款弹唱 App，唱鸭在产品创新上的不断探索为音乐行业带来了全新的用户价值，包括弹唱、音效键盘等功能，让它在过去一年中迅速成为了拥有千万级用户量的音乐产品，其中“95后”占比超过 90%。

 

新的需求

随着公司业务的快速发展，公司亟需提升数字化竞争力，延伸价值链条。唱鸭也和众多互联网企业一样依托于以微服务化为基础的互联网架构，并选择用全站上云的方式加快企业发展的步伐，但过程中遇到了以下难题：

 

1. 业务需要实现短时间快速上云，缺乏微服务框架实现经验，导致研发需要投入大量人力去研究微服务底层相关技术，对于业务来说投入产出比很低，并且成本也过高。
2. 客户业务使用容器发布，但是容器技术门槛较高，缺乏相关专业人员及经验，严重阻碍大规模，全站上云。
3. 微服务架构下，应用数量暴增，依赖关系错综复杂，由于缺乏微服务治理工具和经验，使得微服务架构下的应用运维和故障排查变得异常困难。

 

新的解法

 

1. 通过利用阿里云 EDAS 3.0、MSE、ACM 等云产品构建微服务化应用架构，解决用户自建微服务基础框架的问题，实现快速接入，即开即用，极大的降低微服务架构的复杂度，同时减少开发人员工作量。让研发不用再关注底层技术原理和实现，专注于业务的本身。
2. 通过利用 EDAS 3.0 可以非常方便的和容器服务 ACK 集成，极大降低了使用容器技术的门槛。
3. 通过 EDAS 3.0 的服务治理功能实现服务鉴权、服务测试、无损下线、离群实例摘除、金丝雀灰度发布、临近路由等微服务核心功能，一站式解决微服务治理的痛点和难点。

 

上云价值

EDAS 3.0 提供一站式应用全生命周期管理，集成了容器调度，应用监控，资源管理等能力，使得唱鸭研发效率提升15%。同时，EDAS 3.0 提供的微服务治理，很好的支持了唱鸭 APP 实现微服务应用的发布、监控、管理等日常业务场景。作为运维侧的重要平台和开框架的提供者，EDAS 3.0 帮助用户可以更专注业务。微服务架构升级后，业务具备水平扩展能力，具备支撑千万级 DAU 潜力。

原文链接

本文为阿里云原创内容，未经允许不得转载。