一,传统的应用
1.1,在此之前,所有的架构都是采用单体应用的模式,通过status,spring,hibernate,mybatis等技术架构
每一个项目都会发布一个单体应用,通过war包的形式发布到tomcat,每新增一个模块都要在原始应用上增加,若干个版本后,该war包不断膨胀,程序员要维护和调试都要启动半天,变得极其复杂和管理。例:如下war包
该系统涵盖了销售,库存,会员,报表模块,后期可能还会增加采购,财务,行政等模块,这样的单体应用隐患非常多,可能某个模块的一个Bug就会引发系统的宕机,不断效率低,风险性还很高,所以得从本质上去改变。
二,架构演进
针对以上的单体应用对架构进行改进,参考SOA架构,将各个模块划分为独立的服务模块,并进行数据的读写分离。
各个模块之间存在相互依赖关系,例如销售模块需要调用库存模块,未来减少模块之间的耦合,我们加入企业服务总线(ESB)
加入ESB后,将各个模块发布到ESB中,发现系统的整体性能提高了,模块之间的耦合度也降低了,但过了段时间后发现销售终端的数量增多了,销售模块也明显超出了其承受范围,为了保证销售前端的正常运行,我们加入nginx做负载均衡
目前回到正常运行状态,但随着以后各模块数量的不断增多,不便于后期的维护,一旦出现模块修改则牵引着一大批依赖模块的改动,企业服务总线也可能成为性能的瓶颈。
1.2从前面的架构演进也可知,应用中的每一点都可能成为系统的问题点,随着互联网的普及和大数据应用,高并发,我们必须建立一套全新的架构能应对这些问题严谨的挑战,它起码得满足以下要求。
1:高性能:这是应用程序的基本要求
2:独立性:确保在某个模块出现bug等不影响其他模块
3:易扩展:系统中的每个模块都能根据需求进行扩展
4:便于管理:轻松管理各个模块之间的资源,升级,减少维护成本
5:状态监控和警报:当某个节点出现问题能及时发出警报通知从而做出相应的处理方案
为了能解决以上的问题,我们着手研究SpringCloud吧!
三,微服务与SpringCloud
3.1
微服务对比SOA架构的好处是微服务中的各个模块单元本身就可以做成一个或多个服务组件,更加细粒度的划分。
3.2:SpringCloud与微服务
SpringCloud并不是一个具体的框架,大家可以理解为一个工具箱,它能帮我们快速构建一个分布式系统,SpringCloud的各个项目通过SpringBoot将NetFilx的多个项目进行封装,通过自动配置的形式绑定到Spring中,从而简化了这些框架的使用,由于SpringBoot的简单易用,我们要使用SpringCloud时可以方便的使用将Netfilx中的各个项目整合进来,SpringCloud主要整合了Netfilx中的项目
Eureka:基于Rest服务的分布式的中间件,主要用于服务管理
Hystrix:容错框架,通过添加延迟阀值来帮我们控制分布式组件中的交互
Feign:一个Rest客户端,帮助我们简化webService的开发
Ribbon:一个负载均衡框架,在微服务中为各个集群中的通信提供支持,主要应用在中间层框架的负载均衡
Zuul:为微服务提供代理,过滤,路由等功能
3.3:SpringCloud中的主要模块
除了SpringCloud-Netfilx中的各个项目,还包括以下主要模块
SpringCloud-Config:为分布式系统中的服务器和客户端提供配置,通过配置可以更好的管理各组件的配置文件
SpringCloud-Sleuth:服务跟踪框架,可以与Zipkin,Apache,HTace等数据分析,服务跟踪系统进行整合
SpringCloud-Steam:用于构建消息驱动的微服务框架
SpringCloud-Bus:连接RibbitMQ,Kafka等消息代理的集群消息总线
结尾:以上就是本篇的整体概述,下一篇开始代码。
以上内容部分引自<<杨大仙的疯狂Spring Cloud>><链接>