微服务架构是进来比较火的一个概念,其核心思想就是将业务按照最小颗粒度进行拆分,无论是基础服务还是业务功能,服务拆分之后我们通过一种数据通讯协议将系统之间连接起来,现在看来,标准的做法就是将每个服务对外的接口封装成为ReatApi供其他的服务进行调用.,那么,我想说的是这个通信协议一定要用Http么,答案但是否定的.
首先,我们来八一下Rest这个玩意,Rest其实是一种架构风格,由Roy Thomas博士于2000年提出(多么有远见的人),其论文原文见:Architectural Styles and
the Design of Network-based Software Architectures 其实在thomas博士并没有在其论文中说一定要用在http这个协议上,只是拿http来做为一个例子而已,所以理论上我们在服务之间使用rest这种风格来传输数据就可以了,至于中间传输数据的协议用http,还是soap还是别的都没有关系,所以这里我们可以知道,不一定需要使用HTTP协议作为数据传输的协议载体.
在http2并没有完全推广起来之前,大家其实对于http作为微服务的传输协议都是有疑惑的,最关键就是在于http的传输效率,因为它不是长连接,所以每次请求都需要花费时间用来建立tcp的连接,当并发量大起来的时候,这确实会成为一个问题,也许现在大家都是在小范围内的应用微服务,所以瓶颈也不大会马上显现出来.但是我想在将来使用http协议构建的为服务体系肯定会成为一个性能瓶颈,先看看论文中描述的微服务网络架构.
这里使用的DNS做服务发现与负载均衡,现实应用中会有专门的discover服务提供给应用发现服务,然后由Nginx来做负载均衡,这样看来整个服务链的调用是变快了,但是总的说来调用层次多了,每一层耗费3~5ms的话,加起来还是很大的性能损耗,相比而言SOA中service直连的方式,会更加高效很多.
不过话说回来,SOA中服务依赖的处理中,如果颗粒度也降低到微服务的级别的话,那么它也将面临很大的路由压力,我的想法是如果有一个中间件来路由所有的服务请求,至于服务发现与治理由这个中间件来做,所有的数据请求由中间件来转发,一旦这个中间件与个应用之间建立长连接的话,这个速度还是会很快的,当然,这个中间件的性能要求也会非常的高.一旦能成功,那么它的好处是显而易见的,我想了想,这个中间件的功能应该有以下几点:
- 服务注册
- 服务路由
- 应用监听
- 数据缓存
- 调用监控
- 服务降级
- 流量控制
- 分布式部署
基于以上几点,能做到的话,那么好处也是显而易见的:
- 无需应用自动发现服务自己创建连接,省去了很多时间
- 应用一旦注册成功,离线可以报警,或者频繁离线也会报警,保证了服务稳定性的监控
- 有关于幂等性的操作,可以缓存数据,加快数据调用
- 服务与服务之间的的调用能后用非入侵的方式被监控(类似google的Drapper的思路,在公共组件中注入监控),而且可以由中间件控制超时与服务熔断.
- 可以在中间件中处理服务降级的需求
- 对于不同的服务可以设置不同的Qos,保证服务质量
- 分布式部署保证中间件的高可用,并且可以在多集群部署,来保证服务分区的需求.
本人对微服务研究的不深,有很多地方考虑的也不是很周到,请各位看官赐教,也可以直接邮件[email protected]
