大型网站系统与Java中间件实践 第4章 服务框架

为什么需要服务化

数据库连接数带来的压力
应用复杂臃肿,还有一些代码冗余,影响开发效率

前期的解决方案: 把应用拆小,但是数据库的压力还在,一些公用的代码还是可能存在冗余,当前也可以使用共享库的方式解决,应用起来不太方便。

服务化能够解决哪些问题

系统架构更加清晰
专门的团队负责自己的服务,提高代码质量,由于核心相对稳定,修改和发布的次数会减少,也会提供稳定性
更加底层的资源统一由服务层管理,结构更加清晰,利于提高效率。

服务化需要解决哪些问题

服务可能是多层的,服务之间也可能相互调用在,这就需要服务治理。

如何实施服务化

寻址

名称服务
规则服务器

序列化

常用的参数

version :加入版本号控制
group : 分组,如果同一个接口的远程服务有很多机器,我们就可以把这些机器规组,这样就可以将不用调用者对于同一个服务的调用进行隔离了。
服务自身部署方式

将服务框架作为应用的一个依赖包,与应用一起打包,这样就是存在问题,如果要升级服务,就要更新应用本身,并且服务框架没办法接管classloader。
服务框架作为容器的一部分

jar包冲突处理

通过Classloader, 使用用户自定义的ClassLoader,将服务框架自身用到的类和应用用到的类都控制在User-Defined Class Loader级别,这样就实现了相互的隔离。
Web容器对多个应用的处理,以及OSGi对于不同Bundle的处理都采用了类似的方式。

运行时版本统一的情况

需要服务框架比应用优先启动,并且把一些需要统一的jar包放到User-Defined Class Loader所公用的祖先ClassLoader中。

通信方式

透明代理
通过服务注册查找中心进行直连

服务的拆分

要拆分的服务是需要为多方提供公共服务的,对于那些比较专用的实现,如果它们是独立部署在远程机器上的,就不需要拿出来做一个服务了,增加系统的复杂度。

服务的粒度

这是很难量化的方面,需要根据业务的实际情况来划分。

优雅与实用的平衡

在做服务化的同时,还需要考虑到实用性,服务化并不是标准,目的就是一个,提高系统的性能。服务化虽然能够是系统的架构更加优雅清晰,但是如果损失了性能就本末倒置了。

分布式环境中的请求合并

Future方式
分布式锁服务
路由策略

在多机环境中,需要由独立于服务调用者、服务提供者之外的节点来完成相关的工作,也就是需要分布式锁服务来控制。需要考虑其性能。

另外一个思路: 根据一定的规则把同样的请求发送到同一个服务提供者上,然后在服务提供者的机器上做单机控制,这样通过路由策略的选择,可以不用引入分布式锁服务,减少了复杂性。

此外,对于比较消耗资源的操作,不论是使用分布式锁服务,还是采用路由方式把请求送到特定机器,在服务调用者上都可以进行单机多线程的控制。

具体采用何种方式,需要根据具体场景来决定,而且需要数据的支持来做最后的决定。

阅读更多
版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/enzoy/article/details/52386066
文章标签: 系统架构
个人分类: 读书
想对作者说点什么? 我来说一句

大型网站系统Java中间件实践

2015年03月09日 49.42MB 下载

大型网站系统Java中间件实践PDF

2017年10月27日 47.53MB 下载

没有更多推荐了,返回首页

不良信息举报

大型网站系统与Java中间件实践 第4章 服务框架

最多只允许输入30个字

加入CSDN,享受更精准的内容推荐,与500万程序员共同成长!
关闭
关闭