1.1 单体应用架构存在的问题
一个归档包（例如war格式）包含所有功能的应用程序，通常称为单体应用。
下面列举单体应用所存在的一些问题：
*复杂性高：整个项目包含的模块非常多、模块之间的边界模糊、依赖关系不清晰、代码质量参差不齐、混乱的堆砌在一起..整个项目非常复杂，每次修改代码胆战心惊，甚至添加一个小bug都会带来隐含的缺陷。
*技术债务：随着时间的推移、需求变更、人员迭代，会逐渐形成应用程序的技术债务。已经使用的系统设计或代码难以被修改，因为程序中其他模块可能会出乎意料的使用它。
*部署频率低：随着代码的增多，构建和部署的时间也会增加。而在单体应用中，每次功能的变更或缺陷的修复都会导致重新部署整个应用。全量部署的方式耗时长、影响范围大、风险高，所以单体应用部署频率较低。而部署频率低又导致两次发布之间会有大量的功能变更和缺陷修复，出错概率高。
*可靠性差：某个应用bug，例如死循环、OOM等，可能会导致整个应用崩溃。
*扩展能力受限：单体应用只能作为一个整体进行扩展，无法根据业务模块的需要来进行伸缩。例如，有些模块是计算密集型的，需要强劲的CPU；有的模块则是IO密集型，需要大的内存。由于这些模块部署在一起，不得不在硬件的选择上做出抉择。
*阻碍技术创新：单体应用往往使用统一的技术平台或方案解决所有的问题，团队中所有的成员都必须使用相同的开发语言和框架，想要引进新框架或技术会非常困难。
单体应用存在很多问题，有没有一种架构模式解决可以解决这些问题？微服务就是这样一种架构。
1.2 什么是微服务
微服务架构风格就是一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务之间采用轻量级通信机制（通常用HTTP资源API）。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。
微服务架构特性：
*每个微服务可独立运行在自己的进程里。
*一系列独立运行的微服务共同构建起整个系统。
*每个服务为独立的业务开发，一个微服务只关注某个特定的功能，例如订单管理、用户管理等。
*微服务之间通过一些轻量级的通信机制进行通信，例如通过RESTful API进行调用。
*可以使用不同的语言与数据存储技术。
*全自动部署机制。
1.3 微服务的优点与不足
优点：
*易于开发和维护：一个微服务只会关注一个特定的业务功能，所以他的业务清晰、代码量较少。开发和维护单个服务相对简单。而整个应用是由若干个微服务构建而成，所以整个应用也会为维持在一个可控的状态。
*单个微服务启动较快：单个微服务代码较少，启动较快。
*局部修改容易部署：单体应用只要有修改，就得重新部署整个应用，微服务解决了这样的问题。一般来说，对某个微服务进行修改，只需重新部署这个服务即可。
*技术栈不受限制：在微服务架构中，可以结合项目业务及团队的特点，合理的选择技术栈。
*按需伸缩：可以根据需求，实现细粒度的扩展。例如，系统中的某个服务遇到了瓶颈，可以根据这个微服务的业务特点，增加内存、升级CPU或者增加节点。
不足:
*运维要求较高：更多的服务以为着更多的运维投入。在单体架构中，只需要保证一个应用的正常运行。而在微服务中，需要保证几十个甚至几百个服务的正常的运行与协作。
*分布式固有的复杂性：使用为微服务构建的分布式系统。对于一个分布式系统，系统容错、网络延迟、分布式事务都会带来巨大的挑战。
*接口调整成本高：微服务之间是通过接口通信。如果修改了某一个微服务的API，可能所有使用了该接口的微服务都需要做调整。
*重复劳动：很多服务可能都会使用到相同的功能，而这个功能并没有达到分解为一个微服务的程度，这个时候，可能各个服务都会开发这一功能，从而导致代码重复。尽管可以使用共享库来解决这一问题。（例如可以将这个功能封装成公共组件，需要该功能的微服务引用该组件），但共享库在多语言环境下就不一定能够行的通了。
1.4 微服务的设计原则
*单一职责原则：一个单元（类、方法、服务）只应关注整个系统功能中单独、有界限的一部分。单一职责原则帮助我们更优雅的开发、更敏捷的交付。
*服务自治原则：每个微服务应该具备独立的业务能力、依赖与运行环境。在微服务架构中，服务是独立的业务单元，应该与其他服务高度解耦。每个微服务从开发、测试、构建、部署，都应当可以独立运行，而不应依赖其他服务。
*轻量级通信机制：微服务之间应该通过轻量级的通信机制进行交互。
*微服务的粒度：微服务的粒度是难点，也常常是争论的焦点。应当使用合理的粒度划分微服务，而不是一味的把服务做小。