阅读 1479

Spring Cloud在云计算SaaS中的实战经验分享


摘要

云帐房CTO张英磊基于自己的个人经验,分享Spring Cloud在云计算SaaS中的实战经验,希望能为大家带来一些思路上的帮助。

内容来源:2017年5月6日,云帐房CTO张英磊在“Spring Cloud中国社区技术沙龙-北京站”进行《Spring Cloud在云计算SaaS中的实战经验分享》演讲分享。IT 大咖说作为独家视频合作方,经主办方和讲者审阅授权发布。

阅读字数:2084 | 5分钟阅读

嘉宾演讲视频及PPT回顾:t.cn/RETMgVo

SaaS漫谈

SaaS模式是什么?

传统的软件模式是在开发出软件产品后,需要去客户现场进行实施,通常部署在局域网,这样开发、部署及维护的成本都是比较高的。

现在随着云服务技术的蓬勃发展,就出现了SaaS模式。所谓SaaS模式即是把产品部署在云服务器上,从前的客户变成了“租户”,我们按照功能和租用时间对租户进行收费。这样的好处是,用户可以按自己的需求来购买功能和时间,同时自己不需要维护服务器,而我们作为SaaS提供商也免去了跑到客户现场实施的麻烦,运维的风险则主要由IaaS提供商来承担。


SaaS多租户数据库方案

目前主流的SaaS多租户数据库方案有以下三种:


完全隔离:独立数据库,它的好处就是隔离度很高,但是占用成本也相当高,而且资源共享度低。

共享+隔离:可以共享数据库,但是有独立的Schema。这样它的各项指标相对来说都是比较平均的。

完全共享:共享数据库和数据表。我个人不太推荐这种方式,因为虽然它的共享度很高,但是几乎没有隔离度,而且开发上的复杂度会随着业务发展越来越高。

什么是Schema?

数据库中的Schema是数据库对象的集合。比如在Oracle中,一个用户一般对应一个Schema。

对MySQL来说,Schema并不是Database的下级,而是等同于Database。比如执行create schema test,和createdatabase test是一样的。

Oracle与MySQL的数据库层级对应关系如下:


独立Schema模式的优点和问题

独立Schema模式的优点:

高独立性:每个租户都拥有自己的库,与其他租户是隔离的;

高可扩展性:可以方便的进行横向扩展和数据迁移;

业务开发简单:开发时只需要考虑单租户的业务逻辑即可,通过切换Schema来达到多租户的效果,联查的表更少;

定制化服务:用户可以定制个性化服务,不影响其他租户;

独立Schema模式存在的问题:

1、数据库越来越多怎么办?如果有10万个租户,就有10万个库,单个服务器肯定无法承受。

2、如此多的数据库,如何进行表的更新与维护?

3、租户的数据都隔离开了,进行整体数据分析的时候怎么办?

分布式多租户数据库集群

为了解决第一个问题,我们采用了分布式多租户数据库集群。假设有10万租户,它们可以分布在不同的服务器上,而且每台服务器上的数量都不是固定的,可以根据业务量进行分布,必要时还可以进行租户迁移。


当租户分布开以后,可使用如下方式来定位租户:


数据微服务

第二和第三个问题,可以使用数据微服务来解决:


数据微服务可以专门用来处理新增Schema,更新数据结构、批量执行SQL以及统计分析等操作。

至于统计分析的时效性,租户通常只关注自身业务的统计分析,因此我们在面向租户时可以只对单个业务库进行实时统计分析,数据量一般不大。而我们后台对全局数据的统计分析通常时效性要求不高,就可以使用异步或定时任务处理,此时建议使用多个数据微服务来分区处理数据再汇总。当总体数据量大到一定程度,还可以引入Hadoop等大数据处理框架。

架构设计

微服务的拆分原则

微服务大体上有两种情况的拆分。第一种是根据业务功能进行拆分,微服务本身应该是高内聚的,微服务之间低耦合,微服务业务应该是单一的。

另一种情况就是从架构设计来拆分,是从基础组件、性能均衡和资源分配这三个角度考虑的。

业务架构设计


通常情况下,我们都可以拆分出许多通用业务微服务和基础架构微服务,现在假设我们有这样的通用业务服务池和基础架构服务池。首先我们可能有很多不同的系统,它们一些通用的业务就放在通用业务池里,但是它们本身也会有一些独立的特殊业务。那么我们既可以直接调用通用业务服务池里的API,也可以在处理特殊业务时调用其他业务微服务的API,而这些业务微服务也同样可以调用通用业务池里的微服务。

产品不是由服务组成的,而是由API组成的。服务就是服务,我们不一定要让它必须属于哪个产品,而是要把不同服务的API组合成一个产品。

下面是一个使用Spring Cloud的服务拓扑举例:


实战经验分享

配置集中化管理


前后端协作


通常使用swagger方式中存在的问题:

各类与业务无关的注解大量污染Controller代码,造成维护困难;

灵活性差,想要给特定人暴露特定接口(比如第三方)比较麻烦;

发布生产时需要特殊处理来关闭swagger;

Swagger有时会与其他jar包冲突(比如springfox-swagger2.6.0会导致注册Eureka异常)。

Spring Cloud + Swagger


开发未动,文档先行。正式开发前优先编写独立的Swagger微服务供开发人员参考,让Swagger回归文档本质;

项目初期,由Swagger微服务直接返回格式化的假数据供前端调试,方便前后端并行开发;

前后端联调时,前端可继续由Swagger通过Feign来调用后端服务查看数据,或直接连后端服务调试真实业务逻辑;

可针对不同第三方的需求,提供不同的对外Swagger微服务让对方调试,灵活暴露接口。

后端服务完全不引入任何Swagger代码,保持代码纯净,也避免了Swagger冲突,发布生产时直接关掉Swagger服务即可;


注意事项:

Swagger的接口路径、参数等必须与真正的业务接口保持一致,严格遵守规范,方便前端直连后端时统一修改;

Swagger微服务中需要有相应的VO,这类东西可以编写一次,到处复制。因此并不会增加工作量。

总结


技术并不是全部


我今天的分享就到这里,谢谢大家!