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

微服务 类 分解

摘要

Juval Löwy开创了一种构建面向服务的应用程序的新方法。在这种方法中，每个类本身都代表一个服务。虽然这些应用程序乍一看可能像“类爆炸”，但它们实际上真是系统分解的结果，经过了恰当的分析和设计。Juwal说明了他的意图，并描述了开发团队如何从这个过程中获得提升。

正文

许多人都认为，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