今天我们来聊一下系统架构设计的相关基本概念。

系统架构这个词现在用的非常多，大家可能平时都在用在讲。那么这个词我觉得用的也比较淡，什么事情可能不能扯上一点系统架构。但是回过头去想，这种架构确实也不是一个高大上的东西，你可能每天都在接触，每天都在应用。如果那方面你没有去总结，另一方面，你可能也没有把这个事情提高到系统架构设计这么高度去看问题，这篇就是希望帮助大家去理一下思路，看一下什么叫做系统架构设计。

什么是系统架构设计？或者说做什么样事情称之为系统架构设计。我们这个问题暂时先不回答，我们先来看几个例子，看完几个例子，我们再来探讨这个问题。、

第一个例子，我们看到这是一张UML里面的部署图，我们看到有中间有一个节点Node1，然后里面有一个组件，这个组件名字叫做Web，Web组件里面包含了各种页面、服务、Dao，还有其他杂七杂八的东西，这是我们的系统架构1.0，也就是我们最原始的一个架构风格。

这个架构风格在现实当中确实有些地方（包括我们自己团队），有时候也会用这样的风格去组建我们的系统，这种系统风格在有些时候是很有用，因为它比较简单，这一个Web什么都在这里面了。部署上就是一个普通的一个Web工程。但是随着团队规模的扩大，或者随着业务逻辑复杂，软件功能越来越多，可能很多人就觉得这种单独部署Web包这个方式就不一定太合适。这样需要想一些策略和方法，我们想到这个思路，可能大家也想到了，我们称之为分层。那么分层怎么分？我们还是在一个Web里面，我们还在一个Web里面，只不过把Web里面的组建一层层拨开来，我们有页面组件，有Service属性，有Dao或其他的组件。总而言之，我们把一个Web的一个节点分成了几个组件。这几个组件我们可以称之为是一个分层的组件，相对刚才只是一个组件而言，这个分层方式就比较经典的所谓的三层模式。三层模式能解决什么问题？解决就是刚才我们讲到的，所有东西都是放在一起导致可复用性比较低的一个问题。也就是说我们页面、Service跟D奥之间实际上是有一定关系的，这种关系我们有时候认为是可以复用的。这就是我们的2.0架构，也就是分成基本的分层架构。

基本的分层有了之后，我们可能又会碰到问题，什么问题？随着业务更加复杂，人越来越多，可能光三层模式不一定满足我们的需求了，我们怎么办呢？我们还想再分拆要怎么分？我们也有这个思路，就是把刚才讲到的几个组件的拎出去，拎到另外一个节点里面去，我们叫这个节点为Note2。那么大家可以看到Note1里面的Web肯定会去调用Note2里面的服务，这两个节点上正好体现了一种跨进程调用。跨进程的调用，物理上可能不一定在两个节点，可能是在同一个节点或者说在不同的虚拟机里面，但是它的服务调用方式已经从普通的函数级的调用变成一个分布式的服务调用。这时候我们就看到我们把组件从一个地方分到两个地方，这样的好处就是说我们的服务之间的依赖关系通过分布式的方式能够得到更进一步的扩展，即架构3.0。

但是有时候也会有问题，什么问题呢？我们到时候可能服务越来越多，服务多的理也理不清楚，就算理清了又管不好，比方说不知道这个服务到底在哪里，那怎么办？这时候我们也会想到把服务这个东西再分层，所以我们有了架构4.0。

这时候大家看到在架构4.0中我们又多了一个节点，对不对？Node2里面放的也是服务，Node3里面放的也是服务。但他们两个本质性的区别在于说任Node2的服务是面向Web的，也就是Web只能调用Node2里面的服务，所以这个服务是我们方案中的前端服务。那么前端服务可能有时候是很薄的一层，只是充当一个服务的转发适配和门面的功能，所以很多核心的服务我们放在Core里面，或者说我们称之为基础服务。这样的话我们本身服务管理就比较简单了，对不对？我们可以通过两个角度去看这个服务了，我们把核心的服务放在Node3里面，把需要扩展性的针对外部的服务放在Node2里面，这样的话我们如果业务很复杂，可能有一部分业务可以放在Frontend服务，另一部分业务放到Core服务。这就是我们的系统架构4.0。那么这个时候这个架构实际上已经满足很多场景的需求了。但是有时候可能因为服务太多，或者说服务之间进程之间要有关系，跨进程调用可能会影响到一些性能，对不对？所以性能变成我们系统架构就必须要考虑的一个问题。至于具体如何在架构设计上解决性能问题，请看本系列的下一篇。

如果对文章感兴趣，可以关注我的微信公众号：程序员向架构师转型，或扫描下面的二维码。

我出版了《系统架构设计：程序员向架构师转型之路》、《向技术管理者转型：软件开发人员跨越行业、技术、管理的转型思维与实践》、《微服务设计原理与架构》、《微服务架构实战》等书籍，并翻译有《深入RabbitMQ》和《Spring5响应式编程实战》（待出版），欢迎交流。