Multi-tenant SaaS 的2种部署方式 - 未名空间MITBBS历史存档

Multi-tenant SaaS 的2种部署方式# Java - 爪哇娇娃

f*n2013-01-17 08:01

1 楼

做起来倒不算麻烦，就是画图纸画死我了~
本来又没啥美术和数学细胞，画KITTY头像，算纸板和布料长度什么的……
不过运气还算好，虽然有些地方算差了点，毕竟不织布还算有伸缩性，也还凑合~
开心呃开心~对了，帮我看一看，盒盖上需不需要加条丝带？谢谢~

M*02013-01-17 08:01

2 楼

各位做这方面的，你们公司用的是以下哪种方式，优点缺点各是什么？
1 让所有tenants用同一个application instance
例如application的名字叫MyApp(root url), 有N个客户A,B,C,etc
部署以后的URL是
对A公司用户 Http://hostname/MyApp/../A/../..
对B公司用户 Http://hostname/MyApp/../B/../..
对C公司用户 Http://hostname/MyApp/../C/../..
在runtime的时候用各种interceptor来决定用哪个bean implementation哪个jdbc
connection等等
2 给每个tenant deploy一个ear(can be in the same cluster or different
clusters)，在compile之后package之前，用ant等工具修改bean implementation（i.e
inject哪个class）, web.xml，application.xml， persistence.xml etc里的value
，部署之后URL是
对A公司用户 Http://hostname/MyApp-A/..
对B公司用户 Http://hostname/MyApp-B/..
对C公司用户 Http://hostname/MyApp-C/..
说说你们都是用哪种。第1种写代码的时候繁琐很多，经常要把tenant-name(A,B,C)传
来传去的，manually放到RESTful的url里（both consumer and service）或者http
header里等等；
第2种写代码容易(feel like single tenant)，但是因为deploy多个
application instances, 本来一个bean instance变成多了bean instances所以多消
耗了些memory and cup？

s*c2013-01-17 08:01

3 楼

好可爱啊～～
我觉得加丝带挺好看的，侧面就不那么单调了～～：）

【在 f******n 的大作中提到】

: 做起来倒不算麻烦，就是画图纸画死我了~
: 本来又没啥美术和数学细胞，画KITTY头像，算纸板和布料长度什么的……
: 不过运气还算好，虽然有些地方算差了点，毕竟不织布还算有伸缩性，也还凑合~
: 开心呃开心~对了，帮我看一看，盒盖上需不需要加条丝带？谢谢~

g*g2013-01-17 08:01

4 楼

通常你开发要用1，这样灵活性最高，运营成本最低。对于大的客户，可以给dedicated
cluster。
对于使用的区别，在SOA架构下，可以把不同的地方做成另外的service跑在不同的
cluster上，这样每个服务不用考虑多个客户。比如A客户可以调用UI和后端的M和N，B
调用的则是UI和后端的X和Y，这样UI那里只是薄薄一层。

【在 M***0 的大作中提到】

: 各位做这方面的，你们公司用的是以下哪种方式，优点缺点各是什么？
: 1 让所有tenants用同一个application instance
: 例如application的名字叫MyApp(root url), 有N个客户A,B,C,etc
: 部署以后的URL是
: 对A公司用户 Http://hostname/MyApp/../A/../..
: 对B公司用户 Http://hostname/MyApp/../B/../..
: 对C公司用户 Http://hostname/MyApp/../C/../..
: 在runtime的时候用各种interceptor来决定用哪个bean implementation哪个jdbc
: connection等等
: 2 给每个tenant deploy一个ear(can be in the same cluster or different

v*32013-01-17 08:01

5 楼

好可爱啊,我喜欢有丝带的^_^

【在 f******n 的大作中提到】

: 做起来倒不算麻烦，就是画图纸画死我了~
: 本来又没啥美术和数学细胞，画KITTY头像，算纸板和布料长度什么的……
: 不过运气还算好，虽然有些地方算差了点，毕竟不织布还算有伸缩性，也还凑合~
: 开心呃开心~对了，帮我看一看，盒盖上需不需要加条丝带？谢谢~

k*e2013-01-17 08:01

6 楼

JVM很快就会支持cloud了，对于客户来说，这两种办法都不好，而应该采取多个VM单独
部署。
现在有商用JVM支持cloud，资源共享，而不是VM互相独立。

b*u2013-01-17 08:01

7 楼

赞啊！！！很漂亮哦！！！
我觉得加上丝带好看~

【在 f******n 的大作中提到】

: 做起来倒不算麻烦，就是画图纸画死我了~
: 本来又没啥美术和数学细胞，画KITTY头像，算纸板和布料长度什么的……
: 不过运气还算好，虽然有些地方算差了点，毕竟不织布还算有伸缩性，也还凑合~
: 开心呃开心~对了，帮我看一看，盒盖上需不需要加条丝带？谢谢~

r*s2013-01-17 08:01

8 楼

multi-tenancy是个伪命题，
本来是为了通过省Resource省钱，
结果开发上维护上安全上要多花很多。
除非你的tenancy is as small as individuals，
某种意义上只要支持personalization
就是multi-tenancy了。

【在 M***0 的大作中提到】

: 各位做这方面的，你们公司用的是以下哪种方式，优点缺点各是什么？
: 1 让所有tenants用同一个application instance
: 例如application的名字叫MyApp(root url), 有N个客户A,B,C,etc
: 部署以后的URL是
: 对A公司用户 Http://hostname/MyApp/../A/../..
: 对B公司用户 Http://hostname/MyApp/../B/../..
: 对C公司用户 Http://hostname/MyApp/../C/../..
: 在runtime的时候用各种interceptor来决定用哪个bean implementation哪个jdbc
: connection等等
: 2 给每个tenant deploy一个ear(can be in the same cluster or different

a*y2013-01-17 08:01

9 楼

好可爱,更喜欢有个丝带:)

b*y2013-01-17 08:01

10 楼

Everything is the same.
In DB, except global tables, all other tables have a customerId column...

【在 M***0 的大作中提到】

: 各位做这方面的，你们公司用的是以下哪种方式，优点缺点各是什么？
: 1 让所有tenants用同一个application instance
: 例如application的名字叫MyApp(root url), 有N个客户A,B,C,etc
: 部署以后的URL是
: 对A公司用户 Http://hostname/MyApp/../A/../..
: 对B公司用户 Http://hostname/MyApp/../B/../..
: 对C公司用户 Http://hostname/MyApp/../C/../..
: 在runtime的时候用各种interceptor来决定用哪个bean implementation哪个jdbc
: connection等等
: 2 给每个tenant deploy一个ear(can be in the same cluster or different

l*r2013-01-17 08:01

11 楼

可爱可爱:)!

【在 f******n 的大作中提到】

: 做起来倒不算麻烦，就是画图纸画死我了~
: 本来又没啥美术和数学细胞，画KITTY头像，算纸板和布料长度什么的……
: 不过运气还算好，虽然有些地方算差了点，毕竟不织布还算有伸缩性，也还凑合~
: 开心呃开心~对了，帮我看一看，盒盖上需不需要加条丝带？谢谢~

M*02013-01-17 08:01

12 楼

这正是我发贴的原因，用方法1，写代码的时候麻烦很多，而方法2虽然多部署了几次，
但维护上并没多多少工作量和成本。一个developer每个月工资几千一万多块，我感觉
方法1得不偿失。

不懂，能详细解释一下吗，谢谢

【在 r*****s 的大作中提到】

: multi-tenancy是个伪命题，
: 本来是为了通过省Resource省钱，
: 结果开发上维护上安全上要多花很多。
: 除非你的tenancy is as small as individuals，
: 某种意义上只要支持personalization
: 就是multi-tenancy了。

m*g2013-01-17 08:01

13 楼

好可爱恩也觉得有丝带就更妙了

g*g2013-01-17 08:01

14 楼

There's an operation cost. With 1, you can easily scale up and down,
irregardless of tenants' growth. At the end of the day, it's management that
makes the call.

【在 M***0 的大作中提到】

: 这正是我发贴的原因，用方法1，写代码的时候麻烦很多，而方法2虽然多部署了几次，
: 但维护上并没多多少工作量和成本。一个developer每个月工资几千一万多块，我感觉
: 方法1得不偿失。
:
: 不懂，能详细解释一下吗，谢谢

n*82013-01-17 08:01

15 楼

心灵手巧

c*e2013-01-17 08:01

16 楼

if there is an issue with a tenant, it will bring down the whole.system. do
not like it from the perspective of isolation.

that

【在 g*****g 的大作中提到】

: There's an operation cost. With 1, you can easily scale up and down,
: irregardless of tenants' growth. At the end of the day, it's management that
: makes the call.

x*a2013-01-17 08:01

17 楼

好好好好可爱阿,尤其是加上丝带:)
请问楼主毛茸茸的布容易粘毛吗?

g*g2013-01-17 08:01

18 楼

A properly layered architecture should prevent this from happening. Sure,
bring down all customers is very bad, but bring down a customer completely
is bad enough. You have to make your system more resilient, not counting on
isolation.

do

【在 c*****e 的大作中提到】

: if there is an issue with a tenant, it will bring down the whole.system. do
: not like it from the perspective of isolation.
:
: that