“转眼已经，距离微服务这个词落地已经过去好多年！（我记得年就听过这个词）。然而今天我想想什么是微服务，其实并没有一个很好的定义。
为什么这样说？按照微服务的定义：
微服务架构就是将一个庞大的业务系统按照业务模块拆分成若干个独立的子系统，每个子系统都是一个独立的应用，它是一种将应用构建成一系列按业务领域划分模块的，小的自治服务的软件架构方式，倡导将复杂的单体应用拆分成若干个功能单一、松偶合的服务，这样可以降低开发难度、增强扩展性、便于敏捷开发，及持续集成与交付活动。
根据这个定义，不难看出其实就是对复杂的业务系统统一做逻辑拆分，保持逻辑上的独立。
那么逻辑上独立，一个服务这样做真的就好吗，如何界定：小、独，还有要做一个事情，完成单一的业务，单一的功能要拆分出来，为了独立而独立会不会导致拆的过细？
不同人有不同的见解，我们今天一起探讨微服务的过去和未来。
微服务缘起
在没有微服务之前，我们最早的架构模式就是MVC模式，把业务逻辑分为：
表示层业务逻辑层数据访问层
MVC模式随着大前端的发展，从一开始的前后端不分离，到现在的前后端分离逐渐演进。
这种演进好的一点是剥离了不同开发语言的开发环境和部署环境，使得开发较为便利，部署更直接。
然而问题是：这种模式仍然是单体应用模式，如果有一个改动需要上线，你不得不因为这个改动去考虑更多，因为你无法估量在这么大体量的代码中你的一个改动会不会引发蝴蝶效应。
另外很重要的一点就是移动互联网时代的到来，引发了用户数几何倍数暴增，传统的单体应用模式已经无法支撑用户量暴涨的流量冲击，互联网人不得不做出加机器的无奈之举。
然而发现有的时候加机器都无法搞定问题，因为逻辑调用过于耦合导致调用链复杂。
继而出现精简调用流程，梳理调用路径的举措，于是演变出微服务这个概念。
其实在没有微服务这个词出现之前，我们也是这样干的，只是干的不彻底而已。
比如说有一个信贷系统，分为贷前，贷中，贷后三步：
在微服务未出现之前，我们大多是单体应用，基本上一个工程包含所有，无所不能，所以很臃肿。上述这些模块应该都是在一个工程中，但是按照业务做了代码上的拆分。
另外就是RPC框架横空出世，如果有服务上的拆分，比如不同部门之间调用对方提供的服务，那么八九不离十肯定定义的是HTTP接口，因为通用。但是某些时候大家又怕HTTP接口性能差，关键服务不敢用。
微服务出现之后，大家觉得按照模块分别部署好像是这么回事，同时默默在心里嘀咕，以前我只用发布一个工程，现在倒好，可能有个改动涉及3个服务，我一个小小的改动就要发布3次，是不是增加了工作量。
另外我以前都不用调接口的，现在依赖了一堆别的系统，系统调用这么复杂，万一别的系统有问题，我岂不是就被耽搁了！
在这种质疑中大家虽有抱怨但是也没有放弃赶时髦，微服务开展的如火如荼，用户中心独立部署，风控系统单独成型，支付中心全公司统一独立，财务系统不再各个业务各自为战而是统筹公司各个业务线统一规划。
按照业务抽象独立之后，大家发现好像是这么回事，用起来真香。虽然每次需要别的模块的时候就需要找对应模块进行接入，但是业务逻辑上清晰了呀，如果出了问题，不是自己的，那就是别人的，甩锅很方便的（笑）。
如何做微服务
因为微服务是功能粒度上的拆分，必然导致拆分之后的模块变多。
针对模块与模块之间的通信与维护，又演变出如下问题：
模块与模块之间如何通信每个被拆分的微服务如何做负载均衡服务如何做注册，如何做发现服务之间调用如何做限流，服务调用失败如何做降级，流量异常如何做熔断服务调用是否可以做统一的访问控制
针对这些问题，业界也在发展中慢慢演进出几套通用的框架。
理想中微服务框架应该具备这样的能力：
基于上述微服务框架应该具备的能力，我们来分析目前可以落地的微服务框架的具体实现。
目前国内用的最多的无外乎是两套框架：
DubboSpringCloud
Dubbo大家都很熟悉，从开源到无人维护再到重新冲击Apache顶级项目。
但是Dubbo更加准确来说是一个分布式服务框架，致力于提供高效的RPC远程服务调用方案以及SOA服务治理方案。说白了就是个分布式远程服务调用框架。
Dubbo
从Dubbo