下面着重介绍微服务架构： > 微服务架构风格是一种将一个单体应用程序开发为一组小行服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制（通常用 HTTP 资源 API）。这些服务围绕业务能力构建摒弃人可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理，服务可用不同的语言开发，使用不同的数据存储技术。——引自 Martin Fowler 的博客 最直观的区别如下：  那么从上面的描述中可以看到，微服务加否应具备以下特性： * 每个微服务可独立运行在自己的进程里，做到了进程隔离。 * 一系列独立运行的微服务共同构建起整个系统。 * 每个服务为独立的业务开发，一个微服务只关注某个特定的功能，例如订单管理、用户管理等。 * 微服务之间通过一些轻量级的通信机制进行通信，例如通过 RESTful API 进行调用。 * 可以使用不同的语言与数据库存储技术。 * 全自动的部署机制。 还是以之前的电商平台系统为例，使用微服务架构来架构该应用，如下图：  将整个应用拆分为多个服务，各个微服务独立运行在自己的进程中，并分别有自己的数据库，微服务之间使用 REST 或者其他协议通信。 当然，在软件领域，没有万能的解决方案。同样的，微服务也存在一定的不足： * 运维要求较高： 更多的服务意味着更多运维的投入。在单体应用架构中，只需要抱枕一个应用的正常运行。而在微服务当中，需要保证几十甚至几百个服务的正常运行与协作，这给运维带来了很大的挑战。 * 分布式系统固然的复杂性： 使用微服务构建的是分布式系统。对于一个分布式系统，系统容错、网络延时、分布式事务等都会带来巨大的挑战。 * 重复劳动： 很多服务可能都会使用相同的功能，而这个功能并没有达到分解为一个微服务的程度，这个时候，可能各个服务都会开发这一功能，从而导致代码重复。