Martinfowler的这篇微服务文章引发了软件架构方面的热烈讨论,
“今天在软件架构方面,除了微服务这个名称没有什么新的”。现大意翻译如下:
微服务,是另外一个在软件体架构这个拥挤的街道上冒出的新名词。虽然我们很自然地用轻蔑的一瞥对待这个事情,但是我们发现它是越来越吸引人的软件系统风格。我们已经看到很多项目都在使用这种风格,在过去的几年里一直到今天,以至于我们许多同事都默认使用这种风格来构建企业级应用。但不幸的是,并没有有关“什么是微服务风格”等方面更多信息。
简短地说,微服务架构风格是一种使用一套小服务来开发单个应用的方式途径,每个服务运行在自己的进程中,通过轻量的通讯机制联系,经常是基于HTTP资源API,这些服务基于业务能力构建,能够通过自动化部署方式独立部署,这些服务自己有一些小型集中化管理,可以是使用不同的编程语言编写,正如不同的数据存储技术一样。
未了解释微服务,必须比较一下铁板一块式monolithic(整体) 风格,一个铁板一块monolithic的应用作为一个单元构建,企业应用经常基于三个部分构建:一个客户端用户界面(浏览器运行HTML和javascript),一个数据库和一个服务端应用,服务端应用处理Http请求,执行领域逻辑,加载和更新数据库数据,查询和导出Html视图到浏览器,这个服务端应用是铁板一块monolithic ,只有一个合乎逻辑的可执行文件,这个系统的任何改变都会涉及到重新构建和部署新版本。
这样一个铁板一块的服务器是构建一个系统的最朴素的方式,你所有处理请求的逻辑都运行在一个过程中,允许你使用你语言基本特点将应用切分到类 函数和名称空间等,如果你够仔细,你能够运行测试这个应用,使用部署通道确保所有改变能被测试并应用到生产环境,你能够通过水平扩展一个铁板一块式的应用,比如在一个负载平衡器后面运行多台服务器或实例。
铁板一块的应用是成功的,但是越来越多人却感受到其带来的挫折,特别是很多应用部署到云中,改变周期捆绑在一起:一个小改变导致需要整个系统重新构建重新部署,它总是能以保持模块化结构,难以让变化只影响在一个模块内,进行扩展伸缩只能整个系统扩展,而不能针对其一部分扩展其资源能力。
如下图:
这些挫折导致微服务架构,以一套服务来构建应用,这些服务能够独立被部署和扩展伸缩,每个服务提供一个模块边界,允许不同的服务以不同语言编写,由不同团队管理。
我们并不想宣传微服务是创建,它只是以前Unix设计原理的回归,但是我们真的认为不是所有人会考虑微服务,他们也没有认识到使用微服务会让他们开发工作更好。
待续。。