在两年前，我曾经设计过一版，高可伸缩服务器架构， 但只进行了理论推演，并没有使用具体业务逻辑验证过。以这两年的经验来看，这个架构不具备可实施性。
在之前的架构中，我只考虑了Gate和其服务之间的交互。没有考虑其他服务之间也会有基于"玩家"的交互，还可能有基于"联盟"等其他对象的交互。
按这套模型继续演化下去，为了解决"任意两服务"之间的交互问题，势必需要所有服务都有一份相同的Agent对象。这样一来，整个架构的复杂性就大大提升了。
这两年里，我一直在思考，游戏服务器和WEB服务器最本质的区别是什么？为什么WEB可以很轻松的做伸缩， 而游戏服务器想要做对就很难。
现在，我想我有了答案。
WEB的经典模式其实是"逻辑"服务和"数据"服务分离。
每一次WEB请求都是一次全新的上下文来处理。如果需要延续之前的状态，就从"数据"服务获取之前的状态之后再处理。
而由于"逻辑"没有状态，因此几乎可以无限扩展。
如果事情到这里就完美解决，这个世界就不会有“理想情况”和“现实情况”之分了。
这个世界是平衡的，看似WEB可以轻松获取高可伸缩的能力，但其实高可伸缩的压力全落到了"数据"服务（大部分情况下，数据服务都是由数据库来完成)。
由于可能会有任意多个"逻辑"服务，同时访问和修改同一个数据。为了解决并发问题，数据库需要提供ACID功能。
当数据量和读写并发量上来以后，数据库就需要进行"分片"来提供可伸缩性。然而，数据库分片之后，ACID的功能就大打折扣。分布式情况下ACID的难度要远高于单机ACID， 而且性能也得不到保证。这也是为什么后来会有很多NOSQL的出现。NOSQL其实更应该叫NO ACID才对。
为了尽可能的不分片，人们总是倾向于先极限压榨"单机""数据"服务的吞吐量，比如设计一主多从机制来改善查询压力（大部分情况下，你看到网页过3秒跳转的，都是利用了这种机制。主机和从机之间的同步一般在1s以内，延迟3秒就是为了能确保在从机上查询出刚刚在主机上写入的数据)。甚至还会在数据库之前再加Redis或Memcached等缓存系统来改善数据库的压力，一般这种缓存数据服务都是NOSQL，其目的就是为了避免ACID和硬盘数据结构所带来的性能影响
因此可以得出一个结论，其实WEB的可伸缩性的限制并不是不存在，而是主要落在"数据"端。
而"数据"端的可伸缩设计，由于各种现实环境的掣肘，即使是到了现在，也依然没有一个银弹方案。可以认为依然是一地鸡毛。
而游戏服务由于性能原因，不太可能像WEB的工作流程那样，每一次对数据的查询和修改都直接穿透到"数据"服务。
大部分常见的做法是，在服务器启动和玩家登陆时，加载必要的数据到"逻辑"进程的内存中。
在接收到请求之后，直接在内存中处理相关数据，然后在合适的时间节点（比如每个请求处理之后，每个定时器事件处理之后，每隔一段时间之后）对脏数据进行落地。
这么比较下来，其实我们的游戏服务，更像是WEB的"数据"服务而不是"逻辑"服务。而从WEB"数据"服务的可伸缩设计历史来看，游戏服务的高可伸缩性也并不是这么容易就可以实现的。
由于我们需要操作的必要数据都已经在内存中了，我们也不可能再借助一主多从或redis/memcached等机制提升性能了。
我们可以提升性能的惟一手段就是伸缩,而伸缩性的惟一的手段就是“分片”（把玩家的数据，全服数据分摊到不同的游戏服务中)。
然而，由于现代分布式数据库领域都还没有特别完美的ACID解决方案。我们的游戏服务之间的交互更不可能提供ACID功能了。
幸运的是，这个世界是平衡的。在我们需要极高性能的同时，对错误的容忍度也相应提高了。
在此之前，先定义两个术语：
"错误" -> 是指产生了不可预料/推理的结果，比如并发过程中，两个线程同时对一个变量进行自增（没有使用原子操作指令)。这种结果是无法预料了，就算出了错了，你也很难推理出正确结果。
"异常" -> 是指产生了一些异常的，但是可推理出正确结果的操作。比如两个线程同时去对一个变量自增， 一个线程在自增前对此变量加锁，在锁定过程中，另一个线程尝试获取锁（非阻塞），如果获取失败，他直接打了一行log即算完成。在这种情况下，即使变量的最终值是不正确的，但是我们借助log是可以还原出这个变量最终值的。
我认为在游戏服务器的分布式领域中，我们只要阻止错误的发生就可以了。至于异常是避免不了的（比如超时)。
基于这个原则和我两年前的架构设计，我重新抽象了整个分布式架构。
在这次的设计中，我不再为玩家设计Agent。而是为每一个服务设计Agent.
当一个服务SA会被其它服务调用时，SA需要提供一段Agent代码来暴露他的能力。
依赖SA的服务仅通过这段Agent代码来间接与SA交互。
当然SA可能会被水平扩展多份，但是具体这次请求会被路由到哪一个SA的实例上，则由相应的Agent代码来决定，这样从调用方的角度来看，就像集群中永远只有一个SA实例存在一样。
这次的抽象和上次一样，我并不企图抹平分布式的事实，仅仅只是为了抹平同一个服务会被水平布署多份的事实。
在设计完这个抽象之后，一个自然而然的事实，摆在我面前。
假如，有三个服务A，B，C。每一个服务都有一段对应的Agent代码agent.A, agent.B, agent.C。
因此，在每个服务中，每一份Agent代码都各有一份实例:
A::agent.B,A::agent.C
B::agent.C,B::agent.A,
C::agent.A,C::agent.B
我们需要保证所有的X::agent.A，X::agent.B, X::agent.C实例中的对相应服务的连接是一致的。
讲道理，用配置文件是最简单，也是最可靠的，但是服务间的启动依赖需要自己实现代码来管理。
索性将服务发现一起实现了吧（坏处就是，即然是服务发现，就意味着节点在挂掉和重启之间，是有可能进行地址变更的）。
在WEB领域，一般服务发现典型的做法是，使用etcd或zookeeper。
但是对照一下上面对WEB的概述就会发现，他们的服务发现，一般是用于"逻辑"的服务发现，而不是"数据"的服务发现。
我们的游戏服务与WEB的"数据"服务相似。每一个实例都负责惟一的一份数据，而且我们游戏服务并没并有提供ACID。
试想一下，如果我们用’etcd’来做服务发现会发生什么情况。
我们有一个role_1服务负责处理uid: 1000-2000的玩家数据，由于某种原因，它失联了。我们认为他挂了，又启动了一个实例role_1_new来负责处理uid: 1000-2000的玩家数据。但其实role_1只是与集群中的部分节点失联而已。这时就会出现，role_1和role_1_new同时操作着1000-2000的玩家数据, 这种就属于"错误"而不是"异常"。因为这种操作不可推理，也不可逆。
一旦出现这种情况后，我们的期望应该是"异常"而不是"错误"。
为了解决这个问题，我们必须自己设计“服务发现”机制。
在这次设计中，我将所有实例分为两类，master和worker。
master用于协调所有worker之间的互联，以及提供某种一致性，不参与业务逻辑，全局只有一份。
worker节点则真正用于处理业务逻辑，worker可以再细分为不同种类的服务（比如auth, gate, role)，具体由业务逻辑来决定。每个服务可以水平布署多份实例。
为了确保不会出上述两个服务实例处理同一份数据的情况。我将一个实例成功加入集群的过程分为两个阶段:"up", "run"。
在"up’阶段，worker携带服务名向master申请加入集群，master检查此服务是否全部健在（即已经有足够多的处于"up"或"run"状态的服务存在），如果全部健在，则向此worker返回加入失败，worker收到失败后自动退出。如果此服务有空缺（比如需要5个实例，但现在只有4个健康实例。master会定期检查所有worker的心跳状态，如果有worker心跳超时，则将其标记为"down"状态，但是并不通知集群，直到有新的worker替换它才会通知集群，这么做是为了防止过载误判。）则master向所有worker广播当前集群信息（所有的Worker的信息)。worker收到广播之后，如果发现某个实例被替换，则关闭掉相应的rpc连接，并返回成功。在所有worker都返回成功之后，master向申请的worker节点返回成功。
worker在"up"阶段完成之后，会拿到当前分配的slotid和当前服务被计划布署实例的个数capacity。其中slotid即为(1~capacity)中的一个值，一般用于做数据分片。
worker根据slotid和capacity开始从数据库加载所需数据。
加载完成之后，worker再向master申请接管消息处理。此时master会再次将集群信息广播给所有worker， 待所有worker都返回成功之后master返回成功。在worker收到广播消息之后，发现有新的“run”节点，则创建与其对应的rpc连接。
至此，新加入的实例，处于一致状态。
API设计类似如下：
----master实例
local capacity = {
['auth'] = 1,
['gate'] = 2,
['role'] = 2,
}
local ok, err = master.start {
listen = addr,
capacity = capacity
}
---worker实例
worker.up {
type = "auth",
listen = listen,
master = master,
proto = require "proto.cluster",
agents = {
["gate"] = gate,
}
}
worker.run(MSG)其中在worker.up时需要提供关心的服务列表，提供其相应的agent对象。每个服务在新建立rpc连接时，都会回调其对应的agent.join，示例代码如下：
function M.join(conns, count)
if not gate_count then
gate_count = count
else
assert(gate_count == count)
end
for i = 1, count do
local rpc = conns[i]
if rpc then
gate_rpc[i] = rpc
end
end
endBTW, 这种组网机制还可以提供一些时序保证（就是上面提到的一致性），如果在worker.up或worker.run返回之后，Agent对象中还没有建立相应的rpc连接，那么这个Agent对象所对应的服务一定在此之后才能成功加入集群。