微服务宏观把控
区别
SOA架构主要针对企业级、采用ESB服务（ESB企业服务总线），非常重，需要序列化喝反序列化，采用XML格式传输。
微服务架构主要用于互联网公司，轻量级、小巧、独立运行，基于Http+Rest+JSON格式传输。
ESB也可以说是传统中间件技术与XML、Web服务等技术相互结合的产物。
单体架构存在的缺点
复杂性逐渐变高
技术债务逐渐上升
部署速度逐渐变慢
阻碍技术创新
无法按需伸缩
什么是微服务
Martin Fowler：简言而之，微服务架构风格这种开发方法，是以开发一组小型服的方式来开发一个独立的应用系统。其中每个小型服务都运行在自己的进程中，并经常采用HTTP资源API这样的轻量的机制来互相通信。这些服务围绕业务功能进行构建，并能通过全自动的部署机制来进行独立部署。这些微服务可以使用不同的语言来编写，并且可以使用不同的数据存储技术。对这些微服务我们仅做最低限度的集中管理。
微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）.每个服务都围绕着具体业务进行构建，并且能够独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制、对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。
微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。
微服务具备的特性
- 每个微服务可独立运行在自己的进程里。
- 一系列独立运行的微服务共同构建起了整个系统
- 每个服务为独立的业务开发，一个微服务一般完成某个特定的功能，比如：订单管理、用户管理等。
- 微服务之间通过一些轻量的通信机制进行通信，例如通过RESTAPI或者RPC的方式进行调用。
微服务的优点
- 易于开发和维护
- 启动较快
- 局部修改容易部署
- 技术栈不受限
- 按需伸缩
- DevOps
微服务带来的挑战
- 运维要求较高
- 分布式的复杂性
- 接口调整成本高
- 重复劳动
微服务设计原则
- 单一职责原则
- 服务自治原则
- 轻量级通信原则
- 接口明确原则
