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

草根开发群体的大力支持正在将微服务架构的采用率推到新的高度。据红帽公司中间件专家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说：“所以你要担心调用远程服务意味着什么，如果你在响应时间方面有严格要求，更要担心了。越是将这些东西分解成服务，无论它们是宏服务、微服务还是纳米服务，你越要开始担心：我是在分布式环境中运行。这对我来说意味着什么?我的应用程序实际上忍受得了吗?”

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