王磊：前ThoughtWorks首席咨询师，《微服务架构与实践》作者，翻译有《DevOps Handbook》,国内较早倡导和实践微服务的先行者，有丰富的微服务/DevOps/持续交付实战经验
微服务架构那点事
相信很多朋友了解微服务架构都是从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等发表的见解。
感兴趣的朋友可以继续挖掘一下，了解微服务架构演进过程中，大师们是如何看待微服务架构的。
来源：中生代技术