写点什么

微服务意味着分布式系统

  • 2016-09-17
  • 本文字数:3404 字

    阅读完需:约 11 分钟

Sander Hoogendoorn 认为,向微服务迁移就意味着向分布式系统进行迁移,在这里,我们必须要处理延迟、认证与授权、无法到达的消息。通过使用微服务,我们能够将大型系统拆分为更小的组件,从而实现对架构的重新掌控。借助于微服务,我们可以通过扩展并部署单个或一组组件的方式,实现小的变更或添加单独的特性。

Hoogendoorn 会在 9 月 12 至 13 日举行的 SwanseaCon 2016 上做最终的主题演讲,这是在南威尔士举行的第二个有关敏捷开发和软件匠艺的会议。InfoQ 对他进行了采访,我们讨论了多个话题,包括单体架构的软件产品的问题、如何使用微服务来构建最小化的可行产品、微服务的测试、微服务如何适应持续交付、微服务的优势和劣势,针对希望实现微服务的组织,他还给出了自己的建议。

有很多人针对微服务相关的话题撰写过文章,涵盖了如何使用和测试微服务、因使用微服务而创建的分布式系统所带来的额外复杂性该如何进行处理,并提供了在组织中实现微服务的建议。

InfoQ:在组织中,采用单体架构的软件产品的最大问题是什么?

Sander Hoogendoorn:单体的系统,不管是采用什么语言编写,运行在什么平台上,随着时间的推移都会不断增长。这意味着会有很多不同的人针对它们来开展工作,每个人在写代码的时候,都有其自己的风格。在系统存在的这些年中,会有特性的添加、修改和移除,这通常会导致不稳定架构的出现。另外,系统不是隔离运行的,通常会与更为广泛的系统进行集成,这样的话,会带来大量的外部接口。

因为很难集成新的特性,所以很多的组织在推出某项新特性的时候会耗费很长的时间才能将其推向市场。创新会减缓,经常会很难甚至根本不可能去拥抱新的技术。

InfoQ:微服务是如何为这些问题提供解决方案的呢?

Hoogendoorn:微服务架构的基本理念就是将大型的系统拆分为更小的组件,因此帮助组织实现对系统架构的重新掌控。这些组件之间的交流会通过易于使用的协议来实现,如基于 HTTP 的 REST 和 JSON。这个词的前缀“微”意味着组件会按照代码行或服务端点的数量来进行衡量,但是我更喜欢采用领域驱动设计范式中的有界上下文(bounded context)来拆分系统,在这里每个组件会负责处理系统领域中一个独立的部分。

在 InfoQ 关于微服务反模式的文章中,Vijay Alagarasan 阐述了微服务与面向服务架构(SOA)之间的关联关系:

如果你没有合适的人、文化和投入的话,SOA 不会实现其业务价值。微服务架构与 SOA 没有本质的差异,它们的目标是一致的,但是微服务的方式更加精细,我可以这样说,微服务就是实现了可扩展性的 SOA。

InfoQ:你们如何使用微服务构建最小化的可行产品(Minimum Viable Product)呢?

Hoogendoorn:按照最小化可行产品的思考方式,意味着要持续关注为产品新增价值,这需要通过提供该价值的最小版本来实现。微服务允许我们通过扩展一个或一组组件,为其添加独立的特性,并将它们(独立地)部署到系统之中。如果搭建了对应的持续交付功能,那么部署所修改组件的新版本就可以通过每日的基础代码来进行,当然这需要有相应的自动化测试。按照这种方式,在组织内部就可以持续地实现小的变更。

InfoQ:测试微服务可以采用什么方式呢?

Hoogendoorn:当你将整个系统拆分为很小的组件时,就需要在很多不同的级别来进行测试。首先,单元测试要覆盖到组件内部的所有内容。其次,服务接口需要进行测试,验证它是否会产生正确的输出或文档,比如 JSON 对象或 PDF。下游的应用或其他的组件如果使用该组件所提供的服务,那么它们也需要进行测试,检验组件的输出是否依然正确。在微服务架构中,服务是松耦合的,通常会使用基于 HTTP 协议的 REST 和 JSON,因此对于某个服务接口的变更,团队不一定马上就能意识得到。在组件的每次变更之后,都要运行自动化测试,这样的话,整个管道(pipeline)就能尽可能快地发现破坏性的变更。随着组件和服务数量的增长,测试的数量也会快速膨胀,在微服务架构中,我推荐让所有的测试都能实现自动化。

在一个关于微服务开发和测试的采访中,来自 Redgate 软件的 Jose Lima 则认为在微服务中,你并不需要将所有的测试都实现自动化,可以由其他的人实现功能检查,而不一定通过测试人员来完成:

有些人会认为测试自动化同样也是一项必备的技能,但我并不认同。首先,我不相信测试自动化,其次,检查自动化也可以由团队的其他人员来执行,并非一定要由测试人员来执行。并没有什么所谓的测试自动化,但肯定有检查自动化——对我而言,测试涵盖的内容要比检查更多,检查的过程可以进行自动化,不过只有你理解了要做什么以及这意味着什么之后,你才能够将功能检查做好(不管是否采用自动化),这样的话就能检查它的行为是否符合预期。

InfoQ:微服务是如何与持续交付协作的?

Hoogendoorn:借助持续交付,每项变更都会成为发布版本的备选内容。在微服务架构中,这意味着一个或一组组件会持续有新版本发布出来。因为这些组件会发布到分布式系统或互相协作的服务之中,所以设计良好部署管道就显得尤为重要,管道需要集成自动化测试的功能,这甚至比持续交付与单体架构结合使用时更为重要。你可能会说在理论上持续交付和微服务能够很好地进行协同。但在我的经验中,组织内将会面临大量的配置,这样做并不一定总能让事情变得更简单。

按照 Alagarasan 的说法,如果你想要采用微服务的话,持续部署和自动化测试是必需的:

如果你还没有采用持续部署的话,那么作为任意一家企业来讲都应该在这方面进行投资,并致力于实现相关的文化变更。至少,如果你无法实现自动化测试和部署的话,那么就不要采用微服务。微服务的目标在于驱动敏捷性,其中会伴随速度的变化;质量保证会涉及到每一个服务,每项服务都要具有自动化的单元、功能、安全以及性能测试。

InfoQ:微服务的优势和劣势是什么呢?

Hoogendoorn:往微服务架构迁移有助于将大型的系统拆分为更小的组件,从而实现对系统架构的重新掌控。这些独立的组件更加易于管理、替换、部署、扩展和测试。采用新的技术,如新语言、框架或数据库,也会变得更加容易,因为它们可以用于较少的一些组件中,而不必一次性地用到整个系统之中。但是,采用微服务也会带来其他的影响。这些小组件之间的通信会大幅增加。实际上,组织必须要意识到往微服务的迁移就意味着往分布式系统进行迁移,在得到它所有收益的同时,也伴随着分布式系统的所有缺点,包括必须要处理延迟、认证与授权、无法抵达的消息。

在 InfoQ 上一篇名为“微服务:分解应用以实现可部署性和可扩展性”的文章中,Chris Richardson 也认为实现微服务就意味着创建分布式系统:

开发人员必须要处理创建分布式系统所带来的额外的复杂性。开发人员必须要实现进程间的通信机制。要实现跨多个服务的用例的话,如果不使用分布式事务是很难完成的。IDE 以及其他的开发工具关注于开发单体架构的应用,并没有为开发分布式应用提供明确的支持。编写涉及到多个服务的自动化测试用例也是很有挑战的。在开发整体架构应用时,你无需处理这样的问题。

InfoQ:对于希望实现微服务的组织,你有什么建议要给他们吗?

Hoogendoorn:考虑采用微服务的组织应该有这样做的正当理由,而不仅仅因为这是当下最火的技术。这样做的理由可以包括当前的系统无法维护、新技术或平台需要纳入到系统中或者新特性推向市场的时间需要大幅减少。但是,当我们向微服务架构迁移的时候,还有很多的方面要考虑进来。它会改变我们设计、构建和测试软件的方式,它会改变我们搭建部署管道、认证与授权的方式,还会改变团队运维和协作的方式,这甚至会改变与组织内外利益相关者的交流方式。但是最为重要的是,需要意识到你将要构建的是分布式系统,这并不简单。有时候,另外一种方案就是采用与微服务相同的设计技术来拆分单体应用,然后依然在单体应用中重构和模块化我们的代码。

Alagarasan 建议与总经理和高级主管一起协作,推动实现微服务所需的文化变更:

微服务的目标在于解决三个最常见的问题,也就是提升用户体验、应对新需求的高度敏捷性和降低成本,我们借助细粒度的服务来交付业务功能,就可以解决这三个问题。这并不是什么银弹,它需要训练有素的平台,在这里会以敏捷的方式来交付服务,从而使高质量成为了可能。(…)这是我们讨论容器化、云应用等内容之前所必需的一小步。(…) 大多数的行为都会带来组织文化的变更,这是你自己所无法完成的,因此需要确保能够与你的总经理和高级主管进行协作。

查看英文原文 Microservices Imply a Distributed System

2016-09-17 19:006797

评论

发布
暂无评论
发现更多内容

🔎【Java源码探索】深入浅出的分析HashMap(JDK8)

洛神灬殇

Java 源码 源码分析 hashmap 5月日更

用Python在树莓派上播放音乐

IT蜗壳-Tango

5月日更

我厂与张家港市达成全面战略合作,共推数据中心和城市智能化转型

百度大脑

数据中心 城市智能化

走向机器智能时代:移动机器人的困局与创新

晨山资本

机器人 移动机器人 AMR

面阿里P7,竟问这么简单的题目?

Java架构师迁哥

活动预告 _ 即构×火山引擎:泛娱乐社交音视频技术实践沙龙

ZEGO即构

获得业内一致好评!华山版Java性能优化全栈手册“登场”

Java架构追梦

Java 阿里巴巴 架构 性能优化 华山版

40K成功入职:六年开发终获小米Offer(附面经+面试题+答案详解)

Java架构师迁哥

Fabric | 自动化神器

Python研究所

签约计划

脉脉3小时转发65w次!这份Java面试宝典发生了什么?

Java架构师迁哥

服务可达,达者为先,产品发布会嘉宾精彩观点分享!

博睿数据

博睿数据 数据链DNA 服务可达

Vue-1-初识

Python研究所

签约计划

MeterSphere | 超好用的开源测试平台

Python研究所

签约计划

中国呼叫中心与卓越客服产业峰会,百度智能客服再提行业创新

百度大脑

解决方案 行业创新

牛x运维常用的工具系列-1

运维研习社

运维 工具分享 5月日更

MPP大规模并行处理架构详解

五分钟学大数据

大数据 MPP 5月日更

🍃【SpringCloud基础使用】Nacos与Gateway实现动态路由

洛神灬殇

nacos SpringCloud Gateway 5月日更 自定义配置

获5项大奖,发布《云计算开放应用架构标准》,阿里云持续领航云原生

阿里巴巴中间件

云计算 最佳实践 云原生 案例 白皮书

公安局重点人员研判分析系统解决方案

百余大企业共赴新文明之约:2021 DEMO WORLD 世界创新峰会拉开帷幕

创业邦

创新

量化网格策略交易软件,马丁倍投策略机器人

编曲新手可以用什么编曲软件?

奈奈的杂社

编曲 编曲宿主 编曲软件

论证:iOS安全性,为什么需要审核?

37手游iOS技术运营团队

ios SIP Sandbox iOS Developer ios安全

1小时内被全网疯转 29.8w 次,最终被所有大V协力封杀!

Java架构师迁哥

如何评估 Serverless 服务能力?这份报告给出了 40 条标准

Serverless Devs

云计算 云原生 Forrester Wave #Serverless

ARM和X86云服务器的算力对比

Python研究所

签约计划

现在已经卷到需要问三色标记了吗?

艾小仙

工业4.0加速实现“数物相合”,可视化工厂节省时效高达85%

一只数据鲸鱼

人工智能 数据可视化 工业互联网 智慧工厂 智能生产

Bugless 异常监控系统 (iOS端)

37手游iOS技术运营团队

ios iOS Developer 崩溃分析 bugless

答应我,别再学Swing框架了好吗?

北游学Java

Java spring swing

从零开始学习ThingJS之创建App对象

ThingJS数字孪生引擎

可视化 3D可视化 数字孪生

微服务意味着分布式系统_SOA_Ben Linders_InfoQ精选文章