基于MongoDB的高并发高可用政府云平台架构实践

MongoDB (2.0万) 2017-03-26 22:29:32

3月12日下午在阿里巴巴西溪园区,举行了MongoDB杭州用户交流会。微软MSDN特邀讲师徐雷分享《基于MongoDB的政府云平台高并发高可用HA架构实践 》,从自身实践出发,讲述了政府云平台分层、技术栈选型、物理架构、API架构及DB数据库架构的设计思路和方法。

以下内容根据现场分享和演讲PPT整理而成。

学习MongoDB的重要性

目前,几乎所有国内外的互联网大公司都在用MongoDB,学习企业需要的技术很重要。

MongoDB优点

基于MongoDB的高并发高可用政府云平台架构实践 (https://www.tiejiang.org/) MongoDB 第1张

相比较关系型数据库而言,MongDB有两个明显的优点:灵活的数据模型和便于横向扩展。

灵活的数据模型:作为一位网站开发者,最痛苦的就是需求变更,MongDB可以接受字段的不断修改,非常灵活。

便于横向扩展: 如果有海量数据存储,这时可以做Sharding,非常容易,这个是MongDB本身已经支持的。传统的关系型数据库在这一块比较难实现,因为它会由很多固有的设计缺陷导致。但传统关系型数据库的分片思想和MongDB分片思想其实很像,从算法的角度来说,没有太大区别,比如基于范围进行分片,这两个是通用的。

高并发与高可用架构关键点

程序员一般追求高并发,对于高并发这个关键词容易产生兴奋点。作为架构师设计一个架构,如果要支持某个级别的并发,一定要注意:不是用Redis就是高并发,不是用MongDB就是高并发。高并发高可用架构关键点包含:多线程、分布式通信RPC、集群、负载均衡、网络与硬件、监控与诊断等。比如Java有多线程、高并发的问题,如果涉及到分布式通信RPC 、分布式架构的话,一定会有一些RPC的技术,会有线程通信、进程间的通信出现,这些在不同框架中都有对应的实现。架构师在设计架构时,需要深入研究。

集群:是不是一定要用集群?不一定。一般小规模公司才用3-5台服务器,大规模公司用128G、256G、甚至2T的服务器内存,连数据和索引都进服务器。MongDB在数据量非常大的时候,比如你有16G内存,发现它很慢,有一个很重要的问题,稍微研究下底层的算法,会发现MongDB在使用索引结构进行数据查询的时候,它需要对索引进行遍历,如果能整体进内存最好,如果不能整体进内存,它就部分加载,这样的话就更慢,因为涉及到一个磁盘内存问题。

负载均衡:假设用了集群,比如有10台web服务器,需要做负载均衡,可以用业内比较成熟的实现方案,比如阿里云、微软云、亚马逊云,直接配置就可以用。如果要构建私有云,或者数据中心的话,需要想一些负载均衡的方案。比如业内比较流行的,软负载均衡,反向代理负载均衡。

网络和硬件:这也是高并发的前提。比如10w并发,平均一个消息多大,估算一下网络流量,不要说不管带宽是5M,还是10M,就要10w并发,这需要看硬件的服务器配置,所有的高并发一定是个完整的体系,不是说在某个点上,写段代码就高并发了。所以现在看到的高并发系统,一定是经过无数次的迭代。

监控与维护:这是运维最头疼的。因为运维每天晚上需要远程登录看机器正常不正常,影响正常休息,所以现在也提出了自动化运维概念。

政府云平台背景
基于MongoDB的高并发高可用政府云平台架构实践 (https://www.tiejiang.org/) MongoDB 第2张

政府也需要进行转变,他们希望把整个政府平台信息化,构建统一高效的政府云平台。比如税务的信息化、公务人员考核的效率化等。

基于前面说到的,设计的架构一定要微观上+宏观上高并发,不能说了搭了几层就是高并发架构,首先要看写的代码,如果在后台就产生了大量问题,大量bug,怎么能够高并发,从前端到后台是一条链,任何一个节点出问题,都会影响整个系统架构。

政府云平台分层架构图基于MongoDB的高并发高可用政府云平台架构实践 (https://www.tiejiang.org/) MongoDB 第3张

从上图显示,这个架构系统不是只有关系型数据库,或者NoSQL数据库。因为这个场景是比较特殊的。对于政府官员考核的指标比较多,每个指标量化单位不一样,考核数据模型是会变化的,会导致数据的不确定性。这个时候比较适合用NoSQL,如果用传统关系型数据库的话,开发就需要天天改数据层的表。

参考上图,我们做的技术并不仅仅是一种技术,需要考虑传统PC端,也要考虑移动端的问题。这里作为服务治理层,或者服务层,这里服务治理层不仅是服务层,因为希望对服务做一个统一的规划和安排。另外希望后期加一些自动化运维和监控的知识,包括现在比较新的微服务的概念,这是设计的思路。

协议的话,也没有固定只用http这一个,也没有只用soap协议。可能大家会说因为你对 SOA 架构比较熟,但其实今天所有的系统架构,这个叫SOA的概念已经存在。不是说用哪个框架,就一定能解决问题,不推荐这种方式。如果涉及到移动端,可能会用到MQTT协议,如果是页面应用的话,可能会用到最新的web socket。

业务逻辑层上,分层不是越多越好,而是根据需要分层,分完层之后是否方便后期扩展。比如业务逻辑层,Java和.NET里面都有分层的思想,这个部分把业务逻辑独立出来,不影响其它层。需要注意一下,这里用到Redis,前面讲过高并发的系统应用,Redis我们推荐。如果公司有能力开发一套缓存系统可以开发,比如阿里巴巴的RocketMQ消息队列,如果开发不了,就用开源成熟的产品。Redis目前是最流行的开源的免费缓存,它属于NoSQL的范畴,这两个结合和MongDB不冲突。MongDB能够解决10000个并发,一般公司够用。如果遇到峰值的时候,可以用兔子消息队列,让其帮助从中加一层,来缓解数据库压力。缓存技术除了加速以外,还可以充当请求缓存池,用于处理一些不太着急的请求。

再说一个问题,这里不论是Java和.NET,连接数据库的技术都是差不多的,都有连接池,都有多线程,而且垃圾回收的机制也差不多。同样如果想对传统型关系数据库或者NoSQL数据库做研究的话,可以看下NoSQL并发有很重要的问题,传统关系型数据库是不强调事务的,但是传统的NoSQL数据库,从诞生之初开始,高并发是它很重要的一个特点。目前NoSQL也开始支持事务,但是部分事务,不完整。关于MongDB有很多坑,因为它有几个存储引擎,这个有点像MySQL,MySQL也有几个开源的存储引擎,每个存储引擎都不一样,要用这个数据库的话,需要注意使用版本、存储引擎,需要在官方文档上确认一下。

政府云平台技术栈选型

基于MongoDB的高并发高可用政府云平台架构实践 (https://www.tiejiang.org/) MongoDB 第4张

Java底层和.NET底层原理是相通的,数据结构的算法基本上一样。但为什么有些是Java做的,有些是.NET做的,这里面我们会用到。反向代理考虑到尽量是免费的,节省成本。涉及到一些日志框架,建议用最成熟的框架,这里没有平台或者语言系统的偏见。用Docker方便运维。

政府云平台SOA架构设计

基于MongoDB的高并发高可用政府云平台架构实践 (https://www.tiejiang.org/) MongoDB 第5张

现在有手机定位,自动驾驶,政府也在考虑这些问题。比如政府希望看到各省县长的履历,进行优先提拔;比如要防控房地产的问题,房价波动厉害,需要了解房地产的交易资金,房地产大数据等,任何一个指标政府都希望能看到。SOA叫做面向服务的架构,是基于服务来集成现成的系统,这个架构没有过时。

政府云平台新SOA架构:ESB+微服务

基于MongoDB的高并发高可用政府云平台架构实践 (https://www.tiejiang.org/) MongoDB 第6张

这些架构如果开始做的话,两个系统直接服务集成,后面更复杂的问题来了,像阿里巴巴自己做了一个服务框架叫Dubbo,它里面有服务治理的事项,也有微服务的特点。作为一名技术人员,一定要注意它的试用场景,如果没有这些框架,能不能做个类似的功能?

这里面涉及到一个问题,如果后期系统特别多,最好有一个中间件平台的概念出来。这样在服务治理的过程中,可以更好的规划系统架构,而不是所有系统之间随便连接。随便连接的后果是,后期所有系统接口都是乱的,系统越多,乱的越厉害。比如早期是webservice,有可能后期改成TTP,或者改成HTTP等等一些新型的协议。

另外,这还涉及到高并发高可用的问题。网站选一个高并发的框架,在网站上要求1w个并发,一台服务器支持1w/秒的并发,接下来你想要10w的,一定要想办法进行横向扩展,当然如果企业特别有钱,可以把服务器换成1T的内存。还有一个高可用指标,比如每秒是1w个并发,更新一下直接挂掉,这是不行的。

省级单位政府云平台物理架构

基于MongoDB的高并发高可用政府云平台架构实践 (https://www.tiejiang.org/) MongoDB 第7张

物理架构和逻辑架构不同,逻辑架构可以分10层、100层都可以,但不是分层越多越好。分层越多,解耦越厉害,越影响性能。很多人不管设计什么架构,先分个三层,不管需不需要,直接把接口用webservice包容。这里一定要根据需要做判断。

MongDB做集群,做高可用。首先,保证物理安全,服务器不要坏掉;然后,MongDB可以支持数据直接加密,金融数据不安全的话,数据永久加密。MongDB3.4版本之后加了金融的数据类型。

MongDB可以做可复制性集群,这里可以一对多,但是有个问题,它可以实现自动化过程转移,如果说数据访问层开发的比较好的话,使用了较新的驱动,无论是Java还是C sharp ,它可以自动化来切换。在这个集群中,它自动会找一台新的节点出现,来替代主节点。这是相对于传统数据库MongDB做的好的地方。作为运维只要把web关系层配好,就不用担心哪台服务器在服务,直接可以自动化切换,图片服务器和缓存服务器,也不是所有的数据都进缓存,有部分数据为了缓解压力,把用户资料的数据可以放到缓存里,这样可以从缓存里拉所有数据。

负载均衡的话,用硬件软件都可以,负载均衡如果只用一台服务器,风险较高。CDN从单数据中心扩展到多数据中心也可以,一般公司还用不到多个数据中心。

政府云平台服务治理API架构设计

所有系统上线之后,不是简单的开发和发布,后期系统需要跟其它平台进行对接,会有一个服务组件的中间件平台,可以用开源的,也可以用商用的,比如Oracle、SAP、微软、阿里巴巴的中间件平台。中间集成可能会有不同的协议,这里面会涉及到很多问题,Redis后面可能会换成消息队列,比如一个5年考核指标,一个月内的数据量比较大,这个时候数据库肯定要持久化,有些内容放到MongDB,有些会放到传统的关系型数据库里面,需要提前做一些预测。再注意一个问题:这里的数据web层和访问层,全部都是集群。Redis也是支持集群。

系统上线之后,要看哪些系统出现异常了,什么样的异常是需要马上解决的,这里面涉及到服务监控的问题,需要配合专门的运维工程师制定一些规则。

另外,缓存在UI层就有了,API这层也可以有缓存,不是所有的东西放到Redis里面才叫缓存,Redis属于分布式缓存,有些数据可以放到数据持久层,比如关系型数据库,MongDB也有,服务器只要配置够高,数据直接进数据持久层缓存或者数据访问层缓存也可以。如果单独加一层缓存也可以。像中间件平台也有独立的缓存,API层也有。从架构角度来说,要想下缓存放在哪层比较合适,相应的硬件配置要跟的上。当然,越接近客户端的缓存,效率越高,因为它的物理位置更接近客户端请求。如果放在最下面,说白了中间要经过很多层才能到数据这一块。

省级单位政府云平台DB数据库架构

政府系统,首先物理上保持隔离,再保证安全。要注意的是,峰值出现的时候,需要加一层缓存或者消息队列。

政府系统的数据量规模是有限的。小规模系统可以用可复制集群,保证数据库节点的自动化灾备转化就可以了,这样的好处是:首先,读写分离把压力分担了;另外,如果出问题,可以自动化灾备、自动化切换,避免手动修复,或者宕机带来的一些问题。

缓存数据服务器最好用两台。比如支付宝,新浪微博做的比较成功,大量数据放在缓存里。缓存也有读写分离。一些互联网公司的测试数据显示,Redis的并发能达到每秒11w,所以它很适合做数据持久层的这一套缓存机制,无论是传统关系型数据库,还是MongDB,用普通的SSHD,每秒只有1w写入量的话,可以把数据先写入Redis,这个并发高,基本上10w的并发,能够满足绝大多数互联网公司的需求,如果还不行,可以写入的数据量少一点,再做读写分离。

政府云平台架构设计考量

基于MongoDB的高并发高可用政府云平台架构实践 (https://www.tiejiang.org/) MongoDB 第8张

推荐阅读

《MongoDB实战》

《jQuery 实战》

基于MongoDB的高并发高可用政府云平台架构实践 (https://www.tiejiang.org/) MongoDB 第9张

THE END

发表评论