科技行者

行者学院 转型私董会 科技行者专题报道 网红大战科技行者

知识库

知识库 安全导航

至顶网CIO与应用频道CIO加油站微服务架构全解析:绝不是360度无死角

微服务架构全解析:绝不是360度无死角

  • 扫一扫
    分享文章到微信

  • 扫一扫
    关注官方公众号
    至顶头条

鉴于微服务的人气扶摇直上,那些记性不好的人可能忽略了这种方法极其类似面向服务的架构(SOA),20年前SOA第一次出现在世人眼前。草根开发群体的大力支持正在将微服务架构的采用率推到新的高度。

来源:51CTO 2015年7月17日

关键字: IT管理 微服务

  • 评论
  • 分享微博
  • 分享邮件

草根开发群体的大力支持正在将微服务架构的采用率推到新的高度。据红帽公司中间件专家Mark Little博士声称,微服务是个好东西,却不是世界和平的答案。

红帽公司中间件部门工程副总裁Mark Little博士:采用微服务并不意味着你那架构差强的泥球突然变得架构很好。

鉴于微服务的人气扶摇直上,那些记性不好的人可能忽略了这种方法极其类似面向服务的架构(SOA),20年前SOA第一次出现在世人眼前。

不过红帽公司中间件部门工程副总裁Mark Little博士喜欢将微服务看成面向服务的架构中的精华部分,它得益于出现了更先进的工程和运维技术及技巧。

Little说:“区别就在于,推动它的主要是开发软件和分布式软件领域的新方法。Linux容器等技术――Docker就是个典例。你现在有了不 变的服务,有了Kuberneters之类用于协调那些服务的技术――很显然,你有了开发运维(DevOps),而开发运维受到敏捷开发理念的重大影 响。”

“那些技术让人们真正回顾我们在过去开发分布式系统的方法,面向服务的架构就是这方面的一个例子,并挑选与那些技术相匹配的精华部分。或者反之亦 然,找到与面向服务的架构的一些精华部分相匹配的那些技术。这可能就是区别所在。架构方法并非不一样,但是其背后的技术确实不一样。”

在微服务架构中,应用程序组装成一组小小的半自主式进程,这些进程执行特定的任务,并使用API彼此进行联系。微服务旨在易于使用、灵活扩展,在Web应用程序、移动应用程序和物联网应用程序中日益崭露头角。

在面向服务的架构的以往不足中,Little提到了一个不足:无法在客户机和服务之间提供很好的契约定义,他还提到了Web服务描述语言(WSDL)的不足,这种语言对松散耦合、分布式的系统而言差强人意。

然而,就因为许多因素和技术融合到一起,让微服务成为当下风光无限的架构,并不能保证它就能一帆风顺。

Little说:“认识到微服务不是世界和平的答案,这一点很重要。它对一些任务来说很好。但是它跟任何技术一样,也有缺点。就因为你采用了微服 务,并不突然意味着你那架构差劲的泥球(ball of mud)突然架构变得很好,不再是泥球。它有可能变成了好多分布式泥球。”

“这让我有点担忧。我长期以来就在关注面向服务的架构,知道优点和缺点。我喜欢微服务,因为它让我们得以关注优点,但是人们以为它能解决根本就解决不了的许多问题,这确实让我担心。”

如果你正在考虑微服务,最好从良好的软件工程实践开始入手。

Little说:“从根本上来说,这正是面向服务的架构背后的思想。如果你不从那方面开始入手,无论你使用Docker、虚拟化、Java虚拟机还是使用其他什么都不重要,合适的工具不会为你解决架构问题。”

微架构或者甚至面向服务的架构真正发挥所长的地方在于,应彼此独立部署的逻辑服务,这些逻辑服务可以独立于其他服务进行扩展,而且能够实现独立的故障切换。

Little说:“我在微服务方面担心的问题之一就是,你有一个整体式系统(monolith),假设你开始把它分解成多个服务,可是分解时很随意,到头来就会分解得过细,最后会有10个、100个甚至1000个微服务。”

“但是这些微服务又彼此高度依赖,以至于如果某一个服务出现故障,其余服务很有可能也会出现故障。这种情况下,你一无所获。你有999个服务就在那里干等着另一个服务恢复正常运行。”

据Little声称,那些开始使用微服务的人应该找出未能实现其功能的软件,而不是就因为使用年限而把那些旧软件挑出来。

他说:“找出对你来说确实没有发挥功能的软件――我强调的是没有发挥功能的那个组件,因为你如今可能拥有在过去30年一直顺畅运行的整体式系统,而且全年365天很顺利地处理你交给它处理的负载。”

“在这种情况下,把整体式系统分解成微服务可能不会给你带来多大的好处。但是你可能会有完全相反的整体式系统:来来去去的不同团队长年累月构建了某套系统,你只好不断给它打补丁。”

“该系统甚至可能很不可靠,用许多不同的语言来实施,你在考虑无论如何要重新实施它。这种情况下,就很适合使用微服务。”

除了深入了解应用程序的功能、它在哪里没有实现功能外,还要明白它里面的哪些组件可以分解成微服务,但切忌过犹不及。

Little说:“你不应该把它分解成太小的微服务。有些人甚至在谈论纳米服务(nano service),那未免也太过了。别这么做。明白你将如何衡量成功,这通常很重要,对微服务来说尤为重要。”

即使在软件没有发挥功能的情况下,也要避免从头开始重新实施一切,因为有些部分可以保留下来。

Little说:“如果你拥有的软件没有发挥功能,仍应该看看有些部分能不能保留下来――要是软件部署已有二十三年,好多人在使用它,更是要有所保留,要是它是用COBOL实施的,更是要有所保留,这表明它久经考验。”

“比如说,由于你在圣诞节那天的请求规模比30年前多出几个数量级,软件如今对你来说可能没发挥功能。但是这并不意味着那些COBOL代码中就没有 一些基础的部分可以拿来重复使用。应该可以重复使用,因为就算软件错误出现在新的系统中,你也希望它们是新的软件错误。你不希望重新引入已加以解决的旧软 件错误。”

所以,有的操作系统(unit of work)可以独立于其他一切而部署;它们可能会出故障,但不会引起应用程序的其余部分陷入停顿;还可以独立于其他一切进行扩展,找出了这种操作单元后,下一步就是考虑你可以对它定义什么样的契约。

Little说:“该契约将包括其接口:我如何远程调用它,我用什么来远程调用它?许多人谈论微服务和代表状态传输协议(REST);REST对微服务来说绝对是一种根本方法。但是它未必就是你想与服务进行联系的唯一方法。”

“你可能想使用一种二进制协议与服务进行联系。可能除了使用一些老式协议与它进行联系外,你别无选择。如果是COBOL,尽管你改用微服务,你的架 构中可能仍有相当多一部分仍与公共对象请求代理架构(CORBA)紧密相关。它可能不是与你的微服务进行联系的独家方式,但是你可能得在某个地方要有 CORBA适配件。”

之后是典型的分布式系统问题,因为一旦你开始创建可独立扩展的微服务,通过HTTP或二进制协议的远程交互其速度将不如内存中的过程调用。

Little说:“所以你要担心调用远程服务意味着什么,如果你在响应时间方面有严格要求,更要担心了。越是将这些东西分解成服务,无论它们是宏服务、微服务还是纳米服务,你越要开始担心:我是在分布式环境中运行。这对我来说意味着什么?我的应用程序实际上忍受得了吗?”

“因为我可能确实需要微服务,可是很遗憾,除非有人发明一种网络使用超光速粒子来传输信息,否则我其实无法调用任何东西,因为我从来无法履行我的契约义务。我的一切都在大泥球里面。”

    • 评论
    • 分享微博
    • 分享邮件
    邮件订阅

    如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。

    重磅专题
    往期文章
    最新文章