传统的单体应用开发思路在新时代已经站不住脚了。一个简单的应用程序可以随着时间的推移而增长。在每一次冲刺中，开发团队都会面对一个新的“故事”，开发出大量的新代码。几年后，这个小而简单的应用程序可以变成一个巨大的怪物。一旦你的应用程序变成了一个庞大而复杂的怪物，对开发团队来说一定是一种痛苦。敏捷开发和部署遇到了困难，其中最主要的是应用程序太复杂以至于任何一个开发人员都无法理解。因此，修复错误和正确添加新功能变得非常困难和耗时。另外，团队士气可能会走下坡路。最后，单体应用使得采用新的架构和语言变得非常困难。例如，假设您使用XYZ框架编写了200万行代码。如果要改成ABC框架，无论是时间还是成本都非常昂贵，即使ABC框架再好。所以，这是一个无法逾越的鸿沟。在你最初的选择之前，你必须低头。与单体应用程序相比，微服务使用一组服务来构建应用程序。服务独立部署在不同的进程中，不同的服务通过一些轻量级的交互机制进行通信，如RPC、HTTP等，服务可以独立扩展和伸缩，每个服务定义明确的边界，不同的服务甚至可以实现在不同的编程语言并由独立的团队维护。打个比方，点菜服务就是把所有东西都放在一个大盒子里，这个大盒子什么都有。微服务更像是汽车箱。每个盒子都包含特定的功能模块和物品，一切都可以灵活拆分。换句话说，在点菜服务中，所有的部分都在一个巨大的包裹中。在微服务架构下，有很多独立存在的小服务，通过API接口连接起来形成一个庞大的系统。从表面上看，微服务架构模式有点像SOA，它们是由多个服务组成的。但是，从另一个角度来看，微服务架构模式是一个不包括Web服务（WS-）和ESB服务的SOA。微服务应用乐于采用简单轻量级的协议，例如REST，而不是WS-，并避免在微服务内部使用ESB和类ESB功能。微服务架构模式也拒绝规范模式等SOA概念。微服务架构下，技术选型是去中心化的。每个团队都可以根据自身的业务需求和行业发展现状，自由选择最合适的技术栈。由于每个微服务都比较简单，升级技术栈的风险较低，甚至完全重构一个微服务也是可行的。当一个组件发生故障时，在传统的单进程架构下，故障很可能在进程内蔓延，导致应用程序全局不可用。在微服务架构中，故障被隔离在单个服务中。如果设计得当，其他服务可以通过重试、平滑降级等机制在应用层面实现容错。使用微服务构建新型的云就绪应用程序是有意义的，因为它可以让您利用横向扩展和纵向扩展架构，此外您还可以获得可在整个业务中重复使用的API组合。可能每分钟都会有新的服务交付，所以你有一个敏捷响应迅速的应用平台，当然是在不断改进，微服务架构也在进步。
