SOA的精髓在于面向接口做架构设计

SOA的精髓在于面向接口做架构设计




这里的接口指的是可远程调用的接口，RPC、JSON，或者某些二进制封装的协议




当然，一般情况下，基于HTTP/JSON的处理文本类型数据的性能已经足够好了




每个Web服务的提高者分为有状态和无状态两种，爬虫不需要保存状态，但是爬取的数据的存储需要保存状态




在支持分布式存储的NoSQL类存储系统中，我比较欣赏倍冗余的设计，或者是基于quota多数投票的写一致性协议




冗余增加了可靠性可用性，但是可能造成不一致，如果要求分布式环境下的强一致性则可能损伤性能，进而也就损失可用性




在分布式计算环境中维护一个虚拟的“集中式大脑”可能是个设计错误——这个“集中式大脑”需要查询多个源获取信息以便做决定




我倒是觉得，分布式计算环境中可以使用基于Agent的“多方协商框架”，正如机器学习中的集成学习等“多脑”技术




但是Agent作为计算的主体，需要一个可靠的支持运行时迁移的计算环境，虚拟化、容器等技术就是非常必要的了




在反爬虫领域，可怕的并不是某种机器/人的判别技术（如CAPTCHA），而是某种识别出bot但是不做声悄悄给数据“下毒”的行为




从量子力学的角度看，爬虫也只是信息系统的一个观察者，可能造成状态的“塌陷”，并不能完全反映信息系统的本身情况




设想某种基于不可变数据的存储系统，则可以实现某种乐观锁/MVCC的全局快照，但是分布式下的全局快照其实很困难，基本上没听说过具体的工业实现，只是理论学术阶段？




从实现简单的角度考虑，可把实现任意时刻的分布式全局快照简化为“基于点扩展模型的冻结操作”，逐步地快速停止所有写更新操作，然后就可以观察这个冻结状态下的数据不一致问题了




假如这个思想实施不了，则可以尝试串行log（WAL），也就是说，并发的写更新操作强制地通过串行log现成一个线性顺序的副本，本质上，这会导致状态的塌陷，可能无法定位某些特殊的分布式/并发问题




我有时候在想，Google的PageRank所需要的超大型稀疏矩阵的运算是如何在分布式MapReduce框架上实现的？也许这并不困难，关键是性能指标，以及为此所需要完成的系统底层的优化措施。。。