随身而行的服务3-分布式服务的基础构架特性

服务信息的存储可拆分
服务信息的存储在一般的情况下，如UBB、VBB这样的论坛，它们将数据存储在了一个mysql数据库中。我们会发现如果我们的一台机器不能承担访问怎么办。现在的办法差不多就是增加web服务器，如果数据存储的压力过大，则使用mysql的mast和slave的机制做出几个只读数据库来。所有读的请求发到slave上，所有写的请求发到master上。哪么还有可以扩充的办法吗？看来是没有了！

哪么我们看看我们web bbs的先烈bbs和news system是如何做到了分布在全世界的服务体系。老的bbs和news服务器有一个feed的功能，它将所有分布式的服务器，通过feed交换彼此间所差异的数据。每个用户都访问与自己最近的bbs服务器，从而共享数据、共享服务。这样的例子可以通过看到各大news上的comp.*以及bbs里各大院校的共同feed的版而发现。

但是bbs和news由于个性化数据非常少，所以不是一个服务信息拆分的方式。最终带来的效果并不完美。每个人不能将自己的帐号在所有服务器上漫游，同时回复是需要时间才能反应到每台机器上去。对于个性化的服务，我们可以用另外一个例子，就是my yahoo这样的服务。用户真实的信息是存储在自己使用的哪个服务器上的，而yahoo的sso又可以将用户分发到他自己的服务信息所处的服务器上去，从而达到了一套完整的系统拆分服务信息、拆分服务到若干台服务器上去的目的。

服务必须有一个统一的登录和认证机制，建立基于sso的应用与认证相分离的认证体系
在上面也说到了，yahoo的my yahoo是通过sso来导向用户到自己所处的服务器上去。我认为sso不是一个必然，可以通过一个处在每台机器上的login程序来做导向处理。但是显然，一个分布式的用户认证信息存储系统无论如何都会成为sso或每台机器上login程序所使用的基础数据存储主体。这个用户认证信息的数据中包括了用户的用户名、密码、所处的服务器、所处的状态等为分布式服务所必须的数据。

同样，因为用户登录后会被导向到自己数据所在的服务器，所以，在设计完整的系统时，也必须考虑到认证系统和服务系统不在同一台服务器上的问题。如session的应用、cookie的应用等。

服务器间必须有良好的数据迁移机制
就像news和bbs的feed所解决的问题一样，在用户在两个数据网间漫游时会充分的感受到服务响应跨网的极慢响应的感觉。当用户漫游时必须允许用户将自己的个性化信息数据在两个数据网间进行迁移。需要设计一个良好的迁移机制，这样的机制主要考虑的问题如下：
1.迁移数据的可靠性和完整性
2.迁移数据时用户的操作所带来的服务暂停或是服务不可用的情况
3.迁移数据的粒度
4.迁移数据的速度
不同的应用和业务会有不同的侧重。只能按系统逐一考虑，不能一概而论的。

对于统一认证的数据必须能有良好的同步复制机制，保证在各数据网间的同步
对于用户认证的数据由于其覆盖全部数据网络，所以要保证其在各数据网间的同步。因为用户可能会通过任何一个数据网来登录到自己的服务之上，所以需要尽量及时、尽量完整的将认证数据部署到所有的数据网中去。到现在为止我们可以看到各大互联网服务提供商在服务未到之前，用户认证系统的部署都会先行进行的。yahoo、hotmail这样的大规模用户认证系统是SDN的基础的基础。

对于业务层面来讲，服务一定是个性化的
从业务层面一定要考虑什么样的服务数据是个性化的，什么样的数据会是全局的。做这样的重要决策是基于将什么样的数据加入全局的各数据网同步数据中去，什么样的数据与服务同行，分布在各个服务器上。这样的决定差不多每天都会去做，只是刚开始只会比较迷惑，后面会越来越清晰自己的需要而将数据分布到不同的系统上去。