单体应用架构概述
传统的服务发布都是采用单体应用架构，那么什么是单体应用架构呢？
单体建构：一个归档宝（如war）包含所有功能的应用程序，通常称为单体应用。而架构单体应用的方法论，就是单体应用架构。
以一个电影售票系统为例，尽管将其分为各个模块，但是由于UI和若干业务模块最终都被打包在一个war包中，该war包包含了整个系统的所有业务功能，这样的应用系统成为单体应用。
微服务概述
微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制（通常用HTTP资源API）。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理，服务可用不同的语音开发，使用不同的数据存储技术。
微服务的特性
- 每个微服务可独立运行在自己的进程里。
- 一系列独立运行的微服务共同构建起整个系统。
- 每个服务为独立的业务开发，一个微服务只关注某个特定的功能。
- 微服务之间通过一些轻量的通信机制进行通信，例如RESTful API进行调用。
- 可以使用不同的语言与数据存储技术。
- 全自动的部署机制。
微服务架构的优点
- 易于开发和维护
- 单个微服务启动较快
- 局部修改容易部署
- 技术栈不受限
- 按需伸缩
微服务面临的挑战
- 运维要求较高
- 分布式固有的复杂性：使用微服务构建的是分布式系统。对于一个分布式系统，系统容错、网络延迟、分布式事物等都会带来巨大的挑战。
- 接口调整成本高：微服务之间通过接口进行通信，如果修改某一个微服务的API，可能所有使用了该接口的微服务都需要调整。
- 重复劳动：很多服务可能都会使用到相同的功能，而这个功能并没有达到分解为一个微服务的程度，这个时候，可能各个服务都会开发这个功能，从而导致代码重复。
微服务的设计原则
- 单一职责原则：指的是一个单元（类、方法或服务等） 只应关注整个系统功能中单独、有界限的一部分。
- 服务自治原则：指每个微服务都应具有独立的业务能力、依赖于运行环境。在微服务架构中，服务是独立的单元业务，应该与其他服务高度解耦。每个微服务从开发、测试、构建、部署，都应当可以独立运行，而不应该依赖其他的服务。
- 轻量级通信机制：微服务之间应该通过轻量级的通信机制进行交互。
- 微服务粒度：应当使用合理的粒度划分微服务，而不是一味的把微服务做小。