再谈分布式服务及框架

再谈分布式服务及框架。

分布式服务最初是从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？

怎么缩容？

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

要怎么做到弹性伸缩？

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

整理后再发出来。