常见的三种系统架构

了解多种不同的架构可以使我们的知识面更宽广，面对一类问题的时候可以提出其它解决办法。同时，了解多种架构可以让我们在设计阶段做好规划，避免后续频繁的重构。常见的三种架构分别是：

• 单体架构；
• 分布式架构；
• 微服务架构；

单体架构

单体架构是我们平时接触较多的架构，也是相对容易理解的架构。单体架构把所有功能都聚合在一个应用里，我们可以简单地将这种架构视作：

这种架构简单、容易部署和测试，大部分应用的初期都采用单体架构。

单体架构也有几个明显缺点：

• 复杂性高，所有功能糅合在一个应用里，模块多、容易出现边界模糊，而且随着时间的推移和业务的发展，项目越来越大、代码越来越多，整体服务效率逐渐下降；
• 发布/部署频率低，牵一发而动全身，新功能或问题修复的发布上线需要多方协调，发布时间一拖再拖。项目大则构建时间长、构建失败的几率也会有所增加；
• 性能瓶颈明显，一头牛再厉害也抵不过多头牛合力的效果，随着数据量、请求并发的增加，读性能的不足最先暴露出来，接着你就会发现其它方面也跟不上了；
• 影响技术创新：单体架构通常选用一类语言或一类框架统一开发，想要引入新技术或者接入现代化的服务是很困难的；
• 可靠性低，一旦服务出现问题，影响是巨大的。

分布式架构

分布式架构相对于单体架构而言，通过拆分解决了单体架构面临的大部分问题，例如性能瓶颈。假如单体架构是一头牛，那么分布式架构就是多头牛：

当单体架构出现性能瓶颈时，团队可以考虑将单体架构转换为分布式架构，以增强服务能力。当然，分布式并不是万能的，它解决了单体架构性能瓶颈、可靠性低的问题，但复杂性问题、技术创新问题和发布频率低依然存在，这时候可以考虑微服务。

微服务架构

微服务架构的关键字是拆，将原本糅合在一个应用中的多个功能拆成多个小应用，这些小应用串联起来组成一个与之前单体架构功能相同的完整应用。具体示意如下：

每个微服务可以独立运行，它们之间通过网络协议进行交互。每个微服务可以部署多个实例，这样一来就具备了跟分布式架构相同的性能。单个服务的发布/部署对其它服务的影响较小，在代码上没有关联，因此可以频繁的发布新版本。复杂性的问题迎刃而解，拆分之后架构逻辑清晰、功能模块职责单一，功能的增加和代码的增加也不会影响到整体效率。服务独立之后，项目就变得语言无关，评价服务可以用 Java 语言来实现也可以用 Golang 语言实现，不再受到语言或者框架的制约，技术创新问题得以缓解。

分布式和微服务并不是银弹

从上面的对比来看，似乎分布式架构比单体架构好，微服务架构比分布式架构好，这么说来微服务架构>分布式架构>单体架构？

这么理解是不对的，架构需要根据场景和需求选择，微服务架构和分布式架构看上去很美，但也衍生出了许多新问题。以微服务架构为例：

• 运维成本高，在单体架构时，运维只需要保证 1 个应用正常运行即可，关注的可能只是硬件资源消耗问题。但如果换成微服务架构，应用的数量成百上千，当应用出现问题或者多应用之间协调异常时，运维人员的头就会变大；
• 分布式系统固有的复杂性，网络分区、分布式事务、流量均衡对开发者和运维进行了敲打；
• 接口调整成本高，一个接口的调用方可能有很多个，如果设计时没有遵循开放封闭原则和接口隔离原则，那么调整的工作量会是非常大的；
• 接口性能受限，原本通过函数调用的方式交互，在内存中很快就完成了，换成接口后通过网络进行交互，性能明显下降；
• 重复劳动，虽然有公共模块，但如果语言无关且又要考虑性能（不用接口交互）就需要自己实现一份相同功能的代码；

到底用哪种架构，需要根据具体的场景来选择。如果你的系统复杂度并没有那么高、性能追求也没有那么高，例如一个日数据量只有几万的爬虫应用，单体架构就足以解决问题，不需要强行做成分布式或者微服务，因为这样只会增加自己的工作量。

参考

• https://mp.weixin.qq.com/s/1D676yBFUgukqmllo4yd3A