什么是微服务

微服务的概念源于2014年3月Martin Fowler写的一篇文章 Microservices

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。
每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）。
每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。
另外应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。

微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。
系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。
每个微服务仅关注于完成一件任务并很好地完成该任务。
在所有情况下，每个任务代表着一个小的业务能力。



微服务架构优势
 
复杂度可控
每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。
由于体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。

独立部署
由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。
当某个微服务发生变更时无需编译、部署整个应用。
由微服务组成的应用相当于具备一系列可并行的发布流程，
使得发布更加高效，同时降低对生产环境所造成的风险，最终缩短应用交付周期。

技术选型灵活
微服务架构下，技术选型是去中心化的。
每个团队可以根据自身服务的需求和行业发展的现状，自由选择最适合的技术栈。
由于每个微服务相对简单，对技术栈进行升级时所面临的风险也较低，甚至完全重构一个微服务也是可行的。

容错
当某一组建发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。
微服务架构下，故障会被隔离在单个服务中。若设计良好，其他服务可通过重试、平稳退化等机制实现应用层面的容错。

扩展
单体架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。
当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独立进行扩展。


微服务架构缺点
 
分布式系统的复杂性
额外的网络开销性能开销 
测试复杂度
运维复杂度
增加了资源使用  （人  硬件资源 等）
增加沟通成本
每一个组件可选择不同的技术栈，增加维护成本