learn - 项目架构演变-01（五层架构篇）

写作目的

我写此篇的目的，适合于初期创业者或者已经有起步的项目对整个项目上的架构规划与演变。

我现在是一个golang使用者，所以我继续用golang的视角去处理。

项目基建架构

五层架构

表示层：我们用gin或者go-zero等框架中，相关路由层，负责对外协议交互的输入和输出。

业务控制层：假设我们已经有想要的数据结构对象后，进行的拼装，这里可以认为每个接口实现自己的功能。

数据服务层：这一层是为了各个业务控制层统一返回需要的数据传输体，单一职责和里氏替换的好处是，业务控制层可以根据业务需要把多个数据服务层拼装成想要的功能给表示层。

数据访问层；仍然沿用单一职责和迪米特法则。数据服务层用到持久化层的数据时，统一经过数据访问层处理。数据访问层可以做多级缓存，但对数据服务层来说是无感知的。越简单越好（写数据/读数据/列表/字典对象等都是单独一个接口方法对外开放出去），不允许业务控制层直接使用数据访问层。

持久化层：对项目来说，底层数据存储位置或服务的架构演变，不应当导致整个项目的重构。例如原来的mysql改成了api，或原来使用mysql改为了redis。

单体服务和微服务

为啥会有单体服务？

我的回答：项目初期创建，包括业务方向，会频繁变动更新，有时候一天一个版本，两天一换方案。所以单体服务可以快速应对局面，并且好控制，可以在一台物理机部署，也可以分布式方式。方便运维管理。

那为啥还有好多要进行微服务方向？

我的回答：项目趋近于稳定（已经有忠实用户，我们既然发展，也要保持好的口碑），根据木桶原理，这个时候要保持多个业务板块或功能不会因为某一个板块的瓶颈而导致其他功能不可用，所以要进行按领域对数据业务划分，然后把单体服务拆成多个为微小的服务。对于有瓶颈峰值的服务，可以临时的增加机器或升级宽带或升级底层数据服务，来暂时解决问题，从而为新的架构方向预留时间。

技术角度的投入与产出

1. 初期阶段：以最小的成本，换取最大的收益。
2. 演变阶段：用稳定的方式，换取持续的收益。
3. 成熟阶段：技术方案规模继续扩大，换取更多的收益。