经常有朋友问我，为什么要做分层架构，架构应该在什么时候进行抽象，今天就来聊聊这个问题。上图展示了一个典型的互联网分层架构：客户端层：典型的调用者是浏览器或APP；站点应用层：实现核心业务逻辑，从下游获取数据，向上游返回html或json；数据缓存层：加速访问存储；data-数据库层：固化数据存储；如果实现面向服务，这个分层架构图可能是这样的：中间多了一个服务层。同层内部，比如端APP，web-server，也有MVC分层：view层：display；控制层：逻辑；模型层：数据；可以看出，每个工程师都在不知不觉中实现了分层架构。那么，互联网分层架构的本质是什么？我们仔细想想就会发现，无论是跨进程的分层架构，还是进程内分层的MVC，都是“数据移动”，然后“处理”。而“被呈现”的过程，归根结底一句话：互联网分层架构是一个数据移动、处理和呈现的过程，其中数据移动是整个过程的核心。如上图所示，数据处理和呈现需要CPU计算，而CPU是固定的：db/service/web-server都部署在一个固定的集群上；最后，无论是浏览器还是APP，也有固定的CPU处理；数据移动：跨进程移动：数据从数据库和缓存传输到服务层，到web-server层，到客户端层；同进程移动：数据从模型层传输到控制层，再到视图层；数据需要移动，所以有两点很重要：数据传输的格式；每个级别的数据形状；首先看数据传输的格式，即协议很重要：service和db/cache之间，二进制协议/文本协议是数据传输的载体；web-server和service之间，RPC二进制协议是数据传输的载体；client和web-server之间，http协议是数据传输的载体；看每一层数据的形式，user以数据为例：在db层，数据是以“行”为单位的row(uid,name,age)；在缓存层，数据的形式是kv(uid->User)；在服务层，将row或kv转换为程序友好的User对象；web-server层会将程序友好的User对象转换为http友好的json对象；客户端层：最终终端得到一个json对象；结语：互联网分层架构的本质是数据的移动。为什么这么说？这将引出“分层架构演进”的核心原则和方法：让上游更高效地获取和处理数据并进行复用；让下游能够屏蔽数据获取和封装的细节；有了上面的铺垫，水友们经常会问这样的问题：是否有必要引入DAO层，什么时候引入；是否需要面向服务，什么时候需要；是否需要抽取一般中台业务，何时抽取；;很容易回答，下期再和大家讨论。画外音：网友的这些问题其实很难回答。在不了解业务发展阶段、业务规模、数据量和并发量的情况下，就妄下YES或NO的结论是不负责任的。总结互联网分层架构的本质，就是数据的移动；在互联网的分层架构中，每一层的数据传输格式（协议）和数据形态非常重要；互联网分层架构演进的核心原则和方法：封装和复用；【本文为专栏作者《58神剑》原创稿件，转载请联系原作者】点此阅读更多该作者好文
