contenu
- fond d'affaires
- Points faibles lorsque les centres de données multiservices ne sont pas introduits
- Idées de conception d'architecture de centre de données
- Conception de l'architecture de stockage des données du centre de données
- Mécanisme de sauvegarde et de récupération des données hors ligne dans le centre de données
- Résumer
fond d'affaires
Aujourd'hui, je voudrais partager avec vous l'architecture de centre de données que nous avons conçue pour plusieurs équipes commerciales de l'entreprise.Comment il est parti de l'analyse de la situation actuelle des données de plusieurs équipes commerciales étape par étape, puis a progressivement évolué vers la conception une architecture de centre de données J'espère que cela peut aider tout le monde à construire une compréhension systématique du concept populaire de centre de données.
Tout d'abord, laissez-moi vous dire quelle est la situation de chaque équipe commerciale de l'entreprise lorsqu'il n'y a pas de centre de données. En termes simples, différentes équipes commerciales ont leurs propres systèmes commerciaux et un stockage de données indépendant. Il suffit d'accéder à vos propres données. dans votre propre système, comme le montre la figure 1 ci-dessous :
Figure 1
Points faibles lorsque les centres de données multiservices ne sont pas introduits
Mais ensuite, à mesure que votre système évolue progressivement, les exigences deviennent de plus en plus complexes, et progressivement, il y aura une situation où chaque système aura besoin d'accéder aux données des autres systèmes. Interface de données, laissez les autres systèmes appeler votre interface pour accéder à vos données, et vous devrez peut-être également accéder aux interfaces d'autres personnes pour obtenir les données d'autres personnes, comme illustré à la figure 2 ci-dessous :
Figure 2
Comment vous sentez-vous lorsque vous voyez la photo ci-dessus ? Vous sentez-vous confus? Car en effet, le système évoluant lentement, l'interface ouverte par le système A peut être appelée par les systèmes B et C, l'interface ouverte par le système B est appelée par les systèmes A et C, et l'interface ouverte par le système C est appelée par le système A et B, à ce moment-là, il y aura une scène très embarrassante, qui est le chaos, oui, je parie que si vous regardez l'image ci-dessus pendant 10 secondes, vous devriez toujours être très confus et n'avoir aucune idée.
C'est vrai, c'est donc en fait le plus gros problème. Chaque système d'entreprise est en fait une île de données, c'est-à-dire que chacun ne peut accéder qu'à ses propres données, puis les autres doivent accéder à vos données via votre interface, et enfin Cela conduit à des appels complexes relations entre les n systèmes de l'entreprise, ce qui entraîne à son tour une mauvaise maintenance du système et des difficultés d'exploitation et de maintenance .
Idées de conception d'architecture de centre de données
所以这个问题，我们设计了一个面向多业务团队的数据中心，这个数据中心的架构设计思想，就是通过各个业务系统的数据存储的变更监听，比如针对MySQL数据库就可以部署Canal来监听他的数据变更，然后把各个业务系统的数据都拉取到数据中台里统一存储，如下图3所示：
图3
接着数据中心可以提供两种数据访问模式，一个是主动查询接口，一个是被动监听MQ通知，也就是说，对于数据中心来说，你各个业务系统都可以调用数据中心的接口，直接获取你想要的其他业务系统的数据，同时数据中心也会把各个业务数据的变更通知发送到MQ，你也可以订阅你感兴趣的业务数据变更通知，如下图4所示：
图4
大家看到上面的架构设计图，是不是瞬间感觉世界一下子就清净了？没错，其实在互联网公司里，对于多业务系统错综复杂的互相调用接口访问对方数据，往往会抽出一个统一的公共的数据中心来，让各个业务系统实现数据共享，这样就可以大幅度的提升我们系统整体架构的整洁性了。
数据中心的数据存储架构设计
那么再来给大家讲一下数据中心架构设计的另外一个关键点，就是他的数据存储架构设计，大家可以想一下，虽然我们的各个业务系统的数据存储基本都是以MySQL为主的，但是我们的数据中心的存储架构其实跟业务系统的需求是不同的，因为业务系统一般都是需要利用MySQL的事务机制实现复杂的业务逻辑，但是对于我们数据中心来说，本质仅仅是将数据同步过来，然后后续的重点是对外提供查询。
这是功能上定位的不同，另外一个不同就是数据量级的不同，因为我们的数据中心是存储所有业务系统的全量数据的，所以这就导致了可能各个业务系统的数据量级是百万级到亿级，而我们的数据中心他的数据量级可能是百亿级的，这是很大的一个特点，如下图5所示：
图5
所以最终我们的数据中心存储架构采用的是HBase+Elasticsearch作为核心架构，也就是说，基于HBase把数据以kv的格式分布式的存储在多台服务器上，写入的时候是kv格式，读取的时候也是kv格式，key就是数据的主键id，value就是一行完整的数据。
同时会为各个查询接口的查询条件，把要查询的字段值写入es里建立查询索引，让查询接口可以基于es中的索引先搜索数据主键id，然后根据数据主键id去HBase里查询完整的一行数据，如下图6所示：
图6
接下来给大家说一下这套架构下的一些技术难点和问题： 一个是hbase和es之间的一致性问题如何保证，也就是说，万一写入hbase成功了，结果写入es失败了，此时应该怎么办？这个时候其实应该设计一个补偿机制，也就是说，写入hbase成功，而写入es失败的时候，需要发一个补偿消息到mq里去，然后下次再重试做一个写入，实现最终一致性的效果，如下图7所示
图7
另外一个比较关键的生产架构经验就是多业务资源隔离，也就是要限制每个业务方对数据中台接口的访问量，否则可能会出现一个问题，就是某个业务方因为自身业务激增或者是业务bug，导致读数据中心的接口进行了瞬时高并发访问，一下子就把数据中心的请求处理线程都打满了，接着就没法处理别的业务系统的查询请求了，如下图8所示：
图8
所以说往往在这种情况下，我们必须在数据中心里设计多业务资源隔离的机制，就是说让每个业务系统接入接口访问的时候，最多就是使用数据中心里一部分的线程资源，超过这个阈值，就会限流，不允许这个业务方过量访问，如下图9所示：
图9
数据中心的离线数据备份和恢复的机制
接着我们还有另外一个重要的架构方案设计，数据中心现在是极为重要的是数据存储，因为所有业务系统的数据都会在数据中心内部进行汇总存储，然后各个业务系统都会强依赖数据中心提供的所有数据，所以如果数据中心要是出现数据存储故障甚至是数据丢失一类的问题，那就会导致很大的麻烦，因此我们设计了离线数据备份和恢复的机制。
也就是说，基于大数据技术将所有数据定时同步一份到hadoop集群中去，如果要是出现了hbase或者es集群的崩溃或者数据丢失，此时可以基于hadoop集群中的离线备份数据，把数据恢复到某个时间点，继续对外提供服务，如下图10所示：
图10
总结
好了，今天给大家分享的一个互联网公司的多业务系统数据中心架构设计就到这里介绍了，希望大家今天看了我们的架构设计思路之后，能够让大家未来在公司里遇到类似问题的时候，有一个整体的设计和解决思路。
END
扫码 免费获取 600+页石杉老师原创精品文章汇总PDF
原创技术文章汇总