微服务概述

“微服务”这个术语在过去几年如雨后春笋般涌现,它是一种构建可独立部署服务套件的软件设计方式。虽然这样的架构风格没有明确的定义,但它们在组织方式、业务能力、自动化部署、智能化终端以及对语言与数据的去中心化等方面具备共同的特征。

以下内容摘自Martin Fowler的网站

“微服务”,又一个出现在拥挤的软件架构街道的新名词。虽然我们的第一反应是不屑一顾,但它的确是一个出镜率越来越高的软件设计风格。在过去的几年中,我们已经看到很多的项目使用了微服务,目前来看效果不错,我们很多同事已经将它作为构建企业应用的默认方式。但很遗憾,并没有很多资料解释微服务是什么以及如何实现微服务。

简而言之,微服务是一种将单个应用以许多微小的服务所组成的服务套件的形式来构建软件的方法,每个微服务拥有自己的轻量级数据处理模块以及通信机制(通常是HTTP API的形式)。微服务围绕业务能力和各自独立的自动化部署机制构建而来。由于微服务需要极少的集中管理,因此各个服务可以使用不同的编程语言以及不同的存储技术。

为了解释微服务的设计风格,我们先来把它和单块架构风格做一个比较。单块架构的应用只有一个单元。企业应用常常包含三个主要部分:客户端用户界面(包括运行在用户计算机浏览器中的 HTML 页面和 JavaScript)、数据库(包括保存在常见的关系型数据库中的各种表)和服务器端应用程序。服务器端应用程序处理 HTTP 请求,执行业务逻辑,在数据库中检索和更新数据并选择和渲染 HTML 视图发送到浏览器。此服务器端应用程序是一个完整的、 单一的逻辑可执行单元。任何对系统的更改都需要构建和部署完整的服务器端应用程序的新版本。

这样的单块服务器是构建系统最自然的方式。所有处理请求的业务逻辑都在同一个进程中,它允许你使用编程语言的特性来将整个应用划分为类、函数及命名空间。利用某些方法,你可以在笔记本电脑中运行和测试应用程序,并使用部署流水线确保新的更改通过了测试,并部署到了生产环境中。最后你可以通过增加运行实例并进行负载均衡,对应用进行横向扩展。

单块应用是可行的,但越来越多的人在使用的过程中受挫,尤其是随着越来越多的应用被部署到云中。整个系统的更新周期是被绑在一起的——对应用的一小部分进行了更改,就需要整个系统重新构建和部署。随着时间的推移它往往很难保持一个良好的模块化结构,继而难以保证新的更改只影响其所在的模块。需要对应用进行扩展时,只能将整个应用一起进行扩展,而不是扩展应用中的某个部分,这也消耗了更多的资源。

MicroservicesFowler

这些挫折导致了微服务的架构方式:以服务套件的形式构建软件。微服务是独立部署的和可扩展的,每个服务都有明确的模块边界,甚至允许不同的服务使用不同的编程语言,它们甚至可以由不同的团队管理。

我们不认为微服务架构是什么创新,它的历史可以追溯到 Unix 年代的设计思想。但还没有足够多的人考虑过采用微服务架构,如果他们使用微服务,很多软件开发过程会变得更好。

了解更多信息:

詹姆斯和马丁的文章接着罗列了9个微服务的特点来定义什么是微服务架构,并探讨了其与面向服务的架构(SOA)的关系,最后论述了这种风格是否是企业软件的未来。

请到这里继续阅读:http://martinfowler.com/articles/microservices.html

James Lewis是 ThoughtWorks 的资深咨询师,也是技术顾问委员会的成员。James 的兴趣点在整合企业级系统时采用小型的相互协作的服务构建应用。他已经成功得构建了许多采用微服务的系统,并且在最近的几年里一直是社区的活跃分子。

Martin Fowler 是一位作家,演讲家和大名鼎鼎的软件开发者。如何组件化软件系统的问题一直困扰着他,一些模棱两可的答案并没有让他满意。他希望微服务不要辜负倡导者们所提出的承诺。

1 1 收藏 评论

关于作者:ThoughtWorks

ThoughtWorks是一家全球IT咨询公司,追求卓越软件质量,致力于科技驱动商业变革。擅长构建定制化软件产品,帮助客户快速将概念转化为价值。同时为客户提供用户体验设计、技术战略咨询、组织转型等咨询服务。 个人主页 · 我的文章 · 76 ·   

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部