微服务在实际项目中的应用

在 GOTO Berlin2015 大会上，Alexander Heusingfeld 进行了一场名为“当微服务遇上实际项目”的演讲。InfoQ 对Alexander Heusingfeld 与他的同事Tammo van Lessen 进行了一次采访，谈到了如何让来自运维团队的人员参与架构、在实施DevOps 实践时如何处理“各管各的”这样的行为、如何通过自包含的系统方式实现现代化的软件系统、自包含的系统与微服务之间的相似之处与差异、如何改进部署管道并在部署时进行测量。还谈到了Alexander 在一个“离开自己熟悉的领域”的活动中获得的经验。

InfoQ：你如何向来自于系统运维团队的人员推荐某种架构，这对于他们来说有什么意义？

Heusingfeld：只有实际进行日常业务工作的人员接受了某种系统架构，这种架构才能够体现出价值。因此，在开展一个新的项目时，我的第一步总是尝试与来自于运维团队和业务部门的人进行交流，并认真地倾听他们的声音。他们都很擅长于介绍公司和流程，以及流程对于日常业务的影响。在讨论系统的新特性、流程的变更或改进时，这些见解的价值是无可估量的。一旦他们感到自己的想法得到理解，并且意识到我确实考虑到了他们的关注点，那么我就完全不必刻意地推销我的观点了。

van Lessen：这主要取决于人与人之间的信任。我经常需要面对一些来自于运维团队的成员，他们对于新的思想或技术显得非常抗拒。我想这是因为他们对于维护与支持新的系统感到不安，其实他们可能还没有完全从运维的角度理解这种变化，也不明白这些技术对于项目的重要性。项目成功的一个重要因素是让这些成员尽早地参与到项目的架构设计阶段，这种做法能够在团队中实现思想的共享，在整个团队中的开发与运维工作这两方面达成互相依赖与互相理解。

InfoQ：在实施 DevOps 时，来自于不同部门的人将成为同一团队的成员，这使得实施工作将面临许多挑战。当你希望团队成员之间能够密切合作时，对于可能出现的“各管各的”这种表现，你有什么建议？

van Lessen：DevOps 正是克服“各管各的”这种行为的第一步，它意味着成立一个跨职能的团队。传统的做法是通过一些刻板的流程人为地建立一条鸿沟，然后不断地调整某个团队如何将信息丢给另一个团队的做法。我非常确信，与之相比，实施 DevOps 团队所面对的挑战要小得多。真正的挑战在于如何让采用传统做法（或类似做法）的公司转而采用新的做法。在许多情况下，让人们放弃陈旧的习惯而采用新的途径总是非常困难的。

Heusingfeld：我们经常注意到一个现象，当来自于不同部门的人组成了一个跨职能的团队后，有可能会产生小团队之间的战争，尤其是在保持了传统的部门结构的情况下。这也是为什么我认为所有团队成员的最高优先任务必须是实现团队的目标。部门的直接领导绝不可为某个团队成员安排更高优先级的任务或与团队相抵触的任务。在这种情况下，团队成员要么被迫加班，要么就得让其他成员失望。如果这种情况持续发生，那么团队成员之间就将失去信任。正如我们所知，如果我们无法信任某人，那么也无法在关键性的场合中依赖他们。具体来说，这意味着无法相互信任的团队成员也无法实现最佳的效率，并且在面对压力时很可能会很挣扎。因此我们建议在成立团队时进行一些团队建设，在团队成员之间建立信任关系。

InfoQ：你在 GOTO Berlin 大会上提到了一种自包含系统的架构方式，你能否概括性地解释一下这种方式？

van Lessen：自包含系统（SCS）描述的是一种构建软件系统的架构方式，例如将一体化的架构切分为多个功能相互分离，而又保持自治的 web 应用。关键在于，SCS 应当负责自己的 UI 以及数据存储部分。系统的边界展现了一个垂直的分片，这在领域驱动设计（DDD）中被称为“边界上下文”。在多数情况下，整个应用是通过连接与嵌入的方式在浏览器中将每个 SCS 部分整合到一起的。这些系统既不会共享某种通用的 UI 代码，也没有通用的业务逻辑。每个系统可能都是由独立的团队自行选择技术进行维护的。如果做得足够好，那么终端用户将能够流畅地游走于各个系统之间，通过点击连接或单击按钮的方式跨越应用的边界。在理想的情况下，用户甚至不会注意到他们已经离开了某个系统而进入了另一个系统。通过渐进增强的方法，这种架构方式将能够支持所有浏览器，从陈旧的到现代化的、从屏幕阅读器到移动电话。有些应用会直接显示跳转至某个系统的链接，而有些应用会将连接替换为某种在视觉上效果更好的方式，但所展示的内容是相同的。

Heusingfeld：我注意到，来自于运维团队的成员认为自包含系统（SCS）架构方式是一种合理地构建与保持系统现代化的方式。在我看来，SCS 有助于避免由于过多的复杂性而压垮团队成员。这一点对于我来说至关重要，因为正如我之前所说，负责每日业务的人需要理解你打算引入变化的原因与做法，才能够支持你的工作。我们还收集了大量有关 SCS 方式的内容，对此有兴趣的读者可以访问 http://scs-architecture.org/ ，并参与我们的讨论。

InfoQ：你能否举几个例子说明如何运用自包含系统方式构建现代化的软件系统？

Heusingfeld：关于 SCS 方式的应用有两个非常有力的例子，即 otto.de（请参与德语的Otto TechBlog ）以及 Galeria Kaufhof 。在 scs-architecture.org 网站可以找到更多的参考资料与文章。除了学习案例之外，另一个有趣的方面是如何在不下线的情况下将一个一体化的架构切分为 SCS 架构。正如我们在演讲中提到的，我们收集了一些典型的改进方式，成功地用于改进系统的过程中，并将这些内容以一个名为 aim42 的架构改进方法的名义进行发布。尤其是其中“干掉坏的部分”以及“通过萃取进行改变”这两种策略由 SCS 进行实现看起来是很自然的选择。在这两种情形中，你首先要在你的一体化应用中找到那些需要移植到新系统中的功能。SCS 将解答你关于如何切分旧系统的疑问：找到这一功能对应的业务领域，将其放入在 SCS 中同样只负责这一领域功能性代码，即包含相同用例的对应位置。如果你的一体化架构无法做到清晰地分离业务领域，SCS 方法能够为你提供一定的自由度，以实现粗粒度的步骤。例如你可以首先将一个一体化架构分为两个 SCS 系统，然后通过小型的迭代逐步改进。在 aim42 中对此专门有一个改进方式，名为“通过切分进行改变”

InfoQ：你能否详细地解释一下自包含系统方法与微服务之间的相似点与区别？

van Lessen：SCS 与微服务之间有许多概念是相通的。例如在技术选型中保持灵活性与多样性、保持组织边界与架构边界的一致性、以及通过独立的可部署单元实现功能的隔离。不过，SCS 显然更为粗粒度一些。实际上，SCS 应用可以由内部的微服务组合实现。SCS 的意图是在 UI 层进行整合，而微服务比较多的是在一个较大的应用的逻辑层进行组合。因此，虽然两者都基于同样的思想，但 SCS 将微服务原本的思想推到了一个宏观的层面上。

InfoQ：有人可能会说，既定的流程可能会限制部署的速度，你们对此有什么建议？

Heusingfeld：有些时候，如果在交付流程中需要进行合规性与安全性的审计，或是需要进行大量的手工测试，那么你确实有可能会听到这种说法。从我的经验来看，人们在流程变更的一开始通常会产生排斥的态度，其原因一是他们不相信最终的益处会像宣告中说的的那么好，二是他们认为不值得付出那么多精力。因此，我不建议一上来就尝试将所有过程都自动化，而是选择较小的步骤，从与你最相关的部分开始自动化。要实现软件部署的自动化，例如在开发团队中搭建一台类似于 Jenkins 的 CI 系统的服务器，这种事一般不会遇到什么合规性问题。可以通过这种系统实现自动化验收测试，为团队提供快速的反馈，以了解应用的行为是否符合预期，或者是否破坏了某些功能。一旦团队表现出了速度与质量方面的提高，团队的经理就能够向管理层分享这个“成功信号”。这样，其他团队也能够认可他们的做法，如果能够找到符合自己需求的益处，这些团队也很可能开始实施这些实践。因此，即使你在交付过程中需要手动操作，也可以持续地进行改进并逐步地实现自动化，可随意选择在手动操作过程之前或之后执行这些自动化脚本。整个过程就像是工厂中的生产线一样运转。

van Lessen：尽管如此，但在某些情况下，这种规则确实是无法改变的。我曾经在一些大公司中遇到这种问题，他们的 IT 部门并非头等公民，而只是实现目的的一种手段而已。他们的核心业务都建立了严格的流程制度，然后同样延伸到了 IT 部门。这种情况下，IT 部门基本没有什么力量去主动地打破公司级别的规章制度。不管怎样，在一些流程的边缘地带，仍然有机会尽量实现一些自动化过程。

InfoQ：你们能否分析一下，如何通过透明的部署管道探索及改进软件的交付过程？

Heusingfeld：我们曾遇到过一个客户，他希望“晚一点再实现自动化”，其原因正如我在之前的例子中提到的“合规性”问题。他们也通过 KPI（关键业绩指标）衡量某个软件的特性是否成功。因此，在软件真正部署到生产环境并获得 KPI 指标之前，团队完全不知道他们是否在做正确的事。我们决定检查一些这些指标数据是如何收集的，随后便发现我们应该在部署到生产环境之前获取这些指标。最终，我们不仅在集成测试的系统与手动测试阶段就收集到了这些指标，并且通过修改与添加自动化验收测试，在早期于开发服务器上进行的验收测试过程中，我们也能够获取第一批结果。通过这种方式，开发者在将代码提交到远程 Git 库的 5 至 15 分钟后就能够大致了解运行情况了。这样的洞察力能够让整个交付管道达到一个崭新的透明度，并且在团队的交付与工作中建立了信任关系，尤其是对于产品负责人来说。

InfoQ：你们能否举例说明在部署管道中如何进行检测？这种检测对于开发者来说有什么价值，他们应当如何利用这些检测结果？

van Lessen：在我看来，人们对于从应用与系统中获取运行时指标的做法还没有足够的重视。虽然实现这一点需要付出额外的努力，但它对于一个更专注的开发过程是一种非常有力的促进。我们通常会划分出三种指标：业务指标能够解答 C 级别（CIO、COO 等）管理者经常提出的一些问题；应用指标能够获取应用本身的健康和性能状况；系统指标则获取硬件与操作系统的信息。当你的指标覆盖了所有这些信息之后，就能够更深入地理解应用在每时每刻的行为。从运维的角度来说，这对于生产环境来说是最迫切的。但正如 Alex 所说，这些信息也为开发者提供了一些见解，以持续地分析他们的实现的质量。我举一个具体的例子：用户抱怨说报表的生成时间太长，而你从“太长”这个描述中无法获得任何信息。生产环境中的指标能够立即回答这一问题，而从一个运行在 CI 系统中的测试过程中所获得的同一指标则能够帮助开发者分析如何解决问题。这里可能包含了多个不同的指标，业务指标或者是“我们每天能够生成多少份报表”，而应用指标则回答你的疑问，到底是数据库访问还是 PDF 的生成消耗了更多的时间。如果 CPU 处于空闲状态（系统指标），而报表的生成依然很慢，那可能是出现了并发问题，例如连接池中的连接都处于阻塞状态因而没有可用的连接。而在部署管道中，同样的指标则能够更早的回答一些疑问，例如“新的代码是否有所改进？”。在理想的状态下，开发者在提交代码后就能够立即知道答案。这种做法也能够让找到某个问题的解决办法更简单。

Heusingfeld：众所周知，持续交付管道能够带来快速的反馈，并让开发者能够更多地接触到许多问题的解答，而我们则充分地利用了这一点。通过对堆的使用、CPU 的利用率、或网络及磁盘的 I/O 进行分析，我们就能够指出某个代码改动是否对应用的性能产生了负面的影响。不仅如此，我们还能够做到更进一步。产品负责人通常会对生产环境中的 KPI 进行分析，以检查产品的表现情况。这些指标可能包括“结账流程的时间”或“过去 24 小时内新注册客户的数量”。我们可以向产品负责人了解有哪些指标将用于计算他们的 KPI，并尝试在运行自动化测试的环境中对这些指标加以分析。这种做法可能不适用于所有生产环境中的 KPI，但或许比你想象中要多。

InfoQ：你在演讲中提到，在你之前的某个公司中，曾开展过一个“离开自己熟悉的领域”的活动。你能否分享一下你的经验，以及从这一活动中学到了什么？

Heusingfeld：这家公司为员工安排了一个项目，让每个人都在一个陌生的部门中工作一天时间，至少每三个月就要进行一次。负责控制系统的员工可能会出现在数据中心里，市场人员可能要去仓库，而开发者也可能要参与 HR 团队的工作。我本人当时在 IT 部门为销售点开发一个 Java 应用，我很乐意与一名销售经理一起访问几家店铺。这不仅能够让我看到所开发的软件得到了实际应用，他还要求我通过这一软件销售产品。这为我提供了一个全新的视角，我终于意识到在软件测试过程中将自己想象为一名用户与在现实生活中的实际应用是完全不同的：销售要面对压力与催促，这已经改变了我的使用行为，并且销售点的环境与一个受到保护的办公环境中完全不同的。这次体验对我来说是无价之宝！还有一次，一位物流组的员工来到了开发部门，你可以想象人们会对他多少有些偏见。大家都不知道如何与他共处，因为“他完全不懂写代码”。因此大家决定带他四处看看，让他了解软件是如何构建的，并通过一些易懂的图形为他解释我们的交付流程。结果这家伙突然冒出了一句话：“抱歉，如果我理解的没错，如果你们真的这么做，那么就是在浪费时间”。每个人都为此感到震惊，并要求他解释。他用了两个小时描述了他的观点，并指出了我们的流程中某个低效的地方，而我们自己这几个月都没有发现这一点，这真是上帝的赏赐。我从这些经验中至少学到了两点，即“别让偏见蒙蔽了你的双眼”，以及“经常换一个角度思考！”。

关于受访者

Alexander Heusingfeld是德国 innoQ 公司的一位软件架构与工程方面的高级顾问。作为一位顾问、软件架构师与开发者，他以他对 Java 以及基于 JVM 的系统的长期了解为客户提供支持。他经常参与企业应用整合（EAI）、现代 web 应用以及微服务架构的设计、分析以及实现工作。他乐于为开源项目贡献代码、在 IT 大会与 Java 用户组中进行发言，并偶尔会在 http://goldstift.de 上发表一些博客文章。

Tammo van Lessen是德国 innoQ 公司的软件架构与工程方面的首席顾问，他同时被选为 Apache 软件基金会的一名成员，以及 Apache ODE 的 PMC 主席。他参与了一本有关 WS-BPEL 的德文书，也是 OMG（对象管理组织）的 BPMN 2.0 Finalization Task Force 的一名成员。他自认对于软件架构、DevOps 和现代化监控工具的尺度总是掌握不好。他曾在 Web service 与业务流程执行方面发表了一些学术性与非学术性的文章。同时，他也经常在国内与国际性的大会上进行演讲。

查看英文原文： Microservices in the Real World