你的项目真的适合微服务架构吗？微服务架构有哪些痛呢？（一）
在介绍业务场景之前，我们先来谈谈对微服务的一些理解。
一、单体式架构 VS 微服务架构
为了快速理解单体式架构与微服务架构之间的区别，我们先来看一个新零售系统的例子。
比如门店（门店分为自营店和加盟店）想研发一款新零售系统进行商品售卖，它需要包含订单、营销、门店、商品、加盟商、会员等功能模块。
在搭建新零售系统架构时，如果我们使用单体式架构进行设计，它的架构图如下所示：
从图中我们发现，单体式架构将所有模块的代码存放在一个应用中，所有模块的数据存放在一个数据库中。在这种架构模式下，当业务功能增加到一定程度，我们只要稍微有点小改动，就有可能影响整个应用的其他功能，这种事情在我们公司实在了发生太多次了。
虽然每次不小心把公司系统弄崩后，我们都会进行复盘总结，后期需要 Code Review、合理设计、仔细评估风险、一起评审方案，但是就算这么做了这种事情还是会发生。因此，随着风险控制流程的复杂化，代码发布的频率也就越来越慢，最终导致系统迭代不了了，而别家公司交付新功能的效率却是我们的 10 倍+。
面对这种情况，我们必须把各个模块的代码进行拆分，以免相互影响。于是我们把单体式架构拆分为如下图所示的微服务架构。
在上面的架构图中，我们发现 1 个应用被拆分为了 6 个应用，它们分别负责订单、营销、商品、门店、加盟商、会员等相关业务逻辑，且每个模块的数据分别存放在不同数据库中。如果各个应用之间彼此存在依赖关系，我们可以通过接口、消息、共享缓存、数据库同步等方式解决。
二、微服务的好处
将单体式架构迁移到微服务架构后，确实为我们带来了诸多便利，下面我们具体谈谈微服务的好处有哪些。
- 易于扩展： 某个模块的服务器处理能力不足时，我们在那个模块所处应用的服务器中增加节点就行。
- 发布简单： 在单体式架构中，因为所有代码存放在一个应用中，所以每次发布代码时，我们需要连带整个应用一起发布，使得整个团队人员都得配合集成测试、统一协调排期。但是迁移到微服务架构后，我们只需要保证对外契约不变就行，发布过程变得特别简单了。
- 技术异构： 因为各个服务之间相互独立、互不影响，所以我们只需要保证外部契约（一般指接口）不变即可，而内部想使用什么语言或框架都行。
- 便于重构： 在单体式架构中，因为系统重构的影响面较大，所以在做任何改动时我们都要小心翼翼，以至于我们不敢尝试大的重构或优化，最终出现代码加速腐烂的情况。但是在微服务架构中，因为我们把模块间的影响进行了隔离，所以大大增加了重构的灵活性。
三、微服务的痛
在产品研发过程中，我认为引入一个技术解决一个业务问题并不难，难的是我们能否合理评估技术风险，这个观点对微服务同样适用。因此，我将通过三篇文章来聊聊微服务会带来哪些问题，这部分内容不管是在面试中还是日常技术设计中，对我们的帮助都会非常大。
这一篇文章我们主要聊聊微服务的两个痛点，其他的痛点在后面的文章详细介绍。
（一）微服务职责划分
微服务的难点在于无法对一些特定职责进行清晰划分，比如这个特定职责它应该归属于服务 A 还是服务 B？为了方便理解这部分内容，下面我们举几个例子说明下。
- 比如一个能根据商品 ID 找出商品信息的接口，我们把它放在商品服务中就行。再比如单个用户的所有订单，我们把它放在订单服务中就行。
- 业务逻辑服务归属与业务人员的划分可能存在关系，比如每个商品在每个门店的库存应该放在商品服务还是门店服务呢？因为各自门店的商品库存由各自门店的运营人员管理，最终我们决定把它放在门店系统中。
- 业务逻辑服务归属与产品人员的划分可能存在关系，比如业务部门提了一个新需求，需要我们设计一个能对商品进行相关设置的功能，使得某些门店只能卖某些商品。此时这个功能应该放门店服务还是放商品服务呢？这就需要看这个功能由哪条业务线的产品负责人负责了，比如由商品系统的产品经理负责，我们就把它放商品服务中就行；比如由门店的产品经理负责，把它放门店服务中就行。
- 业务逻辑服务归属与工期可能存在关系，紧接着上面的例子——实现某些门店只能卖某些商品的需求，最终我们依据 DDD 中的相关原则定了一个划分逻辑，特定门店的特定商品的上架功能放在门店服务中，因为特定商品由门店的运营人员负责上架。但是这种划分逻辑会出现这么一个情况：比如门店服务的开发人员很忙，没空接这个需求，而商品服务的开发人员刚好有空，但他们对门店服务的逻辑不了解。于是，商品的开发人员提议，如果我们想在 2 周内实现上线这个需求，则必须把这个功能放在商品服务中。这种方案看起来比较诡异，不过最终他们确实把这个功能放在了商品服务中，因为再优雅的设计也抵不过业务部门要求的上线压力。
- 业务逻辑服务归属还与组织架构可能存在关系，通过康威定律我们就能很快明白。
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.
康威是个程序员，他在 1967 年提出：设计系统的组织在设计系统时，会设计出基于这些组织的沟通结构的系统。
关于微服务职责划分的痛，通过前面几个例子的介绍，大家应该隐隐约约有所感觉了，接下来我们再说一个进销存供应链系统的例子，让大家有更深刻的体会。
这里的进指的是供应商的采购，销指的是门店的销售单，存指的是一些中央仓库的库存，且进销存供应链系统与新零售系统之间紧密结合，对应的架构图如下所示。
在这个架构中，原本门店的商品库存是由门店运营人员（即新零售业务）负责，中央仓库库存由供应链人员管理。后来，不知什么原因领导要求更改供应链总监职责，此时供应链总监需要同时负责门店商品库存+中央仓库库存。
我们先来看看原职责划分情况，对应关系如下图所示。
在图中我们可以看到，在原有的组织架构中，新零售业务的产研只对接新零售业务，供应链业务的产研只对接供应链业务。现如今，门店库存管理职责需要划分到供应链业务中，也就是说新零售业务的产研不再负责这个需求，而是交由供应链业务的产研负责了。此时供应链业务的产研会把门店库存积极地搬运到供应链的库存管理中，因为门店库存管理好了，供应链业务方的绩效也就好了，产研的绩效也就高了，年终奖也就更多了。
因此，在现实场景中，微服务职责的划分会受太多人为因素的影响，我们也就能理解为什么市面上关于服务职责划分原则的相关资料太少了。
（二）微服务粒度拆分
在我所经历的企业中，发现大家都会遇到微服务太多的情况。因此，我们有必要通过一个加盟商的例子把服务粒度的内容详细介绍下。
还是以上面的新零售系统为例，刚开始系统只有登录和信息管理功能，我们把这些功能存放在一个服务中就行，实现起来比较简单。随着加盟商的加入，因为加盟商准入、开店、退出都涉及费用问题，因此我们又需要增加财务功能（如应收、应付、实收、实付、退款、对账等）。
随着业务的逐步开展，我们又需要增加加盟商员工管理（员工管理、部门管理、权限管理）返点、加盟商子门店管理等功能，而此时的加盟商管理系统只有一个服务，你觉得合适吗？答案肯定是不合适。那微服务的粒度到底拆分多少比较合适呢？比如什么时候拆分加盟商服务比较合适？做加盟商的财务功能时还是加盟商的员工管理功能时？做加盟商的返点功能时还是加盟商的子门店管理功能时？
一般来说，在设计新功能之前，我们会遵循一个大致原则：根据新的微服务的大小，安排 3-4 人设计即可。
但是当一个微服务设计出来后，它的改动成本一般不高，除非实现大规模重构，为了防止开发人员出现闲置的情况，公司会安排他们设计新的功能。而设计新功能时，开发人员倾向于将独立的功能存放在新的服务中，导致加盟商的财务、员工管理及返点功能都被独立出来了。为了避免这种情况的发生，因此，在对微服务粒度进行拆分时，我们还需要考虑另外一个因素——绩效。
**大家都知道，开发人员的绩效很难实现量化，而微服务数可谓是一个难得的可量化指标。**在规章制度上，虽然我们不会把微服务数列为一个 KPI（这样微服务数绝对会爆发），但是开发人员在阐述个人工作量时偶尔还是会提微服务数，如果其他同事听后开始留心，潜意识里也喜欢上做微服务，随着时间的推移，微服务就会越来越多，甚至出现人均 5 个服务数的奇葩情况。
说到这你可能想说，会不会是你们的微服务分得太细了？说得太对了，我们也是这样认为的，于是开始控制服务数，这种方式确实起到了一定的效果。
那服务的粒度大小控制在什么范围比较合适呢？我只能说没有确切的答案，需要根据实际业务情况来定。
四、总结
以上介绍的微服务的痛点是根据实际工作经历总结出来的，因此为了便于理解，每个痛点都会举一个实际的例子进行说明。其他的痛点我们后面继续聊。
感兴趣的朋友欢迎关注微信公众号：服务端技术精选
个人博客：http://jiangyi.cool