微服务架构定义那点事

从微服务架构定义的历史能够看出，这些概念来源都是提出者对我的实际工做工面临问题的解决方案的总结，是那些技术专家对十多年前工做中遇到问题的解决方案，在他们提出后不断被发展，进而成了如今流行的微服务架构。

---

 相信不少朋友了解微服务架构都是从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》,国内较早倡导和实践微服务的先行者。