当前位置：首页 > news >正文

业务架构发展历史及相关技术应用介绍

news 来源：原创 2025/8/28 20:05:01

1，单体架构

企业处于发展初期阶段，业务的开发量与用户的访问量较少的情况下，通常情况会将业务编写在一个应用中，由一个web容器完成部署调用。如下图，一个应用中所有的功能模块写在一个war包中，功能模块的代码由项目中的package包来区分，最后打包成war包，放在应用服务器中运行。
在这里插入图片描述

2，集群与垂直架构

随着业务的不断发展和访问需求的日益增加，将会出现以下问题：

用户量越来越多，网站的访问量也越来越大，服务器不堪重负，导致负载过高
用户量的增多，产品需要满足更多用户的需求，业务场景也越来越丰富，随之带来业务功能的拓展与维护量的增加

服务器负载过高将会导致用户在网上的操作响应变慢甚至无法访问

业务场景越多越复杂，意味着war包的代码量会持续上升，并且各个模块业务间代码的耦合度也会越来越高，后期代码维护以及版本发布测试都会变得更加困难。有时候一个小小的bug修复也会导致整个war包需要重新部署，一个小小的业务修改可能也会牵连到其他业务代码的修改
解决方案

1，将单台应用变成多台应用，构建集群实现横向扩展，单纯的集群模式，能缓解单台服务器的访问压力，降低单台服务器的负载；其中如果服务器的性能还可以的情况下，多个tomcat应用可以放在同一台服务器上，利用不同的端口运行，然后通过Nginx做负载均衡，做负载的转发工作；如果单台服务器性能较差，可以将tomcat应用放在多台服务器上，同样通过Nginx做负载均衡，做负载的转发工作。
在这里插入图片描述
2，对业务进行垂直拆分，每个业务模块拆分为相应的子系统，由不同的业务团队负责维护和独立部署。多个子系统对内是一个个独立的应用，对外则是一个整体，用户通过统一入口访问系统的各个子系统

此种架构较上面一种，主要区别在于应用层面做了拆分，将功能模块代码做了项目的划分，每个功能模块能够单独在tomcat中运行。按照上图部署，就不需要考虑系统登陆用户问题，session存放在tomcat中，一套应用可以共享session。
3，垂直拆分后的应用，引发的问题就是有的功能模块的访问量不是很大，比如用户服务访问量不大，而订单系统访问量大，因此在tomcat中都运行了系统所需要的所有war就会造成性能的浪费。因此分布式架构油然而生。
在这里插入图片描述
在应用被垂直拆分之后，单个应用可以独立运行，这样可以根据需要将访问量大的服务多跑几台服务，访问量小的服务，少跑几台，充分利用服务器的性能，不造成浪费，同时带来的问题是，单独的模块服务运行在不同的tomcat上，整个系统的登录用户每个系统都需要登录才能访问，因为session在不同的服务器上，单点登录就是解决这个问题的，主要的原理就是通过redis实现session共享，当用户登录一次之后，将用户登录的session缓存到redis中，然后访问其他应用服务的时候，在redis中获取登录用户信息，保证用户登录的session共享。

3，SOA面向服务架构 Service-Oriented Architecture

在垂直架构中，由于每个应用都由独立团队进行开发和维护，不可避免会出现多个垂直应用中出现重复冗余的业务处理，比如在一个电商系统中，用户系统和订单系统在用户下单时需要进行子系统的通信，此时下单检查库存的判断放在用户系统中还是放在订单系统中？诸如此类的共享业务将会大量出现在每个独立的垂直子系统中，使得子系统成为了信息孤岛

解决方案

将重复的业务抽离成独立的服务应用，将并服务发布到服务总线上，其他子系统可以通过服务总线对已发布的服务进行调用

服务的提供方和调用者可以实现高度解耦，并能实现功能功能的复用
在这里插入图片描述
因此微服务油然而生，SOA是一种企业开发的设计架构，用于满足日益增加的业务开发需求并实现高重用与高解耦。微服务是对SOA的细化表现，当每一个服务需要进行精度更高的设计，并完成进一步拆分和重用时，微服务由此诞生
在这里插入图片描述
微服务的特征：

是一种架构设计的风格
单独的应用会被拆分成一个个小的服务
每个服务是一个独立的进程
服务之间调用采用轻量级的通信机制【HTTP协议、RPC协议等】
每个服务可以通过不同的开发语言编写

微服务随之带来的问题:
7. 多个微服务之间的通信，使用http工具类？socket？webservice?rpc?【通信工具】
8. 每个微服务在调用时都应有一个url地址，当新增或者变化一个服务的url地址时，如何通知到调用者？因此服务的url需要进行管理和维护【注册中心】
9. 每个微服务都需要集群支持更多的并发访问量以及稳定性，如何选择集群中的多个服务？【负载均衡】
10. 如果某个微服务不可调用，或者调用失败该如何处理？【容错机制】
11. 每个微服务虽然是一个独立的应用，但对于用户而言多个微服务还是一个整体应用，因此需要一个统一的入口来访问【网关】
12. 因为业务的复杂度导致多个微服务间递进调用，由此形成一个调用链路，当某个微服务出现问题时如何对链路进行追踪？【监控】
13. …………

解决方案的选择处理

上述微服务中出现的每个问题实际上都有对应的解决方案，比如注册中心有Eureka、Nacos、Zookeeper、consul等，那我们到底选择哪种解决方案？

众所周知，现在Java开发离不开Spring框架的应用，因为spring makes Java simple|moden|productive，所在在考虑解决方案的时候必须要考虑如何将工具整合进spring，而所有能整合至 spring框架的技术内容必须要由spring提供接入的接口规范。因此spring推出一套微服务领域的标准，这就是springCloud
SpringCloud微服务解决方案

企业在微服务架构中遇到的种种问题给开发人员带来诸多麻烦，Spring在2015年将微服务开发中可能产生的问题与流程进行了规范，在Spring框架的基础上将解决微服务中常见问题的框架进行了整合，并提供了相应接口，为开发人员提供了较好的微服务开发体验，因此SOA是一种面向服务的架构设计思想，微服务是SOA的延展，提高了服务颗粒的细度，而SpringCloud则是微服务的一套具体的实施解决的方案和标准

SpringCloud中的每个服务都是一个SpringBoot应用，因此在使用SpringCloud时需要注意和SpringBoot版本的匹配，可以通过 https://spring.io/projects/spring-cloud/ 查看

在这里插入图片描述
SpringCloud的版本说明

SpringCloud的starter中包含了大量Spring组件，每个组件的版本也都独立发型，因此组件的版本号都不尽相同，每次使用时如果要分别指定这些组件的版本是件麻烦的事，并且这些组件还存在版本依赖的关系，所以SpringCloud为了统一设置这些组件的版本，使用了伦敦地铁的名称作为SpringCloud的版本号，这样我们在使用时就不用关注组件的版本了

springCloud提供了非常丰富的解决方案提供给开发人员选择，包括了spring自身提供的方案比如Config分布式配置、Gateway网关路由、OpenFeign服务调用、RabbitMQ分布式消息等，甚至将一些成熟团队的批量解决方案也一起并入了spring

Netflix团队提供了Eureka注册中心、Hystrix熔断器、Feign服务调用、Zuul路由器、Ribbon负载均衡

Alibaba团队提供了Nacos注册中心、Sentinel熔断器、RoketMQ分布式消息、Seata分布式事务、Dubbo RPC服务调用

开发时我们可以选择Netflix的配套方案，也可以选择Alibaba的配套方案，或者将两个团队的方案拆分使用都是非常灵活的

SpringCloudAlibaba版本说明

https://sca.aliyun.com/
在这里插入图片描述

上述为大体的演变过程，还有更详细的演变过程如下：
https://mpbeta.csdn.net/mp_blog/creation/editor/103584125

1，单体架构

2，集群与垂直架构

3，SOA面向服务架构 Service-Oriented Architecture

相关文章：