再谈分布式服务及框架

再谈分布式服务及框架。

分布式服务最初是从RPC演变过来的,客户端调用远程方法(应用),本质上是远程调用的可用性问题。

假设服务还是以前的那种单体应用结构,它的业务承载能力毕竟有限,它支持多少并发?不考虑业务复杂如何,单体能支持5,6万的并发已经很高了,这个并发量在现在也很高,这在以前还没有那么高并发量的业务场景,对于单体来说,很多都可能就支持几百上千的并发,3,4千也很高了。

那如果超过了单体所能支撑的并发怎么办?

对于前端(包括api)来说,可以很容易的多加一台机器就可以解决问题, 无非就在ng上在加一个server,就可以做到通过多台机器来支持更多的用户访问。

但对于后台应用怎么办?多加一台机器后,又怎么负载路由? 怎么将用户请求转发到后台应用?

所以到这里就需要有个路由表。

这个路由表的配置在哪? 是不是应该有个路由配置的地方?

有了这个路由表之后呢? 要怎么配置?

这个配置是要手工配置还是?像ng那样手工添加配置?这个后话。

这个路由表需要配置些什么?

我们要调用远程的一个方法,至少需要知道host,port信息以及哪个对象,包括调用的是哪个方法。

这些必要的信息都需要配置到这个路由表中么?

我们将用户请求转发给后台应用,只需要将请求转发到后台的一台节点(机器),所以只需要有host,port就基本可以了。

通常我们要调用远程的一个方法, 我们在客户端会有个代理负责将用户请求转发给服务,代理和服务具有相同的行为,有相同的方法。参考各个RPC实现,如hessian,thrift,grpc,Java RMI等。

有了这个路由表后,又怎么进行路由呢?这个路由转发是均衡的么? 

如果后台机器配置不一样, 处理任务等也不一样,均衡的转发请求又不合适了吧?假设两个机器,一台配置高,一台配置低,配置高的机器就可以处理更多的用户请求,应该将更多的用户请求转发给这台机器,这个又怎么办?

动态配置路由呢?

这个路由配置信息可以自动注册吗?

服务又是怎么注册的?

zookeeper,Eureka, etcd,portmap等等。

服务实例故障后failback又是怎么重新注册的?

这个注册是不是应该有个专门注册的地方?

服务注册中心?

注册的时候是要将远程服务对象注册到Registry上吗?

服务注册了之后又怎么发现这个服务?

发现的时候,发现的服务对象是从Registry查询出来的吗?

服务发现是主动发现还是被动发现的?

failback的服务又是怎么发现的?

这个服务注册中心是中心化的?

可以是非中心化的? 

去中心化呢?

去中心化的分布式服务是怎样的?

如果其中的某台机器出现故障怎么办?

出现故障后怎么将出现故障的机器offline?

如果其中的某台机器负载过高怎么办?

如果在调用某个服务发现服务不可用怎么办?

服务实例failover及failback怎么考虑?

故障容错?

远程调用失败是failfast的还是failback?

调用失败后是要立即重试还是稍后重试?

远程调用上层对象层怎么设计?

远程调用底层Transport怎么设计?

远程调用底层网络层是怎么通信?

IO模型怎么考虑?

基于什么RPC协议?

序列化设计

机器可以一直加下去吗? 可以无限加下去吗?

怎么扩容?

业务请求量降下来了的时候是不是应该多余的机器offline?

怎么缩容?

怎么去评估分布式服务的容量?

要怎么做到弹性伸缩?

要怎么在服务层面上做到弹性伸缩?

整理后再发出来。

相关推荐