微服务的好处有好多，易于扩展，发布简单，技术异构，便于重构等等，但今天我们的主题不是说好处，而是我们需要知道微服务同样也会带来痛，我觉得我们更要重视，提出问题，定义问题比解决问题更加的重要。
（1）微服务职责划分
微服务的难点在于无法对一些特定职责进行清晰划分，比如这个职责归属于A还是属于B，举例如下：
- 一个能根据商品ID找出商品信息的接口，将他放在商品服务中，再比如单个用户的所有订单，我们就把他放在订单服务中
- 业务逻辑服务归属和业务人员的划分可能存在关系，比如每个商品在每个门店的库存应该放在商品服务还是门店服务呢？因为各自门店的商品库存是由各自门店的运营人员管理，最终我们决定把它放在门店系统中。
- 业务逻辑服务归属还与组织架构可能存在关系，通过康威定律我们很快就能明白
Conway’s law is an adage named after computer programmer Melvin Conway, who introduced the idea in 1967. It states that. organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.
康威是个程序员，他提出:设计系统的组织在设计系统的时候，会设计出基于这些组织的沟通结构的系统。
上面的例子说明，在现实的场景中，微服务职责划分会受到太多因素的影响。我们需要慎重考虑。
（2）微服务粒度划分
举例一个新零售系统，刚开始只有登录和信息管理。这些功能放在一个服务就行了，随着加盟商的加入，因为加盟商准入，开店，退出都设计费用问题，因此我们又需要增加财务功能，比如应收、应付、实收、实付，退款，对账等，紧接着又要对加盟商员工管理(员工管理、部门管理、权限管理等)返点、加盟商子门店管理等功能，而此时的加盟商管理系统只有一个服务，你觉得合适吗？
一般来说，在设计新功能之前，我们会遵循一个大致的原则：根据新的微服务的大小，安排3-4人设计即可。
在对微服务拆分的时候，我们还需要考虑另外一个因素—绩效。大家都知道，开发人员的绩效很难实现量化，而微服务可谓是一个难得的可量化指标。
虽然我们不能拿微服务数作为KPI，但是开发人员在阐述个人工作量的时候会提及服务数。然后潜意识里就会细化微服务的个数，所以我们需要控制服务数，这种方法也可以作为服务拆分的一个逆向操作。
（3）没人知道系统整体架构的全貌
不知道你有没有碰到过这种情况：每隔几个月或半年，大领导就会发话让我们汇报下每个部门的微服务数量、公司微服务总数量、每个微服务都用来做什么等情况。因为企业微服务数较多，所以每次给大领导汇报时，都是长长的一条清单。
在以前的公司，我首先会把公司的整个架构系统全貌搞清楚，之后一旦出现问题，也就容易定位故障点了。可是自从来到这家使用微服务的公司后，我便再也没有这样的冲动了，只要求搞懂自己的一亩三分地就行，如果出现问题临时学习一下相关系统就好了。
因此，在实际工作中，很难找到这么一个人，他能知道系统整体架构的全貌，这就是微服务的一个痛点。
(4)重复代码多
比如某个团队做了一个日志自动埋点的功能，它能自动记录一些特定方法的调用。但是第一个吃螃蟹的团队使用后，立马报出了一个 JAR 版本冲突问题，自动埋点团队又重新设计了一版埋点的 JAR，并去掉了一些特定 API 的使用，最终 2 个团队终于可以正常使用了。不过呢，第三个使用埋点的 JAR 的团队又汇报了一个 JAR 版本冲突问题，又开始重复了上面的操作。
后来我们复盘了下，得出结论：重用 JAR 本身没有错，错就错在我们使用的 JAR 版本太多了，必须改变这个局面。
不过，维护这些小小的重复代码总比统一排期做重构、统一评审 JAR 版本的成本低得多。
（5）分布式事务
分布式事务是微服务永久的痛，事务出错，是哪些回滚，哪些不会滚等等问题。
因此在这种情况下，大部分场景下我们不考虑回滚和重试，只考虑Happy Path，如果报错就记个异常日志，再线下处理。也是So easy！
(6)耗费更多的服务器资源
有时候为了运维更好的定位问题，我们把服务各自分配到每一个节点上，同样这样就会耗掉很多的服务器。
总结：
