微服务确实很受欢迎，但是对于微服务的误解也是事实，本文对这些误解一一介绍下：
微服务不够“微”？
虽然微服务的定义很明确，但在开发社区中对它的解释却截然不同。
有些问题是：
1.它是否是单体架构的代表？
2.它是否是单体服务的代表？
3.它是否是逻辑功能的组合？
为了讨论这个问题，让我们以一个银行应用程序为例，
- 3层架构解决了技术组件之间紧密耦合的问题，使它们能够独立更改。 例如：Web更改不应影响后端等。
- 但是三层架构没有考虑到组件的功能或基于功能的分组。
- 我创造了这个名字“F-Tier”架构，表明架构需要按功能划分。 这对于现代应用程序性能和吞吐量的成功至关重要，我将在本文中进一步解释细节。
微服务是可伸缩性的！
微服务是一种架构风格，它允许你向规模化的宏伟系统衍变，这是怎么做到的呢？传统的三层架构服务能伸缩可被扩展，那微服务有啥特别之处呢？
例如：在线旅行预定，购买请求和预定请求比例是100：1。
- 这意味着什么呢， 101个请求中，购买请求能达到100个，而预定请求只有1个；
- 这就敲响了警钟！预定需要的资源远远小于购买所占用的资源，为何不将整个系统按照期望比例缩放成100：1呢？
微服务更有利于系统维护和运行
“滚动式重启”， “热部署”， “轮询式部署， ”是不是听起来很熟悉？用最短的停机时间来维护应用系统，是现代应用系统的一个状态优先级典型表现。让我们举个例子，改变应用将会贯穿整个三层架构，包括数据库应用程序的变化。如果数据的语义被修改了，任何上述技术都是注定要失败的（例如：ORM（对象映射关系）一旦看到了对象的变化，就需要重新启动所有的节点）。
关于微服务：功能型-层架构给高可用性和维护带来了一个新的局面。即使银行报表微服务奔溃了也不会影响银行系统其他的功能。你将会为90%的消费者不使用银行报表功能感到庆幸。
微服务需要进一步发掘
好吧，任何关于自动伸缩的系统都需要被挖掘。
1.在微服务中有10个节点是购物的，两个节点是预定的；
2.由于假日季节，流入流量比较高；
3.你期望通过人工分拆购物实例得到什么？
4.假设分拆出了多个实例，那负载平衡器又是怎么实现负责均衡的呢？
传统的负载均衡器在静态环境中能够运行良好，但是当动态增加节点或执行脚本添加新实例的就很糟糕了。如果微服务能够实现缩放，微服务项目就需要被挖掘、注册、添加实现负载均衡；对，大部分的软件问题，通过引用间接层来解决。每个微服务在关闭或启动时都需要自我注册。这就需要一个注册管理员-负载均衡器，对微服务的加载很敏感。如何检查呢？
Netflix解决了这个问题， Netflix在开源Eureka上实现了负载均衡。
微服务是否支持多元化编程语言？
顾名思义微服务是以协议驱动的服务，这些服务是基于HTTP/REST（ XML/ JSON数据传输）的。微服务与轻量级协议之间的清晰的定义边界，有助于建立一个多元化的编程团队，因为他们的焦点是功能而不在于选择语言。
微服务和容器是天作之合？
虚拟机的笨重和现代应用程序的性质，将他们分拆为微服务，使微服务成为容器的理想搭配。这是真正意义上的DevOps，打的包不仅仅是微服务的容器也是整体的一个执行环境。缺点是，应用团队将成为基础设施团队，需要对容器有个很好的理解。
微服务添加额外的复杂性？
1.Jenkins简单通道把两个应用部署到2个Tomcat里，以此类推，将膨胀出无数个微服务；
2.随着部署的数量增加，部署的时间也跟着显著上升；
3.需要有一个良好的容器管理，部署和分发工具和技术；
4.每个微服务将拥有更多的日志文件，如果没有stash、 splunk这种合适的工具，对接调试事务将成为一场噩
