微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。
微服务的概念源于2014年3月Martin Fowler所写的一篇文章“Microservices”()。
尽管“微服务”这种架构风格没有精确的定义，但其具有一些共同的特性，如围绕业务能力组织服务、自动化部署、智能端点、对语言及数据的“去集中化”控制等等。微服务架构的思考是从与整体应用对比而产生的。
通常，在一家公司随着业务需求的增长为逐步发展（自然增长）的过程中，前期往往是以单块架构的方式来组织系统的。因为对于软件的初期构建来说，单块架构的方式是最容易且最高效的。但是若干年（甚至是几个月）后，受限于前期既有单块软件系统内部耦合性，再向该系统加新功能变得越来越艰难。
单块软件企业应用，因为服务于众多业务需求，因此会有些特定的软件应用提供许多功能，而一般惯例是把这些功能都堆在单个单片应用中。例如，ERP，CRM和其他各种软件系统被规划构建为具有数百个功能的整体。这种带坑应用一经部署，在往后的故障排除、扩展和升级场景中就是一场接一场的恶梦了。
面向服务架构（SOA）旨在通过引入“服务”的概念来克服以上的限制，“服务”是从应用程序提供的类似功能中提取出来的聚合和分组。因此，使用SOA，软件应用程序就会被设计为“粗粒度”服务的组合。然而，SOA中服务的范围非常广泛，这又引出了复杂而庞大的服务与一大堆操作（功能）以及复杂无比的消息格式和标准（如WS *标准）。
多数情况下，SOA中的服务彼此独立，只不过它们与所有其他服务一起部署在相同的运行时间里（只需考虑将部署到同一个Tomcat实例中的多个Web应用）。和单片软件应用类似，这些服务通过积累各种功而具有随时间推移的习惯。图1是一个非常好的一个单片架构的例子，显示了包括多个服务的零售软件应用，所有这些服务都能部署到同一应用程序。
说了那么多，大家是不是有点不明所以？我总结了一些重点，以下就是基于单快软件架构的应用程序的一些特性归纳：
单片应用程序被设计、开发和部署为单个单元。
单片应用相对复杂，导致维护，升级和新特性困难重重。
难以用单片架构来实践敏捷开发和交付方法。
想更新某部分，很可能要重新部署整个应用。
规模需求冲突的情况下，若想做单点扩展，要做好多倍资源甚至推倒重来的准备（例如，想给A服务更多CPU，B服务可能要重做，也可能要补两三倍memory）
可靠性：一个不稳定的服务可以拖慢整个应用性能。
难创新：采用新技术和框架非常困难，因为所有的功能必须建立在均匀的技术/框架上。
面向微服务的架构面向微服务的架构拥有一些特质。任意规模的大中型公司如果想让自身IT系统保持弹性，并希望随时都可以对系统规模进行伸缩的话，必定会对这些特质趋之若鹜。
为什么面向微服务的架构更好微服务架构（MSA）的基础是将单片应用作为一套小型和独立服务来开发，这些服务都在自己的空间独立开发、部署和运行。在微服务体系结构的大多数定义中，它普遍被解释为将巨大的可用服务隔离成一套独立服务的过程。
但是面向微服务的架构并是不工程的圣杯。弹性、可组合性以及灵活性是面向微服务架构设计的关键原则。如果不遵守你将失去一个完美的解决方案，并最终在单块应用分拆多台机器上时遇到大量的问题。
不足之处事无绝对，微服务也会有几下问题：
网络延迟：微服务具有分布式的特性，从而无可避免地会存在网络延迟
运维负担：更多的服务器也意味着需要更多的维护工作
最终一致性：在一个对事务性要求较高的系统中，考虑到实现的局限性，各个节点在某一时间内可能会出现数据不一致
关键设计原则一般来说，我们可以确定一下设计原则：
单一责任原则（SRP）：为微服务提供有限和重点突出的业务范围，有助于我们满足开发和提供服务的敏捷性。
在微服务的设计阶段，我们应该找到各服务的边界，并将其与业务能力（也称为域驱动设计中的有界环境 ）保持一致。
微服务设计要确保敏捷/独立开发和部署服务的丝滑稳定。
我们的重点应该放在微服务的范围上，而不是使服务更"小"。服务的大小应该是指所需的范围大小，以促进给定的业务能力。
与SOA中的服务不同，给定的微服务应该具有很少的操作/功能和简单的消息格式。
随着时间的推移，首先开始具有相对广泛的服务边界，重构到较小的服务界限（基于业务需求），这是一个很好的做法。
关键的好处现在我们看几项关键的好处。
弹性