作为架构师的你，有没有走入服务拆分的误区，你是不是也在为服务的拆分而苦恼？到底该怎么拆呢？公说公有理，婆说婆有理。

有人说服务拆分的越细越好，这样能更方便的进行服务原子组合，也能更好的进行复用。

有人说服务没有必要进行拆分，拆分多了，维护成本高，开发迭代慢

那事实到底是怎么样的？

要搞清楚这个问题，就要清楚微服务为什么产生的？微服务产生的是为了解决什么的问题而存在的？

在2010年前，大家很少听到微服务这个概念把，那为什么在2014年之后微服务又一下子就火爆起来，搞得好像你公司不使用微服务就是技术架构不先进一样，甚至有些企业内部没有使用微服务，对外也在宣称使用了微服务。

大家来看2014年是一个什么年代，在2010之后安卓手机和苹果手机开始流行，在2013年之后，小米公司将智能手机变成了人人都能用的起的东西，一下子移动互联网迅速铺开，一大批新型应用涌现，微信逐步取代了QQ，成为即时通讯的霸主，手机淘宝逐渐替换了PC淘宝，成为人们购物的主要场所，还有滴滴打车逐渐取代了传统的线下打车。整个业务的复杂度和用户群体激增，在移动互联网+的时代，涌现出了一大批企业，企业的规模迅速暴增，其中的代表有大家一直熟知的阿里、腾讯、京东等，也有后面迅速崛起的新起之秀，如小米、滴滴、美团等。

那么大家可以知道，微服务就是在这样的一个大的背景下，迅速火起来的，其主要的作用就是为了解决移动互联网+时代所面临的企业业务复杂度高，用户基数大，用户访问流量大的问题。

因此微服务需要怎么拆？如何拆？不就显而易见吗？

如果你的公司业务简单，没有用户，用户的访问也不大，微服务适用吗？很显然不太使用，单体应用应该更适合公司当下的发展

如果你的公司业务复杂，但是用户基数不大，用户的访问也不大，可以适当的按照业务领域进行拆分，但没有必要一个领域的东西，在拆分的过细。

如果你的公司业务复杂，用户访问量也很大，这个时候，可能考虑的不仅仅是按照业务领域进行拆分，还需要考虑按照流量进行拆分，要搞清楚那个场景下的流量是最大的，那些场景下的流量是可控，这样才能在流量上来的时候，游刃有余。

那简单的概括一下，微服务的拆分有以下维度

业务的复杂度：就是我们通常按照领域去划分，看有多少个领域

业务的流量大小（包含用户的基数）:也就是大家常说的性能问题

团队的规模：也就是你团队的人能不能hold住这么多的服务，一般人均5个已经是极限了。

机器的成本：简单来说就是打算花多少钱，服务拆的越多，可能部署的机器越多，成本可能也越高。

举个例子更好理解，比如你们公司现在打算做一个电商系统。如果你们公司的业务比较的简单，只需要用户能登陆、注册、下单、支付、发货，那么此时你们采用了一个单体应用完全能满足要求

随着你们公司的业务发展，用户不仅仅只是注册，登录，还需要延伸出了用户画像、用户等级、用户会员等等业务，这个时候随着延伸出来的东西越来越多，业务的复杂度也越来越高，很显然采用单体应用来迭代就有很多吃力了。

随着你们公司的业务越做越大，使用了你们公司的用户数越来越多，访问量也越来越大，用户层次也不太相同，比如有些是C端客户，访问有明显的峰值，有些是B端用户，有固定的访问频次（一般就是白天上下班期间）B端业务可能也存在着很多方便操作的批量处理、跑批的业务。而C端业务更多都是浏览，下单、支付这些偏简单操作的业务，这个时候你就发现很多时候的卡顿，都是因为B端业务的批量操作、跑批导致的，为了能够简单多场景下的用户卡顿问题，很显然是不是服务又要进行拆分了。

你看服务的拆分其实是很自然而然的事情，别一开始就大刀阔斧的拆，我看到有一些公司的业务很简单，但是就拆了出了100多服务，而研发人员总共加起来也不到10个人，我在想每天研发人员把这些服务打开一遍得花多少时间哈，还不考虑他机器能不能打开的了。所以微服务的拆分不是想当然，也不是按照照抄网上的一些攻略去拆的，而是要考虑自身的业务复杂度、研发人员的情况、业务的性能要求甚至公司在这边的机器成本要求。很多时候其实拆分是很自然而然。

这也是大家常说的架构是随业务发展不断调整和演进的，不是设计出来的，没有一种架构能适合公司的所有时候，只有相匹配的架构才是最好的。甚至有时候公司的业务在发展期，我们的微服务会随着的业务发展，不断的拆多，如果公司经历了发展期，正处于衰退期，那么我们的微服务也需要根据公司的业务发展情况合并。

所有的架构存在就有其合理性，不管是之前的单体应用，还是后面的微服务应用，还是Uber鼓吹的宏服务，其本质都是在适用当前的业务发展需要，不能简单的依葫芦画瓢。