p**2
发帖数: 613 | 1 今天看的一片文章想起的，
比如说amazon的某用户的order页面可能包含了N个micro service calls
因为数量到一定程度的，所以就用api gateway处理所有的calls
然后后面再做区分，这个没啥问题。
但是说是user profile也是分了好几部分，
比如说first name/last name一个
birth一个
gender一个
...
大概这样一个说法，
那我个人觉得是不是有点分的太细了，
本来一个可以搞定的事情，分成了3个，
网络I/O用了gateway，就算内部处理吧，
那系统处理方面也是坑爹啊，本来一个query出的结果，变成了3个query，
觉得有点不解。
我个人想法是这些基本的信息，直接一个搞定，
对方只要name的，其他信息不用不就好了，
还是说其实也是一个query出结果后，放在cache层，
然后根据不同要求再返回结果？
这样玩过的大神说说大概是什么概念？
@古霸，听说你们一个api gateway搞定所有设备的micro service calls
是不是真的？ |
g*****g
发帖数: 34805 | 2 microservice是根据数据来划分的，最根本的划分有两个，一个是team，一个服务不应
该跨越两个组去维护，另一个是数据耦合度，如果服务A需要调用服务B，服务B需要调
用服务A，那么很可能本来就应该是一个服务。反之，如果什么东西都放在一起，很容
易引起数据库性能问题。所以，这是艺术，你要细分来避免数据库瓶颈，来避免服务太
大难以维护。但又不是越小越好。OO的核心思想high cohesion, low coupling在这里
可以体现。
对于user profile这东西，我认为name, gender这些是应该放在一起的。然而payment
的信息则可以放在另外一个服务里。两者的服务对象，安全要求，更新频率都很不同。
至于API gateway，是为了简化前端的开发，屏蔽无关的细节。比如后端几乎每个服务
都有读写，然而用户能写的只是很少一部分，需要读的还是很少一部分。大部分服务的
API都是low level，为了其他服务使用的，没有必要暴露给前端，也不需要做安全设置
。而API gateway需要暴露一些high level的API，对安全要求很高。
【在 p**2 的大作中提到】
: 今天看的一片文章想起的，
: 比如说amazon的某用户的order页面可能包含了N个micro service calls
: 因为数量到一定程度的，所以就用api gateway处理所有的calls
: 然后后面再做区分，这个没啥问题。
: 但是说是user profile也是分了好几部分，
: 比如说first name/last name一个
: birth一个
: gender一个
: ...
: 大概这样一个说法，
|
p**2
发帖数: 613 | 3 多谢回复，
是啊，我也觉得个人基本信息应该放一个服务，
要是说地址什么的分开也可以理解，
因为可能一个人对应multiple addresses。
payment
【在 g*****g 的大作中提到】
: microservice是根据数据来划分的，最根本的划分有两个，一个是team，一个服务不应
: 该跨越两个组去维护，另一个是数据耦合度，如果服务A需要调用服务B，服务B需要调
: 用服务A，那么很可能本来就应该是一个服务。反之，如果什么东西都放在一起，很容
: 易引起数据库性能问题。所以，这是艺术，你要细分来避免数据库瓶颈，来避免服务太
: 大难以维护。但又不是越小越好。OO的核心思想high cohesion, low coupling在这里
: 可以体现。
: 对于user profile这东西，我认为name, gender这些是应该放在一起的。然而payment
: 的信息则可以放在另外一个服务里。两者的服务对象，安全要求，更新频率都很不同。
: 至于API gateway，是为了简化前端的开发，屏蔽无关的细节。比如后端几乎每个服务
: 都有读写，然而用户能写的只是很少一部分，需要读的还是很少一部分。大部分服务的
|
