• 软件设计:为什么每个类都应该是一个服务
  • 勇在天涯 发表于 2016/7/6 13:54:00 | 分类标签: 设计模式 WCF编程
  • 许多人都认为,Juval Löwy是想让服务无所不在,但他辩称,微服务只是深思熟虑之后系统分解的逻辑结果。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    关于受访者

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

    ·自觉遵守:爱国、守法、自律、真实、文明的原则

    ·尊重网上道德,遵守《全国人大常委会关于维护互联网安全的决定》及中华人民共和国其他各项有关法律法规

    ·严禁发表危害国家安全,破坏民族团结、国家宗教政策和社会稳定,含侮辱、诽谤、教唆、淫秽等内容的作品

    ·承担一切因您的行为而直接或间接导致的民事或刑事法律责任

    ·您在编程中国社区新闻评论发表的作品,本网站有权在网站内保留、转载、引用或者删除

    ·参与本评论即表明您已经阅读并接受上述条款

  • 感谢本文作者
  • 作者头像
  • 昵称:勇在天涯
  • 加入时间:2013/5/15 0:00:00
  • TA的签名
  • 这家伙很懒,虾米都没写
  • +进入TA的空间
  • 以下内容也很赞哦
分享按钮