单体式应用的问题
1 一个简单的应用会随着时间推移逐渐变大。变成一个又大又复杂的怪物，开发团队肯定很痛苦。敏捷开发和部署举步维艰，因为这个应用太复杂，以至于任何单个开发者都不可能搞懂它。
2 单体式应用也会降低开发速度。应用越大，启动时间会越长。
3 复杂而巨大的单体式应用也不利于持续性开发。持续部署也会很艰难。
4 单体式应用在不同模块发生资源冲突时，扩展将会非常困难。比如，一个模块完成一个CPU敏感逻辑，应该部署在AWS EC2 Compute Optimized instances，而另外一个内存数据库模块更合适于EC2 Memory-optimized instances。然而，由于这些模块部署在一起，因此不得不在硬件选择上做一个妥协。
5 单体式应用另外一个问题是可靠性。因为所有模块都运行在一个进程中，任何一个模块中的一个bug，比如内存泄露，将会有可能弄垮整个进程。
6 最后，单体式应用使得采用新架构和语言非常困难。比如，设想你有两百万行采用XYZ框架写的代码。如果想改成ABC框架，无论是时间还是成本都是非常昂贵的，即使ABC框架更好。

总结一下：一开始你有一个很成功的关键业务应用，后来就变成了一个巨大的，无法理解的怪物。因为采用过时的，效率低的技术，使得雇佣有潜力的开发者很困难。应用无法扩展，可靠性很低，最终，敏捷性开发和部署变的无法完成。

什么是微服务
一个微服务一般完成某个特定的功能，比如下单管理、客户管理等等。每一个微服务都是微型六角形应用，都有自己的业务逻辑和适配器。一些微服务还会发布API给其它微服务和应用客户端使用。其它微服务完成一个Web UI，运行时，每一个实例可能是一个云VM或者是Docker容器。

每一个后台服务开放一个REST API，许多服务本身也采用了其它服务提供的API。
所有服务都是采用异步的，基于消息的通讯。
不像传统多个服务共享一个数据库，微服务架构每个服务都有自己的数据库。
每种服务都有自己的数据库，另外，每种服务可以用更适合自己的数据库类型，也被称作多语言一致性架构。

表面上看来，微服务架构模式有点像SOA，他们都由多个服务构成。但是，可以从另外一个角度看此问题，微服务架构模式是一个不包含Web服务（WS-）和ESB服务的SOA。微服务应用乐于采用简单轻量级协议，比如REST，而不是WS-，在微服务内部避免使用ESB以及ESB类似功能。微服务架构模式也拒绝使用canonical schema等SOA概念。

微服务的目的是有效的拆分应用，实现敏捷开发和部署。

微服务架构的好处
1 通过分解巨大单体式应用为多个服务方法解决了复杂性问题。单个服务很容易开发、理解和维护。
2 这种架构使得每个服务都可以有专门开发团队来开发。开发者可以自由选择开发技术，提供API服务。这种自由意味着开发者不需要被迫使用某项目开始时采用的过时技术，他们可以选择现在的技术。
3 微服务架构模式是每个微服务独立的部署。快速的部署变化。微服务架构模式使得持续化部署成为可能。
4 微服务架构模式使得每个服务独立扩展。你可以根据每个服务的规模来部署满足需求的规模。甚至于，你可以使用更适合于服务资源需求的硬件。

微服务架构的不足
1 『微服务』强调了服务大小，可能会导致很大数量的微服务产生。
2 微服务应用是分布式系统，由此会带来固有的复杂性。开发者需要在RPC或者消息传递之间选择并完成进程间通讯机制。更甚于，他们必须写代码来处理消息传递中速度过慢或者不可用等局部失效问题。但相对于单体式应用中通过语言层级的方法或者进程调用，微服务下这种技术显得更复杂一些。
3 另外一个关于微服务的挑战来自于分区的数据库架构。最终你不得不使用一个最终一致性的方法，从而对开发者提出了更高的要求和挑战。
4 测试一个基于微服务架构的应用也是很复杂的任务。
5 微服务架构模式应用的改变将会波及多个服务。
6 部署一个微服务应用也很复杂，成功部署一个微服务应用需要开发者有足够的控制部署方法，并高度自动化。

从单体服务向微服务