【SOA】从单体架构到分布式微服务架构

前言

2016年局座B站直播首秀，由于观众瞬间大量涌入导致网站直播系统崩溃。早期的B站不以直播起家，当时的直播系统还是一个php写的单体架构系统即LAMP（Linux+Apache+MySql+PHP），基本上所有的模块都耦合在一起，就像这样：

做过单体项目的人都知道项目中的子模块只要一个出问题就有可能拖垮整个系统
举一个我亲身经历的故事：
在以前我做瑞吉外卖（一个SpringBoot+MySQL的单体项目）的时候我用Jmeter开辟了1000个线程去测了一下接口性能（没用缓存），结果测试用例执行到一半数据库就挂了，自然而然子模块的功能就不能生效连带着耦合着的模块失效。当请求去访问其他模块的接口返回结果就像多米诺骨牌一样全是ERROR，这种情况的发生单体架构就显得苍白无力。

回归正题，在那样突如其来的高并发情况之下，子模块肯定是承受不住压力的，所以导致整个B站的直播系统就崩了~也是自此开始B站慢慢由Php转为了Go，由单体架构转型成了微服务架构。那么，什么是单体架构？为什么以前要使用单体架构？什么又是微服务架构？

单体架构系统

整个系统的所有功能单元,整体部署到同一个进程(所有代码可以打包成1个或多个文件)，我们可以称之为”单体系统”
比如（SSM+Tomcat+Mysql）吧业务逻辑层的service,controller和数据访问层的dao层,打包成war包，部署在Tomcat或者Jetty或者其他容器上运行

这样的系统优点特别明显：

易于开发、易于测试、易于部署，而且因为各个功能、模块、方法的调用过程，都是在进程内调用的，不会发生进程间通讯，所以程序的运行效率也要比分布式系统更高，所有的代码都运行在同一个进程空间之内，所有模块、方法的调用也都不需要考虑网络分区、对象复制这些麻烦事儿，也不担心因为数据交换而造成性能的损失。

但劣势也非常致命：

当业务越来越复杂，单体架构扩展性不足，业务扩展带来的代价越来越大。用户越来越多，程序承受的并发越来越高，单体应用的并发能力局限性是很大的，因为所有的代码都共享一个进程空间，程序运行中一旦发生内存泄漏、线程爆炸、阻塞、死锁、死循环等问题，都将会影响到整个程序的运行，而不仅仅是某一个功能、模块本身的正常运作；而如果消耗的是某些更高层次的公共资源，比如端口占用过多或者数据库连接池泄漏，还将会波及到整台机器，甚至是集群中其他单体副本的正常工作。

在以前学习Spring的IOC时提到了他一个“解耦合”的特点，IOC降低了类与类之间的耦合性，但离开类的范围，单体系统中模块与模块之间的耦合性始终得不到降低。

微服务架构系统

上述的缺点推动着架构的演进，从开始的水平架构到垂直架构再到最后的分布式架构…作为分布式架构的完美解决方案“微服务”在近些年也是十分的火爆。

见名知意，微服务——将一个系统拆分成若干个独立的模块，运行于独立的进程中。每一个子模块也被叫做一个“微服务”，并且每个服务都有属于自己的数据库，极大降低了事故发生的概率。

在单体架构中所有的子模块都在统一进程里，不存在进程之间的调用，当一个模块想要调用另一个模块时直接注入实例，调用实例即可。

服务治理

但对于微服务而言，模块间的调用跨越了进程。要想得到目标的实例可不能直接进行注入，于是就需要将一个个子模块，也就是微服务注册到Nacos（注册&配置中心）并进行相关配置，通过Feign实现服务间的远程调用，并使用Gataway做权限认证。为了保证微服务模块间消息的高可用与服务响应的速度则是使用到了异步通信工具MQ，这些治理的组件得到了Spring的整合，因此SpringCloud通常被拿来用作服务治理的方案。

所以，不要再把SpringCloud与微服务画“=”了！