第一招：分层

其实分层不是架构图的特点，而是架构的特点。架构的核心奥义就是分层，分层的目的是为了解耦。

比如最早的MVC模式，即Model-View-Controller(模型-视图-控制器) 模式既是如此。

但是分层不宜过多，一般最多 7层，倒不是有啥明文规定，而是层数太多了，你就没办法看了，可读性太差。

比如下面这个，分5层：接入层、展现层、应用层、支撑层、基础层。

这几层各司其职，就像公司的各个部门一样。其中具体的内容我们不需要仔细研究哈，简单了解分层逻辑就行了。

需要注意的是，系统架构中需要注明跟内外部系统的交互，比如上图中右侧的部分就是了。

第二招：切分

分层是横向分割，切分是纵向切割。我感觉“切分”这个词不太好，感觉“劈开”更形象。

比如下图，核心业务层，就是劈开了。每一个业务模块都有自己的功能、数据库，都是单独的MCV模式。

把一个单体架构，按照切分的逻辑给纵向切出来，其实就是大名鼎鼎的“SOA”了。有些人说SOA已经过时了，其实不完全是哈。

无论什么结论，都不能脱离前提。如同“抛开剂量谈毒性都是耍流氓”一样，“脱离业务场景谈架构也是耍流氓”。

能解决问题就好了，你一个30人的公司，搞什么业务中台、数据中台？一个3岁的娃娃谈什么青龙偃月刀？那是活腻歪了，找死呢。

第三招：抽象

抽象很容易理解哈，简单来说就是提取公因式，复杂一点来说就是升维。比如张三和李四抽象一下就是男人；张三和王大妈可以抽象成中国人；张三和Lisa可以抽象成人。

上图中，就是“抽象”的典型代表。业务中台其实就是把各个系统中都需要用的东西抽象一层出来就好了。

这个是阿里的业务中台架构，这张图中所有的功能都不是单独定制的，全部是其他各个系统公用的部分。

所以中台的架构图其实挺好画的，你有多少个系统，其中有多少“公因式”，把他们抽象出来就行了。

-END-