微服务架构全解析

1、微服务架构全解析：绝不是360度无死 角草根开发群体的大力支持正在将微服务架构的采用率推到新的高度。据红帽公司中间件专家 Mark Little博士声称，微服务是个好东西，却不是世界和平的答案。红帽公司中间件部门工程副总裁Mark Little博士：采用微服务并不意味着你那架构差强的泥 球突然变得架构很好。鉴于微服务的人气扶摇直上，那些记性不好的人可能忽略了这种方法极其类似面向服务的架 构(SOA)，20年前SOA第一次出现在世人眼前。不过红帽公司中间件部门工程副总裁Mark Little博士喜欢将微服务看成面向服务的架构中 的精华部分，它得益于出现了更先进的工程和运维技术及技巧。Little

2、说：“区别就在于，推动它的主要是开发软件和分布式软件领域的新方法。Linux容器 等技术一一Docker就是个典例。你现在有了不变的服务，有了 Kuberneters之类用于协调那 些服务的技术一一很显然，你有了开发运维:DevOps)，而开发运维受到敏捷开发理念的重大 影响。”“那些技术让人们真正回顾我们在过去开发分布式系统的方法，面向服务的架构就是这方面 的一个例子，并挑选与那些技术相匹配的精华部分。或者反之亦然，找到与面向服务的架构 的一些精华部分相匹配的那些技术。这可能就是区别所在。架构方法并非不一样，但是其背 后的技术确实不一样。”在微服务架构中，应用程序组装成一组小小的半自主式进程

3、，这些进程执行特定的任务，并 使用API彼此进行联系。微服务旨在易于使用、灵活扩展，在Web应用程序、移动应用程 序和物联网应用程序中日益崭露头角。在面向服务的架构的以往不足中，Little提到了一个不足：无法在客户机和服务之间提供很 好的契约定义，他还提到了 Web服务描述语言(WSDL)的不足，这种语言对松散耦合、分布 式的系统而言差强人意。然而，就因为许多因素和技术融合到一起，让微服务成为当下风光无限的架构，并不能保证 它就能一帆风顺。Little说：“认识到微服务不是世界和平的答案，这一点很重要。它对一些任务来说很好。 但是它跟任何技术一样，也有缺点。就因为你采用了微服务，并不突然意味

4、着你那架构差劲 的泥球(ball of mud)突然架构变得很好，不再是泥球。它有可能变成了好多分布式泥球。” “这让我有点担忧。我长期以来就在关注面向服务的架构，知道优点和缺点。我喜欢微服务， 因为它让我们得以关注优点，但是人们以为它能解决根本就解决不了的许多问题，这确实让 我担心。”如果你正在考虑微服务，最好从良好的软件工程实践开始入手。Little说：“从根本上来说，这正是面向服务的架构背后的思想。如果你不从那方面开始入 手，无论你使用Docker、虚拟化、Java虚拟机还是使用其他什么都不重要，合适的工具不 会为你解决架构问题。”微架构或者甚至面向服务的架构真正发挥所长的地方在于，应彼

5、此独立部署的逻辑服务，这 些逻辑服务可以独立于其他服务进行扩展，而且能够实现独立的故障切换。Little说：“我在微服务方面担心的问题之一就是，你有一个整体式系统(monolith)，假设你 开始把它分解成多个服务，可是分解时很随意，到头来就会分解得过细，最后会有10个、100个甚至1000个微服务。”“但是这些微服务又彼此高度依赖，以至于如果某一个服务出现故障，其余服务很有可能也 会出现故障。这种情况下，你一无所获。你有999个服务就在那里干等着另一个服务恢复正 常运行。”据Little声称，那些开始使用微服务的人应该找出未能实现其功能的软件，而不是就因为使 用年限而把那些旧软件挑出来。他说

6、：“找出对你来说确实没有发挥功能的软件一一我强调的是没有发挥功能的那个组件， 因为你如今可能拥有在过去30年一直顺畅运行的整体式系统，而且全年365天很顺利地处 理你交给它处理的负载。”“在这种情况下，把整体式系统分解成微服务可能不会给你带来多大的好处。但是你可能会 有完全相反的整体式系统：来来去去的不同团队长年累月构建了某套系统，你只好不断给它 打补丁。”“该系统甚至可能很不可靠，用许多不同的语言来实施，你在考虑无论如何要重新实施它。 这种情况下，就很适合使用微服务。”除了深入了解应用程序的功能、它在哪里没有实现功能外，还要明白它里面的哪些组件可以 分解成微服务，但切忌过犹不及。Little

7、说：“你不应该把它分解成太小的微服务。有些人甚至在谈论纳米服务(nano service)， 那未免也太过了。别这么做。明白你将如何衡量成功，这通常很重要，对微服务来说尤为重 要。”即使在软件没有发挥功能的情况下，也要避免从头开始重新实施一切，因为有些部分可以保 留下来。Little说：“如果你拥有的软件没有发挥功能，仍应该看看有些部分能不能保留下来一一要 是软件部署已有二十三年，好多人在使用它，更是要有所保留，要是它是用COBOL实施的， 更是要有所保留，这表明它久经考验。”“比如说，由于你在圣诞节那天的请求规模比30年前多出几个数量级，软件如今对你来说 可能没发挥功能。但是这并不意味着那些

8、COBOL代码中就没有一些基础的部分可以拿来重 复使用。应该可以重复使用，因为就算软件错误出现在新的系统中，你也希望它们是新的软 件错误。你不希望重新引入已加以解决的旧软件错误。”所以，有的操作系统(unit of work)可以独立于其他一切而部署;它们可能会出故障，但不会引 起应用程序的其余部分陷入停顿;还可以独立于其他一切进行扩展，找出了这种操作单元后， 下一步就是考虑你可以对它定义什么样的契约。Little说：“该契约将包括其接口 ：我如何远程调用它，我用什么来远程调用它?许多人谈论 微服务和代表状态传输协议(REST);REST对微服务来说绝对是一种根本方法。但是它未必就 是你想与服

9、务进行联系的唯一方法。”“你可能想使用一种二进制协议与服务进行联系。可能除了使用一些老式协议与它进行联系 外，你别无选择。如果是COBOL，尽管你改用微服务，你的架构中可能仍有相当多一部分 仍与公共对象请求代理架构(CORBA )紧密相关。它可能不是与你的微服务进行联系的独家方 式，但是你可能得在某个地方要有CORBA适配件。”之后是典型的分布式系统问题，因为一旦你开始创建可独立扩展的微服务，通过HTTP或二 进制协议的远程交互其速度将不如内存中的过程调用。Little说：“所以你要担心调用远程服务意味着什么，如果你在响应时间方面有严格要求， 更要担心了。越是将这些东西分解成服务，无论它们是宏服务、微服务还是纳米服务，你越 要开始担心：我是在分布式环境中运行。这对我来说意味着什么?我的应用程序实际上忍受 得了吗？”“因为我可能确实需要微服务，可是很遗憾，除非有人发明一种网络使用超光速粒子来传输 信息，否则我其实无法调用任何东西，因为我从来无法履行我的契约义务。我的一切都在大 泥球里面。”原文标题：Microservices 101: