保姆级教程！Golang微服务简洁架构实战

导语 | 本文从简洁架构的理论出发，依托trpc-go目录规范，简单阐述了整体代码架构如何划分，具体trpc-go服务代码实现细节，和落地步骤，并讨论了和DDD的区别。文章源于我们组内发起的go微服务最佳实践的第一部分，希望从开发和阅读学习中总结出一套go微服务开发的方法论，互相分享一下在寻求最佳的实践过程中的思考和取舍的过程。本次主要讨论目录如何组织，目录的组织其实就是架构的设计，一套通用架构的设计，可以让开发专注于逻辑设计和具体场景的代码设计，好的架构设计可以预防代码的腐败，并且相关的规范操作简单，可以按步骤根据情况分步落地，可操作性强。

引言

现在有了高效的go语言和成熟的trpc-go框架和一系列的中台SDK，发布平台，一个新手也可以通过教程快速写出简单功能的微服务，以此入门，开始go的微服务开发，并应对大部分开发需求。

但是一旦开始了就会发现随着需求的增加我们常常不得不去花很多时间去维护代码，变更已有的逻辑，不断的抽象，提高部分常用能力的可扩展性，但往往随着多个人在同一份微服务代码里协作，维护这件事情越来越难做了，不仅仅是因为大家的抽象风格不同，对于抽象的标准，模块的分割，数据的流向，分层的逻辑都是不同的，看每个服务都像是一个新的生命，千姿百态。

千姿百态的代码库不是我们希望的，我们希望在代码的架构上保持易读性、可扩展性、可维护性，这样除了对于代码细节的一致性（代码标准）外，还希望有架构上的标准，让开发专注于逻辑设计和具体场景的代码设计，在海量之道的知识下把服务相关内容做好，而不是将时间和精力浪费在纠结如何重新组织和解乱麻、重构等工作上，如果每个服务的架构都足够简洁清晰，团队内部每个仓库都像是自己写的，上手也会很快，团队的效率就会几何的速度提升。

一、 开发现状

不同的业务场景不太一样，在增值的业务场景下，大部分的需求边界或者服务全部职能一开始并不能确定，一般就是一个小需求开始的微服务，后续可能随着业务的增长慢慢变得复杂的，仿佛是从一颗小树苗渐渐长成一颗枝繁叶茂的大树，可能一开始这个服务的职责很单一，很简单，一个service搭配一个logic就ok了，但后面加入了各种依赖，logic就开始变复杂，更可怕的是，因为来一个需求做一个需求（假设最坏的情况下无法预测产品的需求），对于落后的开发模式，或者没有架构概念来说，多一个需求，无非就是加个函数，加个分支，需要啥，import啥就完事了，渐渐地，绝大多数服务成为：

• 没有合理分包，或者仅逻辑职责分包（分目录）

• 面向过程编程，函数调用链很长，在各种包之间穿插。

• 没有依赖注入，依赖是以全局引入的方式存在，作用域很大，潜在的并发问题。

最终导致：

• 不通用，一切都不通用，每次修改一个逻辑部分可能要牵扯到多个函数调用的地方去修改参数关系。

• 测试用例难写，import进来的函数，是mock呢还是不mock呢，mock函数一个个写，monkey mock是否合理？

• 每个模块不独立，看似按逻辑分了模块，比如order_hanlder，conf，XXX_helper，database等，但没有明确的上下层关系，每个模块里可能都存在配置读取，外部服务调用，协议转换等。

先看目前的微服务代码状态，截几个常见的微服务目录组织风格：

四种目前常见的微服务目录组织方式，从左至右分别为1，2，3，4，可以看到：