saas系统架构经验总结

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

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

1.分层设计

saas系统分层大概是:

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

业务代码都是写在应用层。

租户识别可以用spring拦截器实现,然后使用ThreadLocal传递给后端

数据库和缓存层对应用层应该是透明的。程序员在写代码的时候,只关心业务逻辑,不应该担心多租户的问题。

2.数据隔离要透明

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

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

改成

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

  

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

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

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/

时间: 2024-08-05 11:52:36

saas系统架构经验总结的相关文章

SaaS 系统架构设计经验总结

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

SaaS架构经验总结

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

可伸缩系统的架构经验

最近,阅读了Will Larson的文章Introduction to Architecting System for Scale,感觉很有价值.作者分享了他在Yahoo!与Digg收获的设计可伸缩系统的架构经验.在我过往的架构经验中,由于主要参与开发企业软件系统,这种面向企业内部的软件系统通常不会有太大的负载量,太多的并发量,因而对于系统的可伸缩性考虑较少.大体而言,只要在系统部署上考虑集群以及负载均衡即可.本文给了我很多启发,现把本文的主要内容摘译出来,并结合自己对此的理解. Larson首

[转载] 可伸缩系统的架构经验

原文: http://agiledon.github.io/blog/2013/02/27/scalability-system-architecture-lessons/ 最近,阅读了Will Larson的文章Introduction to Architecting System for Scale,感觉很有价值.作者分享了他在Yahoo!与Digg收获的设计可伸缩系统的架构经验.在我过往的架构经验中,由于主要参与开发企业软件系统,这种面向企业内部的软件系统通常不会有太大的负载量,太多的并发

系统架构师考试之备考经验分享

系统架构设计师考试偏重技术,想要通过考试,需要系统地去学习软件架构设计的理论,追踪业界架构设计的发展动态,对大多数考友有一定的难度,如果从考过的前辈们那里取取经,知道他们的过关秘诀,学习他们的备考方法,相信对大家有用处,下面我给大家整理了一位前辈的通关秘诀,希望能帮助到大家! 一.参加这次考试的原因 参加工作后,我一直都有学习新的知识,但是都是少有总结,阶段性的成果也不太明显.我日益地觉得要么有一些文档记录自己的心得.要么有一段程序实践自己新的知识.要么可以通过某一些考试证明学习的效果,这样才能

【软考】系统架构设计师(高级)考试经验回顾分享

首发地址 https://blog.leapmie.com/archives/503970b4/ 前言 全文以过程回顾为主,跳转到"备考攻略"小节可成功闪避唠叨攻击 早在2013年还在大三的时候便随大众考了「软件设计师(中级)」证书,时隔多年在2019年11月9日再次踏入软考的考场参加「系统架构设计师(高级)」的考试,最终结果是侥幸的以49/50/46成绩低分飘过. 由于当时备考时也没看见多少关于系统架构设计师考试的文章,所以既然难得通过了,那也顺手记录一下这个过程做个分享吧.考试过后

全栈软件工程师和系统架构师的异同

看完后.发现.不用怕....因为程序员不会看完.只有"架构师"才有耐心看这么长的. 一 每个好架构师都是一位出色的程序员(卓越的程序员) 架构师,听起来是如此神秘的一个称号.尤其是在开发领域刚入门不久的菜鸟级程序员眼中,架构师都是高手,都是牛人,都是如此高高在上的存在. 不过,在搞了四.五年编程之后,程序员们往往早已失去了当年对这些"高级"职位的神秘感,甚至会对自己所在项目的架构师抱怨不已,背后里称他们是一群水王.所以有江南白衣曾撰文述说:"国内的架构师到

HRMS(人力资源管理系统)-从单机应用到SaaS应用-架构分析(功能性、非功能性、关键约束)-上篇

一.开篇 上一篇<HRMS(人力资源管理系统)-从单机应用到SaaS应用-系统介绍>我们已经详细的分析了HRMS系统具备的功能,并且从HRMS系统的概念.系统功能.HR行业管理现状及痛点.发展趋势及行业前景.行业内的服务提供商情况.HRMS系统的建设意义及价值等方面进行了系统化的分析梳理.我想大家已经对于HRMS系统的大体情况有了初步的了解,本篇将对HRMS系统的需求进行全方位的梳理(功能性需求.非功能性需求.系统约束等),这对于HRMS系统的架构设计来说是核心关键,是架构能否成功的前提.这也

秒杀系统架构分析与实战

0 系列目录 秒杀系统架构 秒杀系统架构分析与实战 1 秒杀业务分析 正常电子商务流程 (1)查询商品:(2)创建订单:(3)扣减库存:(4)更新订单:(5)付款:(6)卖家发货 秒杀业务的特性 (1)低廉价格:(2)大幅推广:(3)瞬时售空:(4)一般是定时上架:(5)时间短.瞬时并发量高: 2 秒杀技术挑战 假设某网站秒杀活动只推出一件商品,预计会吸引1万人参加活动,也就说最大并发请求数是10000,秒杀系统需要面对的技术挑战有: 对现有网站业务造成冲击 秒杀活动只是网站营销的一个附加活动,