嗨，我是程序员Alan，很高兴认识你。在《系统架构设计— 高并发场景微服务实战（三）》一文中，我提出了一个问题“系统架构设计为什么要分层？”在这篇文章中，我将详细阐述我的观点。文笔比较浅，见笑了。什么是分层架构软件架构分层是软件工程中常用的设计方法。它将整个系统拆分成N层，每一层都有独立的职责，多层协作提供完整的功能。让我与您分享一些我最喜欢的分层架构图。分层有什么好处？如果公司要开发一个小程序，而你是唯一的程序员，你就得写前后端。即使程序很简单，如果不熟悉前端或后端开发，是不是很痛苦？因为你必须是一个精通全栈开发的程序员，你必须知道前后端的知识和各种异常情况的处理。而如果前后端分离，有一个前端或者后端跟你合作，你只需要专注于你会的领域，其他的交给其他同事，是不是？是不是很开心？举一个发生在我身上的例子吧。写上一篇《系统架构设计— 高并发场景微服务实战（三）》的时候，真的很想把自己所知道的高并发技术栈和微服务技术栈开发中遇到的问题全都说一遍。我说清楚了，但我的能力还不足以在一个简短的推文中把矛盾和纠葛表达清楚，所以我感到很痛苦。痛苦的程度，你只要看了我上面那一长串没有标点符号的句子，你就会深深地感受到。为什么会这么痛，我写这篇文章的时候大概就明白了，主要有两个原因。第一点是自己的能力不够，对各种组件的把握不够。第二点，我没有把任务分层解耦，什么都想在一起，增加了任务的复杂度。综上所述，我对一切都太贪心了。我不是全才，现在不是，将来也不是。会遇到很多复杂的问题。这时候就需要把问题逐层解耦，分解成小问题来解决。我会遇到很多我个人无法解决但不得不解决的问题。这时，我需要向朋友寻求帮助。我不需要很清楚我的朋友是怎么解决问题的，但是我需要知道向哪些朋友求助并心存感激。如何做一个系统层次化的分层架构还是有很多优点的，那么我们如何进行分层设计，需要考虑哪些关键因素呢？我个人认为最重要的一点是弄清楚每个级别的边界是什么。即使是层次化的Web项目，当业务逻辑复杂时，也会出现边界越来越模糊的问题。让我举一个简单的例子。每个人开发的系统中应该有一个用户服务。最基本的界面是查询用户信息界面。它的请求链接是DTO->Controller->Service。DTO层接收来自前端的请求参数，并序列化。然后传递给Controller层调用Service层接口。此时如果PO提出请求，当查询的用户不存在时，应该自动创建一个用户并返回。这时候逻辑层的边界开始变得模糊，因为表现层也承担了部分业务逻辑（查询用户和创建用户的安排）。这个时候我们能做什么？参考阿里发布的《阿里巴巴 Java 开发手册 v1.4.0（详尽版）》，我们可以将原来的三层架构细化为：在这个分层架构中，增加了一个Manager层，它与Service层的关系是：Manager层提供原子服务接口，以及服务层负责根据业务逻辑安排原子接口。以上面的例子为例，Manager层提供创建用户和获取用户信息的接口，而Service层负责组装这两个接口。这样一来，原本分布在表现层的业务逻辑就统一到了Service层，每一层的边界都非常清晰。另外，在分层架构中还有一个需要考虑的因素就是相邻的层之间必须相互依赖，数据流只能在相邻的两个层之间流动。分层架构的不足虽然分层架构有很多优点，但它也有很多缺点。最重要的缺陷之一是它增加了代码的复杂性。这个很明显，明明我们接到请求后可以直接查询和操作数据库，但是我们在中间插入了多个层级，每个层级可能只是简单的做数据传递，有时候增加一个小的需求也是可能需要修改的整个链接上的代码。如果这时候增加了同事的负担，肯定会引来大量的抱怨。另外，如果我们独立部署每一层，那么层与层之间的交互在性能上就会有所损失。留下一些问题你知道什么是单一职责原则吗？你知道什么是迪米特定律吗？你知道开闭原则吗？站在巨人的肩膀上唐扬——高并发系统设计40题文强——SpringCloud微服务实战从0学架构
