微服务还没完全理解，宏服务又要来了？我太难了

当Uber公司某支团队宣布从微服务转向宏服务时，脑子瞬时飘来几个字“某种马”。微服务还没吃透呢，宏服务又来了，听到宏服务这个名字，脑海中好像是听说过，但是完全不了解。于是各种搜索，各种网站的信息翻了一遍。今天的主要目的是介绍为什么要使用宏服务？

image

一、先从微服务说起

因为不是专门介绍微服务，因此我们直接给出微服务的定义。 James Lewis与Martin Fowler是这样定义微服务架构风格的：

单个应用可以作为一系列小型服务的套件组合，其中每个小型服务都运行在自己的进程中，并且通过轻量级的机制实现彼此间的通信，这通常是 HTTP 和RPC。这些服务是围绕着业务功能构建的，并且可以自动化独立部署。每一种服务都可以通过不同的编程语言进行编写，并且可以使用不同的数据存储技术。

意思已经够简单明了了，假设是一个电商网站，注册登录就可以作为不同的微服务，他们相辅相成，又各自独立，共同为整个系统服务。这样来看微服务的优点不言而喻：

image

（1）每个服务都很简单，只关注于一个业务功能。

（2）每个微服务可以由不同的团队独立开发。

（3）微服务是松散耦合的。

（4）微服务可以通过不同的编程语言与工具进行开发。

这么明显的优点，不知道哪一个丛林深处的团队还未拥抱它。但是从github上的数据显示已经很明显了，基本上大多数公司不是已经用了微服务，就是还在使用微服务的路上。

不过凡事有利就有弊，微服务也不是十全十美的，这不就因为某些缺点，Uber就开始使用了宏服务。

image

下面我们再来看一下微服务有什么缺点：

（1）硬件成本高

五个微服务可能需要占据10个进程，如果要加入负载均衡和监控机制等等，需要的进程就更多了，这对于一些运维的硬件设施来说，成本真的太高了。

（2）需要DevOps

微服务的组织肯定需要DevOps ，毕竟微服务开发好了之后需要运维，这一下这么多进程，我们还要保证每个微服务都能流畅的运行，还要保证不能把空间消耗殆尽，也就是说运维起来要保证时间和空间效率。

（3）复杂性

多个微服务就意味着是一种分布式系统，既然是分布式系统就不可避免的带来复杂性和其他若干问题，比如说“网络延迟、容错性、消息序列化、不可靠的网络、异步、版本化、应用层中的负载变化等等”。

（4）测试成本高

无论是手工测试还是自动化测试，这么多微服务就需要都测试通过，而且微服务之间会进行通信，可能会带来更多的测试。

（5）代码重复

微服务中，可能有些功能是类似的，这也就意味着有些代码重复写了很多遍。

这里就先列出这么多，上面的这些缺点总结起来那就是一个系统拆分的微服务过多。各方面就开始麻烦起来。比如一个普通的电商网站，会拆分成几百个微服务。需要的人力、物力、财力都是很庞大的。正因为如此Uber的某个团队才舍弃了他。

image

既然微服务有这么多缺点，是不是说微服务今后就要被舍弃了，实时证明是Uber公司依然在使用大量的微服务，为此我还查看了他们的github。微服务的数量也一直在增多。但是我相信这是一个勇敢的尝试。

下面我们就开始今天的主题，介绍一下宏服务。

二、宏服务是个啥？

在创建新平台的时候，Uber 支付体验团队对新服务进行了更加深思熟虑的规划：不再只是完成一件事，而是使其服务于一项业务功能，由 5-10 个工程师负责维护。Gergely Orosz 把这样的服务规划称之为宏服务。

image

其实可以通俗地来讲，宏服务就是介于单体服务到微服务之间。宏服务关注的不再是某一个细节点，而是一个业务点。有一篇英文文献中这样描述宏服务：

宏服务应该定义为运行 2-20 个单独服务的应用程序体系结构，每个服务代表一个中等大小的代码库，可处理业务中定义明确的部分。宏服务的关键是拆分服务，最大程度地从拆分中获得收益，同时最大程度地降低运行多个服务的开销。

但是我觉得这篇文章有点问题，因为谁也不知道一个系统的业务点有多少个。因此宏服务的界限没有一个严格的定义。

宏服务既然是单体服务和微服务之间的折中，也就会带来很多的优点，比如运维成本会降低很多，既有了微服务的特点，又能在一定程度上解决了微服务的缺点。但是宏服务并非是比微服务更优的架构，只是架构演进中的不同选择。将来会不会出现这样一个宏服务框架，就由你或者他来设计吧！

image

OK。今天的文章先写到这。

image