许多人都认为&＃xff0c;Juval Löwy是想让服务无所不在&＃xff0c;但他辩称&＃xff0c;微服务只是深思熟虑之后系统分解的逻辑结果。
\\
在Löwy设计和构建的系统中&＃xff0c;每个类都是一个服务&＃xff0c;这是他在2007开创的一种方法&＃xff0c;在《WCF服务编程》第四版中&＃xff0c;他进一步阐述了这一方法。面向服务的应用程序更容易维护&＃xff0c;因为业务逻辑和底层管道完全隔离&＃xff0c;Löwy已经克服了软件开发平台的局限&＃xff0c;将这种隔离推广到了系统的所有层面。
\\
InfoQ采访了Löwy&＃xff0c;内容涉及软件设计方法以及传统方法中经常失败的地方。
\\
InfoQ&＃xff1a;您提出“每个类作为一个服务”的理念已经10多年了。是什么让您想到了这种方法&＃xff1f;
\\
\ Juval Löwy&＃xff1a;一般来说&＃xff0c;面向服务并不是一种质的飞跃——它只是漫长的软件工程演进过程的下一个步骤。例如&＃xff0c;如果面向对象是一个好主意&＃xff0c;那么你就不会停留在系统或子系统的层面上&＃xff0c;并说那个粒度和对象一样。恰恰相反&＃xff0c;你会设法将对象的优势尽可能地往下推&＃xff0c;甚至创建基元对象。
\\ 服务是行业的一次尝试&＃xff0c;旨在将业务逻辑&＃xff08;这是客户关心和购买的东西&＃xff09;和支撑业务逻辑的底层管道解耦&＃xff0c;后者包括安全、激活、同步、事务、错误处理、部署&＃xff0c;等等。事实证明&＃xff0c;管道占用了大部分的开发时间和工作&＃xff0c;而开发人员往往在这方面做得并不好。借助微服务&＃xff0c;你就可以选择使用预先构建好的、现成的管道&＃xff0c;这样&＃xff0c;你就可以在保持管道界限不变的同时&＃xff0c;从标准管道中获益。
\\ 不注意范围&＃xff08;企业、系统、子系统、类&＃xff09;的话&＃xff0c;管道会带来麻烦&＃xff0c;所以不难理解&＃xff0c;要尽可能地利用服务所带来的好处。由此可以得出最终的结论&＃xff0c;整数或字符串必须是服务。为什么开发人员要考虑字符串安全、整数同步等问题呢&＃xff1f;
\\ 你所遇到的问题是&＃xff0c;当时&＃xff08;如今&＃xff09;的开发平台没有在这方面提供开箱即用的支持。不过&＃xff0c;我解决了这个问题&＃xff0c;并提出了一种增强技术&＃xff0c;只要你愿意&＃xff0c;就可以在类的层面上使用服务&＃xff0c;同时还可以保持现有的编程模型和常规类的总拥有成本不变。
\
\\
InfoQ&＃xff1a;过去十年中&＃xff0c;“每个类作为一个服务”的方法与SOA模式相比怎么样&＃xff0c;与我们如今看到的微服务运动相比又怎么样&＃xff1f;
\\
\ Löwy&＃xff1a;比较意味着对立或矛盾。但它们之间不存在那种关系。为了取得成功&＃xff0c;你应该在我十年前提出的粒度上使用服务。这恰恰是合理的设计。
\\ 你的身体不是个大问题。但只有一个巨大单体服务的系统是不具可维护性的&＃xff0c;它充斥着缺陷&＃xff0c;会带来痛苦。没有什么可以重用和扩展。
\\ 为外界提供一个“大”服务或功能没什么错&＃xff0c;但实现方式应该是通过集成微服务。顺便说一下&＃xff0c;这是个通用的设计规则&＃xff1a;功能一值都是整合出来的&＃xff0c;而不是实现出来的。任何东西都是这样的&＃xff0c;如马、汽车、平板电脑、工厂&＃xff0c;等等。汽车有一个重要的功能&＃xff0c;就是可以把你从A地点带到B地点&＃xff0c;但汽车并没有提供开箱即用的实现。这个功能是通过整合汽车的内部组件、司机、燃料和公路提供的。
\
\\
InfoQ&＃xff1a;如何正确地分解系统&＃xff1f;那与传统的设计方法有什么不同&＃xff1f;
\\
\ Löwy&＃xff1a;事实证明&＃xff0c;大部分人都是根据功能或领域来分解设计的。因此&＃xff0c;如果需要完成A、B、C&＃xff0c;他们就会有一个A服务、一个B服务、一个C服务&＃xff0c;或者他们会找个地方&＃xff08;领域&＃xff09;安置A或B。这种方法的问题是&＃xff0c;随着时间推移&＃xff08;不用太长时间&＃xff09;&＃xff0c;需要做的东西会发生变化&＃xff0c;其结果就是&＃xff0c;设计需要修改。当设计需要修改时就非常痛苦了。
\\ 结论是&＃xff0c;你永远不应该针对需求&＃xff08;或功能&＃xff0c;或用例&＃xff0c;或用户故事&＃xff09;进行设计。相反&＃xff0c;你必须识别出构建块的最小集合&＃xff0c;如果你愿意&＃xff0c;可以称它们为微服务&＃xff0c;你可以把它们组合在一起满足任何需求&＃xff1a;现在的和未来的&＃xff0c;已知的和未知的。关于如何做到这一点&＃xff0c;有一个完善的过程。
\\ 正确的设计方法是确定出容易变化的部分&＃xff0c;把它们封装进&＃xff08;微&＃xff09;服务。然后&＃xff0c;你就可以将需要的行为实现为那些服务之间的交互。新需求只不过意味着一种不同的服务交互&＃xff0c;而不是一种不同的分解&＃xff0c;所以现在&＃xff0c;当需求变化时&＃xff0c;设计无需修改。
\\ 此外&＃xff0c;由于分解是根据容易变化的部分进行的&＃xff0c;当变化发生时&＃xff0c;只需在一个地方处理它&＃xff0c;这样&＃xff0c;你就遏制了变化。使用功能或领域分解&＃xff0c;当变化发生时&＃xff0c;它影响的不只一个地方&＃xff0c;所以你就最大化了变化的影响&＃xff0c;让它成为最糟糕的架构设计方法。
\\ 微服务极大地增强了这种分解方法&＃xff0c;因为服务就是要简化交互和集成。此外&＃xff0c;在大部分软件系统中&＃xff0c;容易变化的部分都很典型&＃xff0c;所以&＃xff0c;你可以以此为起点。这些部分也会有典型的交互模式&＃xff0c;所以&＃xff0c;一旦识别了出来&＃xff0c;设计就会非常快速正确地收敛。
\
\\
InfoQ&＃xff1a;在基于易变性进行分解之后&＃xff0c;开发过程该如何适应一个高度模块化的系统构建方法&＃xff1f;
\\
\ Löwy&＃xff1a;你要设计和构建服务&＃xff0c;但也要构建装配它们的工厂。当你想要生产汽车时&＃xff0c;你首先要设计汽车的各个组件&＃xff08;变速箱、引擎、油泵、座椅&＃xff0c;等等&＃xff09;&＃xff0c;但你还必须设计装配线来将这些零件组装在一起。从设计的角度看&＃xff0c;它甚至比零件或汽车本身的设计更具挑战性。任何人都可以设计汽车油泵。设计一种可以满足数百种汽车的油泵&＃xff0c;或者设计一条可以组装很多不同汽车的装配线&＃xff0c;可不是一件简单的事情。
\\ 在软件领域&＃xff0c;你要设计微服务&＃xff08;零件&＃xff09;和项目&＃xff08;装配线&＃xff09;。这不是偶然或意外。你不会偶然建立一座工厂。借助经验与实践&＃xff0c;你还可以引入多个管道&＃xff0c;如服务、单元测试、集成等&＃xff0c;提升工厂的生产能力。你所做的一切都是遵循一套完善的工程指南&＃xff0c;而后者来自于容易变化的部分之间特定的交互模式。
\\ 其结果是超级敏捷&＃xff0c;因为使用那些微服务&＃xff0c;你可以非常快地准备好新特性和行为。借用敏捷术语来说&＃xff0c;你使用已经构建的微服务实现了用户故事&＃xff0c;理论上不需要任何新代码。在一座汽车工厂中&＃xff0c;实际的生产非常少——零件整个地到达工厂&＃xff0c;他们只是整合它们。
\
\\
关于受访者
\\
Juval Löwy是IDesign的创建者&＃xff0c;同时也是一名专门研究系统和项目设计的大师级软件架构师。Löwy对全球数百名架构师进行过指导&＃xff0c;分享他在架构、项目设计、开发过程和技术方面的观点、技巧和突破性创新。Löwy是微软硅谷地区的区域负责人&＃xff0c;参与过微软内部C#、WCF及相关技术的战略设计评审。Löwy经常在各种重大的国际软件开发大会上发表演讲。他已经出版了多本畅销书&＃xff0c;并发表了大量的文章。作为世界上最顶尖的专家和行业领导者之一&＃xff0c;微软授予他“软件传奇”称号。你可以通过他的网站和他取得联系。
\\
查看英文原文&＃xff1a;Juval Löwy: Why Every Class Should Be a Service
京公网安备 11010802041100号