本文摘自《微服务文集》thoughtworks 浙版数媒
“微服务” 这个术语在过去几年如雨后春笋般涌现，它是一种构建可独立部署服务套件的软件设计方式。虽然这样的架构风格没有明确的定义，但它们在组织方式、业务能力、自动化部署、智能化终端以及对语言与数据的去中心化等方面具备共同特征。
以下内容摘自Martin Fowler的网站。
“微服务”，又一个出现在拥挤的软件架构街道的新名词。虽然我们的第一反应是不屑一顾，但它的确是一个出镜率越来越高的软件设计风格。在过去的几年中，我们已经看到很多的项目使用了微服务，目前来看效果不错，我们很多同事已经将它作为构建企业应用的默认方式。但很遗憾，，并没有很多资料解释微服务是什么以及如何实现微服务。
简而言之，微服务是一种将单个应用以许多微小服务所组成的服务套件的形式来构建软件的方法，每个微服务拥有自己的轻量级数据处理模块以及通信机制（通常是HTTP API的形式）。微服务围绕业务能力和各自独立的自动化部署机制构建而来。由于微服务需要极少的集中管理，因此各个服务可以使用不同的编程语言以及存储技术。
为了解释微服务的设计风格，我们先来把他和单块架构风格做一个比较。单块架构的应用只有一个单元。企业应用常常包含三个主要部分：客户端用户界面（包括运行在用户计算机浏览器中的HTML页面和JavaScipt）、数据库（包括保存在常见关系型数据库中的各种表）和服务器端应用程序。服务器端应用程序处理HTTP请求，执行业务逻辑，在数据库中检索和更新数据并选择和渲染HTML视图发送到浏览器。此服务器端应用程序是一个完整的、单一的逻辑可执行单元。任何对系统的更改都需要构建和部署完整的服务器端应用程序的新版本。
这样的单块服务器是构建系统最自然的方式。所有处理请求的业务逻辑都在同一个进程中，它允许你使用编程语言的特性来讲整个应用划分为类、函数及命名空间。利用某些方法，你可以在笔记本电脑中运行和测试应用程序，并使用部署流水线确保新的更改通过了测试，并部署到了生产环境中。最后你可以通过增加运行实例并进行负载均衡，对应用进行横向扩展。
单块应用是可行的，但越来越多的人在使用的过程中受挫，尤其是随着越来越多的应用被部署到云中。整个系统的更新周期是被绑在一起的 - 对应用的一小部分进行了更改，就需要整个系统重新构建和部署。随着时间的推移它往往很难保持一个良好的模块化结构，继而难以保证新的更改只影响其所在的模块。需要对应用进行扩展时，只能将整个应用一起进行扩展，而不是扩展应用中的某个部分，这也消耗了更多的资源。
这些挫折导致了微服务的架构方式：以服务套件的形式构建软件。微服务是独立部署的可扩展的，每个服务都有明确的模块边界，甚至允许不同的服务使用不同的编程语言，它们甚至可以由不同的团队管理。
我们不认为微服务架构是什么创新，它的历史可以追溯到Unix年代的设计思想。但还没有足够多的人考虑过采用微服务架构，如果他们使用微服务，很多软件开发过程会变得更好。
了解更多信息：
詹姆斯和马丁的文章接着罗列了九个微服务的特点来定义什么是微服务架构，并探讨了其与面向服务的架构（SOA）的关系，最后论述了这种风格是否是企业软件的未来。
请到这里阅读：
