亿级海量数据SAAS系统架构实践经验分享

我们的应用场景是提供一套SaaS系统，一个在线商家结算的系统，规模十万用户实时在线。大家可能会觉得奇怪，这在互联网行业并不算很大的用户量，有什么难度吗？

相当少的用户量，其难度在哪里？

比如说淘宝的商家后台类似我们的商家结算后台用户，它的商家是千万级别的。但不同之处呢？

举个例子，譬如淘宝的商家查询订单界面，根本没有什么查询条件。用户只能筛选一个月，或者是一周的。而做过大型系统的人都知道，系统的复杂度和挑战性，就取决于它的查询条件。我们的数十万用户实时在线的查询系统，有50多个查询条件，你可以按照年月日、商家的类型、账单的维度等等进行查询，而且是实时查询。并且我们的系统每天产生亿级增量的数据，即1亿行单表。通常单表超过2G，我们就建议去拆分，所以亿级增量数据这本来就是一个难点，再加上实时读写，亿级大量复杂的分页查询，这就更难了。

最后，一个商家在月初有百万级别的数据导出，我们有10万用户，假设有一半的人月初导入百万明细，要怎么实现？怎么导出Excel？在服务器上生成Excel，再提供下载；还是实时生成这种数据流，输出去？这么干你会出大问题。

第一个挑战是亿级增量数据的存储。行业通用的做法就是分表、分库。而业务场景因为是结算系统，所以对实时性、一致性、完整性要求很高，结算系统少一分钱都不行。做过架构的都应该知道CAP定理：可用性、一致性和分区容错性，三个条件只能满足两个。对于结算系统来说，可用性、数据一致性的要求相当高。另外数百个应用部署的实例对数据库造成压力。假设有500个应用部署实例，500个机器都去连数据库，按每一个应用开20个数据库连接计算，这就有1万个链接，哪个数据库扛得住？可能有人会说采用多个数据库，这就会涉及到分库、分表。也有人说会有连接池，但是要注意，我们在这种复杂条件下执行查询，有的比较低效，可能需要执行几秒甚至十几秒，很可能会耗尽数据库连接。

高可用对结算系统来说，3个9、4个9是很基本的要求。我们的数据来源于第三方，同步到系统，然后用MQ来做实时的数据处理，当数据进入系统，我们要按我们的逻辑加工，所以它的业务逻辑非常复杂。对于涌入的数据，MQ解决了高并发的问题，但业务逻辑的复杂性依然存在，这就是系统面临的巨大挑战。

云原生微服务架构，是建立在容器基础上的DevOps，基于敏捷小团队的开发模式来做的微服务架构。

在我们的SaaS系统里，用户登录注册、到完成报价、出账单，横向的黄色版块是业务逻辑。要完成这样的业务逻辑闭环，在微服务架构上，第一，他会进入一个网关层，然后请求链接会分到各个业务系统。从用户注册、到业务员报价，每一块都是垂直独立的，有独立的应用、独立的service、以及独立的数据库存储。我们用集群微服务，去解决这样大型互联网应用系统的架构。

其中有一个网关层，网关层其实就是做简单的鉴权、负载均衡、缓存、请求分片与管理等类似的工作。在我们的大型微服务架构里面，它通常有几个特点：解耦、去中心化治理、去中心化管理数据。这套微服务架构是基于Spring boot进行开发，使用dubbo作为微服务框架、zookeeper作为服务治理平台、使用网关进行鉴权、负载均衡、缓存、请求分片与管理等工作的大型微服务架构系统。

在我们的项目中，集成了CAT，做到全链路监控。在服务治理方面，每一个应用在内部实现了RPC的框架，内部调用时，我们的服务就要明确定义：

要实现高可用，我们就用到刚才讲的微服务化之后，每一个应用——比如说SSO或订单service服务，就可以通过加机器的方式做到弹性扩容。

其实我们的业务也是从零开始，一开始实现了单体架构，等业务量扩大到一定程度才拆分成微服务。

当我们做一个做从零开始的系统架构，一开始就要注意开发框架，我们基于Spring boot，去后台的架构分层，至少要先实现RPC的架构，部署一个单体应用或简单分成前后台。等到后期业务量增长到一定的程度，在RPC框架的基础上去重新部署，凭借微服务架构的横向可扩去拆分工作，就不用大规模的重构了。

更多技术干货欢迎关注，点赞，收藏，转发，技术视频私信小编即可领取