认识达内从这里开始

NoSQL架构是目前大多数软件编程开发程序员在开发软件的时候会经常用到的一种架构方式，我们在前几期的文章中给大家简单介绍了NoSQL架构架构的目的与应用的一些基础知识等内容，而本文我们就再来学习一下，多模型NoSQL模块结构包含哪些内容。

多模型NoSQL的模块架构中，我们分为数据面和控制面。数据面主要是指业务在线增/删/改/查请求路径上的模块;控制面是业务的控制台、运维系统，或者内部的定时任务维护处理所涉及的模块。

数据面模块架构，为方便长尾延时的管控和成本的控制，采用两层设计，服务一个请求后端多经过两跳，业务场景需求设计三类请求处理。

常规路径

请求到达接入层gateway，其查询本地缓存的元信息，并将请求转发给底层的存储模块cell，独立gateway部署方便于收敛前端网络连接数，以及业务前端不支持定制SDK的场景。

缓存路径

请求到达接入层cache，其查询本地的内存缓存，如果命中就直接返回，如果不命中，访问底层存储模块cell查询获取并通知cache主节点，由cache主节点根据预配置的缓存策略更新缓存并基于一致性协议同步更新给所有cache从节点。便于降低有明显热点效应的业务请求，降低访问成本。

定制路径

通过定制的sdk允许客户端直连存储节点，实现一跳访问，同时也可以将部分计算功能卸载到客户端上执行，有利于降低访问延时，减少计算成本。

控制面模块结构，控制面对外的访问入口有两个访问网关和三个内部部分。访问网关为userAdmin和sysAdmin，userAdmin是供客户控制台API访问的网关，sysAdmin是供运维系统访问的网关。内部三个部分分别是元数据的存储和分发、工作流Workflow和监控。

元数据存储和分发，主要是资源管理服务，包含资源管理服务(RM)和资源管理缓存服务(RMC)。元数据采用分布式的强一致存储，目前是五副本存储在CMongo中，未来会考虑闭环存储于自身系统里面。RMC是为了方便于元数据分发而设计的，数据面的gateway和cache服务启动后会注册到RMC，方便RMC做元数据的增量、推送、分发和一次性校验，通过userAdmin和sysAdmin网关访问RM，实现元数据的更新，RMC通过更新流感知到这个数据的变动，并推知元数据的更新给注册到自己的gateway和cache容器。

工作流Workflow，以往存储管控的实践中，通常是基于微服务架构设计数据迁移服务、数据巡检服务、数据调度服务、容量采集服务、数据冷备服务、资源上下架服务等众多的独立模块上来实现存储管控。虽然实现了较好的伸缩性，但模块多会增加开发、维护、运营、管理方面的成本。在X-Stor中，我们设计的是Workflow框架，搭积木的方式配置组装处理流程，实现可重入的执行。通过Workflow框架，结合容器化部署，共用一个Workflow服务来实现上述的所有功能，同时自动伸缩和容错，对所有的Workflow执行、日志存档和审计等能力也非常容易实现。

监控，通过在每个服务器Node的上面本地部署NodeAgent，实时汇集本Node上的各个容器的状态信息，并且推送给集群的Monitor服务。Monitor服务对接到Prometheus的存储、集群调度服务、监控报警组件如TEG智研监控宝等，可以方便地按集群实现实时调度和基于Grafana定制一个自己的可视化Dashboard。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。