内容来自《从程序员到架构师》
在产品研发过程中，引入一种技术来解决一个业务问题并不难，难的是能否合理评估技术风险，这个观点对微服务同样适用。因此，本节将专门讨论微服务会带来哪些问题，这部分内容不管是在面试中还是日常架构设计中，对大家的帮助都会非常大。
微服务的难点在于无法对一些特定职责进行清晰划分，比如某个特定职责应该归属于服务A还是服务B?为了方便理解，下面举几个例子说明一下，微服务的职责划分是怎么演变成公司技术部门的陷阱的。
首先，微服务的划分原则都是很容易理解的。
1.根据存放主要数据的服务所在进行划分
比如一个能根据商品ID找出商品信息的接口，把它放在商品服务中即可。再比如获取单个用户的所有订单，把它放在订单服务中即可。
2.业务逻辑服务归属与业务人员的划分可能存在关系
比如每个商品在每个门店的库存应该放在商品服务还是门店服务？因为各个门店的商品库存由该门店的运营人员管理，最终可以把它放在门店系统中。
3.业务逻辑服务归属与产品人员的划分可能存在关系
比如业务部门提出一个新需求，需要设计一个能对商品进行相关设置的功能，使得某些门店只能卖某些商品。
此时这个功能应该放在门店服务还是放在商品服务呢？这就需要看这个功能由哪条业务线的产品负责人负责了，比如，由商品系统的产品经理负责，就把它放在商品服务中；由门店的产品经理负责，就把它放在门店服务中。
4.业务逻辑服务归属与工期可能存在关系
紧接着上面的例子——实现某些门店只能卖某些商品的需求。根据前面产品从属原则的划分逻辑，特定门店特定商品的上架功能放在门店服务中，因为特定商品由门店的运营人员负责上架。