从微服务架构定义的历史可以看出，这些概念来源都是提出者对个人实际工作工面临问题的解决方案的总结，是那些技术专家对十多年前工作中遇到问题的解决方案，在他们提出后不断被发展，进而成了现在流行的微服务架构。
相信很多朋友了解微服务架构都是从Martin Fowler的那篇文章开始。而实际上，Martin却并不是最早谈及微服务架构的，本篇文章就和你聊聊微服务架构定义的那点事。
最易懂的版本
Martin Fowler的这篇文章《Microservices》通俗易懂的讲解了什么是微服务架构.
微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相协作（通常是基于HTTP协议的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。
我在2015年4月QCon的《基于微服务架构，改造企业遗留系统的实践》演讲上，将这四个特性定义抽象为“小、独、轻、松”。最后一个字之所以定义成松，是为了读起来能朗朗上口。确切的讲，松所代表的含义其实是服务具备独立的流水线，能够被独立的构建，并且被独立的部署。实际上，Martin Fowler并不是最早提出微服务架构概念的人。
最早期的版本
最早提出微服务架构概念的，是Fred George。他一位非常传奇的人物，从业40多年，接触过70+编程语言，就职过IBM、TW等多家公司，并在社区和大会上做过很多分享。后来成立独立的咨询公司，为金融、电信、保险、航空等多个行业提供敏捷、持续交付、DevOps等转型服务，他也是最早实践XP、Scrum、和看板的人之一.
在2012年3月的Agile India上，Fred George分享了题为
“Micro (u)Services Architecture -small, short lived services rather than SOA.”
的演讲。在演讲中，他描述了从2005~2009年期间，他和所在的团队是如何将100万行的传统J2EE程序，通过解耦、自动化验证等实践，逐渐分解成20多个5K行代码的小服务，又分解成200多个500行代码的服务的过程，而其中，也大谈了基于Kafka的消息解耦服务间依赖。我认为，这是对微服务定义的最早版本了。
最简洁的版本
Adrain Cockcroft，Netflix的云架构师，主导了Netflix从2009到2016年服务化拆分、从数据中心迁移到云平台、以及组织、流程、工具等的演进等.
他对微服务的定义是:
Loosely coupled service oriented architecture with bounded contexts.
其中两个核心点Loosely coupled 和 Bounded context。Loosely coupled表明，服务之间是松耦合的。什么叫松耦合?就是指服务能够被独立更新。如果不能被独立更新，那证明服务就不是松耦合的。Bounded context，源于DDD(领域驱动设计)，表明对于服务而言，它的业务是独立的，我们不需要知道它的依赖者，根据接口就可以更新服务的代码。我认为，这是对微服务定义的最简洁版本了。
最与时俱进的版本
第三个版本，来自Neal Ford，他是TW的资深技术专家，《卓有成效的程序员》作者，也是TW技术雷达的发起者和维护者之一。
他对微服务架构的定义是
“Microservices are the first post DevOps revolution architecture.”
这是第一次将微服务和DevOps紧密关联起来的版本。
实际上，DevOps作为一场开发与运维手拉手，心连心的运动，正在席卷着整个社区。DevOps所涵盖的一系列文化、实践以及自动化的理念(CALMS)，是微服务演进过程中必不可少的先决条件。可以说，在传统的运维模式下，有效实现微服务架构几乎是不可能的，因为微服务的实施需要自动化基础设施、自动化部署、自动化验证、以及利用有效的工具完成运维、监控、告警等。而只有将DevOps与微服务紧密的结合起来，才能达到事半功倍的效果。
总结
如上就是我认为微服务演进过程中，最具有代表性的几个定义，当然，除了这3位大师，还有很多其他大师，譬如Sam Newman，James Lewis等发表的见解。
感兴趣的朋友可以继续挖掘一下，了解微服务架构演进过程中，大师们是如何看待微服务架构的。
王磊：前ThoughtWorks首席咨询师，《微服务架构与实践》作者，翻译有《DevOps Handbook》,国内较早倡导和实践微服务的先行者。