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 的大作中提到】
: 各位做这方面的，你们公司用的是以下哪种方式，优点缺点各是什么？
: 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 的大作中提到】
: 各位做这方面的，你们公司用的是以下哪种方式，优点缺点各是什么？
: 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 的大作中提到】
: 各位做这方面的，你们公司用的是以下哪种方式，优点缺点各是什么？
: 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 的大作中提到】
: 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 的大作中提到】
: 这正是我发贴的原因，用方法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 的大作中提到】
: 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 的大作中提到】
: 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
|
|
