转载

良好的分层和规范比微服务更好

微服务真的好吗？

一个完善的微服务对基础建设要求十分高，持续集成、自动化部署、全程监控、容器管理、运维自动化。

而拥有了这些才刚刚开始，多个项目的依赖关系需要链路跟踪整理。项目十分复杂后每次上线的时候很难快速上线。

多次系统之间引用调用性能极差

这不理智，也不现实

下面简单介绍下分层，我去年也讲过，批判过微服务，只是当时会场有些仓促，没有很深入的去分享。

一个好的代码分层，每层职责是单一的，隔离的，每一层都会把下面一层的所有细节屏蔽掉，类似tcp/ip协议栈。

只有这样越高层级别的分层才能够更专注，好的分层一个api所有依赖整理出来后是一个树形依赖关系，一个坏的分层整理出来的是一个多根的B+tree（笑）。

只有简洁的树形结构，才十分容易的做横向纵向拆分

代码内做分层很容易，而使用微服务做分层代价就会变得很大，因为层级越低性能要求越高，调用越频繁，RPC并不代表性能好反倒会导致性能下降

下面分享一些分层思路：

相信大家都知道，最常见的分层思想就是MVC了，而复杂的项目建议将项目从三层拆分出更多层级，由于后续PHP很少写View层了，这里分层思路特指API服务。

注意：不同层职责单一同层不能相互调用，只能上层调用下层。若必须同层互调业务相关逻辑压到下一层，再在上层封装调用。

此方式设计后的业务各层能够够更好的隔离业务代码变更，保证每层输入输出格式来降低代码改版导致的风险，方便测试改版横向、纵向拆分。

分层样例：

Controller外部请求的参数校验及内部业务服务逻辑拼装
- Service内部标准服务API，是业务提供的标准最大粒度的业务服务，如下订单服务（扣库存，计算优惠，创建订单，设置价格，返回订单号）
- Module整合统一管理多数据源数据，实现数据对象化，并对多Model组合数据提供cache，联动更改
- Model封装数据源含第三方API，隔离数据层变化差异

为了方便理解分层，举例如下：