基于Spring Cloud微服务集群的服务治理思考

基于Spring Cloud微服务集群的服务治理思考

基于Spring Cloud微服务集群的服务治理思考

Spring介绍

1.核心组件:

Beans:表示的是Spring对所有Bean对象的管理,主要包含了对象间的关系配置以及一些对象实例化操作.

Core:包含了最底层的开发支持,例如:依赖注入关系,资源文件的访问,数据类型的转换;

Context:提供的是一个完整的容器上下文,在这个上下文可以处理对象生命周期或者是事务.

表达式语言模块:利用SpEL实现表达式语言的操作,以增强String的功能,

2.切面编程:

AOP:是整个Spring的灵魂所在,利用切面编程来解决所有的辅助性操作,例如:数据库关闭,事务处理,

Aspect:表示的是切面编程的语法支持,该语法形式最早起源于Apache中1AspectJ组件;

Instrumetation:是在JDK1..5之后增加的一个组件,主要用于检测JVM在运行中代码的动态处理功能.

3.数据访问模块

JDBC:在整个JAVA 之中,对于数据库的操作只有JDBC一种操作形式,所以在Spring里面也提供有专门的ORMapping框架,这个框架就利用JDBC半原生完成

ORM:ORMapping框架的处理操作,可以方便整合,JDO,Hibernate,IBatis,MyBatis等常见组件

OXM:提供了一个对象与XML文件之间的互相转换,

JMS:提供有消息服务的支持;

Transactions:表示在数据访问模块支持了事务的操作处理

4.WEB支持模块

MVC:Spring提供有自己的MVC实现(是目前实现最好的一种);

Struts:Spring方便的支持Struts的管理(方便的是Struts2.x而不是Struts1.x)

Servlet:负责处理MVC的Servlet程序类.

现在可以发现,整个Spring完全承办了一个项目能够独立开发,并且可以容纳其他框架同时存在的综合性框架,不像Struts只能够负责控制层,而Hibernate能够负责数据层,Spring全都可以进行负责.

基于Spring Cloud微服务集群的服务治理思考

总结:

Spring中避免了关键字new造成耦合的问题;

Spring本身就是一个工厂,不需要再编写工厂类了;

Spring不再需要进行明确的引用关系的传递,直接通过配置完成;

所有框架几乎都可以在Spring中整合在一起使用

Spring编程=Fcatory设计模式+Proxy设计模式.

在此我向大家推荐一个架构学习交流群。交流学习群号:575745314 里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多
基于Spring Cloud微服务集群的服务治理思考

Spring Cloud微服务集群的服务治理

就目前了解的情况来看,公司的服务提供方是较为混乱的。可能也是因为刚进公司对大多数服务都不是很了解的原因。至少目前来说还是一头雾水。

个人觉得在以下方面可以加强:

  • 每一个服务提供方的功能范围需要明确,且能够从某种意义上与其它的服务提供方区分开来,形成文档来描述系统划分的原则与依据,协助使用者清晰的理解各个提供方的功能,简化调用。同时在后续的服务开发过程中严格按照这些原则来将新增加的服务划分到正确的系统中去,避免系统之间的边界在发展过程中越来越模糊与混乱。
  • 对于当前微服务集群中所提供的服务清单,应该能够通过系统能够看到完整的系统名称、包含提供的服务内容的描述信息、该系统提供的服务清单及其描述信息等。目前通过EurekaServer、Actuator及Swagger可以完成这些功能,但就多数应用来说,目前有一些不尽如人意的地方:一是各个系统的名称、描述信息等较为混乱,无法从这些信息上得到这个系统是做什么用途的。各个应用在定义名称、版本、描述信息时都很随意。同时,在使用Swagger来描述各个接口时,其描述信息也写的比较混乱。二是通过Swagger来查看各个服务提供方的服务信息非常不友好,无法在某一个界面中查看及搜索、定位集群所提供的所有服务接口,而只能先通过EurekaServer定位到某一个提供方后再去访问该提供方的SwaggerUI中查看其提供的接口信息。

可以通过以下方式来进行改进 :

  • 严格规范每一个提供方的应用名称、描述信息的定义。
  • 通过使用Actuator、Erueka、Swagger已有的接口来做一个界面,将这些应用及其接口信息统一收集,并提供搜索定位等功能来辅助使用。
  • 提供调用链路的监控,每一个调用可能会同时调用多个提供者提供的服务,而提供者提供的服务本身又可能会调用其它提供者提供的服务,这些服务调用者之间的关系,如果有一个调用链路图能够看清楚每一个调用请求所使用的服务,那么在后续分析问题、进行某些修改的影响分析等都会非常有用。可以考虑引用sleuth来对调用链路进行监控与分析。
上一篇:apache + tomcat 整合 + tomcat集群 session共享


下一篇:ArcGIS API for Silverlight 地图加载进度条类之MapProgressBar