我们经常能听到一些新的名词,不太熟悉的时候,觉得它似乎是一个高深莫测的黑科技,但在真正了解它之后,感觉“也就是那么回事”,甚至很可能发现在很早之前,自己就已经熟练地在运用这些技术了。在以前,“闭包”、“函数式”这类词汇大概跟这种印象类似。

而在 2015 年,可能最令人“捉摸不透”的概念大概就数“微服务”了吧。虽然现在已经 2016 年第一个季度都快过去了,但我还是想聊聊这个你可能已经很熟悉的概念。

 

什么是微服务

关于什么是微服务,不管是市面上的书,还是网上的文章,我相信都已经很多了。但为什么你还是没弄清楚,反而更不清晰了,或是不相信自己的理解了?

还记得领域驱动设计的 限界上下文 的概念吗?在《实现领域驱动设计》一书中有讲述“限界上下文主要是一个语义上的边界,它是一个显式的边界,领域模型便存在于边界之内。一个限界上下文并不是只包含领域模型。诚然,模型是限界上下文的主要‘公民’。但是,限界上下文并不局限于容纳模型,它通常标定了一个系统、一个应用程序或者一种业务服务。”,在注解中,作者又说“应当承认,对于系统,应用程序和业务服务的含义,业界并没有达到一致。但是一般来讲,我倾向于将它们表示成一系列用于实现业务用例的复杂组件。”

可以说,微服务就是这段话中所说的“业务服务”形式的限界上下文的直接体现。简单来说,它以一个独立子系统的形式向其他子系统提供围绕一类业务的完整实现。更直接地说,这里说的独立子系统指的就是能够独立、直接地接受来自 HTTP 请求的 Web 系统。

也就是说,微服务的各个服务完全内聚,在一个大的系统中,每一个微服务独立地完成一个限界领域上下文中的功能,例如存取、查询,以及业务规则。

它有如下特点:

  • 它就是一个 Web 网站,可以直接访问和调用 它提供围绕单一业务的服务 它的直接用途通常是给其他微服务使用 它拥有完整的垂直层次,例如 Facade、Domain 和 Repository

典型的微服务例子,比如鉴权系统、账户系统、权限系统形成的系统标识体系;再如商品系统、订单系统,以及支付系统构成的电子商务交易体系。

怎么样,很轻松地了解了它的概念?那么,是不是觉得它并不新鲜呢,似曾相识?

 

微服务与相关技术的异同

我也不知道微服务怎么就突然一下子火了,毕竟它确实并不是什么新的技术。或许是日趋成熟的分布式系统架构方法,或许是互联网行业的发展推动的 DevOps 理念盛行,又或许是以 Docker 为代表的更高效运维工具的出现,所有这些技术和理念成熟之后,人们猛然地发现自己那些老旧的系统竟然无法利用这些新的实践!于是,本来在很多系统中已经实施多年的“微服务”作为一种方法论被提了出来。

在此之前,关于分布式的技术并不少。比如,负载均衡,集群,以及 SOA。

先说负载均衡和集群技术。负载均衡通常指的是针对单个具体 Web 站点可用性和性能的保障手段。它可以说是与我们谈论的业务系统的分布式架构距离比较远。而集群跟负载均衡有些类似,它指的是用于支持单个 Web 站点的基础设施的伸缩性和可用性的方法。可以说,负载均衡和集群都是针对单个 Web 站点而言,它们分别在站点外层和内部提供了多路运算的支持。但它们都与业务的切分无关。

SOA 是一个经常被滥用的词,大概谁也没法准确定义它。我习惯将它狭义地理解为,它既包含分布式运算,又包含子系统的架构思想。从分布式运算的角度来说,为了提高性能和吞吐量,将来自一个 Web 站点中大量的运算,使用类似于一定的编程方法,将这些运算任务分派到运算集群中;从子系统的架构思想来说,SOA 将业务中的一些步骤,以函数的形式部署到多个计算机中,在需要时,调用这些服务来完成业务需求。SOA 中主要用到的技术是 Web Service 和 Message Queue。

微服务与它们的不同是,微服务本身就是一个 Web 站点。因此负载均衡和基础设施集群均可能服务于微服务。而与 SOA 的主要区别便是微服务架构中单个子服务都是完整的业务子系统,甚至可以直接从浏览器中访问;还有一个次要好处,微服务采用更轻量级的 JSON 或更简单的 XML RPC 作为数据交换方式,而不是 Web Service 中的重量级协议交换。

 

试试微服务?

与所有其他技术一样,在你不知道它是什么之前,最好不要将一个工作良好的产品直接、冒然以微服务的名义破坏掉。与所有其他技术一样,微服务最好也需要一个驱动力——当你发现,每一部分业务可以独立于其他业务部分工作的时候,就是个不错的时机。

虽然说微服务中的子系统都是业务系统,它们都一定程度上能够提供相对独立的业务功能。但这些子系统并不能形成一个典型业务场景的全部,因此仍然需要额外的集成服务来实现用户场景需求。另外,多个独立的业务系统中的事务保障越来越难,数据不一致的情况很可能时常出现。最后,可想而知,一个 Web 网站由一个整体变成依赖多个子网站,显然可用性方面的挑战是以积的 形式在增长的。在尝试微服务之前,最好做足功课。

微服务是

  • 一种分布式架构方法 一种降低单个子系统架构、实现和维护复杂度的实践方式 一种好的迫使我们使用“分治方法”来理解业务的工具 可以说,成功的方法

微服务不是

  • 能够解决所有问题的方法 提高性能的方法 提高稳定性的方法 降低整体复杂度的方法 适用于所有软件系统的方法

如果决定要尝试微服务架构,尝试从以下思路着手:

  • 将现有系统重构到领域明晰,最终切分 在开始新系统之前,按微服务子系统的思维方式梳理业务模型 考虑好服务集成的问题 准备面对数据不一致的挑战 为服务提供可用性和性能保障

最后,Building MicroServices 一书详细介绍了微服务架构的设计和实践的方方面面,值得阅读。