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模式存在的问题：

一、数据库愈来愈多怎么办？若是有10万个租户，就有10万个库，单个服务器确定没法承受。

二、如此多的数据库，如何进行表的更新与维护？

三、租户的数据都隔离开了，进行总体数据分析的时候怎么办？

分布式多租户数据库集群

为了解决第一个问题，咱们采用了分布式多租户数据库集群。假设有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，这类东西能够编写一次，处处复制。所以并不会增长工做量。

总结

技术并非所有

我今天的分享就到这里，谢谢你们！