引言
作为一个讨厌使用java的后台程序员，我选择使用golang作为后台开发语言，而golang本身的web支持就十分详尽，不太需要外部框架进行辅助，这也就带来了一个问题，我们需要自己去想办法自己实现java spring框架支持的三层架构。
提前声明，以下内容只是个人在正式来说第一次完整的系统开发中的一些经验，实际可能并不是我以下所提到的方式，所以具体的请以大型项目的分享为准。
三层架构(内容主要来自百度)
持久化层：主要是对非原始数据（数据库或者文本文件等存放数据的形式）的操作层，而不是指原始数据，也就是说，是对数据库的操作，而不是数据，具体为业务逻辑层或表示层提供数据服务。
业务逻辑层：主要是针对具体的问题的操作，也可以理解成对数据层的操作，对数据业务逻辑处理，如果说数据层是积木，那逻辑层就是对这些积木的搭建。
表示层：主要表示WEB方式，与用户打交道，如果逻辑层相当强大和完善，无论表现层如何定义和更改，逻辑层都能完善地提供服务。
我们这边并不考虑前端界面，因此不考虑表示层的内容。
简单来说呢，就是当一个用户的请求发往后台之后，由业务逻辑层进行处理，而业务逻辑层则是调用持久化层提供的服务来完成，持久化层所要做的很简单，也就是最基础的增删改查(这里只考虑数据库的情况)；好的，每个层在一个请求中，他们需要做的事情大概已经比较清楚了，接下来我们就结合go语言来看看具体该怎么做。
golang的三层架构
持久化层
我们还是从持久化层来说，这里以一个存储用户信息的users库作为例子来说明，增删改查四个字说起来很容易，但是具体到代码，其实并没有那么简单。我们考虑另一个问题，事务管理该如何进行，例如，在一个转账的场景下，对于数据库的操作要么同时成功，要么一起失败，那这到底是由持久化层直接完成，还是通过某种方式，让业务逻辑层辅助完成？
针对以上的问题，我给出一点个人的意见，那就是：持久化只需要完成对数据库的操作，并不需要考虑具体的业务场景。那么，我们的答案其实也就很清楚了，持久化层最好的方式，就是只做数据库的操作，而事务管理，交给业务逻辑层去做。
golang可以自定义类型以及自己的方法，所以我使用xorm做法是：对每个数据库，创建一个类型与之对应，并给这个类型一组操作，用来对数据库进行操作，而为了方便事务管理，参数中接收上一层，也就是业务逻辑层传入的session进行数据库操作即可。
业务逻辑层
业务逻辑层在这里可以其实需要做的很简单：
- 接收用户的数据
- 调用持久化层接口，并根据相应的业务逻辑，进行事务管理
用户传来的数据不一定是合法的，因此首先要进行数据的合法性检查，而完成检查之后，则需要调用持久化层的接口，完成业务，这里可能就不仅仅是对于单一数据库的操作的，执行操作的顺序可能也是有严格要求的，因此，这里就需要创建session，用session来管理事务，然后将session传给持久化层，这样便可以保证原子性（atomicity）、一致性（consistency）、隔离性（isolation）和持久性（durability）。当然，这里使用的是orm的技术，如果自己实现的话，可能会更复杂一些，需要更多注意，这里不再深入。
表示层
虽说不涉及表示层，但是为了方便对外提供api接口，我还是在上面加了一层，当然，可能并不是我加的，可能是别人早就给出的实践，我这里借鉴而已，无论如何，上面一层用户解析用户的请求数据，同时调用业务逻辑层的方法，将得到的数据传回给用户，可以看成是整个后台和外部的接口吧，所以我觉得放在表示层并不为过。
我习惯于每一层各司其职，那这一层呢，需要做的就只有两件事：解析用户请求数据 以及 组装响应的数据，甚至连数据合法性都不需要管，什么邮件地址非法啊，电话号码是空号什么的，他都不要管，一股脑给业务逻辑层去，让它去做就够了，拿到下层的数据，也只需要全部进行封装并传回即可。
最后
讲完了上面的，希望大家可以对golang如何使用三层模式有一个基本的概念，当然，由于资料并不多，这也是本人自己在查找资料之后给出的一个自己的方法，肯定会存在不合理之处，还望大家指正。最后，想留一个问题让大家帮忙一起解决：
不考虑专门的权限控制服务器的话，接口的权限怎么限制，是业务层实现方法，表示层调用直接鉴权？还是表示层压根不参与，完全由业务层负责？