SaaS 系统架构设计经验总结

2B SaaS系统最近几年都很火。很多创业公司都在尝试创建企业级别的应用 cRM, HR,销售, Desk SaaS系统。很多SaaS创业公司也拿了大额风投。毕竟SaaS相对传统软件的优势非常明显。

最近一年,有幸架构一个Crm SaaS 系统,上线了几个月来,各方面都比满意。整个系统创建过程,踩了很多坑,收获也比较多。总结一下SaaS系统架构一些特点:

1.分层设计

SaaS系统分层大概是:

租户识别>应用层>数据访问层>缓存层>数据库

  • 业务代码都是写在应用层。
  • 租户识别可以用spring拦截器实现,然后使用ThreadLocal传递给后端
  • 数据库和缓存层对应用层应该是透明的。程序员在写代码的时候,只关心业务逻辑,不应该担心多租户的问题。

2.数据隔离要透明

SaaS系统说起来很简单,任何系统似乎加个tenant_id(租户id)就变成SaaS系统了。比如原来的用户登录是:

  1. select username,password from users where email=‘[email protected]‘

改成

  1. select username,password from users where email=‘[email protected]‘ and tenant_id =1;

对于复杂业务的SaaS系统,这样做法非常危险,而且开发效率很低。你想想如果那个程序员写sql时候忘了加 “ and tenant_id =1” . 结果不堪设想。

比较好做法是在数据库访问层对SQL进行改写。

  1. TenantContext.exec("select username,password from users where email=‘[email protected]‘ ");

在连接池根据TenatnContext改写Sql.

这样做好处是,一来程序猿最多把系统搞down了,也不至于信息串了互相泄露。二来将来做分表分库也很方便,上层应用不用修改。

3. 租户识别方案

比较好做法是通过url识别租户。系统是给租户生成一个随机的三级域名,比如 abc.crm.baidu.com. 如果客户想使用自己的域名,可以在cname到我们生成的三级域名,并在管理系统里面做绑定。

这样一个租户可以有两个域名,访问SaaS,一个随机生成的三级域名,另外一个租户自己的域名.代码里面可以根据过来的域名,判断是那个租户然后初始化TenantContext.

如果不想通过域名来做,也可以通过登录名来判断。这种方式要涉及到租户切换问题。

4. 智能DNS

(以后补充。)

5. 租户管理系统(计费,订购,定制,充值,催缴)

SaaS系统是必须考虑计费系统和租户控制系统。这个系统需要都是独立设计。比如那个租户购买了那些模块,一个月多少钱。租户可以创建最多的用户数。计费到期邮件提醒等功能。

计费方式一般有两种,周期性计费,类似月租方案,和使用量计费,用多少付多少。 周期性计费比较简单。也可以两者结合起来。

6. 定制化开发

SaaS的优势在于一套系统多人使用,似乎和定制化开发有冲突。比如A客户想要A功能,B客户不想要。但定制化开发是无法避免的,比如CRM系统这样复杂的系统,不可能一套系统满足所有公司的要求。定制化开发尽可能分系统,分模块去做。然后通过控制台中配置不同租户订购不同模块,那些模块可以在前端页面上显示。不同的子系统需要分开部署。前端可通过nginx根据url分发,比如 abc.crm.baidu.com/bi/xxx/xx这个地址,就分发到BI子系统。不要尝试OSGI去搞模块化,这个是个大坑。

还有开发和产品,现有需求一定要分析清楚,不要一上线发现后患无穷。新功能尽量做的独立可以配置。

7. 灰度升级

SaaS付费企业客户对系统问题都特别敏感。 为了减少升级可能出现问题的影响范围,一般都采用灰度升级策略。如果使用了url来区分不同租户,灰度升级配置就会很方便。可以配置nginx 来根据域名做分发,比如租户A(aaa.com)到实例1(版本1.0),租户B(bbb.com)到实例2(版本). 当需要域名配置非常多的时候,nginx配置文档会乱。这块时候可以考虑使用nignx_lua来写一些扩展模块。

8. 容量估计

暂时先写这么多了。有时间再补充。

原文链接:http://www.cnblogs.com/codemind/

原文地址:https://www.cnblogs.com/itsharehome/p/8120500.html

时间: 2024-10-06 21:14:15

SaaS 系统架构设计经验总结的相关文章

saas系统架构经验总结

2B Saas系统最近几年都很火.很多创业公司都在尝试创建企业级别的应用 cRM, HR,销售, Desk Saas系统.很多Saas创业公司也拿了大额风投.毕竟Saas相对传统软件的优势非常明显. 最近一年,有幸架构一个Crm saas 系统,上线了几个月来,各方面都比满意.整个系统创建过程,踩了很多坑,收获也比较多.总结一下Saas系统架构一些特点: 1.分层设计 saas系统分层大概是: 租户识别>应用层>数据访问层>缓存层>数据库 业务代码都是写在应用层. 租户识别可以用s

SOA架构设计经验分享—架构、职责、数据一致性

阅读目录: 1.背景介绍 2.SOA的架构层次 2.1.应用服务(原子服务) 2.2.组合服务 2.3.业务服务(编排服务) 3.SOA化的重构 3.1.保留服务空间,为了将来服务的组合 4.运用DDD+GRASP进行分析和设计(防止主观的判断导致错误的假设) 5.SOA分布式下的数据一致性 5.1.分布式事务(基于DTC的分布式事务) 5.2.事务补偿(提供正向或反向的操作来让数据在业务上是一致的) 5.3.异步EDA(基于异步事件流来实现柔性的分布式事务) 6.总结 1.背景介绍 最近一段时

海尔电商峰值系统架构设计最佳实践

多数电商平台都会经历相似的过程,流量和业绩每年以几倍至十几倍的速度增长,每年都要接受几次大规模.全方位的系统检阅,例如双11.周年庆等购物狂欢节,期间流量和订单可能是日常的十几倍甚至几十倍,产生的峰值对平台形成极其强烈的冲击,对电商平台的架构带来巨大的考验.因此,对电商平台的规划和架构工作不仅要高瞻远瞩,而且要细致入微,否则将导致平台无法满足高速增长的业务发展,细微处的失误也可能造成严重后果,不仅影响业务指标的实现,还可能导致对系统进行重新架构,劳时费力又伤钱. 从2012年开始,海尔进入了网络

[转]SOA架构设计经验分享—架构、职责、数据一致性

阅读目录: 1.背景介绍 2.SOA的架构层次 2.1.应用服务(原子服务) 2.2.组合服务 2.3.业务服务(编排服务) 3.SOA化的重构 3.1.保留服务空间,为了将来服务的组合 4.运用DDD+GRASP进行分析和设计(防止主观的判断导致错误的假设) 5.SOA分布式下的数据一致性 5.1.分布式事务(基于DTC的分布式事务) 5.2.事务补偿(提供正向或反向的操作来让数据在业务上是一致的) 5.3.异步EDA(基于异步事件流来实现柔性的分布式事务) 6.总结 1.背景介绍 最近一段时

电商峰值系统架构设计--转载

1.1 系统架构设计目录 摘要:双11来临之际,<程序员>以“电商峰值系统架构设计”为主题,力邀京东.当当.小米.1号店.海尔商城.唯品会.蘑菇街.麦包包等电商企业,及商派.基调网络等服务公司,分享电商峰值系统架构设计的最佳技术实践. 自2009年11月11日,淘宝商城(现名天猫)拉开网购狂欢节的序幕,各大电商的促销浪潮此起彼伏.此时的电商大战不仅是价格之争,更是技术的较量.如何设计电商峰值系统来更好地满足用户蜂拥而至的访问,如何在海量数据处理中实时发现有效信息并转化为商机,成为众多电商企业密

5G 融合计费系统架构设计与实现(一)

5G 融合计费系统架构设计与实现(一) 随着5G商用临近,5G的各个子系统也在加紧研发调试,本人有兴全程参与5G中的融合计费系统(CCS)的设计.开发.联调工作.接下来将用几篇文章介绍我们在CCS实现过程遇到的挑战与架构设计的考量.相信这些宝贵的经验可以适用于更广的软件系统,免于重复地陷入软件开发的焦油坑. 5G系统由3Gpp定制统一的架构和协议规范,这也是电信行业一直以来通行的作法.不同的是,5G以前的规范3Gpp总是喜欢独树一帜,比如最出名的DCC(Diameter Credit Contr

Unity3D手游开发日记(2) - 技能系统架构设计

我想把技能做的比较牛逼,所以项目一开始我就在思考,是否需要一个灵活自由的技能系统架构设计,传统的技能设计,做法都是填excel表,技能需要什么,都填表里,很死板,比如有的技能只需要1个特效,有的要10个,那么表格也得预留10个特效的字段.在代码里面也是写死一些东西,要增加和修改,就得改核心代码,如果我要把核心部分做成库封装起来,就很麻烦了. 能不能做成数据驱动的方式呢? 改技能文件就行了,即使要增加功能,也只需要扩展外部代码,而不用改核心代码, 我是这么来抽象一个技能的,技能由一堆触发器组成,比

IM系统架构设计之浅见

背景:除去大名鼎鼎的QQ这款即时聊天工具,还有许多细分行业的IM,比如淘宝阿里旺旺.网易泡泡.YY语音.......恰巧公司产品也要开发一款基于我们自己行业的类IM系统,很有幸我担当了这个产品的架构师,核心代码编写.实现者.下面我近年来从技术上我对IM系统(即时消息的传输,不包括语音,视频,文件的传输)的理解和设计分享出来,浅薄之见,望大家别见笑,欢迎给出批评意见. 一.网络传输协议的选择 目前我知晓的所有IM系统传输即时消息无外乎使用UDP.TCP.基于TCP的http这几种协议中的一种或几种

秒杀系统架构设计

秒杀活动的用户量可能是网站平时正常访问量的数百甚至上千倍,网站如果为了秒杀时的最高并发量而设计部署,就需要比正常运营多的多的服务器,而这些服务器在绝大部分时候都是用不着的,浪费惊人.所以秒杀业务不能使用正常网站的业务流程,也不能与正常网站业务共用服务器,必须设计部署专门的秒杀系统. 秒杀系统所面对的技术挑战: 1.对现有业务造成冲击 2.高并发下的应用.数据库负载 3.突然增加的网络及服务器带宽 4.直接下单 秒杀规则是到点了才能下单,而下单页面也只是一个普通的url,如果得到这个url则不用等