Layered Microservices Architecture

位置

2018年11月第19期技术雷达(点击此处下载)技术象限,建议暂缓

标签

Microservices,Architecture,Anti-pattern

目标受众

系统架构师,技术管理者,开发设计人员

关注问题

构建微服务架构首当其冲要解决的问题,就是业务服务如何划分的问题。我们发现很多组织在技术快速发展的今天,仍然会重蹈过去的覆辙,对于服务按照以前的多层架构的分层方式进行划分。这样的架构不但没有尝到微服务所带来的独立交付业务价值的甜头,还要承受微服务所引入的运维复杂度。

解决方案

按照业务能力(business capabilities)而非技术能力来划分团队和服务。

解读

对于N年前的多层架构来说,层往往是按照技术能力来划分的。以最典型的三层架构为例,包含用户界面层、业务逻辑层和数据访问层,分别由擅长前端、后台和数据库的团队来维护。每一层可以部署在不同的服务器上,构成了分布式系统的雏形。

但这样的架构很快就会出现问题。因为用户访问的是业务功能,不是上述某一个特定的层,所以用户的每一次访问都会贯穿这三层服务。任何一层出现问题,都会导致这次访问失败。而每当新的功能需要交付时,都必然要修改和重新部署所有的层次。

我们常用切蛋糕来举例子。分层架构就像是横切蛋糕,切下来的每一块都只是那一层的原材料,可能是奶油,可能是水果,也可能是慕斯。但每一块都不是完整的蛋糕(业务功能)。只有纵切蛋糕,奶油水果慕斯蛋糕一应俱全,才是用户真正想要的东西。所以我们都是纵切,切出来的每一块蛋糕都是可以分给别人吃的(独立交付的单元)。

微服务架构正是基于此诞生的。它打破了传统多层架构的束缚,以业务能力而非技术能力来划分服务和组件。比如在电商系统里常见的微服务可能包括商品服务、订单服务、支付服务等,而在传统多层架构下这些只是业务逻辑层和数据访问层的一部分内容。微服务和传统多层架构对于服务的划分,是正交的。

随着近年来的飞速发展,微服务已经逐渐成为主流架构。但无论技术如何快速变化,一些企业仍然想方设法地重新实现过去的反模式。分层式微服务架构(Layered Microservices Architecture)就是这样一种反模式。它打着微服务的旗号,但仍然按照技术能力来划分服务。比如用户体验API、进程API或系统API等。这导致任何有价值的业务变更,都需要缓慢而昂贵的多团队合作。微服务独立演进、独立交付、快速响应变化的好处一个也体会不到。

之所以陷入这样的误区,还是康威定律在背后起着作用。因为组织仍然按照技术能力而不是业务能力来划分团队,那么步入以技术能力来划分服务的歧途也就在所难免了。

因此在最新的第19期ThoughtWorks技术雷达中,分层式微服务架构首次入选,并进入“暂缓”行列。我们强烈建议组织评估这种分层方式带来的影响,我们更推荐根据业务能力来划分服务和团队。

注意,这里的分层(layered)特指按照技术能力来划分微服务,会导致教条式的逐层调用。它并不代表按照业务划分的微服务之间,根据不同服务的职责所划分的层次。比如,有些服务负责具体的业务能力,有些服务则会将不同业务服务组合起来,并提供一个对调用端更加友好的接口,我们常常称之为Composer或Orchestrator。这样的“分层”属于categorized,不是layered。

相关Blip

Share

微服务测试的思考与实践

最近几年,微服务架构越来越火爆,逐渐被企业所采用。随着软件架构的变化,对应的软件测试策略需要作何调整呢?本文将介绍微服务架构下的测试策略,并结合分享在业务和架构演变过程中,一个历经九年的项目测试策略的演进。

关于微服务

微服务架构是一种架构模式,它提倡将单一应用程序划分成一组小的服务,每个服务运行在其独立的进程中,服务间采用轻量级通信机制互相沟通(通常是基于HTTP协议的RESTful API)。每个服务都围绕着具体的业务进行构建,并且能够被独立部署到生产环境、预生产环境。

从微服务的概念可以看出它有如下好处:

  • 每个服务可以独立开发
  • 处理的单元粒度更细
  • 单个服务支持独立部署和发布
  • 更有利于业务的扩展

同时,独立开发导致技术上的分离,HTTP通信加上Queue的机制增加了问题诊断的复杂度,对系统的功能、性能和安全方面的质量保障带来了很大的挑战。另外,服务间的复杂依赖关系带来了很多的不确定性,要实现独立部署,对运维也提出了更高的要求。微服务架构的系统要特别关注这几个方面:

  • 服务间的依赖、连通性
  • 服务的容错、可用性
  • 数据的最终一致性
  • 独立部署
  • 不确定性

测试策略的选择

谈到微服务的测试策略,很容易就想到了老马推荐的文章《Microservices Testing》,该文推荐的微服务框架下的测试策略是这样的:

(经典策略模型)

这个策略模型强调测试分层以及每一层的恰当覆盖,整体符合金字塔结构。它是最优的吗?

有人对此提出了质疑…认为策略模型应该是蜂巢形状的(请参考文章):

(蜂巢模型)

这个模型重点关注服务间的集成测试,两端的单元测试和UI层E2E测试较少。

也有同事提出微服务下的测试结构应该是钻石形状的,服务间的集成依然是重点,单元测试较少,而顶层增加了安全和性能等非功能测试。

(钻石模型)

好像都有道理,到底选择什么样的策略模型好呢?不禁陷入了困境……怎么办?不妨先来听听我们项目的故事吧!

项目的故事

测试策略的演进

还是那个蓝鲸项目,不知不觉进入了第九个年头。在这九年里,随着业务的不断发展,系统架构也进行了多次演进和调整。相应的,测试策略也发生了有意思的演进变化。

(测试策略的演进)

最初单一用户系统、单体架构的时候,严格按照测试金字塔来组织各层的自动化测试。随着功能的扩展,大量mock的单元测试给重构带来了很大的不便。

企业系统开始开发的时候,我们调整了策略,减少单元测试的编写,增加UI层E2E测试的覆盖,测试结构由原来的金字塔演变成上面梯形下面倒三角的形式。

后来,架构调整,开始服务化。此时,大量的E2E测试渐渐暴露出问题:

  • CI上的测试执行时间越来越长,而且定位问题的能力很弱,测试一旦失败需要很长时间修复,测试人员好几天也拿不到可以测试的版本,反馈周期过长;
  • 由于服务化带来的不稳定因素增加,E2E测试没法很好的覆盖到需要的场景,测试人员就算拿到可测的版本也总有各种缺陷发生。

因此,项目引入契约测试,停止编写新的E2E测试,将测试下移,分别用API测试和契约测试取代。

随着功能的不断增加,虽然E2E测试的量并不增加,但是其不稳定性、维护难、定位难的问题有增无减,此时已经很难由自动化测试来保证产品的质量。为了平衡成本和收益,项目考虑去掉大部分E2E测试,只保留少量的Smoke测试,将更多的测试下移。

同时,技术雷达上新的技术“生产环境下的QA”出现,项目也开始关心生产环境,并且在QA测试阶段结合微服务的特点进行对应的探索式测试。

应对微服务的挑战

前文提到过微服务带来的挑战,下面来看项目是如何应对这些挑战的。

服务间的依赖、连通性

微服务架构下,独立开发的服务要整合起来最具挑战,如何保证服务间的依赖关系和连通性非常关键。前面已经讲过E2E集成测试有很大的挑战,并不适合,而消费端驱动的契约测试是个不错的选择。项目正是利用契约测试去保证服务间的连通性,取代一部分E2E集成测试。

服务的容错、可用性

在系统负荷达到一定程度或者某个服务出现故障的时候,微服务架构有两种技术来确保系统的可用性:服务的熔断和降级。服务的熔断是指当某个服务出现故障时,为了保证系统整体的可用性,会关闭掉出现故障的服务;服务的降级则是当系统整体负荷过载的时候,考虑关闭某些外围服务来保证系统的整体可用性。

对应的测试包括:

  1. 熔断:从性能角度,当系统负载达到某个熔断状态的时候,服务是否能正确熔断;同时,从功能角度验证熔断后系统的行为是否跟预期相符;
  2. 降级:从业务的角度,要能区分出核心业务和外围业务,在需要降级的时候不能影响核心业务;当某个服务降级后,从功能角度验证系统行为是否跟预期相符。

数据的最终一致性

(数据一致性)

数据一致性是微服务特别需要关注的。举个例子,电商平台某个订单支付成功以后,需要更新积分和订单状态,当订单服务或者积分服务其中有一个出现故障的时候,就会导致最终的数据不一致性。

测试这种情况,从业务的角度分析哪些服务会导致数据不一致性,制造对应的异常情况去测试数据的最终一致性。

独立部署

微服务的独立部署需要有CI、CD的支持,跟DevOps实践分不开。同时,更为关键的是需要契约测试来验证独立部署后服务行为的正确性。项目在这方面的工作,请参考王健的文章:你的微服务敢独立交付吗?

不确定性

微服务架构使得系统复杂度增加不少,很多的事情发生都是不可预测的,只能在其发生以后找到产生的原因。因此,也就没法在预生产环境通过测试去发现在真实生产环境才会发生的issue,我们需要把目光转移到生产环境,利用生产环境的不确定性、微服务的不可预测性来构建反脆弱的系统。

项目在这方面主要采用的技术是生产环境下的QA,请参考文章:生产环境下的QA

项目测试策略

从前面介绍的演进过程可以看到,项目测试策略在不同阶段结合参考了不同的策略模型:金字塔->近似钻石(除非功能测试外,类似于钻石模型)->蜂巢。后期全面服务化的时候,我们认为蜂巢模型是比较适合的。

当然,光有符合这个策略模型的自动化测试是远远不够的,我们项目还采用了针对微服务特点的探索式测试,保持持续交付节奏,践行DevOps实践,结合生产环境下的QA等技术把关注点右移到生产环境。

现在,项目整体测试策略演变成下图的形式:

(项目测试策略)

  1. 项目采用的是敏捷迭代开发和持续交付的模式,每四周一个发布周期。
  2. 在开发过程中实现的自动化测试是分层实现的:底层少量的单元测试,中间量最多的是API测试(类似于老马策略模型里的组件测试),上面有一部分契约测试和少量的Smoke测试来保证服务间的契约和集成。除此之外,QA有手动的探索式测试,其中包括针对微服务特点进行的一些测试。整个测试结构是类似于蜂巢模型的。
  3. 采用生产环境下的QA技术,利用生产环境,进行error监控、用户行为分析、用户反馈收集,从而来影响和指导预生产环境的开发和测试工作。
  4. 利用DevOps实践,做到高效的部署和监控,跟生产环境下的QA结合,形成良性的环路,保证项目的正常交付。

测试策略再思考

项目上多次测试策略的调整,看似很简单,其实每次调整并不是一个轻松的过程,都是平衡利弊、综合考虑多个因素才做出的决定。

分析整个调整过程,最后突然发现:当我们面对多个策略模型不知道如何选择的时候,其实我们陷入了一个太过于关注测试结构的误区,忘记了最初的目标是什么。

影响测试策略的因素

跳出误区,回到原点,重新思考测试策略的目标。影响策略的最关键因素是业务价值、质量要求、痛点。

(影响测试策略的因素)

业务价值

带来更大的业务价值、帮企业赢得更多的利润,是软件系统的目标;软件测试是软件系统成功的保障之一,业务价值也是测试策略的终极目标。所有测试活动都要围绕这个目标开展,考虑业务优先级,有效规避业务风险。

质量要求

不同的系统、同一系统的不同利益干系人(参与的不同角色)对于质量的定义和要求都可能是不同的,这毫无疑问是影响测试策略的一个关键因素。

对于仅有内部用户的系统,关注的重心可能是系统的功能;而对外发布的产品,则要求更高,一个按钮位置的不恰当都可能带来大量用户的流失。

痛点

真正的痛点往往也是优先级最高,迫切需要解决的。那些可以通过测试策略的调整来解决的痛点,自然成为了关键的影响因素之一。比如,CI Pipeline出包太慢,为了提高出包的效率,一方面在Pipeline本身想办法,另一方面调整自动化测试的比例、执行频率等也是解决方案之一。

演进式测试策略

处在不同阶段的项目,在业务价值这个大目标下,其他影响因素也是会不一样的,跟技术架构的演进一样,测试策略也应该是演进式的。

从目标出发,综合所处阶段各个方面的影响因素,制定出适合当时的测试策略。随着时间的推移,对策略进行评估和度量,并进一步改进、提高,以更好的满足需求。这就是目标驱动的演进式测试策略。

(演进式测试策略)

总结

微服务架构下多个服务的整合是最具有挑战的,对此最重要的是契约测试。契约测试有效保证服务间的契约关系不被破坏,确保服务的连通性,有助于实现真正的独立部署和独立交付。

微服务架构引入的不确定性并不是坏事,可以利用这些不确定性,采用生产环境下的QA等技术,增强系统的反脆弱性,从中获益。

测试策略的影响因素不是唯一的,技术架构并不是最关键的因素。微服务架构下的测试策略跟其他架构下的并不会有本质的区别。

业务价值始终是我们的终极目标。在这个终极目标的驱动下,测试策略不是制定完了就可以束之高阁的,需要在整个软件系统构建过程中不断的度量和改进,是演进式的。


更多精彩洞见,请关注微信公众号:思特沃克

Share

讨论微服务之前,你知道微服务的 4 个定义吗?

关于“什么是微服务”的问题,其实并没有一个统一的认识。这些年在不同的场合里和不同背景的朋友都在探讨微服务。但聊得越多,越发现大家聊的不是同一回事。和 DevOps 一样,“微服务”也是一个内涵十分广泛的词。本文从“Microservice“这个概念的源头出发,总结了 4 个常用的微服务定义。

James Lewis 原始版的微服务 6 大特征

这个版本起源于2012年,这里首先要注意年份,那时候还没有 Docker,而且 Netflix 的微服务化过程也在这个概念提出之前——2008年就开始了,那时候甚至连 DevOps 还没发明出来。James Lewis 在波兰第 33 次 Degree in Kraków 会议上分享了一个案例,名称是 “Micro Services – Java, the Unix Way”。在这个分享里, James Lewis 分享了在 2011 年中参与的一个项目中所采用的一系列实践,以 UNIX 的哲学重新看待企业级 Java 应用程序,并且把其中的一部分称之为“ Micro-Services ”。

这个时候的微服务所用的单词和我们现在所用的 Microservices 这个单词有所不同。一方面,采用 Micro 作为形容词,是和 Monolithic 相对,而不是和 Macro 相对是源于操作系统这门大学课程。我们知道,现代的操作系统课程都是以 UNIX 作为案例进行讲解的。而这两个单词来自于“微内核”(Micro-Kernel)和“宏内核”(Monolithic kernel)的比较。而非常见的“微观经济学”和“宏观经济学”中的 Micro 和 Macro 两个相对应的单词。

另一方面,服务要以复数形式出现,表示的是一个以上。由于汉语里单复数是同型的,所以我们在翻译的时候会出现问题。因此,“微服务”在作为架构的形式出现的时候,我们会用“微服务架构”称呼。单个的微服务从概念上为了和 SOA 以及其它领域的“服务”有所区分,会以“单个微服务”以示区别。而“微服务”单独拿出来是被看作为一系列技术实践的总称。

在这个分享里,James Lewis将所实践的“微服务架构”总结为 6 大特征:

  1. Small with a single responsibility —— “小到只有单一原则”在这个特征里,关于微服务有多小有两个标准:第一个标准是如果一个类复杂的超过一个开发人员的理解范围,那么它就太大了,需要被继续拆分。第二个标准是:如果它小到可以随时丢弃并重写,而不是继续维护遗留代码,那么它就足够小。这个标准有个很重要的原则就是 Rewrite over Maintain,即“重写胜于维护”。
  2. Containerless and installed as well behaved Unix services —— “去容器化并且作为 Unix Service 安装”在这个特征中,James Lewis 提倡采用 Jetty 这样的工具集成到 Maven 里,可以很方便的调试或者部署,然后打包成一个可执行的 JAR 包并以 UNIX 守护进程的方式在系统启动时执行。特别是在 AWS 这样的公有云环境下,把这样的应用程序和虚拟机实例的初始化脚本结合在一起。使得应用程序的生命周期和虚拟机的生命周期绑定成为一体,由于守护进程在所有 Unix 系统中都是通用的,因此简化整体架构的开发和运维。
  3. Located in different VCS roots ——“分布在不同的版本控制代码库里”在这个特征中,James Lewis 提到了应用程序的分离,他认为一个“微服务”应该完全和另外一个服务实现彻底的隔离,这里当然是指的从开始的代码库就开始隔离了。他同样也要求开发人员看到相似性和抽象,并采用单一的领域来指导开发团队的开发。因此接下来他继续讨论了领域驱动设计领域驱动设计和康威定律的重要性。他认为界限上下文要足够的清晰,但可以有所重合。如果没有办法做到领域之间很清晰,就通过“物理上的手段”——分离不同的团队来做到这一点。这不可避免的带来一些公共代码,但要把这些公共代码作为“库”和“基础设施即代码”来对待,就像你代码中用到的开源软件。并搭建一个 nexus 库来存储那些二进制依赖
  4. Provisioned automatically ——“自动初始化”自动初始化的要点不在于如何自动化,因为不同的应用不同的平台有不同的初始化方式。这里的重点在于管理分布式应用的复杂性。所以对于每个服务,能够采用声明出这些初始化。例如:服务 A,需要一个 负载均衡,并且可以自动扩展。服务 B,也是同样的声明方式。而这些声明可以用基础设施即代码技术很好的管理起来。
  5. Status aware and auto-scaling ——“关注状态和自动扩展”在这里,他认为这些应用应该是能够感知吞吐量的监控指标来自我进行扩展的。对于一个现代的应用而言,这是一个基本的架构性要求,但这需要团队有一定的 DevOps 能力。因为这不光要求开发人员能够让应用无状态化,而且要求基础设施可以及时捕获环境的变化。
  6. They interact via the uniform interface —— “它们通过统一格式的接口进行交互”在这里,James 建议大家采用已经成熟的 HTTP 协议以及标准的媒体类型进行接口交互,而不是采用其它的方式。并且采用HATEOAS(Hypermedia As The Engine Of Application State) 的方式构建 Restful API,使其成为一个超媒体的应用状态引擎。这样就可以将状态和执行过程隔离区分开来,更加容易进行水平扩展。此外,它也构建了一个避免架构孵化的层,可以独立于客户端持续演进。

在总结的时候,它特意提到了 UNIX 哲学。这引用自Doug McIlroy 的一篇采访

Everybody started putting forth the UNIX philosophy. Write programs that do one thing and do it well. Write programs to work together. Write programs that handle text streams, because that is a universal interface.” Those ideas which add up to the tool approach, were there in some unformed way before pipes, but they really came together afterwards. Pipes became the catalyst for this UNIX philosophy. “The tool thing has turned out to be actually successful. With pipes, many programs could work together, and they could work together at a distance.”

从这段话里,我们看到了“微服务架构”和 UNIX 哲学之间的关联:

  1. 职责独立:让多个程序(注意是 Programs 不是 Program)做好一件事。
  2. 统一接口:文本流是统一的接口,每个程序都可以通过统一的接口进行消费。
  3. 公共通信:采用管道(pipe)的方式可以说,微服务架构本身是对 UNIX 哲学在企业级 Java 应用系统中的另一个案例。

可以说,虽然应用场景变了,但 UNIX 分解复杂度的方式和保持简单的理念并未改变。

最后,James Lewis 把上述六点特征变成了一个六边形的业务能力:

Hexagonal Business capabilities composed of: Micro Services that you can Rewrite rather than maintain and which form A Distributed Bounded Context. Deployed as containerless OS services With standardised application protocols and message semantics Which are auto-scaling and designed for failure

翻译过来就是:

微服务可以通过重写而非维护一个分布式的界限上下文,且作为一个无应用容器的操作系统服务部署。并以标准化的应用协议和消息语义,为失败设计且可自动扩展。

Martin Fowler & James Lewis 合作版的微服务 9 大特征

由于在 James Lewis 之后,有很多不同的项目也采用“微服务”作为它们的实践名称。然而,不同项目之间还是存在一些差异的,且每个人都按照自己的方式在实践“微服务”。因此,基于“求同存异”的原则,Jame Lewis 的同事 —— 大名鼎鼎的 Martin Fowler 采用一种归纳的方式来解决这个问题:他认为“定义”是一些“共有的特征”(Common characteristics)。Martin Fowler 继续采用了 James Lewis 对这一系列实践的命名,并且做了修改,使之成为一个单独的名词 —— Microservices。

所以,他将微服务总结为以下9大特征

  1. 通过服务组件化
  2. 围绕业务能力组织
  3. 是产品不是项目
  4. 智能端点和哑管道
  5. 去中心化治理
  6. 去中心化数据管理
  7. 基础设施自动化
  8. 为失效设计
  9. 演进式设计

这 9 大特征的中文版具体内容请参考这里,限于篇幅原因,本文不展开讨论。

我们可以从中看出,Martin Fowler 试图将 James Lewis 的微服务定义进行一般化推广,使其不光可以在不同的语言架构和技术栈上使用。又可以兼顾敏捷、DevOps 等其它技术,成为一个架构的“最佳实践”集合。但这样一组实践本质上并没有太多的创新,只是把我们本身知道的很多架构和设计的原则结合在当前的技术栈上进行了一次整体的组合和应用。

恰逢一系列互联网公司的成功事迹带来的新实践(持续交付、DevOps)和新技术(Docker)在经历了早期实践者(Early Adopter)实践积累后的结果井喷后。这样的最佳实践的集中反应固然得到了技术人员的掌声。然而,这种定义对于妄图采用“微服务架构“的人来说是一个很高的门槛。如果这样的 9 个特征的总结是对”微服务架构“的定义。那么,为了要满足以上的 9 个定义,则需要花费很大的精力来进行改造,而且已经超出了技术升级和企业 IT 部门的职责范围。此外,即便我们知道其中每个特征所带来的收益,但却很难拿出案例和数据去佐证满足这 9 个特征的改造收益。

避开这 9 个特征的概念正交性不谈,即便这 9 个特征可以从既有的结果来回答”什么(What)是微服务“,但却没有给出“为什么(Why)要满足这些特征”和”如何(How)同时满足这些特征”。

如果自己挖的坑填不了,就教给别人来填吧:

Sam Newman 版微服务的两大特征和 7 个原则

同样作为 Martin Fowler 的同事,Sam Newman 在其著作 “Building Microservice”(中文译名为“微服务设计”)的第一章就重新回答了”什么是微服务架构“并回答了”为什么要采用微服务架构“的问题。

Sam Newman 在书中是这么定义微服务的(《微服务设计》的翻译):

微服务就是一些协同工作的小而自治的服务。

Sam Newman 自述的微服务的定义更加简单,包含了两个特征:“小” 和 “自治”。

除了继承 James Lewis 关于微服务应该有多小的描述以外(当然,大小都是基于个人的主观判断),还创造性的用康威定律来约束微服务的大小,即“能否和团队结构相匹配”:如果你的团队维护单个服务很吃力,需要保持团队大小不变的情况下还对维护工作游刃有余,那么这个服务就需要继续被拆分。

而“自治” 则很谨慎的把 Martin Fowler 微服务定义的 9 大特征中的“去中心化”、“独立” 、”松散耦合“等字眼进行了统一。并进一步解释到“一个微服务就是一个独立的实体”。并且从外部,也就是黑盒的角度来看每个符合”自治”的单个微服务所具有的特征,即:

  1. 可以独立部署。
  2. 通过网络通信。
  3. 对消费方的透明。
  4. 尽可能降低耦合,使其自治。

此外,他还采用了更简单的“黄金法则”来判断期”自治性”。即能否修改一个服务并对其部署,且不影响其他任何服务。如果答案是否定的,说明你的微服务还不够”自治“。

从 Sam Newman 的定义中,我们可以推导出“微服务”的几个基本事实:

  1. 微服务架构是一个分布式系统架构。
  2. 微服务是微服务架构的基本单元。
  3. 网络隔离是“必要的”解耦手段。
  4. 微服务的业务功能从概念上是完整的,并符合用户角度的“独立”认知。

简而言之,以上的两个特征的表述主要是将微服务从逻辑架构上和部署架构上都看作是一个正交的原子功能单元。而要做到这一点,则需要而要把整个应用系统正确的建模到这个层次,则需要参考很多的内部外部因素。

此外,为了达到“小”和“自治”的目的,Sam Newman 还总结了 7 条原则用来在实施的时候和具体实践结合,分别是:

  1. 围绕业务概念建模
  2. 接受自动化文化
  3. 隐藏内部实现细节
  4. 让一切都去中心化
  5. 可独立部署
  6. 隔离失败
  7. 高度可观察

可以看出,Sam Newman 把 Martin Fowler 的 9 大特征用更加具体的术语来重新描述,并且从逻辑上处理了 Martin Fowler 微服务 9 大特征中概念重复和不明确的部分,使其更简单和明确并且更加可操作。例如把“去中心化的数据管理” 和 “去中心化治理”合并为“让一切都去中心化”等。

更重要的是,Sam Newman 提出了采用微服务技术的主要好处,告诉了我们“为什么要用微服务”:

  1. 技术异构性:采用更合适的技术栈灵活的处理局部问题。
  2. 弹性:这里的“弹性”是弹性工程学的概念,指的是局部失败会被隔离,使得整体不会失败。
  3. 扩展:可以根据系统的部分组件按需扩展。
  4. 简化部署:这里简化部署不是指的是部署的拓扑结构,而是通过持续的小批量、小范围的部署来降低整体失败的风险。
  5. 与组织结构相匹配:微服务架构可以让组织的团队转化为合适的大小,并采用透明的制度来进行规范和复制。避免团队的人数增长而带来更多的管理层,使组织熵的上涨。
  6. 可组合性:由于各个微服务间不存在依赖关系,所以可以根据用户界面的情况进行灵活的调整和复用,避免对单体应用进行整体的大规模调整。
  7. 对可替代性的优化:由于风险和领域更加独立和隔离。因此,抛弃一个微服务并重写的成本并就变的十分低廉。

Chris Richardson 的“微服务架构模式”

2017 年,Chris Richardson 使用 Microservices.io 域名开始推广自己的微服务理念。他是这样定义微服务的:

Microservices – also known as the microservice architecture – is an architectural style that structures an application as a collection of loosely coupled services, which implement business capabilities. The microservice architecture enables the continuous delivery/deployment of large, complex applications. It also enables an organization to evolve its technology stack.

中文翻译过来,大意如下:

微服务,也就是微服务架构。是一种用于把一个应用程序结构化为一个实现业务功能的松散耦合的服务集合的架构风格。 微服务架构使得在大型、复杂的应用程序中实现持续交付和持续部署成为可能。它使得组织可以演进自己的技术栈。

在 Chris Richardson 采用了较为简单的架构定义和准确的目标定义相结合的方式来定义”微服务架构“:它一方面简单的把微服务架构定义成一个实现业务功能的松散耦合的服务集合,另一方面又以十分具体的目标和结果(持续交付/持续集成)来约束这样一个松散耦合系统的效果:组织可以演进自己的技术栈。

Chris Richardson 将“单体架构”和“微服务架构”看做两种架构模式。并且在同样的上下文中对二者各自的优劣进行了比较。更加重要的是,Chris Richardson 采用 AFK 扩展立方来拆分微服务从而回答了“如何做微服务”的问题。

值得注意的是,Chris Richardson 所采用的例子虽然在同样的上下文中,但由于特征不同并不具备可比较性。因此,他采用了在“单体架构模式”(Pattern: Monolithic Architecture)的基础上描述其局限性的方法引出了“微服务架构模式”(Pattern: Microservice Architecture)。严格的说,Chris Richardson 的“单体架构模式”是一种对现状的和举例,并没有给出其特征和方法的描述,因此不能称之为模式。而“微服务架构模式”则又是一系列模式的总和,如下图所示:

从这个角度看,Chris Richardson 的这些模式并没有突破 Sam Newman 在《微服务设计》中总结出的实践。但相较于我们所知道的微服务的优点。Chris Richardson 也列出了微服务的缺点:

  1. 开发者的 IDE 对分布式系统的在线开发和调试相对于单体应用架构来说并不友好。
  2. 测试更加困难。
  3. 开发者必须实现跨服务的通信机制。
  4. 不采用分布式事务来跨服务构建业务是十分困难的。
  5. 需要进行跨团队的协调工作。
  6. 部署更加复杂。
  7. 更多的内存消费,对于 Java 应用来说,独立的部署意味着无法共享 JVM 的内存管理。

相较于之前的微服务定义而言, Chris Richardson 的微服务体系比较完整,而不仅仅是总结和列举实践。Chris Richardson 的”微服务架构模式”不光回答了“什么是(What)微服务”,也回答了“为什么(Why)要用微服务”,“什么时候(When)用微服务”,“什么场景(Where)下”以及“如何(How)实现微服务”的问题。

Chris Richardson 还编写了一套微服务的指南,可以在这里查看。

比“什么是微服务”更重要的事

本文总结了微服务常见的 4 个定义。但比这些定义更重要的是你为什么要用微服务?你想从微服务中获得什么益处?你是否了解为了追求这些益处所带来的代价?如果不先明确这些问题,在不理解微服务架构或者技术所带来的的风险和成本。盲目的采用所谓的微服务,可能带来的结果并不理想。

不过,在讨论这些问题之前,坐下来统一一下对微服务的理解,会提升我们讨论和实践微服务的效率。


更多精彩洞见,请关注微信公众号:思特沃克

Share

识别领域事件

随着微服务架构的兴起,微服务设计与拆分的的最佳实践DDD已然成为大家讨论与实践的热点,整个行业都在探索如何用DDD建模来实现微服务设计。事件风暴作为最接地气的实践,在不同的项目中野蛮生长,不断演进,今天已经渐渐成熟。作为事件风暴的灵魂——领域事件,值得我们投入更多的精力去设计与打磨。

领域事件是用特定方式(已发生的时态)表达发生在问题域中的重要事情,是领域通用语言(UL)的一部分。为了方便理解这个概念,这里举一个宠物的例子:如果做为宠物主人,你的问题域是如何养好一只猫,那么是不是已经打了疫苗,给宠物饲喂食物等将成为你关注的事情,领域事件会有:疫苗已注射,猫粮已饲喂等。如果你是宠物医生,问题域是如何治好宠物的病,关注的事情是宠物的身体构成,准确的诊断宠物病情,对症下药,领域事件会有:病情已确诊,药方已开治。虽说二者关注的都是宠物,在不同的问题域下领域事件是不同的。

DDD的提出者和圈内的大师先后提到领域事件在领域建模中的价值,前沿实践者们已经开始应用领域事件来表达业务全景。在DDD建模过程中,以领域事件为线索逐步得到领域模型已经成为了主流的实践,即:事件风暴。

事件风暴是以更专注的方式发现与提取领域事件,并将以领域事件为中心的概念模型逐渐演化成以聚合为中心的领域模型,以快速可落地的方式实现了DDD建模。

对于高质量的事件风暴,首先要解决识别领域事件的问题,理想的情况下领域专家和研发团队一起参加事件风暴,从业务的视角去分析涉众关心的领域事件,短时间内高度可视化交流,集中思考,快速发散收敛形成所有参与者一致认可的领域事件集合。我在多个项目上实现事件风暴后,总结了一些坑和应对办法,供大家参考:

1. 组织没有领域专家

对问题域有深刻见解的主题专家称为领域专家,在大多数组织中没有这个角色,当DDD建模需要领域专家支持时,组织往往找业务部门的业务人员,BA,产品经理或在这个领域有多年开发经验的DEV来充当。

这些一线业务人员和开发团队都清楚有什么功能,但往往不清楚为什么有这些功能。举个例子:如果我们的问题是打开一瓶红酒,你去调研每天都会打开酒瓶的waiter, 给你的答案是:开瓶器。但换做领域专家的视角来看,会回归问题的本质,如果我们希望打开酒瓶,需要把瓶塞移除,移除瓶塞的方式有多种,包括推,撬与拉拽,对于拉拽可能基于吸力或螺旋拉拽,下面右图的开瓶器只不过是螺旋拉拽的一种解决方案。领域专家应该对问题域及其中的各种可行方案有更深入的理解。

在辅导团队的过程中,为了弥补这部分视角的缺失,往往会在事件风暴之前,组织业务愿景和场景分析,与被指派的业务干系人对齐业务愿景,一起分析业务场景背后的问题域,找到问题域的本质后再展开事件风暴。

2. 面向复杂业务系统的事件风暴

高效事件风暴的规模推荐5-8人,超过8人的事件风暴就会出现讨论时间过长,部分成员参与度不高,业务之间的相关度弱等问题。在一个以支付中台为主题的事件风暴中,对于电商商城的支付与理财产品的支付相关性就很弱,各自关心的是自己的业务,让这两组人在一起讨论,在得到同样产出的情况下,会花费双倍的时间。

在处理复杂问题时,一个有效又好用的方法就是分而治之,对于复杂系统的事件风暴也是同样如此。在业务干系人达到一定规模后,将业务干系人分成多组,组织多轮事件风暴,迭代演进领域模型也是一种不错的选择。

分组的基本原则应以业务线为线索,如果目标系统的业务干系人在同一个业务主线上,每一组人代表业务主线上的一个环节 (如下图),这种情况按照业务结点进行分组即可。对于业务相对简单的结点,可以将其与相临结点合并组织事件风暴。

当目标系统是多条业务线上的某几个公共结点,一般业务中台会出现这种情况,如支付中台要为不同的业务部门(保险,商城,还信用卡等)提供支付服务,如下图中的虚线部分。这类业务往往结点之间的边界并没有那么清楚,系统做什么与不做什么只有在梳理完整条业务线才能确认下来,这种情况按每条业务线分组展开事件风暴,然后针对多组产出结果进行统一业务概念抽象,建立系统边界内的统一事件流。

3. 业务代表或领域专家用自己的语言表达业务

事件风暴的第一个环节是让参与者头脑风暴,各自找出业务干系人关注的领域事件,对于业务干系人来讲,往往不适应把自己理解的业务按领域事件的方式表达出来,他们看到一串领域事件,也不觉得这种表达方式比传统方式直观,在这种情况下,我们就需要考虑如何引导业务共同输出领域事件。留心领域专家在表达需求过程中的一些模式:

1. 当…
2. 如果发生…
3. 当…的时候请通知我
4. 发生…时

通过模式中的关键字转换成领域事件,按时间顺序排序后,基于商业模式与价值定位与领域专家讨论领域事件,以统一的语言与统一的业务视角修正并验证领域事件。高质量的领域事件定义自然是清楚的,是可以找到问题域中的某个actor是关注它的,通过讲述领域事件是可以体现商业价值的。

4. 事件风暴可能识别不出来所有领域事件

通过事件风暴可以快速把整个问题域主线梳理出来,这样的产出是相当的高效和有价值,但对于正在尝试用事件风暴成果代替传统交付物的组织,往往会质疑事件风暴是否可以发现所有领域事件。

试考虑一个投资者,为一座摩天大楼的建造提供资金,投资者未必对建造过程的细节感兴趣,材料的选择及各种工程细节会议对于建造者来说是很重要的活动,对于投资者来讲,感兴趣的是良好的投资回报,保护投资免受风险,较为务实的投资者会设立明确的里程碑,每个里程碑通过后再做下一次注资。例如,在项目开始时,提供适量资金进行建筑设计工作。当建造事宜被批准时,再为项目提供较多的资金以进行设计工作。在设计通过评审通过后,才拔给更大量的资金,以便建造者破土动工。梳理得到事件如下:

系统建模同理,我们不关注所有事件,仅关注对干系人解决特定问题有价值的事件,并且这个特定问题应该已经在项目初期,业务愿景梳理的过程中在组织内达成了共识,就像上述投资者关注的问题一样清楚,在业务场景梳理与事件风暴的过程中,不断还原具体过程,以确保识别出的活动或事件真正可以解决业务问题。所以在事件风暴的过程中,并不需要担心是不是找出所有领域事件,只要真正解决了业务问题就好了。

另外,当开始采用新的方法论时,实践过程与角度都有差别,旧有体系的交付物不适用是常有的情况,重点关注的新的方法会不会以更简洁的方式解决实际问题。在存疑的风险处,活学活用新方法的交付物能够让组织更顺利的落地,当然必要的开发过程与交付物改进也是需要的,即可以更高效的完成设计工作,也能够让团队更专注在问题上。

总结

有人说微服务的设计与拆分是一门艺术,经验性的成份占了很大比重。当我们准备基于经验来做微服务的设计决策时,结合业务愿景,找出问题域内所有业务干系人真正关心的领域事件,展开完整的事件风暴,循序渐进的让场景变得更加具体,让经验与艺术在生动的问题域之中得到最大的发挥。

另一方面,有效地识别领域事件,既统一了语言,又助力在模型中体现出业务价值部分,为设计关注业务价值的领域模型打下了坚实的基础。


更多精彩洞见,请关注微信公众号:思特沃克

Share

无服务器架构下的运维

前言

在介绍运维之前,大家先来快速了解一下无服务器(serverless)的概念。由于笔者的实战经验是在AWS平台上,本文中出现的无服务器均指使用AWS Lambda构建的serverless应用。Serverless的特点是用户无需预配置或管理服务器,只需要部署功能代码,服务会在需要的时候执行代码并自动伸缩,从每天几个请求到每秒数千个请求,轻松地实现FaaS(Function as a Service)。如下图所示:

(图片来自网络)

在传统的应用中,开发团队除了需要编写功能代码,还要监控实时负载,并相应地对应用进行伸缩,还要处理一些因非功能性故障导致的停机(硬盘、内存等)。而无服务器架构则将开发团队从服务器维护的工作中解放出来,继而能更专注在功能代码上(图中的Function)。在实际的项目里,开发者只需将功能代码打包上传到AWS Lambda,再进行少量配置(环境变量,触发条件,内存,超时时间等)即可将应用/服务上线。

以上是无服务器架构的基本概念。接下来,笔者将从日志,指标,监控及报警,灾备这四个维度来介绍无服务器架构下的运维。

日志

默认情况下,应用运行时产生的日志会保存在应用服务器本机,在需要查看日志的时候,需要运维人员远程登录到这台服务器获取日志信息。这种方式操作起来稍显繁琐,而且当应用服务器的数量增多后,由于需要先找出产生错误信息的那台服务器,会严重降低查找日志的效率。

一种解决办法是ELK(ElasticSearch, Logstash, Kibana),这三个开源工具各司其职,Logstash负责日志的推送和转换,ElasticSearch作为数据库与搜索引擎,Kibana作为图形界面。好处是搭建容易,良好的伸缩性,以及免费。但带来的额外成本是,独立出来的日志服务也需要做好全方位的监控(应用状态,硬盘,网络等),避免因为基础服务的问题导致系统全面故障。

AWS无服务器架构中的日志是一个开箱即用的服务,所有日志自动采集到AWS CloudWatch Logs中,只要根据服务名称找到对应的日志组,即可进行查询搜索,不需要任何配置,也没有任何维护成本。

指标

通常情况下,运维工作会包含采集线上应用的运行指标,来反映应用的健康状况,故障率,性能,访问量,访问频率等。这里以一个使用Spring Boot构建的API服务来举例,Spring Boot中的Actuator扮演了采集指标的角色。默认配置下,对于每个API,Actuator会自动采集以下几个指标:

  • uri,例如/api/person/{id}
  • method,例如GET或POST
  • status,例如200或500

当然我们可以通过实现一些接口来扩展/自定义采集指标,这里就不展开了。有了指标数据,还需要对应的报表或仪表盘工具,以便更好地查询和展示,可以选择像Prometheus,Grafana这样的工具。

那么AWS无服务器架构是否提供了类似的指标采集呢?答案是肯定的,AWS CloudWatch Metrics自动采集了Lambda function的以下四个指标:

  • Invocations(实际调用量)
  • Errors
  • Duration(执行时间)
  • Throttles(超过并行限制而被阻止的调用的数量)

Invocations和Errors取一段时间的总数,结合二者可以得出应用的错误率,如下

Duration则通过取平均数来反映一段时间的性能表现,在笔者的项目中Lambda function的耗时主要集中在SQL的查询上,这个数字可以相应地反映技术人员对查询优化的效果。当然,在实际情况中,这些检验都可以在预发布环境下进行,这个例子只是为了方便理解。

在笔者目前的项目中,Throttle并未被使用到,默认的并发限制是1000/秒,而用量最大的Lambda function的调用频率也不过每分钟150次,距离超限差得很远,不过这一数据对于并发高的应用有很重要的意义。

除了开箱即用的几个指标以外,还可以结合CloudWatch metrics的API,在相应的功能代码中埋点,定制化采集指标。例如,对于一个Lambda function,代码里三个子task,默认提供的Duration只能反映总体的运行效率,如果需要统计每个task的消耗,就需要用到AWS CloudWatch metrics API。

监控&报警

监控的意义在于全面了解应用的资源使用率,性能和运行情况,这些数据可以用来帮助团队及时作出调整,保证应用程序顺畅运行。这通常包括CPU使用率,数据传输,磁盘使用等。在突发状况导致系统不可用的时候,团队的响应速度,往往取决于监控和报警的及时性,全面性和准确度。如果能在对历史数据的分析之上对监控系统进行合理的配置,团队甚至能预测不好的事情将要发生,提前做好防范,未雨绸缪。

同上,这里还是以一个Spring Boot应用为例,在上一小节指标数据的采集中提到过Actuator,事实上Actuator除了可以记录上面提到的指标,还可以用来收集监控数据。这里我们只需要设置一个Spring Boot Admin应用,给需要进行监控的应用加上Spring Boot Admin client配置,监控数据就会通过Actuator暴露的API传递给Spring Boot Admin。

报警功能一般则要根据实际情况自行实现。Spring Boot Admin中实现了对Pagerduty,Slack等第三方工具的集成,如果只是需要简单的邮件提醒,实现起来也不复杂,这里就不展开了。

随着云上基础设施的普及,上面提到的监控和报警早已是各个平台的标准配置,根本轮不到开发者去操心如何实现及维护,运营团队可以把更多的精力放在配置优化的工作中去。

AWS默认提供了非常完备的监控数据,也允许自定义监控dashboard,通过把一系列重要的指标添加到创建好的dashboard中,应用的运行状况一目了然。

前面已经提到过,在出现错误,或性能底下时,根据某些关键指标的变动情况发送警告通知非常必要。笔者所在的项目的做法是使用AWS CloudWatch和AWS SNS提供的告警通知功能,只需要先选择指标然后设定触发阈值和检查间隔时间即可,AWS SNS支持HTTP、SMS、Email等多种订阅方式。下图展示了如何设定当某个Lambda在过去5分钟内发生了5次以上错误的时候发送通知。

灾难备份&恢复

在系统镜像,构建工具还有容器技术越来越普及的今天,灾难备份的意义很大程度上是为了有效保护重要数据。通常的做法是设定一些定期任务,将数据传输到远端的灾备中心,从物理上抵御不可抗灾难。如果数据量过大,出现网络传输效率跟不上的情况,可以参考AWS用卡车拉数据的解决办法。

真正需要用到灾难备份的情况在笔者有限的经历中还没有发生过,但是如果不未雨绸缪,真正发生时的后果将难以设想。笔者项目中用到的AWS RDS默认启用了以7天为周期的自动备份,这个配置可以手动调整也可以将配置写入构建基础设施的脚本中去。 如果灾难真的发生,光有数据备份是不够的,还需要能够快速重建应用运行时的基础设施。笔者所在的团队(下文简称团队)分别使用了AWS CloudFormationServerless framework,CloudFormation用来重建数据库、网络等基础设施,Serverless framework用来重建Lambda function,在重建数据库的时候,通过持续集成流水线,以环境变量的方式传入最近一次数据备份快照的Id,15分钟以内即可重建一套产品环境。

总结

笔者所在的团队是10个人左右的配置,采用结对编程的方式,3对pair,包含web端、业务层、数据层。从产品原型确定到第一次上线(MVP)耗时30天,每周至少发布一次新版本,story的平均交付时间(cycle time,从需求确定到上线)为8天。这样的速度也许不能算快,但是如果没有Serverless架构在运维端提供的支持,我们想要在交付速度上有更高的突破会困难得多。

最后来谈一下成本,俗话说抛开商业化谈技术都是耍流氓,大部分人看到一个强大易用的工具都会下意识里觉得开销会很大。实际上并不是这样,我们做了一个粗算,选用双核CPU,8G内存的M4型服务器,开销是$72每月。dev,staging,prod三个环境都用同样的配置就是$216每月,而实际上Lambda每个月的开销包含所有环境在$20左右,需要注意的是Lambda的计费是根据使用量来的,我们的API访问大约在150万每月的量级。可以预见到当访问达到一定数量的时候Lambda的开销会和使用服务器的方案持平甚至更大,但是在量小的时候优势明显。

得益于强大的AWS生态,利用Lambda构建的无服务器应用经过少量甚至无需任何配置,即可以极低的价格获得完整的运维功能和体验。与自己利用开源工具进行搭建的方式相比,研发团队可以从繁琐的运维工作——特别是基础工程搭建——中解脱出来,更加专注于产品本身,极大的提高软件交付速度,可用性、可靠性和可扩展性也相当有保障。换来的代价是更高的迁移成本,某些功能的不可定制化可能成为瓶颈,以及对底层实现原理的屏蔽也可能对开发者的学习和成长有影响。


更多精彩洞见,请关注微信公众号:思特沃克

Share