微服务架构概述
微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制（通常用HTTP资源API）。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理，服务可用不同的语言开发，使用不同的数据存储技术。从中可以看出，微服务应具备以下特性：
- 每个微服务可独立运行在自己的进程里。
- 一系列独立运行的微服务共同构建起整个系统。
- 每个微服务为独立的业务开发，一个微服务只关注某个特定的功能。
- 微服务之间通过一些轻量的通信机制进行通信，例如通过RESTful API进行调用。
- 可以使用不同的语言与数据存储技术。
- 全自动的部署机制。
单体应用存在的问题
- 复杂性高：整个项目包含的模块多，模块的边界模糊，依赖关系不清晰，代码质量参差不齐混乱的堆砌在一起，整个项目非常复杂。
- 技术债务：随着时间推移、需求变更和人员更迭，以使用的系统设计或代码难以被修改。
- 部署频率低：随着代码的增多，构建和部署的时间也会增加，每次都是全量部署，耗时长，影响范围大，风险高。
- 可靠性差：某个应用Bug，可能会导致整个应用的崩溃。
- 扩展能力受限：无法根据业务模块的需求进行伸缩。
- 阻碍技术创新：团队中的每个成员都必须使用相同的开发语言和框架，要想引入新框架或新技术平台会非常困难。
微服务架构的优点
- 易于开发和维护。
- 单个微服务启动较快。
- 局部修改容易部署。
- 技术栈不受限：可以结合项目业务和团队特点，合理地选择技术栈。
- 按需伸缩：可根据需求实现细粒度的扩展。
微服务架构面临的挑战
- 运维要求高。
- 分布式固有的复杂性：系统容错、网络延迟、分布式事务等都会带来巨大的挑战。
- 接口调整成本高：微服务之间通过接口进行通信，如果修改某一个微服务的API，所有使用了该接口的微服务都需要做调整。
- 重复劳动：很多服务可能都会使用到的相同功能，这部分代码可能导致代码重复。（可以通过共享库解决，但共享库在多语言环境下就不一定行得通了）。
微服务设计原则
- 单一职责原则：只用关注整个系统中单独、有界限地一部分。【1】
- 服务自治原则：每个微服务应具备独立地业务能力、依赖与运行环境。
- 轻量级通信机制：首先，体量较轻；其次，它应该是跨语言，跨平台地。
- 微服务粒度：应当使用合理得粒度划分微服务，而不是一味地把服务做小。
【1】：SOLID原则之一