M***0 发帖数: 1180 | 1 各位做这方面的,你们公司用的是以下哪种方式,优点缺点各是什么?
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? | g*****g 发帖数: 34805 | 2 通常你开发要用1,这样灵活性最高,运营成本最低。对于大的客户,可以给dedicated
cluster。
对于使用的区别,在SOA架构下,可以把不同的地方做成另外的service跑在不同的
cluster上,这样每个服务不用考虑多个客户。比如A客户可以调用UI和后端的M和N,B
调用的则是UI和后端的X和Y,这样UI那里只是薄薄一层。
【在 M***0 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 各位做这方面的,你们公司用的是以下哪种方式,优点缺点各是什么? : 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
| k********e 发帖数: 368 | 3 JVM很快就会支持cloud了,对于客户来说,这两种办法都不好,而应该采取多个VM单独
部署。
现在有商用JVM支持cloud,资源共享,而不是VM互相独立。 | r*****s 发帖数: 985 | 4 multi-tenancy是个伪命题,
本来是为了通过省Resource省钱,
结果开发上维护上安全上要多花很多。
除非你的tenancy is as small as individuals,
某种意义上只要支持personalization
就是multi-tenancy了。
【在 M***0 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 各位做这方面的,你们公司用的是以下哪种方式,优点缺点各是什么? : 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
| b******y 发帖数: 1684 | 5 Everything is the same.
In DB, except global tables, all other tables have a customerId column...
【在 M***0 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 各位做这方面的,你们公司用的是以下哪种方式,优点缺点各是什么? : 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
| M***0 发帖数: 1180 | 6 这正是我发贴的原因,用方法1,写代码的时候麻烦很多,而方法2虽然多部署了几次,
但维护上并没多多少工作量和成本。一个developer每个月工资几千一万多块,我感觉
方法1得不偿失。
不懂,能详细解释一下吗,谢谢
【在 r*****s 的大作中提到】![](/moin_static193/solenoid/img/up.png) : multi-tenancy是个伪命题, : 本来是为了通过省Resource省钱, : 结果开发上维护上安全上要多花很多。 : 除非你的tenancy is as small as individuals, : 某种意义上只要支持personalization : 就是multi-tenancy了。
| g*****g 发帖数: 34805 | 7 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 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 这正是我发贴的原因,用方法1,写代码的时候麻烦很多,而方法2虽然多部署了几次, : 但维护上并没多多少工作量和成本。一个developer每个月工资几千一万多块,我感觉 : 方法1得不偿失。 : : 不懂,能详细解释一下吗,谢谢
| c*****e 发帖数: 3226 | 8 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 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 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.
| g*****g 发帖数: 34805 | 9 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 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 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
|
|