浅谈微服务架构的演变史

一、什么是微服务架构？

在理解微服务之前，顾名思义应该从两个方面进行理解，什么是“微”？什么是“服务”？然后再去理解为什么需要用到“微”这个量级，这里就需要结合整个软件架构模式进行演变了；微狭义来讲就是体积小，多小算小？亚马逊认为：由2-Pizza团队端到端负责一个到一组服务，大小是合适的；主要有一下四个特性：1、粒度小，且专注于一件事；2、独立的进程（java的tomcat,nodejs等）；3、轻量级通信机制，通常是HTTP/REST(接口）；4、松耦合，可独立部署（这点是微服务与单体服务的核心区别）

二、微服务架构的背景：

微服务最早由Martin Fowler与James Lewis于2014年共同提出，微服务架构风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理

三、微服务的优势是什么?

在讨论微服务的优势之前，这里是将微服务与早期的单体服务进行相关的比较：
1、更快的上线时间：
在单体服务时期，如果对系统的部分功能的改动，需要对整个系统进行重新部署，第一部署的时间将大大延长，第二轻微的更改都需要重新部署整个堆栈，从而引入风险性及复杂性；相反微服务的情况下进行修改更新可以立马测试、部署上线，对个别服务的更改不会影响系统其他的部分；
2、更好的灵活性和可扩展性
单体服务要求整个系统（及所有功能)同事扩展，而使用微服务，只需要缩放需要额外性能的组件或功能，可以通过部署更多微服务实例来扩展服务范围，从而实现更有效的容量规划并降低软件许可成本，从而降低总体成本；
3、具有良好的故障弹性：
使用单体服务时，组件故障可能会危及整个应用程序；在微服务中，每项服务都是隔离的，以防止级联失败导致整个系统崩溃，如果单个微服务的所有势力均失败，则整体服务可能降级，也即出现部分功能崩溃，但是其他组件仍然可以提供有价值的服务