微服务架构下如何提取通用工具代码以避免重复实现？

针对你提到的不想重复编写错误处理代码、且需要技术栈无关的需求，可参考以下几种方案：

1. 轻量内部共享库 #

不用依赖公共npm registry，而是搭建内部私有包管理仓库（比如企业级npm源、Maven私服、Go Module私有仓库等），把错误处理逻辑拆成仅包含核心功能的轻量库——只保留异常捕获、Kafka日志生成、响应格式封装这三块核心代码，剔除无关冗余内容。两个微服务直接依赖这个私有库，后续更新逻辑时只需同步升级库版本即可。
如果觉得搭建私有仓库成本高，也可以用Git子模块/子树：将错误处理代码单独放在一个独立Git仓库中，两个微服务仓库通过Git子模块引入该仓库，需要更新时拉取最新代码即可，纯代码层面实现复用，无需依赖包管理工具。

2. 全局中间件/代理层拦截 #

把错误处理逻辑抽离到API网关或独立代理层中，作为全局拦截器使用。所有微服务的请求都经过这个代理层，当微服务抛出异常时，代理层统一捕获异常信息，自动完成Kafka日志写入，并按照指定格式生成响应返回给客户端。这种方式下，每个微服务无需单独集成错误处理代码，只需保证抛出的异常能被代理层识别（比如约定异常结构），完全实现技术栈无关，只要代理层支持服务的通信协议（HTTP、gRPC等）。

3. 抽象为公共服务能力 #

将错误处理的核心能力（日志上报、响应格式化）封装成一个独立的公共服务，微服务在需要处理错误时，通过标准协议（REST、gRPC等）调用该公共服务的接口，传入错误详情。公共服务完成Kafka日志写入后，返回格式化好的响应内容，微服务直接将该响应返回给客户端。这种方案彻底解耦错误处理逻辑与业务服务，技术栈无关，后续修改错误处理规则时只需更新公共服务即可，无需改动所有微服务。

针对你担心的“npm registry共享模块小题大做”的问题，其实只需封装轻量的核心逻辑库，通过内部私有仓库共享即可，既避免重复代码，又不会引入不必要的复杂度。

内容的提问来源于stack exchange，提问作者Aryan Shrivastava