微服务架构并不算是新鲜事物或者创新成果，虽然我们还不能确切的定义这一架构形式，我也没见过谁明确的定义这种架构形式。但是它确实是很早就出现了，并且可能是更早的时间就出现了。
       2011年5月威尼斯附近的一个软件架构师小组于首次提及提出“微服务”的概念，当时他们用这个词汇来描述自己近期研究项目当中所涉及的通用性架构机制。
        2012年5月，该小组作出最终决议，认为“微服务”是最适合的架构名称。
        2012年3月，James在《微服务-Java以及Unix方式》当中就此发表了一篇案例研究报告，而Fred George也几乎在同一时间进行了相同的工作。
 
        这一概念因软件作者Martin Fowler而流行，但是他并没有确切地定义出这一架构形式。当然与我而言或者说与大家而言这是很棒的，因为你可以畅所欲言，尽情发挥自己的创造力。事实上，现在对微服务架构的理解，也正是处于这样一种百花争艳的状态。当然这不是什么坏事，而是一种非常棒的状态，前提是你不能百花迷了心神。我们需要时刻保持清醒，保持自己对事物理解，探索的敏感和热情。
        在我们系统构建过程中，总是随着业务的扩展，第三方框架的引入，与外部系统的交互都会导致系统的规模越来越大。大家肯定也都遇到过一个系统的启动都要花费一个小时甚至更久，一个数据库的更新都要花费数个小时，一个服务的异常都会引动整个系统的崩溃等等问题。不得不说这是系统规模扩大后必然会遇到的问题，我将其称为系统的第一阶段业务功能的膨胀阶段，一个系统负责了太多的业务职责。通常我们会将这样的大系统按照业务拆分为数个规模较小的系统。系统拆分能很好的解决业务规模导致的系统复杂规模庞大的问题，但是也同时带来了第二个阶段的问题。为了各个系统之间的通信交互，通常需要在规模小的系统中引入很多第三方服务组件。比如为了和外部系统交互，我们可能会引入GRPC，dubbox，为了使用提高消费稳定性需要引入rocketMQ，为了缓存一些常用信息需要redis等等。此时系统就开始面临第二个阶段的问题，第三方服务组件导致系统复杂，变得不易维护，不易扩展，甚至部署，监控，扩容，定位都同时出现问题。面对第三方服务组件带来的问题，我们通常会将第三方服务组件封装称http接口服务，或者接入ESB数据总线（很多年前，架构师们喜欢这么玩，但是现在应该很少人这么干了，ESB的接入极大的限制了服务扩展的灵活性，而且现在使用dubbox等远程调用工具或者rocketMQ等消息队列工具，都能很好的完成数据总线的职责。）截止这里，其实我们的服务已经变成了一个个规模很小并且能独立完成一定的业务的小系统，这也就是我理解中的微服务。

         微服务最多只能有三层，三层是我能接受的极限。在微服务的演化过程中，系统所提供的服务越来越明确单一，系统所依赖的第三方服务组件也越来越规范。比如我理解中的微服务架构在最上游系统他不需要以来任何第三方组件，而是仅仅通过标准的HTTP协议来与外部系统交互，这样的系统规模即便是一个刚出学校的实习生都能很好的胜任业务功能的开发工作。在系统的下游通过标准http接口将redis，dubbox，rocketMQ等关键服务进行封装，上游的使用者完全不需要了解下有服务的实现方式。下游系统通常还包括外部系统（外部系统可以自行封装http接口，也可以通过dubbo接口为外部系统提供服务）。这样一来一个微服务系统架构，最多就只有三层。第一层是对外服务层，对外服务层直接为用户提供业务系统的各种业务支撑，第二层是中间件服务层，中间件服务层将自己作为服务的提供者比如redis或者rocketMQ，或者是对接外部系统层服务的封装比如dubbo；第三层是外部系统层，外部系统层自身可以为用户提供服务，同时也可以为其他系统提供服务。微服务三层架构，是我能接受的极限，层次再多就会导致系统混乱，问题定位负责，极端情况下，任何一个微服务的变动都可能影响到整个系统。

        我们可以通过一个简单的案例，来直观的认识为什么我对微服务的极限是三层。
比如有一天早上你饿了想去买个包子。原本是你在家里屯了包子馅，包子皮，蒸笼，燃气，而且你也会做包子，然后就做吧，这就是最开始的整体架构，所有的事情都会集中在一个环节。但是今天你不想出门，所以你点了外卖，外卖平台把单子派给了快递小哥，快递小哥拿着单子到包子店里买包子，包子老板看到单子后去买包子馅，包子皮，然后上笼蒸包子。买包子从下单，快递，买包子馅，蒸包子，每一个环节都是独立的，互不干扰的，这就是微服务的模型。我们可以看到微服务不需要单一环节具备支持业务的所有能力，但是也额外引入了很多服务，并且这些服务环节息息相关，任何一个环节的故障都会导致业务受到影响。比如如果包子店老板没买到包子馅，蒸笼坏了，或者外卖小哥不认识路，或者外卖平台服务宕机了，你早上都吃不上包子，只能挨饿了。这就是我说的为什么微服务架构不能超过三层，一旦超过三层。服务的任何一个环节的影响都会扩散到整个链路。让我们回顾一些正常的外卖流程。你在外面平台下单，外买平台把通知包子店，包子店确认后，把快递单子发送给很多快递小哥，快递小哥抢到单子后去店里拿包子。而包子店老板也不会现场去买包子馅包子皮等等，一般他们都是做好了的。这样一来我们买包子的流程就简化到了第一层是外买平台，第二层是快递小哥和包子店，而且快递小哥还是多活高可用场景。这个设计就是非常合理，非常符合我们的需求的了。

         在上面的例子中我们除了看出微服务架构下，服务层次不能多，每个服务层独立之外，也不难发现另一个问题，微服务架构下需要非常高效稳定的服务监管和治理能力。实际上我在网络上查询的大量文章中，都是在讲微服务治理。当然微服务治理非常重要，但是我们一定要搞清的是微服务的构建在于服务的设计，而不是用了多少微服务框架。服务被拆分为多个微服务进程后，如果微服务层次涉及过于深入，上下游服务之间的依赖过高。那么任何一个微服务环节的影响都有可能扩散到整个系统，这种变化会带来分布式系统的一系列问题，此时微服务异常对系统的影响是破坏性的。首先让我们来一起看一下微服务架构所具有的技术特点

1. 服务的注册与发现
2. 身份验证与授权
3. 服务的伸缩控制
4. 反向代理与负载均衡
5. 路由控制
6. 流量切换
7. 日志管理
8. 性能度量、监控与调优
9. 分布式跟踪
10. 过载保护
11. 服务降级
12. 服务部署与版本升级策略支持
13. 错误处理

        微服务架构的成功案例在我们身边其实也是非常多的，比如说dubbo服务，比如说rocketmq服务。dubbo是高性能的RPC服务框架，RocketMq是高性能的消息队列组件，但是无疑他们自身也具有非常优异的微服务架构理念。结合上面微服务的技术特点，是不是很容易发现du bbo和rocketMQ除了自身服务本身外，更多的是在解决微服务所带来的难点。更具体的我们在这里就不讨论了，微服务治理的每个核心点，不仅是微服务本身的问题，也是我们系统设计中都需要面对的问题，每个点都值得我们深入理解的，本文知道他们存在就好。

总结：微服务架构和任何架构一样，是一把双刃剑，善用者天下无敌，滥用者会陷入无底深渊。在使用过程中我认为重点应该在系统基础架构本身，而非框架的使用（当然很多时候有些框架是我们必须用）。