写点什么

Juval Löwy:为什么每个类都应该是一个服务

  • 2016-07-05
  • 本文字数:2469 字

    阅读完需:约 8 分钟

许多人都认为,Juval Löwy 是想让服务无所不在,但他辩称,微服务只是深思熟虑之后系统分解的逻辑结果。

在 Löwy 设计和构建的系统中,每个类都是一个服务,这是他在 2007 开创的一种方法,在《WCF 服务编程》第四版中,他进一步阐述了这一方法。面向服务的应用程序更容易维护,因为业务逻辑和底层管道完全隔离,Löwy 已经克服了软件开发平台的局限,将这种隔离推广到了系统的所有层面。

InfoQ 采访了 Löwy,内容涉及软件设计方法以及传统方法中经常失败的地方。

InfoQ:您提出“每个类作为一个服务”的理念已经 10 多年了。是什么让您想到了这种方法?

Juval Löwy:一般来说,面向服务并不是一种质的飞跃——它只是漫长的软件工程演进过程的下一个步骤。例如,如果面向对象是一个好主意,那么你就不会停留在系统或子系统的层面上,并说那个粒度和对象一样。恰恰相反,你会设法将对象的优势尽可能地往下推,甚至创建基元对象。

服务是行业的一次尝试,旨在将业务逻辑(这是客户关心和购买的东西)和支撑业务逻辑的底层管道解耦,后者包括安全、激活、同步、事务、错误处理、部署,等等。事实证明,管道占用了大部分的开发时间和工作,而开发人员往往在这方面做得并不好。借助微服务,你就可以选择使用预先构建好的、现成的管道,这样,你就可以在保持管道界限不变的同时,从标准管道中获益。

不注意范围(企业、系统、子系统、类)的话,管道会带来麻烦,所以不难理解,要尽可能地利用服务所带来的好处。由此可以得出最终的结论,整数或字符串必须是服务。为什么开发人员要考虑字符串安全、整数同步等问题呢?

你所遇到的问题是,当时(如今)的开发平台没有在这方面提供开箱即用的支持。不过,我解决了这个问题,并提出了一种增强技术,只要你愿意,就可以在类的层面上使用服务,同时还可以保持现有的编程模型和常规类的总拥有成本不变。

InfoQ:过去十年中,“每个类作为一个服务”的方法与 SOA 模式相比怎么样,与我们如今看到的微服务运动相比又怎么样?

Löwy:比较意味着对立或矛盾。但它们之间不存在那种关系。为了取得成功,你应该在我十年前提出的粒度上使用服务。这恰恰是合理的设计。

你的身体不是个大问题。但只有一个巨大单体服务的系统是不具可维护性的,它充斥着缺陷,会带来痛苦。没有什么可以重用和扩展。

为外界提供一个“大”服务或功能没什么错,但实现方式应该是通过集成微服务。顺便说一下,这是个通用的设计规则:功能一值都是整合出来的,而不是实现出来的。任何东西都是这样的,如马、汽车、平板电脑、工厂,等等。汽车有一个重要的功能,就是可以把你从 A 地点带到 B 地点,但汽车并没有提供开箱即用的实现。这个功能是通过整合汽车的内部组件、司机、燃料和公路提供的。

InfoQ:如何正确地分解系统?那与传统的设计方法有什么不同?

Löwy:事实证明,大部分人都是根据功能或领域来分解设计的。因此,如果需要完成 A、B、C,他们就会有一个 A 服务、一个 B 服务、一个 C 服务,或者他们会找个地方(领域)安置 A 或 B。这种方法的问题是,随着时间推移(不用太长时间),需要做的东西会发生变化,其结果就是,设计需要修改。当设计需要修改时就非常痛苦了。

结论是,你永远不应该针对需求(或功能,或用例,或用户故事)进行设计。相反,你必须识别出构建块的最小集合,如果你愿意,可以称它们为微服务,你可以把它们组合在一起满足任何需求:现在的和未来的,已知的和未知的。关于如何做到这一点,有一个完善的过程。

正确的设计方法是确定出容易变化的部分,把它们封装进(微)服务。然后,你就可以将需要的行为实现为那些服务之间的交互。新需求只不过意味着一种不同的服务交互,而不是一种不同的分解,所以现在,当需求变化时,设计无需修改。

此外,由于分解是根据容易变化的部分进行的,当变化发生时,只需在一个地方处理它,这样,你就遏制了变化。使用功能或领域分解,当变化发生时,它影响的不只一个地方,所以你就最大化了变化的影响,让它成为最糟糕的架构设计方法。

微服务极大地增强了这种分解方法,因为服务就是要简化交互和集成。此外,在大部分软件系统中,容易变化的部分都很典型,所以,你可以以此为起点。这些部分也会有典型的交互模式,所以,一旦识别了出来,设计就会非常快速正确地收敛。

InfoQ:在基于易变性进行分解之后,开发过程该如何适应一个高度模块化的系统构建方法?

Löwy:你要设计和构建服务,但也要构建装配它们的工厂。当你想要生产汽车时,你首先要设计汽车的各个组件(变速箱、引擎、油泵、座椅,等等),但你还必须设计装配线来将这些零件组装在一起。从设计的角度看,它甚至比零件或汽车本身的设计更具挑战性。任何人都可以设计汽车油泵。设计一种可以满足数百种汽车的油泵,或者设计一条可以组装很多不同汽车的装配线,可不是一件简单的事情。

在软件领域,你要设计微服务(零件)和项目(装配线)。这不是偶然或意外。你不会偶然建立一座工厂。借助经验与实践,你还可以引入多个管道,如服务、单元测试、集成等,提升工厂的生产能力。你所做的一切都是遵循一套完善的工程指南,而后者来自于容易变化的部分之间特定的交互模式。

其结果是超级敏捷,因为使用那些微服务,你可以非常快地准备好新特性和行为。借用敏捷术语来说,你使用已经构建的微服务实现了用户故事,理论上不需要任何新代码。在一座汽车工厂中,实际的生产非常少——零件整个地到达工厂,他们只是整合它们。

关于受访者

Juval Löwy 是 IDesign 的创建者,同时也是一名专门研究系统和项目设计的大师级软件架构师。Löwy 对全球数百名架构师进行过指导,分享他在架构、项目设计、开发过程和技术方面的观点、技巧和突破性创新。Löwy 是微软硅谷地区的区域负责人,参与过微软内部 C#、WCF 及相关技术的战略设计评审。Löwy 经常在各种重大的国际软件开发大会上发表演讲。他已经出版了多本畅销书,并发表了大量的文章。作为世界上最顶尖的专家和行业领导者之一,微软授予他“软件传奇”称号。你可以通过他的网站和他取得联系。

查看英文原文 Juval Löwy: Why Every Class Should Be a Service

2016-07-05 19:003659
用户头像

发布了 1008 篇内容, 共 387.8 次阅读, 收获喜欢 344 次。

关注

评论

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

Linux系统中“sid”是什么意思?

百度搜索:蓝易云

云计算 Linux 运维 云服务器

程序员金三银四跳槽指南:时间线&经典面试16问

王中阳Go

面试技巧 金三银四 跳槽 跳槽技巧 面试攻略

扯淡的DevOps,我们开发根本不想做运维!

京东科技开发者

灌电流与拉电流的含义及电路解析

芯动大师

Frappe RestAPI 的filters的写法

麦兜

第十周作业

大肚皮狒狒

流计算不止Flink

WuKongCoder

flink 流式计算 RisingWave

Python雪花代码

百度搜索:蓝易云

Python Linux 算法 运维 云服务器

Java:commons-codec实现byte数组和16进制字符串转换

百度搜索:蓝易云

Java Apache Linux 运维 云服务器

浅谈iPaaS对企业转型的重要性

RestCloud

应用集成 ipaas

《计算机程序设计艺术(第3卷):排序与查找》PDF

程序员李木子

GaussDB通信运维:详解stream连接池设计原理

华为云开发者联盟

数据库 华为云 华为云GaussDB 华为云开发者联盟 华为云GaussDB(DWS)

2023 IoTDB Summit:清安储能技术(重庆)有限公司高级 Java 工程师杨泰贤《IoTDB 在清安云能源数据集成的解决方案》

Apache IoTDB

35岁,走出焦虑

芃篙君

#深度思考

第十一周作业

大肚皮狒狒

GIT好习惯助你成为更出色的开发者

南城FE

git 开发者 前端 后端 开发工具

一文搞懂设计模式—门面模式

Java随想录

Java 设计模式

基于OpenTelemetry实现Java微服务调用链跟踪

华为云开发者联盟

Java 微服务 Spring Boot 华为云 华为云开发者联盟

深入了解 Java 方法和参数的使用方法

小万哥

Java 程序人生 编程语言 软件工程 后端开发

第九周作业

大肚皮狒狒

Juval Löwy:为什么每个类都应该是一个服务_SOA_Thomas Betts_InfoQ精选文章