数据集合类系统如何架构

以下内容来源于QCon某高可用架构群聊天记录整理

如果携程网想把旅游信息展示到另一平台上 平台和他们的系统数据对接，pull好一些还是post好一些？或者说一个系统只是把好多其他商家的数据集合展示到统一的系统上，这样的系统一般如何架构？

先回答第一个问题：数据对接是pull好一些还是post好一些，这里需要根据实际业务做权衡，如果平台系统很大部分是通过聚合第三方数据再展示，那么比较推荐让第三方post数据，自己设计统一数据规则接口。这种情况，需要考虑自身服务的稳定性了，预防第三方误调用，击垮自身系统。如果只有小部分内容聚合第三方，那就pull，比较好保证自己系统稳定性，不过最终还得把所有的数据转换成自己格式，需要自己开发团队做这块工作。

相比较而言，post时效性高，数据交互少，如果系统会需要各个源的信息，最终也不会只是展示那么简单。如果使用post方案，则需要在接入，数据，读取等方面做隔离，在接入使用mq可以提高吞吐，在读的时候用Cache抗。并且在前期需要考虑好数据存储和数据的量级，因为是第三方的数据，在存储的扩展性方面要有比较好的方案。

最终落地的方案可能是：

按业务隔离，不同的业务相互不影响，拆分子系统；
使用redis和kafka保障高性能，kafka主要一方面用到日志上 一方面用到缓解数据库并发上；
使用nginx和lvs保障高可用；
在后期所有数据进hbase然后用storm做数据流处理和分析

以上这些并不需要一次性做到位，不要过早优化，只需要有一些大的原则，比如隔离，扩展等。小系统会随着业务慢慢演变，最终会变成大系统。在演变的过程中，可能会需要读写分离、业务分布式，分服务，架构就是在这样演变的路上成长起来的。