Redian新闻
>
Multi-tenant SaaS 的2种部署方式
avatar
Multi-tenant SaaS 的2种部署方式# Java - 爪哇娇娃
f*n
1
做起来倒不算麻烦,就是画图纸画死我了~
本来又没啥美术和数学细胞,画KITTY头像,算纸板和布料长度什么的……
不过运气还算好,虽然有些地方算差了点,毕竟不织布还算有伸缩性,也还凑合~
开心呃开心~对了,帮我看一看,盒盖上需不需要加条丝带?谢谢~
avatar
M*0
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?
avatar
s*c
3
好可爱啊~~
我觉得加丝带挺好看的,侧面就不那么单调了~~:)

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

avatar
g*g
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

avatar
v*3
5
好可爱啊,我喜欢有丝带的^_^

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

avatar
k*e
6
JVM很快就会支持cloud了,对于客户来说,这两种办法都不好,而应该采取多个VM单独
部署。
现在有商用JVM支持cloud,资源共享,而不是VM互相独立。
avatar
b*u
7
赞啊!!!很漂亮哦!!!
我觉得加上丝带好看~

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

avatar
r*s
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

avatar
a*y
9
好可爱,更喜欢有个丝带:)
avatar
b*y
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

avatar
l*r
11
可爱可爱:)!

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

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

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

【在 r*****s 的大作中提到】
: multi-tenancy是个伪命题,
: 本来是为了通过省Resource省钱,
: 结果开发上维护上安全上要多花很多。
: 除非你的tenancy is as small as individuals,
: 某种意义上只要支持personalization
: 就是multi-tenancy了。

avatar
m*g
13
好可爱 恩 也觉得有丝带就更妙了
avatar
g*g
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得不偿失。
:
: 不懂,能详细解释一下吗,谢谢

avatar
n*8
15
心灵手巧
avatar
c*e
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.

avatar
x*a
17
好好好好可爱阿,尤其是加上丝带:)
请问楼主毛茸茸的布容易粘毛吗?
avatar
g*g
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

avatar
L*e
19
赞耐心的mm
我总是懒得画,最后尺寸还要慢慢对,哎
avatar
c*j
20
好漂亮的首饰盒啊~~~我就是对首饰盒上瘾,家里一大推,可惜没一个是我做的,mm这
个盒子好漂亮啊,加上蕾丝缎带更精致了~~~mm怎么做的?我是手笨的人,可是看着这
个盒子很眼馋的说~~~
帮我打个分吧~~呵呵~~谢谢~~~
avatar
t*a
21
很好看
avatar
m*9
22
好看,喜欢丝带的
avatar
l*8
23
真可爱啊!!我也要学!!!
avatar
h*g
24
加丝带好看。
avatar
T*e
25
nice
avatar
j*8
26
好漂亮,加丝带更好!
avatar
w*y
27
好看!等明天我的材料到了,我也做一个!!
avatar
w*d
28
水啦~
avatar
k*t
29
mm做的好漂亮!就像商场里卖的。
加丝带更好看
avatar
M*n
30
是个女孩都会喜欢这么漂亮的DD。
相关阅读
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。