我们知道，微服务架构由多个相对简单的服务组成，依赖服务之间的隔离性降低系统复杂度。理论上拆解完备的微服务，不应当存在过多业务代码复用的机会，因为服务之间的有效的隔离会使得各自代码只关注自身的上下文，微服务的边界清晰不但包含职责清晰，从代码层面也应当清晰隔离。

但微服务群组产出的两类代码，我们仍然建议被公用：

第一类是交互协议代码，微服务之间交互协议标准的代码，由于每个独立微服务单一职责都有自身边界，微服务之间交互就被暴露为新的特征。交互协议标准代码公用，也可以看做以微服务容易理解的方式公布出来，有利于维护微服务之间交互的便利性和精确性。

第二类是纯工具类代码，这部分代码独立于微服务群的业务特征，往往是提供更低层次的函数库或组件，如版本比较、时间对比工具、上传资源组件等。这一类代码应当视为第三方独立仓库，类似我们引用的 Github 上的开源库。

第二类代码相对简单，作为独立于微服务业务群组的仓库存在即可。对于第一类，微服务之间同步的信息传递，往往是通过 HTTP、PRC 等通信协议，并依据交互双方定义的业务协议将传递的 JSON 或 Protobuf 等解析为业务可理解的信息。这部分交互相关的代码可以被视为公用代码。本文来探讨这部分代码在整个微服务体系中如何更好的被组织和使用，以提升研发效率并减少相关故障。

此部分代码组织的问题，本质上并非为系统或模块的依赖问题，而是在微服务架构体系中，如何更方便的同步和使用公用代码的问题。我司在走上了微服务修行的不归之路后，此部分交互代码组织也经历了不同的阶段，本文会借此案例进行探讨。Go 是我司的指定语言，本文的一些示例和特性是用 Golang 来展示，Git 是最流行的分布式版本控制系统，讨论也基于 Git。