下载掌阅APP，畅读海量书库
立即打开
微服务是2012由Martin Fowler提出的概念，并没有严格的定义。从本质上来说，分布式经过前一轮的服务化后，应用本身臃肿复杂的问题已经得到了很好的解决。不过微服务则希望将其更进一阶。这里的重点就是“微”，即一个服务只负载一个独立的功能。此时，传统的“用户中心”服务，对于“微服务”来说，根据业务需要可能就需要再次拆分，例如针对电商场景，可能就需要拆分成“买家服务”“卖家服务”“商家服务”等。
至于到底需要拆分到多细，这里的原则便是，任何一个需求不会因发布或者维护而影响到不相关的服务，一切可以做到独立部署运维。当然，甚至可以拆分到一个独立的功能、一个服务，肯定就不会相互影响，这也正是 Serverless 思想所提倡的
。不过 Serverless 尚需要较多的基础服务支撑，而且还没有被主流公司接受，因此服务的拆分粒度，现在仍然是一个没有明确界限的事。
“微服务”所强调的不只是服务划分粒度上的“微”，同时对整个架构也有更高层次的要求。例如“微服务”希望远程调用协议是非常轻量级的，它不提倡使用像 Dubbo 这样的强语义协议，因为每种语言都需要一个针对性的客户端，而且客户端逻辑还比较复杂，甚至还支持编写Groovy 语言来自定义扩展。
广为大众所接受的Spring Cloud框架是微服务的典型代表。相对于传统分布式服务架构，Spring Cloud使用HTTP作为RPC 远程调用协议，配合上 Netflix 贡献的 Eureka 与 API 网关Zuul，其能做到细分内部服务的同时对外暴露统一的接口，让外部终端对系统内部分布式架构无感知。此外，Spring Cloud 的 Config 组件还将配置与上述各框架结合起来，让每个服务都可以非常简单地接入并配置系统。
综上所述，在我看来，“微服务”所强调的轻，其实就是反映工程师们普遍不希望分布式相关架构逻辑侵入业务系统的事实。在传统的分布式服务架构中，一个服务（应用）通常要非常多的配置才能正常工作，例如 Dubbo 需要填入配置中心地址、配置 Service 接口 XML 文件等，并且要求对方也接入 Dubbo 客户端才行，而 Spring Cloud 则只需要通过几个简单的注解即可完成对服务调用的声明，因为是基于HTTP的，即便是不同语言，也可以很好地支持。
纵观整个分布式发展史，微服务时期可以说是一个发展的分水岭，因为此时工程师们真正开始注意到架构本身带来的复杂性。在此之前，分布式都是往做多做细方向发展，例如之前“集群化”“服务化”“服务治理化”等一系列过程，都是一种架构扩展演进。而微服务在细化的同时，首次提出了“微”，即轻量级的概念，在此之后，分布式架构便进入了一个架构收缩的过程，因为其本身已经太复杂了，工程师仅是理解业务估计都需要好几天，因此需要让他们尽量少地去感知架构的存在，甚至做到完全无感知。
要知道，所有这些对于加班如家常便饭一般的工程师来说，那是一件非常幸福的事。