所属技术领域：
微服务
|发展历程|
上世纪 80 年代初，第一种重要的系统分发技术 “远程过程调用 (RPC)” 诞生的时候。RPC 是 Sun Microsystems 最初的 ONC RPC 背后的设想理念，也是 DCE（1988 年）和 CORBA（1991 年）背后的基本理念。
自 1999 年推出 Enterprise Java（奇怪的是版本为 1.2）以来，应用程序所有者与应用程序管理员之间的关系就一直很紧张。
该模式是 Martin Fowler 最初在 2004 年提出的，他在多年后才开始研究微服务）。他的概念被称为 “Strangler Application 模式”，旨在解决您几乎从未实 际生活在 green field 的事实。最需要微服务的程序是网络上最大和最烦人的程序，但是同样地，利用网络的架构可为我们带来一 种管理所需重构的策略。
Circuit Breaker 最初记录在 Michael Nygard 于 2007 年发表的图书《Release It!》中。
|名词定义|
在介绍微服务时，首先得先理解什么是微服务，顾名思义，微服务得从两个方面去理解，什么是"微"、什么是"服务"，微，狭义来讲就是体积小、著名的"2 pizza 团队"很好的诠释了这一解释（2 pizza 团队最早是亚马逊 CEO Bezos提出来的，意思是说单个服务的设计，所有参与人从设计、开发、测试、运维所有人加起来 只需要2个披萨就够了 ）。 而所谓服务，一定要区别于系统，服务一个或者一组相对较小且独立的功能单元，是用户可以感知最小功能集。
|技术特点|
微服务设计原则
1.单一职责原则
意思是每个微服务只需要实现自己的业务逻辑就可以了，比如订单管理模块，它只需要处理订单的业务逻辑就可以了，其它的不必考虑。
2.服务自治原则
意思是每个微服务从开发、测试、运维等都是独立的，包括存储的数据库也都是独立的，自己就有一套完整的流程，我们完全可以把它当成一个项目来对待。不必依赖于其它模块。
3.轻量级通信原则
首先是通信的语言非常的轻量，第二，该通信方式需要是跨语言、跨平台的，之所以要跨平台、跨语言就是为了让每个微服务都有足够的独立性，可以不受技术的钳制。
4.接口明确原则
由于微服务之间可能存在着调用关系，为了尽量避免以后由于某个微服务的接口变化而导致其它微服务都做调整，在设计之初就要考虑到所有情况，让接口尽量做的更通用，更灵活，从而尽量避免其它模块也做调整。
微服务优势与缺点
- 特性
每个微服务可独立运行在自己的进程里；
一系列独立运行的微服务共同构建起了整个系统；
每个服务为独立的业务开发，一个微服务一般完成某个特定的功能，比如：订单管理，用户管理等；
微服务之间通过一些轻量级的通信机制进行通信，例如通过REST API或者RPC的方式进行调用。 - 特点
易于开发和维护
启动较快
局部修改容易部署
技术栈不受限
按需伸缩 - 缺点
运维要求较高
分布式的复杂性
接口调整成本高
重复劳动
微服务开发框架
目前微服务的开发框架，最常用的有以下四个：
Spring Cloud：http://projects.spring.io/spring-cloud（现在非常流行的微服务架构）
Dubbo：http：//dubbo.io
Dropwizard：http://www.dropwizard.io （关注单个微服务的开发）
Consul、etcd&etc.（微服务的模块）|资料来源|
发展历程：
https://www.ibm.com/developerworks/cn/cloud/library/cl-evolution-microservices-patterns/index.html
