微服务的好处有好多，易于扩展，发布简单，技术异构，便于重构等等，但今天我们的主题不是说好处，而是我们需要知道微服务同样也会带来痛，我觉得我们更要重视，提出问题，定义问题比解决问题更加的重要。
（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)耗费更多的服务器资源
有时候为了运维更好的定位问题，我们把服务各自分配到每一个节点上，同样这样就会耗掉很多的服务器。
总结：
