微服务

一个新的架构术语

“微服务架构”一词是在过去几年里涌现出来的，它用于描述一种独立部署的软件应用设计方式。这种架构方式并没有非常明确的定义，但有一些共同的特点就是围绕在业务能力、自动化布署、端到端的整合以及语言和数据的分散控制上面。

“微服务”- 这是在软件架构领域这个非常拥挤的街道上，冒出的一个新名词而已。虽然我们对这个新出的名词不屑一顾，但是它所描述的软件系统的风格越来越吸引我们的注意力。在过去的几年里，我们发现越来越多的项目开始使用这个风格，并且到目前为止得到的反馈都是积极的，以至于我身边的许多同事在设计企业架构时，都把它作为默认的构建方式，然而很不幸，到底什么是微服务，我们又如何来使用它，外界并没有太多的信息可供参考。

总之，微服务这种架构风格就是把一组小服务演化成为一个单一的应用的一种方法。每个应用都运行在自己的进程中，并通过轻量级的机制保持通信，就像HTTP这样的API。这些服务要基于业务场景，并使用自动化布署工具进行独立的发布。可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语言来编写服务，也可以使用不同的数据存储。

在开始解释什么是微服务之前，先介绍一下单块系统结构还是很有用的：把一个单块软件结构构建成为一个单元。企业应用通过是由三个重要部分组成：客户端界面（由HTML、Javascript组成，使用浏览器进行访问）、数据库（由许多的表组件构成一个通用的、相互关联的数据管理系统）、服务端应用。服务端应用处理HTTP请求、执行领域逻辑、检索并更新数据库中的数据、选择和填充HTML视图发送给客户端。这个服务端应用是一个单块结构也就是一个整体，这是一个可执行的单一逻辑，系统中的任何修改都将导致服务端应用重新编译和布署一个新版本。

就这样一个单块的系统结构很自然的被构建成了一个系统，虽然可以使用开发语言基本特性会把应用封装成类、函数、命名空间，但是业务中所有请求都要在单一的进程中处理完成，在某些场景中，你可以在开发人员的笔记本电脑中运行和测试，并且通过布署通道将测试通过的程序布署到生产环境中，你还可以水平扩展，利用负载均衡将实例布署到多台服务器中。

的确，单块系统结构也是很成功的，但是越来越多的人感觉到了不妥，特别是应用程序被发布到了云的时候，变更发布周期被绑定了 —- 原来可以划分成小的应用、小的需要的变更，需要统一的进行编译和发布。随着时间的推移，软件开发者很难保持原有好的模块架构，使得一个模块的变更很难不会影响到其它的模块，而且在扩展方面也只能进行整体的扩展，而不能根据进行部分的扩展。