对分布式框架的一些思考

利用一些RPC框架进行分布式计算已经不是什么新鲜的话题,微服务在生产中的应用也变得越来越普及。但是,我们还是需要回到起点思考一下,微服务到底有什么用呢,它解决了什么问题又带来了哪些问题呢?今天我结合Dubbo这个框架,讲一下平时使用的一些心得。

首先是第一个问题:为什么需要拆分子模块呢?
这是因为随着公司业务的发展,东西肯定越做越大,开发的人也越来越多,甚至分成了好几个小组。代码量一大,人一多,可能维护起来就变得麻烦,再加上应用越来越大的内存开销,拆分为多个模块往往是一个比较好的选择。这样子,一个小团队的人维护他们自己的子模块,每一个模块在整个系统中扮演着不同的角色。这些角色的服务目标人群可能是其他开发小组,内部的其他部门,甚至是对外开放,所以,每一个角色的性质可能也不一样,包括权限、监控等等方面——拆成一个个子模块,就很容易对它们进行个性化的定制。同时,某一些子模块可能是其他一些模块的基础服务,比如spring cloud的配置中心,比如某个支付系统下的订单系统。他们的功能有可能会发生改变,但同时可能会影响其他N个模块。将它们抽离出来,单独维护,这样子就能避免写很多重复性的代码。当然仅仅是多模块,其实也不是必须需要分布式计算才能完成,比如springboot的多模块项目,只需将公用的模块打成jar包,让其他模块依赖就行了,然后设置扫描的路径,这些公用模块的组件一样可以发挥功能。所以,分布式的所要解决的痛点完全不止这一处。

那么第二个问题来了:rpc到底解决了什么问题,他又带来了什么问题?
正如问题一所说,实现代码的公用、抽象、解耦是一方面,实际上,比如dubbo,feign这些分布式框架,他们往往还提供了服务治理等其他功能。比如dubbo的服务提供者可以在zk上注册多个,然后消费者去zk上取到他们的地址并调取接口。这个过程往往是跨机器的,而且不是简单的一次调用。查看dubbo的默认设置,我们会发现它有最大失败重试次数,超时时间,最大请求堆积数等等,其实这些参数就是一些服务治理的个性化配置,我们通过设置这些参数,可以实现高可用,削峰等等特性。当然,这不仅仅只有优点,他也带来了很多新的问题。首先,不管是json(feign)还是二进制(dubbo),服务消费者和生产者交互的数据必须是可以序列化的(比如dubbo传输的对象或者它的父类需要实现Serializable接口),而且在序列化的同时会带来很多问题,包括异常类型的丢失(dubbo会把service层抛出的异常套一层RunTimeException,所以如果你设置了mvc异常拦截器,往往不会按你预想的完成功能,必须要采取封装为RpcResult类似的方式避免,至于feign没有具体了解过),一些transient字段的丢失等等。而在运维方面,分布式的采用也会带来一些额外的麻烦,比如服务的平滑升级,中间组件的维护(zk对网络波动的反应非常大,而且没有特别好的监控管理页面)等等。
另外,还会导致其他一些比较麻烦的问题,比如分布式事务,等等。

那么,既然有http 请求,为什么还要用rpc调用?
这个问题其实是有理解误区的,首先 http 和 rpc 并不是一个并行概念。
这里附上一个链接,这位知乎大佬的解释比较全面:
https://www.zhihu.com/question/41609070
他详细解释了“良好的rpc调用是面向服务的封装,针对服务的可用性和效率等都做了优化。单纯使用http调用则缺少了这些特性”。其实不光是性能,站在应用层的角度,我们会发现web服务和service服务还是有很大的差异的。web服务往往不需要直接连接数据源进行操作,而是应该将宝贵的数据源连接集中在service服务统一维护管理;service服务往往不需要设置额外的权限,系统内部应该是互信的,像zk那种简单的权限控制就能满足需求,而web服务往往需要security或者shiro等专门的安全框架,还要处理jwt或cookie或session等等东西。根据高内聚,低耦合的设计思想,必须需要一个专门的中间组件来处理这个特定的功能,而非在每一个应用上随意地添加功能。

有空我会补上代码,再详细下一些说明~

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值