关于FaaS和微服务，什么是最合理的架构

又是翻译一篇，主要在概念和使用场景上来介绍FaaS和微服务，并不是介绍他们具体是什么。而是在对服务架构和业务结合的角度上去看待架构问题。微服务不是全部也不是未来的唯一的架构设计，在我们经历了单体架构，SOA，微服务，无服务架构还是其它的服务架构，从本质上来说一定是有业务需要才出现，而且一定是随着业务规模发展，组织大小变化，组织文化，和组织资本等各个方面去思考，当前我们应该采用那种架构最合适。

原文：https://dzone.com/articles/faas-vs-microservices

作者：Christian Posta

采用微服务是没有一刀切的。你需要务实的去看在你的技术栈中采用怎么样的微服务+FaaS。

在本地云开发中，你可能正在为你下一代应用采用微服务架构。在DevOps和自动化构建上你或许已经取得初步成功，从而为你的微服务开发开辟了道路。或许一年之后，你也许会继续把你公司的其他人也劝到这条路上来。过程中无论如何都会遇到一些想到和想不到的问题。微服务是一个复杂的架构模式而且分布式系统它本身也是不容易做好的。当你朝着这个方向进行的并且解决一些挑战的时候，你就会遇到一些反对的声音或者一些人想走另外的路子。随着技术的快速发展，在构建服务和应用上新的选择不断出现。你能确定你能把微服务作为你组织的成功因素？而不是白费功夫。

简单的回答是是可以确定的。

近来，发现无服务和函数即服务已经处在操作早期了。目前有人也说服务和函数即服务就是下一代服务的发展，所以你应该跳过整个微服务架构的发展而直接进入无服务时代。正如你所看到的那样，有点夸张了。你也不用感到惊讶。作为架构师和开发人员还是有很多令人兴奋的技术来提升我们的能力去达成业务成果。我们也需要一个务实的角度去看待和判断使用这些新技术。虽然作为技术从业者，我们有责任去跟进最新技术，同样我们应该要知道新技术什么时候应用到我们已有的技术和IT部门中。让我们来看一个模型，从而了解微服务架构和函数即服务的无服务怎么适应我们的工具箱中。

首先，我们看看为什么我们会用微服务架构。我们采用微服务架构的主要原因就是针对单体架构在变更时会成为瓶颈，而微服务可以提升应用变更效率。微服务架构其它所有的优势都是以这个为基础的。当然我们为什么要快速变更应用也是为了更快速的向客户提供新特性和功能，以测试我们是否可以通过这些修改来实现预期的好结果。如果我们针对提升业务结果而做的软件变更无效，那么我们就需要尽快的尝试一些新的方向。微服务是一个让我们可以针对我们的应用架构优化作出非常快速的发展并且让我们自己也可以更快的变化。

大多数组织会发现，定制构建应用会在一定程度上受益于微服务架构的发展。这些变化对构建应用是有好处的，而作为架构师和开发者，我们不能因为这些遇到的障碍而灰心。有一些重要的指标来说明采用微服务之后的进步：比如每天对软件我们可以做多少次变更，变更如此多，安全成功变更了多少次，等等类似的方式。

另一方便，不是所有的应用都需要一组高度复杂，可拆分的服务来快速演进。相反，当你要开发一个最小可用产品作为试验品来测试你的创意在市场上的价值，你就会为这样的产品生命周期而采用不同架构来做到快速开发快速上线。对于MVP测试来说，你很有可能失败并且市场价值也会很小。如果这样，你就可以直接放弃这个MVP应用。MVP可以做到快速迭代和从潜在用户那里获取到反馈。在这种场景下，产品的商业价值还未知，你在代码中实现的内容会不断的修改（项目没有失败的情况下），并且在不断迭代前行的过程中你对代码的认识也在不断深入。在这种环境下，你将不断更改API，系统边界，和组件来构建系统。过早的使用API设计把所有组件都修改为分布式服务会影响开发速度。你可以不断的修改API和组件，并且不断协调你开发各个单体服务的小团队。你也可以直接就是采用单体架构开发，从而让开发更快的开发。

这一点上，我们看到微服务架构适合一部分应用开发，而单体架构适合另外一部分。没有什么一刀切的方式。从另外一个角度看微服务架构和单体架构：你需要的开发的功能是否已经作为第三方服务存在了或者你的公司已经有了这类服务了，这取决于你是想优化现有的架构还是测试你的想法。我们可以充分利用现有的服务来构建我们需要的应用，而无需购买硬件，无需安装和修补操作系统，无需为应用生命周期中的预期的高流量而优化容量，这正是云和其服务存在的意义。云服务商和其合作者（云上的第三方服务提供商）通常会提供数据库，消息队列，缓存，CND，甚至更高级的功能，比如语言翻译、地图/地理空间坐标地图、天气等。这些服务按需付费，你可以灵活自由的组合构建你的应用。当我们直接使用现有的高阶服务而不用担心怎么安装，提供和计划容量的时候，我们就开始向“无服务”架构进发了。无服务架构尽量使用已有的服务来构建应用而无需担心运行服务需要什么。是以服务为提供对象的服务。

函数即服务就是一种无服务，因为它允许我们使用计算模型（范围缩小单个应用函数）帮助我们把构建应用可能需要的各种服务无缝组合起来。在这种计算模型中，函数按需运行，而且只为函数运行的时间计费。这种非常适合针对可能使用多种服务而且可以按需计费按需付费的服务。如今你可以构建可扩展的应用，而不必担心实现这些服务的技术难度。这是服务提供商或者云提供商的问题了。如果你可以外包大量这类复杂的基础服务，按需付费，而更多专注于你特别的业务逻辑，你就能更快的实验你的点子，且为你的客户提供价值。

然而，外包这类功能并不是一直可行的。当我们决定使用云服务，我们就放弃了对运行时间、SLA、特性路线图，问题修复，监管合规等的控制。这可能是对一部分事情或者一部分组织权衡的结果。有些组织或者事情可能不愿意这样做。

然而，无服务架构不必是一个完整的“公有云或者无云”方案。如果我们在一个组织内去看，它的部分功能对其它部分来说就可能是“无服务”的。例如，零售运营的购买方可能为组织的其它方提供服务，或者甚至为第三方买方或合作者提供服务，并且帮助他们构建分析，推荐或者使用购买者服务的其它应用。使用定义规范的API和申请使用API的流程，你就可以使用基于你自己的基础设施或者云的微服务或者单体服务来提供无服务服务了。在很多方面来说，这只是SOA的一种演进。当你你自己（或者你个租住的一部分为另外一部分提供服务）在做的时候的最大不同就是组织作为一个整体而不是无服务的；任然有些人还需要去为服务安装，管理和打打补丁，并且维护所有的基础支撑设施。

最终，当我们决定我们可以采用什么样的应用架构或者技术的时候，业务决策，业务目标，一个IT组织的成熟度和能力，还有已经存在的约束条件都会参与到我们的决策当中来。如果你是应为正确的原因而采取了微服务架构，那就不要被其它东西分心了。相反，你则需要不断的学习最新的技术和技巧来知道如何使用他们。总结一下，当体架构，微服务架构和无服务架构都有适合他们的地方。

看完本文有收获？请分享给更多人

关注「黑光技术」加星标，关注大数据+微服务