单体应用到微服务应用的演变

ludy✘

已于 2024-10-01 16:59:09 修改

阅读量675

点赞数 16

文章标签：微服务架构云原生 java 后端

于 2024-10-01 16:49:47 首次发布

本文链接：https://blog.csdn.net/2303_76265918/article/details/142671306

版权

随着互联网的发展，从早期到现在随着需求增长不断产生了新的架构。演变过程如下：

单体应用架构——>垂直应用架构——>分布式架构——>SOA架构——>微服务架构

其实甚至还有个偷偷兴起得网格架构（grid service,这里就不讲了）

我会针对每个架构的优点，缺点以及需求一一讲解。首先最先是最早期应用最广的单体架构，就像下图：

需求：一般网站流量小的话，比如各个商家的宣传网站，只要一个应该并把所以的功能实现写再一起然后统一打包成jar包或war包部署到一台tomcat服务器上就行了。

优点：所以项目代码都打包到一起部署在一个节点上，减少了开发、部署以及运维的维护成本。

缺点：项目之间代码相互依赖耦合度高，一但一个部分处了问题可能导致整个项目挂掉。而且要针对一个项目模块优化起来比较麻烦，水平扩展新能差。

然后就是垂直应用架构了，参考下图：

需求：随着需求跟访问量变大（但是还没那么大的时候），单体架构只能增加节点来应对，但又不是所有部分都有那么多需求，比如一个商城系统做了个好友系统，那这个系统访问量量肯定远远小于商品系统的。因此垂直应用架构诞生了。这种架构在传统行业跟外包行业应用较多。

优点：系统拆分后实现了流量的分担（提高了并发能力），而且还能分小组各自开发各自的模块系统，并且可以针对某一模块进行优化。耦合性降低，假如好友系统挂了的话，商场系统还是可以继续访问的。

缺点：两个核心缺点，一是系统都是相互独立的，无法相互调用；二是随着业务代码的不断增多，各个系统会有重复的代码。

紧接着就有分布式系统了，参考下图：

需求：随着垂直架构业务越来越庞大，重复代码缺点越来越明显，这时候我们就可以把这些重复的代码抽出来做成独立的业务层去单独部署当做统一的服务提高代码复用性。

假如我拿淘宝做例子先把他做出垂直应用架构：

用户管理系统：每个应用都有自己的用户管理模块。
订单处理系统：每个应用都有自己的订单处理逻辑。
支付系统：每个应用都有自己的支付处理模块。

然后我做成分布式的淘宝系统：

用户服务：将用户管理模块抽离出来，创建一个独立的用户服务，所有需要用户管理的应用都调用这个服务。
订单服务：创建一个统一的订单服务，处理所有订单相关的业务逻辑。
支付服务：建立一个支付服务，负责处理所有支付请求。

优点：显而易见，当我把这些系统的重复代码模块抽出来做出单独的服务的话，提高了代码的复用性。

缺点：因为各个模块的调用，系统耦合度提高，而且错综复杂的调用服务使得代码维护起来便困难了。

接着就是SOA架构了，参考下图：

需求：为了更好的管理那些服务，SOA提供了一个服务治理中心，要是使用nginx采用轮询对服务进行负载均且有个节点突然挂掉了，治理中心会处理这个问题。

优点：可以解决服务之间调用的自动调节。假如分布式系统调用采用不同的协议，比如一个用java写的服务需要调用http传输协议，一个用其他语言写的需要调用webservice协议，这样调用不同协议需要不同处理，这样会增加复杂度。而SOA的治理中心会根据这些帮我们来自动协调，可以将不同协议进行转化。

缺点：一是服务之间要是依赖紧密的话，扇出调用服务可能会导致服务雪崩。二是治理中心会让让我们服务中心化，服务必须注册到治理中心，而且调用必须到治理中心拿，这样会导致强耦合。这样也会导致服务关系复杂，运维部署起来成本更高。

最后也就是我们平时最耳熟听起来也似乎最厉害的微服务架构了：

需求：微服务架构也是面向服务开发的一种在SOA架构的升级版本，现在大部分三高（高并发、高可用、高性能）的国内互联网大厂电商用的最多而且有成熟的解决SOA缺点导致的问题的成熟方案。

优点：服务拆分更加精细原子化，可以去独立打包部署，想去单独优化某小块服务也很方便。而且可以让分工更明确，更擅长某块服务的程序员去开发某块服务，易于扩展。市面上还有像springAlibaba的微服务体系提供像nacos来服务注册与发现，也能服务配置，sentinel来进行服务监控，服务降级熔断与限流，这样能更好的管理服务以及防止服务雪崩等情况。各个服务之间通过Restful等轻量http协议来相互调用。