您现在的位置是:主页 > 数据库技术 > 数据库技术

Spring Cloud的示例分析

IDCBT2021-12-25服务器技术人已围观

简介这篇文章给大家分享的是有关Spring Cloud的示例分析的内容。小编觉得挺实用的,因此分享给大家做个参考,一起跟随小编过来看看吧。 1Spring Cloud概述1.1 传统的应用1.1.1 单体应用 在此之

这篇文章给大家分享的是有关Spring Cloud的示例分析的内容。小编觉得挺实用的,因此分享给大家做个参考,一起跟随小编过来看看吧。

1 Spring Cloud概述1.1 传统的应用1.1.1 单体应用

        在此之前,笔者所在公司开发Java程序,大都使用Struts、Spring、Hibernate(MyBatis)等技术框架,每一个项目都会发布一个单体应用。例如开发一个进销存系统,将会开发一个war包部署到Tomcat中,每一次需要开发新的模块或添加新功能时,都会在原来的基础上不断的添加。若干年后,这个war包不断的膨胀,程序员在进行调试时,服务器也可能需要启动半天,维护这个系统的效率极为低下。这样一个war包,涵盖了库存、销售、会员、报表等模块,如图1-1。

图1-1 单体应用

        这样的单体应用隐患非常多,任何的一个bug,都有可能导致整个系统宕机。笔者印象最深刻的是,曾经有一客户在高峰期,导出一张销售明细报表(数据量较大),最终造成整个系统瘫痪,前台的销售人员无法售卖。维护这样一个系统,不仅效率极低,而且充满风险,项目组的各个成员惶惶不可终日,我们需要本质上的改变。

1.1.2 架构演进

        针对以上的单体应用的问题,我们参考SOA架构,将各个模块划分独立的服务模块(war),并且使用了数据库的读写分离,架构如图1-2。

图1-2 架构演进

        各个模块之间会存在相互调用的依赖关系,例如销售模块会调用会员模块的接口,为了减少各个模块之间的耦合,我们加入了企业服务总线(ESB),各模块与ESB之间的架构如图1-3所示。

图1-3 ESB

        加入ESB后,各个模块将服务发布到ESB中,它们与ESB之间使用SOAP协议进行通信。图1-2与图1-3的架构实现后,整个系统的性能有了明显的提升,各个模块的耦合度也降低了。运行了一段日子后,又出现了新的问题,由于销售终端数量的增多,销售模块明显超过其承受能力,为了保证销售前端的正常运行,我们使用了Nginx做负载均衡,请见图1-4。

图1-4 使用Nginx

        随着销售模块的增多,带来了许多问题,例如管理这些模块,对于运维工程师来说,是一项艰巨的任务,一旦销售模块有所修改,他们将通宵达旦进行升级。另外,企业服务总线也有可能成为性能的瓶颈,虽然目前仍未出现该问题,但我们需要未雨绸缪。

1.1.3 架构要求

        从前面的架构演进可知,应用中的每一个点,都有可能成为系统的问题点。随着互联网应用的普及,在大数据、高并发的环境下,我们的系统架构需要面对更为严苛的挑战,我们需要一套新的架构,它起码能满足以下要求:

标签:

很赞哦! ()

本栏推荐